[OpenSIPS-Users] serialize_branches/next_branches problem

Jeff Pyle jpyle at fidelityvoice.com
Tue Mar 31 21:20:02 CEST 2009


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090331/b3d8fb1e/attachment.htm 


More information about the Users mailing list