Hi,

Thanks, this was very helpful for understanding.

Still let’s see if i got it right:

I get the INVITE.

Do whatever I do on the main route.

Then do:

“append_branch();”

“changes….changes…..;”

 Now before the t_relay do t_on_branch(name of branch).

Get the reply (301 in my case)

And from here I am back to the original request?

maybe a stupid question now but - I must use the append_branch()  right :-)?

BR,

Uri

 

 

Hi,

On 03/27/2012 04:46 PM, Uri Shacked wrote:
> In my case i need to change the header and then send it.
>
> Here the case works if i make the changes after i sent the invite and
> got the reply. As i know the t_on_branch will work after the invite is

> sent... am i wrong?
>
> There are many questions to ask about the branches... when do they work > in a serial manner, when parallel... where can i find it documented best?

Actually it's quite simple. If a request comes in and you modify it in a
normal route (e.g. calling rtpproxy_offer(), uac_replace_from(), adding
additional headers and stuff like that) and you send it out using e.g.
t_relay(), then in a serial scenario when you re-enter via a
failure-route, these changes will still be there (which is not always
what you want).

On the other hand, if you register a branch route via t_on_branch() and
do your changes there instead of prior to calling t_relay(), then these
changes from branch route will be rolled back, and you can do your
changes easily again in the same or another branch route starting with
your original message. This is important for example in serial call
forward scenarios, where the first destination might require an
rtpproxy, but the second doesn't, or when the first destination requires
different custom headers compare to the second.

Basically the same applies to parallel scenarios. If you modify your
message before calling lookup() and you've multiple contacts registered
for your destination, then your changes will apply for all branches
which are created by that. However if you move your modifications to a
branch route, then you can work on your messages individually, depending
on the branch.

Hope this clarifies it a bit.

Andreas