sip-based enterprise converged networks for voice/video-over-ip

IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 23, NO. 10, OCTOBER 2005 1921

SIP-Based Enterprise Converged Networks forVoice/Video-Over-IP: Implementation and

Evaluation of ComponentsSamir Chatterjee, Member, IEEE, Bengisu Tulu, Student Member, IEEE, Tarun Abhichandani, Student Member, IEEE,

and Haiqing Li, Student Member, IEEE

Abstract—The next generation of enterprise networks is under-going major changes as a plethora of new architectures, applica-tions, and services begin to roll out within businesses. In general,the world of voice/telephony, video, and data are “converging”into a global communications network. The purpose of this paperis twofold. First, the design, analysis, and performance of a sessioninitiation protocol (SIP)-based videoconferencing desktop client,which has been developed and deployed over Internet2, is pre-sented. Second, a guideline for managing SIP-based services to bedeployed within enterprises, which addresses several challenges ineach layer, such as network address translator (NAT)/FW issues,directory service integration issues, and interoperability issues, isproposed. Several detailed experimental results related to inter-operability and conformance that were carried out are presented.Findings of extensive SIP/NAT traversal analysis through networktraffic measurements are reported. The lessons learned from boththe design of a new SIP-based voice/video client, as well as man-agement challenges with enterprise deployment are highlighted.

Index Terms—Architectures, middleware, security, sessioninitiation protocol (SIP), videoconferencing, voice-over-Internetprotocol (VoIP).

I. INTRODUCTION

THE next generation of enterprise networks is undergoingmajor changes as a plethora of new architectures, ap-

plications, and services begin to roll out within businesses.In general, the world of voice/telephony, video, and data are“converging” into a global communications network. Thispaper deals with the technical and managerial aspects of im-plementing such converged network architecture and services.A large number of factors are involved in creating a robustenterprise network capable of delivering multimedia services.These factors include, but not limited to, better voice and videocodecs, packetization, packet loss, packet delay, delay variation,directory services, resource integration, and reliable networkarchitecture. Also, critical are the choices of call signalingprotocols, security concerns, the ability to integrate seamlesslywith existing Internet services and the need to traverse networkaddress translator (NAT) and firewalls.

Manuscript received May 1, 2004; revised December 3, 2004 and March 29,2005. This work was supported in part the National Science Foundation underGrant NMI 0222710.

The authors are with the Network Convergence Laboratory, ClaremontGraduate University, Claremont, CA 91711 USA (e-mail: [email protected]; [email protected]; [email protected]; [email protected]).

Digital Object Identifier 10.1109/JSAC.2005.854118

In this paper, we focus on issues regarding the design,deployment, and management of “converged” enterprise net-works using the session initiation protocol (SIP) [1] as thesignaling platform. SIP, which is an Internet Engineering TaskForce (IETF) standard for Internet Protocol (IP) Telephony,has received much attention recently and seems to be the mostpromising candidate as a signaling protocol for the current andfuture IP telephony services, video services and integrated weband multimedia services. While SIP is new and actual deploy-ment experiences are fewer, it is widely expected that futureenterprise networks will incorporate SIP for its simplicity,flexibility, and built in security features. We note that H.323 [2]is also another signaling platform to build enterprise convergedservices. Instead of debating between the two protocols, werefer the readers to interesting literature on their comparison[3]–[5].

Although the evolution of the core enterprise network to IP isenabling the migration of the traditional circuit-switched voiceand call signaling message traffic over the Internet using voice-over-IP (VoIP) technology, there are many technical issues andchallenges that need to be resolved for its successful commer-cial deployment. The purpose of this paper is to discuss thoseissues and present existing solutions. However, we first analyzethe benefits offered by such a unified end-to-end IP-based mul-timedia network solution.

• Cost reduction: Moving voice calls over the Internet elim-inates the notion of long-distance. Further convergence ofvoice, data, and video traffic can improve network effi-ciency and reduce operation cost.

• Utilization: Digitized voice calls require less bandwidththan the traditional 64-kb/s circuit calls and, hence, morecalls can be made over the existing bandwidth.

• Simpler integration: An integrated infrastructure allowsmore standardization and is simpler to manage. It is nowpossible to have tighter integration with web-based appli-cations and supply chains.

• Enhanced services: Richer and enhanced services that in-tegrates existing enterprise applications with VoIP, video,or presence technologies is now possible.

• Consolidation: Since users are among the most signifi-cant cost elements in a network, any opportunity to com-bine operations, to eliminate points of failure, and to con-solidate accounting systems to track usage of resources,would be beneficial.

0733-8716/$20.00 © 2005 IEEE

1922 IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 23, NO. 10, OCTOBER 2005

While enterprise customers clearly see the benefit of mi-grating to such converged networks, even the service providershave optimism to support such convergence.

• More revenue: While traditional voice business is down,data is growing. Hence, digitized voice and video serviceswill provide them with more new revenue models.

• Efficiency: It has been proven that it is more efficient andcheaper to provision a packet-switched network than acircuit-switched network [6]. Hence, the migration towardpacket architecture is inevitable.

• Ubiquitous service: The service providers will now be ina position to offer any service (voice, video, or data) toany customer through their converged network.

The goal of this paper is twofold. First, to present the design,development, and performance of a SIP-based converged appli-cation. Second, to provide a technical and managerial guidelinefor SIP-based enterprise deployments by highlighting issuesidentified throughout our experience with SIP-based systems.The rest of this paper is organized as follows. Section II givesa brief overview of the SIP protocol. Section III presents atechnical guideline that addresses the important issues at eachlayer of the stack that one needs to consider before deployingany SIP-based enterprise architecture. Section IV presentsthe design, implementation, functionality, and performance ofSIP-based advanced desktop software that we have built forInternet21 and addresses the middleware support, namely, theneed for directory and security services. Section V presentsexperimental conformance and interoperability test results forSIP user agents (UAs). Section VI presents the NAT traversalissues and proposed solutions to tackle them. Section VIIpresents a management decision flow to guide decisions re-garding SIP-based enterprise implementations. Section VIIIsummarizes the implications and lessons learned with SIPenterprise architecture, and we conclude with potential futurework in Section IX.

