Snom 4S NAT Filter User manual

snom 4S NAT Filter
Admin Manual
snom 4S
NAT Filter
Version 2.09

snom 4S NAT Filter Version 2.09
© 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 filter 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
specifically 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.
snom is a registered trademark in the United States of America, Germany and some other
contries.

snom technology AG • 3
Table of Contents
1 Overview ..........................................................5
1.1 Applications ...................................................................... 6
1.2 Features ........................................................................... 6
2 Architecture .....................................................9
2.1 The NAT Filter and SIP ........................................................ 9
2.2 NAT ............................................................................... 10
2.2.1 How does NAT work? ..............................................................................................................................................11
2.2.2 Symmetrical RTP ............................................................................................................................................................11
2.2.3 Signalling SIP .......................................................................................................................................................................11
2.2.4 Media RTP ...................................................................................................................................................................................12
2.2.5 Classification of User Agents ....................................................................................................................12
2.2.6 Probing Media Paths .................................................................................................................................................13
2.2.7 The Role of the NAT Filter ..............................................................................................................................13
2.2.8 Optimizing the Media Path for Symmetrical NAT ..................................................14
2.3 Filter Behaviour ............................................................... 15
2.3.1 Registering without UA Support ..........................................................................................................15
2.3.2 Registering with UA Support .....................................................................................................................16
2.3.3 RTP Relay ....................................................................................................................................................................................18
2.4 Scaling and Redundancy ................................................... 20
2.5 Detecting the right NAT Filter ............................................ 21
2.6 Requirements on User Agents ............................................ 21
2.6.1 Non NAT-Aware User Agents .....................................................................................................................21
2.6.2 STUN/ICE-Aware User Agents ................................................................................................................22
2.7 Defining the Maximum Session Time .................................. 22
3 Installation .....................................................25
3.1 Windows ......................................................................... 25
3.2 Linux ............................................................................. 30
4 Configuration ..................................................33
4.1 Logging In ...................................................................... 33
4.2 Port Binding .................................................................... 33
4.3 System Settings .............................................................. 35
4.3.1 Logging ...........................................................................................................................................................................................35
4.3.2 Preparing Recovery ...................................................................................................................................................36

4 • Contents
[ S N O M 4S NAT FI L T E R ]
4.3.3 General Outound Proxy ......................................................................................................................................36
4.3.4 Media Ports ..............................................................................................................................................................................36
4.3.5 Media Relay .............................................................................................................................................................................37
4.3.6 Controlling Routing ....................................................................................................................................................37
4.3.7 Multiple 2xx Handling ............................................................................................................................................38
4.3.8 Trusted Addresses .......................................................................................................................................................38
4.3.9 Maximum Packet Size ...........................................................................................................................................39
4.3.10 Silence Suppression .................................................................................................................................................39
4.3.11 Connection Oriented Media .........................................................................................................................39
4.3.12 Removing Headers ......................................................................................................................................................40
4.3.13 Codec Control ......................................................................................................................................................................40
4.3.14 Web Server Integration ......................................................................................................................................40
4.4 Timeout Settings ............................................................. 42
4.4.1 Register Timeouts ........................................................................................................................................................43
4.4.2 Call Timeouts ........................................................................................................................................................................44
4.5 Security Settings ............................................................. 45
4.6 Outbound Proxy List ......................................................... 47
4.7 System Information ......................................................... 48
4.8 Server Log ...................................................................... 48
4.9 Trace .............................................................................. 49
4.10 Call History ..................................................................... 50
4.11 Current Ports .................................................................. 51
4.12 Currently Handled UA ....................................................... 52
4.13 Memory Statistics ............................................................ 52
5 Checklist for Installation ................................53
5.1 Linux ............................................................................. 53
5.2 Windows ......................................................................... 53

