SIP Working Group H. Sinnreich, Ed. Internet-Draft Adobe Systems, Inc. Expires: August 28, 2008 A. Johnston Avaya E. Shim Locus Telecommunications K. Singh February 25, 2008 Lightweight SIP Toolkit for Peer-to-Peer and Basic Client-Server Systems draft-sinnreich-sip-tools-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. 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 August 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This memo discusses the usage scenario of SIP where all the applications reside in the endpoints. This is an alternative to the current usage of SIP where the services reside in the network. The use of SIP where the applications reside in the endpoints is Sinnreich, et al. Expires August 28, 2008 [Page 1] Internet-Draft SIP Tools February 2008 applicable to P2P SIP networks and also to client-server networks. Such an approach reduces the number of required SIP related standards (as by spring 2008) from roughly 100 to about 11. Successful IP communications must also include the relevant standards for NAT traversal, some of which are not directly related to SIP and also several standards for security. These standards are included in the simple usage scenario for SIP as well. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Using SIP for network based applications is not optimal . 5 2.2. Cost, scalability and reliability of applications . . . . 8 2.3. The endpoint application imperative for SIP deployments . 8 3. Services and Features in User Agents . . . . . . . . . . . . . 10 3.1. Forwarding Services . . . . . . . . . . . . . . . . . . . 11 3.2. Shared Servers . . . . . . . . . . . . . . . . . . . . . . 12 4. Methodology to Develop Lightweight SIP . . . . . . . . . . . . 12 4.1. Updating the use of SIP and SDP . . . . . . . . . . . . . 13 4.2. Re-using other SIP standards . . . . . . . . . . . . . . . 13 5. Presence and Instant Messaging . . . . . . . . . . . . . . . . 14 5.1. Presence . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Instant Messaging . . . . . . . . . . . . . . . . . . . . 14 6. NAT and Firewall Traversal . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7.1. Security for SIP Signaling . . . . . . . . . . . . . . . . 15 7.2. Media Security . . . . . . . . . . . . . . . . . . . . . . 15 7.3. Authenticated Identity for SIP . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Sinnreich, et al. Expires August 28, 2008 [Page 2] Internet-Draft SIP Tools February 2008 1. Introduction SIP standardization was started in the IETF in 1996 in the expectation to have a simple and flexible protocol for establishing multimedia communications. The flexibility of SIP has been a mixed blessing however: SIP has been fully embraced as the standard for IP communications, while at the same time all stakeholders in the communications industry have built equipment and launched services using SIP. As a result, in the over twelve years that have passed, the SIP family of related protocols has grown into approximately 100 RFCs with thousands of pages of specifications [11] and an ever increasing number of Internet Drafts, many of them about to increase even more the large number of existing RFCs on SIP. The ITU-T and other organizations have added to this complexity by layering more and more services on top of SIP. Competitive pressure makes the steady increase in the number of new applications inevitable. This raises the question of how scalable and interoperable can such a multi-service standard be and where does it make sense to draw a line? It is of interest to note that other VoIP and IM protocols that are using servers in the network have comparable large numbers of specifications, similar to SIP, even when no attempt is made to emulate the PSTN and ISDN networks. The meaning in this memo of network based services is any SIP call control feature that goes beyond the remote endpoint discovery and the setting up of a multimedia session. Services such as voice mail, conferencing or call transfer can be implemented either in a feature server or as an application in the endpoints. We will use this meaning to explore the cause of the complexity of SIP. The common root of SIP's complexity is (a) the overuse of the client server model and the resulting migration of endpoint applications, such as voice, presence, IM, video and their various derivatives into (b) 'network based services' trying to emulate the Intelligent Network of the telephone system, especially reincarnations of ISDN type of services. By contrast, simple client-server (CS) systems and peer-to-peer (P2P) SIP systems may not need to support any of the network based services, except the rendezvous function for which SIP was initially designed. Also, by the nature of P2P systems, their architectural difference from client server (CS) systems, P2P SIP systems may need approaches different from those taken in the context of CS SIP to Sinnreich, et al. Expires August 28, 2008 [Page 3] Internet-Draft SIP Tools February 2008 realize various functions. The emergence of P2P SIP raises the question as to what SIP specifications must be used to (1) preserve the core SIP properties, (2) preserve basic interoperability with server based SIP systems and (3) preserve the advantages of SIP for use in P2P communication systems. The objective of this memo is to clarify what SIP specifications are essential to meet these objectives. We will refer for brevity to these essential SIP specifications as 'simple SIP'. In a nutshell, simple SIP uses only message routing required for session initiation and leaves all the complexity of the applications to be handled in the endpoints. Simple SIP is thus an alternative usage scenario to the use and proliferation of feature servers and other elements in the network. This memo is not trying to redefine SIP in any sense since it is based on RFC 3261 and a small number of extension RFCs that tighten the concepts found in RFC 3261, that is define SIP simply as a rendezvous service to discover endpoints and establish a multimedia session between them. The so called 'network based services' using feature servers are not part of RFC 3261 and we also draw here the line for simple SIP. Once a session has been established between endpoints, it is up to the applications in the endpoints how to provide the best multimedia service to the users. SIP call control document [12] and the SIP remote call control specification [13] provide ample evidence that all possible and desirable services can be provided by the endpoints, without any support from feature servers in the network. Also, it is important to note that simple SIP is not a profile of SIP, but an alternative usage scenario to 'network services'. It involves no modifications or subtractions to the MUSTs in RFC 3261. It represents an attempt to reign in the seemingly endless set of SIP extensions which add 'network services' to the native SIP rendezvous and session initiation functions. Though simple SIP is targeted primarily for P2P SIP, simple SIP is also useful for basic CS SIP systems that use the peer-to-peer SIP call control. Peer-to-peer SIP call control is not to be confused with P2P SIP, since it makes no assumption of the existence of a P2P overlay network. However simple SIP and peer-to-peer call control can take full advantage of overlay routing and operations in a P2P SIP system. In conclusion, simple SIP is limited to the original intent of SIP; Sinnreich, et al. Expires August 28, 2008 [Page 4] Internet-Draft SIP Tools February 2008 establishing sessions between endpoints and leaving the applications in the endpoints. Establishing a session also includes the negotiation of the session parameters. The proposed simple SIP benefits users, endpoint manufacturers, application developers and service providers alike, since it fully enables innovations in the endpoints and decouples the network functions of service providers from the endpoints. Simple SIP reduces the cost and complexity for enterprise networks and for service providers alike and these benefits can be passed along to users. Device manufacturers have already proven in commercial products that a P2P PBX for example can be implemented such that all the PBX functions reside in the end devices - the desktop phones, PCs and mobile devices. In the following section we drill into more detail on the problems that are avoided by using simple SIP. To put it another way, the authors encourage engineers and designers to redirect their current efforts and energy away from designing and developing complex network based services and instead focus on innovation in user agent endpoints at the edge of the Internet. Work in this area is much more likely to produce enduring results as it is consistent with the principles and architecture of the Internet. 2. Motivation 2.1. Using SIP for network based applications is not optimal There is a clear distinction between the SIP servers defined in RFC 3261 and feature servers used for network based applications. The SIP server functions in RFC3261 are the registrar, the proxy and redirect and they are used only for routing SIP messages between endpoints, not for the support of applications in the network. This is the key to simple SIP. By contrast, feature servers are dedicated to provide network based applications, such as voice mail, call control server (PBX or local telephone switch), IP Centrex emulation, interactive voice response, presence service, etc. RFC 3261 does not mention any feature servers. Applications in the network are in contradiction with the e2e principle of the Internet. As we will see in the following, contradicting the end-to-end principle of the Internet for applications creates non-trivial technical problems. Adding new network based applications may Sinnreich, et al. Expires August 28, 2008 [Page 5] Internet-Draft SIP Tools February 2008 require massive re-engineering every time and thus complicates or blocks the introduction of innovation. The difficulties resulting from telephony style network based applications are not specific to SIP and RTP. They are also encountered by any other signaling protocols attempting to support network based applications. A similar analysis for H.323 and XMPP is however beyond the scope of this memo, even though it is worthwhile to notice that neither H.323 nor XMPP have been used for multimedia network services to the extent of SIP. The placement of applications in the network will unavoidably lead to SIP network designs that are optimized for one business model or another. In fact, the SIP routing for these networks is actually not designed to enable new services but to make it easy to deny service to those who have not paid for specific service provider applications. This leads to technically indefensible architectures in which, for example, a SIP request between two UAs routes through multiple B2BUAs. Another example is the mandatory use of an outgoing SIP proxy when a mobile user is in a visited network. The sole rationale for the visited proxy is to apply roaming charges, since on the Internet endpoint mobility is a native property. The routing of messages within such SIP networks will therefore reflect the respective business model. Searching for a standard for SIP routing to accommodate different and often competing business models for network based applications is futile. Large SIP networks have such complex routing rules that multi-vendor interoperability is a significant engineering effort or just may not be practical. An example at hand is forking within the network, instead of forking to multiple endpoints only. The special case of forking to several PSTN gateways [15] is best dealt with at the edge between the IP and the PSTN networks and must not burden the SIP routing elsewhere. Another example that shows the complexity and difficulties inherent in network based services is application sequencing. This concept of cycling a request through a parade of stateful B2BUAs in order to provide services seems currently in vogue. Practioners are discovering the need for close coordination, provisioning, and even new protocols and standards are needed to make even simple sequenced applications work. Sequencing adds latency, complexity, cost, unreliability, and compounds security and authentication problems. While this may keep engineers and standards bodies busy for years, it does not solve the root of the problem: that centralized services and features are too complex to scale and interoperate. The showcase of the futility of embedding business models into SIP Sinnreich, et al. Expires August 28, 2008 [Page 6] Internet-Draft SIP Tools February 2008 routing arises when emulating PSTN and ISDN services. For example supporting early media throughout a SIP network is still a topic of much debate. Since early media is required for compatibility with the PSTN, it is best handled at the IP network edge with the PSTN and need not burden the whole SIP network. Many VoIP SIP network designs include intermediaries known as B2BUA that break applications in the endpoints that they don't understand. The use of some B2BUA called Session Border Controllers (SBC) raises fundamental architectural issues that are detailed in [17] and the misuse of B2BUA is still attempted to be minimized or avoided. For example if the communicating user agents can do screen sharing but the intermediate B2BUA can't negotiate that, then the user agents are deprived of this function. See also the generic arguments for preserving the e2e transparency on the Internet [18]. The result of placing features in servers in the network has so far made SIP routing a manual art that requires great expertise and costly engineering, since a SIP routing protocol that can be executed in software similar to IP routing could not be defined. Multi-vendor interoperability in SIP networks is not feasible without detailed custom engineering. The custom engineering effort increases faster than the number of new applications introduced in the network due to the mesh of interdependency of SIP routing and the characteristics of the feature servers. The combined message flows required for SIP signaling between all feature servers, TLS and SRTP key exchanges and message flows, new complex SDP negotiation, NAT traversal, QoS, AAA functions and policy servers is literally overwhelming. The number of messages can reach 100 and more, to support all the feature servers. The total number of servers and other network elements, such as B2BUA is also in the 10- 100 range. Such complexity forces service providers into complete vertical bundles from single vendors who control this complexity by choosing their own shortcuts. Security may be another victim of placing services in the network. The lack of a straightforward standard for SIP routing and the large number of network elements make security audits very difficult. The last defense for network based services is obscuring the network details to the outside using a fronting proxy. This may however provide no protection against network compromise from an insider. The possibility of compromising the network from the inside increases with more application servers in the network. Sinnreich, et al. Expires August 28, 2008 [Page 7] Internet-Draft SIP Tools February 2008 A lot of trust is also required in all intermediaries and a multi-hop SIP signaling path, especially when more than one service provider is involved. In other words, multi-hop SIP signaling may not be secure, and there are discussions on how much trust to put on secure SIP (SIPS). If the last hop is to a PSTN gateway and on the other side of the PSTN may be other gateways to unknown IP networks, SIPS obviously loses its meaning. This item is mentioned here as a caution to avoid PSTN gateways as much as possible, not only for their limitation to narrowband 3.1 kHz audio, loss of IM and video, the inevitable charging for the voice call, but also for security reasons. 2.2. Cost, scalability and reliability of applications Large scale VoIP systems have experienced load problems and there are proposals on how to deal with large loads on SIP servers that support mostly voice. Presence servers in large networks experience both a tremendous message load and require very large storage capacity, especially in interconnected networks. By contrast, distributing the presence processing in the endpoints, no presence servers are required at all. Deployment experience shows that client-server based system scalability comes at a cost that grows faster than the number of new users. This places a practical upper limit on scalability for client- server based VoIP systems. Reliable and robust server-based VoIP infrastructure requires geographically distributed backup servers. These further add to the cost of server based applications. For inter-domain traffic the proxy server function is inevitable, though it can be better distributed in p2p systems as we will discuss below. Note the technical difficulties of server based communication applications have nothing to do with the cost of deploying server hardware, which is low indeed. The operational costs of deploying and maintaining feature servers are discussed separately in the following section. 2.3. The endpoint application imperative for SIP deployments The above deployment problems of network based applications lead to the conclusion that P2P SIP systems are unavoidable for the following expected advantages and characteristics of P2P SIP systems: Sinnreich, et al. Expires August 28, 2008 [Page 8] Internet-Draft SIP Tools February 2008 o Peer routing and discovery protocols in overlay networks are quite mature and sophisticated to meet the requirements of the SIP registration and location service. o The applications can reside in the endpoints. There can be specialized applications that reside in dedicated endpoints, such as proxies to connect to the DNS world and from there to various outside systems. Small scale conferencing can also be hosted in endpoints. Large scale conferencing is better accomplished using application layer multicast. Other types of dedicated endpoints can also perform specialized telephony functions such as the auto- attendant, the receptionist workstation and contact center agent workstation. The main P2P SIP network is however not burdened with any such application functionality. o The overlay network is completely transparent to applications. Current work on P2P SIP networks recommends flexibility in the choice of the P2P overlay, thus further decoupling the P2P network design from the application design. o All peer nodes have identical peer protocol software. o None of the peer nodes require individual user data provisioning from service provider IT systems. o The fulfillment process to add/remove users can be completely separated from all network elements and be delegated to user enrollment servers that are generic to any other Internet type of businesses. They need only provide users with cryptographic keys to execute the fulfillment process for new customers. This is probably the simplest order fulfillment process known today and is the very opposite to the complex fulfillment processes used in telecoms VoIP, where feature servers must be made aware of individual customer data. o P2P SIP systems do not require any manual engineering for operation, no matter if and how many new users or new applications are added. o P2P SIP nodes may use URIs but do not require DNS. ENUM is also not required. Only peer nodes that have off-net connectivity and act as proxies require DNS support. As mentioned, the use of ENUM can be delegated to edge networks that provide PSTN gateway service and ENUM does not need to burden simple SIP. o P2P SIP offers the promise of a scalable rendezvous system without requiring proxy servers or proxy routing. P2P SIP also offers the promise of Contact URIs with GRUU properties but without using the registrar server based acquisition methods in the GRUU specification. o P2P SIP inherits also the generic benefits of p2p systems, such as: * The overlay network is self organizing and requires no manual configuration, Sinnreich, et al. Expires August 28, 2008 [Page 9] Internet-Draft SIP Tools February 2008 * The system is fully decentralized and therefore more robust, * P2P systems are fully scalable and get better the bigger the system grows, * The cost of deploying server farms; computing, bandwidth, real estate and electricity is moved to the endpoints were the incremental cost of P2P is arguably not perceived due to the power of personal computing and broadband connectivity. With this motivation in mind we will explore in the following which SIP and the related standards are required and applicable for P2P SIP and basic CS SIP systems. 3. Services and Features in User Agents Implementing services and features in UAs is actually easy and straightforward to do. A quick survey of the SIP Service Examples and SIP Call Control Framework shows that nearly every feature listed can be implemented in a peer-to-peer manner between two UAs. The fact that some features can be optimized by putting the feature into a network server does not invalidate this observation. Obviously, if network servers are present, it makes sense in some cases to put features and services into them. However, consider this problem the other way: if an architecture does not have any network servers, does it make any engineering sense to add them for services that can be implemented without them? To further the discussion, we have copied Figure 1 from RFC 3261 to make clear what we mean by servers providing only rendezvous functionality. This call flow, apparently unnoticed by many, clearly shows the proxy servers providing the rendezvous functionality by routing the INVITE and 200 OK between Alice and Bob, and then dropping out of the dialog. Of course, this does require that Alice and Bob use Contact URIs that have GRUU properties, but this is solvable. It also requires that Alice and Bob have some authentication/integrity method besides transitivity. Sinnreich, et al. Expires August 28, 2008 [Page 10] Internet-Draft SIP Tools February 2008 atlanta.com . . . biloxi.com . proxy proxy . . . Alice's . . . . . . . . . . . . . . . . . . . . Bob's softphone SIP Phone | | | | | INVITE F1 | | | |--------------->| INVITE F2 | | | 100 Trying F3 |--------------->| INVITE F4 | |<---------------| 100 Trying F5 |--------------->| | |<-------------- | 180 Ringing F6 | | | 180 Ringing F7 |<---------------| | 180 Ringing F8 |<---------------| 200 OK F9 | |<---------------| 200 OK F10 |<---------------| | 200 OK F11 |<---------------| | |<---------------| | | | ACK F12 | |------------------------------------------------->| | Media Session | |<================================================>| | BYE F13 | |<-------------------------------------------------| | 200 OK F14 | |------------------------------------------------->| | | Figure 1: SIP session setup example with SIP trapezoid The exceptions to peer-to-peer implemention in the SIP Service Examples are forwarding services and services where a third server is involved, such as a voicemail server, park server, or music-on-hold server. We will examine these two cases separately. 3.1. Forwarding Services Call Forwarding services are usually shown as being implemented in proxy servers. As this is a rendezvous functionality, this is reasonable. However, it turns out that use of a proxy is not required. For instance, redirection is a reasonable alternative. The redirection provides the rendezvous service but allows the SIP dialog to proceed in a peer-to-peer manner. UAs can provide their own call forwarding busy service. Providing call forwarding when the UA is not connected or signed in is a problem. However, this, too is solvable in two ways. Firstly, the UA could be part of a group of UAs. These UAs could provide various forwarding and storage services on behalf of each other. As a result, as long as one UA in a group is available, the various forwarding services are available for any group member. Another approach could take advantage of P2P overlay Sinnreich, et al. Expires August 28, 2008 [Page 11] Internet-Draft SIP Tools February 2008 routing behavior. Most overlays have the concept of a neighbor node. Neighbor nodes could assume responsibility for providing forwarding services for UAs that are not currently in the overlay. This makes sense since the neighbor node is the node which knows authoritatively that the UA is not in the overlay. Using this approach, call forwarding can be implemented in a peer-to-peer manner even when the UA is not available. 3.2. Shared Servers This section discusses how shared servers such as voicemail, music, park, etc can be provided without requiring centralized network servers. There are two ways this could be implemented. For a group of UAs, a pair of UAs within the group could be elected or assigned to provide these shared services within the group. In a larger overlay, an algorithm could be used to discover and locate UAs which provide these services. For a service such as voicemail, this might seem to have security issues. However, this is only true if the UAs are not using a peer- to-peer security solution. For example, a voicemail prompt could be signed by the UA which recorded it, allowing a listener to verify that this message came from them. The recorded message could also be encrypted with a key that is only available to the destination UA. As a result, any UA could store and forward the message without any loss of privacy or security. Note: the concepts discussed in this section have been proven using commercial products. In other services, there is a centralized server which is arbitrating between UAs. For example, consider the multiple appearances (MA) feature. However, even for this feature, it is possible to implement it in a peer-to-peer manner. For example, if the appearance contention algorithm can be coded and implemented in each UA, there is no longer a need for a centralized server to do the arbitration. Both UAs would discover the contention, both would run the algorithm and come to the same answer. As a result, one would succeed and the other fail - the exact same result as if the server were present. 4. Methodology to Develop Lightweight SIP The method to develop Lightweight SIP has several parts: a. Preserve the basic SIP definitions as per RFC 3261 [2]. SIP can work with or without servers. The trapezoid model in RFC 3261 is only an example. Also, in the trapezoid model no attempt is made to provide any specific services in the network, since the proxies only act as the application level message routers. We do not propose any Sinnreich, et al. Expires August 28, 2008 [Page 12] Internet-Draft SIP Tools February 2008 changes to RFC 3261, to eliminate any methods or headers, error messages, etc., since this would carry among other risks the danger of losing backward interoperability and lack of flexibility. b. Analyze the main SIP related specifications as highlighted and eliminate all network based services residing in servers and various other network elements. c. Adopt the NAT traversal techniques developed for SIP. d. Adopt the security techniques developed for SIP and RTP, to the extent that they are not dependent on central control and on providing network based telephony style services. 4.1. Updating the use of SIP and SDP We do not intend to re-write RFC 3261 for Lightweight SIP, but to take into account later work in SIP. Examples are: o Add items that have been developed in later work on SIP, such as the use of "rport" in the Via header and how to use the connection data "c=" in the SDP body behind a NAT. This information is now used differently as per RFC 3489bis defining the STUN protocol. o Add the offer/answer model with SDP as per RFC 3264 [3]. o Add Locating SIP Servers [4]. o Make TLS mandatory and leave S/MIME optional since it has not found wide acceptance. Note that not using S/MIME does not preclude end-to-end privacy of messages in P2P SIP. End-to-end privacy is still possible in the single hop P2P SIP architecture. o Simplify early media by specifying that User Agents accept but do not generate early media. Early media functionality is best delegated to IP-PSTN VoIP gateway networks. Most of the User Agent behavior described in RFC 3261 can be re-used in Lightweight SIP, while the proxy behavior should be limited to the most basic interoperability between P2P SIP nodes and CS SIP systems. One key difference between RFC 3261 and P2P SIP systems is the replacement of the location database at the back side of SIP proxy and registrar servers with the P2P DHT layer as proposed in [18]. 4.2. Re-using other SIP standards A summary review of the other over roughly 100 SIP related standards reveals that they are mostly dedicated to telephony style of "services in the network" and therefore are out of scope for Lightweight SIP. The only exception is probably RFC 3840 for indicating user agent capabilities [5], such as for various media Sinnreich, et al. Expires August 28, 2008 [Page 13] Internet-Draft SIP Tools February 2008 types and SIP events. 5. Presence and Instant Messaging 5.1. Presence Subscriptions and notifications for presence based on SIP have been defined in [6] and the data format for presence information has been defined in [7]. Rich presence information can be conveyed about the location, activity and other data about a user. Presence can also be used to integrate applications and communications. Such extended applications for presence are however beyond the scope of this memo. 5.2. Instant Messaging Instant messaging for SIP is based on the simple extension "MESSAGE" defined in [8]. Interesting activity information can be conveyed in various ways, such as the indication of "is typing" [9]. 6. NAT and Firewall Traversal While NAT traversal is not strictly speaking a SIP signaling property, we believe that any IP communication and application is useless without complete NAT traversal capabilities. The essential documents for a complete solution for NAT traversal for SIP based communications are referenced here. A. Requirements for NAT to "behave" [19] for UDP packets. B. NAT Traversal for SIP 1. Updating the Via header information with "rport" for symmetric response routing [9]. 2. Connection reuse for "SIP Outbound". C. NAT Traversal for RTP/RTCP Media 1. Symmetric RTP [10] 2. Simple Traversal Under NAT (STUN) 3. Media relay function for STUN servers Sinnreich, et al. Expires August 28, 2008 [Page 14] Internet-Draft SIP Tools February 2008 4. Interactive Connectivity Establishment (ICE) An excellent summary of all the above in the form of deployment examples is given in the document on NAT scenarios. 7. Security Considerations Security for SIP communications touches on both signaling and media. Existing security standards for CS SIP are described here. In P2P SIP systems, besides the security for signaling and media, the additional security for the P2P layer must also be provided. There are no security standards as yet for P2P SIP. 7.1. Security for SIP Signaling SIP secure authentication between the UA and the server is based on the digest authentication schema as specified in RFC 3261. SIP transport security for confidentiality is based on Transport Level Security (TLS) that is also specified in RFC 3261. End-to-end SIP security through intermediaries based on S/MIME has not found wide application at present, so it need not be implemented in Lightweight SIP. Instead, P2P TLS connections should be used to achieve end-to-end security. 7.2. Media Security End-to-end media security without any dependency on intermediaries, such as SIP proxies and certificate authorities will be provided using SRTP. Key management for SRTP is currently an active area of discussion and standardization in the IETF. The authors favor key management approaches that have no reliance on centralized certificate authorities and PKI infrastructures. For VoIP, the recommended protocol is ZRTP protocol [20]. ZRTP is based on users authenticating themselves to each other by voice or video, before activating media encryption for the rest of the conversation and for all following communications. 7.3. Authenticated Identity for SIP In scenarios where the identity and authentication is required, the SIP identity header will be used as described in [23]. In P2P systems, the user enrollment server can be the source for the authentication service. Sinnreich, et al. Expires August 28, 2008 [Page 15] Internet-Draft SIP Tools February 2008 8. IANA Considerations There are no IANA considerations associated with this memo. 9. Conclusions We have shown in this document how the number of SIP related standards for presence, IM and multimedia communications can be reduced by (1) using SIP without network based services and (2) without emulating the telephone network. The approach for Lightweight SIP reduces the number of SIP related standards (as in 2006) from roughly 100 to about 11. Successful IP communications must however include a number of standards for NAT traversal, some of which are not directly related to SIP. The standards for NAT traversal are however referenced here, since SIP based communications must traverse NAT. 10. Acknowledgements We would like to thank Wilhelm Wimmreuter for the detailed review of the initial draft. 11. References 11.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] 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. [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [5] Kompella, K., Rekhter, Y., and A. Kullberg, "Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)", RFC 3480, February 2003. [6] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. Sinnreich, et al. Expires August 28, 2008 [Page 16] Internet-Draft SIP Tools February 2008 [7] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004. [8] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [9] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing", RFC 3581, August 2003. [10] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, July 2007. 11.2. Informative References [11] Ohlmeier, N., "VoIP RFC Watch", http://rfc3261.net . [12] Mahy, R., "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", draft-ietf-sipping-cc-framework-09 (work in progress), December 2007. [13] Audet, F., Johnston, A., Mahy, R., and C. Jennings, "Feature Referral in the Session Initiation Protocol (SIP)", draft-audet-sipping-feature-ref-00 (work in progress), February 2008. [14] Worley, D., "Guidelines for Implementing the Dialog Event Package in User Agents", draft-worley-sip-dialog-03 (work in progress), February 2007. [15] Worley, D., "A New Forking Mechanism for Session Initiation Protocol (SIP)", draft-worley-sipping-forking-02 (work in progress), February 2007. [16] Aboba, B. and E. Davies, "Reflections on Internet Transparency", RFC 4924, July 2007. [17] Rang, T., "Problem Statement for SIP/SIMPLE", draft-rang-simple-problem-statement-01 (work in progress), October 2006. [18] Sinnreich, H. and A. Johnston, "SIP, P2P, and Internet Communications", draft-johnston-sipping-p2p-ipcom-02 (work in progress), March 2006. Sinnreich, et al. Expires August 28, 2008 [Page 17] Internet-Draft SIP Tools February 2008 [19] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [20] Zimmermann, P., "ZRTP: Media Path Key Agreement for Secure RTP", draft-zimmermann-avt-zrtp-04 (work in progress), July 2007. [21] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. Authors' Addresses Henry Sinnreich (editor) Adobe Systems, Inc. 601 Townsend Street San Francisco, CA 94103 Email: henrys@adobe.com Alan Johnston Avaya St. Louis, MO 63124 Email: alan@sipstation.com Ensoo Shim Locus Telecommunications Email: eunsooshim@gmail.com Kundan Singh Email: kundan@adobe.com Sinnreich, et al. Expires August 28, 2008 [Page 18] Internet-Draft SIP Tools February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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). Sinnreich, et al. Expires August 28, 2008 [Page 19]