serialize_branches/next_branches problem

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

serialize_branches/next_branches problem

Jeff Pyle
serialize_branches/next_branches problem 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@...:5060;user=phone>;q=0.5,<sip:+13030000000@...: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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: serialize_branches/next_branches problem

Bogdan-Andrei Iancu
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:+[hidden email]:5060;user=phone>;q=0.5,<sip:+[hidden email]: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
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: serialize_branches/next_branches problem

Jeff Pyle
Re: [OpenSIPS-Users] serialize_branches/next_branches problem 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@....116.46:5060;user=phone>;q=0.5,<sip:+13030000000@....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@....119.46:5060;user=phone> q=250
DBG:uac_redirect:sort_contacts: sort_contacts: <sip:+13030000000@....116.46:5060;user=phone> q=500
DBG:uac_redirect:shmcontact2dset: adding contact <sip:+13030000000@....119.46:5060;user=phone>
DBG:uac_redirect:shmcontact2dset: adding contact <sip:+13030000000@....116.46:5060;user=phone>
DBG:core:serialize_branches: loaded <sip:+13030000000@....119.46:5060;user=phone>, q=-1 q_flag <0>
DBG:core:serialize_branches: loaded <sip:+13030000000@....116.46:5060;user=phone>, q=500 q_flag <16>
DBG:core:next_branches: branch is <sip:+13030000000@....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@...> 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@...:5060;user=phone>;q=0.5,<sip:+1303000000
>> 0@...: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@...
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>   
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: serialize_branches/next_branches problem

Bogdan-Andrei Iancu
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:+[hidden email].116.46:5060;user=phone>;q=0.5,<sip:+[hidden email].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:+[hidden email].119.46:5060;user=phone> q=250
> DBG:uac_redirect:sort_contacts: sort_contacts:
> <sip:+[hidden email].116.46:5060;user=phone> q=500
> DBG:uac_redirect:shmcontact2dset: adding contact
> <sip:+[hidden email].119.46:5060;user=phone>
> DBG:uac_redirect:shmcontact2dset: adding contact
> <sip:+[hidden email].116.46:5060;user=phone>
> DBG:core:serialize_branches: loaded
> <sip:+[hidden email].119.46:5060;user=phone>, q=-1 q_flag <0>
> DBG:core:serialize_branches: loaded
> <sip:+[hidden email].116.46:5060;user=phone>, q=500 q_flag <16>
> DBG:core:next_branches: branch is
> <sip:+[hidden email].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" <[hidden email]> 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:+[hidden email]:5060;user=phone>;q=0.5,<sip:+1303000000
> >> [hidden email]: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
> >> [hidden email]
> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >>
> >


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: serialize_branches/next_branches problem

Jeff Pyle
Hi Bogdan,

I still get the parallel forking to both contacts.


- Jeff



On 3/26/09 2:48 PM, "Bogdan-Andrei Iancu" <[hidden email]> 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:+[hidden email].116.46:5060;user=phone>;q=0.5,<sip:+130300000
>> [hidden email].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:+[hidden email].119.46:5060;user=phone> q=250
>> DBG:uac_redirect:sort_contacts: sort_contacts:
>> <sip:+[hidden email].116.46:5060;user=phone> q=500
>> DBG:uac_redirect:shmcontact2dset: adding contact
>> <sip:+[hidden email].119.46:5060;user=phone>
>> DBG:uac_redirect:shmcontact2dset: adding contact
>> <sip:+[hidden email].116.46:5060;user=phone>
>> DBG:core:serialize_branches: loaded
>> <sip:+[hidden email].119.46:5060;user=phone>, q=-1 q_flag <0>
>> DBG:core:serialize_branches: loaded
>> <sip:+[hidden email].116.46:5060;user=phone>, q=500 q_flag <16>
>> DBG:core:next_branches: branch is
>> <sip:+[hidden email].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" <[hidden email]> 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:+[hidden email]:5060;user=phone>;q=0.5,<sip:+1303000000
>>>> [hidden email]: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
>>>> [hidden email]
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>
>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: serialize_branches/next_branches problem

