[OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT

[Johansson Olle E]

10 feb 2009 kl. 13.44 skrev Iñaki Baz Castillo:

> 2009/2/10 Johansson Olle E <oej at edvina.net>:
>
>>> alice --- (NAT A) --- ProxyA & RtpProxyA --- ProxyB & RtpProxyB ---
>>> (NAT B) --- bob
>>>
>>> In this case, when alice calls bob, ProxyA will apply RtpProxyA so  
>>> the
>>> SDP will contain a public IP.
>>> Since ProxyB knows that bob is registered behind NAT, it will try to
>>> apply RtpProxyB but this will "fail" because the incoming SDP  
>>> contains
>>> a line:
>>> a=nortpproxy:yes
>>> This line was added by ProxyA when applying RtpProxyA.
>>> When ProxyB executes "force_rtpproxy()" this function will not  
>>> modify
>>> the SDP since that line is present. If not, there will be no audio
>>> because RtpProxyA would be waiting for audio from RtpProxyB and vice
>>> versa (lock condition).
>>
>> On the INVITE there's no need for ProxyB to allocate an rtpproxy,  
>> since
>> the SDP already has public IP - fixed by Proxy A.
>
> No, that's not an excuse. RtpProxy must be applied in both the request
> and response.
> If a PSTN gateway calls a SIP user behind NAT, you must apply RtpProxy
> even if the incoming SDP has public address.
Not in the INVITE sdp - the device behind the NAT can always send
to a public IP address, right?

>
>
>
>>>
>>>
>>> ProxyB must be well configured, this means that since
>>> "force_rtpproxy()" didn't success on the incoming INVITE, it must no
>>> execute "force_rtpproxy()" on the 18X/2XX response from bob. For  
>>> this,
>>> I use a bflag(RTPPROXY_SET) which only set to 1 if  
>>> "force_rtpproxy()"
>>> succeded in the incoming INVITE, and only run "force_rtpproxy()" for
>>> responses from bob if that bflag is on.
>>
>> It should force RTPproxy on teh response from Bob, since Bob is
>> a local user and the SDP includes a private IP.
>
> Not again, please re-read my explanation above :)
>
> In the example of a PSTN gateway calling a natted SIP user, if the
> proxy only applies RtpProxy in the user response then you will get
> asymmetric audio:
>
>
> user  (NAT)                RtpProxy              Gateway
>
>    --------------------------(RTP)------------------->
>
>                                    <---------(RTP)----------
>    <---------(RTP)----------
>
> So the RTP from the gateway will not arrive to the user since the NAT
> router will not allow it (there is not an existing UDP mapping to
> allow UDP traffic from the RtpProxy, but just from the Gateway
> address).
The gateway will (in teh case of Asterisk) listen to the audio
coming from the user and change to the port and
IP we're receiving audio from. That way, we'll have symmetric
audio and will bypass the NAT.

>
>
> So RtpProxy must be present in the request and response, then the NAT
> router mapping will work and allow incoming data from RtpProxy after
> the user sends RTP data to the RtpProxy.
>
>
> Am I wrong?

We are mixing cases here. One case is a gateway scenario, where
the RTP proxy isn't really needed, since the gateway may take
care of it by itself, provided that the gateway is on a public IP.

If you have two users both behind NAT, each user applies
an RTP proxy to the incoming audio stream, not the outbound
stream.

/O


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2206 bytes
Desc: not available
Url : http://lists.opensips.org/pipermail/users/attachments/20090210/bff071b2/attachment.bin