[Serusers] rtpproxy question

Maxim Sobolev sobomax at portaone.com
Mon Nov 3 22:57:09 CET 2003


Yes, but it this header not traverse certain SIP signalling B2BUAs.

-Maxim

Jan Janak wrote:

> 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.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
> 
> 
> 





More information about the sr-users mailing list