[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/Avaya
                                             K. Singh/Columbia U. Alumni
Intended status: Informational
June 29, 2009
Expires: December 2009




        Simple SIP Usage Scenario for Applications in the Endpoints
                      <draft-sinnreich-sip-tools-07>




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) 2009 IETF Trust and the persons identified as the
   document authors. All rights reserved.

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

   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





Sinnreich               Expires December 2009                  [Page 1]

Internet-Draft      <draft-sinnreich-sip-tools-07>            June 2009


   This Internet-Draft will expire in October 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
   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."

   Abstract

   For Internet-centric usage, the number of SIP required standards for
   presence; IM and audio/video communications can be drastically
   smaller than what has been published, 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 can be combined
   with rich Internet applications (RIA). 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 11.

   References for NAT traversal and for security are also provided.

Table of Contents

   1.    Introduction................................................3
   2.    The Endpoint in the SIP and Web Architectures...............5
      The Telephony Gateway as a SIP Endpoint........................7
   3.    Applicability for 'simple SIP' in the Endpoints.............7
      What 'simple SIP' can accomplish...............................7
      Baseline for 'simple SIP'......................................8
      What 'simple SIP' may or may not accomplish....................8
      What is out of scope for 'simple SIP'..........................8
      Borderline cases...............................................9
   4.    Mandatory SIP References for Internet-Centric Usage........10
      RFC 3261: "SIP: Session Initiation Protocol"..................10
      RFC 4566: "SDP: Session Description Protocol".................10
      RFC 3264: "An Offer/Answer Model with SDP"....................11


Sinnreich               Expires December 2009                  [Page 2]

Internet-Draft      <draft-sinnreich-sip-tools-07>            June 2009


      RFC 3840: "Indicating User Agent Capability in SIP"...........11
      RFC 3263: "SIP: Locating SIP Servers".........................11
      RFC 3265: "SIP-Specific Event Notification"...................11
      RFC 3856: "A Presence Event Package for SIP"..................12
      RFC 3863: "Presence Information Data Format (PIDF)"...........12
      RFC 3428: "SIP Extension for Instant Messaging"...............12
      RFC 4474: "Enhancements for Authenticated Identity Management in
      SIP"..........................................................12
      RFC 3581: "An Extension to SIP for Symmetric Response Routing"12
      Updates to SIP Related Protocols..............................13
   5.    SIP Applications in the Endpoints..........................13
   6.    NAT Traversal..............................................14
   7.    Security Considerations....................................15
   8.    IANA Considerations........................................16
   9.    Acknowledgements...........................................16
   10.   References.................................................16
      10.1 Mandatory References.....................................17
      10.2 Informative References...................................17
   Acknowledgment...................................................19


     1. Introduction

   The Session Initiation Protocol (SIP) has become the global standard
   for real time multimedia communications over the Internet and in
   private IP networks, due to its adoption by service providers and in
   enterprise networks alike. The cost of this success has been a
   continuing increase in complexity to accommodate the various
   requirements for such networks. At the same time, the World Wide Web
   has become the platform for a boundless variety of Rich Internet
   Applications (RIA), both in the browser and on the desktop. For SIP
   to be useful for RIA, legacy voice service provider requirements that
   add unnecessary complexity may be avoided by delegating the
   interworking to telephony gateway endpoints. This usage scenario for
   SIP 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 from the Web services perspective 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 December 2009                  [Page 3]

Internet-Draft      <draft-sinnreich-sip-tools-07>            June 2009


   1. Value proposition: SIP applications in the endpoints can be easily
      mixed with RIA and thus enable service providers to offer new
      services in a scalable and flexible manner as well as
      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.

   2. Eliminating the problems associated with distributed SIP
      applications in various feature servers across the network allows
      us to greatly simplify SIP. 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.

   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". This includes presence,
   instant messaging, voice and video for point to point and various
   conference applications. One or a very small number of additional
   servers may also be provided, for example a voice mail server as an
   auxiliary to making a simple one-to-one call to voice mail if the
   callee does not answer, or to check voice mail.

   Once the applications in the endpoints 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 integrated use of SIP and RIA in the endpoints can combine
   the best of both.

   This approach limits the number of SIP standards to roughly 11 that
   are listed here as the core for simple SIP. At the time of this
   writing, the Real-Time Applications and Infrastructure (RAI) area of
   the IETF is focused on a dedicated working group for the core SIP
   protocol, separate from various SIP applications. We anticipate this
   emerging work will also be the core of what is termed here as 'simple
   SIP' and will actually further reduce the number of references that
   reflect the present core SIP standards.

   This memo aims to shield Web application developers from the need to
   know or understand more than the core SIP protocol. 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


