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

Iñaki Baz Castillo ibc at aliax.net
Tue Feb 10 15:17:44 CET 2009


2009/2/10 Johansson Olle E <oej at edvina.net>:
>> 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?

Yes, but it will not receive it if the incoming RTP comes from a
different address (the RtpProxy). The NAT router will not allow that
incoming traffic since there hasn't been a NAT mapping before (the
client doesn't send its RTP to RtpProxy but to the gateway).



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

Ahhh, but that's Comedia mode (available in Asterisk, SEMS, some Cisco
gateways...)
I already mention decives supporting Comedia mode in my first mail to
this thread :)


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

In this point I don't agree again. What you suggest it:

alice --- (NAT A) --- ProxyA & RtpProxyA --- ProxyB & RtpProxyB ---
(NAT B) --- bob

So:

- alice calls bob. ProxyA applies RtpProxyA to the INVITE.
- ProxyB receives the INVITE and doesn't apply RtpProxyB since address
in SDP is public (set by ProxyA).
- bob replies 200 OK.
- ProxyB applies RtpProxyB to the response.
- The reply arrives to ProxyA which doesn't apply RtpProxyA since the
SDP address is public (set by ProxyB).

So we get the following RTP flow (please use fixed size fonts):

alice       (NAT A)       RtpProxyA      RtpProxyB    (NAT B)     bob

-------------------------------------------->
                                             ----------------------->

<------------------------------
                               <-------------------------------------

- RTP from alice will not arrive to bob since it will be rejected by
NAT B router (no existing mapping).
- RTP from bob will not arrive to alice since it will be rejected by
NAT A router (no existing mapping).
- No audio at all.


-- 
Iñaki Baz Castillo
<ibc at aliax.net>



More information about the Users mailing list