[Serusers] Re: [Serdev] Better NAT support in registrar

Klaus Darilion klaus.mailinglists at pernau.at
Tue Mar 1 11:07:47 CET 2005


Wow! A perfect description. Thanks Jan.

Wouldn't it be a good idea to put such detailed descriptions from the 
mailinglist into the README files or any other repository, e.g. FAQomatic?

Sometimes there are really good descriptions on the mailinglist (e.g. 
http://lists.iptel.org/pipermail/serdev/2005-February/003877.html) which 
should also be put into the README files.

regards,
klaus


Jan Janak wrote:

> Hello,
> 
> The development version of SER now includes enhanced NAT support in
> registrar and user location database. A small example:
> 
> Let's suppose that you have a single SER instance listening on two
> ports -- 5060 and 5090. Using a different port seems to be often
> necessary because of broken SIP ALGs (Application Level Gateways) that
> are often built into DSL routers or other devices. Such ALGs would
> mangle SIP requests and responses coming to and from port 5060 and the
> only option how to avoid such mangling is using a different port number.
> 
> Let's suppose that we have two UAs beind NAT, one of them is configured
> to reach SER on port 5060, the other one is configured to use port 5090
> (due to the reasons described above):
> 
>                   +---------+
> UA1 ---- NAT1 ----| 5060    |
>                   |      SER|
> UA2 ---- NAT2 ----| 5090    |
>                   +---------+
> 
> The previous version of registrar would store the public IP of NAT with
> each registered contact, thus it would know how to reach both user
> agents.
> 
> But, it would not store the port number of SER the UAs used to register
> themselves and later, when an INVITE comes, it would not know which
> port number (5060 or 5090) it should use as the source port number of
> the outgoing INVITE. The previous version would use the default one,
> which would be the first one configured in the configuration file
> (usually 5060).
> 
> When an INVITE for UA1 comes, everything would work because UA1 used
> port 5060 when registering and that is also the destination port in the
> pinhole being kept open in NAT1:
> 
>                                  SER
>                  INVITE UA1  +--------+     INVITE UA1
> UA1 ---- NAT1 <------------- |  5060  | <---------------- 
>                              |        |
> UA2 ---- NAT2                |  5090  |
>                              +--------+
> 
> When an INVITE for UA2 comes, SER would again use port 5060 as the
> default outgoing source port number, but this time the message will be
> dropped by NAT2, because the pinhole opened during the registration has
> 5060 as the destination port number:
> 
>                                  SER
>                  INVITE UA2  +--------+     INVITE UA2
> UA1 ---- NAT1        +------ |  5060  | <--------------- 
>                      |       |        | 
> UA2 ---- NAT2 X <----+       |  5090  |
>                              +--------+
> 
> The new version of registrar would also store the destination IP and
> port number used on SER side when performing registration and that
> information would be used later by SER when forwarding INVITEs:
> 
>                                  SER
>                              +--------+     INVITE UA2
> UA1 ---- NAT1                |  5060  | <---------------
>                  INVITE UA2  |        |
> UA2 ---- NAT2 <------------- |  5090  |
>                              +--------+
> 
> (Note that the X next to NAT2 has disappeared in this picture which
>  means that the message will be lucky enough to make it through :-).
> 
> SER would encode this information into a SIP URI when saving contacts in
> database and later, after restart of SER, this information will be
> restored. The URI looks like:
> 
> sip:1.2.3.4:5060;dstip=5.6.7.8;dstport=5090
> 
> Where the hostname part is the public IP of the NAT, the port (5060) is
> the port allocated by the NAT, "dstip" parameter is the IP used on SER
> side and "dstport" parameter is the port number used on SER side during
> registration. This information is later used to find the correct outgoing
> socket in SER. If no such socket can be found (it can happen if you
> reconfigure SER to use different ports or IPs), it will use the default 
> IP/port again.
> 
> Daredevils are encouraged to give it a try and send feedback to the list :-)
> 
>    Jan.
> 
> _______________________________________________
> Serdev mailing list
> serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev
> 
> 




More information about the sr-users mailing list