Interoperability and Vulnerabilities in VOIP protocol (SIP, H.

323)
Rachana kamble Department of Computer Science and Engineering MTech IV sem(Information Security) MANIT Bhopal, Email: [email protected] Mob-+91-8109752027 Guided by R. K. Pateriya Associate Professor, MANIT Bhopal(M.P) INDIA E-mail: [email protected] Phone: +91-755-4051313,+91- 9425027381

Abstract In addition to providing telephony services VoIP technology is becoming a popular service on the internet platform. Several VoIP protocols are used for VoIP communication. But different VoIP protocol clients cannot interoperate directly. Any VoIP device must provide for mechanisms to protect from toll frauds, eavesdropping and callhijacking, among other things. SIP was designed only for the purpose of making communications possible. This paper suggests first a VoIP Web service substructure to facilitate the interoperability among different VoIP protocols. Therefore different VoIP protocols can utilize the common web service interfaces to achieve the interoperability also study the performance and interoperability of OpenH.323 (using Ohphone and Gnome Meeting interfaces in Linux) with Microsoft Netmeeting (in Windows), a popular but proprietary H.323 implementation also suggested the performance and interoperability issues for open H.323 for multimedia over Internet protocol (MoIP) system. And second The SIP-based VoIP network is useful from the point-of-view of a layered approach, Threats, and therefore, countermeasures, can be mapped to the layers of the networkreference model. We analyze security of VoIP protocols at all layers of the VoIP stack. In particular, we focus on the interoperation between protocols at different layers. A protocol may be secure when executed in isolation, but the composition of protocols in different layers may be insecure.

Keywords- VoIP, Web Service, Interoperability of H.323 SIP,

Introduction

Voice over Internet Protocol (VoIP) is the communications technology that enables users to route voice conversations over the Internet, or any other IP network, this technology provides the capability of making phone calls over the packet switched networks instead of traditional circuit switched networks. Because of the low cost feature of the internet usage, VoIP can greatly reduce the telephone call costs comparing with the traditional PSTN system.

In general, phone services via VoIP come out to be cheaper than Public Standard Telephone Network (PSTN), because cost savings are recorded due to convergence, wherein voice and data are carried through a single network. VoIP to VoIP calls are generally free, whereas VoIP to PSTN phone calls bear nominal charges Therefore VoIP is attracting more customers from the traditional telephone communication area, and more and more companies prepare to invest in the development and utilization of the VoIP systems. The VoIP will completely replace the circuit switched PSTN system. Since the VoIP technology was first developed, many VoIP protocols have been proposed. H.323 can be considered as the first generation VoIP protocol. H.323 is proposed at first in 1996 by ITU-T and has been updated several times. It suggests a standard for multimedia communication over packet switched network such as LANs, WANs and internet. Now it is one of the most accepted VoIP standards utilized by many VoIP product vendors. The Session Initiation Protocol (SIP) is another VoIP standard proposed by IETF. It includes a suit of call setup and media mapping protocols for multimedia communication over the packet switched network. Due to its simplicity, flexibility and its modular character SIP is becoming one of the most promising VoIP protocols which has attracted. The PSTN can be considered as the traditional communication method, whereas comparing with SIP H.323 can be considered as legacy VoIP protocol, although H.323 is still widely used. With the VoIP technology development the old standards and systems will be replaced by the new ones sooner or later in the future. But it is very important for the customers to protect their capital that has already been invested in the existing telephony service delivery substructure. This means that the traditional PSTN systems and the legacy protocols will coexist in the long run with the new systems and protocols. But the problem is how to reach the interoperability among these protocols. Standards and products have been suggested and developed to achieve the interoperability. In order to realize the interoperation between the VoIP clients and the PSTN pots, a Gateway is

used in the H.323 substructure. The Gateway can interconnect the IP based network with the traditional telephony network. Another solution for the interoperation between different VoIP protocols is also utilizing a signaling Gateway to translating VoIP signaling in real time. A signaling Gateway to translate SIP signaling from the SIP clients to H.323 signaling and vice versa. The above interoperability solutions can only solve the Concurrence problem between two different protocols. They are not able to be extended to accommodate new protocols. In this paper we suggested a common VoIP web service substructure which can facilitate the interoperability among different protocols. The interoperability between POTS phones and VoIP clients, and the interoperability among different VoIP protocols can all be achieved under this substructure. We also propose a VoIP signaling independent VoIP client (called Simple Client) in the substructure to provide a multi-protocol client which can communicate with different VoIP protocol clients without integrating any related protocol into the Simple Client. The rest of this paper is organized The SIP-based VoIP network is useful from the layered approach. Vulnerabilities and countermeasures could be mapped inside the network reference model. The defense strategy consists of three layer security model, conclusions and future work considerations.
Related Works

