[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 5638

SIP Working Group                                      H. Sinnreich, Ed.
Internet-Draft                                       Adobe Systems, Inc.
Expires: August 28, 2008                                     A. Johnston
                                                                 E. Shim
                                                Locus Telecommunications
                                                                K. Singh
                                                       February 25, 2008

Lightweight SIP Toolkit for Peer-to-Peer and Basic Client-Server Systems

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 28, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).


   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

   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

   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

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

   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
   o  P2P SIP inherits also the generic benefits of p2p systems, such
      *  The overlay network is self organizing and requires no manual

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
   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

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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Sinnreich, et al.        Expires August 28, 2008               [Page 19]

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/