II. BRIEF OVERVIEW OF SIP

A brief overview of SIP is presented in this section. First,basic SIP call flow and SIP functionality is discussed. Later, thesecurity mechanisms utilized by SIP are presented. Finally, adiscussion on SIP packet structure is provided.

A. SIP Call Flow

To make Internet multimedia (audio or video) calls, a callermust know the IP address and port number, where the calleewants to receive audio/video packets, as well as the audio andvideo codecs the callee supports. However, IP addresses are hardto remember and can easily change with users’ mobility whenthey receive dynamic addresses through dynamic host controlprotocol (DHCP) servers. SIP facilitates user mobility by usinghigh-level addresses of the form user@domain, which is calledSIP uniform resource identifier (URI). For instance, a user cancall Alice at [email protected] regardless of what communication

1Internet2 (http://www.internet2.edu/) is a consortium being led by 207 uni-versities working in partnership with industry and government to develop anddeploy advanced network applications and technologies, accelerating the cre-ation of tomorrow’s Internet.

Fig. 1. SIP call flow showing register and invite messages.

Fig. 2. IETF SIP protocol adopted from [5].

device, IP address, or phone number Alice uses. The high-leveladdress is bound to the user’s current location in SIP regis-trar servers, and the user’s communication devices register withthe registrar servers periodically by providing their current ad-dresses (see Fig. 1).

Fig. 1 shows the steps involved when a user Bob wants to callanother user Alice. Bob sends an INVITE message along withthe session description protocol (SDP), carried in SIP requestsand responses, which describes the list of supported audio andvideo codecs and the transport addresses to receive them. Once acall is established, Real-time transport protocol (RTP) and RTPcontrol protocol (RTCP) are used to transfer media between Boband Alice. A SIP proxy server typically handles call routing, andredirect functionality.

B. SIP Security

The overall SIP protocol architecture from IETF is shown inFig. 2. It is important to protect the privacy of SIP users andguarantee confidentiality of their interaction. The mechanismsthat provide security in SIP can be classified as end-to-end orhop-by-hop protection [3]. End-to-end mechanisms involvethe caller and/or callee SIP user agents. SIP provides specificfeatures (e.g., SIP digest authentication [7] and SIP messagebody encryption using S/MIME [8]) for these mechanisms.Hop-by-hop mechanisms secure the communication betweentwo successive SIP entities in the path of signaling messages.SIP does not provide specific features for hop-by-hop protec-tion and relies on network-level (IPSec) [9] or transport-level

CHATTERJEE et al.: SIP-BASED ENTERPRISE CONVERGED NETWORKS FOR VVOIP 1923

Fig. 3. Structure of SIP message.

Fig. 4. Guideline for implementing SIP-based converged services for enterprise.

(TLS) [10] security. If a user address is expressed using a SIPSecure (SIPS) URI (sips:[email protected]), it means that theuse of TLS is requested.

SIP communications are susceptible to several types ofattacks. They include snooping, modification, spoofing, anddenial-of-service [1], [7]. Such attacks make SIP enterprisesystems vulnerable and, hence, it becomes even more importantto design these networks with best possible security solutions.

C. SIP Packet Structure

A SIP message is either a request from a client to a server, ora response from a server to a client [1]. The message consistsof a start-line, message header, an empty line, and an optionalmessage body. Fig. 3, illustrates the structure of the message.Further details can be found in [1].

III. GUIDELINE FOR CONVERGED ENTERPRISE

SIP IMPLEMENTATION

We present a technical guideline in Fig. 4 for a SIP-based con-verged enterprise architecture. For simplicity, the well-knowntransmission control protocol (TCP)/IP stack is also shown. Foreach stack layer, a set of important technical and managerial is-sues are listed. For the application layer, SIP supports variouskinds of IP telephony, videoconferencing, instant messaging, aswell as web-integrated applications. Vendors have built a varietyof IP hard phones and soft phones. Videoconferencing using SIPis still relatively immature which is the subject of our discussionin Section IV. Instant messaging using the SIMPLE [11], [12]standard is also maturing. The important issues that affect thislayer includes design of SIP-based voice or video clients, thequality of media, overall performance, and integration of con-verged applications with legacy enterprise software.


Fig. 5. Functional components of CGUsipV1.1.x.

For the transport Layer, it is best to describe it as a middlewarelayer for SIP. Besides the possible use of various transport layerprotocols that can carry SIP packets [13], many other middle-ware services are needed. These include directories (white pagelookup), provision for security to ensure authentication and au-thorization, and solutions for interoperability issues.

For the network layer, SIP utilizes TCP/IP. However, thereare critical problems with NATs and firewalls [14], [15], im-plementing quality-of-service (QoS) and achieving interoper-ability. NATs and firewalls, behind which most enterprises sit,can disrupt SIP applications easily. For the link layer, SIP isoblivious since it is carried by IP protocol. The link can be wired(Ethernet) or wireless (IEEE 802.11b). Studies for H.323 overwireless networks have been conducted [16]. However, the per-formance aspects of SIP applications and security issues overwireless are not well-studied. Finally, at the physical layer, itis important to design robust infrastructure that can withstandcyber attacks [e.g., distributed denial-of-service (DDoS)].

IV. DESIGN, IMPLEMENTATION, AND PERFORMANCE

OF CGUSIPCLIENT

To provide a freely available SIP-based video/voice-over-IP(VVoIP) tool for Internet2 members, we developed CGUsip-Client v1.1.x (http://ncl.cgu.edu/), which is a java-basedapplication implemented on Dynamicsoft SIP stack. It usesJava Media Framework (JMF) APIs for voice and videooperations. CGUsipClient v1.1.x provides a number of func-tionalities, as shown in Fig. 5. Basic SIP functionality providessession setup and termination. Media functionality providesaudio and video communication capabilities. CGUsipv1.1.xsupports G.723, DVI, GSM and -law audio codecs, and H.261,H.263, and JPEG video codecs. H.350 is an ITU-T standarddeveloped through our work [17]. H.350 functionality providesan LDAP-based solution for providing directory informationand single sign-on. Other features that CGUsipClient v1.1.xprovides are redirection and caller ID.

National Middleware Initiative (NMI—http://nsf-middle-ware.org/Middleware/) proposes middleware as a layer of

software residing between network and traditional applicationsto offer services such as managing security, access, and in-formation exchange. The initiative provides these services toenable effective, scalable, and transparent usage of collabora-tive and communication tools. Adopting from this vision, ViDe(http://www.vide.net/), a Video Development Initiative fromInternet2 group, has developed H.350 (http://middleware.in-ternet2.edu/video/docs/H.350/). H.350 provides a directoryservices architecture for multimedia conferencing currentlysupporting SIP, H.323, H.320, and generic protocols.

H.350 is an LDAP object class specification designed to stan-dardize the way multimedia conferencing information is storedand accessed. By maintaining an enterprise directory with userinformation, as well as a communication directory for endpointdevice and protocol information, H.350 simplifies configurationmanagement and scalability in an enterprise. A detailed dis-cussion on H.350 can be found in [17]. CGUsipClientv1.1.xis the first SIP client to utilize this directory structure to offer“White Page,” “Click-to-Call,” and “Single Sign-On” facilities.“White Page” displays a list of users with SIP URIs who arein the enterprise directory. “Click-to-Call” enables a user tocall another user by “clicking” on the other user’s SIP URI.“Single Sign-On” provides facility of authenticating with a SIPproxy/registrar based on the credentials fetched from the LDAPstructure instead of explicitly providing for user name and thepassword for registration. A snapshot of CGUsipClientv1.1.x isshown in Fig. 6. More details on our client can be found in [18].

The performance of CGUsipClient was evaluated by makinga point-to-point videoconferencing call between two systems.The configuration of these systems is provided in Table I.

Four metrics were identified for performance testing: CPUload, video frames per second, audio, and video bit rates. Recenttesting with CGUSipClientv1.1.1 provided the following per-formance results shown in Table II. All the values represent re-ceived video and audio performance ranges during a “2 minute”call.

The performance provided in Table II is achieved after theinitiation phase is over. During the initiation phase the CPU loadchanges, as shown in Table III.


Fig. 6. Snapshot of CGUsipClientv1.1.x.

TABLE IPERFORMANCE TEST CONFIGURATION

TABLE IIPERFORMANCE METRICS AFTER INITIATING THE CALL

TABLE IIICALL INITIATION PERFORMANCE

V. EVALUATION: CONFORMANCE AND INTEROPERABILITY

Interoperability is an important issue for VVoIP becausethere are multiple protocols and devices that provide similarservices [19]. Accordingly, multiple protocols and devicesneed to be examined to decide whether they provide servicesas prescribed by standards. In enterprise-wide VVoIP deploy-ments, local administrators have full control over the systemsand devices selected for implementation. However, the needto communicate with others outside the enterprise is crucialand local administrators do not have control over external

TABLE IVCLIENTS TESTED

domains. Therefore, administrators need to take into accountthe conformity of clients with the standards, as well as inter-operability between various clients, while selecting solutionsfor their enterprise. Evaluating conformity will provide admin-istrators the disparity of their implementation of SIP entitieswith the standards. The further away an enterprise is fromthe standards the lesser flexibility is available to it in termsof implementing better solutions that are offered by researchcommunity. Moreover, examining interoperability betweenSIP products, available for implementation, will indicate thelimitations of an enterprise in communicating with externalorganizations engaged in VVoIP. This study examined variousSIP clients, as illustrated in Table IV, for conformance andinteroperability testing.

The first subsection presents the results of tests conductedthrough HCL Technologies Conformance Test Suite and SipTest Tool [20]. HCL’s SIP Test Tool can be used for testing con-formance to standard, as well as load, regression, and integra-tion testing. It acts as a distinct SIP entity and responds to thetest automation needs of SIP-based products such as SIP useragent, conference servers, and proxy servers. Use of this testtool is limited to the basic conformance tests of user agents inthis paper. The goal is to investigate the basic protocol imple-mentation of the clients being tested.

The second subsection presents the interoperability test re-sults between the selected SIP clients. Among the proposed SIPinteroperability scenarios [21], we selected a scenario in whichwe can test the capability of clients to make a basic voice andvideo call, if possible, to another client through a single proxy.Using a single proxy reduces the complexity of the session ini-tiation and helps us focus on the client side only.

A. Conformance

Methodology: A SIP-based user agent or an endpoint is “log-ical entity that can act as both a user agent client and user agentserver” [1]. The conformance testing was conducted based onthese two functionalities—user agent server (UAS) and useragent client (UAC). Another set of conformance tests was con-ducted that examined capability of an endpoint to receive ortransmit SIP calls within a dialog or outside a dialog. A dialog,as defined in [1], represents a peer-to-peer SIP relationship be-tween two user agents that persists for some time.

Simple call testing was conducted to evaluate the basic callsetup functionality of a client within a dialog and outside a di-alog. The process of communicating SIP-based call betweenendpoints is similar in both cases with one difference being thatthe communication within a dialog necessitates generation of“Tag” header from an endpoint that responds to the very first


Fig. 7. Simple call test scenario.

request it receives. The mechanism of “Tag” parameter in com-bination with “Call-Id” is used to identify a dialog between twoSIP endpoints [1]. Simple call setup functionality is designed totest whether an endpoint is capable of generating a request orresponse based on the type of message it receives. In this groupof tests, every endpoint was used to make or receive a SIP-basedcall to or from an HCL server. There were three subtests con-ducted under this set of testing. Fig. 7 illustrates a successfulcall attempt from “user agent” to HCL server.

UAS tests are designed to test the server behavior of an end-point under various conditions. In this set of tests, a SIP-basedendpoint receives requests from the HCL server. The requestsgenerated for the endpoint is transmitted with errors in themlike providing unknown header parameters, unknown method,or supplying malformed requests. In all these behaviors, if theendpoint does not respond as prescribed by [1], it is consideredto have failed that particular test. Overall, 17 different tests wereperformed under UAS testing and they can be grouped into threecategories.

• Method: Evaluate behavior of an endpoint when it re-ceives an invalid method in the request. There was onesubtest in this category.

• Header: Evaluate behavior of an endpoint when it re-ceives a malformed header in any of the header param-eters or receives unknown parameter in the header. Therewere 12 subtests in this category.

• Request: Evaluate behavior of an endpoint when it re-ceives request with or without mandatory parameters in“Request-Line,” shown in Fig. 3. There were four subtestsin this category.

Under UAC set of tests, a SIP-based endpoint generates a re-quest to the HCL server and the HCL server responds to therequest. This response is generated with malformed or invalidresponse messages or that expected a specific type of informa-tion to be transmitted from the endpoint. Similar to UAS tests,if the endpoint does not respond as prescribed by RFC 3261, itis considered to have failed that particular test. Overall, 24 testswere performed under UAC testing and they can be grouped intothree broad categories.

TABLE VSUMMARY OF CONFORMANCE TEST RESULTS

• Request: Evaluate an endpoint when it is expected to gen-erate request with specific parameters. There were threetests in this category.

• Responses: Evaluate whether an endpoint is able tohandle different kinds of responses. There were 20 testsin this category.

• Redirection: Evaluate whether an endpoint is capable tohandle the redirection response from the other endpoint.There was one test in this category.

Results: Table V presents a summary of overall results. Theresults of simple call test indicate that Helmsman SIP-basedclient was unable to receive or transmit a basic call. However, itwas able to transmit messages based on a dialog.

In UAS testing, it was observed that Messenger™ was ca-pable of responding appropriately in almost all cases exceptwhere the header in the requests were malformed or had un-known values in header fields. A specific pattern of behaviorstayed undetermined for Siemens client. While it was able torespond appropriately to certain requests, it failed to serve otherrequests that were malformed or incorrect. Grandstream andsipc were almost identical in their performance—both of themunable to detect the errors in headers of the message. CGUsip,Cisco, and Session™ displayed variable behavior. While all ofthem could not trace the errors in header fields, CGUsip andSession detected errors in methods supplied, whereas Cisco wasable to respond appropriately when the requests had errors inthem. Helmsman was unable to detect errors in almost all of themessages.

In UAC testing, CGUsip was unable to respond appropriatelyto certain response codes communicated to it by the HCL server.Messenger, in addition to not responding to response codes,was unable to detect malformed responses or serve multiple re-sponses for a request and was unable to serve request for redirec-tion. Session was able to trace malformed responses but was notable to respond to certain response codes. Similar was the casefor Siemens but with certain variations. Although the numberof tests passed by Cisco and Grandstream was same, the typesof tests were different. Grandstream was able to trace fields inheader, whereas Cisco was able to serve various response codes.The results for sipc were similar to Grandstream, however, sipcwas not able to parse certain header fields. Helmsman was notable to parse response codes, header fields or multiple requests,or responses.

B. Interoperability

Methodology: This group of tests was based on a singleproxy scenario presented in Fig. 8. All selected user agentswere registered to a single proxy and a testing protocol was


Fig. 8. Interoperability testbed.

TABLE VIINTEROPERABILITY RESULTS

Note: Y and N stand for yes and no, respectively, and na stands fornot applicable

established to test (S) establishing a session, (A) establishingaudio communication, and (V) establishing video communica-tion (if supported) between two different clients. Evaluating thequality of media is done in a subjective manner.

Results: The results of the interoperability tests are pre-sented in Table VI. The highlighted columns indicate completeinteroperability between two clients within their respectivevoice or video capabilities. For example, in Table VI, when acall is initiated from Messenger to sipc the clients were ableto establish the session, audio as well as video—indicatingcomplete interoperability between them, however, this is not thecase between Messenger and CGUsip. Only the calls betweendifferent clients are reported in the table. The results of ClientA making a call to Client B is different in some cases than

Client B making a call to Client A. This is caused by the UACand UAS implementation differences in handling events.

Three clients in the testbed (Cisco, Grandstream, andHelmsman) are audio only clients and, hence, no video connec-tion was expected from them. Moreover, even though Session isa video client since it only supports a proprietary video codec,it was not possible to make video communication betweenSession and any other client.

Cisco phone was able to communicate with all the clients ex-cept Helmsman. They failed to establish an acceptable audiocommunication since the audio received by Cisco was not un-derstandable, where as the audio sent by Cisco was perfect onthe Helmsman side.

Grandstream hard phone passed all the tests with one excep-tional case of Grandstream calling Session. The implementa-tion at Session for codec negotiation is the main reason for thisfailure. If a single audio codec is selected in Session side, thisproblem does not occur and the audio communication can beestablished.

Session’s codec negotiation problem is related to the way thecodec list is presented in 200 OK messages. The session descrip-tion protocol (SDP) [22] states “When a list of payload formatsis given, this implies that all of these formats may be used in thesession, but the first of these formats is the default format forthe session.” Session responds back with a list of codecs that itsupports without changing the order according to the incomingcodec list in the INVITE message. This results in audio commu-nication failure if the two lists are not in the same order sinceit misleads both clients and ends up with the exchange of audiousing different audio codecs. Among video clients, Messengerand Siemens were the only two clients that established a sessionin any direction and shared both audio and video in any order.

Implications Derived From Evaluation: The experimentspresented in this section are based on certain predefined sce-narios that are common in real-life implementations. However,the same measurements in a field study environment can pro-vide different results. Therefore, further studies needs to beconducted to better understand interoperability and confor-mance issues in an enterprise setting. It is also important toevaluate the extra features provided by clients in terms of theway these features are utilized and their effects on the basicfunctionality, network load, and other applications. It is alsoimportant to note that during our experiments, quality of audioand video was measured subjectively. Further studies can becarried out that can evaluate the audio/video quality of theclients by using both objective and subjective measurements.

VI. SIP-OVER-NETWORK ADDRESS TRANSLATOR

(NAT)/FIREWALL TRAVERSAL

The challenge of traversing NAT and/or firewalls is still abarrier for VVoIP deployments [14]. NAT and/or firewalls posetwo challenges for these technologies. First, if NAT is placedbetween a SIP-based user agent (UA) and the Internet, the UAis allotted a private network address, which is not valid in theInternet. As a result, contact information (IP address and portnumber) is invalid for the external networks and responses fromexternal proxy servers may not reach the UA. Another challenge


is related to media sessions. During the SIP session initiation,RTP and RTCP ports are negotiated for establishing a mediasession between two user agents [1]. Even if the negotiation issuccessful, NAT or firewall will disallow the direct connectionusing the ports negotiated.

We have tested the performance of some existing NAT/fire-wall solutions using network traffic analysis techniques. Wehave analyzed and evaluated three popular solutions for SIPover NAT traversal, which are: 1) an IETF Standard calledSimple Traversal of User Datagram Protocol (UDP) throughNetwork Address Translators (NATs) (STUN) [23]; 2) Uni-versal Plug and Play (UPnP) [24]; and 3) a proprietary solutionby Ridgeway Systems, Inc.,—IPFreedom™ [25]. Even thoughother solutions have been proposed by IETF such as r-port [26]and MIDCOM [27], the common deployment of these threesolutions motivated the choice of selection. Another recentsolution, Interactive Connectivity Establishment (ICE) [28]was not tested, as there were no implementations available atthe time.

A. Brief Overview of STUN, UPnP, and IPFreedom™Solutions

STUN [23] is used to resolve whether a UA is behind a NATand if it is, the type of that NAT. Implementing a solution forSTUN requires a STUN server external to the network that isbeing protected behind a NAT and a STUN-enabled client on aSIP device. A STUN-enabled UA requests external IP and portthat it can use to form SIP headers when it initiates a sessionwith another UA placed external to the network. These portsare related to SIP signaling, as well as media.

UPnP [24], targeted at small-business users and residentialinstallations [29], has been popularized by Microsoft. It is anextension of Device Plug and Play (PnP) providing a solutionfor traversing NAT for communication with external networks.It includes the entire network, enabling discovery and control ofdevices, including networked devices and services, such as net-work-attached printers, Internet gateways, and consumer elec-tronics equipment [24]. This solution, unlike STUN, does notrequire a server outside the network, but it requires a UPnP-en-abled NAT device and a UPnP-enabled SIP UA.

IPFreedom [25] is a solution proposed by Ridgeway Systemsfor traversing VVoIP over NAT and firewalls. This solutionworks for all types of NAT’s and firewalls. It does not requireconfiguration modifications on firewall or a NAT device. Inthis solution, a UA in private network establishes outboundcommunication connections through the NAT with a Ridgewayserver on the public network. Signaling messages are trans-mitted through the server via TCP tunneling and media packetsare transmitted over user datagram protocol (UDP) connec-tions. Further, IPFreedom solution requires colocation of anIPFreedom client and SIP UA. The user needs to configure theSIP UA to use the IPFreedom client. This solution can be usedwith various UAs without any modifications.

B. Experiment Methodology

For tracing different behaviors of three solutions, we com-pared benchmark (No NAT/Fw) and experimental scenarios.For both scenarios, Vocal, an open source SIP proxy by

Vovida (http://www.vovida.org), was utilized. Further, Ethereal(http://www.ethereal.com) was placed in every network in thestudy to gather traffic on the network and trace the behavior ofthe packets being transmitted on the network.

The benchmark scenarios were categorized based on differentclients that were used for the study that provided solutions forNAT traversal. As per Fig. 9, in Grandstream Benchmarkscenario, Grandstream BudgeTone SIP endpoints were used.In Microsoft XP Messenger™ Benchmark scenario, WindowsMessenger™ 4.7 on Windows XP operating system clients wasused. In Wave3 Session Benchmark scenario, Wave3 Session2.1.5 clients were used. These clients and the Vovida proxy/reg-istrar were placed on a single public network. Experimentsin benchmark scenario involved establishing and terminatingcalls, making audio and video calls between the clients usingVovida proxy. The traffic measurement involved counting thenumber of messages transmitted for video and audio calls andtracing the process delays.

A small-business scenario was considered for the exper-imental setup. This scenario involved placing a client in anetwork behind a NAT making calls to clients in the public IPnetwork through a proxy or registrar in the public network. Thescenarios in Fig. 10 are categorized based on the solutions forNAT traversal, explained before.

In STUN scenario, a Grandstream BudgeTone SIP Phone thatprovides STUN capability was placed behind a NAT and anotheron the public network. In the UPnP scenario, Microsoft’s Win-dows XP Messenger was used on internal as well as externalnetwork. In IPFreedom scenario, Wave3 Session™ client wasused to test IPFreedom solution.

C. Performance Results

Results collected from Ethereal for each experiment were an-alyzed: 1) to calculate the load on the network infrastructure bymeasuring SIP message traffic on the network and 2) to calculateprocess delays caused by NAT traversal solutions. Three basicprocesses were evaluated—REGISTER message with the SIPproxy/registrar, INVITE, and BYE messages between SIP UA.The analysis of message count, based on the exchanged mes-sages between participating SIP entities was done for the threesolutions. A summary of the results is presented in Table VII formessage counts.

