Peer-to-Peer VoIP & MMoIP for Public Services Requirements and Architecture Nico Schwan, Thomas Strauss, Marco Tomsu (nico.schwan@alcatel-lucent.de, thomas.s.strauss@alcatel.-lucent.de, marco.tomsu@alcatel-lucent.de) Alcatel-Lucent Deutschland AG, Research & Innovation, Lorenzstrasse 10, 70435 Stuttgart, Germany Abstract We discuss a lightweight VoIP model based on a hybrid peer-to-peer (P2P) session control architecture to simplify IP based Voice and Multimedia platforms like IMS, providing a cost-effective solution with standardized interoperability to today s SIP based systems. The defined disruptive architecture offers a carrier grade approach in terms of service integrity and regulatory issues, while still retaining all IMS based telecom operator business opportunities, which are based on owning the user data base, on hosting a flexible application deployment environment offering value-added services to the end-users and on assuring a seamless crossoperator and multi-access interconnectivity. This paper presents the requirements for an open standard based carrier grade solution for the Internet. The architecture includes the basic call system, the service integration and the peering subsystem. An estimation of the performance gain is given and finally the relations to the standardization are described. Index Terms SIP, P2PSIP, VoIP, Hybrid P2P, IMS 1 Introduction There exists a long-held tradition of voice as a unique service, based on decades of POTS. With broadband Internet and more capable end devices revenue chains have changed. Many well accepted voice or instant communication solutions like Skype, Yahoo or GoogleTalk using plain Internet technologies are battling for subscribers. These over-the-top providers are building huge world-wide user communities. Telecom service operators, which are faced with painful voice revenue declines, are forced to react to the longterm risk of loosing large portions of their subscribers, as users usually have a strong and long-term association with their telephone identity. Beyond lowering the prices for their PSTN services offering, telecom network operators are looking for competitive solutions, focusing on broadband Internet based service-oriented models. The deployment of the IMS technology, which fits seamlessly into the existing GSM and NGN softswitch infrastructure (class 4/5 replacement), allows the offering of new IP based real-time and web oriented applications and media-rich personalized services, across any fixed or mobile access network, and for any IP end device. The standardized call control core architecture of IMS is strongly oriented along the traditional revenue models of voice, which are based on per-minutes billing, cross-network roaming and calloriented services, invoked from the call routing/switching engine after the analysis of the signaling content. This fits comfortably for traditional telecom network design norms. Assuming reliable carrier grade first line services, the comprehensive protection of a centralized call control infrastructure requires a strict walled garden security, and the overall cost of system scaling will at the end be influenced to a large extent by counter measures against threats for the service and infrastructure integrity. As more service providers report starting with ROIbased fixed-mobile convergent (FMC) deployments, and then migrating to full IMS deployment, the cost (CAPEX, OPEX) of the implementation must match the revenue opportunity but also be open and extendible to offer a rich set of value added services. Peer-to-peer technology in general promises and has already proven in different application spaces like voice, CDN and video some valuable properties like good scalability in terms of resources, high robustness against system failures and attacks, self-organization and healing at lowest cost. The idea of leveraging on at least some of their design principles to head for the simplification of a next generation IMS seems appealing. In general, P2P systems make use of resources provisioned by users. In fact, today s fixed-mobile convergence is already shifting network costs to customers, e.g. RF coverage via WiFi or Femto, broadband services provisioning and backhauling over consumer s own broadband connection. As a next logical step, a P2P-oriented simplification approach to session control could simply make more usage of the intelligence and resources of distributed IP end devices, e.g. controlled residential gateways (RGW), for the setup of sessions, while retaining the control over valuable services and data. The IETF P2PSIP working group is chartered to develop protocols and mechanisms for the use of the Session Initiation Protocol (SIP) in settings, where the service of establishing and managing sessions is principally handled by a collection of intelligent endpoints, rather than centralized servers as in SIP as currently deployed. [1]
This paper presents some key requirements for carrier grade services in chapter 2, and then motivates and describes a hybrid P2P architecture approach in chapter 3. In chapter 4 a first estimation on the performance gain is given, followed by a discussion of some related standardization in chapter 5 and the conclusion in chapter 6. 2 Requirements The assumed and discussed architecture targets at a lightweight solution deployable on today s Internet. Consequently the network functionality is reduced compared to IMS if it doesn t offer obvious and direct value for the end user. So neither call roaming is assumed in today s flat Internet, nor is call state awareness required for the flat rate billing scheme of Internet business models (free basic services). Subscribed services can be invoked directly by the peers, and that mostly overcomes the classical telephony service triggering model. These design assumptions lead to a disruptive model with the usual loss of some feature continuity. REQ1: A central requirement is a secure, well manageable, scalable and extensible data base for a global subscriber community, as lightweight communication solutions for Internet business models have to potentially scale to >100M members. REQ2: Another central requirement is cost efficient implementation and deployment as the basic communication services may be offered at low cost or even free. These basic services include simple voice/multimedia calls but also basic supplementary services like call completion on busy subscriber, small conference calls, call redirect, call hold or call transfer. REQ3: A solution based on Internet technology has to be basically developed independent from but not agnostic of any IP access network and the connected device types. This includes deployment on thin mobile peers with limited capabilities regarding battery power, bandwidth and storage, as well as fat PC clients or residential gateways. Further they demand support of cross-network mobility on the application level. REQ4: These often not trustable and un-controlled Internet access networks (e.g. any public WLAN hotspot) require the use of encryption for the user data, media and signaling traffic. REQ5: When offered by a traditional voice carrier, a reliable solution must provide a high level of service integrity. This includes thorough security means for any service-critical operator infrastructure. REQ6: The solution must support the integration of valuable end user multimedia services and bundling/blending of several applications. As the basic voice call services are mostly free, advanced valueadded services such as voice box, SPIT and personal preferences filtering, personalized communication assistance, Web integration, interactive IP-TV, gaming and other community applications are creating the necessary differentiators. REQ7: As a central feature of operator networks, interworking to other domains, IMS/SIP systems or PSTN/PLMN networks must be provided for worldwide interconnectivity. This is a major standardization issue. REQ8: Legal interception (LI) is a mandatory regulatory requirement for carriers, but it will be adapted to an Internet environment. While classical telephony always routes any signaling and media traffic through defined intermediary nodes in an operator infrastructure, Internet-oriented solutions make use of new standard mechanisms (e.g. ICE [10]) which allows end devices to setup direct often end-to-end encrypted communication links between peers. The classical voice LI scheme remains still possible at any gateway points to PSTN. As a technical fact, no Internet-based VoIP solution with IP end-to-end traffic can offer 100% undetectable LI in the classical sense. Similar to other Internet applications like IM, email, chat, blogging, it has to rely on existing or new IP-level wiretapping infrastructure, e.g. at the access nodes, the edge router or similar nodes of the ISPs. To support this IP level interception the user-specific device registrations, contacts, usernames and certificates must be made available by the service operator. REQ9: To offer a first-line voice service, emergency calls have to be supported. The mechanisms to direct emergency calls to the right emergency answering point based on given location information are currently under joint definition at several standardization bodies [15, 16, 17]. REQ10: The solution must be based on open and standardized protocols. 3 Architecture 3.1 Motivation A lightweight VoIP (LiVo) architecture is discussed, which is designed for a competitive plain Internet voice market with the goal to attract a huge, global user community with cost effective or even free basic services. Here it is assumed that the cost for operating and securing the call control infrastructure is a significant portion of the overall cost, thus the core infrastructure for delivering standard voice calls between subscribers is reduced to the absolute minimum level. This is achieved by shifting the call control to the peer devices, and no operator resources are burdened by these free services. To enable future valuable personalized and rich
media applications, the main assets are hosted in the domain of the operator similar to IMS: The user data (and the information needed to support ISP LI) are kept in a centralized, mostly stateless and thus highly scalable user database. We assumed that in an operator hosted public service system it might not be acceptable to distribute the user data across possibly insecure client devices, even if pure next generation P2P systems are using a distributed database (DHT) for storage of user data. The architecture allows operators to include on demand and for paying customers so called service peers to offer value-added network services. These services can be executed on IMS application servers. The data base also contains emergency call answering points and other service numbers. For the inter-domain peering already existing border and gateway elements are reused. 3.2 Architecture Overview Figure 1 illustrates the overall architecture. The basic system consists of the IP based user devices, such as soft clients, LiVo hard phones or residential gateways with attached standard SIP or POTS terminals. The clients establish direct signaling and media connections between each other if ever possible. For some cases of end devices in private address domains where a direct connection is not possible, a supportive NAT traversal helper relay in the network can be used. The nucleus of the system is the user database which can be accessed by client devices directly to store or query address-ofrecords (AORs). In the networked services subsystem a service peer acts on behalf of the end user to offer all kinds of value-added networked services, e.g. voice box or SPIT filtering. A peering subsystem provides interconnectivity towards SIP/IMS or PSTN/PLMN networks. For completeness, a dedicated client management system offers the possibility to manage end devices, hosted service components and software upgrades. 3.3 Basic System % & ' ( ))$ The basic system consists of three functions: the client function, the lookup and register function, and the NAT helper function. These functions are enough to provide the core system functionality for basic voice services and most supplementary services. Figure 2 illustrates the functional elements of the basic architecture and indicates the three essential protocols for lookup/registration, signaling and media. The client function (CF), implemented in user hosted devices like PCs or RGWs, does the full call setup and thus is responsible to register in and to query the # ) ) *))+)!" Figure 1 - Overall Architecture registry service for destination lookups. The SIP [3] signaling protocol is used to establish the media connection. Signaling and media both can be end-to-end signed and/or encrypted to traverse un-trusted networks. It is assumed that some user services (similar to the so called PSTN supplementary services) can be implemented directly on endpoints, e.g. do not disturb, call completion on busy subscriber, call forking The registry service, called lookup and register function (LRF) is contacted by a standardized GET/PUT protocol (see chapter 5), including authentication. The LRF stores the Address-of-Records (AOR) for the users and operates without any complex transaction state machines and timers, which makes it a simple server, easy to secure, to load balance and to scale. #!$ Figure 2 - Basic System As many CFs in the Internet may reside behind NAT devices, a NAT helper function (NHF) is required.. For a majority of NATs, but not all of them, a STUN [8] operation to obtain the public address of the NAT is sufficient to allow pass-through of incoming SIP requests. This requires a special socket [10] at the CF, multiplexing incoming and outgoing STUN and SIP messages into a single IP/port pair. For a significant part of NATs, or if this type of socket is not available in the CF, the NHF must provide a public relaying function to this NAT d CF. The NHF assigns a public IP/port to such a CF and this public endpoint is registered in the database as AOR with a corresponding user name. Each NAT d CF maintains a keep-alive connection to its NHF relay to enable the forwarding of incoming INVITEs from the NHF to the CF through the NAT device. The NHF is neither SIP protocol aware nor touches the SIP messages; it just becomes the public endpoint for all incoming requests - and also responses. %,)
Each NHF operates in uni-directional mode towards the UA, so there are several NHFs involved in the communication. During a session initiation dialog the response path is different from the request path; however the connection remains logically P2P. This approach is in principle compliant to the SIP standard [3]; however for this P2P cross-over routing a SIP user agent needs to make dedicated use of the respective header fields (via, contact). GET(Callee) AORs of Callee INVITE 180 Ringing 200 OK The assumption is that significant lower entry barrier can be offered if the infrastructure is only loaded for value added calls, but not for basic calls. A service peer may act e.g. as a voicemail box, a preference module, a personal communication assistant, or a SPIT filter. A service peer whether it is hosted on a network server or a user device serves as a proxy agent for a particular user, e.g. when the user has subscribed to a value-add service or the terminal is offline. A voicemail service peer, for example, registers to the LRF on behalf of the user. Any incoming call will then be made directly to the IP/port of this service peer. From the point of view of the calling peer, there is no difference between a regular peer and a service peer.!"# ) *$ ACK '(( $ BYE $%& 200 OK Figure 3 - Basic call flow in the LiVo model Figure 3 shows the call flow for a basic call. After the initial lookup of the destination address at the LRF, the session signaling messages are exchanged between caller and callee CFs, logically P2P, physically crossover via intermediary NHFs. RTP media can, as in standard SIP, either be relayed via a NHF (as std. TURN) server as indicated in [7], or go directly between the clients, negotiated by the ICE [10] protocol. For simplicity reasons Figure 3 shows the direct media flow without the details of ICE. There are several options on how to control the NHF: One option is that the CF controls its NHF, which could be realized with a slightly amended TURN [9] protocol. Another option would be the use of e.g. H.248 [20] for an operator controlled and assigned NHF. Optional security features of a hosted NHF would be message throughput control, filtering or blocking. 3.4 Network Hosted Services Integration Application logic can be implemented in two types of end-points of the P2P network: user s terminal and service peers. Service peers are nodes that run or aggregate one or more applications, similar to a Service Capability Interaction Manager in IMS. In principle service peers can be hosted by a network operator, by a third party service provider, or by user-owned devices. Assuming that the value of future communication services lies in the personalization and blending of fancy features, service peers will be offered for applications paid by users and running on IMS application servers. "! Figure 4 - Network based voice mail Figure 4 illustrates the integration of a service peer running a network hosted voice mail. Apart from the lookup protocol, the SIP call flow is similar to a standard proxy based IMS system. In both cases the initial INVITE is sent to the proxy or respectively the service peer and is then forwarded (proxy or B2BUA) to an application server. Media traffic in both approaches goes directly between device and application server. To estimate the overall operator infrastructure load, it s important to note that the service peer resources are only needed for some users and calls, namely when the service is utilized. For all those users that do not pay for value added services, or those services that are executed in the clients, no network resources are laded. 3.5 Peering Subsystem The peering subsystem enables clients to establish calls towards other domains, IMS/SIP systems or PSTN/PLMN networks. Basically there are several architectures possible that allow inter-domain peering. The generic peering approach described here is similar to the standard trapezoid approach of SIP domains [14] or IMS. An alternative could be a peering model between different LiVo domains on lookup level, which is not described here. In the generic peering model (Figure 5) the client queries its own LRF and gets an outbound peering peer of its own domain. The client then starts a normal call
attempt, routing the signaling traffic to the peering peer. The peering peer is an adapter that slightly adapts the signaling for a standard SIP gateway (if necessary) and forwards it towards the destination domain, e.g. by use of DNS. In the destination domain a standard SIP proxy, an I-CSCF or another peering peer receives the incoming signaling traffic and processes it accordingly. - ' *$ )! Figure 5 - Peering model 4 Performance Analysis * $ )+ '+ P2P systems leverage from the fact that each new peer joining the system offers some resources to the network, such as CPU cycles and storage to run state machines. By consequently shifting the call control logic to the client devices, the system avoids to burden infrastructure intermediaries to process call control logic (protocol stack and state machine) for all non-service calls, and is thus different from a standard SIP proxy system. The following estimation gives some key performance numbers of the core system for basic calls. The lookup server LRF is (in terms of transaction state machines and number of messages per call setup) a low complexity node and can be compared to a web server as lookup and register transactions are similar to HTTP requests (see Figure 3). Web server benchmarks [6] show that the freely available Apache 2.0 implementation can serve up to 16.000 requests per second, thus a rate of 16.000 CAPS is assumed per LRF with appropriate caching techniques. Considering the fact that some directly interconnected devices (e.g. buddies constantly exchanging their presence information) don t need to query the LRF for most call setups, it indicates that the overall CAPS rate for the entire basic system could be even larger. A NHF implemented similar to an IP router forwarding engine is due to its internal simplicity mainly limited by its network interface bandwidth. Assuming that 100 IP addresses with 50.000 active ports per address can be shared, one NHF can handle up to 5 million simultaneously active ports to serve as public SIP contact point for NAT d devices. We estimate that each NHF connected with a 500 MBit/s link could handle about 20.000 forwarded call attempts per second (f-caps). 20.000 f-caps require a total bandwidth of approximately 470 MBit/s, aggregated by 200 MBit/s for the call control traffic (assumed 10 messages per call and an average of 200 bytes per message), 100 MBit/s for P2P presence exchange traffic and 170 MBit/s for NAT binding keep-alive traffic (for a scenario with 25% registered users in a call, whereas 80% of all users reside behind a NAT and need a NHF as signaling relay). A comparison to a standard C/S SIP system shows that standard SIP proxies usually do not achieve a comparable CAPS rate. In [4] the authors present a study of different proxies with the result that one single machine handles 90 to 700 calls per second depending on configuration and scenario. Although giving just estimations, these numbers indicate at least a potential gain of one order of magnitude in terms of overall system signaling throughput. This cost ratio is further influenced by a different integrity protection effort. It is obvious that a transaction-stateful SIP proxy in the very heart of the operator network, being involved in every signaling process, needs another level of security means compared to the fairly simple wire-speed request / response machine of an LRF. In contrast, a reliable standard SIP system requires more complex security means like a walled-garden infrastructure with SIP aware session border controllers (SBCs). Security, in conclusion, aggravates the cost difference between a standard SIP system and the presented lookup-based approach. 5 Relation to IETF Standardization The discussed solution is oriented along SIP and other related protocols currently under standardization at the IETF. 5.1 Session Initiation Protocol (SIP) Besides the triangle and trapezoid SIP proxy architecture models the SIP standard [3] offers already a direct (i.e. P2P) SIP signaling between end points. Prior to the signaling message exchange the IP address of the callee s device needs to be made available to the caller. One possible way to realize this procedure could be a stateless SIP redirect proxy and registrar function: 1. The caller UA1 sends an INVITE to the redirect proxy, 2. gets a 302 response (redirect) back, pointing to the registered AOR of the callee s UA2, and 3. sends the INVITE directly to the UA2. An important hurdle originates from NAT devices blocking incoming SIP requests that are directed to the callee. Due to the magnitude of NAT variants, [10] has developed several options: 1. SIP signaling is proxy d via the keep-alive link between the outbound Px of the callee and it s UA. 2. For true P2P signaling the messages can be exchanged through a previously created STUN [8] pin-hole. 3. For some NAT devices STUN is not working. The required relaying of SIP messages via an intermediate peer between two such hidden UAs is
not yet defined in the SIP framework, and the SIP community starts addressing this issue with several very recent proposals [13, 18]. The analyzed hybrid P2P architecture model can basically be realized with the standard SIP means, except from the trustable relayed message routing between two NAT d devices. 5.2 P2PSIP Besides the creation of a new trustable secure NAT traversal mechanism, a separation of the registration/lookup protocol from the call signaling itself is introduced in P2PSIP. This protocol mechanism between an UA and a registrar must be defined, because it has not yet been explicitly addressed in standard SIP as a proxy-internal interface [19]. IMS has defined this interface between the CSCF proxy and the HSS registrar and proposes the use of DIAMETER [21]. A DHT is seen as the favorite mechanism to structure the peers, as it enables efficient and full contained storage, lookup and message routing function across widely distributed and dynamic elements [2]. The big challenge here is to define a new trusted peer protocol to build and maintain structured topology, to securely publish, remove and lookup data elements such as AOR or services descriptions, and to provide overlay routing/tunneling functionality. The defined P2PSIP solution must support collapsing the distributed system into a single entity, at least for debugging purposes. A hybrid P2P system can be seen as a variant making use of this data base centralization. To allow clients on less capable devices making use of the data base and routing infrastructure without spending resources to it, a simpler client protocol (potentially a subset of peer protocol, or a SIP derivate) is envisaged. This covers mainly lookup and publish operations, (e.g. put and get ). If a lightweight and efficient client protocol will be created, this would be a valid choice for the lookup procedure in the architecture analyzed in this paper. 5.3 Host Identity Protocol (HIP) HIP [7] is an end-to-end connection protocol on top of IP, which recently included NAT traversal mechanism. Extending existing TCP/IP between L3 and L4 at L3.5, a new host identifier is used for end-to-end connections, while intermediate publicly reachable rendezvous points can act as signaling relay node. This capability could be used to support P2P communication [11, 12]. A non-technical challenge is the required consistent adoption of HIP across the complete solution. A NHF based (= IP/UDP relaying) or a similar solution can be deployed on any standard SIP UA without wide adoption of HIP enhanced TCP/IP stacks within the devices operating systems. 6 Conclusion In this paper we described how far a public service carrier system for VoIP and MMoIP over the Internet can realistically approach the lower bound of network infrastructure. We estimated a significant potential performance gain by limiting network functions to be involved only in valuable application and interworking scenarios. We presented protocol options and the relation to current standardization activities at IETF. It requires deeper analysis of the overall cost model of a telecom operator service platform to give the real influence of optimizing the core call control subsystem. References [1] IETF P2PSIP WG Charter [2] D. Bryan et.al.: Concepts and Terminology for Peer to Peer SIP, 2007, work in progress [3] J. Rosenberg et.al: SIP, RFC3261; 2002 [4] M. Cortes et.al.: On SIP Performance; Bell Labs Technical Journal 2004 [5] Miercom, Lab Testing Summary Report: Feature/application Server with SIP Proxy [6] LiteSpeedtech.com Webserver Performance Benchmarks [7] R. Moskowitz et.al.: HIP, RFC 4423, 2007 [8] J. Rosenberg: STUN draft-ietf-behave-rfc3489bis-07, 2007, work in progress [9] J. Rosenberg et.al.: TURN draft-ietf-behave-turn-04, 2007 [10] J. Rosenberg: draft-ietf-mmusic-ice-17, 2007, work in progress [11] J. Hautakorpi et.al.: Utilizing HIP for P2PSIP, 2007, work in progress [12] E. Cooper et.al.: A Distributed Transport Function in P2PSIP using HIP for Multi-Hop Overlay Routing, 2007, work in progress [13] C. Jennings et.al.: Address Settlement by Peer to Peer, 2007, work in progress [14] J. Rosenberg et.al.: RFC 3263, 2002 [15] IETF ECRIT WG Charter [16] http://www.3gpp.org/ [17] National Emergency Number Association, http://www.nena.org/ [18] V. Gurbani et.al.: Cryptographically Transparent Session Initiation Protocol (SIP) Proxies, ICC 2007 [19] A.Johnston et.al.: SIP, P2P, and Internet Communications, 2006, work in progress [20] ITU-T SG 16, H.248.50 NAT Traversal Toolkit Packages, 2006, work in progress [21] 3GPP TS 29.229 V7.5.0, 2007