Solving the Firewall and NAT Traversal Issues for SIP-based VoIP.PDF

Solving the Firewall and NAT Traversal Issues for SIP-based VoIP Yevgeniy Yeryomin

Florian Evers

Jochen Seitz

Technische Universit¨at Ilmenau Germany, 98693 Ilmenau EMail: [email protected]

Technische Universit¨at Ilmenau Germany, 98693 Ilmenau EMail: [email protected]

Technische Universit¨at Ilmenau Germany, 98693 Ilmenau EMail: [email protected]

Abstract— Voice over the Internet Protocol (VoIP) – telephony over the Internet – is gaining popularity. VoIP is an evolving technology that still has several problems. Some of them are caused by network topology, such as the deployment of firewalls and network address translation (NAT). This is referred to as the “NAT and firewall problem”. This paper discusses the problems of SIP-based VoIP. SIP is the most relevant signaling protocol for VoIP today. Unfortunately, a VoIP call cannot be established if one of the SIP softphones is situated behind a NAT gateway or behind a restrictive firewall. A VoIP call involves three random UDP ports for replies that must be allowed. This can be problematic due to security reasons. In this paper, we present a software suite that solves the aforementioned problems. This “SIP-RTP-Proxy” (SRP) works as a “Session Border Controller” (SBC) by accepting and relaying SIP signaling data and RTP / RTCP media data. A special feature of this solution is the possibility to place the SRP inside a private network, while former solutions such as SBCs have to be installed directly on the NAT gateway or in the public Internet. One goal of this project was to develop a universal solution that solves the NAT problem for VoIP in small business and home environments. It can be used in combination with various operating systems and does not depend on modified clients or a modified “Internet Protocol Private Branch Exchange” (IP PBX).

I. I NTRODUCTION Voice over IP (VoIP) is an attractive technology for business and private customers. The reasons are lower prices, an easier installation and a cheaper maintenance compared to the “plain old telephony system” (POTS). One important aspect of VoIP for many business customers is the possibility to use the currently available IP-based network to carry phone calls. Unfortunately, there are some drawbacks, such as a lower security and reliability when compared to POTS. Other problems arise from the network topology. For example, NAT gateways and firewalls are applied to real-world network devices. This causes some critical problems regarding SIP-based VoIP, which are known as the “NAT and firewall problem”[1], [2]. These problems can be divided into three parts: • the NAT problem for SIP communication, • the NAT problem for RTP (and RTCP) media data and • the firewall problem. Several solutions are available, but they are either providercentric or require additional software that must be installed directly on the NAT gateway. In this paper, another solution

is presented that is related to “Session Border Controllers” (SBCs). In contrast to them, our software suite can also be installed on a different PC that resides somewhere in the private subnet. This paper is structured as follows: Section 2 provides an overview of the NAT problem of SIP and RTP. Existing solutions are described and analyzed. In section 3 and 4, another solution for the NAT and firewall problem is presented. It builds on the “SIP-RTP-Proxy” (SRP) software suite that was developed by us. In Section 5, the structure and the functionality of the SRP are shown. Section 6 describes the testbed and discusses the measured results. Section 7 deals with further developments regarding the SRP and section 8 concludes this paper. II. T HE NAT AND FIREWALL PROBLEM A SIP-based VoIP network consists of two or more SIP softphones and a central IP PBX with SIP support (the SIP proxy / registrar). The signaling messages (SIP and the “Session Description Protocol”, SDP) are directed to the PBX. The media data (RTP and RTCP) are usually exchanged directly between softphones without passing the PBX. A. The NAT and firewall problem for SIP VoIP communication does not operate properly if a NAT gateway or a firewall has to be passed. The UDP packets containing the SIP response messages arriving from the PBX cannot reach the SIP softphones in the private network. SIP requires two simplex UDP associations for outgoing SIP requests and incoming SIP responses respectively. Unfortunately, NAT gateways do not allow the establishment of incoming UDP associations. The SIP responses are unable to reach the SIP softphone. This problem is known as the “NAT problem for SIP communication” [2]. However, this problem can be solved with “SIP Symmetric Response Routing” (SIP-SRR) that has to be activated at the PBX. Then the SIP softphone and the PBX use one single fullduplex UDP association [2]. This association is established from within the private network and passes the NAT gateway. B. The NAT and firewall problem for RTP / RTCP After the NAT problem for SIP is solved, signaling via SIP runs smoothly. However, another similar problem appears

