3 Nov
2003
3 Nov
'03
1:10 p.m.
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.
> >
> >
>
>
>