3 Nov
2003
3 Nov
'03
1:43 p.m.
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(a)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(a)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.
> >
> >
>
>
>