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 >>> <bog...@voice-system.ro <mailto:bog...@voice-system.ro>> wrote: >>> >>> Jock McKechnie wrote: >>>> >>>> >>>> On Tue, Apr 13, 2010 at 5:04 AM, Bogdan-Andrei Iancu >>>> <bog...@voice-system.ro <mailto:bog...@voice-system.ro> >>> <mailto:bog...@voice-system.ro <mailto:bog...@voice-system.ro>>> >>> wrote: >>>> >>>> Hi Jock, >>>> >>>> Jock McKechnie wrote: >>>>> >>>>> On Mon, Apr 12, 2010 at 10:48 AM, Bogdan-Andrei Iancu >>>>> <bog...@voice-system.ro <mailto:bog...@voice-system.ro> >>> <mailto:bog...@voice-system.ro <mailto:bog...@voice-system.ro>> >>>> <mailto:bog...@voice-system.ro >>> <mailto:bog...@voice-system.ro> <mailto:bog...@voice-system.ro >>> <mailto:bog...@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:passw...@192.168.0.20/company >>> <http://openser:passw...@192.168.0.20/company> >>>> <http://openser:passw...@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:+14109999...@192.168.0.2 >>> <mailto:sip%3a%2b14109999...@192.168.0.2> >>>> <mailto:sip%3a%2b14109999...@192.168.0.2 >>> <mailto:sip%253a%252b14109999...@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@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