Interoperability between two different protocols has-been discussed in several documents suggests signaling Gateway to translate the signaling between SIP protocol and H.323 protocol. For the Concurrence between H.323 and PSTN a Gateway is required, which includes Media Gateway, Media Gateway Controller and Signaling Gateway components, is suggested to handle media flow conversion and control, and signaling translation by the ITU-T has also discussed about the Concurrence issues between SIP and PSTN with Gateway. All these above solutions are based on the one to one solution. Starting from the basic OSI Reference Model and the Department of Defense (DoD) or TCP/IP reference model, the SIP-based VoIP network can be analyzed by a layered approach. With this layered analysis strategy, it becomes immediately apparent that each layer has different security threats. The SIP has two biggest challenges are security and NAT/ firewall traversal.
VoIP Web Service substructure

The VoIP web service substructure consists of three layers: Simple Clients Layer, VoIP Web Service Manager Layer and VoIP Protocol Web Service Layer. The Simple Clients Layer consists of Simple Clients, which integrate only media processing and transmission related protocols usually the audio codecs such as PCMU, G.723 etc, and the RTP [6] and RTCP protocols are integrated into the Simple Client. The signaling related protocols are separated from the Simple Client to be implemented as signaling web services which are integrated in the VoIP Protocol Web Service Layer. For example, the protocols such as H.225 and H.245, which belong to the H.323 protocol suit and relate to signaling handling, are integrated into the H.323 Web Service. With separating of the VoIP signaling related protocols the Simple Client can function as different VoIP protocol client through calling different VoIP signaling web service. The VoIP Web Service Manager Layer is a multifunction layer in the VoIP web service substructure. It provides authentication service to control the usage of the VoIP web service system. The accounting service can collect the VoIP resource usage information for the billing purpose. Other management services such as billing service can also be easily integrated into this substructure. The Call Handler is a call session management core service. It creates, monitors, deletes each call session, and it is responsible for the message dispatching, event forwarding etc. It is the bridge among the different VoIP protocol web services. The VoIP Protocol Web Service Layer consists of different VoIP protocol web services. Each VoIP protocol web service exposes common VoIP abstraction interfaces. The common VoIP abstraction interfaces encapsulate the different signaling processing details. With the common VoIP abstraction interfaces different VoIP signaling can interoperate with each other, and the Simple Clients can also call different type clients with web service methods. New VoIP protocols can be integrated into this substructure easily if it can also be encapsulated to Provide the same common VoIP abstraction interfaces. According to our analysis of different VoIP protocols following common VoIP abstraction interfaces are defined to provide the VoIP web services. initCall - Prepare a call. Include checking the authorization, resource availability etc. makeCal l- Send a call setup request to remote endpoint. acceptCall- Accept a call setup request from remote endpoint. denyCall - Deny a call setup request from remote endpoint. endCall - Stop the already connected call. getCallInformation - Retrieve the call related information such as RTP IP address, port number, codec etc which collected during the signaling handling process. callProceeding - Indicate the signaling handling is in progress.

A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machineprocessable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. Figure 1 illustrates the VoIP web service substructure.
Simple clients VOIP Web Service Manager Authentication Call Handler SIP Web service Accounting Availability

callConnect - Indicate call setup success, now the voice over RTP can begin.

H.323 service

web

PSTN service

web

..

Figure1. VoIP Web Service substructure

Vulnerabilities in VOIP protocol, e.g. SIP

In addition to providing telephony services, any VoIP device must provide for mechanisms to protect from toll frauds, eavesdropping and call-hijacking, among other things. SIP was designed only for the purpose of making communications possible. The SIP-based VoIP network is useful from the point-of-view of a layered approach. Threats, and therefore, countermeasures, can be mapped to the layers of the networkreference model. The defense strategy mainly consists of a three-layer security model, which goes as follows:

