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

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

SIPPING Working Group                        H. Sinnreich/Adobe, editor
Internet Draft                                        A. Johnston/Avaya
                                                           E. Shim/Locus
Intended status: Informational
November 21, 2008
Expires: May 2009

        Simple SIP Usage Scenario for Applications in the Endpoints

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Copyright (c) 2008 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   "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 is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

   "This document may not be modified, and derivative works of it may
   not be created."

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

Sinnreich                Expires May 21, 2009                  [Page 1]

Internet-Draft      <draft-sinnreich-sip-tools-04>        November 2008

   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 in April 2009.

   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


   For Internet-centric usage, the number of SIP related standards for
   presence, IM and audio/video communications can be drastically
   reduced by using only the rendezvous and session initiation
   capabilities of SIP. The simplification is based on avoiding
   emulating telephony and its model of the intelligent network. Simple
   SIP by contrast relies on powerful computing endpoints. Simple SIP
   desktop applications for example can be combined with rich Internet
   applications (RIA). However, significant telephony features may also
   be implemented in the endpoints.

   This approach for SIP reduces the number of SIP standards to comply
   with, currently from roughly 100 and still growing, to about 10.

   References for NAT traversal and for security are also provided.

Table of Contents

   1.    Introduction................................................3
   2.    Applicability for simple SIP in the Endpoints...............5
      2.1. What simple SIP can accomplish............................5
      2.2. Baseline for simple SIP...................................6
      2.3. What Simple SIP may or may not accomplish.................6
      2.4. What is out of scope for simple SIP.......................6
      Borderline Cases for Out of Scope for Simple SIP...............7

Sinnreich                Expires May 21, 2009                  [Page 2]

Internet-Draft      <draft-sinnreich-sip-tools-04>        November 2008

   3.    Minimal Set of Mandatory SIP References.....................8
      RFC 3261: "SIP: Session Initiation Protocol"...................8
      RFC 4566: "SDP: Session Description Protocol"..................8
      RFC 3264: "An Offer/Answer Model with SDP".....................8
      RFC 3840: "Indicating User Agent Capability in SIP"............9
      RFC 3263: "SIP: Locating SIP Servers"..........................9
      RFC 3265: "SIP-Specific Event Notification"....................9
      RFC 3856: "A Presence Event Package for SIP"...................9
      RFC 3863: "Presence Information Data Format (PIDF)"...........10
      RFC 3428: "SIP Extension for Instant Messaging"...............10
      RFC 4474: "Enhancements for Authenticated Identity Management in
      RFC 3581: "An Extension to SIP for Symmetric Response Routing"10
      Updates to SIP Related Protocols..............................10
   4.    SIP Applications in the Endpoints..........................11
   5.    NAT Traversal..............................................12
   6.    Security Considerations....................................13
      SIP Security..................................................13
         6.2. Datagram Transport for SIP and Media Security.........13
         6.3. ZRTP: Media Path Key Agreement for Secure RTP.........14
   7.    IANA Considerations........................................14
   8.    Acknowledgements...........................................14
   9.    Informative References.....................................14
   Author's Addresses:..............................................17

     1. Introduction

   The Session Initiation Protocol (SIP) has become the global standard
   for real time multimedia communications over the Internet and private
   IP networks, in large part due to its adoption by service providers
   and in enterprise networks. The cost of this success has been a
   continuing increase in complexity to accommodate the various
   requirements for these networks. At the same time, the World Wide Web
   has become the platform for a boundless variety of Rich Internet
   Applications (RIA), both on the desktop and in the browser. For SIP
   to be useful for such as desktop SIP applications and for RIA, legacy
   voice service provider requirements that add unnecessary complexity
   may be avoided, as well as the inheritance of the notion of the
   "intelligent network" from the telephone industry. This requires
   following the end-to-end principle of the Internet architecture at
   the application level, or in other words, placing SIP applications in
   the endpoints.

   There are several reasons to place most or all SIP applications in
   the endpoints and just use the client-server (CS) or peer-to-peer
   (P2P) rendezvous function for SIP:

Sinnreich                Expires May 21, 2009                  [Page 3]

