snom 4S NAT Filter
Admin Manual
snom 4S
NAT Filter
Version 2.05
snom 4S NAT Filter Version 2.05
© 2004 snom technology Aktiengesellschaft. All Rights Reserved.
This document is supplied by snom technology AG for information purposes only to licensed
users of the snom 4S NAT lter and is supplied on an “AS IS” basis, that is, without any
warranties whatsoever, express or implied.
Information in this document is subject to change without notice and does not represent any
commitment on the part of snom technology AG. The software described in this document
is furnished under a license agreement and may be used only in accordance with the terms
of that license agreement. It is against the law to copy or use this software except as
specically allowed in the license. No part of this document may be reproduced, republished
or retransmitted in any form or by any means whatsoever, whether electronically or
mechanically, including, but not limited to, by way of photocopying, recording, information
recording or through retrieval systems, without the express written permission of snom
technology AG.
Legal Disclaimer
snom offers the software described in this manual for both open source operating systems
as well as licensed operating systems. Whenever software that has been used under GPL
or LGPL licensing conditions has been used by this product you can download the sources
from http://www.snom.com/downlad/gpl/snom_ossdk or purchase a disc from snom for a
nominal fee under the ordering code snom SDK CD.
snom technology AG • 3
Table of Contents
1 Overview ..........................................................5
1.1 Applications ...................................................................... 5
1.2 Features ........................................................................... 6
2 Architecture .....................................................7
2.1 The NAT Filter and SIP........................................................ 7
2.2 NAT ................................................................................. 8
2.2.1 How does NAT work?
.........................................................................................................................................................
8
2.2.2 Symmetrical RTP
.....................................................................................................................................................................
9
2.2.3 Signalling SIP
...............................................................................................................................................................................
9
2.2.4 Media RTP
......................................................................................................................................................................................
10
2.2.5 Classication of User Agents
..............................................................................................................................
10
2.2.6 Probing Media Paths
.......................................................................................................................................................
11
2.2.7 The Role of the NAT Filter
......................................................................................................................................
11
2.2.8 Optimizing the Media Path for Symmetrical NAT
..................................................................
12
2.3 Filter Behaviour ............................................................... 12
2.3.1 Registering without UA Support
....................................................................................................................
12
2.3.2 Registering with UA Support
..............................................................................................................................
14
2.3.3 RTP Relay
.......................................................................................................................................................................................
15
2.4 Scaling and Redundancy ................................................... 17
2.5 Detecting the right NAT Filter ............................................ 18
2.6 Requirements on User Agents............................................ 19
2.6.1 Non NAT-Aware User Agents
.............................................................................................................................
19
2.6.2 STUN/ICE-Aware User Agents
..........................................................................................................................
19
3 Installation.....................................................21
3.1 Windows......................................................................... 21
3.2 Linux ............................................................................. 29
4 Conguration..................................................31
4.1 Logging In ...................................................................... 31
4.2 Port Binding .................................................................... 31
4.3 System Settings .............................................................. 33
4 • Contents
[ S N O M 4 S N A T F I L T E R ]
4.4 Security Settings ............................................................. 35
4.5 System Information ......................................................... 36
4.6 Server Log...................................................................... 36
4.7 Trace.............................................................................. 37
4.8 Currently Ports ................................................................ 38
4.9 Currently Handled UA ....................................................... 38
4.10 Memory Statistics ............................................................ 39
5 Checklist for Installation ................................41
5.1 Linux ............................................................................. 41
5.2 Windows......................................................................... 41
snom technology AG • 5
1 Overview
The snom 4S NAT Filter enables non-NAT aware devices to
operate in private networks. The lter operates typically on a public IP
address. Non-NAT aware devices are automatically refreshed; NAT-aware
devices that operate behind symmetrical NAT may self-refresh their
bindings using the built-in STUN server of the lter. Devices on public
Internet traverse the lter without changes or refreshes. By supporting
Interactive Communications Establishment (ICE), the number of calls that
must go through the lter can be minimized.
The operator version of the product also offers recording
capabilities. Through a separate management interface, operators
can dene numbers that are silently recorded. The lter records in
uncompressed PCAP format which is primary important for troubleshooting
and signalling recording. It also offers a compressed mode where only the
voice part of the conversation is recorded in highly-compressed audio
format (13.2 kBit/s).
The operation of the lter is similar to a session border controller.
However, we do not like the term “session border”, because the lter
does not control sessions nor is it on the border of a call. It does also not
translate signalling, e.g. from SIP to H.323 or to MGCP. If all user agents
are fully NAT-compliant or on public Internet, the lter can transparently
be removed from the network without changing of the call ows or
functionality. Also, the lter does not interfere with unknown applications.
This is tremendous advantage against session borders controllers which
need software update for new applications.
1.1 Applications
The lter can be used in the following scenarios:
• Corporations. Corporations which operate their infrastructure be-
hind NAT and/or rewalls can talk to the public Internet through the
lter.
• Operators. Operators offer the NAT traversal feature to their cus-
1.
6 • Overview
[ S N O M 4 S N A T F I L T E R ]
tomers. Using the scalability feature of the lter, the operation of
large networks becomes possible.
• Record specic calls for legal purposes. In many countries, operators must provide the possibility to record certain calls on request.
The lter can perform this task.
• Recording can be used for legal proong (brokers, etc). The lter is
fully compliant with other SIP equipment and can for example put
between a PSTN gateway and SIP phones.
1.2 Features
The lter offers powerful features based on modern VoIP
technology:
• The built-in RFC3261-compliant SIP proxy makes additional external SIP logic superuous and simplies the system setup.
• A built-in RFC3489-compatible STUN server for single IP addresses
allows client to self-refresh their bindings
• Support for instant messaging, presence and all other SIP-compliant applications.
• Rich logging features allow easy maintenance.
• Recording functions based on number lists and expressions offer a
exible way of ltering out information.
• Recordings can be saved in PCAP and WAV le formats (6 MB/h).
• Almost stateless operation allows the lter to be used in server
farms. This offers a tremendous scalability and redundancy making
the product suitable for large operators.
• Both http and https as web interface for simple access from anywhere on the Internet.
• The lter supports Interactive Connectivity Establishment (ICE).
User agents that support this feature will optimize the media path
for the shortest possible delay.
1.
snom technology AG • 7
2 Architecture
2.1 The NAT Filter and SIP
In the SIP architecture, the lter acts as the rst proxy that is
contacted by user agents. There are two ways to make sure that the
relevant trafc gets routed trough the lter:
• User agents can be set up to use the lter as outbound proxy. When
using this method, all SIP trafc will ow through the lter, weather
it is destined to the operator or not. That means that also service for
calls outside of the operator’s domain may be serviced by the lter.
However, by redirecting all outgoing trafc of the lter to a proxy
the operator can make sure that the authentication, authorization
and accounting (AAA) requirements for requiring the service are
fullled.
• User agents resolve the lter though the RFC3263 DNS resolving
process. That means that only the trafc that is destined to the
operator’s domain will use the service of the NAT Filter. However,
users might be annoyed if they place a call to a domain that does
not properly support NAT services. In this case, the lter can also
redirect the trafc to another proxy for AAA.
We recommend using the rst alternative and only choose the
second alternative if it is too difcult to provision the user agents with the
outbound proxy or there are concerns about providing service for foreign
operators.
Usually, the lter acts as stateless proxy. That means, by default
it just forwards the packets and does not change the content of the
attachments or the headers themselves. That means, the lter will not
interfere with applications (instant messaging, presence, weather report,
etc).
There are two exceptions to this rule:
• The rst exception is a REGISTER request. When a user agent tries
to register and needs the support of the lter, the lter will set up a
2.
8 • Architecture
[ S N O M 4 S N A T F I L T E R ]
snom technology AG • 9
[ S N O M 4 S N A T F I L T E R ]
local data structure representing the user agents. It will make sure
that the connection to the user agents stays alive. It will also make
sure that requests that are destined to the user agents will be forwarded properly. The same applies to SUBSCRIBE requests.
• The second exception is a SDP attachment. The lter checks if the
user agent needs support (or must be recorded) and will in that case
add a local contact to the SDP that can be used for media relay.
These two exceptions make sure that all user agents will work
behind NAT, no matter what NAT-type or how many NAT-levels are being
used. If user agents support ICE, they will automatically nd the shortest
path to the other party (peer-to-peer).
2.2 NAT
Network Address Translation (NAT) is a reality in today’s networks.
Many operators save IP addresses by providing only one IP address for a
number of devices, sometimes companies. Firewall manufacturers make
NAT a feature by performing inspection of packets that go though NAT.
Even for IPv6 networks, the fundamental problem will remain as there will
also be a need for rewalls and private networks.
The Session Initiation Protocol (SIP) has neglected this problem
in the beginning. However, in some recent RFC there have been useful
proposals how to deal with the problem. This document shows how the
snom 4S lter can be used to solve the problems.
Although snom also makes user agents, the snom 4S lter works
with most SIP user agents from other companies. The requirements on
these user agents are described below.
If you want to use the lter just for recording purposes, you don’t
need to bother about NAT. The lter also works when no NAT is present.
2.2.1 How does NAT work?
NAT is essentially a translation table that maps public IP address
and ports combinations to private IP address and port combinations.
The translation table is implicitly set up when a packet is sent
from the private network to the public network. The association is kept
alive for a certain time and is refreshed every time a new packet is sent
2.
snom technology AG • 9
[ S N O M 4 S N A T F I L T E R ]
from the same origin. This fact is used by STUN (RFC3489) to set up an
association between a public IP address and a private IP address.
In symmetrical NAT, the router stores the address where the
packet was sent. Only packets coming from this address are forwarded
back to the private address. This algorithm increases the security as it is
harder to guess the source IP and port for attackers. Full cone NAT does
not perform this check.
There are some mixed variants between full cone NAT and
symmetrical NAT. Restricted port NAT works similar like symmetrical NAT,
but uses only one port association.
Hairpinning is the ability of the NAT to route packets coming from
the private network addressed towards a public IP address binding back
to the private network. Not all routers are supporting this feature.
2.2.2 Symmetrical RTP
The real time protocol (RTP) is used to transport media.
Symmetrical RTP is a trick to extend the number of cases when
communication can be established. A SIP user agent that supports
symmetrical RTP waits for the rst RTP packet coming in and then sends
its media stream back to the IP address from which it received that packet.
Symmetrical RTP works always if the user agent that does symmetrical
RTP is on a globally routable address. However, this algorithm can easily
be cheated (port spraying) and therefore implies a certain security risk.
2.2.3 Signalling SIP
SIP trafc is relatively unproblematic because SIP typically is not
as time critical as media. Usually, it is ok to route SIP packets through a
longer path than media.
In SIP it is legal to send from a different port than the receiving
port. When this is being done, there is no way of supporting these devices
behind NAT. However, some phones offer an option that disables this
mechanism so that the sending port is the same as the receiving port.
Typically, the SIP proxy will run on a public IP address where it
is possible to deal with all kinds of NAT. Keep-Alive messages may keep
the NAT binding open (for example, short registration periods or non-SIP
messages).
2.
10 • Architecture
[ S N O M 4 S N A T F I L T E R ]
snom technology AG • 11
[ S N O M 4 S N A T F I L T E R ]
2.2.4 Media RTP
Media is much more problematic than SIP because users are
sensitive to delay in a voice conversation. When the delay is too long, the
speakers need to be disciplined not to interrupt the other person when
starting to speak. Also, the ear is much more sensitive to echo when the
media delay becomes too long. The effect is known from intercontinental
calls where the speed of light increases the delay for voice transmission.
SIP was designed for peer-to-peer communication. That means
the user agents (telephones) send the media directly to the other user
agent. This approach is the best way to minimize the delay; however it
becomes a problem when NAT is involved.
2.2.5 Classication of User Agents
From a lter point of view, available user agents can be classied
into the following categories:
• Public IP devices. These devices operate on public IP addresses and
don’t need any specic support regarding NAT. The true location of
these devices may be in a private network, as they might have allocated a public identity using mechanisms like UPnP™ [3]. These
devices are most welcome as they don’t cause any additional requirements.
• STUN devices. Phones that operate behind full cone NAT and allo-
cate public IP addresses themselves fall into this category. The only
support that the proxy needs to give is a STUN server. Apart from
that they act like public IP devices.
• Non NAT-aware devices. These devices don’t attempt to check the
NAT type or allocate a public IP address. Often, they are “legacy”
devices that have been designed without having NAT in mind. These
devices can register only for a short period of time, so that the REGISTER messages keep the port association open (the SIP messages
are used to keep the port association). Also, these devices need a
NAT-aware media server or other device that forward the RTP packets of these devices.
• Symmetrical NAT devices. These devices may be NAT-aware; how-
ever, because they operate behind symmetrical NAT, there is little
that they can do. They essentially behave like non NAT-aware SIP
devices and hope for the support of the proxy.
2.
snom technology AG • 11
[ S N O M 4 S N A T F I L T E R ]
2.2.6 Probing Media Paths
ICE is a method that has been proposed recently in the IETF [4].
The algorithm is simple: A user agent that supports ICE lists the possible
addresses where it could possibly be reached. These addresses may
include the private address, an address allocated via STUN, one or more
addresses allocated with the TURN protocol or an address allocated with
UPnP. Because practically it is hard to predict which of these addresses are
visible to the other user agent, all of the possible addresses are proposed
to the other user agent.
The other user agent sends test packets to the possible addresses.
Picking the rst reply on the test packet will establish a working media
path and it will also probably be the fastest connection. STUN is being
used for these test packets.
2.2.7 The Role of the NAT Filter
When a user agent is not able to allocate a globally routable
address or it is not sure if it found enough possible addresses, the NAT
Filter can help out.
Again, the way the NAT Filter works, is simple. For the signalling,
the NAT Filter keeps the NAT alive with bogus messages (which can be SIP
messages or other non-SIP message). It patches the messages in such a
way, that other user agents will address the NAT Filter instead of the user
agent when they want to deliver a message. The NAT Filter then forwards
the message to the user agent using the connection which is kept open
with the keep-alive messages.
When the NAT Filter sees a message that contains information
about sending media (session description protocol, SDP), it opens a local
globally routable port on behalf of the user agent and patches these
messages in a way that the destination will send media via this port.
The NAT Filter will relay the media to the user agent like it relays SIP
messages. Using symmetrical RTP, it can detect the user agent’s public
media identity and reroute the packets to this destination.
While this approach has the huge advantage that it does work
will all kinds of NAT, it has the disadvantage that it increases the media
path signicantly. For example, when a user A in Tokyo is registered
with a operator in New York and wants to call his colleague B (which is
registered to a service provider in Sydney and who is sitting in the same
2.
12 • Architecture
[ S N O M 4 S N A T F I L T E R ]
snom technology AG • 13
[ S N O M 4 S N A T F I L T E R ]
ofce in a private network), the media would have to ow rst from Tokyo
via New York then via Sydney and then back to Tokyo. Considering the
speed of light, the delay would at least be around one second; practically
it would be much higher although the user agents are located in the same
network.
Unfortunately, it is not trivial to make the media path shorter.
There have been some attempts to reduce the problem, but it is much
easier to address the problem from the user agent. If the user agent uses
ICE, it will try all addresses listed in the SDP attachment, including the
port allocated by the NAT Filter. If there should be a shorter path, it will
switch to this shorter path. If there is no other way of if the other side
does not support ICE, it will fall back to the NAT Filter-allocated port which
will work in all cases.
2.2.8 Optimizing the Media Path for Symmetrical
NAT
In the case when both user agents are behind symmetrical NAT
the NAT Filter approach will ensure that media will ow between the
user agents. However, the Tokyo example shows that this might result in
intolerable media delay.
To address this problem, TURN [5] comes into play. The idea
behind this approach is to allocate identities on several places in the
Internet and to propose all of the allocated ports to the other user
agent. If the ports are allocated on all continents, the other user agent
will automatically pick the TURN server with the shortest delay. In the
Tokyo example, a TURN server located in Japan will reduce the delay
to a tolerable level (if there is not even a direct path between the user
agents).
2.3 Filter Behaviour
2.3.1 Registering without UA Support
When a user agent registers, it puts its IP address in the top
Via. If the user agent is on public Internet or properly supports NAT, this
Via will match the perceived IP address. In this case the lter does not
interfere with the registering process and just forwards this packet.
2.
snom technology AG • 13
[ S N O M 4 S N A T F I L T E R ]
If the top Via does not contain the perceived address, the lter
will take care about the request. It will replace the provided contact with
a locally generated contact and forward the request to the registrar (see
below).
REGISTER sip:snomag.de SIP/2.0
Via: SIP/2.0/UDP 203.145.183.113:12975;branch=z9hG4bKabx3au3mxb01;rport
From: “denny” <sip:denny@snomag.de>;tag=k9p6fmeg7h
To: “denny” <sip:denny@snomag.de>
Call-ID: 3c26701d7cb9-pady07b5783t@203-145-183-113
CSeq: 14 REGISTER
Max-Forwards: 70
Contact: <sip:denny@203.145.183.113:12975;line=lhynyb3y>;q=1.0
User-Agent: snom200-2.03w
Supported: gruu
Expires: 86400
Content-Length: 0
REGISTER sip:snomag.de SIP/2.0
Via: SIP/2.0/UDP 217.115.141.99:5082;branch=z9hG4bK-e8d1feb8138c3d85
0637ced821ef40a3;ua=c9b140ab598290e5bb491e9c3aaca440
Via: SIP/2.0/UDP 203.145.183.113:12975;branch=z9hG4bKabx3au3mxb01;rport=17401
From: “denny” <sip:denny@snomag.de>;tag=k9p6fmeg7h
To: “denny” <sip:denny@snomag.de>
Call-ID: 3c26701d7cb9-pady07b5783t@203-145-183-113
CSeq: 14 REGISTER
Max-Forwards: 69
Contact: <sip:217.115.141.99:5082;ua=c9b140ab59829bb491e9c3aaca440>
Supported: gruu
User-Agent: snom200-2.03w
Expires: 86400
Content-Length: 0
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 217.115.141.99:5082;branch=z9hG4bK-e8d1feb8138c3d85
0637ced821ef40a3;ua=c9b140ab598290e5bb491e9c3aaca440
Via: SIP/2.0/UDP 203.145.183.113:12975;branch=z9hG4bKabx3au3mxb01;rport=17401
From: “denny” <sip:denny@snomag.de>;tag=k9p6fmeg7h
To: “denny” <sip:denny@snomag.de>;tag=epuy85kzm5
Call-ID: 3c26701d7cb9-pady07b5783t@203-145-183-113
CSeq: 14 REGISTER
Contact: <sip:217.115.141.99:5082;ua=c9b140ab598290e5bb491e9c3aaca44
2.
14 • Architecture
[ S N O M 4 S N A T F I L T E R ]
snom technology AG • 15
[ S N O M 4 S N A T F I L T E R ]
0>;expires=3600;gruu=”sip:denny@snomag.de;gruu=hobiv52b”
Date: Wed, 26 May 2004 16:03:33 GMT
Server: snom proxy (Unix) 2.42.6
Content-Length: 0
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 203.145.183.113:12975;branch=z9hG4bKabx3au3mxb01;rport=17401
From: “denny” <sip:denny@snomag.de>;tag=k9p6fmeg7h
To: “denny” <sip:denny@snomag.de>;tag=epuy85kzm5
Call-ID: 3c26701d7cb9-pady07b5783t@203-145-183-113
CSeq: 14 REGISTER
Contact: <sip:denny@203.145.183.113:12975;line=lhynyb3y>;expires=360
0;gruu=”sip:denny@snomag.de;gruu=hobiv52b”
Server: snom proxy (Unix) 2.42.6
Date: Wed, 26 May 2004 16:03:33 GMT
Content-Length: 0
2.3.2 Registering with UA Support
Leaving the refreshing of the UDP binding to NAT Filter usually
will keep the connection alive. However, it is better if the user agent
refreshes the binding:
• When the user is taken off the network the NAT Filter does not gen-
erate unnecessary refreshes. The same happens when for example
the DSL router is turned off.
• When refresh packets cannot be delivered because of congestion
or other network problems, the NAT router will close the ports and
there is no way to open them again from the outside. If the user
agent refreshes the bindings, the port is opened automatically
again.
• User agents may send from time to STUN packets and process the
answer to check if the IP address has changed. In this case, the user
agent may refresh the SIP binding.
A user agent that supports this way of refreshing the bindings
includes a “P-NAT-Refresh” header in the REGISTER message:
REGISTER sip:snom.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.10:5060;branch=z9hG4bK-fozdn9kbolfw
From: “Karl Klammer” <sip:kk@snom.com>;tag=9e9mynnnwa
To: “ Karl Klammer” <sip:kk@snom.com>
Call-ID: 10f2c240790b-cj4sy7drgp6q@192-168-1-10
CSeq: 2 REGISTER
2.
Loading...