Privacy/Anonymity: Privacy addresses issues like phone number harvesting, cell pattern tracking, etc. that violates user privacy. Stateful signature: Juniper network provides signatures, which protect against a number of exploits that target Skype, and other VoIP vendors. Protocol anomalies: Recall the chapter covering how Skype fights hacker intrusions. That is a summation of SIP guides, to arrest protocol anomalies, which may vary a lot.

Concurrence under the VoIP web service substructure

Figure 3 shows the interconnection model with the VoIP web service substructure. All the VoIP web services integrate signaling handling related functions. They can be considered as signaling gateways. Other components such as gatekeeper in H.323, SIP proxy in SIP, and Media Gateway (MG) and Media Gateway Controller (MGC) are needed to cooperate with the VoIP web services for Concurrence among different clients. Since RTP is the protocol for media flow transmission for different VoIP protocols, the Simple Client also integrates the RTP protocol to transmit the media flow.

Figure2. The layered approach to threat assessment.

Based on general security precepts on above figure 2, each security layer has to be evaluated based on the following premises:Authentication: Confirm the identity of communicating entities, whether individuals, entities, devices, services or applications, mainly using authentication guards.
Figure3. Heterogeneous VoIP clients interconnection model

Authorization: Cross-checks identity for role and access. This provides unauthorized access to services, and identity frauds. Accountability/Audit: Keeps track of usages, and security services, and provides early intimidation on security threats, and also helps in recovery. Availability/Reliability: Redundancy, perimeter-protection, and hardening ensure that authorized users continue to have access to network services, despite DoS attacks, and other security hazards. Confidentiality: Encryption of communications streams prevents unauthorized entry, with better access control. Integrity: Prevents unauthorized deletion and replication of data. Non-repudiation: A method to prove communications actually occurred.

With the Figure 3 illustrated model different type VoIP clients and POTS phones can interwork under the VoIP web service substructure. In this model a VoIP Web service can act as both web service consumer and Web Service provider. A web service playing which kind of role depends on whether it calls other web service or its service is called. For example, if H.323 Web Service represents a H.323 client to call an SIP client, the H.323 Web Service will request the SIP Web Service to setup the call to the SIP client. In this situation the H.323 Web Service acts as a web service consumer whereas the SIP Web Service acts as a web service provider. A. Address Translation In the VoIP web service substructure there exist different types of clients and to identify the clients different address schemes are to be used. The H.323 address can be presented as IP address, host name, emails address, URL, E.164 telephone number etc. The SIP address can expressed as URL or SIP URI which can in the form of telephone number, user name etc. For the POTS phones E.164 telephone number form is used.

Figure 5 depicts the call setup process when a SIP client calls a H.323 client.

B. Connection Establishment In this paper it gives some scenario examples to explain how to realize the Concurrence between two different VoIP clients. These examples do not cover all call setup possible situation, but the similar scenarios can be deduced from these examples.

Concurrence between Simple Client and VoIP client Figure4 depicts the call setup process when Simple Client calls H.323 client.

Figure4. Simple Client calls H.323 client

When a Simple Client wants to call a H.323 client, it sends the makeCall request to the Call Handler which will forward the request to the H.323 Web Service. The makeCall request includes call setup needed information such as the destination of the call, IP address and port number of the Simple Client for RTP data receiving, and media capabilities of the Simple Client. The H.323 Web Service will now represent the Simple Client to handle the H.323 call setup signaling. Steps 2, 3, 4 are the normal H.323 call setup signaling handling process in case the H.323 client accepts the call request from the Simple Client. After the connection established all media transmission information such as RTP IP address, port number and codec of the H.323 client are collected, the H.323 Web Service sends callConnect message to notify the Simple Client to begin media transmission with RTP. The processes of Simple Client calling other clients are similar except the corresponding VoIP web service will be called to handling the signaling. If a VoIP web service receives a call setup request to a Simple Client from other VoIP client, the request will be forwarded to the

For the Simple Client a URL scheme is defined to be compatible with different address schemes. It can support H.323, SIP addresses and also E.164 telephone number. The Simple Client can call different clients with URLs such as H323:, sip:, tel: The address translation between Simple Client address and other protocol address is simple, since the Simple Client provides other protocol compatible address scheme. In the VoIP web service substructure the address translation is executed by the VoIP Web Service Manager. For the call between the VoIP client and the POTS phone, the E.164 address scheme should be used by both sides to omit the address translation process [11]. During the address translation process the Gatekeeper, SIP proxy and VoIP Web Service manager are needed to resolve the addressed for different protocols.

