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.
) 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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev