Hi, you need the "append_branch" only, if you modify the request URI in your config (e.g. by doing a lookup()) and you want to have another branch (e.g. parallel forking to voicebox).
Carsten 2012/3/28 Uri Shacked <ushac...@gmail.com>: > OK... > It worked great... and, no append_branch() was needed... only t_on_branch > with the main branch route. > When will i need to use the append_branch? > BR, > Uri > > On Wed, Mar 28, 2012 at 4:00 PM, Uri Shacked <ushac...@gmail.com> wrote: >> >> 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 >> > > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > -- Carsten Bock CEO (Geschäftsführer) ng-voice GmbH Schomburgstr. 80 D-22767 Hamburg / Germany http://www.ng-voice.com mailto:cars...@ng-voice.com Mobile +49 179 2021244 Office +49 40 34927219 Fax +49 40 34927220 Sitz der Gesellschaft: Hamburg Registergericht: Amtsgericht Hamburg, HRB 120189 Geschäftsführer: Carsten Bock Ust-ID: DE279344284 Hier finden Sie unsere handelsrechtlichen Pflichtangaben: http://www.ng-voice.com/imprint/ -- Meet ng-voice at LinuxTag 2012 in Berlin - May 23rd - 26th, 2012. Save the date! _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
