[SR-Users] rtpproxy module flags 1 and 2 question

[Klaus Darilion]

Thanks, now I remember again :-)

Please copy the whole description into the rtpproxy README.

Thanks
Klaus

On 22.10.2012 22:46, Andreas Granig wrote:
> Hi,
>
> On 10/22/2012 07:04 PM, Klaus Darilion wrote:
>> Please ask Andreas about those flags - he commited it
>
> It's actually about serial hunting e.g. on ring-timeout (maybe the term
> "forking" is ambiguous).
>
> Consider this scenario:
>
> A sends INVITE to proxy, which calls rtpproxy_offer to create a new
> session in rtpproxy. You set fr_inv_timer to 5sec, then the INVITE is
> sent to B, which replies with 100/180. Let's call this "branch B".
>
> After 5sec, tm triggers an internal timeout, and in a failure route you
> set the R-RUI to C, call append_branch and spiral the INVITE to the same
> proxy again, which goes through call routing again, calls rtpproxy_offer
> again and forwards it to C. Let's call this one "branch C".
>
> In the meanwhile, the proxy sent a CANCEL for "branch B", so you'll get
> a 487 back from B, where you call rtpproxy_destroy in your failure route
> to tear down this branch. In "normal" operation mode, this will delete
> the full session in rtpproxy (both B and C), because both are identified
> with the same call-id and from-tag.
>
> And after that, you get at some point a 200 back from C, where you call
> rtpproxy_answer. In this lookup, rtpproxy won't find the call anymore,
> because it got deleted by the rtpproxy_destroy triggered by the 487 from B.
>
> The order of the 200 for "branch C" and the 487 for "branch B" doesn't
> really matter. The 487 before the 200 will result in an error when
> rtpproxy_answer is called, because the session is gone on the rtpproxy
> already. The 487 after the 200 will just successfully delete the session
> on the rtpproxy, cutting the already established audio.
>
> And this is the reason why we pass the Via branch to the rtpproxy in the
> offer, answer and destory when we're spiraling a call multiple times
> over the proxy, in order to be able to only delete a specific branch
> instead of the whole session in case a branch fails.
>
> The usual configuration is to set "1" for a request when calling
> rtpproxy_offer and "2" in a response when calling rtpproxy_answer.
> For rtpproxy_destory you either set nothing when called from a request
> (e.g. on CANCEL from caller or BYE) to tear down all branches, or "1"
> when called from failure route (e.g. on negative response from callee)
> or "2" when called from reply route (if you don't arm a failure route
> for some reason).
>
> Hope this clarifies it.
>
> Andreas
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>