[asterisk-dev] Symmetric RTP behaviour and 'nat' peer option.

[Alistair Cunningham]

Alex,

We suffered from the same when doing a Dial() to the IP address of the 
SIP proxy, and a fix was produced. For more details, see:

http://bugs.digium.com/view.php?id=14546

Alistair Cunningham
+1 888 468 3111
+44 20 799 39 799
http://integrics.com/


Alex Balashov wrote:
> Greetings,
> 
> I am running Asterisk 1.4.21.2 and seeing some counterintuitive 
> behaviour with regard to RTP and far-end NAT traversal and could use a 
> little perspective.
> 
> The topology looks like this:
> 
>    endpoint <--NAT GW--> NAT traversal fixup proxy <--> Asterisk
> 
> The NAT traversal fixup proxy uses the usual far-end traversal 
> techniques - mangling the Contact header to the received IP, forcing the 
> use of the received port for replies, and SDP received IP endpoint 
> mangling.
> 
> There is a SIP peer built out to the proxy from Asterisk.
> 
> Anyway, when I initiate a call from the phone to a PSTN gateway through 
> this chain (Asterisk bridges the call to a PSTN gateway via SIP), I am 
> seeing the following behaviour.  Here is the scenario:
> 
>    1) Endpoint sends INVITE to proxy;
> 
>    2) Proxy does NAT traversal fixups including substitution of received
>       IP in the m= line of the SDP payload.
> 
>    3) Proxy statefully forwards call to Asterisk.
> 
>    4) When the endpoint starts sending RTP toward Asterisk after the
>       call is established, the source port of the RTP packets is
>       different from the destination port announced in the endpoint's
>       initial INVITE's SDP payload.  This is typical of SIP NAT gateways
>       without SIP-aware ALGs.
> 
> And here is what I am experiencing:
> 
> 1) With nat=no on the peer, Asterisk sends RTP toward the endpoint at 
> the destination port specified in the SDP payload of its INVITE *until* 
> it receives its first RTP packet from the endpoint.  The first RTP 
> packet has a different source port than what was advertised in the 
> endpoint's SDP offer, and from that moment, Asterisk starts sending RTP 
> to the source port of that first media packet *instead* of what is in 
> the SDP.
> 
> 2) With nat=yes, Asterisk ignores the source ports of incoming RTP from 
> the endpoint and continues sending media to the destination port 
> specified in the received SDP.
> 
> ...
> 
> This seems counterintuitive to me.  I had always thought that nat=yes is 
> what enables symmetric RTP, but it seems that the opposite is true in 
> this implementation;  with nat=yes, the received source port of 
> subsequent RTP is ignored and the SDP is used, while with nat=no, 
> attention is paid to the actual received source port.
> 
> What am I missing?
> 
> Thanks!
>