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 > <[email protected] <mailto:[email protected]>> wrote: > > Jock McKechnie wrote: > > > > > > On Tue, Apr 13, 2010 at 5:04 AM, Bogdan-Andrei Iancu > > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > wrote: > > > > Hi Jock, > > > > Jock McKechnie wrote: > > > > > > On Mon, Apr 12, 2010 at 10:48 AM, Bogdan-Andrei Iancu > > > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>>> > > 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:[email protected]/company > <http://openser:[email protected]/company> > > <http://openser:[email protected]/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:[email protected] > <mailto:sip%3a%[email protected]> > > <mailto:sip%3a%[email protected] > <mailto:sip%253a%[email protected]>>") > > 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 [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
