Hi Bogdan, It appears my therapy was not complete. I reinstalled a current build from the devel repository since 1.4.5 was crashing/stopping in weirder ways than 1.5.0. I'm back to having the two Contacts from the 302 being sent in parallel. Here are the debugs, the same as before I believe:
DBG:uac_redirect:get_redirect: resume branch=0 DBG:uac_redirect:get_redirect: checking branch=0 (added=0) DBG:uac_redirect:get_redirect: branch=0 is a redirect (added=0) DBG:core:parse_headers: flags=7 DBG:core:get_hdr_field: content_length=0 DBG:core:get_hdr_field: found end of header DBG:uac_redirect:sort_contacts: sort_contacts: <sip:[email protected]:5060;user=phone> q=250 DBG:uac_redirect:sort_contacts: sort_contacts: <sip:[email protected]:5060;user=phone> q=500 DBG:uac_redirect:shmcontact2dset: adding contact <sip:[email protected]:5060;user=phone> DBG:uac_redirect:shmcontact2dset: adding contact <sip:[email protected]:5060;user=phone> DBG:core:serialize_branches: loaded <sip:[email protected]:5060;user=phone>, q=250 q_flag <0> DBG:core:serialize_branches: loaded <sip:[email protected]:5060;user=phone>, q=500 q_flag <16> DBG:core:next_branches: branch is <sip:[email protected]:5060;user=phone> The config looks like this: failure_route[4] { # Un-assign dialog profile unset_dlg_profile("outbound", "$avp(s:dlgid_out)"); if (isflagset(18)) exit; # Got a 18x, so route this failure # Check to see if we've got a permanent failure if !(t_check_status("302|403|404|408|500|503|606")) { # Only route advance on these response codes exit; } if (t_check_status("302")) { resetflag(16); # Clear pre-routing setdebug(6); if(!get_redirects("*")) { route(20); # No redirects, junk the call exit; } serialize_branches(1); next_branches(); setdebug(3); setbflag(3); # 302 in progress t_on_failure("4"); t_on_branch("1"); resetflag(1); route(23); # Send request } if (isbflagset(3)) { if (next_branches()) { t_on_failure("4"); resetflag(22); route(23); # Send request (see below) } else { resetbflag(3); # The 302's over setflag(22); # Make sure there's failure accounting route(20); # Done trying, fail the call (t_relay an error) } } # some other stuff that isn¹t used in this 302 case } route[23] { # Route out # Check to see if we're at maximum capacity if !(get_profile_size("outbound", "$avp(s:dlgid_out)", "$var(dlgsize_out)")) { xlog("L_INFO", "Couldn't get dialog size, continuing route-out\n"); } else { # Do some stuff to get to the next PSTN carrier } if (is_avp_set("$avp(s:dlgid_out)")) { set_dlg_profile("outbound", "$avp(s:dlgid_out)"); } else { xlog("L_INFO", "No outbound dialog profile value to assign\n"); } t_on_reply("1"); if !(t_relay("0x05")) { sl_reply_error(); } exit; } - Jeff On 3/31/09 4:35 AM, "Bogdan-Andrei Iancu" <[email protected]> wrote: > Hi Jeff, > > Jeff Pyle wrote: >> Evidently responding publically to my own question is some sort of cheap >> therapy. > any therapy that has results is a good one :) > >> Anyway, I found some old examples of how this is supposed to work, >> and all the examples included a t_on_branch() statement. My config did not. >> I ripped off one of the examples almost character for character and it is >> now behaving as one would expect. Apparently my lack of understanding when >> it comes to branch routes was to blame all along. >> > Can you post the script you got to? Maybe the "misconfiguration" you > found is hiding some bug.... > > Thanks and regards, > Bogdan
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