c 2008 IEEE 978–1–4244–2036–0/08/$25.00

Authorized licensed use limited to: Jyvaskylan Ammattikorkeakoulu. Downloaded on October 16, 2008 at 05:16 from IEEE Xplore. Restrictions apply.

that affects RTP-based media data (see fig. 1). Although the RTP packets coming from within the private network (from softphone 1) reach softphone 2 in the public Internet, the RTP packets from softphone 2 cannot reach softphone 1. This happens because the RTP packets are sent to the address of softphone 1, and this IP address is a private IP address. It was embedded in a SIP message created by softphone 1, and softphone 1 had no information regarding a valid public IP address. This problem causes the VoIP communication to run in simplex mode. Softphone 2 is able to “hear” softphone 1, but softphone 1 cannot receive voice data from softphone 2. Private network

NAT

5060

SIP request

INVITE SDP 10.8.0.6:X

Softphone 1 10.8.0.6 private address

Public Internet

IP PBX

88.88.88.88 public address

SIP

X

SIP request

INVITE SDP 10.8.0.6:X

SIP

RTP

UDP destination port: X IP destination address: 10.8.0.6

Softphone 2 99.99.99.99 public address

Fig. 1. The NAT problem for RTP communication during a call. Softphone 1 sends the address of its RTP socket (10.8.0.6:X) to softphone 2 via a SIP / SDP INVITE-request. The PBX relays this INVITE-request to softphone 2, which reads a useless private IP address.

C. Existing solutions for the NAT problem for RTP Unfortunately, softphones in private subnets are unable to recover a usable public IP address and UDP port number. This pair is defined by the NAT gateway. There is no possibility for the softphones to recover these parameters by themselves. However, there are solutions that cope with this problem: SIP-SRR has already been explained in this paper. “Symmetric RTP” works in a similar manner and is considered to be a preliminary step in order to solve the NAT problem for media data [2]. Symmetric RTP is an option for SIP softphones to accept and send RTP packets on one single full-duplex UDP association. This mechanism is important for the traversal of NAT gateways. Unfortunately, it is not able to solve the NAT problem without additional efforts. Other mechanisms are “Interactive Connectivity Establishment” (ICE), “Simple Traversal of UDP through NAT” (STUN), “Traversal Using Relay NAT” (TURN) and “Universal Plug and Play” (UPnP) [2]. They solve the NAT problem, but lead to further problems. These technologies use dedicated protocols, which have to be supported by the SIP softphones. ICE, STUN and TURN rely on dedicated servers in the public Internet (provider-centric). STUN does not work with symmetric NAT. A VPN may be rolled out in order to circumvent the NAT problem. Here, all SIP softphones and the PBX reside inside a shared private subnet. Unfortunately, this scheme is hard to maintain in world-wide scenarios.

“Application Layer Gateways” (ALGs) [3] are another popular approach. They consist of a dedicated software suite that runs directly on the NAT gateway. However, not all NAT gateways allow the installation of additional software, especially commonly used dial-up network router do not offer this possibility. Another solution is offered by media-proxies for SIP-based VoIP. The OpenSER software suite offers a media proxy module. In Asterisk, one can deactivate the “canreinvitemode” [4]. In these schemes, “Symmetric RTP” is used and the RTP packets run through a media proxy entity at the PBX. Only inbound full-duplex RTP associations are used by the PBX in order to send RTP packets to the softphones. These associations are established by softphones that reside behind NAT gateways. This approach solves the NAT problem, but is a provider-centric solution. Additional components have to be installed in the public Internet and cause additional costs for the providers. The next popular solution involves “Session Border Controllers” (SBCs) [1]. They are interesting because of their similarities regarding our “SIP-RTP-Proxy” (SRP). Such a SBC acts as a “Back to Back User Agent” (B2BUA). This is usually a combination of hardware and software which is placed on the borders of networks (gateways) or in the public Internet. They allow the traversal of a NAT gateway without depending on modifications of the SIP softphones. However, SBCs cannot be placed within private a network of the customer and thus form another provider-centric solution. In the next section, our own approach to solve the NAT problem for VoIP is presented. This solution builds on a software developed in by us, the “SIP-RTP-Proxy” (SRP). The SRP can be installed directly on a NAT gateway or on a dedicated PC inside the private network. This offers a nonprovider-centric solution without the requirement of additional components in the public Internet.