Bogdan-Andrei Iancu
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" <[hidden email]> 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:+[hidden email].116.46:5060;user=phone>;q=0.5,<sip:+130300000
>>> [hidden email].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:+[hidden email].119.46:5060;user=phone> q=250
>>> DBG:uac_redirect:sort_contacts: sort_contacts:
>>> <sip:+[hidden email].116.46:5060;user=phone> q=500
>>> DBG:uac_redirect:shmcontact2dset: adding contact
>>> <sip:+[hidden email].119.46:5060;user=phone>
>>> DBG:uac_redirect:shmcontact2dset: adding contact
>>> <sip:+[hidden email].116.46:5060;user=phone>
>>> DBG:core:serialize_branches: loaded
>>> <sip:+[hidden email].119.46:5060;user=phone>, q=-1 q_flag <0>
>>> DBG:core:serialize_branches: loaded
>>> <sip:+[hidden email].116.46:5060;user=phone>, q=500 q_flag <16>
>>> DBG:core:next_branches: branch is
>>> <sip:+[hidden email].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" <[hidden email]> 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:+[hidden email]:5060;user=phone>;q=0.5,<sip:+1303000000
>>>      
>>>>> [hidden email]: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
>>>>> [hidden email]
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>>          
>
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: serialize_branches/next_branches problem

Jeff Pyle
Re: [OpenSIPS-Users] serialize_branches/next_branches problem 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@....119.46:5060;user=phone> q=250
Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:sort_contacts: sort_contacts: <sip:+13030000000@....116.46:5060;user=phone> q=500
Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:shmcontact2dset: adding contact <sip:+13030000000@....119.46:5060;user=phone>
Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:shmcontact2dset: adding contact <sip:+13030000000@....116.46:5060;user=phone>
Mar 30 14:55:58 opensips[16337]: DBG:core:serialize_branches: loaded <sip:+13030000000@....119.46:5060;user=phone>, q=250 q_flag <0>
Mar 30 14:55:58 opensips[16337]: DBG:core:serialize_branches: loaded <sip:+13030000000@....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@....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@...> 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@...> 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@....116.46:5060;user=phone>;q=0.5,<sip:+1303000
>>>> 00
>>>> 00@....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@....119.46:5060;user=phone> q=250
>>>> DBG:uac_redirect:sort_contacts: sort_contacts:
>>>> <sip:+13030000000@....116.46:5060;user=phone> q=500
>>>> DBG:uac_redirect:shmcontact2dset: adding contact
>>>> <sip:+13030000000@....119.46:5060;user=phone>
>>>> DBG:uac_redirect:shmcontact2dset: adding contact
>>>> <sip:+13030000000@....116.46:5060;user=phone>
>>>> DBG:core:serialize_branches: loaded
>>>> <sip:+13030000000@....119.46:5060;user=phone>, q=-1 q_flag <0>
>>>> DBG:core:serialize_branches: loaded
>>>> <sip:+13030000000@....116.46:5060;user=phone>, q=500 q_flag <16>
>>>> DBG:core:next_branches: branch is
>>>> <sip:+13030000000@....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@...> 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@...:5060;user=phone>;q=0.5,<sip:+13030000
>>>> 00
>>>>       
>>>>>> 0@...: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@...
>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>>>           
>>
>>
>>   
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: serialize_branches/next_branches problem

Jeff Pyle
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" <[hidden email]> 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:+[hidden email].119.46:5060;user=phone> q=250
> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:sort_contacts:
> sort_contacts: <sip:+[hidden email].116.46:5060;user=phone> q=500
> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:shmcontact2dset: adding
> contact <sip:+[hidden email].119.46:5060;user=phone>
> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:shmcontact2dset: adding
> contact <sip:+[hidden email].116.46:5060;user=phone>
> Mar 30 14:55:58 opensips[16337]: DBG:core:serialize_branches: loaded
> <sip:+[hidden email].119.46:5060;user=phone>, q=250 q_flag <0>
> Mar 30 14:55:58 opensips[16337]: DBG:core:serialize_branches: loaded
> <sip:+[hidden email].116.46:5060;user=phone>, q=500 q_flag <16>
> Mar 30 14:55:58 opensips[16337]: DBG:core:next_branches: branch is
> <sip:+[hidden email].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" <[hidden email]> 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" <[hidden email]> 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:+[hidden email].116.46:5060;user=phone>;q=0.5,<sip:+130300>>>>>
0

>>>>> 00
>>>>> [hidden email].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:+[hidden email].119.46:5060;user=phone> q=250
>>>>> DBG:uac_redirect:sort_contacts: sort_contacts:
>>>>> <sip:+[hidden email].116.46:5060;user=phone> q=500
>>>>> DBG:uac_redirect:shmcontact2dset: adding contact
>>>>> <sip:+[hidden email].119.46:5060;user=phone>
>>>>> DBG:uac_redirect:shmcontact2dset: adding contact
>>>>> <sip:+[hidden email].116.46:5060;user=phone>
>>>>> DBG:core:serialize_branches: loaded
>>>>> <sip:+[hidden email].119.46:5060;user=phone>, q=-1 q_flag <0>
>>>>> DBG:core:serialize_branches: loaded
>>>>> <sip:+[hidden email].116.46:5060;user=phone>, q=500 q_flag <16>
>>>>> DBG:core:next_branches: branch is
>>>>> <sip:+[hidden email].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" <[hidden email]> 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:+[hidden email]:5060;user=phone>;q=0.5,<sip:+1303000>>>>>
0

