[OpenSIPS-Users] serialize_branches/next_branches problem

[Jeff Pyle]

Hi Bogdan,

Works perfectly now.  Thanks.


- Jeff



On 4/6/09 9:41 AM, "Bogdan-Andrei Iancu" <bogdan at voice-system.ro> wrote:

> 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:+13030000000 at ww.xx.119.46:5060;user=phone> q=250
>> DBG:uac_redirect:sort_contacts: sort_contacts:
>> <sip:+13030000000 at ww.xx.116.46:5060;user=phone> q=500
>> DBG:uac_redirect:shmcontact2dset: adding contact
>> <sip:+13030000000 at ww.xx.119.46:5060;user=phone>
>> DBG:uac_redirect:shmcontact2dset: adding contact
>> <sip:+13030000000 at ww.xx.116.46:5060;user=phone>
>> DBG:core:serialize_branches: loaded
>> <sip:+13030000000 at ww.xx.119.46:5060;user=phone>, q=250 q_flag <0>
>> DBG:core:serialize_branches: loaded
>> <sip:+13030000000 at ww.xx.116.46:5060;user=phone>, q=500 q_flag <16>
>> DBG:core:next_branches: branch is
>> <sip:+13030000000 at ww.xx.116.46: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" <bogdan at voice-system.ro> 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 
>