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

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.

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.