[OpenSIPS-Users] serialize_branches/next_branches problem

Jeff Pyle jpyle at fidelityvoice.com
Tue Mar 31 02:48:24 CEST 2009 

Evidently responding publically to my own question is some sort of cheap
therapy.  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.


- Jeff



On 3/30/09 4:17 PM, "Jeff Pyle" <jpyle at fidelityvoice.com> wrote:

> Bogdan,
> 
> I'm seeing the same behavior in 1.4.5.  There's got to be some misconfig on
> my part, no?
> 
> 
> - Jeff
> 
> 
> 
> On 3/30/09 3:02 PM, "Jeff Pyle" <jpyle at fidelityvoice.com> wrote:
> 
>> Hi Bogdan,
>> 
>> Here it is:
>> 
>> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:get_redirect: resume
>> branch=0 
>> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:get_redirect: checking
>> branch=0 (added=0)
>> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:get_redirect: branch=0 is a
>> redirect (added=0)
>> Mar 30 14:55:58 opensips[16337]: DBG:core:parse_headers: flags=7
>> Mar 30 14:55:58 opensips[16337]: DBG:core:get_hdr_field: content_length=0
>> Mar 30 14:55:58 opensips[16337]: DBG:core:get_hdr_field: found end of header
>> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:sort_contacts:
>> sort_contacts: <sip:+13030000000 at ww.xx.119.46:5060;user=phone> q=250
>> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:sort_contacts:
>> sort_contacts: <sip:+13030000000 at ww.xx.116.46:5060;user=phone> q=500
>> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:shmcontact2dset: adding
>> contact <sip:+13030000000 at ww.xx.119.46:5060;user=phone>
>> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:shmcontact2dset: adding
>> contact <sip:+13030000000 at ww.xx.116.46:5060;user=phone>
>> Mar 30 14:55:58 opensips[16337]: DBG:core:serialize_branches: loaded
>> <sip:+13030000000 at ww.xx.119.46:5060;user=phone>, q=250 q_flag <0>
>> Mar 30 14:55:58 opensips[16337]: DBG:core:serialize_branches: loaded
>> <sip:+13030000000 at ww.xx.116.46:5060;user=phone>, q=500 q_flag <16>
>> Mar 30 14:55:58 opensips[16337]: DBG:core:next_branches: branch is
>> <sip:+13030000000 at ww.xx.116.46:5060;user=phone>
>> 
>> When t_relay¹ing this, parallel invites went out to both the .119.46 and
>> .116.46 hosts.  Same as before.  Same 302 Contact header as well.
>> 
>> Shortly I¹m going to be reverting to 1.4.5 from 1.5.0 because 1.5.0 just
>> ³stops² after many hours of use with no debug info and no core.  I have no
>> idea why, and my attempts to get debug information have failed.
>> Unfortunately
>> it¹s my only option.  As such, I won¹t be able to test this anymore on 1.5.
>> 
>> 
>> - Jeff
>> 
>> 
>> 
>> 
>> On 3/30/09 5:12 AM, "Bogdan-Andrei Iancu" <bogdan at voice-system.ro> wrote:
>> 
>>> Hi Jeff,
>>> 
>>> could you post the debug again? maybe there is something else....
>>> 
>>> Thanks and regards,
>>> Bogdan
>>> 
>>> Jeff Pyle wrote:
>>>> Hi Bogdan,
>>>> 
>>>> I still get the parallel forking to both contacts.
>>>> 
>>>> 
>>>> - Jeff
>>>> 
>>>> 
>>>> 
>>>> On 3/26/09 2:48 PM, "Bogdan-Andrei Iancu" <bogdan at voice-system.ro> wrote:
>>>> 
>>>>   
>>>>> Hi Jeff,
>>>>> 
>>>>> I found a small bug in the uac_redirect() function - I fixed it on 1.5
>>>>> and trunk, so if you upload from svn it should work now.
>>>>> 
>>>>> Thanks and regards,
>>>>> Bogdan
>>>>> 
>>>>> Jeff Pyle wrote:
>>>>>     
>>>>>> Hi Bogdan,
>>>>>> 
>>>>>> Debug level was 6 for get_redirects("*"), serialize_branches(1) and
>>>>>> next_branches(). The contact header from the 302 was as follows:
>>>>>> 
>>>>>> 
> 
Contact:<sip:+13030000000 at ww.xx.116.46:5060;user=phone>;q=0.5,<sip:+130300>>>>>
>
> 0
>>>>>> 00
>>>>>> 00 at ww.xx.119.46:5060;user=phone>;q=0.25
>>>>>> 
>>>>>> Debug output:
>>>>>> 
>>>>>> 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=-1 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 Opensips build is from an SVN checkout of branches/1.5 about 15:00
>>>>>> GMT today.
>>>>>> 
>>>>>> 
>>>>>> - Jeff
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 3/23/09 10:38 AM, "Bogdan-Andrei Iancu" <bogdan at voice-system.ro>
>>>>>> wrote:
>>>>>> 
>>>>>>       
>>>>>>> Hi Jeff,
>>>>>>> 
>>>>>>> please post the debug=6 logs - also be sure you are using the latest
>>>>>>> version as a similar bug was fixed one or two weeks ago.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Bogdan
>>>>>>> 
>>>>>>> Jeff Pyle wrote:
>>>>>>>         
>>>>>>>> Hello,
>>>>>>>> 
>>>>>>>> I catch a 302 in a failure_route that runs: get_redirects(³*²),
>>>>>>>> serialize_branches and next_branches. The subsequent t_relay() causes
>>>>>>>> a parallel fork to both contacts in the 302¹s Contact header.
>>>>>>>> 
>>>>>>>> The 302¹s Contact header looks like this:
>>>>>>>> 
>>>>>>>>           
>>>>>> 
> 
Contact:<sip:+13030000000 at qq.rr.ss.tt:5060;user=phone>;q=0.5,<sip:+1303000>>>>>
>
> 0
>>>>>> 00
>>>>>>       
>>>>>>>> 0 at qq.rr.ww.tt:5060;user=phone>;q=0.25
>>>>>>>> 
>>>>>>>> I would expect it to load only the q=0.5 route at first, no?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> - Jeff
>>>>>>>> 
----------------------------------------------------------------------->>>>>>>>
-
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list
>>>>>>>> Users at lists.opensips.org
>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>> 
>>>>>>>>           
>>>> 
>>>> 
>>>>   
>>> 
>> 
>> 
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

More information about the Users mailing list