17 Oct
2012
17 Oct
'12
7:47 p.m.
i'm new to rtpproxy (have been using mediaproxy for years) and now try
to understand if it would make sense to switch over. rtpproxy readme
has this on flags value 1:
+ 1 - append first Via branch to Call-ID when sending command to
rtpproxy.
...
This is especially useful if you have serially forked call
scenarios where rtpproxy gets an "update" command for a new
branch, and then a "delete" command for the previous branch,
which would otherwise delete the full call, breaking the
subsequent "lookup" for the new branch.
how it would be possible in SERIAL forked scenario to get anything for a
new branch before previous branch has first failed and gone?
-- juha
17 Oct
17 Oct
8:10 p.m.
Hi Juha!
Maybe the description is bad/wrong, but the details are described in
this thread:
http://lists.sip-router.org/pipermail/sr-users/2012-February/071943.html
regards
Klaus
On 17.10.2012 18:47, Juha Heinanen wrote:
i'm new to rtpproxy (have been using mediaproxy
for years) and now try
to understand if it would make sense to switch over. rtpproxy readme
has this on flags value 1:
+ 1 - append first Via branch to Call-ID when sending command to
rtpproxy.
...
This is especially useful if you have serially forked call
scenarios where rtpproxy gets an "update" command for a new
branch, and then a "delete" command for the previous branch,
which would otherwise delete the full call, breaking the
subsequent "lookup" for the new branch.
how it would be possible in SERIAL forked scenario to get anything for a
new branch before previous branch has first failed and gone?
-- juha
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
8:23 p.m.
That's a very unclear/ambiguous description for those flags ...
-ovidiu
On Wed, Oct 17, 2012 at 1:10 PM, Klaus Darilion
<klaus.mailinglists(a)pernau.at> wrote:
Hi Juha!
Maybe the description is bad/wrong, but the details are described in this
thread:
http://lists.sip-router.org/pipermail/sr-users/2012-February/071943.html
regards
Klaus
On 17.10.2012 18:47, Juha Heinanen wrote:
>
> i'm new to rtpproxy (have been using mediaproxy for years) and now try
> to understand if it would make sense to switch over. rtpproxy readme
> has this on flags value 1:
>
> + 1 - append first Via branch to Call-ID when sending command to
> rtpproxy.
> ...
> This is especially useful if you have serially forked call
> scenarios where rtpproxy gets an "update" command for a new
> branch, and then a "delete" command for the previous branch,
> which would otherwise delete the full call, breaking the
> subsequent "lookup" for the new branch.
>
> how it would be possible in SERIAL forked scenario to get anything for a
> new branch before previous branch has first failed and gone?
>
> -- juha
9:06 p.m.
Klaus Darilion writes:
Maybe the description is bad/wrong, but the details
are described in
this thread:
http://lists.sip-router.org/pipermail/sr-users/2012-February/071943.html
klaus,
that description there is not very clear either:
I ran into a scenario with couple of serial forks where kamailio loops
to itself and, due to the looping, the INVITE to a new branch happens
before the CANCEL to an old branch.
is the setup without the 1/2 flags like this:
uac invite -> proxy -> invite -> proxy -> invite -> first uas
-> cancel -> proxy -> cancel -> first uas
-> invite -> second uas
where second proxy instance calls unforce_rtpproxy when it receives the
cancel, thus tearing down also the rtpproxy session for the second leg?
is so, why would second proxy instance be involved with rtpproxy stuff
at all because that has been already taken care of by the first
instance?
-- juha
9:18 p.m.
Juha Heinanen writes:
is the setup without the 1/2 flags like this:
uac invite -> proxy -> invite -> proxy -> invite -> first uas
-> cancel -> proxy -> cancel -> first uas
-> invite -> second uas
where second proxy instance calls unforce_rtpproxy when it receives the
cancel, thus tearing down also the rtpproxy session for the second leg?
is so, why would second proxy instance be involved with rtpproxy stuff
at all because that has been already taken care of by the first
instance?
or is it so that first proxy instance didn't arm rtpproxy, but second
instance did and then first instance armed rtpproxy for second uas
before second instance unarmed it due to cancel?
-- juha
22 Oct
22 Oct
8:04 p.m.
Please ask Andreas about those flags - he commited it
regards
klaus
On 17.10.2012 20:18, Juha Heinanen wrote:
Juha Heinanen writes:
is the setup without the 1/2 flags like this:
uac invite -> proxy -> invite -> proxy -> invite -> first uas
-> cancel -> proxy -> cancel -> first uas
-> invite -> second uas
where second proxy instance calls unforce_rtpproxy when it receives the
cancel, thus tearing down also the rtpproxy session for the second leg?
is so, why would second proxy instance be involved with rtpproxy stuff
at all because that has been already taken care of by the first
instance?
or is it so that first proxy instance didn't arm rtpproxy, but second
instance did and then first instance armed rtpproxy for second uas
before second instance unarmed it due to cancel?
-- juha
11:46 p.m.
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
25 Oct
25 Oct
5:02 p.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
4414
days inactive
4422
days old
7 comments
4 participants
participants (4)
-
Andreas Granig -
Juha Heinanen -
Klaus Darilion -
Ovidiu Sas