snom technology AG • 5
1 Overview
Network address translation (NAT) is a reality today. There have
been many discussions about the evil and the good of this network topol-
ogy and the replacement by IP version 6. However, operators and busi-
ness want to offer VoIP services today and therefore must address the
problem.
The snom 4S NAT Filter enables non-NAT aware devices to oper-
ate in private networks. The filter typically operates on a public IP ad-
dress. Non-NAT aware devices are automatically refreshed; NAT-aware
devices that operate behind symmetrical NAT may self-refresh their bind-
ings using the built-in STUN server of the filter, which is operating on the
same address as the SIP application. Devices on public Internet traverse
the filter without changes or refreshes. By supporting Interactive Commu-
nications Establishment (ICE), the number of calls that must go through
the filter can be minimized.
The product also offers recording capabilities (depending on the
licensing). Through a separate management interface, operators can de-
fine numbers and patterns that are silently recorded. Users may explicitly
request the recording of a call by pressing a key on the phone; in this case
the whole call will be recorded (even parts of the call before pressing the
key). The filter records in a compressed format where only the voice part
of the conversation is recorded in highly-compressed audio format (13.2
kBit/s). By using the snom 4S recording studio, operators can manage
very large numbers of calls and, for example, forward them per e-mail to
users or authorities.
The snom 4S NAT Filter is a session border controller. However,
we do not like the term “session border”, because the program neither
controls sessions nor is it on the border of a call. It also does not trans-
late signalling, e.g., from SIP to H.323 or to MGCP. If all user agents are
fully NAT-compliant or on public Internet, the filter can transparently be
removed from the network without changing the call flows or functional-
ity. Also, the filter does not interfere with unknown applications. This is
a tremendous advantage over session border controllers that operate on
the application level.
1.

6 • Overview
[ S N O M 4S NAT FI L T E R ]
1.1 Applications
The filter can be used in the following scenarios:
• Corporations. Corporations which operate their infrastructure be-
hind NAT and/or firewalls can talk to the public Internet through the
filter.
• Operators. Operators offer the NAT traversal feature to their cus-
tomers. Using the scalability feature of the filter, the operation of
large networks becomes possible.
• Record specific calls for legal purposes. In many countries, opera-
tors must provide the possibility to record certain calls on request.
The filter can perform this task.
• Recording can be used for legal proofing (brokers, etc). The filter is
fully compliant with other SIP equipment and can, for example, put
between a PSTN gateway and SIP phones.
1.2 Features
The filter offers powerful features based on modern VoIP
technology:
• The built-in RFC3261-compliant SIP proxy makes additional exter-
nal SIP logic superfluous and simplifies the system setup.
• A built-in RFC3489-compatible STUN server for single IP addresses
allows clients to self-refresh their bindings
• Support for instant messaging, presence and all other SIP-compli-
ant applications.
• Rich logging features allow easy maintenance.
• Recording functions based on number lists and expressions offer a
flexible way of filtering out information.
• Recordings can be saved in WAV file format (the data rate is 6 MB
per hour).
• Almost stateless operation allows the filter to be used in server
farms. This offers a tremendous scalability and redundancy making
the product suitable for large operators.
1.

snom technology AG • 7
[ S N O M 4S NAT FI L T E R ]
• Both http and https as web interface for simple access from
anywhere on the Internet.
• The filter supports Interactive Connectivity Establishment (ICE).
User agents that support this feature will optimize the media path
for the shortest possible delay.
• Media relay is established using connection-oriented media. User-
agents that are not NAT-aware inherently support this feature. This
makes the operation of the NAT filter backward-compatible.
• User agents may self-refresh their bindings. With this feature, bind-
ings can be kept alive even when IP addresses are changed dy-
namically and when the user agent is temporarily available from the
outside.
• Call-alive polling. During calls, the filter checks if the call is still
alive and terminates the call if this should not be the case. With this
feature, charging users for broken calls can be avoided.
• Reliable and unreliable transport layers. The filter supports both
UDP and TCP transport layers. Full TLS support will be added soon.
• To and From headers may be changed for calls. The filter talks to a
web application server to get this information.
• Simple request-routing feature. The web application server can also
change the request-URI. This makes simple routing possible, which
can be used for least cost routing, for example. Usually, the filter
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 filter will not interfere with
applications (instant messaging, presence, weather report, etc).
There are three exceptions to this rule:
• The first exception is a REGISTER request. When a user agent tries
to register and needs the support of the filter, the filter will set up a
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 destined to the user agents will be forwarded
properly.
• The second exception is an SDP attachment. The filter 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.
1.

