Hi Andrei,
I just tested the patch both with and without calling append_branch(), and it worked. I also tried two additional scenarios which were a bit more complicated, both of them worked as expected:
a) serial forking with 3 branches: 1. request route: t_relay() 2. failure_route1: rewrite URI, append_branch(), t_realy() 3. failure_route2: rewrite URI, append_branch(), t_realy()
b) serial forking + parallel forking from failure route 1. request route: t_relay() 2. failure_route: rewrite URI, append_branch(), rewrite URI, append_branch(), t_relay()
Thanks, Miklos
On 09/30/2010 12:19 PM, Andrei Pelinescu-Onciul wrote:
On Sep 30, 2010 at 12:05, Miklos Tirpakmiklos@iptel.org wrote:
hi,
I was recently fighting with a serial forking issue, and figured out that t_relay() automatically appends a new branch when the RURI has been changed. This means to me that the config below becomes incorrect:
failure_route["abcd"] { ... rewritehostport("127.0.0.1:5062"); append_branch(); t_relay(); }
I saw two branches created with the same RURI and sent to the same destination in parallel.
As far as I got it append_branch() should not be called any more in failure route unless parallel forking is desired. This is great, the only issue is that this is not mentioned in the documentation, the tm readme file still contains the old examples, and all the configurations under etc/ still call append_branch(). Is there any plan to update the docs and configs before releasing the new sip-router version?
There is a plan to try to avoid this situation by making append_branch() not have any effect in the above case.
I even have a patch (attached) for it (Daniel discovered the same problem as you), but so far I did not have any time to test it.
Nevertheless we should update the docs, migration document and the configs.
Andrei