Table VII is organized based on different processes and so-lutions for NAT traversal. For INVITE and BYE messages theexperimental scenario is classified as “ ,” indicatingcalls made from client on the public address to clients on theprivate address, and “ ,” indicating calls made fromclient on the private network address to clients on the public net-work address.

As per Table VII, STUN solution resulted in an increase inthe number of messages in processes. The UA on the private net-work uses four additional STUN messages compared with thebenchmark scenario. The four additional messages are related toSTUN request and response. Similarly, for INVITE, there weretwo additional messages exchanged between the clients. Therewere no changes in the process of call termination. For UPnP,the process of UA negotiating IP and port with NAT/firewallresults in dramatic increase in the number of messages (85 in


Fig. 9. Benchmark scenario design.

Table VII) for registering with the proxy/registrar. There weresimilar increases in INVITE, as well as BYE messages. ForIPFreedom, the increase in the message counts were not of thesame magnitude as UPnP but the solution did result in a smallincrease of messages exchanged between SIP entities.

Table VIII illustrates summary of the delay occurred duringthe experiments in the registration and call processes. For cal-culating process delays, ten calls were made between clients.Average (Avg) of these calls were considered after ignoring thehighest and the lowest value for each process. Standard devia-tions (Stdv) of these calls were calculated to measure the vari-ability of the delays in the calls.

