Re: [Serusers] rtpproxy question

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