Re: [Serusers] NAT - Lots of flavours.. - sr-users

11 Jul 2005

Hi all. Thanks to Jan and Andres for the help. 
                  ---     ------

Things are working better now.

I did some tests and now I´m sure. Asterisk don´t give a dam to
"a=direction:active". It only
cares about the NAT="yes" parameter in "sip.conf" file - or
sip_buddies table for realtime users... -

For me its ok. My SER/Asterisk host has a public IP. So, it works. I could debug sip and
rtp and I saw it erroring "could not find network to send RTP" and when the UA
send it first packet...TA-DA!! Everything works fine! RTP media path goes like oil!

----------------------------------

I disabled the SDP fix from my "ser.cfg" so I can make my NATed UAs - behind the
same NAT - talk to each other and establish the media path
based on internal values that, in this case, are true values.

To fix when a public UA calls a NATed one, I use a t_on_reply to fix the 200-0K of all UAs
that are being called from public UAs. When the INVITE cames from a NATed UA, I use
another route - for t_on_reply() - and it don´t fix the 200-OK and my first case - media
between NATed - keeps working...

Ok. But when a NATed UA from ANOTHER NATED NETWORK - calls a NATed UA from my network I
got problems. Problems because my "ser.cfg" won´t deal with SDP values and the
internal IP:Port for media path will be kept. With this, I will never be conversation
between then.

DO ANYBODY HAS ANY IDEA/PRODUCTION CASE TO DEAL WITH THAT?
----------------------------------------------------------

Thanks in advance.

Ricardo Poppi.

Date: Fri, 8 Jul 2005 20:51:58 +0200
From: Jan Janak &lt;jan(a)iptel.org&gt;
Subject: Re: [Serusers] NAT - Lots of flavours...
To: Ricardo Poppi &lt;rpoppi77(a)giro.com.br&gt;
Cc: serusers(a)lists.iptel.org, sobomax(a)portaone.com
Message-ID: &lt;20050708185158.GY6497(a)localhost.localdomain&gt;
Content-Type: text/plain; charset=iso-8859-2

Hello, comments inline.

On 04-07-2005 19:44, Ricardo Poppi wrote:

...

 Hi list,

 I´m trying to put to work a NATed environment and want to share some 
 information and request some I don´t realized yet.

 I use an asterisk gateway, with a public IP, working really fine for UAs 
 with public IPs. At the same machine I runs SER that receives all SIP 
 messages and handle when it should go to a SIP UA or to asterisk, 
 rewriting the port (to the one asterisk uses) and sending to it. I don´t 
 replicate register to asterisk, and use the user accounts as "peer", 
 instead of "friends".

 My ser.cfg is using the "force_rport()" and "fix_nated_contact()" for

 every REGISTER it receives from nat UAs - I know when it comes from a 
 NATed UA using nat_uac_test("2").

 Every INVITE that comes from NATed UA passes through a 
 "fix_nated_sdp("2"), that rewrites the IP address of SDP headers. Using 
 a onreply route I fix the 200 OK INVITE message, just in case that the 
 NATed UA is on the called side.

 The UAs I´m using are X-Lite, Clipcomm CP-100 IP Phone, and Grandstream 
 HT-488.

 Below I wrote the different kinds of configuration into the UA and in 
 ser.cfg, and the results I got:

 1) Using without touching the UA - It don´t know it is a NATed UA.

-----------------------------------------------------------------------------------------------------------------------------

 All REGISTER are treated ok because the force_rport make SER respond to 
 the register on the same external IP:Port it received. On the same hand, 
 it stores the right URI into the location database making the UA receive 
 the subsequent INVITES or other SIP messages through the external IP:Port.

 The INVITES that comes from NATed UA have their SDP IP address rewriten 
 by SER and the external IP takes place. But the port is kept the 
 internal value, so when the called UA tries to reach the 
 External_IP:Internal_port the NAT/Firewall probably block/drops the 
 packets, and the result is a one-way audio - The one-way audio is 
 probably due to the right value that comes from the SDP headers of the 
 called UA - asterisk -, that has a public IP.   

  I just quickly looked into nathelper sources and it looks like it can
  only rewrite the port number in SDP if you run force_rtp_proxy,
  fix_nated_sdp seems to change the IP address only. I CCed to Maxim,
  maybe he could clarify this better than myself.

...
   2)
a=direction:active
 ----------------------------------

 If I add into ser.cfg a "fix_nated_sdp("1")"  command, it will add
the 
 "a=direction:active" parameter to SDP header of INVITE that comes from 
 NATed UAs. I saw that it´s happening but the asterisk seems to not 
 understand that and don´t expect for the first RTP packet to get the 
 IP:Port information of the media. A one-way audio is the result of that. 
 The asterisk is probably sending RTP packets to the 
 Ext_IP:Internal_port, and the firewall is blocking the packets.   

  If asterisk does not support symmetric RTP then you will have to put
  the rtpproxy between the user agent and asterisk and call
  force_rtp_proxy instead of fix_nated_sdp in the script. I am not sure
  if I remember it correctly, but I think that asterisk should support
  symmetrict rtp, so maybe the problem is in fix_nated_sdp function
  which does not alter media ports.

---------
  Does anyone on the list know if asterisk supports symmetric RTP ? In
  other words, can asterisk interpret a=direction:active parameter from
  SDP and send media to the source IP and port of the incoming media
  stream, instead of the IP and port from SDP ?
---------

  You can also try to put rtpproxy between user agents and asterisk and
  call force_rtp_proxy instead fix_nated_sdp. It's not the best
  solution, but this way you could verify if the problem is in unaltered
  port number in SDP.

    Jan.