Sinnreich               Expires December 2009                  [Page 4]

Internet-Draft      <draft-sinnreich-sip-tools-07>            June 2009


   endpoints, NAT traversal and security. The referenced papers are
   however entry points to these knowledge resources. Readers interested
   in a more detailed list of SIP topics, especially telephony, can
   follow up the short list here with the extensive list in "A
   Hitchhikers' Guide to SIP", RFC 5411 [12]. The guide has over 140
   references for understanding most, but not all of the published
   features of SIP in the IETF and elsewhere. There is also a Web site
   that automatically tracks the number of SIP related RFCs [13]. Other
   standards and commercial 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 document.

   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 discussed in section 4.

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


         2. The Endpoint in the SIP and Web Architectures

   SIP has been defined in RFC 3261 for rendezvous and session
   initiation. The usual example is the trapezoid model for
   communications between two endpoints placed in two different SIP
   service provider domains. SIP is also flexible, since SIP
   applications beyond the rendezvous function can reside either in the
   SIP networks in additional feature servers and media servers, or in
   the endpoints. SIP endpoints are our focus in this memo.

   Since SIP has been invented, with much initial similarity between SIP
   and HTTP, the Web has evolved from a global access mechanism to
   static documents, to a universal platform with rich interaction
   between the user and the client. In most cases the client is the
   browser, though recently dedicated Web desktop clients have emerged
   as well.

   The Web provides access to applications as well as to documents. It
   is beyond the scope to describe here the application and network
   architectures of the Web. We will note however some of the new
   application and communication forms that have emerged on the Web as a
   result of a Darwinian evolution [30], rather than being defined in


Sinnreich               Expires December 2009                  [Page 5]

Internet-Draft      <draft-sinnreich-sip-tools-07>            June 2009


   standards organizations. They are referred to as Rich Internet
   Applications.

   Examples of RIA include social networks, blogs, wikis, web based
   office and collaboration tools, task related apps for to-do lists,
   tracking time, combining geographic information with various
   applications such as tracking exercise paths and recording the
   metrics, tracking airline flights, combining live video from events
   with results and comments, etc.

   More information can be found at [31] and in the vast collection of
   books about RIA.

   RIA have positioned the browser and associated Web desktop
   applications, as the dominant platform for a large variety of
   applications. They are universal application platforms, independent
   of network location, operating system, processor or display size.

   Behind the better-known Web applications are a wealth of new
   technologies that can enhance SIP based communications, for example
   the aggregation of data at runtime from several resources on the
   Internet. A variety of RIA components, such as found on interactive
   Web pages can significantly improve the user experience of SIP based
   communications. This is in contrast to the fixed interfaces found in
   most SIP User Agents such as phones and desktop clients.

   The Web network and application architecture is very different from
   SIP service provider networks at present, but the one point where
   they both meet is the end user device of any shape, fixed or mobile.

   The desire by SIP service providers to support new services in a
   scalable and flexible manner is incidentally easier to implement by
   the loose service coupling on the Web: Characterizing a service, or
   actually a mix of several service components (such as in a mash-up)
   by a URI. This is in contrast to network services registration by a
   central registrar. The Web architecture is also better suited for
   users to select and configure their applications and interaction mode
   with the client. The boundless variety of configurations of services
   and client settings on the Web is in contrast with the prepackaged
   services and fixed user agent configurations in present SIP services.

   Last but not least, program execution locally on the client is faster
   if the interaction with servers across the network is minimized.

   The potential of integrating SIP based multimedia communications
   with access to RIA on the Web is the motivation behind this memo. To
   mention a few scenarios: Adding SIP and RTP based real-time


Sinnreich               Expires December 2009                  [Page 6]