8 • Overview
[ S N O M 4S NAT FI L T E R ]
• The third exception occurs when the filter queries a web server for
routing information. In this case, it will send a provisional response
to stop the UAC from repeating messages.
These three 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 find the shortest
media path to the other party (peer-to-peer).
Also, please make sure that you have the necessary administrator
rights to run Windows services.
1.

snom technology AG • 9
2 Architecture
2.1 The NAT Filter and SIP
In the SIP architecture, the filter acts as the first proxy that is
contacted by user agents. There are two ways to make sure that the
relevant traffic gets routed trough the filter:
• User agents can be set up to use the filter as outbound proxy. When
using this method, all SIP traffic will flow through the filter, whether
it is destined to the operator or not. That means that service for calls
outside of the operator’s domain may also be serviced by the filter.
However, by redirecting all outgoing traffic of the filter to a proxy
the operator can make sure that the authentication, authorization
and accounting (AAA) requirements for requiring the service are
fulfilled.
• User agents resolve the filter though the RFC3263 DNS resolving
process. That means that only the traffic 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 filter can also
redirect the traffic to another proxy for AAA.
We recommend using the first alternative and to only choose the
second alternative if it is too difficult to provision user agents with the
outbound proxy or when there are concerns about providing service for
foreign operators.
Usually, the filter acts as stateless proxy. This means, that it just
forwards the packets by default and that it does not change the content
of the attachments or the headers themselves. The filter will not interfere
with applications (instant messaging, presence, weather report, etc).
There are three exceptions to this rule:
• The first exception is a REGISTER request. When a user agent tries
to register and needs the support of the filter, the filter will set up a
2.