Simple Client. If the Simple Client accepts the call, the acceptCall response, which includes call setup information as in makeCall, will be sent to the VoIP web service to continue the call setup process. With the support of different VoIP web services the Simple Client can communicate with different VoIP clients. The Simple Client needs not handle the protocol related signaling, this task is handed to the corresponding VoIP web service. The Simple Client needs only to handle media processing and transmission related protocols. With this mechanism the Simple Client can act as a multi-protocol VoIP client.

Concurrence between SIP client and H.323 client

Figure5. SIP client calls H.323 client

When an SIP client requests to call an H.323 client, it sends an SIP INVITE message to the SIP Web Service which will then represent the SIP client to setup the call with the H.323 client. Next the SIP Web Service sends makeCall message to the H.323 Web Service which will then represent the SIP Web Service to call the H.323 client. In succession the normal H.323 call setup signaling handling process begins as illustrated in Figure 4 from Step 3 till 5. After the call connection established the H.323 Web Service sends callConnect message to the SIP Web Service which will then send an SIP 200 (OK) message to the SIP client. After the SIP client sends the ACK message to the SIP Web Service all media transmission needed information is available, and the SIP client and the H.323 client can directly transmit media flows with each other using the RTP protocol. When a H.323 client wants to call an SIP client, the H.323 Web Service and the SIP Web Service will also intermediate the signaling translation. One thing should be remarked is that without Fast Connect mechanism the H.323 clients capabilities can be collected only after the Capability Exchange process, whereas in SIP the capabilities are included in the INVITE message. The [3] suggested method can be used to solve this problem: after the SIP Web Service receives the makeCall request, it sends an INVITE message without session description, and the capabilities of the H.323 client will be sent through the ACK message to the SIP client after the Capability Exchange process are carried out and the H.323 client capabilities are collected.

Concurrence between POTS phone and VoIP client Figure 6 depicts the call setup process when a POTS phone calls an SIP client.

each other. A gatekeeper functions as a zone maintainer, Including address translation and network access control.

Figure.7. H.323 Zone Figure6. POTS phone calls SIP client

When a POTS phone calls an SIP client, its call request will be sent to the PSTN Web Service through the PSTN. The PSTN Web Service then represents the POTS phone to call the SIP client. It sends makeCall message to the SIP Web Service which in turn sends an SIP INVITE message to the SIP client. Since the POTS phone and the SIP client use different media processing mechanism, a Media Gateway must be introduced to do the conversion between the two media flows generated by POTS phone and the SIP client. Therefore the Media Gateway is the endpoint for both POTS phone and SIP client. The call setup information in the INVITE message, such as IP address and port number, codecs etc, is that of the Media Gateway. If the SIP client accepts the call an SIP 200 (OK) message will be sent to the SIP Web Service. After the SIP Web Service sends an ACK message to the SIP client, then it sends callConnect message to the PSTN Web Service which in turn forwards the connection established notification to the POTS phone. In succession the media flow transmission begins between the Media Gateway and the SIP client with RTP protocol, and the Media Gateway will be responsible for media flow conversion and forwarding for the POTS phone. Although in H.323 a Gateway model has been defined to realize the Concurrence between the H.323 client and the POTS phone, and in [5] a SIP PSTN Gateway is used to bridge the SIP clients and POTS phones, the PSTN Web Service provides a VoIP protocol independent mechanism to support different VoIP protocols. Under the VoIP web service substructure the VoIP PSTN Gateway model can still be kept without affect the interoperability between the POTS phone and other VoIP protocols. For example, a POTS phone calls an SIP client through an H.323 PSTN Gateway. The idea is the H.323 PSTN Gateway acts as a normal H.323 client to call the H.323 web service, with the H.323 and SIP interoperability provided by the VoIP Web Service substructure the H.323 PSTN Gateway can calls the SIP client, therefore the connection between the POTS phone and the SIP client can be built.

