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

Andreas Granig agranig at sipwise.com
Mon Oct 22 22:46:04 CEST 2012


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20121022/b3e02a4e/attachment.pgp>


More information about the sr-users mailing list