10 • Architecture
[ S N O M 4S NAT FI 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 destined to the user agents will be forwarded
properly.
• The second exception is an SDP attachment. The filter checks if the
user agent needs support (or must be recorded) and, in that case,
will add a local contact to the SDP that can be used for media re-
lay.
• The third exception occurs when the filter queries a web server for
routing information. In this case, it will send a provisional response
to stop the UAC from repeating messages.
These three 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 find the shortest
media 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 firewalls 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 on how to deal with the problem. This document shows how the
snom 4S filter can be used to solve the problems.
Although snom also makes user agents, the snom 4S filter works
with most SIP user agents from other companies. The requirements on
these user agents are described below.
If you want to use the filter just for recording purposes, you don’t
need to bother about NAT. The filter also works when no NAT is present.
2.

snom technology AG • 11
[ S N O M 4S NAT FI L T E R ]
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
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 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 per-
form this check.
There are some mixed variants between full cone NAT and sym-
metrical NAT. Restricted port NAT works similar to symmetrical NAT, but
uses only one port association.
Hairpinning is the ability of the NAT to route packets coming from
the private network and addressed towards a public IP address binding
back to the private network. Not all routers support this feature.
2.2.2 Symmetrical RTP
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 supporting symmetrical RTP waits for
the first RTP packet coming in and then sends its media stream back to
the IP address from which it received that packet. Symmetrical RTP al-
ways works when the user agent doing 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 traffic 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.
2.

12 • Architecture
[ S N O M 4S NAT FI L T E R ]
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 de-
vices 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.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 Classification of User Agents
From a filter point of view, available user agents can be classified
into the following categories:
• Public IP devices. These devices operate on public IP addresses and
don’t need any specific support regarding NAT. The true location of
these devices may be in a private network, as they might have al-
located a public identity using mechanisms like UPnP™ [3]. These
devices are most welcome as they don’t cause any additional re-
quirements.
• 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 to allocate a public IP address. Often, they are “legacy”
2.

snom technology AG • 13
[ S N O M 4S NAT FI L T E R ]
devices that have been designed without having NAT in mind. These
devices can register only for a short period of time, so that the REG-
ISTER 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 pack-
ets 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.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 in-
clude the private address, an address allocated via STUN, one or more
addresses allocated with the TURN protocol or an address allocated with
UPnP. Because in practice it is hard to predict which of these addresses
are visible to the other user agent, all of the possible addresses are pro-
posed to the other user agent.
The other user agent sends test packets to the possible addresses.
Picking the first 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.
2.

14 • Architecture
[ S N O M 4S NAT FI L T E R ]
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 mes-
sages 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 iden-
tity and reroute the packets to this destination.
While this approach has the huge advantage that it works with
all kinds of NAT, it has the disadvantage that it increases the media path
significantly. For example, when a user A in Tokyo is registered with an
operator in New York and wants to call his colleague B (who is registered
with a service provider in Sydney and sitting in the same office in a private
network), the media would have to flow first from Tokyo to New York, then
to Sydney and then back to Tokyo. Considering the speed of light, the
delay would at least be around one second; in reality it would be much
higher even though 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 starting at 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 is a shorter path, it will switch
to this shorter path. If there is no other way or 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 cases where both user agents are behind symmetrical NAT,
the NAT Filter approach will ensure that media will flow between the user
agents. However, the Tokyo example shows that this might result in intol-
erable media delay.
To address this problem, TURN [5] comes into play. The idea be-
hind 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 automati-
cally 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
(even when there is no direct path between the user agents).
2.

snom technology AG • 15
[ S N O M 4S NAT FI L T E R ]
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 filter does not
interfere with the registering process and just forwards this packet.
If the top Via does not contain the perceived address, the filter
will take care of 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=z9hG4bK-
abx3au3mxb01;rport
From: “denny” <sip:[email protected]>;tag=k9p6fmeg7h
To: “denny” <sip:[email protected]>
Call-ID: 3c26701d7cb9-pady07b5783t@203-145-183-113
CSeq: 14 REGISTER
Max-Forwards: 70
Contact: <sip:[email protected]: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=z9hG4bK-
abx3au3mxb01;rport=17401
From: “denny” <sip:[email protected]>;tag=k9p6fmeg7h
To: “denny” <sip:[email protected]>
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
2.

16 • Architecture
[ S N O M 4S NAT FI L T E R ]
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=z9hG4bK-
abx3au3mxb01;rport=17401
From: “denny” <sip:[email protected]>;tag=k9p6fmeg7h
To: “denny” <sip:[email protected]>;tag=epuy85kzm5
Call-ID: 3c26701d7cb9-pady07b5783t@203-145-183-113
CSeq: 14 REGISTER
Contact: <sip:217.115.141.99:5082;ua=c9b140ab598290e5bb491e9c3aaca44
0>;expires=3600;gruu=”sip:[email protected];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=z9hG4bK-
abx3au3mxb01;rport=17401
From: “denny” <sip:[email protected]>;tag=k9p6fmeg7h
To: “denny” <sip:[email protected]>;tag=epuy85kzm5
Call-ID: 3c26701d7cb9-pady07b5783t@203-145-183-113
CSeq: 14 REGISTER
Contact: <sip:[email protected]:12975;line=lhynyb3y>;expires=360
0;gruu=”sip:[email protected];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 the NAT Filter usu-
ally 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. When the user
agent refreshes the bindings, the port is opened again automati-
2.

snom technology AG • 17
[ S N O M 4S NAT FI L T E R ]
cally.
• 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:[email protected]>;tag=9e9mynnnwa
To: “ Karl Klammer” <sip:[email protected]>
Call-ID: 10f2c240790b-cj4sy7drgp6q@192-168-1-10
CSeq: 2 REGISTER
Max-Forwards: 70
Contact: <sip:[email protected]:5060;line=5zy4hsui>;q=0.7
User-Agent: snom200-2.05h
P-NAT-Refresh: 15
Supported: gruu
Expires: 86400
Content-Length: 0
The NAT Filter will answer this request with a P-NAT-Header:
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.1.10:5060;branch=z9hG4bK-iu90avx18fc6;rport
=34142;received=217.231.163.127
From: “Karl Klammer” <sip:[email protected]>;tag=9e9mynnnwa
To: “Karl Klammer” <sip:[email protected]>;tag=996wctfnen
Call-ID: 2605c340c91d-cj4sy7drgp6q@192-168-1-10
CSeq: 2 REGISTER
Contact: <sip:[email protected]:5060;line=5zy4hsui>;expires=3600;gruu=
”sip:[email protected];gruu=5npko91p”
Server: snom proxy (Unix) 2.42.7
Date: Sun, 06 Jun 2004 11:50:22 GMT
P-NAT-Refresh: 15
Content-Length: 0
2.

18 • Architecture
[ S N O M 4S NAT FI L T E R ]
2.3.3 RTP Relay
When initiating a call, user agents usually include a Session
Description Protocol (SDP) attachment that describes where they expect
media. If the user agent operates on a public Internet address, there is
no need to interfere in this process. In this case the filter will just forward
the request.
Operators should encourage customers to use equipment that
operates on a public Internet address or properly allocates a globally
routable Internet address. Because media relay is an expensive operation,
it reduces the overall load on the network and at the same time increases
the quality of the service.
However, when a user agent is behind NAT, it might not be able
to receive media directly. In some cases this is because the user agent is
simply not programmed to allocate an address properly or because it is
behind symmetrical NAT, which makes it impossible to properly allocate
this address. In this case, the help of the media filter will make sure that
media will always be delivered properly.
The media filter supports the “interactive connectivity
establishment” (ICE) method that has been published recently in the IETF.
2.
Table 1: NAT conbimations
To/From Public IP Full Cone
NAT
Restricted
NAT
Symmetrical
NAT
Public IP Always When
STUN
support is
available
When STUN
and ICE are
available
When STUN
and ICE are
available
Full Cone NAT When
STUN is
available
When STUN
and ICE are
available
When STUN
and ICE are
available
Restricted
NAT
When STUN
and ICE are
available
When STUN
and ICE are
available
and no port
checking
Symmetrical
NAT
Needs filter

snom technology AG • 19
[ S N O M 4S NAT FI L T E R ]
Using this method, user agents may probe several addresses and decide
which address they use for communication. In this case, the filter will just
add another contact to the ICE list.
Table 1 shows the cases when the filter needs to interfere if STUN
and ICE support are available from the user agents. The support of the
filter is necessary only in cases when both sides have symmetrical NAT
and in the case when talking from symmetrical NAT to restricted NAT. If
the user agents don’t support STUN and ICE, the number of cases goes
up significantly.
If the user agent operates without NAT support, it will send a SDP
like the one below:n
v=0
o=root 19387 19387 IN IP4 192.168.1.10
s=call
c=IN IP4 192.168.1.10
t=0 0
m=audio 58146 RTP/AVP 0 8 3 18 2 101
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:3 gsm/8000
a=rtpmap:18 g729/8000
a=rtpmap:2 g726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
The NAT Filter will detect that the user agents needs help and
allocates local ports for relaying media. It will forward the request with
changed SDP:
v=0
o=root 19387 19387 IN IP4 217.115.141.99
s=call
c=IN IP4 217.115.141.99
t=0 0
m=audio 49170 RTP/AVP 0 8 3 18 2 101
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:3 gsm/8000
a=rtpmap:18 g729/8000
a=rtpmap:2 g726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
2.

20 • Architecture
[ S N O M 4S NAT FI L T E R ]
a=silenceSupp:off - - - -
The NAT Filter changes the private address to a globally routable
address and inserts the local port. It also inserts a hint that tells the other
user agent that it should not do silence suppression. This reduces the risk
that the connection is closed during a talk spurt of one of the parties.
2.4 Scaling and Redundancy
The NAT Filter product was designed to support distributed server
farms. That means that the servers act stateless in principle; user agents
may randomly pick a server in a server farm. This feature allows operators
to set up very large and robust networks.
The distribution of user agents to a server is performed using
DNS SRV (RFC 2782). This means that you need to list the available serv-
ers on DNS level; the user agents must perform DNS SRV look ups and
pick one of the servers (possible using the detection algorithms described
below).
The following table shows an example configuration for Linux
named(8):
_sip._udp IN SRV 3 5 5082 frankfurt1
_sip._udp IN SRV 3 5 5082 newyork1
_sip._udp IN SRV 3 5 5082 newyork2
_sip._udp IN SRV 3 5 5082 newyork3
_sip._udp IN SRV 3 5 5082 tokyo2
_sip._udp IN SRV 3 5 5082 tokyo1
If one of the servers should become unavailable, the SRV algo-
rithm will make sure that the other servers will be contacted. The user
agents that are refreshed by that particular server will become unreach-
able until the user agents initiate a new REGISTER request. Therefore,
you should make sure that your servers have a high uptime probability
and that the registration period is not too long. We think that registration
periods of thirty minutes up to one hour are a good balance between ser-
vice failure time and performance.
2.