[Serusers] rtpproxy question

[Jan Janak]

Using a special header field is even simpler, because it requires no
implementation at all. Adding and testing for a message header field can
be done right out of the box from the configuration script.

  Jan.

On 03-11 19:43, Klaus Darilion wrote:
> 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 at iptel.org] 
> > Sent: Monday, November 03, 2003 7:11 PM
> > To: Klaus Darilion
> > Cc: Maxim Sobolev; serusers at 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 at portaone.com] 
> > > > Sent: Monday, November 03, 2003 6:40 PM
> > > > To: Jan Janak
> > > > Cc: Klaus Darilion; serusers at 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.
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > 
> > 
> >