[sr-dev] append_branch() change

Miklos Tirpak miklos at iptel.org
Thu Sep 30 12:47:25 CEST 2010


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 Tirpak<miklos at 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



More information about the sr-dev mailing list