>>>>> 00
>>>>>      
>>>>>>> [hidden email]: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
>>>>>>> [hidden email]
>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>
>>>>>>>          
>>>
>>>
>>>  
>>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: serialize_branches/next_branches problem

Jeff Pyle
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" <[hidden email]> 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" <[hidden email]> 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:+[hidden email].119.46:5060;user=phone> q=250
>> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:sort_contacts:
>> sort_contacts: <sip:+[hidden email].116.46:5060;user=phone> q=500
>> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:shmcontact2dset: adding
>> contact <sip:+[hidden email].119.46:5060;user=phone>
>> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:shmcontact2dset: adding
>> contact <sip:+[hidden email].116.46:5060;user=phone>
>> Mar 30 14:55:58 opensips[16337]: DBG:core:serialize_branches: loaded
>> <sip:+[hidden email].119.46:5060;user=phone>, q=250 q_flag <0>
>> Mar 30 14:55:58 opensips[16337]: DBG:core:serialize_branches: loaded
>> <sip:+[hidden email].116.46:5060;user=phone>, q=500 q_flag <16>
>> Mar 30 14:55:58 opensips[16337]: DBG:core:next_branches: branch is
>> <sip:+[hidden email].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" <[hidden email]> 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" <[hidden email]> 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:+[hidden email].116.46:5060;user=phone>;q=0.5,<sip:+130300>>>>>

>
> 0
>>>>>> 00
>>>>>> [hidden email].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:+[hidden email].119.46:5060;user=phone> q=250
>>>>>> DBG:uac_redirect:sort_contacts: sort_contacts:
>>>>>> <sip:+[hidden email].116.46:5060;user=phone> q=500
>>>>>> DBG:uac_redirect:shmcontact2dset: adding contact
>>>>>> <sip:+[hidden email].119.46:5060;user=phone>
>>>>>> DBG:uac_redirect:shmcontact2dset: adding contact
>>>>>> <sip:+[hidden email].116.46:5060;user=phone>
>>>>>> DBG:core:serialize_branches: loaded
>>>>>> <sip:+[hidden email].119.46:5060;user=phone>, q=-1 q_flag <0>
>>>>>> DBG:core:serialize_branches: loaded
>>>>>> <sip:+[hidden email].116.46:5060;user=phone>, q=500 q_flag <16>
>>>>>> DBG:core:next_branches: branch is
>>>>>> <sip:+[hidden email].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" <[hidden email]>
>>>>>> 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:+[hidden email]:5060;user=phone>;q=0.5,<sip:+1303000>>>>>

>
> 0
>>>>>> 00
>>>>>>      
>>>>>>>> [hidden email]: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
>>>>>>>> [hidden email]
>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>>
>>>>>>>>          
>>>>
>>>>
>>>>  
>>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: serialize_branches/next_branches problem