Softphone

Softphone

Proxy server with SipRtpProxy

Internet

Softphone Hub

Dial-up network router with NAT

Other PC’s

PBX

Fig. 2. The SRP solves the NAT problem for SIP-based VoIP in home use scenarios. The SRP resides on a machine inside the private network here. Alternatively, it could be deployed directly on the NAT gateway, but commonly available off-the-shelf dial-up network router do not allow this. In the presented scenario, only two UDP port forwarding rules have to be applied to the NAT gateway. All signaling and media data from the SIP softphones pass the SRP.

Authorized licensed use limited to: Jyvaskylan Ammattikorkeakoulu. Downloaded on October 16, 2008 at 05:16 from IEEE Xplore. Restrictions apply.

III. S OLVING THE NAT P ROBLEM FOR VO IP The SRP is a signaling and media gateway for SIP softphones that resides in a private network. All signaling and media data pass the SRP, and the SRP assures that the NAT problem is solved. This mechanism does not require any modifications to the SIP softphones, the NAT gateway or the PBX. Fig. 2 shows the deployment of a SRP entity in a common home use scenario. In order to solve the NAT problem, the “SIP-RTP-Proxy” was designed to • intercept all SIP, RTP and RTCP packets, • sort and modify them (→ session management) and • relay them between all SIP softphones and the PBX. In order to offer a non-provider-centric solution, the SRP may reside on a NAT gateway or on a dedicated PC inside the private network, as shown in fig. 2. When residing in the private network, two UDP forwarding rules (ports 5070 and 5071) have to be activated at the NAT gateway (see fig 3). The SRP acts as a PBX and media gateway to softphone 1 and softphone 2 (both inside the private network). From the point of view of the external softphones 3 and 4 as well as the PBX (all located in the public Internet), the SRP behaves like a SIP softphone. All SIP signaling messages pass the SRP. The SRP modifies the IP addresses and port numbers that are embedded in the SIP messages. This assures that all subsequent associations for media data (RTP and RTCP) also pass the SRP. Both the PBX and the SIP softphones in the public Internet communicate only via the SRP if “private” softphones are addressed. Private network

Public Internet IP PBX

NAT

5060 Softphone 1 Softphone 2

SIP

RTP SIP RTP

5060

SI P

P SI

SipRtpProxy SIP RTP RTP

5070

RTP RTP

SIP

Softphone 3

Softphone 4

5070

Fig. 3. The SRP is used as a signaling and media gateway. Here, two VoIP calls between four softphones are established. SIP-SRR is activated at the PBX. All SIP and RTP packets pass the SRP. The content of each SIP message is modified during traversal in order to direct all subsequent media data associations (RTP and RTCP) through the SRP. This solves the NAT problem for media data. Only two dedicated UDP ports for all softphones and VoIP calls are used in order to solve the firewall problem.

A softphone in the public Internet that wants to send media data to a softphone behind a NAT has to know the public IP address of the NAT gateway and the two UDP ports that are forwarded there. These two static forwarding circuits relay all inbound UDP packets to the SRP. Here, they are accepted and relayed to the corresponding softphone in the private network. The NAT problem for RTP is solved. The SRP supports SIP signaling with activated SIP-SRR (see fig. 3) and without (see fig. 4). Without activated SIPSRR, a second UDP association in simplex mode is involved. It is used by the PBX in order to send SIP messages back to

the SRP. The destination address for this reverse association is extracted from the first SIP message arriving from the SRP. This is always port UDP 5070 at the NAT gateway. Here, a forwarding circuit is activated and no outgoing keep-alive packets are necessary. Inbound packets do not depend on valid NAT table entries but pass through UDP port forwarding circuits defined at the NAT gateway. Private network

Public Internet NAT

SipRtpProxy

X SIP SIP

5070

5070

IP PBX SIP

5060

SIP

Fig. 4. If SIP-SRR cannot be activated at the PBX, SIP signaling works as presented. The SRP transmits outbound UDP packets through a randomly chosen port X at the NAT gateway. Inbound UDP packets arriving from the PBX are sent to port UDP 5070 at the NAT gateway. This port is forwarded to the SRP. The use of keep-alive packets is not necessary, but the SRP requires the public IP address of the NAT gateway. This IP address cannot be discovered without further efforts. As a consequence, the IP address must be static and has to be provided to the SRP manually.