For measuring registration delay, registration interval wascalculated starting from the time REGISTER request was sentby the client to the time 200-OK message was sent by theserver. Invite interval was calculated starting from the INVITErequest was sent to the time 180-RINGING message was sentby the server back to the client.

There were not any marked delays for the processes inSTUN solution when compared with benchmark. There was a0.01 s difference in performance for INVITE message whena UA in public network initiated a call to a UA in privatenetwork. Another noticeable difference was apparent whena UA in private network initiated a call to a UA in publicnetwork. However, neither of these were significant comparedwith other implementations. The process delays in UPnP werenoticeably higher compared with STUN. For example, theshortest delay observed was 2.54 s compared with the longestdelay of 0.7 s in STUN scenario. Performance of IPFreedomsolution in general showed higher values of delay comparedto STUN and UpnP. The delay reduced when INVITE mes-sages were transmitted between clients in private networkand in public network. However, there were no delays in theREGISTER process.

The results indicate that STUN solution was the most effi-cient one in terms of traffic load, message count, as well as the


Fig. 10. Small-business experimental scenario design with NAT/firewall.

TABLE VIISUMMARY OF MESSAGE COUNTS

process delay and causes minimal performance impact on ex-isting networks. However, it cannot solve the traversal issue forall NAT types and firewalls. UPnP generates a large amount ofTCP messages that affect the network load behind the NAT.This may not be problematic for a residential user using UPnP,whereas for an enterprise network, managers can expect unnec-

