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 >> <[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 _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