IV. S OLVING THE F IREWALL P ROBLEM FOR VO IP The “firewall problem” for VoIP arises if one applies a firewall to SIP softphones, a SIP PBX or a NAT gateway. On the one hand, it is required that a wide range of UDP ports is allowed at each softphone and at the NAT gateway. On the other hand, one is interested in minimizing the amount of UDP ports that are allowed because of security reasons. To solve this conflict, the range of possible UDP ports used for VoIP calls has to be reduced. This is especially important if port forwarding rules have to be applied to a NAT gateway. The SRP requires only two non-changing UDP ports that have to be opened at a firewall. In our testbed, the UDP ports 5070 and 5071 are used in order to accept UDP packets arriving from the public Internet (see fig. 3). The SRP accepts all UDP packets that are directed to these ports. Due to the fact that all possible kinds of UDP packets may arrive, the SRP examines the payload and the source address of each packet. Afterwards, they are sorted with regard to the protocol (SIP, RTP or RTCP) and the corresponding SIP session. Only valid packets that were assigned to existing SIP sessions are allowed to pass the SRP. All other packets are discarded. V. S TRUCTURE OF THE SRP A. Client side and server side The SRP is divided into two logical parts, a client and a server related side. For each side, only two UDP ports are used, independent of the amount of softphones that use the SRP. The first UDP port is used for SIP and RTP, and the second UDP port is dedicated to RTCP. These UDP ports have to be adjacent: The RTCP port number is calculated by

Authorized licensed use limited to: Jyvaskylan Ammattikorkeakoulu. Downloaded on October 16, 2008 at 05:16 from IEEE Xplore. Restrictions apply.

incrementing the given RTP port number by one. Each side of the SRP can have its own IP address (when running on a NAT gateway) or they share the same IP address (when being placed on a dedicated PC inside a private network or in the public Internet). The SRP has to be configured in terms of IP addresses and UDP port numbers for both sides. Additionally, the address of a PBX has to be provided. For the client side, the UDP port pair 5060 / 5061 was chosen in order to accept associations from softphones that reside within the private network. This client side of the SRP acts as a SIP PBX and as a media gateway. It is designed to communicate directly with softphones inside private networks and accepts associations for SIP, RTP and RTCP. UDP port 5060 is used for all SIP and RTP associations and UDP port 5061 is used for RTCP. Softphones inside the private network reach the SRP by addressing its private IP address in combination with the UDP port 5060. The server side of the SRP communicates with a PBX (SIP) and with other softphones (RTP / RTCP). Again, a dedicated UDP port (5070) is accepting RTP associations arriving from the softphones. The adjacent UDP port (5071) is used for RTCP. UDP port (5070) is also used for SIP. Here, one single UDP association is directed to the PBX, and SIP messages of all SIP sessions are multiplexed through the same association. The SRP assigns each incoming SIP message to its corresponding SIP session object internally. The SRP uses SIP-SRR and “Symmetric RTP”. All associations are used in full-duplex mode. The softphones in the public Internet reach the SRP by using the public IP address of the NAT gateway in combination with the UDP ports 5070 and 5071. B. Relaying of signaling and media data The SRP accepts and modifies all SIP messages accepted from the softphones inside the private network and relays them to a preconfigured PBX. SIP messages that are arriving from the PBX are accepted and assigned to the corresponding SIP session internally. Here, they are also modified and relayed to a softphone behind the NAT afterwards. The structure of the SRP shown in fig. 5. The main component of the SRP is the SIP session class. It handles signaling and media data. The SRP creates a separate SIP session object for each SIP softphone that associates itself to the SRP. This happens when the first SIP-REGISTER message arrives. The SIP session object remains valid as long as the SIP softphone is registered. When a call is being established, the SRP starts to relay RTP and RTCP packets. Media data by softphones behind NATs are relayed to the external softphone and vice-versa. Another core component are the packet classifiers. They are responsible for assigning incoming packets to existing SIP session objects (session management). SIP is a text-based protocol that can be parsed easily. SIP messages arriving from the PBX are assigned to the corresponding SIP session by evaluation of the embedded Call-ID, the tag-fields and the user name. Each SIP session object maintains a list of