Internet-Draft      <draft-sinnreich-sip-tools-04>        November 2008

     1. Highest quality SIP application software is more easily written
        for endpoints than for distributed SIP systems, since no
        network protocols are required to connect the various
        components if they are running on one single machine.  There is
        also the Internet end-to-end principle that argues that network
        intermediaries cannot completely understand the applications
        and their state in the endpoints.
     2. Eliminating the problems associated with distributed SIP
        applications in various feature servers across the network
        allows us to greatly simplify SIP and was the driver for this

  As an example of a usage scenario, SIP applications in the endpoints
  can be easily mixed with Rich Internet Applications (RIA) and thus
  significantly enhance the value of SIP applications. Rich Internet
  applications support unrestricted user choice as an alternative to
  and beyond what is traditionally prepackaged as network based
  communication service plans.

   We will refer in the following by 'simple SIP' to the SIP functions
   necessary to only support the rendezvous and session setup functions
   of SIP, support voice, video, basic presence and instant messaging
   and also support security. Simple SIP is focused on providing a basic
   multimedia real time communications "call".

   Once the applications have established basic communications, it is up
   to them to support available features selected by users. This paper
   is targeted to such scenarios. In telephony, most of the value to
   users and service providers alike is added by signaling. By contrast,
   on the Web RIA adds most of the value. The combined use of SIP and
   RIA in the endpoints can combine the best of both.

   This approach limits the number of SIP standards to roughly 10 that
   are listed here as the core for simple SIP.

   The total number of references has been kept to a minimum and
   includes other related topics, such as examples for providing
   telephony services in the endpoints, NAT traversal and security. The
   referenced papers are entry points to these knowledge resources.
   Readers interested into a more exhaustive list of SIP topics can
   follow up the short list here with the extensive list in "A
   Hitchhikers' Guide to SIP", RFC (xxxx) [1]. The guide has as of this
   writing over 140 references for understanding most, but not all of
   the published features of SIP in the IETF and elsewhere. There is a
   web site that automatically tracks the number of SIP related RFCs

Sinnreich                Expires May 21, 2009                  [Page 4]

Internet-Draft      <draft-sinnreich-sip-tools-04>        November 2008

   [2]. Other organizations have greatly enlarged the published features
   of SIP as well. We could not actually provide a complete count on
   everything that has been published as some form of SIP standard

   NAT traversal is also a basic requirement for simple SIP. Given
   however the potential option of using the Host Identity Protocol
   (HIP) in SIP enabled endpoints as shown in section 4, simple SIP may
   not require any other standards than those mentioned here. The
   alternative to HIP is to use SIP specific protocols for NAT traversal
   such as STUN, TURN and ICE also discussed in section 4.

   "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   this document are to be interpreted as described in RFC 2119."

         2. Applicability for simple SIP in the Endpoints

   This section aims to clarify the scope of applicability by
   considering what can be done better in the endpoints, what simple SIP
   for user agents can and cannot accomplish and what is out of scope.
   We will use emergency calls as an example to illustrate these points
   on applicability. Emergency calls are also a good example to consider
   if and when SIP plus RIA applications could be used as an emergency
   telephony enhancement or even replacement.

   2.1. What simple SIP can accomplish

   The main driver for SIP applications on the desktop or in the browser
   is to support the integration of SIP and RTP based real time
   communications with RIA. This assumes powerful endpoints, such as
   PC/laptop, smart mobile phones or various dedicated devices.

   Example of better functionality: Emergency calls, not limited to a
   Public Safety Access Point (PSAP), but also extended to a medical
   service taking care of patients or elderly people.

   In this case, besides alerting the right medical provider of the
   emergency, vital body sign data and video can also be transmitted. In
   the opposite direction, the caller may get visual and audio
   information and instructions for instant self-help.  There is no need
   to invoke a PSAP service. A dedicated device for such scenarios may
   actually have an emergency medical call button, though for telephone
   calls to a PSAP this is not recommended [3].  Powerful endpoints may
   also have various means to determine the geographic location and
   transmit it to the emergency provider. In this and other examples,

Sinnreich                Expires May 21, 2009                  [Page 5]

