Re: [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 <o...@edvina.net>:

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


SDP will contain a public IP.
Since ProxyB knows that bob is registered behind NAT, it will try to

a line:
a=nortpproxy:yes
This line was added by ProxyA when applying RtpProxyA.

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

In this case, when alice calls bob, ProxyA will apply RtpProxyA so the apply RtpProxyB but this will "fail" because the incoming SDP contains When ProxyB executes "force_rtpproxy()" this function will not modify

the SDP already has public IP - fixed by Proxy A.

On the INVITE there's no need for ProxyB to allocate an rtpproxy, since

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

succeded in the incoming INVITE, and only run "force_rtpproxy()" for
responses from bob if that bflag is on.

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()"

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

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users