TABLE VIIIPROCESS DELAY FOR EACH EXPERIMENT (SECONDS)

essary traffic that can affect the performance of other applica-tions. It is important to note that this traffic is never reflected


Fig. 11. Management decision flow for SIP-based implementations.

to the public network and UPnP can solve a large number oftraversal problems. On the other hand, due to the fact that en-terprises have a lot of Intranet activity that can get hampered, itmay not be suitable for an organization where a large number ofVoIP traffic is expected everyday. Finally, IPFreedom is a relaysolution where the communication completely depends on aserver outside and, hence, results in higher delays. It causes in-creased TCP traffic in both private and public network. MoreTCP traffic will consume bandwidth on both public and pri-vate side, taking away available bandwidth for real-time ap-plications. Even though we did not measure the media delaycaused by the relay technique, it is expected to be higher com-pared with other solutions.

Length of INVITE process is very important since it rep-resents the waiting time for users to establish a call. Duringthe INVITE process for audio-only calls, IPFreedom solutioncaused higher delays in public, as well as in private network.On the other hand, UPnP solution caused higher delays in pri-vate network for INVITE process for audio-video calls. Thisimplies that depending on the use of audio and video, enterprisenetworks will experience delays both in public and private sidesof the network with these two solutions.

VII. MANAGERIAL IMPLICATIONS

