P2PSIP M. Stiemerling Internet-Draft M. Brunner Intended status: Standards Track NEC Expires: May 22, 2008 November 19, 2007 Peer-to-Peer SIP Implementation Report draft-stiemerling-p2psip-impl-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 22, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This memo is an implementation report about the peer-to-peer SIP system developed in the European IST Ambient Networks research project. This system replaces the traditional SIP proxy-registrar function with a distributed lookup mechanism, adds overlay functionality to the SIP signalling and to RTP traffic, takes care Stiemerling & Brunner Expires May 22, 2008 [Page 1] Internet-Draft P2PSIP Implementation November 2007 about media/packet relay lookup and insertion into the SIP/RTP paths, plus automatic adaptation of the voice transmission according to changing network conditions. Standard, unmodified SIP user agents are used for communication. The presented system is work in progress and this memo is an attempt to gather IETF community feedback about the described approach. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. SATO System Overview . . . . . . . . . . . . . . . . . . . . . 4 2.1. General concepts of SATO . . . . . . . . . . . . . . . . . 4 2.2. Elements of SATO . . . . . . . . . . . . . . . . . . . . . 5 3. Running Peer-to-Peer SIP . . . . . . . . . . . . . . . . . . . 6 3.1. Registering and Deregistering a User . . . . . . . . . . . 6 4. Running a P2P Call . . . . . . . . . . . . . . . . . . . . . . 7 5. Using HIP in P2PSIP . . . . . . . . . . . . . . . . . . . . . 8 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Stiemerling & Brunner Expires May 22, 2008 [Page 2] Internet-Draft P2PSIP Implementation November 2007 1. Introduction This memo is an implementation report about the peer-to-peer SIP system developed in the European IST Ambient Networks research project. The presented system is work in progress and focusses on voice/video calls but does currently not consider presence and instant messaging. The spread of Internet technology in many types of wireless networks, presenting different features and technologies, has been a revolution for the networking architecture, traditionally based on fixed networks. Nowadays, the interconnection of systems presenting heterogeneous network capabilities, access technologies and end-user devices is becoming a must for many applications and services. The European Community's Sixth Framework Program Integrated Project called 'Ambient Networks' [AMBIENT] is trying to address these challenges, following generalisation and integration procedures. The main objective of the project is the definition of a complete innovative networking model, respondent to the development of mobile network solutions and the integration of different types of fixed and mobile networks. One of the main interests in this kind of network organization is the provision of services to the end-users, in a way transparent to the network specific characteristics as much as possible. In this research area, Overlay Networks have been proved to be a powerful solution for abstracting services from the network connectivity and providing a decentralised network organization. Ambient Networks is defining an overlay service with the concept of Service-aware Adaptive Transport Overlay (SATO). The main purpose is the design of a generalised structure which is able to realise overlay networks on demand, in order to carry multiple applications and to provide them useful functionalitiesrealised inside the network paths. The exchange of multimedia traffic like voice and video is one of the applications which can benefit of SATO. Peer-to-peer SIP has been realised on the SATO platform and this memo gives an overview of the current implementation. The remainder of the document is structure in this way that Section 2 defines the goals of our peer-to-peer SIP system and introduces the system. Section 6 reports some findings. You will find the P2PSIP terminology used within this memo being mainly aligned with the terminology in [I-D.willis-p2psip-concepts]. Stiemerling & Brunner Expires May 22, 2008 [Page 3] Internet-Draft P2PSIP Implementation November 2007 2. SATO System Overview This section describes the overall system of the Service-Aware Transport Overlay (SATO) system used to built a peer-to-peer SIP system. 2.1. General concepts of SATO The purpose of SATO in the Ambient Networks architecture is to provide a flexible and customisable transport service to the application layer by using overlay networks on top of the transport layer connectivity. Further service needed to run such a SATO are included, for instance a distributed lookup service (i.e., DHT but not limited to). Service-aware Transport Overlay Service-aware Adaptive Transport Overlays (SATOs) enable the flexible configuration of virtual networks consisting of Overlay Nodes (ONodes) on top of the underlying basic network connectivity. The Overlay Network topologies are responding to the application needs and can follow point-to-point, point-to- multipoint and multipoint-to-multipoint paradigms. Many SATOs can be created and deployed simultaneously. Dynamic Inclusion of Network Elements The novel SATO concept allows the transparent inclusion of network-side data processing elements (SATO Ports) in the end-to- end transport path (between a client and a server or Peer-to- Peer). These SATO Ports can provide value-added functions such as Overlay routing, smart caching, media adaptation, rate adaptation, synchronisation, filtering, metering, congestion control, etc. On Demand Overlay Set Up and Tear Down Service-aware Adaptive Transport Overlays are designed for accommodating the requests of the application services. As a consequence, they should be established on demand, based on particular requirements, and terminated when the service is not requested anymore (e.g., after the last user has disconnected). Stiemerling & Brunner Expires May 22, 2008 [Page 4] Internet-Draft P2PSIP Implementation November 2007 Overlay Adaptation SATOs could adapt as a consequence of ONodes joining or leaving the virtual network or due to ONodes with changing context or as a result of adaptation requests from other Ambient Networks Functional Entities. This introduces the notion of Oadaptive overlaysO that dynamically re-configure in order to optimise the service delivery. Dynamic adaptation of a SATO can also take place in response to changes in other Functional Entities (FEs) or in the underlying network. SATO adaptation requires significant, time-consuming control space activities possibly involving interactions between many FEs. Highly dynamism or fast alterations within SATOs can therefore be addressed by means of internal SATO routing capabilities. 2.2. Elements of SATO The core of the SATO P2PSIP systems are the SATO overlay nodes. These nodes are P2PSIP overlay peers participating in the peer-to- peer routing. Each overlay peer hosts a modified SIP proxy, RTP proxy, and the overlay manager. The overlay manager is in charge of controlling the overlay, providing a distributed lookup service for users and media relays, etc. Additionally, overlay peers can host media relays that are offered to other peers in order to assist in NAT/firewall traversal. Figure 1 shows the overlay peer building blocks. +-------------------------------------------+ | | | +---------+ +---------+ +---------+ | | | | | | | | | | | RTP | |modified |<~~~~>| Overlay | | | | Proxy <~~> SIP | | Mngr <=====> | | | | Proxy | | | | | | | | | | | | | +----+----+ +----+----+ +---------+ | | | | | | v v | | Overlay Peer | +-------------------------------------------+ <~~~> Overlay Peer Internal Control <===> Overlay Peer Protocol ----> IP socket interface Figure 1: P2PSIP overlay peer Stiemerling & Brunner Expires May 22, 2008 [Page 5] Internet-Draft P2PSIP Implementation November 2007 The overlay manager uses Web Services (chosen for rapid prototyping for the P2PSIP Overlay Peer Protocol) to communicate with other overlay managers on other peer nodes. The overlay peer internal communication is using Unix sockets. The SIP proxy is using an off the shelf SIP stack with modified routing, i.e., peer-to-peer routing, stores the user records in a DHT (see next paragraph), and a slightly changed interface to the IP sockets. The RTP proxy is off the shelf as well. The connections between two SIP proxies or two RTP proxies on different overlay peers can use any type of transport protocol or network layer setting, e.g., TCP running over IPsec. The used transport protocol, IP version, encryption, etc is negotiated via the overlay managers. Not shown in Figure 1 is the distributed lookup service for storing P2PSIP overlay user records and location information for media relays. For both, the user records and the media relay location, a mapping of the respective information to the IP address of the overlay peer is stored. The bamboo DHT implementation [BAMBOO] is currently used for storing this information. 3. Running Peer-to-Peer SIP The SATO P2PSIP system is built in such a way that traditional SIP UA can participate without any modification. The SIP UA use their standard way of SIP and RTP for signalling and media. The SIP UAs in the example below use SIP with UDP transport. The settings of the UAs need just to point for the SIP registrar and outbound proxy to their overlay peer (see also Figure 2. So, all outgoing SIP signalling messages will be forwarded to the respective P2PSIP overlay peer. 3.1. Registering and Deregistering a User This section assumes an in advanced happening enrolment process for the user with the P2PSIP system. The enrolment process has not been defined and implemented. The SIP UA proceeds with the standard registration process as defined in [RFC3261] either UDP or TCP to the P2PSIP overlay peer, i.e., the P2PSIP Overlay Client Protocol is standard SIP. The P2PSIP registrar (part of the proxy here) uses in the SATO P2P system currently only the user part of the SIP URI for the registration process. The P2P SIP registrar stores the given user part of the URI in the DHT together with its (or one of its) IP addresses. The real location of the UA is only stored in the P2PSIP registrar. The entry in the DHT and P2PSIP registrar is deleted, when the user Stiemerling & Brunner Expires May 22, 2008 [Page 6] Internet-Draft P2PSIP Implementation November 2007 should be deregistered, i.e., either by timeout of the registration or explicitly request. 4. Running a P2P Call Placing a call from one UA1 to UA2 (see Figure 2) is again following the possible call flows in [RFC3261] from UA to P2PSIP overlay peer. The SIP proxy at the overlay peer receiving the call request (SIP) is using the user part of the SIP URI for the DHT lookup. If the user is registered in the DHT, i.e., register at some overlay peer, the IP address of the serving overlay peer is obtained. Otherwise a 404 (Not Found) response is generated and send to the UA. This IP address is transfered from SIP1 to the local overlay manager OM1. OM1 uses the P2PSIP Overlay Peer Protocol to contact OM2 on the target overlay peer where UA2 is registered to. OM1 and OM2 negotiate the possible and by the SIP proxy desired transport connection between SIP1 and remote P2PSIP proxy SIP2. Once the transport connection between SIP1 and SIP2 is setup, both are notified about this. SIP1 forwards the SIP messages from UA1 (with modified values of some SIP headers to reflect the routing) to SIP2 via this transport connection (TCP in the example). SIP2 in turn forwards the message to UA2. Subsequent SIP messages are transfered via this transport connection. +----------+ +----------+ | +------+ | | +------+ | | | OM1 |#################| OM2 | | | +------+ | | +------+ | | | | | +------+ SIP | +------+ | | +------+ | SIP +------+ | UA1 +-------+ SIP1 *=================* SIP2 +-------+ UA2 | +--+---+ | +------+ | | +------+ | +--+---+ | | | | | | | | +------+ | | +------+ | | +-----------+ RTP1 *=================* RTP2 +----------+ | +------+ | | +------+ | +----------+ +----------+ ---- UDP protocol ==== TCP protocol (or what you have) #### Webservice via TCP Figure 2: P2PSIP overlay network In the process of the call signalling, both P2PSIP proxies (SIP1 and Stiemerling & Brunner Expires May 22, 2008 [Page 7] Internet-Draft P2PSIP Implementation November 2007 SIP2) will replace the media IP address(es) and port(s) by an IP address and port of their local RTP proxy. The SDP part of UA1 will be replaced with IP addresses/ports of RTP2 and of UA2 with IP addresses/ports of RTP1. This behaviour can turned on or off per configuration in the respective P2PSIP proxies if the media should delivered directly between UA1 and UA2. OM1 and OM2 will take care of setting up the desired transport connection between RTP1 and RTP2. The example uses TCP but any other transport can used. Now the call can proceed and when the call ends all transport connections between SIP1/SIP2 and RTP1/RTP2 are torn down. 5. Using HIP in P2PSIP This section briefly describes how the P2PSIP system is using Host Identities and the Host Identity Protocol (HIP) (see [RFC4423] and [I-D.ietf-hip-base]) for establishing a secure communication between different nodes and to securely identify nodes. Each node participating in the Ambient Networks Peer-to-Peer SIP network has assigned a Host Identity and publishes his Host Identity Tag (HIT) with all of its information in the distributed database. Typically, the HIT is used to setup the communication between both hosts and to maintain it even when the IP address is changing (mobility or just assignment of another IP address through DHCP). The P2PSIP implementation relies on HIP's IPsec usage (preferably the BEET mode [I-D.nikander-esp-beet-mode]) for providing authenticated and encrypted data transmission between two nodes. The HIT is also used to ensure that the contacted host is rely the desired host, as stored in the distributed database. The P2PSIP implementation assumes that HIP is able to find the mapping between a HIT and the locator set, i.e., resolving the HIT used by P2PSIP to an IPv4 or IPv6 address usable by HIP itself. It should be noted that this step is not yet fully solved in HIP, other than doing some add-ons to the DNS. HITs are not revealed to the SIP user agents, as they just see and use IPv4 addresses and host names in the regular SIP signalling. However, within the P2PSIP overlay, HITs are used within the SIP signalling and also used to route messages. HITs simply appear as IPv6 addresses in the SIP signalling and can so easily be handled by existing SIP stacks. The current prototype implementation goes even a step beyond HIP, as it is using the Node ID architecture. This architecture is described in [ref.node-id]. Stiemerling & Brunner Expires May 22, 2008 [Page 8] Internet-Draft P2PSIP Implementation November 2007 6. Conclusions This memo sketches the Ambient Networks SATO-based peer-to-peer SIP system, which is one possible way to realise such a P2PSIP system. It uses a generalised overlay deployment system, a well-known distributed lookup service and unmodified SIP stacks in proxies and user agents. Not yet described but also implemented is the lookup of media/packet relays and their inclusion into the overlay network. This enables support for NAT/firewall traversal of signalling and data. The exact changes in the SIP routing and the SIP header values are not yet listed in this memo, but will be added to the next revision. The intention of this document is raise further discussions and not to give a final recommendation or similar. 7. Security Considerations To be done. 8. Acknowledgements Martin Stiemerling and Marcus Brunner are partly funded by Ambient Networks, a research project supported by the European Commission under its Sixth Framework Program. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Ambient Networks project or the European Commission. 9. References 9.1. Normative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 9.2. Informative References [AMBIENT] "IST project 507134 Ambient Networks (AN)", Web Site http://www.ambient-networks.org, October 2006. [BAMBOO] "BAMBOO DHT", Web Site http://bamboo-dht.org/, Stiemerling & Brunner Expires May 22, 2008 [Page 9] Internet-Draft P2PSIP Implementation November 2007 October 2006. [I-D.ietf-hip-base] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-06 (work in progress), June 2006. [I-D.nikander-esp-beet-mode] Melen, J. and P. Nikander, "A Bound End-to-End Tunnel (BEET) mode for ESP", draft-nikander-esp-beet-mode-06 (work in progress), August 2006. [I-D.willis-p2psip-concepts] Willis, D., "Concepts and Terminology for Peer to Peer SIP", draft-willis-p2psip-concepts-03 (work in progress), October 2006. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [ref.node-id] Ahlgren, B., Arkko, J., Eggert, L., and J. Rajahalme, "A Node Identity Internetworking Architecture", April 2006. Authors' Addresses Martin Stiemerling NEC Network Laboratories Europe/University of Goettingen Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342 113 Fax: +49 6221 4342 155 Email: stiemerling@netlab.nec.de URI: http://www.netlab.nec.de/ Stiemerling & Brunner Expires May 22, 2008 [Page 10] Internet-Draft P2PSIP Implementation November 2007 Marcus Brunner NEC Network Laboratories Europe Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342 129 Fax: +49 6221 4342 155 Email: marcus.brunner@netlab.nec.de URI: http://www.netlab.nec.de/ Stiemerling & Brunner Expires May 22, 2008 [Page 11] Internet-Draft P2PSIP Implementation November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Stiemerling & Brunner Expires May 22, 2008 [Page 12]