Hello,
Has something changed about default forking behaviour in >= 4.0?
I have a scenario where INVITEs processed by the proxy first hit a redirect server, catch a 302, and then append another branch and iterate over one or more outbound routes.
In the past, this worked fine. After I upgraded to 4.0, I am seeing two branches at a time on the outbound routes, after the initial branch to the redirect server. The desired behaviour is serial forking at all times.
tm:failure_reply_mode is set to 3, as it always has been.
Any ideas would be appreciated; thank you!
-- Alex
Hello,
I don't recall any change in this aspect, are the two branches going to same destination?
Cheers, Daniel
On 5/13/13 2:43 PM, Alex Balashov wrote:
Hello,
Has something changed about default forking behaviour in >= 4.0?
I have a scenario where INVITEs processed by the proxy first hit a redirect server, catch a 302, and then append another branch and iterate over one or more outbound routes.
In the past, this worked fine. After I upgraded to 4.0, I am seeing two branches at a time on the outbound routes, after the initial branch to the redirect server. The desired behaviour is serial forking at all times.
tm:failure_reply_mode is set to 3, as it always has been.
Any ideas would be appreciated; thank you!
-- Alex
Yes, they are identical in every way except for the .1 and .2 branch IDs.
Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
I don't recall any change in this aspect, are the two branches going to
same destination?
Cheers, Daniel
On 5/13/13 2:43 PM, Alex Balashov wrote:
Hello,
Has something changed about default forking behaviour in >= 4.0?
I have a scenario where INVITEs processed by the proxy first hit a redirect server, catch a 302, and then append another branch and iterate over one or more outbound routes.
In the past, this worked fine. After I upgraded to 4.0, I am seeing two branches at a time on the outbound routes, after the initial branch to the redirect server. The desired behaviour is serial forking at all times.
tm:failure_reply_mode is set to 3, as it always has been.
Any ideas would be appreciated; thank you!
-- Alex
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com
Just to understand exactly:
A calls B B redirects to C and is captured by proxy
then from proxy you have two parallel outgoing branches to C?
How you take the address of C and create the branch? uac_redirect or other script functions?
Cheers, Daniel
On 5/13/13 3:26 PM, Alex Balashov wrote:
Yes, they are identical in every way except for the .1 and .2 branch IDs.
Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
I don't recall any change in this aspect, are the two branches going to
same destination?
Cheers, Daniel
On 5/13/13 2:43 PM, Alex Balashov wrote:
Hello,
Has something changed about default forking behaviour in >= 4.0?
I have a scenario where INVITEs processed by the proxy first hit a redirect server, catch a 302, and then append another branch and iterate over one or more outbound routes.
In the past, this worked fine. After I upgraded to 4.0, I am seeing two branches at a time on the outbound routes, after the initial branch to the redirect server. The desired behaviour is serial forking at all times.
tm:failure_reply_mode is set to 3, as it always has been.
Any ideas would be appreciated; thank you!
-- Alex
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com
On 05/13/2013 09:30 AM, Daniel-Constantin Mierla wrote:
Just to understand exactly:
A calls B B redirects to C and is captured by proxy
then from proxy you have two parallel outgoing branches to C?
How you take the address of C and create the branch? uac_redirect or other script functions?
Yes, your understanding of the scenario is correct.
No, I do not use any of the uac_* or contacts functions. I manually catch the 302 in a failure_route, manually parse out the relevant details from the Contact header, rewrite the RURI (prior to append_branch()), append_branch() and t_relay().
On 5/13/13 4:38 PM, Alex Balashov wrote:
On 05/13/2013 09:30 AM, Daniel-Constantin Mierla wrote:
Just to understand exactly:
A calls B B redirects to C and is captured by proxy
then from proxy you have two parallel outgoing branches to C?
How you take the address of C and create the branch? uac_redirect or other script functions?
Yes, your understanding of the scenario is correct.
No, I do not use any of the uac_* or contacts functions. I manually catch the 302 in a failure_route, manually parse out the relevant details from the Contact header, rewrite the RURI (prior to append_branch()), append_branch() and t_relay().
append_branch() is not needed anymore (for couple of releases, actually, being added in one of the 3.x releases), but should be harmless unless you do other changes of r-uri/dst-uri after append_branch(). Can you try without append branch?
Also, can you look at config execution trace to be sure append branch is not called twice somehow?
Cheers, Daniel
On 05/13/2013 10:45 AM, Daniel-Constantin Mierla wrote:
append_branch() is not needed anymore (for couple of releases, actually, being added in one of the 3.x releases), but should be harmless unless you do other changes of r-uri/dst-uri after append_branch(). Can you try without append branch?
Oh. Well, that was news to me. I guess I missed this. So, now when t_relay() is called from failure route it automatically appends a new branch as necessary?
Given this knowledge, I find it likely that branches are being automatically appended by the proxy and then additionally appended manually. I'll look into it from this angle. Thank you!
On 5/13/13 4:47 PM, Alex Balashov wrote:
On 05/13/2013 10:45 AM, Daniel-Constantin Mierla wrote:
append_branch() is not needed anymore (for couple of releases, actually, being added in one of the 3.x releases), but should be harmless unless you do other changes of r-uri/dst-uri after append_branch(). Can you try without append branch?
Oh. Well, that was news to me. I guess I missed this. So, now when t_relay() is called from failure route it automatically appends a new branch as necessary?
Yes, if the r-uri is changed in failure route, a new branch is created by t_relay() without need of using explicitly append_branch().
But again, using append_branch() once before t_relay() there should do nothing (backward compatible behavior). Unless some new code changed that behavior -- iirc, append_branch() was affected by some outbound code.
Cheers, Daniel
Given this knowledge, I find it likely that branches are being automatically appended by the proxy and then additionally appended manually. I'll look into it from this angle. Thank you!
Daniel,
Thank you for your help. FYI, stopping my use of append_branch() everywhere solved the problem. I was unaware that it had become an essentially deprecated requirement.
Thanks again!
-- Alex
On 5/14/13 2:29 AM, Alex Balashov wrote:
Daniel,
Thank you for your help. FYI, stopping my use of append_branch() everywhere solved the problem. I was unaware that it had become an essentially deprecated requirement.
it was deprecated but should have stayed harmless. Do you touch anything related to next hop address after append_branch()?
Cheers, Daniel
-
Alex Balashov -
Daniel-Constantin Mierla