identifiers of active SIP dialogs. Regarding media data, only the source address of each incoming RTP / RTCP packet has to be examined. These source addresses are known to one of the SIP session objects. This information was previously extracted from the SIP-INVITE and SIP-OK messages during the establishment of the call. During the call, the RTP and RTCP packets are relayed without modification of their payload. Private network

SipRtpProxy

Public Internet

SIP sessions 5060

5070

SIP

SIP

to PBX

to internal softphones

RTP

RTP

5061

5071

RTCP

to external softphones

RTCP packet classifier

Fig. 5. The main parts of SRP are the SIP session objects and the packet classifiers. Each SIP session object contains six handlers that deal with SIP, RTP and RTCP packets arriving from both sides. The packet classifiers assign incoming packets to their corresponding SIP session object. Here, they are parsed, modified and relayed.

C. Management of IP addresses The SRP has to know its public IP address. This address is necessary in order to formulate outgoing SIP-INVITE requests. This is feasible when the SRP resides directly on the NAT gateway (that is the reason why other SBCs and B2BUAs have to be installed directly on NAT gateways). Further problems may occur if the SRP is installed on a dedicated PC within a private subnet. Three scenarios are possible: At first, the public IP address of the NAT gateway could be configured at the SRP. Unfortunately, this is only feasible if this IP address is static and remains unchanged over time. As an alternative, the SRP can discover the public IP address by using SIP-SRR. Then the PBX embeds the source address it received the SIP requests from (the public IP address of the NAT gateway) into the payload of the SIP replies (received field) [5]. Unfortunately, this mechanism fails if the public IP address changes over time and SIP-SRR was not activated at the PBX. In the third solution, a mechanism similar to STUN could be used in oder to discover the public IP address of the NAT gateway. When passing the SRP, all IP addresses embedded in SIP messages are parsed, recorded and manipulated. All private IP addresses of softphones behind NATs are replaced with the server side IP address of the SRP. SIP messages arriving from the PBX are treated equally. Here, the IP addresses are replaced with the IP address and port numbers of the client side of the SRP. VI. T ESTBED AND M EASUREMENTS A testbed has been set up and some tests have been carried out in order to analyze the performance and the capabilities

Authorized licensed use limited to: Jyvaskylan Ammattikorkeakoulu. Downloaded on October 16, 2008 at 05:16 from IEEE Xplore. Restrictions apply.

TABLE I M EASURED ROUND - TRIP TIME WITH AND WITHOUT USING SRP

Without SRP With SRP Difference/RTT caused by SRP

Min. [ms] 1.002 1.212 0.210

RTT (G.711) Max. [ms] 2.472 14.487 12.015

Avr. [ms] 1.171 5.078 3.907

Min. [ms] 0.538 0.581 0.043

RTT (G.729) Max. [ms] 2.824 17.101 14.277

Avr. [ms] 0.666 6.365 5.699

TABLE II M EASURED JITTER WITH AND WITHOUT USING SRP

Without SRP With SRP Difference/Jitter caused by SRP

Jitter (G.711) Max. [ms] 1.135 8.599 7.466

of the SRP. The testbed is shown in fig. 6. In our test environment, the SRP runs on a computer with an Intel Pentium M processor running at 1500 MHz. The operating system is Gentoo GNU/Linux. This PC is connected to the our universitynetwork and to a private LAN. Thus, the SRP is installed directly on a NAT gateway. A total of 20 softphones is installed on two Microsoft Windows based PCs. 10 softphones run on a PC that resides in the public Internet and the other 10 softphones run on a second PC that resides in the private network behind the NAT gateway. We use the SIP softphone X Lite by CounterPath. The Asterisk software suite is used as a SIP server (PBX). A. Stress test All 20 softphones were used simultaneously. The softphones behind NATs were configured to use the SRP as their PBX. The remaining ten softphones were running on a PC in the public Internet. Ten calls have been established and were served simultaneously. The audio codecs G.711 (64 kbps) and G.723 (6.3 kbps) were tested. We transferred authentic speech data in order to trigger the voice activity detection of the codecs. The CPU utilization was obtained by the GNU/Linux tool top. Here, the average CPU usage of the SRP was at about 0.7 percent. This is a very small load. It shows that the relaying of RTP / RTCP data is a very cheap task in terms of CPU usage. NAT

PBX

Private network

10.8.0.1:5 Gateway 060NATGateway SIPRTPProxy NAT-Gateway Server SIP, RTP and RTCP Client side eth0 ethside Softphone 1-10 0 10.8.0.1

