Snom 4S NAT Filter Admin Manual

© 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. 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.

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.....................................................................................................................22 2.6.2 STUN/ICE-Aware User Agents................................................................................................................22 2.7 Defining the Maximum Session Time .................................. 22 3 Installation.....................................................23 3.1 Windows......................................................................... 23 3.2 Linux ............................................................................. 28 4 Configuration..................................................31 4.1 Logging In ...................................................................... 31 4.2 Port Binding .................................................................... 31 4.3 System Settings .............................................................. 33 4.3.1 Logging ...........................................................................................................................................................................................33 4.3.2 Preparing Recovery ...................................................................................................................................................34

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

1 Overview Network address translation (NAT) is a reality today. There have been many discussions about the evil and the good of this network topology and the replacement by IP version 6. However, operators and business that want to offer VoIP services today and they must address the problem. The snom 4S NAT Filter enables non-NAT aware devices to operate in private networks. The filter 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 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 Communications 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 define 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 Email to the 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 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 filter can transparently be removed from the network without changing of the call flows or functionality. Also, the filter does not interfere with unknown applications. This is tremendous advantage against session borders controllers that operate on the application level. 1.

[ S N O M 4 S N A T F I 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 client 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.

[ S N O M 4 S N A T F I 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, bindings can be kept alive even when IP addresses are changed dynamically 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 e.g. for least cost routing.sually, 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 that are destined to the user agents will be forwarded properly. • The second exception is a 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.

[ S N O M 4 S N A T F I 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.

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, 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 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 only choose the second alternative if it is too difficult to provision the user agents with the outbound proxy or there are concerns about providing service for foreign operators. 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 2.

[ S N O M 4 S N A T F I L T E R ] 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 that are destined to the user agents will be forwarded properly. • The second exception is a 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. • 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 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.

[ S N O M 4 S N A T F I 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 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 first 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 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.

[ S N O M 4 S N A T F I 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 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.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 allocate a public IP address. Often, they are “legacy” 2.

[ S N O M 4 S N A T F I 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 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 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.

[ S N O M 4 S N A T F I 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 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 significantly. 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 office in a private network), the media would have to flow first 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 flow 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 2.

[ S N O M 4 S N A T F I L T E R ] 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 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 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=z9hG4bK- abx3au3mxb01;rport From: “denny” ;tag=k9p6fmeg7h To: “denny” Call-ID: 3c26701d7cb9-pady07b5783t@203-145-183-113 CSeq: 14 REGISTER Max-Forwards: 70 Contact: ;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” ;tag=k9p6fmeg7h To: “denny” Call-ID: 3c26701d7cb9-pady07b5783t@203-145-183-113 CSeq: 14 REGISTER Max-Forwards: 69 2.

[ S N O M 4 S N A T F I L T E R ] Contact: 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=z9hG4bK- abx3au3mxb01;rport=17401 From: “denny” ;tag=k9p6fmeg7h To: “denny” ;tag=epuy85kzm5 Call-ID: 3c26701d7cb9-pady07b5783t@203-145-183-113 CSeq: 14 REGISTER Contact: ;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” ;tag=k9p6fmeg7h To: “denny” ;tag=epuy85kzm5 Call-ID: 3c26701d7cb9-pady07b5783t@203-145-183-113 CSeq: 14 REGISTER Contact: ;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 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. 2.

[ S N O M 4 S N A T F I L T E R ] • 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” ;tag=9e9mynnnwa To: “ Karl Klammer” Call-ID: 10f2c240790b-cj4sy7drgp6q@192-168-1-10 CSeq: 2 REGISTER Max-Forwards: 70 Contact: ;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” ;tag=9e9mynnnwa To: “Karl Klammer” ;tag=996wctfnen Call-ID: 2605c340c91d-cj4sy7drgp6q@192-168-1-10 CSeq: 2 REGISTER Contact: ;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.

[ S N O M 4 S N A T F I 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

[ S N O M 4 S N A T F I 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. Only in cases when both sides have symmetrical NAT and in the case when talking from symmetrical NAT to restricted NAT the support of the filter is necessary. 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: 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.

[ S N O M 4 S N A T F I 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). That means, you need to list the available servers 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 algorithm will make sure that the other servers will be contacted. The user agents that are refreshed by that particular server will become unreachable until the user agents initiate a new REGISTER request. Therefore, you should make sure that you 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 service failure time and performance. 2.

[ S N O M 4 S N A T F I L T E R ] 2.5 Detecting the right NAT Filter User agents must detect which server in the server farm is nearest to the user agent. This is an important feature for a company or operator that has user agents scattered around the globe. Example: A company has offices in Berlin, Tokyo and Dallas and locally operates NAT Filter servers. When a user agents is located in Tokyo, it should use the Tokyo server. This could be set up manually; however it is also possible to automatically pick the best server. To detect the nearest server the user agent sends STUN packets to all possible servers (the servers with the lowest priority in the SRV list). The user agent picks the server that responds first. Alternatively, the user agent could send more test packets and take the mean response time for making the decision. The snom 4S NAT Filter includes a STUN server that operates on the SIP UDP port. User agents should send their test packets to the SIP port. 2.6 Requirements on User Agents Generally, there are two categories of user agents: The non NAT aware user agents and the STUN/ICE capable user agents. 2.6.1 Non NAT-Aware User Agents Non-NAT aware user agents must at least fulfill the following features: 1. Must send SIP UDP packets from the port where they receive SIP traffic 2. Must start sending media immediately after receiving SDP Requirement 1 is not fulfilled by the default configuration of the Cisco 7960; however there is a setting that enables this feature. Most known user agents support this feature, however. Requirement 2 gives sometimes problems with user agents that don’t send media during silent periods. In this case, users have to start speaking before two-way audio can be established. 2.

[ S N O M 4 S N A T F I L T E R ] In any case, customers are asked to contact their vendor in case of problems and explanations. As a general remark, snom recommends to use NAT-aware user agents to reduce the network overhead and support overhead. 2.6.2 STUN/ICE-Aware User Agents STUN/ICE-Aware User Agents must implement the two IETF standards. It is ok if the user agents use the built-in STUN server for refreshing the bindings and learning the public IP address. snom phones fall into this category starting with version 2.05a. snom phones starting with version 2.05g support the self-refresh feature using the P-NAT-Refresh header. 2.7 Defining the Maximum Session Time There are a couple of timeout related settings that terminate a call when certain events fire (see below). However, when prepaid cards are being used, operators want to limit the call duration to a certain time. The filter has a mechanism to terminate calls anyway. It does not only send BYE messages to both sides of the call, it also cuts media relaying which practically will be used in most cases when the call is terminated via PSTN. This feature can be used to tear down calls when a card expires. The remaining call duration depends not on a static setting, but a dynamically provisioned parameter. This parameter is usually provided in the AAA procedure in the proxy. The proxy needs a simple way to tell the filter how many seconds this call can stay up. We decided to add a proprietary header called “P-Session- Timeout” to the filter. When this filter is detected in a message that belongs to an existing call, the filter sets the timeout for this call to the value provided in the header (in seconds). After this time the filter will terminate the call with the reason “Maximum Session Duration” (see below, Call History). By the setting for trusted IP addresses, the filter will accept these headers only from explicitly listed addresses. After the header has been 2.

[ S N O M 4 S N A T F I L T E R ] used, the filter removes it from the packet so that the user agent will not see this header. If the proxy wants to provide information about how long the call can stay up, it should use AOC information. snom can help on implementing this feature in networks on demand. 2.

3 Installation If you want to install the product on your own, this chapter will provide you with the necessary information. 3.1 Windows The Windows version of the NAT Filter comes with an InstallShield application that should make the installation very simple for you. Before you start the installation, you might want to make sure that the necessary ports are available on you machine. Please use the 3.

[ S N O M 4 S N A T F I L T E R ] netstat command to check which ports are being used on that machine. You can change the ports later; however you should at least make sure that you can access the administration web interface of the NAT Filter with an open port. Also, please make sure that you have the necessary administrator rights to run Windows services. To start the installation, simple double-click on the installation executable. You will see the Welcome screen of the installation dialog. To continue the installation read the text and click the Next button. It will guide you to the license agreement page. To continue the installation, please read the license agreement. If you agree with the license conditions, select the “I accept the terms in the license agreement” selection box and click on the Next button. If you do not agree with the conditions, you can cancel the installation by clicking the Cancel button. 3.

[ S N O M 4 S N A T F I L T E R ] If you agree with the license agreement, the next screen will ask you to enter the license conditions and select the ports of the NAT Filter. The hostnames are a list of host identifications that identify this installation. Typically, it is the list of DNS FQHN names for the used host. You will receive the license code from the company where you bought the product. Please make sure that the code is correct (copy & paste). If you don’t have a license key, NAT Filter will automatically generate a trial license key for you for a limited period of time. If you wish to use this mechanism, please leave the License Code field empty. The SIP port will be used for communication of the NAT Filter with the outside world. The program will only open a UDP port as other transport layers like TCP or TLS are not supported. The http and the https ports are important for you at it is the only way to administer the NAT Filter. Please select a port number that suits your needs. The default ports are 80 (http) and 443 (https). If you 3.

[ S N O M 4 S N A T F I L T E R ] forget the port number, you need to look it up later using the netstat command. After entering the license information and the port numbers, the InstallShield program will ask you for the installation directory. Typically it proposes a reasonable directory; however you may change the directory using the Change button in this installation dialog. After you have entered the necessary information, the last dialog will ask you to start the installation. You will see a progress indication. The installation typically takes only a few seconds. The installation includes the registration of the NAT Filter with the Windows Services Manager. The next time when you reboot the machine, Windows will automatically start the NAT Filter. This is independently of a user login; this is important when you run the service on a server. After the installation, the service is not started automatically. You can now either reboot to verify that the automatic starting is working or 3.

[ S N O M 4 S N A T F I L T E R ] you may manually start the application using the services manager. The last InstallShield dialog offers you to start the NAT Filter. If you choose this option, you don’t have to go to the services manager. To see the NAT Filter service, go to the Control Panel, Select the Administrative Tools and double click on Services. You will see the list of services, including the snom 4S NAT Filter. If you select the properties menu entry, you will see the Properties dialog for the NAT Filter. The NAT Filter does not require and start parameters, therefore you should not make any changes in the dialog. If you do not want that the NAT Filter is started automatically, you can modify the Startup type to manual. 3.

[ S N O M 4 S N A T F I L T E R ] 3.2 Linux After you downloaded the desired RPM you may install it either with graphical front end of your distribution for installing additional software or as root via the command line. If you do it via command line ‘rpm -ihv snom*.rpm’ entered as user root in the directory where the RPM is stored should install the RPM into your system. The process is not started automatically after the installation, like it was with the old snom software packages, because RPM’s can not be 3.

[ S N O M 4 S N A T F I L T E R ] installed with user interaction. Thus the software is installed with default values for the HTTP and SIP ports. Please verify first if the default values in /etc/syconfig/snom* match with your local requirements, before you start the process as usual with /etc/init.d/snom* (or rcsnom* under SuSE). 3.

4 Configuration 4.1 Logging In First of all, you need to log in to the server (see figure 2). The default login name is “admin” and there is no password set (you should change this if it has not already been done for you). The login creates a session. This session will timeout after a cer- tain time (by default, one hour). 4.2 Port Binding You need to tell the server on what ports it should listen. 4.

[ S N O M 4 S N A T F I L T E R ] For http and https, you need to know these port numbers when you want to log in. We recommend not using the standard ports. Operat- ing a server on the public internet usually leads to a lot of denial of service attacks on the standard ports. For sip, you must decide if you want to run the server on a stand- ard port or a random port. Standard Port Random Port • User Agents that don’t support DNS SRV can automatically find the server • SIP-aware firewalls automatically take care about user agents behind NAT • Buggy SIP-aware firewalls don’t introduce new problems by modifying SIP packets • Less dangerous for DoS attacks • Several SIP services can be run on the same host The decision depends on the situation. If you plan to use a good SIP firewalls, you should choose the standard port. Otherwise we would tend to recommend a random port. Non NAT-aware user agents usually must be configured manually anyway; in this case you can also provide a port number. The port for secure sip (sips) is usually 5061. The decision what port to use is similar to the decision for the SIP port. We recommend using a random port and publish the port number using DNS SRV. 4.

[ S N O M 4 S N A T F I L T E R ] In some situations, if you have several IP addresses you want to limit the bindings to a specific IP address. You can do this by selecting the appropriate address from the pull down menu. If you choose „Default Address“, the server will bind to all available addresses. If you select „Public Address“, the server will select a public address; if you select „Private Address“, the server will select a private address. 4.3 System Settings 4.3.1 Logging The Log Level defines the granularity with which messages are written into the log. A log level 0 means that only the most urgent messages are written, a log level of 9 means that all possible log messages are written. If the Log Filename is set, all log messages are also written to the indicated file. If the file name contains a dollar character, the dollar will be replaced with the current date. Using this method, the NAT Filter will write a log file for every day. This way you can keep a certain history of log files and remove them from the file system as soon as you think the information contained there is not relevant any more. 4.

[ S N O M 4 S N A T F I L T E R ] The Log Length number indicated how many log entries the NAT Filter should keep in internal memory. The NAT Filter writes log messages in the first-in-first-out principle, so that there is no memory leak caused by log messages. The log messages written to the log file are not affected by this setting. 4.3.2 Preparing Recovery You should specify a file name, so that the NAT Filter can Save Registrations to File. The filter will append a XML line for each registration that is being refreshed to a file that has the same name as the registration file appended with a tilde symbol (for example, if you specify “regs.xml”, it will write it to “regs.xml~”). After the Registration Logging Time (see in timeout handling below, in seconds) the filter will move the tilde file to the main file. When the server is restarted it will read both files and this way restore the registration status on the filter. This allows the continuation of the service without waiting for the user agents to reregister. This interval should be longer than the maximum time that you give user agents for reregistration. 4.3.3 General Outound Proxy The Outbound Proxy indicates where messages that are not coming from a UA behind NAT should be sent. Typically, this is the address of the proxy that handles the traffic for the domain the NAT Filter is responsible for. The outbound proxy is a SIP URI, that means it has the format sip:host. If the host contains a number behind a semicolon (like in “sip: proxy.com:5060”), the NAT Filter will just do a DNS A query on the address. Otherwise, it will follow RFC3263 (Locating SIP Servers) to find the proxy. If you use DNS SRV, you can put a server farm behind the NAT Filter. Because the NAT Filter itself can be operated in a server farm, you can set up a completely redundant server setup. Please see also the list of explicit outbound proxies. 4.3.4 Media Ports The Media Port Begin and Media Port End indicate the range of ports that are used for media relaying. Be sure to have enough ports allocated for the number of calls that you wish to route through the 4.

[ S N O M 4 S N A T F I L T E R ] NAT Filter. This is a setting that you might have to coordinate with your firewall. 4.3.5 Media Relay If you set the Always Relay flag, the filter will always relay media via the filter and does not allow bypassing it by ICE contacts. That means it will remove ICE contacts from the SDP and not insert an additional address for it self. This flag is useful when you want to make sure that all media flows through the filter, e.g. for measurement purposes or because you want to be able to record all calls. However, it will not be possible to do local media path optimization if you turn this flag on. 4.3.6 Controlling Routing The Loose Routing flag influences the way that the NAT Filter inserts routing headers into SIP packets. Loose routing is the routing mechanism that is proposed in the latest SIP document; however there are devices which are not able to deal properly with these routing headers (the new standard is not backward compatible with the old standard). The Hide Routing flag will replace route sets with a unique route index when requests or responses are sent to a registered user agent. Via headers are also replaced with one Via header. This feature has several advantages. First, it will reduce the packet size significantly, especially when your core network uses several proxies or loops requests through the proxy several times. Usually, UDP packets will have a size significantly below the MTU size of 1492 bytes for Ethernet. This is a tremendous advantage that solves many problems with equipment that does not support UDP fragmentation. Second, it hides important information about your network topology from the user agents. For example, when you are terminating calls with a PSTN gateway, the users are not able to see the IP address of the PSTN gateway in the routing path (if you turn always relay on, this address will also not occur in the SDP). Users will only “see” the filter as the only window to the outside world. This makes attacks much more difficult. It is much easier to protect only the filter against attacks than you whole SIP network. The third big advantage is that is solves many problems with poor SIP implementations. Typically, immature SIP implementations can not 4.

[ S N O M 4 S N A T F I L T E R ] deal properly with strict and loose routing which results in complicated routing problems. The filter will take care about the routing problems, the user agent just has to route the request to the filter, which even the poorest implementations are able to do. The disadvantage with this flag is that it adds more stateful information to the filter. The stateful does not affect the scalability of the overall system, but when restarting the filter, the information gets lost. However, we recommend turning this flag on. 4.3.7 Multiple 2xx Handling The Filter INVITE 2xx deals with another problem that many poor SIP implementations have. In SIP, it is allowed to fork requests to several user agent servers. Several user agents sending a 2xx response back to the UAC at the same time typically creates a race condition. The proxy that is involved in this transaction cannot cancel the pending requests fast enough to solve this situation. The SIP designers have made the design decision that in this situation, all 2xx responses must be sent back to the UAC which has to resolve the condition. Unfortunately, only a small percentage of existing user agents deal properly with this situation. When you turn the flag on, the filter will only let the first 2xx response pass through to the user agent. Subsequent 2xx responses will be blocked by the filter; instead the filter will send an ACK to the response and immediately terminate the dialog with a BYE message. This is the behaviour that most user agents do when receiving multiple 2xx. However, if you are sure that the user agents in your network handle multiple 2xx properly and implement a different behaviour, you should turn this behaviour off. 4.3.8 Trusted Addresses The list of Trusted IP Addresses is used when sensitive information is extracted from SIP packets. For example, the filter may get an explicit hint on how long the conversation may last at maximum. If a user agent would send this information, it could easily bypass AAA and make telephone calls even when the prepaid card already expired. If you list the IP addresses of your proxies, you can enhance the security significantly. 4.

[ S N O M 4 S N A T F I L T E R ] 4.3.9 Maximum Packet Size The Max MTU tells the filter what the maximum packet size should be. Typically, on Ethernet networks, packets with more than 1492 bytes payload cannot be transported without splitting them up into several packets. As described in the hide routing feature, this can lead to big problems in today’s DSL networks. If you set this variable, the NAT filter will attempt to compress the message until it fits into the size. By default, it will use the short names (e.g. “l” instead of “Content-Length”). If this should not be enough, it will start to remove headers. These headers are: “User-Agent”, “Accept- Language”, “P-Key-Flags”, “Allow”, and “Allow-Events”. If the packet is still too big, it will stop compressing the packet and send it as it is. If you want to remove other headers, please use the “remove the following headers” feature described below. 4.3.10 Silence Suppression Silence suppression is a little bit problematic for the filter. If a user agent does not send media, which might lead to closing of allocated NAT ports on the media. Therefore, it is usually safer to turn silence suppression off. We recommend doing this by provisioning the respective setting to the user agents; however there is a way to indicate this in the SDP as well. If you turn the Add silence suppression flag on, the filter will add this hint to the SDP. Usually it does not cause any additional problems; however it makes the packet a little bit bigger which could cause additional problems with the UDP fragmentation problem. 4.3.11 Connection Oriented Media Typically, you want two-way communication between the same ports in a conversation. Unfortunately, the IETF specifications do not mandate this. For example, it is allowed to have different port for sending and for receiving data. This causes big problems when trying to make phone calls trough NAT. The comedia approach tries to standardize the requirements on using the same port for sending and receiving and to indicate if two-way communication is really desired. By turning the Add comedia flag feature on, you will make the filter add a suitable flag to SDP to indicate that this behaviour is desired. The disadvantage of this 4.

[ S N O M 4 S N A T F I L T E R ] flag is again that it makes the messages bigger and this increases the probability that you will have problems with UDP fragmentation. 4.3.12 Removing Headers As stated before, you may want to remove some headers to make messages shorter. The Remove the following headers setting lists the headers (separated by space) that you want to strip from a SIP packet. This setting does not only help you in making the packets shorter, it can also help you to keep some parts of the SIP message secret. For example, you might want to remove P-Asserted-Identity headers from all SIP messages, because you don’t want others to see which identities you already checked. 4.3.13 Codec Control In many environments, you want to exclude codecs from being used although both communication partners could agree on them. The Allow only the following codecs setting lists (separated by space) the codecs that you will allow. If you don’t set anything here, all codecs will be allowed. The codecs must be written in their SDP name, for example “ulaw”, “alaw”, “gsm”, “g729”, “g723”, etc. This feature can be used for example to make sure that only low- rate codecs are being used. The user agents might otherwise agree on ulaw, which might lead to breaking voice if the bandwidth is not sufficient for a stream using ulaw. 4.3.14 Web Server Integration The filter supports the integration of a web server. Before a call is established the filter may change the to- and from-header content and the request-URI. Changing the to- and from header has several advantages. First, it allows inserting the display name to a plain telephone number. If you have a database where you can retrieve this information, you can make your web server look this information up. Second, you can change the outgoing identity and hide the true identity of the caller. This is sometimes helpful when you want a certain number been called back, e.g. in the case when you have several alias names for an account. 4.

[ S N O M 4 S N A T F I L T E R ] Changing the request-URI makes it possible to do simple routing decisions in a very convenient way on a web server (e.g. using PHP scripting). This can be used for least cost routing, but it can also be used for load balancing and redirecting calls to announcements for example if the prepaid card has expired already. The filter almost becomes a proxy with this feature. The filter talks asynchronously to the web server. That means, the processing of other requests is not blocked by the request. Also the processing of other web requests is also not blocked by another web request. The request is only made at the beginning of a call; further messages inside the call will not cause additional web requests. The request is only made on INVITE-initiated dialogs. The address of the web server must be entered into the Consult http URL before starting call field. Please use the complete form, including the http:// in front of the host name. The filter supports only DNS A resolution for locating the web server; no http proxy is allowed. Before the filter sends out the web request to the URI the filter automatically appends some parameters to the URI: • The parameter “action” is always set to the value “start”. This will make sure that future extensions are possible. • The parameter from_uri is set to the URI in the from header. The display-name and parameters outside of the URI are not available. Parameters inside the URI are available. • The parameter to_uri is set to the URI in the to header. • The parameter uri is set to the value of the request-URI. All parameters are URL-encoded according to the rules of the http protocol. A possible request might look like this: http://snom.com/ post.htm?action=start&from_uri=sip:[email protected]&to_uri=sip: [email protected]&uri=sip:[email protected] (possible escape characters are not shown here for simplicity). While the web request is pending, all subsequent requests will go into a wait queue (including CANCEL). This will make sure that all requests are processed in the right sequence. The filter will evaluate the body of the response to the request. If the response has an error code higher than or equal to 300, it will not evaluate the result and just continue processing. You will see a log 4.

[ S N O M 4 S N A T F I L T E R ] message at level 5 (“Web callback: Code 200 for [email protected]”) on every response that the filter receives, it shows the response code and the call-id. The format of the body has a simple line-oriented format. Each line contains a parameter name and a parameter value. The parameter value and the name are separated by a colon, just like in most http and sip requests. Line break escapes like in SIP are not allowed. All parameters are optional; if not present nothing is changed. The following parameters are allowed: • “from”: This parameter contains the new value for the from-header. It may include the display name, therefore the corner bracket style must be used. Example: from: “1234” • “to”: Same for to-header. • “uri”: The new value for the request-URI. The filter copies the content like it is into the request-URI. Therefore, it must contain the scheme (usually, “sip”) and no corner brackets. Example: uri: sip: [email protected] For programming your web server, please consult your web server manual. Samples and advice are available from snom on demand. 4.4 Timeout Settings In contrast to previous versions, the time related settings have been summarized on this new management web page. The filter differentiates between registration related settings and call related settings. 4.

[ S N O M 4 S N A T F I L T E R ] 4.4.1 Register Timeouts The Refresh Interval for the UA is the number of seconds between NAT refreshes from the NAT Filter. The NAT Filter keeps track of registered user agents and keeps their NAT port binding with packets alive. Typically, a port timeout is 60 seconds; however because this value must handle the smallest timeout. Therefore, a value of 15 seconds seems more appropriate. The filter sends the keep-alive packets regardless of the transport layer. Although on TCP most implementations keep the connection alive for a much longer time, some implementations close their ports after a short timeout. Therefore, also TCP connections must be refreshed. You may use two different methods for the refreshing. If you Use OPTIONS for refresh, the filter sends out OPTIONS SIP requests to the registered user agents. This method has much more traffic overhead than other methods. But it is the only one that ensures compatibility with existing implementations and guarantees that the user agent sends something back from the inside NAT. This is important in some NAT types as they do not allow refreshing NAT bindings from the outside. If you turn the flag off, the filter will send short white space packets to the registered user agent. 4.

[ S N O M 4 S N A T F I L T E R ] The value directly influences the keep-alive traffic caused by the NAT Filter. The Registration Logging Time is the time after which it moves the backup file to the primary location. See preparing recovery above. 4.4.2 Call Timeouts Unfortunately, in SIP little attention has been put on the problem when a user agent just disconnects from the network without further notification. This situation typically occurs on power failure, system crash or when the Internet connection becomes unavailable. In these cases the filter needs to disconnect the call. Even more unfortunate, there is not a single way that this problem can be addressed. Therefore, the filter uses several mechanisms that check if the call is still alive. The first way to find out if the call is still alive is to send OPTIONS requests to the user agents that are directly connected to the filter. The OPTIONS are sent outside of the dialog, because sending them inside the dialog would cause a sequence numbering problem. If no response is coming back, that is an indication that the user agent is not connected any more (the reverse it not necessarily true: some user agents boot up so fast that options responses might be returned in time). The Refresh Interval tell the filter after how many seconds it should send; the No Response Timeout tells the filter how long it should wait for a response. If there is absolutely no media, this is also a fairly good indication that the call is over. The setting No Media Timeout defines how many seconds the filter tolerates calls without media. This setting only applies of any media has been received at all. That means if you for example start a instant messaging session without any media, the filter will not remove this session because of a media timeout. Another famous case is one way audio. Imagine a user agent calling a mailbox and then crashing/rebooting. The media server will play one-way audio possibly for a long time. Because of this scenario, we added the One-Way Audio Timeout. In contrast to the no media timeout, this setting only looks at audio media. This timeout is also only started upon reception of the first media packet. This setting should consider that some user agents do silence suppression. Please keep in mind that some users are very quiet and don’t say anything for a relatively long time. However, 4.

[ S N O M 4 S N A T F I L T E R ] a conversation where someone does not say anything for more than five minutes should be extremely seldom. Another famous problem in SIP is to detect when the call is really over. In SIP, it is possible to challenge a request and wait for a relatively long time until the challenge is answered (for example, if the user has to answer the challenge by entering some data). If the challenged request is not answered after a certain timeout, the filter assumed that the call is over and will not start again. The setting Timeout for Unestablished Calls addresses this problem. Please keep in mind that ringing the phone also falls into this category. Therefore, you should pick a value significantly higher than sixty seconds for this setting. One the other hand, every call attempt will stay in memory until this time is over. If you have many call attempts, you should keep this setting as low as possible. We believe that a value of 120 seconds is reasonable in most situations. If the call has been accepted by receiving a 2xx on INVITE, it will probably last for a relatively long time without any signalling refreshes. Unfortunately, in SIP the session timer is not mandatory and has not been implemented in most of the user agents. Therefore, the filter cannot expect refresh traffic on the call. The setting Timeout for Established Calls defines the maximum duration that you accept without any SIP traffic. In other words this is the maximum conversation time that you accept without any SIP traffic. The other timeouts do not stop the filter from hanging up because of this setting. Therefore, you should pick a reasonable time like four hours for this value. Typically this setting will only be needed for calls that don’t have any media at all and where one of the user agents gets disconnected without notice. However, this setting is necessary to make sure that such calls do not fill the filter over time and reduce the number of available calls. 4.5 Security Settings If you want to restrict access to the web interface of the NAT Filter, you may select the https radio button in the Web Access setting. If you don’t care, you can leave the setting to http/https. If you want ex- clude https access (for example, to save performance), select http. 4.

[ S N O M 4 S N A T F I L T E R ] To restrict the login, you should set a username („admin“ is the default) and a password. You need to enter the password twice, so that typing mistakes do not block your NAT Filter. The Session Timeout is the number of seconds after which the NAT Filter web server deletes the session. If you access the web server after this time, you need to log on again. If you change the password dur- ing a session, you do not have to enter the new password for the existing session. If you have bought a certificate, you may upload that certificate from the web page. Just point the NAT Filter to the file and press the Load button. Otherwise, the server will use a default certificate that you trigger a security warning popup when you enter the web page. However, as the server is not open to public access, we think this is not so important. 4.

[ S N O M 4 S N A T F I L T E R ] 4.6 Outbound Proxy List In addition to the previously mentioned outbound proxy you may specify a number of dedicated outbound proxies. This feature is typically being used in the following scenarios: • Integration of PSTN gateway. If you set the outbound proxy of the PSTN gateway to the filter, it can easily redirect all requests to the proxy. However, when the proxy wants to route a call back through the filter, it must know that the request must be routed to the PSTN gateway. If you set up a DNS name for the PSTN gateway and set the destination to the filter, you can elegantly redirect all outgoing calls to the PSTN gateway trough the filter first. BTW the filter can then take care about such problems like UDP fragmentation and multiple 2xx responses. • Replace PSTN gateway with other gateways, for example ITSP service or IP gateways. • Multiple-Domain hosting: If you are using several proxies for different domains, the filter can redirect the requests automatically to the right proxy. This approach is limited to maximum ten domains per filter; for more domains you need to use the web server integration mentioned above. 4.

[ S N O M 4 S N A T F I L T E R ] The algorithm for searching the outbound proxy is simple. The filter first goes through to the list of outbound proxies and tries to match the hostname in the request-URI of the request to the provided Domain. If it does not find any match, it will take the outbound proxy in the general settings (if provided). If it does find a match, it will replace the hostname part of the request-URI with the Replacement and then send it to the Outbound Proxy. Note that like in all routing decisions, the filter fully supports RFC3264; that means transport layer (tcp, tls, udp) and final destination are determined through DNS NAPTR, SRV and A lookups. 4.7 System Information In the system information you can check the exact build number and the license type. Also we included license information on this web page. 4.8 Server Log This web page shows the log information that is kept in the mem- ory (see above). It is independent from the logging information written to the log file. You find two links that clear the log. Please remember that press- ing the reload button on the web browser asks the NAT Filter to clear the log again. To refresh, you should press the link for refreshing the log. For your convenience, these links are available at the top and the bottom of the page. 4.

[ S N O M 4 S N A T F I L T E R ] 4.9 Trace The NAT Filter keeps a list of the last trace entries in memory. You may see this list by selecting the trace link. The handling of the page is similar to the handling of the log page. Each line contains an abstract of the received or sent packet. The Time column shows you when the packet has been sent or received. The Type shows if the packet has been sent or received; in particular, „Tx“ means the packet has been sent normally from the NAT Filter, “Tr” means the packet has been sent as message repetition, “Td” means the packet was sent to a UA behind NAT, “Rx” means the packet was received normally, “Rr” means the packet was received as a message repetition. 4.

[ S N O M 4 S N A T F I L T E R ] The Source/Destination indicates the IP address where the packet was sent or received. The Header column contains the abstract. By clicking on the header link, you may see the complete packet. 4.10 Call History The call history should help you to understand what’s going on on your system. It is not intended to be an AAA feature. The call history lists the last 32 calls. Each entry lists the to and from header (only the URI part). The start field shows when the call started with its first packet. This time is not identical with the time when the call was established, this is usually a little bit later. The reason field shows the reason why the call was terminated. • The reason “BYE” indicates that the call was terminated because of explicit hang-up. This is the case for normal, successful calls. • The reason “No 200 Ok” is typical when calls have not been picked up (call attempt). • The reason “media timeout” indicates that the call was terminated because of a media timeout. • The reason “OPTIONS” indicates that there was no response to an OPTIONS request. • The reason “Maximum Session Duration” indicates that the session 4.

[ S N O M 4 S N A T F I L T E R ] was terminated because the maximum session time has been reached. This time is indicated by the P-Session-Timeout header. 4.11 Current Ports It is important to see which calls are active on the filter. The Current Ports web page lists the calls where the filter performs relaying on media. The from and to-field show which participants are involved in this media relay. The start column shows you when the port was created. In the destinations field the user may see more information about how the different streams in the SDP are mapped. Each line consist of information about one stream. The number in bold before the stream shows the stream index. If that stream has been mapped to another stream, the number in bold behind the colon indicates to what stream it has been mapped. The number behind the space shows the index in the SDP. Because a conversation can have more than one SDP, the index usually occurs in several places. The indexes are matched by their value, according to their position in the SDP. The next number in bold shows the port number. The next field shows the default destination that was indicated in the SDP. If the destination has not been locked, that address is shown in brackets and the list of learned addresses is shown after it. An address is locked when the NAT Filter received a packet on this port from the location indicated in the SDP. 4.

[ S N O M 4 S N A T F I L T E R ] 4.12 Currently Handled UA This table shows the currently handled UA with their SIP URI and their associated IP address. The third column shows the SIP request type that this binding is using. Typically, this will be a REGISTER or SUBSCRIBE request. User agents may have more than one entry. In this case, they might have dangling registrations on the registrar; this typically happens when the call-id is changed during a re-registration. From the NAT Filter point of view, this is no reason for concern. It is ok if user agents show up several times. This typically indicates that the user agent tries to register several times, possibly on different proxies or after rebooting. The logic of the filter will make sure that only one refresh per destination occurs. Please remember that calling this web page on a large installation would block the system for a potentially long time. Therefore, we limited the display to the first hundred registered user agents. You will see three dots at the bottom of the screen. If you want to check which user agents are registered on your system, you should check the registration log file instead. 4.13 Memory Statistics This web page shows information about the current memory usage. The primary goal is to identify situations when the process grows more than expected. Usually, the NAT Filter process should not take more than five megabytes. 4.

5 Checklist for Installation When snom or one of their partners perform the installation for you, the following information is necessary: 5.1 Linux • Please provide secure shell login to the system that can be ac- cessed at least from the snom.com host (currently at IP address 217.115.141.99). • Please tell us the login address (host and port), user name and password. We need root permissions on that host. • Please tell us for what domains you plan to use the server. Please also tell us where you want to process the requests (which outbound proxy to use for NAT Filter). • Please don’t run too many other services on that host that can degrade the performance of the server. We recommend using the server only for NAT Filter. • Please tell us what ports you want to use for NAT Filter (SIP, http, https). We recommend not using the standards ports, as they some- times trigger inappropriate actions on immature equipment. • Please set your DNS SRV records for SIP up so that they point to the NAT Filter SIP UDP port. Please don’t use other transport layers than UDP. Do not set up DNS SRV records for TCP or TLS. 5.2 Windows • Please make sure that we can access the host from the Internet. Please ask the installation team if they support a remote administra- 5.

[ S N O M 4 S N A T F I L T E R ] tion tool. • Please tell us the login address (host and port), user name and password. We need administrative rights on that host. • Please tell us for what domains you plan to use the server. Please also tell us where you want to process the requests (which outbound proxy to use for NAT Filter). • Please don’t run too many other services on that host that can degrade the performance of the server. We recommend using the server only for NAT Filter. • Please tell us what ports you want to use for NAT Filter (SIP, http, https). We recommend not using the standards ports, as they some- times trigger inappropriate actions on immature equipment. • Please set your DNS SRV records for SIP up so that they point to the NAT Filter SIP UDP port. Please don’t use other transport layers than UDP. Do not set up DNS SRV records for TCP or TLS. References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, „SIP: Session Initiation Protocol“, IETF, RFC 3261, June 2002, http://ietf.org. [2] Rosenberg, J., Weinberger, J., Huitema, C., Mahy, R., „STUN - Sim- ple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)“, IETF, RFC3489, March 2003, http: //ietf.org. [3] UPnP™ Forum, http://www.upnp.org/ [4] Rosenberg, J.: “Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Multimedia Session Establishment Protocols” (Internet draft), http: //ietf.org/internet-drafts/draft-ietf-mmusic-ice-02.txt [5] Rosenberg, J., Mahy, R., Huitema, C.: “Traversal Using Relay NAT (TURN)” (Internet draft), http://www.ietf.org/internet-drafts/draft- rosenberg-midcom-turn-05.txt 5.

Pascalstr. 10B, 10587 Berlin, Germany Phone: +49 (30) 39833-0 mailto:[email protected] http://www.snom.com sip:[email protected] © 2004 snom technology AG All rights reserved.