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

Solving the Firewall and Traversal Issues for SIP-based VoIP Yevgeniy Yeryomin Technische Universität Ilmenau Germany, 98693 Ilmenau EMail: yevgeniy.yeryomin@tu-ilmenau.de Florian Evers Technische Universität Ilmenau Germany, 98693 Ilmenau EMail: florian.evers@tu-ilmenau.de Jochen Seitz Technische Universität Ilmenau Germany, 98693 Ilmenau EMail: jochen.seitz@tu-ilmenau.de 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 (). This is referred to as the 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 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 gateway or in the public Internet. One goal of this project was to develop a universal solution that solves the 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. INTRODUCTION 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, gateways and firewalls are applied to real-world network devices. This causes some critical problems regarding SIP-based VoIP, which are known as the and firewall problem [1], [2]. These problems can be divided into three parts: the problem for SIP communication, the 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 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 problem of SIP and RTP. Existing solutions are described and analyzed. In section 3 and 4, another solution for the 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. THE 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 and firewall problem for SIP VoIP communication does not operate properly if a 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, 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 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 gateway. B. The and firewall problem for RTP / RTCP After the problem for SIP is solved, signaling via SIP runs smoothly. However, another similar problem appears 978 1 4244 2036 0/08/$25.00 c 2008 IEEE

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. SIP request SIP SIP public 88.88.88.88 INVITE SDP10.8.0.6:X SIP address request Public INVITE Internet SDP10.8.0.6:X 5060IP PBX private 10.8.0.6 address UDP IP destination port: address: X10.8.0.6 public address Fig. 1. The 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. Softphone 1X RTP Softphone 99.99.99.992 C. Existing solutions for the 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 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 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 gateways. Unfortunately, it is not able to solve the problem without additional efforts. Other mechanisms are Interactive Connectivity Establishment (ICE), Simple Traversal of UDP through (STUN), Traversal Using Relay (TURN) and Universal Plug and Play (UPnP) [2]. They solve the 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. A VPN may be rolled out in order to circumvent the 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 gateway. However, not all 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 gateways. This approach solves the 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 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 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 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 SoftphoneSipRtpProxy server with Other HubPC s Dial-up router with network PBX Internet Fig. 2. The SRP solves the 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 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 gateway. All signaling and media data from the SIP softphones pass the SRP.

III. SOLVING THE PROBLEM FOR VOIP 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 problem is solved. This mechanism does not require any modifications to the SIP softphones, the gateway or the PBX. Fig. 2 shows the deployment of a SRP entity in a common home use scenario. In order to solve the 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 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 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. SipRtpProxy 5060 IP PBX SIP SIP Public Internet SIP RTP SIP SIP 5060 5070 RTP RTP Softphone 1 Softphone 2 SIP RTP RTP 5070 RTP Softphone 3 Softphone 4 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 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 has to know the public IP address of the 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 problem for RTP is solved. The SRP supports SIP signaling with activated SIP-SRR (see fig. 3) and without (see fig. 4). Without activated SIP- SRR, 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 gateway. Here, a forwarding circuit is activated and no outgoing keep-alive packets are necessary. Inbound packets do not depend on valid table entries but pass through UDP port forwarding circuits defined at the gateway. SipRtpProxy Internet 5060 PBX SIPPublic 5070 SIP SIP X 5070SIP 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 gateway. Inbound UDP packets arriving from the PBX are sent to port UDP 5070 at the 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 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. SOLVING THE FIREWALL PROBLEM FOR VOIP The firewall problem for VoIP arises if one applies a firewall to SIP softphones, a SIP PBX or a gateway. On the one hand, it is required that a wide range of UDP ports is allowed at each softphone and at the 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 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. A. Client side and server side V. STRUCTURE OF THE SRP 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

incrementing the given RTP port number by one. Each side of the SRP can have its own IP address (when running on a 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 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 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 s 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 SIP modification sessions of their payload. SipRtpProxy Public Internet softphones to internal RTP packet classifier RTCP RTP SIP to PBX softphones to external SIP5060 5070 RTCP 5061 5071 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 gateway (that is the reason why other SBCs and B2BUAs have to be installed directly on 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 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 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 gateway. When passing the SRP, all IP addresses embedded in SIP messages are parsed, recorded and manipulated. All private IP addresses of softphones behind s 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. TESTBED AND MEASUREMENTS A testbed has been set up and some tests have been carried out in order to analyze the performance and the capabilities

TABLE I MEASURED ROUND-TRIP TIME WITH AND WITHOUT USING SRP RTT (G.711) RTT (G.729) Min. [ms] Max. [ms] Avr. [ms] Min. [ms] Max. [ms] Avr. [ms] Without SRP 1.002 2.472 1.171 0.538 2.824 0.666 With SRP 1.212 14.487 5.078 0.581 17.101 6.365 Difference/RTT caused by SRP 0.210 12.015 3.907 0.043 14.277 5.699 TABLE II MEASURED JITTER WITH AND WITHOUT USING SRP Jitter (G.711) Jitter (G.729) Max. [ms] Avr. [ms] Max. [ms] Avr. [ms] Without SRP 1.135 0.016 1.059 0.0305 With SRP 8.599 3.379 9.655 5.511 Difference/Jitter caused by SRP 7.466 3.3635 8.596 5.481 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 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 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 s 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. Private 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 SIP, RTP RTP network and / RTCP10.8.0.1:5 060 Internet data is a very cheap task in terms of CPU usage. eth 0Client sidesiprtpproxy -Gateway 77.77.77.77 Server eth0 eth1siprtp 88.88.88.88SIP PBX and RTCP Softphone 1-10 Softphone 11-20 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 gateway. The gateway is a full fledged GNU/Linux-based PC. The SRP is running on the 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. 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 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 gateway directly to SIPp. Here, the RTP packets were accepted and sent back through the gateway (involving the 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 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. 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

Private Public Internet 10.8.0.6 RTP network Gateway rtpsend5060 SIPRTPProxy 10.8.0.1 77.77.77.77 5070 99.99.99.99 (RTP SIPp echo) dumpcap 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. OUTLOOK AND FUTURE WORK The primary purpose of the SRP is the solution of the and firewall problem for VoIP without the necessity to install additional software on 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 Roaming- Enabled 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 problem for softphones behind 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. SUMMARY In this paper, the SIP-RTP-Proxy (SBC) is presented. It offers a software-based solution that solves the 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 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 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. REFERENCES [1] Traversal for Multimedia over IP Services - White Paper, 2006, http://www.newport-networks.com/whitepapers/nat-traversal1.html. [2] 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 () 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.