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

[Bogdan-Andrei Iancu]

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