Internet-Draft      <draft-sinnreich-sip-tools-07>            June 2009


   communications to RIA, integrating from a user perspective the SIP
   location service (not to be confused with geographic location
   services) with other desktop and network based geographic location
   services, using social networks as part of the contact list, etc.

   The Telephony Gateway as a SIP Endpoint

   Integrating SIP communications into RIA precludes in our opinion
   carrying over to the Web legacy telephony features in order to
   accomplish interoperability with the installed base of telephone
   networks of various kinds. Interoperability between the Internet and
   telephone networks is best left to gateways that look to the Web as
   special endpoints serving large numbers of users. Plain one-to-one
   phone calls are already supported by Internet-to-telephony gateways.
   If added PSTN or ISDN telephony features must be exposed to Web
   users, visual Web display and interaction with the user is preferable
   to carrying the extremely complex SIP equivalents over into the
   Internet. On the Internet side of telephony gateways, simple SIP is
   all that needs to be deployed in our opinion. Additional telephony
   features can be just another RIA hosted in the gateway. The market is
   the best indicator to show if such an effort is worthwhile to be
   productized.

   Overloading simple SIP with telephony features is a non-objective as
   detailed in section 3.

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

  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.



Sinnreich               Expires December 2009                  [Page 7]

Internet-Draft      <draft-sinnreich-sip-tools-07>            June 2009


   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. In this scenario,
   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 [14].
   Powerful endpoints may also have various means to determine the
   geographic location and transmit it to the emergency care provider.
   In this and other examples, 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.

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

  What 'simple SIP' may or may not accomplish

   There are border cases where simple SIP may or may not accomplish
   some necessary legacy function. Example: An emergency call to a PSAP
   over the Internet may be supported using the SOS URN [15] and the
   LoST [16] 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.

  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.





Sinnreich               Expires December 2009                  [Page 8]

Internet-Draft      <draft-sinnreich-sip-tools-07>            June 2009


      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 network models. Examples include long chains of
         SIP proxies and feature servers, more than the two SIP servers
         shown in RFC 3261, 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 a security risk that increases with the
         number of SIP network elements. Complex server based networks
         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; the so-
         called race conditions in telephony. This is amplified by
         redesigning the whole network every time there is new SIP
         routing requirement.

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

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

   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


Sinnreich               Expires December 2009                  [Page 9]

Internet-Draft      <draft-sinnreich-sip-tools-07>            June 2009


   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 the issues with
   SIP's Non-Invite transactions as discussed in RFC 4320 [17]. 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
   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
   networks are also most useful when designed to work with the Internet
   model in mind; by giving enterprise users the benefit of SIP enhanced
   Web applications for productivity. Handling of SIP in enterprise
   firewalls is out of the scope in this memo.

         4. Mandatory SIP References for Internet-Centric Usage

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

   The proposed change process [29] for SIP in the IETF RAI area will
   define the updated SIP core specification and thus reduce even more
   the required SIP standards for what is referred here to as 'simple
   SIP'.

   RFC 3261: "SIP: Session Initiation Protocol"

   RFC 3261 [1] 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 [2] is the standard format for the representation of media
   parameters, transport addresses and other session data irrespective


Sinnreich               Expires December 2009                 [Page 10]

Internet-Draft      <draft-sinnreich-sip-tools-07>            June 2009


   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 [3]. 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.

   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 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 [4]. 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 [5] 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 without fragmentation. 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 records.

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

   RFC 3265: "SIP-Specific Event Notification"

   RFC 3265 [6] provides an extensible framework by which SIP nodes can
   request notification from remote nodes indicating that certain events


Sinnreich               Expires December 2009                 [Page 11]

Internet-Draft      <draft-sinnreich-sip-tools-07>            June 2009


   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 [7] 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
   presence.

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

   RFC 3863 [8] 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 [9] 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 [10] 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 [11] 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.



Sinnreich               Expires December 2009                 [Page 12]

Internet-Draft      <draft-sinnreich-sip-tools-07>            June 2009




   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 3261. The added security
   risk for misbehaving SIP UAs is handled in the forwarding SIP proxy.

         5. 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 on the Web. 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.

   Examples:

  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
     members.
  3. Conversations can be invoked while watching some events on the Web
     in real time. 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.



Sinnreich               Expires December 2009                 [Page 13]

Internet-Draft      <draft-sinnreich-sip-tools-07>            June 2009


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

         6. NAT Traversal

   SIP devices behind one or more NAT are at present the rule rather
   than the exception.

  "Best Current Practices for NAT Traversal for SIP" [22]
  comprehensively summarizes 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 RTP media packets
  through NAT devices.

   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 of their own. This list is not exhaustive and
   such approaches are based on different NAT traversal protocols for
   each application protocol separately.

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