A zone can also have one or more multipoint control units (MCU) and gateways (GW). An MCU manages multipoint conferences. A GW allows interoperability with other systems such as PSTN (telephone lines). Functions of a MoIP terminal is shown in Fig. 8. Media processing units consists of audio (speech), video, and data channels. An audio compression block reduces the audio bit rates using G.711 (64 kbps), G723.1 (5.3 or 6.3 kbps), or G729. (8 kbps) algorithms, before sending the audio information to the network. Inverse algorithms convert incoming audio information from the network back to the digital audio; similarly, a video compression block reduces the video bit rates using either H.261 or H.263 algorithms, before sending the video information to the network. Inversely, the block also converts the incoming video information back to video data. Both audio and video data have time-stamp provided by real-time transmission protocol (RTP).

Media

Control

data

Audio Codec

Video Codec

RTCP

GK RAS

Call Setup

H.245

T.120

RTP

Q.931

UDP

TCP

IP
Figure.8. Multimedia over Internet protocol, functions based on H.323

Concurrence between OPEN H.323 FOR MOIP As shown in Fig. 7, an H.323-based MoIP(Multimedia over Internet protocol) operates in Zones of Local Area Network where one zone is connected to other zone through the Internet. A zone has one gatekeeper (GK) and more than one terminal endpoints (TE), connected through a LAN. Terminal Endpoints is the place where the user communicates between

Besides audio-visual information, a MoIP terminal provides data input-output. User can send or type in data and receive data. Its applications include messaging, email, chat, or electronic board. Data protocol follows a T. 120 standard. This includes real time control protocol (RTCP) to manage audiovisual packets. Gate keeper (GK) registration admission and status (RAS) allows a link of terminal (or gateway) to a gatekeeper. Call setup 4.931 is a signaling protocol to start and stop a call and connection. H.245 is used between two communicating terminals to negotiate media capability. Both media and data bits are combined into data packets and sent to an Internet network. A local area network (LAN) interface transports the data packets. After the use of 110th IP, the treatment of media information is different from data

information. Media information uses user datagram protocol (UDP) in combination with RTP. This is to ensure timeliness of media information. On the other hand data information uses transmission control protocol (TCP) instead to ensure reliability. TCP forces for an acknowledgment for each packet received. Hence, packet arrivals are guaranteed often through retransmissions. Most control protocols also use TCP for reliability. OpenH323 implements most of H.323 functionalities in a C++ OpenH323 library (see Fig. 8). The library has all H.323 protocol stack and media compression. It uses portable windows Zibrury (PWLIB) to allow easy transportability among different windows platforms such as Microsoft Windows and Linux. Actual applications (e.g., terminals, gatekeeper, and gateways) call OpenH323 library.

Degradation

Score

Performance

Inaudible

Excellent

Audible but not annoying

Good

Slightly annoying

Fair

Annoying
Table 2. DCR levels

Poor

PERFORMANCE AND INTEROPERABILITY ISSUES FOR OPEN H.323 FOR MOIP

This research considers issues such as (i) connection and interoperability, (ii) audio quality, and (iii) video quality. Connection and interoperability is the ability to set-up and maintain a connection between one H.323 terminals to the other. This is especially important because of the connectionless nature of the Internet. This means the ability of the terminal to find its way through the packet network. Another issue is the ability of OpenH323 to interoperate with other H.323 terminals such as Netmeething. This means the ability of openH323 to make a connection and perform communication with them. The measure of connection is setup delay. ETSI TR 101 329 V1.2.5 is a standard for this connection quality [5]. As shown in Table 1, faster set-up time is better.
Performance Level Best High Medium Poor(Best Effort) Time Delay(s) <1.5 1.5 4 47 >7

Video assessment can use similar rating. However, video quality assessment is more complicated due to variability in frames per second and blockiness of the video image. Nevertheless, the DCR approach should be able to cover such degradations.

Conclusion and future works

Since audio and video Compression is well defined in the terminal; audio and video quality assessment focused more on the impacts of degradation caused by the network. The degradation is caused by packet loss, delays, and jitter. Packet loss removes media information, causing degradation due to incomplete information. Delay result in communication inconveniences. Jitter is variations in packet time arrivals, causing sudden and unnatural changes in media information. Audio and Video quality is observed subjectively using degradation category rating (DCR)[5]. For audio quality assessment, a group of listener is asked to listen to a conversion. They are asked specifically to look for signs of quality degradation. As show in table 2, there is no degradation audible. The worst case is if the degradation level into scores. The DCR is then the score average. The quality is excellent if on average the score is 5. The quality is bad if the average is 1.