Internet-Draft      <draft-sinnreich-sip-tools-04>        November 2008

   SIP voice may be a component of several other communications means,
   but not always the central one: Some emergency communications and
   data transfer may actually be performed without voice, such instances
   as when the "caller" cannot speak for some reason.

  2.2. Baseline for simple SIP

   The focus of the memo is to define the baseline for simple SIP:  The
   establishment of a one-to-one real-time multimedia communication
   session for presence, IM, voice and video. Adequate security must
   also be provided: Authentication, encryption for the media and for
   parts of the signaling in a manner consistent with the routing of SIP

  2.3. What Simple SIP may or may not accomplish

   There are border cases where simple SIP may or may not accomplish a
   necessary function. Example: An emergency call to a PSAP over the
   Internet may be supported using the SOS URN [4] and the LoST [5]
   protocol to determine where to route the call. If however emergency
   calls must be routed over the PSTN to a country specific telephone
   number; the assistance of a SIP proxy and also a SIP-PSTN gateway is
   required to recognize and route the emergency call. Depending on the
   local jurisdiction, emergency calls from a SIP UA may require other
   features that are beyond the scope of this memo.

  2.4. What is out of scope for simple SIP

   The simple usage of SIP is applicable when avoiding the traditional
   voice provider approaches for charging (or monetizing) that aim to
   provide, manage and charge for what is referred to as services (not
   applications), some examples of which are listed here. This means to
   avoid placing any functions in the network other than the rendezvous
   function of SIP.

  o Avoiding the support of legacy telephony functions, such as
     emulating public telephone switch services and voice-only private
     branch exchanges.

  o Avoiding SIP network architectures designed to support telephony
     type models. Examples include long chains of SIP proxies and
     feature servers, more than the two SIP servers shown in RFC 3262,
     that may be encountered inside and between closed VoIP networks and
     in transit VoIP networks in between. Long chains of intermediaries
     of any type are not only adding complexity, they pose an increased

Sinnreich                Expires May 21, 2009                  [Page 6]

Internet-Draft      <draft-sinnreich-sip-tools-04>        November 2008

     security risk, and also make it more difficult to introduce new
     services. A special problem in SIP server chains is forking that
     leads to the well-known problems of concurrency in computing,
     amplified here by distributing application software over the

  o Avoiding the support for legacy telephony models such as
     identifying end user devices for the purpose of differentiated
     charging by type of service or charging for roaming between

  o Avoiding policies and the associated policy servers and network
     elements for Quality of Service (QoS) to enforce service rate
     specific policies for real-time communications.

  o Avoiding design considerations for SIP for compatibility with
     legacy telephony networks, traditional telephony services and the
     various telephone numbering plans. This pushes the responsibility
     of mapping the URI to telephone numbers to edge networks where the
     IP-PSTN gateway functions are performed. The handling of telephony
     specific functions such as early media are also pushed to edge
     gateway networks. Other design considerations for interworking with
     the PSTN and 'look like the PSTN' are also avoided.

   This list is not exhaustive, but conveys the concept on what to avoid
   when using SIP as a simpler protocol to understand and to implement.

   Borderline Cases for Out of Scope for Simple SIP

   There are also some interesting borderline cases for what to avoid,
   such as the Reliability of Provisional Responses (PRACK) specified in
   RFC 3262. PRACK is targeted for multi-hop SIP server networks and
   PSTN interworking, especially to assure reliable early media. PRACK
   can be delegated, albeit with some limitations to the SIP-PSTN
   gateway. PRACK does little to improve the user experience and has no
   relevance on true broadband networks with minimal SIP hop counts.
   Using PRACK may therefore be a decision best left to designers.

   Another interesting example of a borderline case are issues with
   SIP's Non-Invite transactions as discussed in RFC 4320 [6]. Long
   chains of SIP intermediaries complicate the handling of provisional
   responses and may create several problems such as storms of late
   responses from forked SIP forwarding paths. We mentioned that long
   chains of SIP intermediaries are out of scope for simple SIP, but

Sinnreich                Expires May 21, 2009                  [Page 7]