Bogdan-Andrei Iancu
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" <[hidden email]> 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" <[hidden email]> 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:+[hidden email].119.46:5060;user=phone> q=250
>>> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:sort_contacts:
>>> sort_contacts: <sip:+[hidden email].116.46:5060;user=phone> q=500
>>> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:shmcontact2dset: adding
>>> contact <sip:+[hidden email].119.46:5060;user=phone>
>>> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:shmcontact2dset: adding
>>> contact <sip:+[hidden email].116.46:5060;user=phone>
>>> Mar 30 14:55:58 opensips[16337]: DBG:core:serialize_branches: loaded
>>> <sip:+[hidden email].119.46:5060;user=phone>, q=250 q_flag <0>
>>> Mar 30 14:55:58 opensips[16337]: DBG:core:serialize_branches: loaded
>>> <sip:+[hidden email].116.46:5060;user=phone>, q=500 q_flag <16>
>>> Mar 30 14:55:58 opensips[16337]: DBG:core:next_branches: branch is
>>> <sip:+[hidden email].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" <[hidden email]> 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" <[hidden email]> 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:+[hidden email].116.46:5060;user=phone>;q=0.5,<sip:+130300>>>>>
>  
>> 0
>>    
>>>>>>> 00
>>>>>>> [hidden email].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:+[hidden email].119.46:5060;user=phone> q=250
>>>>>>> DBG:uac_redirect:sort_contacts: sort_contacts:
>>>>>>> <sip:+[hidden email].116.46:5060;user=phone> q=500
>>>>>>> DBG:uac_redirect:shmcontact2dset: adding contact
>>>>>>> <sip:+[hidden email].119.46:5060;user=phone>
>>>>>>> DBG:uac_redirect:shmcontact2dset: adding contact
>>>>>>> <sip:+[hidden email].116.46:5060;user=phone>
>>>>>>> DBG:core:serialize_branches: loaded
>>>>>>> <sip:+[hidden email].119.46:5060;user=phone>, q=-1 q_flag <0>
>>>>>>> DBG:core:serialize_branches: loaded
>>>>>>> <sip:+[hidden email].116.46:5060;user=phone>, q=500 q_flag <16>
>>>>>>> DBG:core:next_branches: branch is
>>>>>>> <sip:+[hidden email].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" <[hidden email]>
>>>>>>> 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:+[hidden email]:5060;user=phone>;q=0.5,<sip:+1303000>>>>>
>  
>> 0
>>    
>>>>>>> 00
>>>>>>>      
>>>>>>>              
>>>>>>>>> [hidden email]: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
>>>>>>>>> [hidden email]
>>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>>>
>>>>>>>>>          
>>>>>>>>>                  
>>>>>  
>>>>>          
>>> _______________________________________________
>>> Users mailing list
>>> [hidden email]
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>      
>
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: serialize_branches/next_branches problem

Jeff Pyle
Re: [OpenSIPS-Users] serialize_branches/next_branches problem 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@....119.46:5060;user=phone> q=250
DBG:uac_redirect:sort_contacts: sort_contacts: <sip:+13030000000@....116.46:5060;user=phone> q=500
DBG:uac_redirect:shmcontact2dset: adding contact <sip:+13030000000@....119.46:5060;user=phone>
DBG:uac_redirect:shmcontact2dset: adding contact <sip:+13030000000@....116.46:5060;user=phone>
DBG:core:serialize_branches: loaded <sip:+13030000000@....119.46:5060;user=phone>, q=250 q_flag <0>
DBG:core:serialize_branches: loaded <sip:+13030000000@....116.46:5060;user=phone>, q=500 q_flag <16>
DBG:core:next_branches: branch is <sip:+13030000000@....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@...> 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

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: serialize_branches/next_branches problem

Bogdan-Andrei Iancu
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:+[hidden email].119.46:5060;user=phone> q=250
> DBG:uac_redirect:sort_contacts: sort_contacts:
> <sip:+[hidden email].116.46:5060;user=phone> q=500
> DBG:uac_redirect:shmcontact2dset: adding contact
> <sip:+[hidden email].119.46:5060;user=phone>
> DBG:uac_redirect:shmcontact2dset: adding contact
> <sip:+[hidden email].116.46:5060;user=phone>
> DBG:core:serialize_branches: loaded
> <sip:+[hidden email].119.46:5060;user=phone>, q=250 q_flag <0>
> DBG:core:serialize_branches: loaded
> <sip:+[hidden email].116.46:5060;user=phone>, q=500 q_flag <16>
> DBG:core:next_branches: branch is
> <sip:+[hidden email].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" <[hidden email]> 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


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: serialize_branches/next_branches problem

Jeff Pyle
Hi Bogdan,

Works perfectly now.  Thanks.


- Jeff



On 4/6/09 9:41 AM, "Bogdan-Andrei Iancu" <[hidden email]> 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:+[hidden email].119.46:5060;user=phone> q=250
>> DBG:uac_redirect:sort_contacts: sort_contacts:
>> <sip:+[hidden email].116.46:5060;user=phone> q=500
>> DBG:uac_redirect:shmcontact2dset: adding contact
>> <sip:+[hidden email].119.46:5060;user=phone>
>> DBG:uac_redirect:shmcontact2dset: adding contact
>> <sip:+[hidden email].116.46:5060;user=phone>
>> DBG:core:serialize_branches: loaded
>> <sip:+[hidden email].119.46:5060;user=phone>, q=250 q_flag <0>
>> DBG:core:serialize_branches: loaded
>> <sip:+[hidden email].116.46:5060;user=phone>, q=500 q_flag <16>
>> DBG:core:next_branches: branch is
>> <sip:+[hidden email].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" <[hidden email]> 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
>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users