<HTML>
<HEAD>
<TITLE>Re: [OpenSIPS-Users] serialize_branches/next_branches problem</TITLE>
</HEAD>
<BODY>
<FONT FACE="Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10pt'>Hi Bogdan,<BR>
<BR>
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:<BR>
<BR>
DBG:uac_redirect:get_redirect: resume branch=0 <BR>
DBG:uac_redirect:get_redirect: checking branch=0 (added=0) <BR>
DBG:uac_redirect:get_redirect: branch=0 is a redirect (added=0) <BR>
DBG:core:parse_headers: flags=7 <BR>
DBG:core:get_hdr_field: content_length=0 <BR>
DBG:core:get_hdr_field: found end of header <BR>
DBG:uac_redirect:sort_contacts: sort_contacts: <sip:<a href="+13030000000@ww.xx.119.46:5060">+13030000000@ww.xx.119.46:5060</a>;user=phone> q=250 <BR>
DBG:uac_redirect:sort_contacts: sort_contacts: <sip:<a href="+13030000000@ww.xx.116.46:5060">+13030000000@ww.xx.116.46:5060</a>;user=phone> q=500 <BR>
DBG:uac_redirect:shmcontact2dset: adding contact <sip:<a href="+13030000000@ww.xx.119.46:5060">+13030000000@ww.xx.119.46:5060</a>;user=phone> <BR>
DBG:uac_redirect:shmcontact2dset: adding contact <sip:<a href="+13030000000@ww.xx.116.46:5060">+13030000000@ww.xx.116.46:5060</a>;user=phone> <BR>
DBG:core:serialize_branches: loaded <sip:<a href="+13030000000@ww.xx.119.46:5060">+13030000000@ww.xx.119.46:5060</a>;user=phone>, q=250 q_flag <0> <BR>
DBG:core:serialize_branches: loaded <sip:<a href="+13030000000@ww.xx.116.46:5060">+13030000000@ww.xx.116.46:5060</a>;user=phone>, q=500 q_flag <16> <BR>
DBG:core:next_branches: branch is <sip:<a href="+13030000000@ww.xx.116.46:5060">+13030000000@ww.xx.116.46:5060</a>;user=phone> <BR>
<BR>
<BR>
The config looks like this:<BR>
<BR>
failure_route[4] { <BR>
# Un-assign dialog profile<BR>
unset_dlg_profile("outbound", "$avp(s:dlgid_out)");<BR>
<BR>
if (isflagset(18)) exit; # Got a 18x, so route this failure<BR>
<BR>
# Check to see if we've got a permanent failure<BR>
if !(t_check_status("302|403|404|408|500|503|606")) { # Only route advance on these response codes<BR>
exit;<BR>
}<BR>
<BR>
if (t_check_status("302")) {<BR>
resetflag(16); # Clear pre-routing<BR>
setdebug(6);<BR>
if(!get_redirects("*")) {<BR>
route(20); # No redirects, junk the call<BR>
exit;<BR>
}<BR>
serialize_branches(1);<BR>
next_branches();<BR>
<BR>
setdebug(3); <BR>
<BR>
setbflag(3); # 302 in progress<BR>
t_on_failure("4");<BR>
t_on_branch("1");<BR>
<BR>
resetflag(1);<BR>
route(23); # Send request<BR>
}<BR>
<BR>
if (isbflagset(3)) {<BR>
if (next_branches()) {<BR>
t_on_failure("4");<BR>
resetflag(22);<BR>
route(23); # Send request (see below)<BR>
} else {<BR>
resetbflag(3); # The 302's over<BR>
setflag(22); # Make sure there's failure accounting<BR>
route(20); # Done trying, fail the call (t_relay an error)<BR>
}<BR>
}<BR>
<BR>
# some other stuff that isn’t used in this 302 case<BR>
}<BR>
<BR>
route[23] { # Route out<BR>
<BR>
# Check to see if we're at maximum capacity<BR>
if !(get_profile_size("outbound", "$avp(s:dlgid_out)", "$var(dlgsize_out)")) {<BR>
xlog("L_INFO", "Couldn't get dialog size, continuing route-out\n");<BR>
} else { <BR>
# Do some stuff to get to the next PSTN carrier <BR>
} <BR>
<BR>
if (is_avp_set("$avp(s:dlgid_out)")) {<BR>
set_dlg_profile("outbound", "$avp(s:dlgid_out)");<BR>
} else {<BR>
xlog("L_INFO", "No outbound dialog profile value to assign\n");<BR>
}<BR>
<BR>
t_on_reply("1");<BR>
if !(t_relay("0x05")) {<BR>
sl_reply_error();<BR>
}<BR>
<BR>
exit;<BR>
}<BR>
<BR>
<BR>
- Jeff<BR>
<BR>
<BR>
<BR>
On 3/31/09 4:35 AM, "Bogdan-Andrei Iancu" <<a href="bogdan@voice-system.ro">bogdan@voice-system.ro</a>> wrote:<BR>
<BR>
<FONT COLOR="#0000FF">> Hi Jeff,<BR>
> <BR>
> Jeff Pyle wrote:<BR>
</FONT><FONT COLOR="#008000">>> Evidently responding publically to my own question is some sort of cheap<BR>
>> therapy. <BR>
</FONT><FONT COLOR="#0000FF">> any therapy that has results is a good one :)<BR>
> <BR>
</FONT><FONT COLOR="#008000">>> Anyway, I found some old examples of how this is supposed to work,<BR>
>> and all the examples included a t_on_branch() statement. My config did not.<BR>
>> I ripped off one of the examples almost character for character and it is<BR>
>> now behaving as one would expect. Apparently my lack of understanding when<BR>
>> it comes to branch routes was to blame all along.<BR>
>> <BR>
</FONT><FONT COLOR="#0000FF">> Can you post the script you got to? Maybe the "misconfiguration" you <BR>
> found is hiding some bug....<BR>
> <BR>
> Thanks and regards,<BR>
> Bogdan</FONT></SPAN></FONT>
</BODY>
</HTML>