In this paper we have presented a VoIP based Web Service Substructure which can be used as a general model to facilitate the interoperability among different VoIP protocols. We have used several different scenarios to explain the Connection Establishment like Concurrence between Simple Client and VoIP client, Concurrence between SIP client and H.323 client, Concurrence between POTS phone and VoIP client, and Concurrence between OPEN H.323 FOR MOIP also explain the performance and interoperability issues for OPEN H.323 FOR MOIP. With this substructure all VoIP protocols signaling handling detail will be hidden through the corresponding web service abstraction. Therefore different VoIP protocols can utilize the common web service interfaces to achieve the interoperability. What we have discussed in this paper is a framework for the Concurrence among different VoIP protocols. In our prototype system implementation only the Simple Client has realized the interoperability with different types of VoIP clients. It will be extended to support the encryption methods for Concurrence between H.323 client and SIP client, and the Concurrence between H.323 client and POTS phone etc. Other consideration such as security and additional services like cryptographic algorithms should also be considered in the system. REFERENCES [1] Facilitating the Interoperability among Different VoIP Protocols with VoIP Web Services, Proceedings of the First International Conference on Distributed Frameworks for Multimedia Applications (DFMA05) 0-7695-2273-4/05 $ 20.00 IEEE. [2] D. Geneiatakis, G. Kambourakis, A. Dagiouklas, C.Lambrinoudakis, S. Gritzalis, Session Initiation Protocol Security Mechanisms: A state-of-the-art review, INC'05 International Network Conference, S. Furnell, S. K. Katsikas (Eds.), pp. 147-156, Samos, Greece, Ziti Pubs, July2005. [3] A. Gisler, M. Loretz and A. Stricker, SIP Security, Diplomarbeit, Zrcher Hochschule Winterthur, 2003.

[4] A. Steffen, D. Kaufmann, A. Stricker ,SIP Security, Security Group, Journal : Zrcher Hochschule Winterthur, CH-8401 Winterthur, 2004. [5] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E.Schooler, "SIP: Session Initiation Protocol", RFC 3261, IETF, June 2002. [6]K. Singh, H.Schulzrinne, "Concurrence Between SIP/SDP and H.323", Proceedings of the 1st IP-Telephony Workshop (IPTel'2000), April 2000. [7] Markus Hillenbrand, Ge Zhang, A Web Service Based framework for Voice over IP, Proceeding of the 30th EUROMICRO Conference, August 2004. [8] A. Vemuri, J. Peterson, "Seesion Initiation Protocol for Telephones (SIP-T): Context and Architecture", RFC 3372, IETF, September 2002. [9] H.Schulzrinne, S.Casner, R. Frederick, V. Jacobson, RTP: A Transport Protocol for Real-Time Applications, RFC 3550, July 2003. [10]OpenH323Project http://www.openh323.org/index.html [11] NIST SIP - SIP parser and IP telephony support tools http://dns.antd.nist.gov/proj/iptel/ [12]Java Media Framework http://java.sun.com/products/javamedia/jmf/index.jsp. [13] Java Web Services Developer Pack (JWSDP) http://java.sun.com/webservices/jwsdp/index.jsp. [14] Comparison of SIP and H.323 Protocols, 978-0-76953188-5/08$25.00 2008 IEEEDOI 10.1109/ICDT.2008.14. [15] An Introduction to Standards-Based VoIP SIP, RTP, and Friends, MARCH/APRIL 2010 1089-7801/10/$26.00 2010 IEEE Published by the IEEE Computer Society. [16] John J. Barton, Stina Nylander, Fopefolu Folowosele,(2006), Dialing for Displays: Session Initiation Protocol for Opportunistic Augmentation, Proceedings of the Fourth Annual IEEE International Conference on Pervasive Computing and Communications (PERCOM06). [17] Arup Acharya, Stefan Berger, Chandra Narayanaswami,(2005), Unleashing the Power of Wearable Devices in a SIP Substructure, Proceedings of the 3rd IEEE Intl Conf. on Pervasive Computing and Communications (PerCom 2005). [18] IP Multimedia Subsystem (IMS), 3GP TS 23.228 v8.0.0, 3rd Generation Partnership Project, March 2007[11] M. Hamdi, O. Verscheure, J. P. Hubaux, Voice Service Concurrence for PSTN and IP Networks, IEEE Communications, Vol 37, Num 5, 1999. [19] H.323: Packet-based multimedia communications system", ITU-T Recommendation Nov. 2000.