Hi Jeff, as I suspected, there was something more hiding there....A fix is available on SVN - I guess you already know the procedure - update, test and if still doesn't work, post the logs.
Thanks and regards, Bogdan Jeff Pyle wrote: > 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
