I like Maxims idea of inserting a flag in the SDP body most, because it seems to be easy to implement. The drawback is that all SIP providers have to support it - but this problem also occours with the other solutions.
regards, klaus
-----Original Message----- From: Jan Janak [mailto:jan@iptel.org] Sent: Monday, November 03, 2003 7:11 PM To: Klaus Darilion Cc: Maxim Sobolev; serusers@lists.iptel.org Subject: Re: [Serusers] rtpproxy question
I think the solution is to modify the RTP proxy. The RTP proxy should be symmetric only for user agents that belong to the domain of the proxy and if the other direction is a foreign user, it should send the data to the IP taken from SDP and not wait for any incomming packets.
Let's take iptel.org as a hypothetical example:
If both caller and callee have iptel.org as their domain, the RTP proxy will work as usual.
If caller is not from iptel.org but callee is, then the SIP proxy will pass IP of the NAT box (known from Contact in usrloc) and IP from SDP of INVITE to RTP proxy. The RTP proxy will be symmetric for the NAT IP and non-symmetric for the IP from SDP.
In the reverse direction, i.e. when callee is not from iptel.org and caller is (i.e. the invite is coming from iptel.org to fwd, for example), the SIP proxy will pass IP from the received parameter for the "symmetric side" and IP from SDP of 200 OK for the "non-symmetric part".
That way it is not ensured that there is just one RTP proxy along the path, but it should work.
In other words, every SIP proxy provides "symmetric RTP proxy" for its users only, it doesn't provide it for foreign users.
Drawback of this approach is that it is not possible to use only one RTP proxy in cases like:
UA---NAT---Sipphone---iptel.org---NAT---UA
In that case both Sipphone and iptel.org must enforce RTP proxy, each proxy is responsible for getting their users through NAT.
Anyway, implement and deploy something like that is quite complex.
Jan.
On 03-11 18:49, Klaus Darilion wrote:
But if UA1 ist not behind NAT, proxy 2 should activated its
rtpproxy to
enable a communciation although there are more than 2 Via headers.
I guess there is no solution yet which will work in all
scenarios as one
SIP proxy will never know the NAT-traversal strategy of
other proxies.
regards, klaus
-----Original Message----- From: Maxim Sobolev [mailto:sobomax@portaone.com] Sent: Monday, November 03, 2003 6:40 PM To: Jan Janak Cc: Klaus Darilion; serusers@lists.iptel.org Subject: Re: [Serusers] rtpproxy question
There is another possible solution: modify nathelper to only apply RTP proxy redirection if there is only one Via in the
request. This will
ensure that in the situation when there are multiple SIP/RTP proxies in the path only first one will handle RTP. Unfortunately it will not help if there are any SIP B2BUAs on the way.
-Maxim
Jan Janak wrote:
On 03-11 19:18, Maxim Sobolev wrote:
Klaus Darilion wrote:
Hi!
As the RTP relaying does not work with 2 RTP proxies, how
can a proxy
detect if the RTP stream is already redirected to an RTP proxy?
My problem is the following scenario:
UA1 --NAT-- SIP proxy 1 -- SIP proxy 2 --NAT-- UA2 rtpproxy1 rtpproxy2
UA1 invites UA2. SIP proxy 1 detects that UA1 is behind
NAT and enables the
rtpproxy1 and forwards the invite to SIP proxy2. SIP proxy
2 knows that UA2
is also behind NAT. Usually, SIP proxy 2 would activate
the rtpproxy2, but
in this case this would not work as there is already an
rtpproxy involved.
How can the SIP proxy 2 detect that the IP address in the
SDP is the IP
address of an RTP proxy?
Known problem. I think that I'll modify nathelper, so that force_rtp_proxy() will insert some flag into the SDP body,
which will
tell other proxies along the request route that there is no
need to put
another RTP relay into the RTP path.
Another option would be to insert a header field telling
that another
RTP proxy is being used already.
The problem is that both solutions (header field and SDP
flags) will
be not interoperable.
Another option would be to modify the RTP proxy so
that it will be
symmetric only for user agents that belong to the domain
of the proxy.
That would probably complicate things a bit.
Jan.