[OpenSIPS-Users] serialize_branches/next_branches problem

Bogdan-Andrei Iancu bogdan at voice-system.ro
Tue Mar 31 10:35:48 CEST 2009


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
>
> - 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