Previous sections provide a guideline for technical issuesenterprises have to face, while deploying SIP-based systems.This section provides a managerial guideline, illustrated inFig. 11, which can help managerial decision makers, whileidentifying the need and finding solutions for enterpriseimplementations.

Every implementation requires a preparation and a decision-making phase. The preparation phase should start with makinga business case for deploying VVoIP systems in the enterprise.Expected returns for stakeholders should be identified to sup-port the business case. Once a clear business case is identified,the management should first initiate an audit of existing infra-structure of the enterprise. Outcome of this audit should be adetailed list of enterprise capabilities. Identifying needs basedon the existing capabilities of the enterprise infrastructure andthe business case made in the first step should follow next. Re-quirements for the project will be the final outcome of this step.Identifying capabilities and requirements completes the prepa-ration phase and initiates the decision-making phase.

Decision-making phase starts with a request for proposalwhere capabilities and requirements are listed with the ob-jectives of the project and the expected timeline. Solutionanalysis starts after the proposals are received. During thisstep, it is important to consider both technical issues, such asinteroperability, conformance, and SIP/NAT traversal, as wellas managerial implications. Depending on the objectives andthe scope of the project, different SIP entities may be necessaryfor deployment. We categorized them as clients and servers.Distinction should be made between these two while doing so-lution analysis since their functionalities vary. Once a decisionis made for a specific set of solutions, a pilot implementation isusually very useful to evaluate the selected solution. Full-scaleimplementation follows successful pilot implementations and ifproblems occur during the pilot implementation new solutionscan be selected for testing. Once a full-scale implementation isin place, management should analyze the match between theresults of the current deployment and the business case madeat the preparation phase.


VIII. SUMMARY: IMPLICATIONS AND LESSONS LEARNED