Internet

SIP 88.88.88.88 SIP

eth1

RTP and RTCP

Softphone 11-20

77.77.77.77

Fig. 6. Our testbed used for measurements consists of a private network (shown on the left side) and the public Internet (shown on the right side). Both networks are interconnected by a NAT gateway. The NAT gateway is a full fledged GNU/Linux-based PC. The SRP is running on the NAT gateway itself. 10 softphones are running on a PC in the private network. An additional set of 10 softphones is running on a PC that is situated in the public Internet.

Avr. [ms] 0.016 3.379 3.3635

Jitter (G.729) Max. [ms] 1.059 9.655 8.596

Avr. [ms] 0.0305 5.511 5.481

B. Quality of Service A QoS test has been carried out in order to check the impact to the voice quality. Measurements with regard to additional delay, jitter and packet loss have been performed. We used the RTP traffic generator rtpSend and SIPp as SIP clients. An entity of rtpSend was running on a computer inside the private network and was used as a RTP packet generator. SIPp was running on a PC in the public Internet. The NAT gateway and the PC running SIPp were both situated in our university network. Here, SIPp was used as an echo server for RTP packets that reflected all incoming RTP packets back to the generator. Two audio codecs were used, G.711 with a high bitrate (64 kbps) and G.729 with a low bitrate (8 kbps). Two different RTP data flows were generated by rtpSend containing a VoIP call of 80 seconds duration. All RTP packets were captured on both computers (see fig. 7) by the dumpcap tool. The round trip time (RTT), jitter and packet loss were extracted from the log files. In order to measure the influence of the SRP to the RTP traffic, two tests were performed: At first, all parameters were measured without an entity of the SRP applied. Later, an entity of SRP was introduced and all tests were repeated. In the first run, the RTP packets were generated by RtpSend and sent through the NAT gateway directly to SIPp. Here, the RTP packets were accepted and sent back through the NAT gateway (involving the NAT table entry) to rtpSend. In the second run, the RTP packets were sent through the SRP. Here, the RTP packets were accepted at UDP port 5060. The SRP relayed them to the SIPp entity in the public Internet. SIPp reflected all incoming RTP packets back to the NAT gateway (to UDP port 5070) where they were accepted by the SRP again. Finally, the RTP packets were relayed to the rtpSend entity running on the computer behind the NAT. Each test was performed 10 times and than average min and max values were noted. This second testbed is illustrated in fig. 7. No packet loss was observed. The measured values of round trip time and jitter are shown in the tables I and II. SRP does not affect the voice quality noticeably. The round trip delay is about 5.7 ms higher if an entity of SRP is applied. The SRP causes an additional delay of 2.85 ms per direction. This

Authorized licensed use limited to: Jyvaskylan Ammattikorkeakoulu. Downloaded on October 16, 2008 at 05:16 from IEEE Xplore. Restrictions apply.

Private network RTP

rtpSend

10.8.0.6

Gateway

5060

SIPRTPProxy

10.8.0.1

dumpcap

NAT

Public Internet 5070

77.77.77.77

SIPp

(RTP echo) 99.99.99.99

dumpcap

Fig. 7. Another testbed was used in order to perform QoS tests. An entity of RtpSend sends RTP packets through the SRP to an entity of SIPp. Here, the RTP packets are reflected. On their way back, the RTP packets pass the SRP again and finally reach RtpSend. On both PCs, all RTP packets were captured by dumpcap.

is acceptable by the ITU-T G.114 recommendation [6] which allows a maximum one-way delay of 150 ms. Furthermore, the average jitter increases to 5.5 ms (see table II), which is an acceptable value that fits into the recommended maximum jitter of 25 ms. The SRP supports multiple simultaneous VoIP calls. The CPU load measured was at about 0.7% for 20 softphones and 10 VoIP calls served simultaneously. This is an acceptable value for the considered home usage and small business solutions. The SRP does not influence the quality of a VoIP call noticeably during normal use. VII. O UTLOOK AND FUTURE WORK The primary purpose of the SRP is the solution of the NAT and firewall problem for VoIP without the necessity to install additional software on NAT gateways or in the public Internet. This is presented in this paper. However, we had further plans beside the solution of the aforementioned problems. Thus, we decided to implement a “SIP Session Border Controller”-style software suite from scratch. Concretely, the SRP was developed in order to extend it to a solution for “Fixed Mobile Convergence” (FMC) afterwards. Additionally, we aimed for integration of the SRP functionalities into the middleware-based vertical handover solution REACH. This combination yielded support for SIPbased VoIP in mobility-enabled environments. A. A solution for “Fixed Mobile Convergence” An FMC network is currently being developed in our department. The main part of this architecture is an FMC server, which is in fact the successor of the SRP. The FMC server offers an access point for FMC users and enables SIP-based handovers. Handovers from circuit switched telephony (GSM) to packet switched VoIP and vice-versa are possible [7]. B. Handover-aware VoIP in Mobility-Enabled Environments Furthermore, we are currently developing the “RoamingEnabled Architecture” (REACH). It offers a middleware-based solution that supports vertical handovers in IP-based networks of any kind. Special plugins for miscellaneous handover mechanisms such as VPN-based schemes [8] are provided.