Internet-Draft      <draft-sinnreich-sip-tools-04>        November 2008

   since designers may encounter various scenarios, even those they
   don't like, the decision to conform the UA to RFC 4320 is best left
   to them.

   The list of borderline cases is also not exhaustive and the above are
   only examples. So where is the borderline? We believe that SIP usage
   on the Internet, without any intermediaries designed to support
   closed VoIP networks eliminates the borderline cases. Enterprise SIP
   proxies are also most useful when designed to work with the Internet
   model in mind. Handling of SIP in enterprise firewalls is out of the
   scope in this memo.

         3. Minimal Set of Mandatory SIP References

   Here is the minimal set of references to support the Internet-centric
   approach to SIP outlined above. The minimal set of references defines
   simple SIP.

   RFC 3261: "SIP: Session Initiation Protocol"

   RFC 3261 [7] is the core specification for SIP. The trapezoid model
   for SIP RFC 3261 is only an example and a use case applicable to two
   service providers featuring an outgoing SIP proxy and an incoming SIP
   proxy in each domain respectively. SIP however can also work in peer-
   to-peer (P2P) communications without SIP servers.

   RFC 4566: "SDP: Session Description Protocol"

   SDP [8] is the standard format for the representation of media
   parameters, transport addresses and other session data irrespective
   of the protocol used to transport the SDP data. SIP is one of the
   protocols used to transport SDP data, to enable the setting up of
   multimedia communication sessions. Other Internet application
   protocols use SDP as well.

   RFC 3264: "An Offer/Answer Model with SDP"

   Though SDP has the capability to describe SIP sessions, how to arrive
   at a common description by two SIP endpoints requires a negotiation
   procedure to agree on common media codecs along with IP addresses and
   ports where the media can be received. This negotiation procedure is
   specified in RFC 3264 [9]. As will be seen in the following on NAT
   traversal, this negotiation is usually considerably complicated due
   to the existence of NAT between the SIP endpoints.

Sinnreich                Expires May 21, 2009                  [Page 8]

Internet-Draft      <draft-sinnreich-sip-tools-04>        November 2008

   RFC 3840: "Indicating User Agent Capability in SIP"

   A SIP UA can convey its capability in the Contact header field
   indicating if it can support such as presence, IM, audio, video, if
   the device is fixed or mobile and other such as the endpoint being an
   automaton; voice mail for example. Which SIP methods are supported
   may also be indicated as specified in RFC 3840 [10]. SIP registrars
   (SIP servers or the P2P SIP overlay) can be informed of endpoint
   capabilities. Missing capabilities can be displayed for the user by
   such as grayed out or missing icons.

   RFC 3263: "SIP: Locating SIP Servers"

   RFC 3263 [11] adds key clarifications to the base SIP specification
   in RFC 3261 by specifying how a SIP user agent (UA) or SIP server can
   determine with DNS queries not only the IP addresses of the target
   SIP servers, but also which SIP servers can support UDP or TCP
   transport as required. TCP may be required to support secure SIP
   (SIPS) using TLS transport or when SIP messages are too large to fit
   into UDP packets. Successive DNS queries yield finer grain location
   by providing NAPTR, SRV and A type records. Note that finding a SIP
   server requires several successive DNS queries to access these

   Locating SIP servers is also required for P2P SIP when a peer node
   wishes to communicate with a SIP UA outside its own P2P SIP overlay

   RFC 3265: "SIP-Specific Event Notification"

   RFC 3265 [12] provides an extensible framework by which SIP nodes can
   request notification from remote nodes indicating that certain events
   have occurred. The most prominent event notifications are those used
   for presence, though SIP events are used for many other SIP services,
   some of which can be useful for simple SIP.

   RFC 3856: "A Presence Event Package for SIP"

   RFC 3856 [13] defines the usage of SIP as a presence protocol and
   makes use of the SUBSCRIBE and NOTIFY methods for presence events.
   SIP location services already contain presence information in the
   form of registrations, and as such can be reused to establish
   connectivity for subscriptions and notifications. This can enable
   either endpoints or servers to support rich applications based on

Sinnreich                Expires May 21, 2009                  [Page 9]

