[Serusers] NAT - Lots of flavours..

[Ricardo Poppi]

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 <jan at iptel.org>
Subject: Re: [Serusers] NAT - Lots of flavours...
To: Ricardo Poppi <rpoppi77 at giro.com.br>
Cc: serusers at lists.iptel.org, sobomax at portaone.com
Message-ID: <20050708185158.GY6497 at localhost.localdomain>
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.