[OpenSIPS-Users] One dispatcher mystery solved; Doesn't seem to be "remembering" a gateway is failed however

[Richard Revels]

Another little harmless thing is the 1.6 documentation calls out ds_ping_sock but the param is ds_ping_from.  Didn't see this mentioned on the list so I don't think this has changed in more recent revisions.

Richard

On Apr 16, 2010, at 6:48 AM, Bogdan-Andrei Iancu wrote:

> Hi Jock,
> 
> ok, while investigating, I found a small harmless bug in the 
> ds_next_xxxx() functions - they were trying to populate the ATTR avp 
> even if it was not set - this was the reason for the err message you 
> were getting.
> 
> The bug was fixed, so if you update from SVN it should go away.
> 
> Regards,
> Bogdan
> 
> Jock McKechnie wrote:
>> 
>> 
>> On Thu, Apr 15, 2010 at 8:41 AM, Bogdan-Andrei Iancu 
>> <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>> wrote:
>> 
>>    Jock McKechnie wrote:
>>> 
>>> 
>>> On Tue, Apr 13, 2010 at 5:04 AM, Bogdan-Andrei Iancu
>>> <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>
>>    <mailto:bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>>>
>>    wrote:
>>> 
>>>    Hi Jock,
>>> 
>>>    Jock McKechnie wrote:
>>>> 
>>>> On Mon, Apr 12, 2010 at 10:48 AM, Bogdan-Andrei Iancu
>>>> <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>
>>    <mailto:bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>>
>>>    <mailto:bogdan at voice-system.ro
>>    <mailto:bogdan at voice-system.ro> <mailto:bogdan at voice-system.ro
>>    <mailto:bogdan at voice-system.ro>>>>
>>>    wrote:
>>>> 
>>>>    Hi Jock,
>>>>> I'm wondering if the above error is some kind of AVP
>>>    storage thing I
>>>>> haven't set up that is causing it not to properly
>>    "mark" the
>>>>    gateway,
>>>>> or more likely, not remember the mark. But I can't spot
>>>    anything in
>>>>> the dispatcher documentation that says as such.
>>>>    your guess is right - dispatcher module uses AVPs to keep
>>>    the state
>>>>    (between sequential tries on the same dialog).
>>>> 
>>>>    I guess the ds_mark_dst() fails - can you check this?
>>>    (this function
>>>>    search for the dst and grp avps to identify the last tried
>>>>    destination.).
>>>> 
>>>> Greetings Bogdan, and thanks as always;
>>>> 
>>>> I tried this:
>>>>        if( t_check_status("408") ){
>>>>                xlog( "L_NOTICE", "[$Tf] FR: $ci --
>>    TIMEOUT for
>>>> Gateway $rd (marking as bad)\n" );
>>>>                if (!ds_mark_dst("p")) {
>>>>                        xlog("L_NOTICE", "[$Tf] Panic! Not
>>>    marked\n");
>>>>                        }
>>>>                }
>>>> 
>>>> No 'Panic' in the logs.
>>>> 
>>>> The dst and grp AVPs are set up, as you saw on my original
>>    post,
>>>> but... that doesn't mean I'm not missing anything.
>>>> 
>>>    So, ds_mark does not fail .....
>>> 
>>>    Are you 100% sure your script does define the "cnt" "grp"
>>    "dst" avp
>>>    params for the dispatcher module ????
>>> 
>>> Unless somehow I'm doing it wrong, pretty sure:
>>> 
>>> # Set up the dispatcher
>>> modparam("dispatcher", "db_url",
>>> "mysql://openser:password@192.168.0.20/company
>>    <http://openser:password@192.168.0.20/company>
>>> <http://openser:password@192.168.0.20/company>")
>>> modparam("dispatcher", "table_name", "dispatcher")
>>> modparam("dispatcher", "flags", 2 )
>>> 
>>> modparam("dispatcher", "dst_avp", "$avp(i:271)")
>>> modparam("dispatcher", "grp_avp", "$avp(i:272)")
>>> modparam("dispatcher", "cnt_avp", "$avp(i:273)")
>>> 
>>> modparam("dispatcher", "ds_ping_method", "OPTIONS")
>>> modparam("dispatcher", "ds_ping_interval", 5)
>>> modparam("dispatcher", "ds_ping_from",
>>    "sip:+14109999351 at 192.168.0.2
>>    <mailto:sip%3A%2B14109999351 at 192.168.0.2>
>>> <mailto:sip%3A%2B14109999351 at 192.168.0.2
>>    <mailto:sip%253A%252B14109999351 at 192.168.0.2>>")
>>> modparam("dispatcher", "ds_probing_threshhold", 3)
>>> 
>>> As far as I can tell from the documentation and other people's
>>> examples, this should be all that is required to make this
>>    function...
>>> 
>>    Could you check and be sure the error:
>> 
>>           ERROR:core:search_first_avp: 0 ID or NULL NAME AVP!
>> 
>>    comes from the ds_mark_dst() ? - put some logs before and after
>>    it. Also eabling full debug (level 4) may also help.
>> 
>> 
>> My apologies, Bogdan, I should have done this better myself. I have 
>> traced the error to the ds_next_domain():
>> 
>> Config section from inside failure_route[]:
>> 
>> xlog("L_NOTICE", "[$Tf] HEREA\n");
>> if (ds_next_domain()) {
>>        xlog("L_NOTICE", "[$Tf] HEREB\n");
>>        .
>>        .
>> 
>> The logs contain:
>> [Thu Apr 15 11:23:06 2010] HEREA
>> ERROR:core:search_first_avp: 0 ID or NULL NAME AVP!
>> DBG:dispatcher:ds_next_dst: using [sip:192.168.0.20:5060 
>> <http://192.168.0.20:5060>]
>> [Thu Apr 15 11:23:06 2010] HEREB
>> 
>> 
>> So clearly the ds_next_domain() is producing it. However the function 
>> -is- returning the correct next entry in the dispatcher list, which is 
>> bizarre. I'm not sure, now, how this related to ds_select_domain() 
>> incorrectly choosing "marked" entries, alas.
> 
> -- 
> Bogdan-Andrei Iancu
> www.voice-system.ro
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users