Internet-Draft      <draft-sinnreich-sip-tools-04>        November 2008

   RFC 3863: "Presence Information Data Format (PIDF)"

   RFC 3863 [14] defines the Presence Information Data Format (PIDF) and
   the media type "application/pidf+xml" to represent the XML MIME
   entity for PIDF. PIDF is used by SIP to carry presence information.

   RFC 3428: "SIP Extension for Instant Messaging"

   The SIP extension for IM in RFC 3428 [15] consists in the MESSAGE
   method defined here only for the pager model of IM based on the
   assumption that an IM conversation state exists in the client
   interface in the endpoints or in the mind of the users.

   RFC 4474: "Enhancements for Authenticated Identity Management in SIP"

   RFC 4474 [16] defines (1) an identity header and (2) an identity info
   header for SIP requests that carry respectively the signature of the
   issuer over parts of the SIP request and the signed identity
   information. The signature includes the FROM header and the identity
   of the sender. The associated identity info header identifies the
   sender of the SIP request, such as INVITE. The issuer of the
   signature can present their certificate as well. It is assumed the
   issuer may be the domain owner. Strong authentication is thus
   provided for SIP requests. Authentication for SIP responses is not
   defined in this document.

   RFC 3581: "An Extension to SIP for Symmetric Response Routing"

   RFC 3581 [17] specifies an extension to SIP called "rport" so that
   responses are sent back to the source IP address and port from which
   the request originated. This correction to RFC 3261 is helpful for
   NAT traversal, debugging and support of multi-homed hosts.

   Updates to SIP Related Protocols

   Several of the above are being updated to benefit from the experience
   of large deployments and frequent interoperability testing. We
   recommend readers to constantly check for revisions. One update
   example is

   "Correct Transaction Handling for 200 Responses to the SIP INVITE
   Requests" [18]. This is an update to RFC 3162. The added security
   risk for misbehaving SIP UAs is handled in the forwarding SIP

   More updates are likely to emerge.

Sinnreich                Expires May 21, 2009                 [Page 10]