Unfortunately, SIP-based VoIP was not supported yet because the protocols of VoIP are too complex for the existing data capturing schemes [9]. The content of the SIP messages has to be manipulated in a similar manner as presented in this paper. We planned to extend the SRP to a REACH relay plugin that can be loaded into the REACH core. Such a relay plugin would support VoIP calls in handover-enabled environments [10]. C. SRP in the public Internet The SRP may be placed in the public Internet in order to offer a signaling and media gateway. This scheme is able to solve the NAT problem for softphones behind NAT gateways if one is unable to roll out the SRP. However, our purpose was to offer a solution that is not provider-centric. D. Conclusion The FMC solution and the relay plugins for REACH were successfully finished in the meantime. These efforts would not have been possible without the SRP as their predecessor. The mechanisms that allow the SRP to be installed on any PC inside private networks were missing in SBCs and B2BUAs but are essential for the mentioned enhancements. VIII. S UMMARY In this paper, the “SIP-RTP-Proxy” (SBC) is presented. It offers a software-based solution that solves the NAT and firewall problem for SIP-based VoIP. In contrast to related solutions such as SBCs and B2BUAs, the SRP does not have to be installed directly on a NAT gateway or in the public Internet. Instead, it can be deployed on any PC within a private network. Only two port forwarding rules have to be activated at the NAT gateway. No further support or modifications regarding the SIP softphones, the PBX or other network components are necessary. The SRP can be used in small businesses or home network scenarios. The software was implemented and tested in a testbed that represents real-world network topologies. R EFERENCES [1] “NAT Traversal for Multimedia over IP Services - White Paper,” 2006, http://www.newport-networks.com/whitepapers/nat-traversal1.html. [2] “NAT Traversal for VoIP and Internet Communications using STUN, TURN and ICE,” Eyeball Networks Inc., Tech. Rep., 2007. [3] P. Srisuresh and M. Holdrege, “IP Network Address Translator (NAT) Terminology and Considerations.” Request for Comments 2663, 1999. [4] J. V. Meggelen, J. Smith, and L. Madsen, Asterisk: The Future of Telephony. O’Reilly, Sept. 2005. [5] J. Rosenberg and H. Schulzrinne, “An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing.” Request for Comments 3581, 2003. [6] “Recommendation G.114 - One-way Transmission Time,” 1999, http: //www.itu.int/itudoc/itu-t/aap/sg12aap/history/g.114/index.html. [7] Y. Yeryomin and J. Seitz, “Universal Enterprise FMC Solution,” in ICEIS Doctoral Consortium (DCEIS 2007), Funchal, Madeira, Portugal, 2007. [8] F. Evers and J. Seitz, “A VPN-driven Infrastructure for Vertical Handovers,” in IEEE Sarnoff Symposium 2006, Princeton, New Jersey, 2006. [9] ——, “REACH: A Roaming-Enabled Architecture for Multi-Layer Capturing,” in IEEE Wireless Communications and Networking Conference 2008 (WCNC 2008), Las Vegas, NV, USA, 2008. [10] F. Evers, Y. Yeryomin, and J. Seitz, “Handover-aware SIP-based VoIP provided by a Roaming-Enabled Architecture (REACH),” in IEEE Sarnoff Symposium 2008, Princeton, New Jersey, 2008, submitted.

Authorized licensed use limited to: Jyvaskylan Ammattikorkeakoulu. Downloaded on October 16, 2008 at 05:16 from IEEE Xplore. Restrictions apply.