Sinnreich               Expires December 2009                 [Page 14]

Internet-Draft      <draft-sinnreich-sip-tools-07>            June 2009


   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 the IPv6 transition in
   endpoints, mobility and multihoming that are beyond the scope of this
   paper. "Basic HIP Extensions for Traversal of Network Address
   Translators and Firewalls" [23] provides an extensive coverage of the
   use of HIP for NAT traversal.

   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 and moves it to the HIP protocol module in
   the endpoint.

         7. Security Considerations

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

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

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

     o The Datagram Transport Layer Security specified in RFC 4347 [27]
       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.
       The DTLS-SRTP Framework [26] can support encrypted
       communications between endpoints using self-signed
       certificates, whose fingerprints are exchanged over an integrity
       protected SIP signaling channel. The SRTP master secret is
       derived using the DTLS exchange as described in [27].


Sinnreich               Expires December 2009                 [Page 15]

Internet-Draft      <draft-sinnreich-sip-tools-07>            June 2009


     o ZRTP [28] provides key agreement for SRTP for multimedia
       communication with voice without depending on SIP signaling,
       though it can utilize an integrity protected SIP signaling path
       for authentication. ZRTP does not require the use of
       certificates or any Public Key Infrastructure (PKI).
       ZRTP provides best effort SRTP encryption without any additional
       SIP extensions.

         8. IANA Considerations

   There are no IANA considerations associated with this memo.



         9. Acknowledgements


   The authors would like to thank Cullen Jennings, Ralph Droms and
   Adrian Farrel for helpful comments in the most recent stage of this
   memo.

   Special thanks are due to Paul Kyzivat for challenging the authors to
   clarify the role of telephony network gateways and also to Keith
   Drage to discuss the use of emergency calls using simple SIP.

   Robert Sparks has pointed to some missing references, which we have
   added.

   The authors would also like to thank 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 the difference between network based services and
   endpoint applications.

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



         10.  References






Sinnreich               Expires December 2009                 [Page 16]

Internet-Draft      <draft-sinnreich-sip-tools-07>            June 2009


10.1 Mandatory References

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

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

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

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

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

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

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

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

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

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

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

10.2 Informative References

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

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

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


Sinnreich               Expires December 2009                 [Page 17]

Internet-Draft      <draft-sinnreich-sip-tools-07>            June 2009


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

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

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

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

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

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

   [22] "Best Current Practices for NAT Traversal for SIP" by C. Boulton
   et al., IETF, September 2008. Internet-Draft.

   [23] "Basic HIP Extensions for Traversal of Network Address
   Translators" by M. Komu et al. Internet-Draft, IETF, June 2009, work
   in progress.

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

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

   [26] Framework for Establishing an SRTP Security Context using DTLS
   by J. Fischl et al. Internet-Draft <draft-ietf-sip-dtls-srtp-
   framework-07>, March 2009. To be published as an RFC.

   [27] Datagram Transport Layer Security (DTLS) Extension to Establish
   Keys for Secure Real-time Transport Protocol (SRTP) by D. McGrew and
   E. Rescorla. Internet Draft, February 2009, work in progress.

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

   [29]"Change Process for SIP" by J. Peterson and C. Jennings.
   Internet-Draft, IETF, February 26 2009, work in progress.


Sinnreich               Expires December 2009                 [Page 18]

Internet-Draft      <draft-sinnreich-sip-tools-07>            June 2009


   [30] Toward 2 exp(W), Beyond Web 2.0" by T.V. Raman. Communications
   of the ACM, February 2009, Vol. 52, No.2, p. 52-59.

   [31] A convenient starting point for information on Rich Internet
   Applications can be found at
   http://en.wikipedia.org/wiki/Rich_Internet_Applications


   Author's Addresses

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

   Alan B. Johnston
   Avaya
   Saint Louis, MO, USA
   Email: alan@sipstation.com

   Eunsoo Shim
   Avaya Labs Research
   233 Mount Airy Road
   Basking Ridge, NJ 07920 USA
   Email: eunsooshim@gmail.com

   Kundan Singh
   Columbia University Alumni
   1214 Amsterdam Ave., MC0401
   New York, NY, USA
   Email: kns10@cs.columbia.edu


Acknowledgment

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











Sinnreich               Expires December 2009                 [Page 19]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/