Internet-Draft      <draft-sinnreich-sip-tools-04>        November 2008

         4. SIP Applications in the Endpoints

   Although the present adoption of SIP is mainly due to telephony
   applications, its roots are in the Web and it has initial similarity
   to HTTP. As a result, SIP may play other roles in adequately powerful
   endpoints (their number keeps increasing with Moore's law). SIP based
   multimedia communications may be linked with various other
   applications. Either some non-SIP application or the communication
   feature may be perceived as the primary usage. An example is mixing
   SIP based real-time communications with some web content of high
   interest to the user.


  1. In a conversation between a consumer and the contact center, a web
     conference can be invoked to present to the user buying options or
     help information. This information can make use of mashups to
     combine real-time data from various sources on the web.
  2. In a social network, multimedia conversations combined with web
     mashups can be invoked thus strengthening the bond between its
  3. Conversations can be invoked while watching sports or political
     events on the web. The main beneficiary in this case may be
     however the web site, since the conversation can prolong the time
     for users watching that web site.

  This shows the value of combining RIA with SIP based communications.

   It is a matter of judgment by the end user if the web content or the
   associated communication capability is more important or if the mix
   of both is most attractive.

   Example:  A web based enterprise directory where employees can find a
   wealth of data. Adding SIP multimedia communications to the
   enterprise directory to call someone if online and not too busy,
   enhances its usefulness, but is not critical to the directory.

   SIP applications in the endpoints can however accomplish most
   telephony functions as well. This has been amply documented in SIP
   related work in the IETF, such as:

  o "A Call Control and Multi-party usage framework for SIP" [19]
     presents a large assortment of telephony applications where the
     call control resides in the participating endpoints that use the

Sinnreich                Expires May 21, 2009                 [Page 11]

Internet-Draft      <draft-sinnreich-sip-tools-04>        November 2008

     peer-to-peer feature invocation model. The peer-to-peer design and
     its principles are based on multiparty call control.

  o "SIP Service Examples" [20] contain a collection of SIP call flows
     for traditional telephony, many of which require no server support
     for the respective features. The SIP service examples for telephony
     are extremely useful, since they illustrate in detail the concepts
     and applications supported by the core simple SIP references.

   In conclusion, SIP applications in the endpoints can support both a
   mix of real-time communications with new rich Internet applications
   and traditional telephony features as well.

         5. NAT Traversal

   SIP devices behind one or more NAT are at present the rule rather
   than the exception. In consequence, IETF contributors to SIP related
   work have published a wealth of information on various tools required
   to solve the difficult problem of NAT traversal for SIP signaling and
   for RTP media streams.

  "Best Current Practices for NAT Traversal for SIP" [21]
  comprehensively summarizes of the use of STUN, TURN and ICE. This
  document provides a definitive set of 'Best Common Practices' to
  demonstrate the traversal of SIP and its associated media through NAT

   The use of ICE has been developed mainly for SIP. Other proposals
   such as NICE, generic for non-SIP, and "D-ICE" for RTSP streaming
   media have also been proposed. Internet games have different NAT
   traversal techniques as well. This list is not exhaustive and such
   approaches are based on different NAT traversal protocols for each
   application protocol separately.

   A general, non-protocol specific approach for NAT traversal is
   therefore highly desirable.

   One approach for NAT traversal that is generic and applicable for all
   application protocols is to deploy the Host Identity Protocol (HIP)
   and solve NAT traversal only once, at the HIP level. HIP has many
   other useful features such as the support for mobility and
   multihoming that are beyond the scope of this paper. "Basic HIP
   Extensions for Traversal of Network Address Translators and
   Firewalls" [22] provides an extensive coverage of the use of HIP for
   NAT traversal.

Sinnreich                Expires May 21, 2009                 [Page 12]

Internet-Draft      <draft-sinnreich-sip-tools-04>        November 2008

   Work is also in progress to prove the use of the Teredo protocol that
   works for both IPv4 and IPv6.
   Using HIP enabled endpoints can provide the functions required for
   NAT traversal [23] for all applications for both IPv4 and IPv6. HIP
   can thus simplify the SIP UA since it takes away the burden of NAT
   traversal from the SIP UA, but moves it to the HIP module in the

         6. Security Considerations

   All protocols discussed in this paper have their own specific
   security considerations that MUST be considered. The special security
   considerations for SIP signaling security and RTP media security are
   discussed here.

  SIP Security

   SIP security has two main parts: Transport security and identity.

  o Transport security for SIP is specified in RFC 3261. Secure SIP has
     the notation SIPS in the request URI and uses TLS over TCP. Note
     that SIP over UDP cannot be secured in this way. Transport security
     works only hop by hop. Specifying SIPS requires the user to trust
     all intermediate servers and no end-to-end media encryption is
     assumed. There is no insurance for misbehaving intermediaries in
     the path. SIPS is therefore really adequate only in single hop

  o RFC 4474: "Enhancements for Authenticated Identity Management in
     SIP" mentioned previously specifies the use of certificates for
     secure identification of the parties involved in SIP signaling

   6.2. Datagram Transport for SIP and Media Security

   The Datagram Transport Layer Security specified in RFC 4347 [24] is a
   comprehensive security solution both for SIP signaling as well for
   RTP media. DTLS has wide applicability for other applications that
   require UDP transport. DTLS has been designed to have maximum
   commonality with TLS yet does not require TCP transport and works
   over UDP.

Sinnreich                Expires May 21, 2009                 [Page 13]

Internet-Draft      <draft-sinnreich-sip-tools-04>        November 2008

   6.3. ZRTP: Media Path Key Agreement for Secure RTP

   ZRTP [25] provides RTP media security without depending on SIP
   signaling, though it can use authentication obtained by SIP signaling
   as well. ZRTP does not require any Public Key Infrastructure (PKI).
   ZRTP uses normal RTP/AVP profiles for codec payload descriptions.
   ZRTP works over UPD since it is designed to provide security for
   real-time media flows. The advantage of ZRTP consists in simplicity
   and its roots in Pretty Good Privacy (PGP) for email.

         7. IANA Considerations

   There are no IANA considerations associated with this memo.

         8. Acknowledgements

   Kundan Singh has contributed to clarify the concepts of simple SIP
   and helped editing all versions of this document. Robert Sparks has
   pointed to some missing references, which we have added.

   The authors would also like to thank Paul Kysivat, Keith Drage, Jiri
   Kuthan, Adrian Georgescu and others for the detailed discussion on
   the SIPPING WG list. As a result, we have added the clarifications of
   what simple SIP can do, what it does not aim to do and some scenarios
   in between. We would also like to thank Wilhelm Wimmreuter for the
   detailed review of the initial draft and to Arjun Roychaudhury for
   the comments regarding the need to clarify what is meant by network
   based services.

   This document was prepared using 2-Word-v2.0.template.dot.

         9. Informative References

   Since this is an informative memo, we provide no list of mandatory
   SIP related standards, but only an informative list of SIP related
   standards and Internet-Drafts that serve us for the purpose of a
   simple toolkit for SIP.

   [1] RFC XXXX: "A Hitchhiker's Guide to the Session Initiation
   Protocol (SIP)" by J. Rosenberg, IETF November 2008.

Sinnreich                Expires May 21, 2009                 [Page 14]

Internet-Draft      <draft-sinnreich-sip-tools-04>        November 2008

   [2] "VoIP RFC Watch by Nils Ohlmeier". Web site counting SIP related
   standards at http://rfc3261.net/"

   [3] B. Rosen and J. Polk: "Best Current Practice for Communications
   Services in support of Emergency Calling". Internet-Draft of the Ecrit
   WG, IETF, November 2008. Work in progress.

   [4] RFC 5031: "A Uniform Resource Name (URN) f or Emergency and Other
   Well-Known Services" by H. Schulzrinne. IETF, January 2008.

   [5] RFC 5222: "LoST: A Location-to-Service Translation Protocol"
   by T. Hardie al. IETF, August 2008.

   [6] RFC 4320: "Actions Addressing Identified Issues with SIP Non-
   Invite Transactions" by R. Sparks. IETF, January 2006.

   [7] RFC 3261: "SIP: Session Initiation Protocol." by J. Rosenberg et
   al. IETF, June 2002.

   [8] RFC 4566: "SDP: Session Description Protocol" by M. Handley et
   al. IETF, July 2006.

   [9] RFC 3264: "An Offer/Answer Model with the Session Description
   Protocol (SDP)" by J. Rosenberg et al. IETF, June 2002.

   [10] RFC 3840: "Indicating User Agent Capabilities in SIP" by J.
   Rosenberg et al. IETF, August 2004.

   [11] RFC 3263: "SIP: Locating SIP Servers" by J. Rosenberg and H.
   Schulzrinne. IETF, June 2002.

   [12] RFC 3265: "SIP-Specific Event Notification" by A. Roach. IETF,
   June 2002.

   [13] RFC 3856: "A Presence Event Package for the Session Initiation
   Protocol" by J. Rosenberg. IETF, August 2004.

   [14] RFC 3863: "Presence Information Data Format (PIDF)" by J. Sugano
   et al. IETF, August 2004.

   [15] RFC 3428: "SIP Extension for Instant Messaging" by B.Campbell et
   al. IETF, December 2002.

   [16] RFC 4474: "Enhancement for Authenticated Identity Management in
   the Session Initiation Protocol (SIP)" by J. Peterson et al. IETF,
   August 2006.

Sinnreich                Expires May 21, 2009                 [Page 15]

Internet-Draft      <draft-sinnreich-sip-tools-04>        November 2008

   [17] RFC 3581: "An Extension to SIP for Symmetric Response Routing"
   by J. Rosenberg and H. Schulzrinne. IETF, August 2003.

   [18] "Correct Transaction Handling for 200 Responses to the SIP
   INVITE Requests" by R. Sparks, Internet-Draft, work in progress,
   IETF, July 2008.

   [19] "A Call Control and Multi-party usage framework for the Session
   Initiation Protocol (SIP)" by R. Mahy et al. Internet-Draft. IETF
   April 2008, work in progress.

   [20] RFC xxxx: "Session Initiation Protocol Service Examples" by A.
   Johnston et al. IETF, November 2008.

   [21] "Best Current Practices for NAT Traversal for SIP" by C. Boulton et
   al., IETF, April 2008. Internet-Draft, work in progress.

   [22] "Basic HIP Extensions for Traversal of Network Address
   Translators and Firewalls" by M. Komu et al. Internet-Draft, IETF,
   October 2008, work in progress.

   [23] "HIP Experimentation using Teredo" by R. Moskowitz. HIPRG in the
   IETF, June 2008. http://www.ietf.org/proceedings/08jul/slides/HIPRG-

   [24] "RFC 4347: "Datagram Transport layer Security" by E. Rescorla et
   al. IETF, April 2006.

   [25] "ZRTP: Media Path Key Agreement for Secure RTP" by P. Zimmermann
   et al. Internet-Draft, IETF, October 2008, work in progress.

Sinnreich                Expires May 21, 2009                 [Page 16]

Internet-Draft      <draft-sinnreich-sip-tools-04>        November 2008

Author's Addresses:

   Henry Sinnreich
   Adobe Systems, Inc.
   601 Townsend Street,
   San Francisco, CA 94103, USA
   Email: henrys@adobe.com

   Alan B. Johnston

   Saint Louis, MO, USA

   Email: alan@sipstation.com

   Eunsoo Shim
   Locus Telecommunications, Inc.
   111 Sylvan Avenue
   Englewood Cliffs, NJ 07632 USA


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

Sinnreich                Expires May 21, 2009                 [Page 17]

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