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

[Richard Revels]

I take that back.  ping_from is different.  ping_sock is either in a newer version than I have or doesn't exist.

Richard

On Sep 5, 2010, at 10:25 AM, Richard Revels wrote:

> 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
>