Re: [OpenSIPS-Users] serialize_branches/next_branches problem
Hi Bogdan,
Works perfectly now. Thanks.
- Jeff
On 4/6/09 9:41 AM, "Bogdan-Andrei Iancu" wrote:
> Hi Jeff,
>
> as I suspected, there was something more hiding thereA 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:
>> q=250
>> DBG:uac_redirect:sort_contacts: sort_contacts:
>> q=500
>> DBG:uac_redirect:shmcontact2dset: adding contact
>>
>> DBG:uac_redirect:shmcontact2dset: adding contact
>>
>> DBG:core:serialize_branches: loaded
>> , q=250 q_flag <0>
>> DBG:core:serialize_branches: loaded
>> , q=500 q_flag <16>
>> DBG:core:next_branches: branch is
>>
>>
>>
>> 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" 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
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] serialize_branches/next_branches problem
Hi Jeff,
as I suspected, there was something more hiding thereA 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:
> q=250
> DBG:uac_redirect:sort_contacts: sort_contacts:
> q=500
> DBG:uac_redirect:shmcontact2dset: adding contact
>
> DBG:uac_redirect:shmcontact2dset: adding contact
>
> DBG:core:serialize_branches: loaded
> , q=250 q_flag <0>
> DBG:core:serialize_branches: loaded
> , q=500 q_flag <16>
> DBG:core:next_branches: branch is
>
>
>
> 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" 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
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
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:
q=250
DBG:uac_redirect:sort_contacts: sort_contacts:
q=500
DBG:uac_redirect:shmcontact2dset: adding contact
DBG:uac_redirect:shmcontact2dset: adding contact
DBG:core:serialize_branches: loaded
, q=250 q_flag <0>
DBG:core:serialize_branches: loaded
, q=500 q_flag <16>
DBG:core:next_branches: branch is
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" 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
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] serialize_branches/next_branches problem
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" 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" 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: q=250
>>> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:sort_contacts:
>>> sort_contacts: q=500
>>> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:shmcontact2dset: adding
>>> contact
>>> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:shmcontact2dset: adding
>>> contact
>>> Mar 30 14:55:58 opensips[16337]: DBG:core:serialize_branches: loaded
>>> , q=250 q_flag <0>
>>> Mar 30 14:55:58 opensips[16337]: DBG:core:serialize_branches: loaded
>>> , q=500 q_flag <16>
>>> Mar 30 14:55:58 opensips[16337]: DBG:core:next_branches: branch is
>>>
>>>
>>> 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" 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" 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:;q=0.5,
>
>> 0
>>
>>> 00
>>> 0...@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:
>>> q=250
>>> DBG:uac_redirect:sort_contacts: sort_contacts:
>>> q=500
>>> DBG:uac_redirect:shmcontact2dset: adding contact
>>>
>>> DBG:uac_redirect:shmcontact2dset: adding contact
>>>
>>> DBG:core:serialize_branches: loaded
>>> , q=-1 q_flag <0>
>>> DBG:core:serialize_branches: loaded
>>> , q=500 q_flag <16>
>>> DBG:core:next_branches: branch is
>>>
>>>
>>> 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"
>>> 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
Re: [OpenSIPS-Users] serialize_branches/next_branches problem
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" 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" 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: q=250
>> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:sort_contacts:
>> sort_contacts: q=500
>> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:shmcontact2dset: adding
>> contact
>> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:shmcontact2dset: adding
>> contact
>> Mar 30 14:55:58 opensips[16337]: DBG:core:serialize_branches: loaded
>> , q=250 q_flag <0>
>> Mar 30 14:55:58 opensips[16337]: DBG:core:serialize_branches: loaded
>> , q=500 q_flag <16>
>> Mar 30 14:55:58 opensips[16337]: DBG:core:next_branches: branch is
>>
>>
>> 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" 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" 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:;q=0.5,
>
> 0
>> 00
>> 0...@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:
>> q=250
>> DBG:uac_redirect:sort_contacts: sort_contacts:
>> q=500
>> DBG:uac_redirect:shmcontact2dset: adding contact
>>
>> DBG:uac_redirect:shmcontact2dset: adding contact
>>
>> DBG:core:serialize_branches: loaded
>> , q=-1 q_flag <0>
>> DBG:core:serialize_branches: loaded
>> , q=500 q_flag <16>
>> DBG:core:next_branches: branch is
>>
>>
>> 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"
>> 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:;q=0.5,
>
> 0
>> 00
>>
>>
Re: [OpenSIPS-Users] serialize_branches/next_branches problem
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" 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: q=250
> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:sort_contacts:
> sort_contacts: q=500
> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:shmcontact2dset: adding
> contact
> Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:shmcontact2dset: adding
> contact
> Mar 30 14:55:58 opensips[16337]: DBG:core:serialize_branches: loaded
> , q=250 q_flag <0>
> Mar 30 14:55:58 opensips[16337]: DBG:core:serialize_branches: loaded
> , q=500 q_flag <16>
> Mar 30 14:55:58 opensips[16337]: DBG:core:next_branches: branch is
>
>
> 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" 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" 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:;q=0.5,
0
> 00
> 0...@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:
> q=250
> DBG:uac_redirect:sort_contacts: sort_contacts:
> q=500
> DBG:uac_redirect:shmcontact2dset: adding contact
>
> DBG:uac_redirect:shmcontact2dset: adding contact
>
> DBG:core:serialize_branches: loaded
> , q=-1 q_flag <0>
> DBG:core:serialize_branches: loaded
> , q=500 q_flag <16>
> DBG:core:next_branches: branch is
>
>
> 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" 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:;q=0.5,
0
> 00
>
>>> 0...@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@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>>
>>>
>>
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
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: q=250
Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:sort_contacts:
sort_contacts: q=500
Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:shmcontact2dset: adding
contact
Mar 30 14:55:58 opensips[16337]: DBG:uac_redirect:shmcontact2dset: adding
contact
Mar 30 14:55:58 opensips[16337]: DBG:core:serialize_branches: loaded
, q=250 q_flag <0>
Mar 30 14:55:58 opensips[16337]: DBG:core:serialize_branches: loaded
, q=500 q_flag <16>
Mar 30 14:55:58 opensips[16337]: DBG:core:next_branches: branch is
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" 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" 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:;q=0.5,>>> 00
0...@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:
q=250
DBG:uac_redirect:sort_contacts: sort_contacts:
q=500
DBG:uac_redirect:shmcontact2dset: adding contact
DBG:uac_redirect:shmcontact2dset: adding contact
DBG:core:serialize_branches: loaded
, q=-1 q_flag <0>
DBG:core:serialize_branches: loaded
, q=500 q_flag <16>
DBG:core:next_branches: branch is
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" 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:;q=0.5,>>> 00
>> 0...@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@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] serialize_branches/next_branches problem
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" 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:;q=0.5,>> 0...@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:
>>> q=250
>>> DBG:uac_redirect:sort_contacts: sort_contacts:
>>> q=500
>>> DBG:uac_redirect:shmcontact2dset: adding contact
>>>
>>> DBG:uac_redirect:shmcontact2dset: adding contact
>>>
>>> DBG:core:serialize_branches: loaded
>>> , q=-1 q_flag <0>
>>> DBG:core:serialize_branches: loaded
>>> , q=500 q_flag <16>
>>> DBG:core:next_branches: branch is
>>>
>>>
>>> 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" 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:;q=0.5,>>
> 0...@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@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] serialize_branches/next_branches problem
Hi Bogdan,
I still get the parallel forking to both contacts.
- Jeff
On 3/26/09 2:48 PM, "Bogdan-Andrei Iancu" 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:;q=0.5,> 0...@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:
>> q=250
>> DBG:uac_redirect:sort_contacts: sort_contacts:
>> q=500
>> DBG:uac_redirect:shmcontact2dset: adding contact
>>
>> DBG:uac_redirect:shmcontact2dset: adding contact
>>
>> DBG:core:serialize_branches: loaded
>> , q=-1 q_flag <0>
>> DBG:core:serialize_branches: loaded
>> , q=500 q_flag <16>
>> DBG:core:next_branches: branch is
>>
>>
>> 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" 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:;q=0.5,>>> 0...@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@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] serialize_branches/next_branches problem
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:;q=0.5,;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:
> q=250
> DBG:uac_redirect:sort_contacts: sort_contacts:
> q=500
> DBG:uac_redirect:shmcontact2dset: adding contact
>
> DBG:uac_redirect:shmcontact2dset: adding contact
>
> DBG:core:serialize_branches: loaded
> , q=-1 q_flag <0>
> DBG:core:serialize_branches: loaded
> , q=500 q_flag <16>
> DBG:core:next_branches: branch is
>
>
> 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" 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:;q=0.5, >> 0...@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@lists.opensips.org
> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >>
> >
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
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:;q=0.5,;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:
q=250
DBG:uac_redirect:sort_contacts: sort_contacts:
q=500
DBG:uac_redirect:shmcontact2dset: adding contact
DBG:uac_redirect:shmcontact2dset: adding contact
DBG:core:serialize_branches: loaded
, q=-1 q_flag <0>
DBG:core:serialize_branches: loaded
, q=500 q_flag <16>
DBG:core:next_branches: branch is
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" 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:;q=0.5,> 0...@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@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] serialize_branches/next_branches problem
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:;q=0.5,;q=0.25 > > I would expect it to load only the q=0.5 route at first, no? > > > - Jeff > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] 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:;q=0.5,;q=0.25 I would expect it to load only the q=0.5 route at first, no? - Jeff ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