As mentioned above, the client developed in our lab wasbased on a commercial SIP stack provided by Dynamic-soft. Along with other commercial stacks, there are anumber of open source stacks available for developmentsuch as Vocal, JAIN (https://jain-sip.dev.java.net/), OSIP(http://www.gnu.org/software/osip/osip.html), and SIP ExpressRouter (http://www.iptel.org/ser/). These options need to beevaluated for RFC 3261 [1] compatibility, without which thedevelopment activities could get hampered in the long run. Thefuture plan of our lab is to migrate from a commercial stack toan open source SIP stack. However, we do recognize that opensource stack might have a limitation of not being fully updatedwith evolving standards.

Further, we have used Java as our development platform.There are some disadvantages of using JMF. We have experi-enced high CPU loads and memory usage. The time to start avideo process is also longer.

Results of conformance testing indicated that some SIP UAsused in our experiments do not adhere to RFC 3261 fully. Thismight create performance problems in the long run as the deci-sions by administrators to opt for clients that do not interoperatewith similar systems might not be well received by the users inthe organization.

NAT/firewall traversal is an important issue in enterprise de-ployments. As yet, there has not been a single comprehensivesolution for overcoming this difficulty. This solution is of para-mount importance for security and scalability of enterprise net-works. Through our analysis, we have found that STUN [23] iseffective but does not provide a solution for all types of NAT orfirewall deployments. UPnP [24] is a popular solution for smalloffice/home office networks. However, it forces serious delaysin the processing of messages and increases delay significantly.IPFreedom is a proprietary solution that could work with mosttypes of NATs and firewalls. Nonetheless, it generates traffic onthe network due to TCP tunneling between entities. Enterprisenetworks need an efficient solution that requires minimum mes-sage exchange and do not generate significant impact on the per-formance of end-user multimedia applications.

Currently, configuring different SIP clients is still problem-atic. In this study, we have tested eight SIP user agents includingcommercial and freeware applications. The configurations ofthese clients vary among themselves and lack standardization.Configuration of these different clients, if not standardized, mayturn into an administrative nightmare. An ideal option wouldbe to devise a centralized solution for configuring clients in anenterprise network. A centralized solution will minimize ad-vanced administrative issues like specifying the availability orunavailability of users at a given date/time or indicating themode of communication like voice, video or messaging at agiven date/time. H.350, an ITU-T standard, could be a poten-tial solution for this problem by providing a standard architec-ture for SIP, as well as other protocols for storing configurationinformation and user authentication information inside LDAPdirectories. H.350 could also provide central control interfacefor device management and user management.

IX. CONCLUSION

This paper has presented a summary of our work based onsubstantial experience in dealing with SIP-based multimediaservices deployment within enterprise. We have described thedesign and architecture of a new SIP-based video client, whilehighlighting the lessons learned from the process. We havealso raised important deployment issues in various stack levels,presented the experimental analysis of the solutions that areavailable and lessons learned. We hope that the technical andmanagerial guidelines provided can be useful to network ad-ministrators and managers who are contemplating on deployingSIP-based solutions. In this paper, we did not focus much onsecuring SIP communication. As a future work, we see a lot ofchallenges in completely securing this SIP environment. Themechanisms of using digital certificates, certificate authorities(CAs), S/MIME for end-to-end encryption, and managingtrusts between domain CAs (federated identity management)will be critical as we move toward a more robust productionenvironment.

ACKNOWLEDGMENT

The authors would like to acknowledge the help from sev-eral people during the course of this project. In particular,they would like to thank J. Fildey of Wave3, Inc., B. Zhangof Grandstream Networks, Inc., and P. N. Janardhanan ofHCL Technologies for providing us with their software andtools. They also acknowledge the contributions of J. Gemmill,T. M. Johnson, E. Verharen, and N. El-Khoury. The authorsthank the VidMid-VC Working Group within Internet2 fore-mail discussions.

REFERENCES

[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R.Sparks, N. Handley, and E. Schooler, “SIP: Session inititation protocol,”Internet Engineering Task Force, RFC 3261, 2002.

[2] International Telecommunications Union, “Packet based multimediacommunications systems,” ITU, Recommendation H.323, 2000.

[3] S. Salsano, L. Veltri, and D. Papalilo, “SIP security issues: The SIP au-thentication procedure and its processing load,” IEEE Network, vol. 16,no. 6, pp. 38–44, Nov.–Dec. 2002.

[4] Packetizer. (2003). Comparisons between H.323 and SIP. [Online].Available: http://www.packetizer.com/iptel/h323_vs_sip/

[5] J. Glassman, W. Kellerer, and H. Muller, “Service architectures in H.323and SIP: A comparison,” IEEE Commun. Surveys, vol. 5, no. 2, pp.32–47, 2003.

[6] S. Dunstan, “Converged voice and data services in the new network,”Telecomm. J. Australia, vol. 51, no. 2, pp. 17–31, 2001.

[7] K. Ono and S. Tachimoto, “SIP signaling security for end-to-end com-munication,” in Proc. 9th IEEE Asia-Pacific Conf. Commun., Penang,Malaysia, 2003, pp. 1042–1046.

[8] E. B. Ramsdell, “S/MIME version 3 message specification,” IETF, RFC2633, 1999.

[9] S. Kent and R. Atkinson, “Security architecture for the Internet pro-tocol,” IETF, RFC 2401, 1998.

[10] T. Dierks and C. Allen, “The TLS protocol version 1.0,” IETF, RFC2246, 1999.

[11] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, “Instant messaging/pres-ence protocol requirements,” Internet Engineering Task Force, RFC2779, 2000.

[12] M. Day, J. Rosenberg, and H. Sugano, “A model for presence and instantmessaging,” Internet Engineering Task Force, RFC 2778, 2000.

[13] G. Camarillio, R. Kantola, and H. Schulzrinne, “Evalutaion of transportprotocols for the session initiation protocol,” IEEE Network, pp. 40–46,Sep./Oct. 2003.

[14] V. Paulsamy and S. Chatterjee, “Network convergence and NAT/firewallproblems,” in Proc. 36th IEEE Hawaii Conf. Syst. Sci., Waikoloa, BigIslands, HI, 2003, p. 752C.


[15] M. Stukas and D. C. Sicker, “An evaluation of VoIP traversal of firewallsand NAT’s within an enterprise environment,” Inf. Syst. Frontier J., vol.6, no. 3, pp. 219–228, 2004.

[16] S. Das, E. Lee, K. Basu, and S. Sen, “Performance optimization of VoIPcalls over wireless links using H.323 protocol,” IEEE Trans. Comput.,vol. 52, pp. 742–752, Jun. 2003.

[17] J. Gemmill, A. Srinivasan, J. Lynn, S. Chatterjee, B. Tulu, and T. Ab-hichandani, “Middleware for scalable real-time multimedia communi-cations cyberinfrastructure,” J. Internet Technol. (Forthcoming), vol. 5,no. 4, pp. 405–420, 2004.

[18] B. Tulu, T. Abhichandani, S. Chatterjee, and H. Li, “Design and de-velopment of a SIP-based video conferencing application,” in Proc. 6thIEEE Int. Conf. High Speed Netw. Multimedia Commun., Estoril, Por-tugal, 2003, pp. 503–512.

[19] G. W. Bond, E. Cheung, K. H. Purdy, P. Zave, and J. C. Ramming,“An open architecture for next-generation telecommunication services,”ACM Trans. Internet Technol., vol. 4, no. 1, pp. 83–123, 2004.

[20] HCL Technologies. VoIP product testing: Challenges and solu-tions. [Online]. Available: http://www.hcltech.com/voip/pdf/VoIP%20Testing%20White%20Paper.pdf

[21] International Multimedia Teleconferencing Consortium—SIP SIG Ac-tivity Working Group. (2000). SIP interoperability scenarios test plan.[Online]. Available: http://www.cs.columbia. edu/sip/drafts/sipsig_in-terop.doc

[22] M. Handley and V. Jacobson, “SDP: Session description protocol,” In-ternet Engineering Task Force, RFC 2327, 1998.

[23] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy, “STUN—Simpletraversal of user datagram protocol (UDP) through network addresstranslators (NAT),” Internet Engineering Task Force, RFC 3289, 2003.

[24] Microsoft. (2000). Understanding Universal Plug and Play—WhitePaper. [Online]. Available: http://www.upnp.org/download/UPNP_Un-derstandingUPNP.doc

[25] Ridgeway Systems. (2003). White Papers and Briefs. [Online]. Avail-able: http://www.ridgewaysystems.com/support/whitepapers.aspx

[26] J. Rosenberg and H. Schulzrinne, “An extension to the session initiationprotocol (SIP) for Symmetric response routing,” Internet EngineeringTask Force, RFC 3581, 2003.

[27] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and A. Rayhan,“Middlebox communication architecture and framework,” InternetEngineering Task Force, RFC 3303, 2002.

[28] J. Rosenberg, “Interactive connectivity establishment (ICE): A method-ology for network address translator (NAT) traversal for multimedia ses-sion establishment protocols,” Internet Engineering Task Force (IETF),Internet-Draft draft-ietf-mmusic-ice-04, Expires, 2005.

[29] Newport Networks. (2003). Solving the firewall and nat traversal is-sues for multimedia over IP services—White Paper. [Online]. Available:http://www.newport-networks.com/whitepapers/

Samir Chatterjee (S’92–M’95) received the B.E.degree from Jadavpur University, Calcutta, India,and the M.S. and Ph.D. degrees from the School ofComputer Science, University of Central Florida,Orlando.

He is an Associate Professor in the School ofInformation Systems and Technology and FoundingDirector of the Network Convergence Laboratory,Claremont Graduate University (CGU), Claremont.Prior to that, he taught at the J. Mack RobinsonCollege of Business, Georgia State University,

Atlanta. Currently, he is exploring fundamental challenges in designing securedIT-based systems to be used in application fields such as healthcare informationsystems, P2P computing, ad hoc collaboration, and medical information.He has actively contributed toward designing middleware for multimediawithin Internet2, which led to the establishment of the ITU-T standard calledH.350. He is principal investigator on several NSF grants and has receivedfunding from numerous private corporations for his research. He has beenan entrepreneur and successfully co-founded a startup company VoiceCoreTechnologies, Inc., in 2000. He is on the Editorial Board of the InternationalJournal of Business Data Communication and Networking (IJBDN) andthe Journal of Information Technology, Theory and Application (JITTA).He has published over 65 articles in respected scholarly journals and refereedconferences. His research interests are mainly in the areas of next-generationnetworking, voice and video over IP, and network security.

Dr. Chatterjee is Vice Chair of the EntNet Technical Committee for the IEEECommunications Society and serves on the TPC for the IEEE Globecom 2005,the IEEE Healthcom 2005, the IEEE MASS’05, and the SIP Workshop Chair atEntNet@Supercom 2005.

Bengisu Tulu (S’03) received the B.S. degree inmathematics and the M.S. degree in informationsystems from the Middle East Technical University,Ankara, Turkey, and the M.S. degree in managementinformation systems from Claremont GraduateUniversity (CGU), Claremont, CA. She is currentlyworking towards the Ph.D. degree in managementinformation systems at CGU.

She works as a Research Associate at the NetworkConvergence Laboratory, CGU. She is currentlyworking on voice/video over IP, security, and ob-

jective/subjective quality measurements for telemedicine applications. Shehas been a member of the design team that implemented CGUSIPClient, avoice/video conferencing client using SIP.

Tarun Abhichandani (S’05) received the M.S.degree in management information systems fromClaremont Graduate University (CGU), Claremont,CA, and the M.S. degree in banking and finance fromMumbai University, Mumbai, India. He is currentlyworking towards the Ph.D. degree at the School ofInformation Systems and Technology, CGU.

He is a Research Associate at the Network Con-vergence Laboratory, CGU. In the past, he has heldvarious positions, while designing and administeringorganization-wide networking infrastructure, data-

base applications, and ERP systems. His research interests include middlewarefor video-conferencing applications, transit-based e-government initiatives,and ad hoc collaboration using peer-to-peer technologies.

Haiqing Li (S’05) is working towards the Ph.D.degree at the School of Information Systems andTechnology, Claremont Graduate University (CGU),Claremont, CA.

He has worked as a Research Assistant in theNetwork Convergence Laboratory, CGU, over thelast three years. He is also a Lecturer at the Uni-versity of La Verne, La Verne, CA. He is currentlyworking on broadband wireless solutions usingWiMax. In addition to digital signature, his researchinterests include network convergence, VoIP secu-

rity, network simulation, and geographic information systems.

sip-based enterprise converged networks for voice/video-over-ip

Documents