SIP                                                         J. Rosenberg
Internet-Draft                                                     Cisco
Intended status: Informational                              July 5,                         November 15, 2007
Expires: January 6, May 18, 2008

     A Hitchhiker's Guide to the Session Initiation Protocol (SIP)
                  draft-ietf-sip-hitchhikers-guide-03
                  draft-ietf-sip-hitchhikers-guide-04

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 6, May 18, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   The Session Initiation Protocol (SIP) is the subject of numerous
   specifications that have been produced by the IETF.  It can be
   difficult to locate the right document, or even to determine the set
   of Request for Comments (RFC) about SIP.  This specification serves
   as a guide to the SIP RFC series.  It lists the specifications under
   the SIP umbrella, briefly summarizes each, and groups them into
   categories.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Scope of this Document . . . . . . . . . . . . . . . . . . . .  3  4
   3.  Core SIP Specifications  . . . . . . . . . . . . . . . . . . .  4  5
   4.  Public Switched Telephone Network (PSTN) Interworking  . . . .  7  9
   5.  General Purpose Infrastructure Extensions  . . . . . . . . . .  9 10
   6.  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . . . . 11 13
   7.  Minor Extensions .  Call Control Primitives  . . . . . . . . . . . . . . . . . . . 13
   8.  Event Framework  . . . 12
   8.  Conferencing . . . . . . . . . . . . . . . . . . . . 14
   9.  Event Packages . . . . . 13
   9.  Call Control Primitives . . . . . . . . . . . . . . . . . . . 14 15
   10. Event Framework and Packages Quality of Service . . . . . . . . . . . . . . . . . . 15
   11. Quality of Service . . . . 16
   11. Operations and Management  . . . . . . . . . . . . . . . . . . 16 17
   12. Operations and Management SIP Compression  . . . . . . . . . . . . . . . . . . . . . . . 17
   13. SIP Compression Service URIs . . . . . . . . . . . . . . . . . . . . . . . 17 18
   14. SIP Service URIs Minor Extensions . . . . . . . . . . . . . . . . . . . . . . . 18 19
   15. Security Mechanisms  . . . . . . . . . . . . . . . . . . . . . 19 20
   16. Conferencing . . . . . . . . . . . . . . . . . . . . . . . . . 23
   17. Instant Messaging, Presence and Multimedia . . . . . . . . . . 20
   17. 24
   18. Emergency Services . . . . . . . . . . . . . . . . . . . . . . 21
   18. 24
   19. Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   19. 25
   20. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   20. 25
   21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   21. 25
   22. Informative References . . . . . . . . . . . . . . . . . . . . 21 25
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30 36
   Intellectual Property and Copyright Statements . . . . . . . . . . 32 37

1.  Introduction

   The Session Initiation Protocol (SIP) [1] [RFC3261] is the subject of
   numerous specifications that have been produced by the IETF.  It can
   be difficult to locate the right document, or even to determine the
   set of Request for Comments (RFC) about SIP.  Don't Panic! [42]  [HGTTG]
   This specification serves as a guide to the SIP RFC series.  It lists
   the specifications under the SIP umbrella.  For each specification, a
   paragraph or so description is included that summarizes the purpose
   of the specification.  Each specification also includes a letter that
   designates its category in the standards track [2]. [RFC2026].  These
   values are:

   S: Standards Track (Proposed Standard, Draft Standard, or Standard)

   E: Experimental

   B: Best Current Practice

   I: Informational

   The specifications are grouped together by topic.  Typically,  The topics are:

   Core:  The essential SIP
   extensions fit naturally into topic areas, and implementations
   interested in a particular topic often implement many or all of the specifications in that area.  There are some specifications which
   fall into multiple topic areas, in which case they are listed more
   than once.

   This document itself is not an update expected to RFC 3261 be
      utilized for every session or an extension to
   SIP.  It is an informational document, meant to guide newcomers,
   implementors and deployers to the SIP suite of specifications.

2.  Scope of this Document

   It is very difficult registration.

   PSTN Interop:  Specifications related to enumerate interworking with the set of SIP specifications.
   This is because there are many protocols that are intimately related
      telephone network.

   General Purpose Infrastructure:  General purpose extensions to SIP SIP,
      SDP and used by nearly all SIP implementations, MIME, but ones that are not
   formally SIP extensions.  As such, this document formally defines a
   "SIP specification" as:

   o expected to always be used.

   NAT Traversal:  Specifications to deal with firewall and NAT
      traversal.

   Minor Extensions:  Specifications that solve a narrow problem space
      or provide an optimization.

   Conferencing:  Specifications for multimedia conferencing.

   Call Control Primitives:  Specifications for manipulating SIP dialogs
      and calls.

   Event Framework:  Defines the core specifications for the SIP event
      framework, providing for pub/sub capability.

   Event Packages:  Packages that utilize the SIP event framework.

   Quality of Service:  Specifications related to multimedia quality of
      service (QoS).

   Operations and Management:  Specifications related to configuration
      and monitoring of SIP deployments.

   SIP Compression:  Specifications to facilitate usage of SIP with the
      Signaling Compression (Sigcomp) framework.

   SIP Service URIs:  Specifications on how to use SIP URIs to address
      multimedia services.

   Security Mechanisms:  Specifications providing security functionality
      for SIP.

   Instant Messaging, Presence, and Multimedia:  SIP extensions related
      to IM, presence and multimedia.  This covers only the SIP
      extensions related to these topics.  See [I-D.ietf-simple-simple]
      for a full treatment of SIP for IM and Presence (SIMPLE).

   Emergency Services:  SIP extensions related to emergency services.
      See [I-D.ietf-ecrit-framework] for a more complete treatment of
      additional functionality related to emergency services.

   Typically, SIP extensions fit naturally into topic areas, and
   implementers interested in a particular topic often implement many or
   all of the specifications in that area.  There are some
   specifications which fall into multiple topic areas, in which case
   they are listed more than once.

   Do not print all the specs cited here at once, as they might share
   the fate of the rules of Brockian Ultracricket when bound together:
   collapse under their own gravity and form a black hole [HGTTG].

   This document itself is not an update to RFC 3261 or an extension to
   SIP.  It is an informational document, meant to guide newcomers,
   implementors and deployers to the many of the specifications
   associated with SIP.

2.  Scope of this Document

   It is very difficult to enumerate the set of SIP specifications.
   This is because there are many protocols that are intimately related
   to SIP and used by nearly all SIP implementations, but are not
   formally SIP extensions.  As such, this document formally defines a
   "SIP specification" as:

   o  Any specification that defines an extension to SIP itself, RFC 3261, where an
      extension is a mechanism that changes or updates in some way a
      behavior specified in RFC 3261 there.

   o  Any  The basic SDP specification, RFC 4566 [RFC4566], and any
      specification that defines an extension to SDP whose primary
      purpose is to support SIP SIP.

   o  Any specification that defines a MIME object whose primary purpose
      is to support SIP

   Excluded from this list are requirements, architectures, registry
   definitions, non-normative frameworks, and processes.  Best Current
   Practices are included when they normatively define mechanisms for
   accomplishing a task.

   The SIP change process [8] [RFC3427] defines two types of extensions to
   SIP.  These are normal extensions and the so-called P-headers (where
   P stands for "preliminary", "private", or "proprietary", and the "P-"
   prefix is included in the header field name) name), which are meant to be
   used in areas of limited applicability.  P-headers cannot be defined
   in the standards track.  For the most part, P-headers are not
   included in the listing here, with the exception of those which have
   seen general usage despite their P-header status.

   This document includes specifications which have already been
   approved by the IETF and granted an RFC number, in addition to
   Internet Drafts which are still under development within IETF and
   will eventually finish and get an RFC number.  Inclusion of Internet
   Drafts here helps encourage early implementation and demonstrations
   of interoperability of the protocol, and thus aids in the standards
   setting process.  Inclusion of these also identifes where the IETF is
   targetting a solution at a particular problem space.  Note that final
   IANA assignment of codepoints (such as option tags and header field
   names) does not take place until shortly before publication as an
   RFC, and thus codepoint assignments may change.

3.  Core SIP Specifications

   The core SIP specifications represent the set of specifications whose
   functionality is broadly applicable.  An extension is broadly
   applicable if it fits into one of the following categories:

   o  For specifications that impact SIP session management, the
      extension would be used for almost every session initiated by a
      user agent

   o  For specifications that impact SIP registrations, the extension
      would be used for almost every registration initiated by a user
      agent

   o  For specifications that impact SIP subscriptions, the extension
      would be used for almost every subscription initiated by a user
      agent

   In other words, these are not specifications that are used just for
   some requests and not others; they are specifications that would
   apply to each and every request that the extension is relevant for.
   In the galaxy of SIP, these specifications are like towels [42]. [HGTTG].

   RFC 3261, The Session Initiation Protocol (S):  RFC 3261 [1]  [RFC3261] is the core
      SIP protocol itself.  RFC 3261 is an update to RFC 2543 [9]. [RFC2543].  It is
      the president of the galaxy [42] [HGTTG] as far as the suite of SIP
      specifications is concerned.

   RFC 3263, Locating SIP Servers (S):  RFC 3263 [10]  [RFC3263] provides DNS
      procedures for taking a SIP URI, and determining a SIP server that
      is associated with that SIP URI.  RFC 3263 is essential for any
      implementation using SIP with DNS.  RFC 3263 makes use of both DNS
      SRV records [11] [RFC2782] and NAPTR records [12]. [RFC2915].

   RFC 3264, An Offer/Answer Model with the Session Description Protocol
   (S):  RFC 3264 [4]  [RFC3264] defines how the Session Description Protocol (SDP)
      [78]
      [RFC4566] is used with SIP to negotiate the parameters of a media
      session.  It is in widespread usage and an integral part of the
      behavior of RFC 3261.

   RFC 3265, SIP-Specific Event Notification (S):  RFC 3265 [13]  [RFC3265] defines the
      SUBSCRIBE and NOTIFY methods.  These two methods provide a general
      event notification framework for SIP.  To actually use the
      framework, extensions need to be defined for specific event
      packages.  An event package defines a schema for the event data,
      and describes other aspects of event processing specific to that
      schema.  An RFC 3265 implementation is required when any event
      package is used.

   RFC 3325, Private Extensions to SIP for Asserted Identity within
   Trusted Networks (I):  Though its P-header status implies that it has
      limited applicability, RFC 3325 [15], [RFC3325], which defines the
      P-Asserted-ID P-Asserted-
      Identity header field field, has been widely deployed.  It is used as
      the basic mechanism for providing secure network asserted caller ID
      services.

   RFC 3327, SIP Extension Header Field for Registering Non-Adjacent
   Contacts (S):  RFC 3327 [16]  [RFC3327] defines the Path header field.  This field
      is inserted by proxies between a client and their registrar.  It
      allows inbound requests towards that client to traverse these
      proxies prior to being delivered to the user agent.  It is
      essential in any SIP deployment that has edge proxies, which are
      proxies between the client and the home proxy or SIP registrar.

   RFC 3581, An Extension to SIP for Symmetric Response Routing (S):
      RFC 3581 [17]
      [RFC3581] defines the rport parameter of the Via header.  It
      is an essential piece of getting
      allows SIP through responses to traverse NAT.  NAT traversal
      for SIP  It is considered a core part one of the specifications. several
      specifications that are utilized for NAT traversal (see
      Section 6).

   RFC 3840, Indicating User Agent Capabilities in SIP (S):  RFC 3840
      [33]  [RFC3840]
      defines a mechanism for carrying capability information about a
      user agent in REGISTER requests and in dialog-forming requests
      like INVITE.  It has found use with conferencing (the isfocus
      parameter declares that a user agent is a conference server) and
      with applications like push-to-talk.

   RFC 4320, Actions Addressing Issues Identified with the Non-INVITE
   Transaction in SIP (S):  RFC 4320 [18]  [RFC4320] formally updates RFC 3261, and
      modifies some of the behaviors associated with non-INVITE
      transactions.  These address  This addresses some problems found in timeout and
      failure cases.

   RFC 4474, Enhancements for Authenticated Identity Management in SIP
   (S):  RFC 4474 [19]  [RFC4474] defines a mechanism for providing a cryptographically
      verifiable identity of the calling party in a SIP request.  Known
      as "SIP Identity", this mechanism provides an alternative to RFC
      3325.  It has seen little deployment so far, but its importance as
      a key construct for anti-spam techniques and new security
      mechanisms makes it a core part of the SIP specifications.

   RFC XXXX,

   draft-ietf-sip-gruu, Obtaining and Using Globally Routable User Agent
   Identifiers (GRUU) in SIP (S):  RFC XXXX [20]  [I-D.ietf-sip-gruu] defines a
      mechanism for directing requests towards a specific UA instance.
      GRUU is essential for features like transfer and provides another
      piece of the SIP NAT traversal story.

   RFC XXXX,

   draft-ietf-sip-outbound, Managing Client Initiated Connections
   through SIP (S):  RFC
      XXXX [21],  [I-D.ietf-sip-outbound], also known as SIP
      outbound, defines important changes to the SIP registration
      mechanism which enable delivery of SIP messages towards a UA when
      it is behind a NAT.  This specification is the cornerstone of the
      SIP NAT traversal strategy.

   RFC 4566, Session Description Protocol (S):  RFC 4566 [78]  [RFC4566] defines a
      format for representing multimedia sessions.  SDP objects are
      carried in the body of SIP messages, and based on the offer/answer
      model, are used to negotiate the media characteristics of a
      session between users.

   RFC XXXX,

   draft-ietf-mmusic-sdp-capability-negotiation, SDP Capability
   Negotiation (S):  RFC XXXX [105]  [I-D.ietf-mmusic-sdp-capability-negotiation]
      defines a set of extensions to SDP that allow for capability
      negotiation within SDP.  Capability negotiation can be used to
      select between different profiles of RTP (secure vs. unsecure) or
      to negotiate codecs such that an agent has to select one amongst a set of
      supported codecs.

   RFC 3388, Grouping of Media Lines in the Session Description Protocol
   (S):  RFC 3388 [79] defines a framework for grouping together media
      streams in an SDP message.  Such a grouping allows relationships
      between these streams, such as which stream is the audio for a
      particular video feed, to be expressed.

   RFC XXXX, select one amongst a
      set of supported codecs.

   draft-ietf-mmusic-ice, Interactive Connectivity Establishment (ICE)
   (S):  RFC XXXX
      [5]  [I-D.ietf-mmusic-ice] defines a technique for NAT traversal of
      media sessions for protocols that make use of the offer/answer
      model.  This specification is the IETF recommended mechanism for
      NAT traversal for SIP media streams, and is meant to be used even
      by endpoints which are themselves never behind a NAT.  A SIP
      option tag and media feature tag RFC XXXX [108] [I-D.ietf-sip-ice-option-tag]
      (also a core specification) have been defined for use with ICE.

   RFC 3605, Real Time Control Protocol (RTCP) Attribute in the Session
   Description Protocol (SDP) (S):  RFC 3605 [80]  [RFC3605] defines a way to
      explicitly signal, within an SDP message, the IP address and port
      for RTCP, rather than using the port+1 rule in the Real Time
      Transport Protocol (RTP) [3]. [RFC3550].  It is needed for devices
      behind NAT and used by ICE.

   RFC 4916, Connected Identity in the Session Initiation Protocol (SIP)
   (S):  [RFC4916] formally updates RFC 4916 [81] 3261.  It defines an extension
      to SIP that allows a UAC calling user to determine the identity of the UAS.
      final called user (connected party).  Due to forwarding and
      retargeting services, this may not be the same as the user that
      the UAC caller was originally trying to reach.  The mechanism works in
      tandem with the SIP identity specification [19] [RFC4474] to provide
      signatures over the connected party identity.  It can also be used
      if a party identity changes mid call due to third party call
      control actions or PSTN behavior.

   RFC 3311, The SIP UPDATE Method (S):  [RFC3311] defines the UPDATE
      method for SIP.  This method is meant as a means for updating
      session information prior to the completion of the initial INVITE
      transaction.  It can also be used to update other information,
      such as the identity of the participant [RFC4916], without
      involving an updated offer/answer exchange.  It was developed
      initially to support [RFC3312] but has found other uses.  In
      particular, its usage with RFC XXXX, 4916 means it will typically be
      used as part of every session, to convey a secure connected
      identity.

   draft-ietf-sip-sips, The use of the SIPS URI Scheme in the Session
   Initiation Protocol (SIP) (S):  [I-D.ietf-sip-sips] formally updated
      RFC XXXX [112] 3261.  It revises the processing of the SIPS URI, originally
      defined in RFC 3261, to fix many errors and problems that have
      been encountered with that mechanism.

   Essential Corrections to SIP:  A collection of fixes to SIP that
      address important bugs and vulnerabilities.  These include a fix
      requiring loop detection in any proxy that forks [82]
      [I-D.ietf-sip-fork-loop-fix] and a clarification on how record-routing record-
      routing works [110]. [I-D.ietf-sip-record-route-fix].

4.  Public Switched Telephone Network (PSTN) Interworking

   Numerous extensions and usages of SIP related to interoperability and
   communications with or through the PSTN.

   RFC 2848, The PINT Service Protocol (S):  RFC 2848 [22]  [RFC2848] is one of the
      earliest extensions to SIP.  It defines procedures for using SIP
      to invoke services that actually execute on the PSTN.  Its main
      application is for third party call control, allowing an IP host
      to set up a call between two PSTN endpoints.  PINT has a
      relatively narrow focus and has not seen widespread deployment.

   RFC 3910, The SPIRITS Protocol (S):  Continuing the trend of naming
      PSTN related extensions with alcohol references, SPIRITS [23] [RFC3910]
      defines the inverse of PINT.  It allows a switch in the PSTN to
      ask an IP element about how to proceed with call waiting.  It was
      developed primarily to support Internet Call Waiting (ICW).
      Perhaps the next specification will be called the Pan Galactic
      Gargle Blaster [42]. [HGTTG].

   RFC 3372, SIP for Telephones (SIP-T): Context and Architectures (I):
      SIP-T [24] [RFC3372] defines a mechanism for using SIP between pairs of
      PSTN gateways.  Its essential idea is to tunnel ISUP signaling
      between the gateways in the body of SIP messages.  SIP-T motivated
      the development of INFO [30]. [RFC2976].  SIP-T has seen widespread
      implementation.
      implementation for the limited deployment model that it addresses.
      As ISUP endpoints disappear from the network, the need for this
      mechanism will decrease.

   RFC 3398, ISUP to SIP Mapping (S):  RFC 3398 [25]  [RFC3398] defines how to do
      protocol mapping from the SS7 ISDN User Part (ISUP) signaling to
      SIP.  It is widely used in SS7 to SIP gateways and is part of the
      SIP-T framework.

   RFC 3578, Mapping of ISUP Overlap Signaling to SIP (S):  RFC 3578
      [26]  [RFC3578]
      defines a mechanism to map overlap dialing into SIP.  This
      specification is widely regarded as the ugliest SIP specification,
      as the introduction to the specification itself advises that it
      has many problems.  Overlap signaling (the practice of sending
      digits into the network as dialed instead of waiting for complete
      collection of the called party number) is largely incompatible
      with SIP at some fairly fundamental levels.  That said, RFC 3578
      is mostly harmless and has seen some usage.

   RFC 3960, Early Media and Ringtone Generation in SIP (I):  RFC 3960
      [27]  [RFC3960]
      defines some guidelines for handling early media - the practice of
      sending media from the called party or an application server
      towards the caller - prior to acceptance of the call.  Early media
      is often generated only from the PSTN.  Early media is a complex topic,
      and this specification does not fully address the problems
      associated with it.

   RFC 3959, Early Session Disposition Type for the Session Initiation
   Protocol (SIP) (S):  RFC 3959 [83]  [RFC3959] defines a new session disposition type
      for use with early media.  It indicates that the SDP in the body
      is for a special early media session.  This has seen little usage.

   RFC 3204, MIME Media Types for ISUP and QSIG Objects (S):  RFC 3204
      [84]  [RFC3204]
      defines MIME objects for representing SS7 and QSIG signaling
      messages.
      These  SS7 signaling messages are carried in the body of SIP
      messages when SIP-T is used.  QSIG signaling messages can be
      carried in a similar way.

5.  General Purpose Infrastructure Extensions

   These extensions are general purpose enhancements to SIP, SDP and
   MIME that can serve a wide variety of uses.  However, they are not as
   widely used or as essential as the core specifications.

   RFC 3262, Reliability of Provisional Responses in SIP (S):  SIP
      defines two types of responses to a request - final and
      provisional.  Provisional responses are numbered from 100 to 199.
      In SIP, these responses are not sent reliably.  This choice was
      made in RFC 2543 since the messages were meant to just be truly
      informational, and rendered to the user.  However, subsequent work
      on PSTN interworking demonstrated a need to map provisional
      responses to PSTN messages that needed to be sent reliably.  RFC
      3262 [28]
      [RFC3262] was developed to allow reliability of provisional
      responses.  The specification defines the PRACK method, used for
      indicating that a provisional response was received.  Though it
      provides a generic capability for SIP, RFC 3262 implementations
      have been most common in PSTN interworking devices.  However,
      PRACK brings a great deal of complication for relatively small
      benefit.  As such, it has seen only mild moderate levels of deployment.

   RFC 3323, A Privacy Mechanism for the Session Initiation Protocol
   (SIP) (S):  RFC 3323 [14]  [RFC3323] defines the Privacy header field, used by
      clients to request anonymity for their requests.  Though it
      defines numerous several privacy services, the only one broadly used is
      the one that supports privacy of the P-Asserted-ID header field
      [15].

   RFC 3311, The SIP UPDATE Method (S):  RFC 3311 [29] defines the
      UPDATE method for SIP.  This method is meant as a means for
      updating session information prior to the completion of the
      initial INVITE transaction.  It was developed primarily to support
      RFC 3312 [59]. used is the
      one that supports privacy of the P-Asserted-Identity header field
      [RFC3325].

   RFC 2976, The INFO Method (S):  RFC 2976 [30]  [RFC2976] was defined as an extension
      to RFC 2543.  It defines a method, INFO, used to transport mid-dialog mid-
      dialog information that has no impact on SIP itself.  Its driving
      application was the transport of PSTN related information when
      using SIP between a pair of gateways.  Though originally conceived
      for broader use, it only found standardized usage with SIP-T [24].
      [RFC3372].  It has been used to support numerous proprietary and
      non-interoperable extensions due to its poorly defined scope.

   RFC 3326, The Reason header field for SIP (S):  RFC 3326 [31]  [RFC3326] defines the
      Reason header field.  It is used in requests, such as BYE, to
      indicate the reason that the request is being sent.

   RFC 3388, Grouping of Media Lines in the Session Description Protocol
   (S):  RFC 3388 [RFC3388] defines a framework for grouping together
      media streams in an SDP message.  Such a grouping allows
      relationships between these streams, such as which stream is the
      audio for a particular video feed, to be expressed.

   RFC 3420, Internet Media Type message/sipfrag (S):  RFC 3420 [85]  [RFC3420] defines
      a MIME object that contains a SIP message fragment.  Only certain
      header fields and parts of the SIP message are present.  For
      example, it is used to report back on the responses received to a
      request sent as a consequence of a REFER.

   RFC 3608, SIP Extension Header Field for Service Route Discovery
   During Registration (S):  RFC 3608 [32]  [RFC3608] allows a client to determine,
      from a REGISTER response, a path of proxies to use in requests it
      sends outside of a dialog.  It can also be used by proxies to
      verify the Route header in client initiated requests.  In many
      respects, it is the inverse of the Path header field, but has seen
      less usage since default outbound proxies have been sufficient in
      many deployments.

   RFC 3841, Caller Preferences for SIP (S):  RFC 3841 [34]  [RFC3841] defines a set of
      headers that a client can include in a request to control the way
      in which the request is routed downstream.  It allows a client to
      direct a request towards a UA with specific
      capabilities. capabilities, which a
      UA indicates using [RFC3840].

   RFC 4028, Session Timers in SIP (S):  RFC 4028 [35]  [RFC4028] defines a keepalive
      mechanism for SIP signaling.  It is primarily meant to provide a
      way to cleanup old state in proxies that are holding call state
      for calls from failed endpoints which were never terminated
      normally.  Despite its name, the session timer is not a mechanism
      for detecting a network failure mid-call.  Session timers
      introduces a fair bit of complexity for relatively little gain,
      and has thus have seen little moderate deployment.

   RFC 4168, SCTP as a Transport for SIP (S):  RFC 4168 [36]  [RFC4168] defines how to
      carry SIP messages over the Stream Control Transmission Protocol (SCTP).
      (SCTP) [RFC4960].  SCTP has seen very limited usage for SIP
      transport.

   RFC 4244, An Extension to SIP for Request History Information (S):
      RFC 4244 [37]
      [RFC4244] defines the History-Info header field, which indicates
      information on how and why a call came to be routed to a
      particular destination.  Its primary application was in support of
      voicemail services.

   RFC 4145, TCP-Based Media Transport in the Session Description
   Protocol (SDP) (S):  RFC 4145 [86]  [RFC4145] defines an extension to SDP for
      setting up TCP-based sessions between user agents.  It defines who
      sets up the connection and how its lifecycle is managed.  It has
      seen relatively little usage due to the small number of media
      types to date which use TCP.

   RFC 4091, The Alternative Network Address Types (ANAT) Semantics for
   the Session Description Protocol (SDP) Grouping Framework (S):  RFC
      4091 [87]
      [RFC4091] defines a mechanism for including both IPv4 and IPv6
      addresses for a media session as alternates.

   RFC XXXX,  This mechanism has
      been deprecated in favor of ICE [I-D.ietf-mmusic-ice].

   draft-ietf-mmusic-sdp-media-capabilities, SDP Media Capabilities
   Negotiation (S):  RFC XXXX [106]  [I-D.ietf-mmusic-sdp-media-capabilities] defines an
      extension to the SDP capability negotiation framework
      [105]
      [I-D.ietf-mmusic-sdp-capability-negotiation] for negotiating
      codecs, codec parameters, and media streams.

6.  NAT Traversal

   These SIP extensions are primarily aimed at addressing NAT traversal
   for SIP.

   RFC XXXX,

   draft-ietf-mmusic-ice, Interactive Connectivity Establishment (ICE)
   (S):  RFC XXXX
      [5]  [I-D.ietf-mmusic-ice] defines a technique for NAT traversal of
      media sessions for protocols that make use of the offer/answer
      model.  This specification is the IETF recommended mechanism for
      NAT traversal for SIP media streams, and is meant to be used even
      by endpoints which are themselves never behind a NAT.  A SIP
      option tag and media feature tag RFC XXXX [108] [I-D.ietf-sip-ice-option-tag]
      have been defined for use with ICE.

   RFC XXXX,

   draft-ietf-mmusic-ice-tcp, TCP Candidates with Interactive
   Connectivity Establishment (ICE) (S):  RFC XXXX [88]  [I-D.ietf-mmusic-ice-tcp]
      specifies the usage of ICE for TCP streams.  This allows for
      selection of RTP-based voice ontop of TCP only when NAT or
      firewalls would prevent UDP-based voice from working.

   RFC 3605, Real Time Control Protocol (RTCP) Attribute in the Session
   Description Protocol (SDP) (S):  RFC 3605 [80]  [RFC3605] defines a way to
      explicitly signal, within an SDP message, the IP address and port
      for RTCP, rather than using the port+1 rule in the Real Time
      Transport Protocol (RTP) [3]. [RFC3550].  It is needed for devices
      behind NAT and used by ICE.

   RFC XXXX,

   draft-ietf-sip-outbound, Managing Client Initiated Connections
   through SIP (S):  RFC
      XXXX [21],  [I-D.ietf-sip-outbound], also known as SIP
      outbound, defines important changes to the SIP registration
      mechanism which enable delivery of SIP messages towards a UA when
      it is behind a NAT.  This specification
      is the cornerstone of the SIP NAT traversal strategy.

   RFC 3581, An Extension to SIP for Symmetric Response Routing (S):
      RFC 3581 [17]
      [RFC3581] defines the rport parameter of the Via header.  It
      allows SIP responses to traverse NAT.

   draft-ietf-sip-gruu, Obtaining and Using Globally Routable User Agent
   Identifiers (GRUU) in SIP (S):  [I-D.ietf-sip-gruu] defines a
      mechanism for directing requests towards a specific UA instance.
      GRUU is an essential for features like transfer and provides another
      piece of getting the SIP through NAT. NAT traversal story.

7.  Call Control Primitives

   Numerous SIP extensions provide a toolkit of dialog and call
   management techniques.  These techniques have been combined together
   to build many SIP-based services.

   RFC 3515, The REFER Method (S):  REFER [RFC3515] defines a mechanism
      for asking a user agent to send a SIP request.  It's a form of SIP
      remote control, and is the primary tool used for call transfer in
      SIP.  Beware that not all potential uses of REFER (neither for all
      methods nor for all URI schemes) are well defined.  Implementors
      should only use the well-defined ones, and should not second guess
      or freely assume behavior for SIP is considered a core part of the specifications.

   RFC XXXX, Obtaining others to avoid unexpected
      behavior of remote UAs, interoperability issues, and Using Globally Routable User Agent
   Identifiers (GRUU) in SIP (S): other bad
      surprises.

   RFC XXXX [20] defines a mechanism 3725, Best Current Practices for
      directing requests towards Third Party Call Control (3pcc)
   (B):  [RFC3725] defines a specific UA instance.  GRUU is
      essential for features like transfer and provides another piece number of different call flows that allow
      one SIP entity, called the controller, to create SIP NAT traversal story.

7.  Minor Extensions

   These sessions
      amongst other SIP extensions don't fit easily into a single specific use
   case.  They have somewhat general applicability, but they solve a
   relatively small problem or provide an optimization. user agents.

   RFC 4488, Suppression of the 3911, The SIP REFER Implicit Subscription Join Header Field (S):
      RFC 4488 [38]  [RFC3911] defines an enhancement to REFER.  REFER normally
      creates an implicit subscription to the target of Join
      header field.  When sent in an INVITE, it causes the REFER.  This
      subscription is used recipient to pass back updates on the progress of
      join the
      referral.  This extension allows that implicit subscription to be
      bypassed as an optimization.

   RFC 4538, Request Authorization through Dialog Identification resulting dialog into a conference with another dialog in
      progress.

   RFC 3891, The SIP Replaces Header (S):  RFC 4538 [39] provides  [RFC3891] defines a mechanism
      that allows a UAS to
      authorize a request because the requestor proves it knows a new dialog
      that is in progress with the UAS.  The specification to replace an existing dialog.  It is
      useful in
      conjunction with the SIP application interaction framework [77]. for certain advanced transfer services.

   RFC 4508, Conveying Feature Tags with the REFER Method in 3892, The SIP Referred-By Mechanism (S):
      RFC 4508 [40]  [RFC3892] defines a mechanism for carrying RFC 3840 feature
      tags in REFER. the
      Referred-By header field.  It is useful for informing used in requests triggered by
      REFER, and provides the target identity of the REFER
      about the characteristics of referring party to the REFER target.
      referred-to party.

   RFC XXXX, Requesting Answer Modes for 4117, Transcoding Services Invocation in SIP (S):  RFC XXXX [41] Using Third Party
   Call Control (I):  [RFC4117] defines
      an extension for indicating how to the called party whether or not the
      phone should ring and/or be answered immediately.  This is useful use 3pcc for push-to-talk and the purposes
      of invoking transcoding services for diagnostic applications. a call.

8.  Event Framework

   RFC XXXX, Rejecting Anonymous Requests in SIP 3265, SIP-Specific Event Notification (S):  RFC XXXX [43]  [RFC3265] defines a mechanism for a called party to indicate to the calling
      party that
      SUBSCRIBE and NOTIFY methods.  These two methods provide a call was rejected since the caller was anonymous.
      This is needed general
      event notification framework for implementation of the Anonymous Call Rejection
      (ACR) feature in SIP.

   RFC XXXX, Referring  To actually use the
      framework, extensions need to Multiple Resources in SIP (S):  RFC XXXX [44]
      allows a UA sending be defined for specific event
      packages.  An event package defines a REFER to ask schema for the recipient event data,
      and describes other aspects of the REFER event processing specific to
      generate multiple that
      schema.  An RFC 3265 implementation is required when any event
      package is used.

   RFC 3903, SIP requests, Extension for Event State Publication (S):  [RFC3903]
      defines the PUBLISH method.  It is not just one.  This an event package, but is useful for
      conferencing, where a client would like to ask a conference server
      to eject multiple users.
      used by all event packages as a mechanism for pushing an event
      into the system.

   RFC 4483, 4662, A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages Event Notification
   Extension for Resource Lists (S):  RFC 4483 [89]  [RFC4662] defines an extension to
      RFC 3265 that allows a mechanism for
      content indirection.  Instead client to subscribe to a list of carrying an object within resources
      using a SIP
      body, single subscription.  The server, called a URL reference is carried instead, and the recipient
      dereferences Resource List
      Server (RLS) will "expand" the URL subscription and subscribe to obtain each
      individual member of the object.  The specification list.  It has
      potential found applicability for sending large instant messages,
      primarily in the area of presence, but
      has yet can be used with any event
      package.

   draft-ietf-sip-subnot-etags, An Extension to find much actual use.

   RFC 3890, A Transport Independent Bandwidth Modifier for the Session
   Description Initiation
   Protocol (SDP)  (SIP) Events for Conditional Event Notification (S):  RFC 3890 [90] specifies
      [I-D.ietf-sip-subnot-etags] defines an SDP extension that allows for to RFC 3265 to
      optimize the description performance of the bandwidth for notifications.  When a
      media session that is independent client
      subscribes, it can indicate what version of a document it has, so
      that the underlying transport
      mechanism.  It has seen relatively little usage.

   RFC 4583, Session Description Protocol (SDP) Format for Binary Floor
   Control Protocol (BFCP) Streams (S):  RFC 4583 [91] defines server can skip sending a
      mechanism in SDP notification if the client is
      up to signal floor control streams that use BFCP. date.  It is used for Push-To-Talk and conference floor control.

   RFC XXXX, Connectivity Preconditions for Session Description Protocol
   Media Streams (S):  RFC XXXX [93] defines a usage of the precondition
      framework [59].  The connectivity precondition makes sure that applicable to any event package.

9.  Event Packages

   These are event packages defined to utilize the
      session doesn't get established until actual packet connectivity
      is checked. SIP events framework.
   Many of these are also listed elsewhere in their respective areas.

   RFC 4796, The SDP (Session Description Protocol) Content Attribute 3680, A SIP Event Package for Registrations (S):  RFC 4796 [94]  [RFC3680]
      defines an SDP attribute event package for describing the
      purpose of a media stream.  Examples include a slide view, the
      speaker, a sign language feed, finding out about changes in
      registration state.

   RFC 3842, A Message Summary and so on.

8.  Conferencing

   Numerous Message Waiting Indication Event
   Package for SIP (S):  [RFC3482] defines a way for a user agent to
      find out about voicemails and SDP extensions other messages that are aimed at conferencing as their waiting for
      it.  Its primary application. purpose is to enable the voicemail waiting lamp
      on most business telephones.

   RFC 4574, The SDP (Session Description Protocol) Label Attribute 3856, A Presence Event Package for SIP (S):  RFC 4574 [95]  [RFC3856] defines an SDP attribute
      event package for providing an opaque
      label indicating user presence through SIP.

   RFC 3857, A Watcher Information Event Template Package for media streams.  These labels can be referred SIP (S):
      [RFC3857], also known as winfo, provides a mechanism for a user
      agent to by
      external documents, and find out what subscriptions are in particular, by conference policy
      documents.  This allows place for a UA to tie together documents particular
      event package.  Its primary usage is with presence, but it may
      obtain through conferencing mechanisms to media streams to which
      they refer.

   RFC 3911, The SIP Join Header Field (S): can be
      used with any event package.

   RFC 3911 [49] defines the
      Join header field.  When sent in 4235, An INVITE Initiated Dialog Event Package for SIP (S):
      [RFC4235] defines an INVITE, it causes event package for learning the
      recipient to join state of the resulting dialog into
      dialogs in progress at a conference user agent, and is one of several RFCs
      starting with
      another dialog in progress. the important number 42 [HGTTG].

   RFC 4575, A SIP Event Package for Conference State (S):  RFC 4575
      [56]  [RFC4575]
      defines a mechanism for learning about changes in conference
      state, including group conference membership.

   RFC XXXX, Conference Establishment Using Request-Contained Lists in 4730, A SIP Event Package for Keypress Stimulus (KPML) (S):  RFC XXXX [70] is similar to [68].  However, instead of
      subscribing to the resource, an INVITE request is sent to the
      resource, and it will act as
      [RFC4730] defines a conference focus and generate way for an
      invitation to each recipient application in the list.

9.  Call Control Primitives

   Numerous SIP extensions provide a toolkit of dialog and call
   management techniques.  These techniques have been combined together network to build many SIP-based services.

   RFC 3515, The REFER Method (S):  REFER [45] defines a mechanism for
      asking a user agent
      subscribe to send a SIP request.  Its a form the set of SIP
      remote control, and is keypresses made on the primary tool used for call transfer in
      SIP. keypad of a
      traditional telephone.  It, along with RFC 3725, Best Current Practices 2833 [RFC2833], are the
      two mechanisms defined for Third Party Call Control (3pcc)
   (B): handling DTMF.  RFC 3725 [46] defines 4730 is a number of different call flows that
      allow one SIP entity, called the controller, to create SIP
      sessions amongst other SIP user agents.
      signaling-path solution, and RFC 3911, The 2833 is a media-path solution.

   draft-ietf-sipping-rtcp-summary, SIP Join Header Field Event Package for Voice Quality
   Reporting (S):  RFC 3911 [49]  [I-D.ietf-sipping-rtcp-summary] defines the
      Join header field.  When sent in an INVITE, it causes the
      recipient to join the resulting dialog into a conference with
      another dialog in progress.

   RFC 3891, The SIP Replaces Header event
      package that enables the collection and reporting of metrics that
      measure the quality for Voice over Internet Protocol (VoIP)
      sessions.

   draft-ietf-sipping-policy-package, A Session Initiation Protocol
   (SIP) Event  Package for Session-Specific Session Policies (S):  RFC 3891 [47]
      [I-D.ietf-sipping-policy-package] defines a
      mechanism SIP event package that
      allows a new dialog policy server to replace an existing dialog.
      It is useful notify a user agent about its desire for
      the UA to use certain advanced transfer services.

   RFC 3892, codecs or generally obey certain media
      session policies.

   draft-ietf-sipping-pending-additions, The SIP Referred-By Mechanism Session Initiation Protocol
   (SIP) Pending  Additions Event Package (S):  RFC 3892 [48]
      [I-D.ietf-sipping-pending-additions] defines a SIP event package
      that allows a UA to learn whether consent has been given for the Referred-By header field.
      addition of an address to a SIP "mailing list".  It is used in requests triggered by
      REFER, and provides
      conjunction with the identity SIP framework for consent
      [I-D.ietf-sip-consent-framework].

10.  Quality of Service

   Several specifications concern themselves with the referring party to the
      referred-to party.

   RFC 4117, Transcoding Services Invocation in interactions of
   SIP Using Third Party
   Call Control (I): with network Quality of Service (QoS) mechanisms.

   RFC 4117 [50] defines how to use 3pcc for the
      purposes 3312, Integration of invoking transcoding services for a call.

10.  Event Framework Resource Management and Packages

   RFC 3265 SIP (S):  [RFC3312],
      updated by [RFC4032] defines a basic framework for event notification in SIP.  It
   introduces way to make sure that the notion of an event package, which is a collection of
   related state and event information.  Much phone of
      the state and events called party doesn't ring until a QoS reservation has been
      installed in
   SIP systems have event packages, allowing other entities to learn
   about changes the network.  It does so by defining a general
      preconditions framework, which defines conditions that must be
      true in that state. order for a SIP session to proceed.

   RFC 3903, 3313, Private SIP Extension Extensions for Event State Publication (S):  RFC 3903
      [51] Media Authorization (I):
      [RFC3313] defines the PUBLISH method.  It is not an event package, but
      is used by all event packages as a P-header that provides a mechanism for pushing an event
      into the system.

   RFC 4662, A Session Initiation Protocol (SIP) Event Notification
   Extension for Resource Lists (S):  RFC 4662 [67] defines passing
      an extension
      to RFC 3265 that allows authorization token between SIP and a client to subscribe network QoS reservation
      protocol like RSVP.  Its purpose is to make sure network QoS is
      only granted if a list of
      resources using a single subscription.  The server, called client has made a
      Resource List Server (RLS) will "expand" SIP call through the subscription and
      subscribe same
      providers network.  This specification is sometimes referred to each individual member of as
      the list.  It has found
      applicability primarily SIP walled garden specification by the truly paranoid androids
      in the area SIP community.  This is because it requires coupling of presence, but can be used
      with any event package.
      signaling and the underlying IP network.

   RFC XXXX, An Extension 3524, Mapping of Media Streams to Session Initiation Protocol (SIP) Events
   for Conditional Event Notification Resource Reservation Flows
   (S):  RFC XXXX [111]  [RFC3524] defines an
      extension to RFC 3265 to optimize a usage of the performance SDP grouping framework for
      indicating that a set of
      notifications.  When media streams should be handled by a client subscribes, it can indicate what
      version
      single resource reservation.

11.  Operations and Management

   Several specifications have been defined to support operations and
   management of SIP systems.  These include mechanisms for
   configuration and network diagnostics.

   draft-ietf-sipping-config-framework, A Framework for SIP User Agent
   Profile Delivery (S):  [I-D.ietf-sipping-config-framework] defines a document it has, so
      mechanism that the server can skip sending allows a notification if SIP user agent to bootstrap its
      configuration from the client is up network, and receive updates to date.  It its
      configuration should it change.  This is applicable to
      any event package.

   RFC 3680, A considered an essential
      piece of deploying a usable SIP network.

   draft-ietf-sipping-rtcp-summary, SIP Event Package for Registrations Voice Quality
   Reporting (S):  RFC 3680 [52]  [I-D.ietf-sipping-rtcp-summary] defines an a SIP event
      package for finding out about changes in
      registration state.

   RFC 3842, A Message Summary that enables the collection and Message Waiting Indication Event
   Package reporting of metrics that
      measure the quality for Voice over Internet Protocol (VoIP)
      sessions.

12.  SIP (S): Compression

   Sigcomp [RFC3320] [RFC4896] was defined to allow compression of SIP
   messages over low bandwidth links.  Sigcomp is not formally part of
   SIP.  However, usage of Sigcomp with SIP has required extensions to
   SIP.

   RFC 3842 [65] 3486, Compressing SIP (S):  [RFC3486] defines a way for a user agent SIP URI parameter
      that can be used to
      find out about voicemails and other messages indicate that are waiting for
      it.  Its primary purpose is a SIP server supports Sigcomp.

   draft-ietf-rohc-sigcomp-sip, Applying Signaling Compression (SigComp)
   to enable the voicemail waiting lamp
      on most business telephones.

   RFC 3856, A Presence Event Package for SIP  Session Initiation Protocol (SIP) (S):  RFC 3856 [53]
      [I-D.ietf-rohc-sigcomp-sip] defines an event package for indicating user presence through how to apply Sigcomp to SIP.

13.  SIP Service URIs

   Several extensions define well-known services that can be invoked by
   constructing requests with the specific structures for the Request
   URI, resulting in specific behaviors at the UAS.

   RFC 3087, Control of Service Context using Request URI (I):
      [RFC3087] introduced the context of using Request URIs, encoded
      appropriately, to invoke services.

   RFC 3857, 4662, A Watcher Information SIP Event Template Package Notification Extension for SIP Resource Lists (S):
      RFC 3857 [54], also known as winfo, provides
      [RFC4662] defines a mechanism for resource called a
      user agent Resource List Server.  A
      client can send a subscribe to find out what subscriptions are in place for this server.  The server will
      generate a
      particular event package.  Its primary usage is with presence, but series of subscriptions, and compile the resulting
      information and send it can be used with any event package.

   RFC 4235, An INVITE Initiated Dialog Event Package for SIP (S):  RFC
      4235 [55] defines an event package for learning back to the state subscriber.  The set of
      resources that the
      dialogs in progress at a user agent, and RLS will subscribe to is one a property of several RFCs
      starting with the important number 42 [42].

   RFC 4575, A
      request URI in the SUBSCRIBE request.

   draft-ietf-sip-uri-list-subscribe, Subscriptions To Request-Contained
   Resource Lists in SIP Event Package for Conference State (S):  RFC 4575
      [56] defines  [I-D.ietf-sip-uri-list-subscribe] allows
      a mechanism for learning about changes client to subscribe to a resource called a Resource List Server.
      This server will generate a series of subscriptions, and compile
      the resulting information and send it back to the subscriber.  For
      this specification, the list of things to subscribe to is in the
      body of the SUBSCRIBE request.

   draft-ietf-sip-uri-list-message, Multiple-Recipient MESSAGE Requests
   in conference
      state, including group membership.

   RFC 4730, A SIP Event Package for Keypress Stimulus (KPML) (S):  RFC
      4730 [57] defines  [I-D.ietf-sip-uri-list-message] is similar to
      [I-D.ietf-sip-uri-list-subscribe].  However, instead of
      subscribing to the resource, a way for an application MESSAGE request is sent to the
      resource, and it will send a copy to each recipient.

   draft-ietf-sip-uri-list-conferencing, Conference Establishment Using
   Request-Contained Lists in the network SIP (S):
      [I-D.ietf-sip-uri-list-conferencing] is similar to
      subscribe
      [I-D.ietf-sip-uri-list-subscribe].  However, instead of
      subscribing to the set of keypresses made on resource, an INVITE request is sent to the keypad of
      resource, and it will act as a
      traditional telephone. conference focus and generate an
      invitation to each recipient in the list.

   RFC XXXX, 4240, Basic Network Media Services with SIP Event Package for Voice Quality Reporting (S):  RFC
      XXXX [58] (I):  [RFC4240]
      defines a way for SIP event package that enables the collection application servers to invoke announcement
      and reporting conferencing services from a media server.  This is
      accomplished through a set of metrics that measure defined URI parameters which tell
      the quality for Voice over
      Internet Protocol (VoIP) sessions. media server what to do, such as what file to play and what
      language to render it in.

   RFC XXXX, A 4458, Session Initiation Protocol (SIP) Event Package URIs for
   Session-Specific Session Policies (S):  RFC XXXX [96] Applications
   such as Voicemail and Interactive Voice Response (IVR) (I):
      [RFC4458] defines a way to invoke voicemail and IVR services by
      using a SIP
      event package that allows URI constructed in a proxy to notify particular way.

14.  Minor Extensions

   These SIP extensions don't fit easily into a user agent about its
      desire for the UA to single specific use certain codecs
   case.  They have somewhat general applicability, but they solve a
   relatively small problem or generally obey certain
      media session policies. provide an optimization.

   RFC 4488, Suppression of the SIP REFER Implicit Subscription (S):
      [RFC4488] defines an enhancement to REFER.  REFER normally creates
      an implicit subscription to the target of the REFER.  This
      subscription is used to pass back updates on the progress of the
      referral.  This extension allows that implicit subscription to be
      bypassed as an optimization.

   RFC XXXX, The Session Initiation Protocol (SIP) Pending Additions
   Event Package 4538, Request Authorization through Dialog Identification in SIP
   (S):  RFC XXXX [103] defines  [RFC4538] provides a SIP event package mechanism that allows a UA UAS to learn whether consent has been given for authorize a
      request because the
      addition of an address to requestor proves it knows a SIP "mailing list".  It dialog that is used in
      progress with the UAS.  The specification is useful in conjunction
      with the SIP application interaction framework for consent [101].

11.  Quality of Service

   Several specifications concern themselves
      [I-D.ietf-sipping-app-interaction-framework].

   RFC 4508, Conveying Feature Tags with the interactions of REFER Method in SIP with network Quality of Service (QoS) mechanisms. (S):
      [RFC4508] defines a mechanism for carrying RFC 3312, Integration 3840 feature tags
      in REFER.  It is useful for informing the target of Resource Management and the REFER
      about the characteristics of the intentended target of the
      referred request.

   draft-ietf-sip-answermode, Requesting Answer Modes for SIP (S):  RFC 3312
      [59], updated by RFC 4032 [60]
      [I-D.ietf-sip-answermode] defines a way an extension for indicating to make sure that the
      phone of
      the called party doesn't whether or not the phone should ring until a QoS reservation has
      been installed and/or be
      answered immediately.  This is useful for push-to-talk and for
      diagnostic applications.

   draft-ietf-sip-acr-code, Rejecting Anonymous Requests in the network.  It does so by defining a general
      preconditions framework, which SIP (S):
      [I-D.ietf-sip-acr-code] defines conditions a mechanism for a called party to
      indicate to the calling party that must be
      true a call was rejected since the
      caller was anonymous.  This is needed for implementation of the
      Anonymous Call Rejection (ACR) feature in order SIP.

   draft-ietf-sip-multiple-refer, Referring to Multiple Resources in SIP
   (S):  [I-D.ietf-sip-multiple-refer] allows a UA sending a REFER to
      ask the recipient of the REFER to generate multiple SIP requests,
      not just one.  This is useful for conferencing, where a SIP session client
      would like to proceed ask a conference server to eject multiple users.

   RFC 3313, Private SIP Extensions 4483, A Mechanism for Media Authorization (I):  RFC
      3313 [61] Content Indirection in Session Initiation
   Protocol (SIP) Messages (S):  [RFC4483] defines a P-header that provides a mechanism for passing
      content indirection.  Instead of carrying an authorization token between object within a SIP and
      body, a network QoS reservation
      protocol like RSVP.  Its purpose URL reference is carried instead, and the recipient
      dereferences the URL to make sure network QoS is
      only granted if a client has made a SIP call through obtain the same
      providers network.  This object.  The specification is sometimes referred has
      potential applicability for sending large instant messages, but
      has yet to as find much actual use.

   RFC 3890, A Transport Independent Bandwidth Modifier for the SIP walled garden specification by Session
   Description Protocol (SDP) (S):  [RFC3890] specifies an SDP extension
      that allows for the truly paranoid androids
      in description of the SIP community.  This bandwidth for a media
      session that is because it requires coupling independent of
      signaling and the underlying IP network. transport mechanism.

   RFC 3524, Mapping of Media 4583, Session Description Protocol (SDP) Format for Binary Floor
   Control Protocol (BFCP) Streams (S):  [RFC4583] defines a mechanism
      in SDP to Resource Reservation Flows signal floor control streams that use BFCP.  It is used
      for Push-To-Talk and conference floor control.

   draft-ietf-mmusic-connectivity-precon, Connectivity Preconditions for
   Session  Description Protocol Media Streams (S):
      [I-D.ietf-mmusic-connectivity-precon] defines a usage of the
      precondition framework [RFC3312].  The connectivity precondition
      makes sure that the session doesn't get established until actual
      packet connectivity is checked.

   RFC 3524 [97] 4796, The SDP (Session Description Protocol) Content Attribute
   (S):  [RFC4796] defines a usage of the an SDP grouping framework attribute for
      indicating that a set describing the purpose
      of a media streams should be handled by stream.  Examples include a
      single resource reservation.

12.  Operations slide view, the speaker, a
      sign language feed, and Management so on.

15.  Security Mechanisms

   Several specifications have been defined extensions provide additional security features to support operations and
   management of SIP systems.  These include mechanisms for
   configuration and network diagnostics. SIP.

   RFC XXXX, Diagnostic Responses 4474, Enhancements for Authenticated Identity Management in SIP Hop Limit Errors
   (S):  RFC
      XXXX [98]  [RFC4474] defines a mechanism for including diagnostic information
      in providing a 483 response.  This response is sent when the hop-count cryptographically
      verifiable identity of the calling party in a SIP request was exceeded.

   RFC XXXX, A Framework for SIP User Agent Profile Delivery (S):  RFC
      XXXX [62] defines a request.  Known
      as "SIP Identity", this mechanism that allows a SIP user agent provides an alternative to
      bootstrap RFC
      3325.  It has seen little deployment so far, but its configuration from the network, importance as
      a key construct for anti-spam techniques and receive updates
      to its configuration should new security
      mechanisms makes it change.  This is considered an
      essential piece of deploying a usable core part of the SIP network. specifications.

   RFC XXXX, Extensions to 3323, A Privacy Mechanism for the Session Initiation Protocol
   (SIP) User
   Agent Profile Delivery Change Notification Event Package (S):  [RFC3323] defines the Privacy header field, used by
      clients to request anonymity for their requests.  Though it
      defines several privacy services, the
   Extensible Markup Language Language Configuration Access only one broadly used is the
      one that supports privacy of the P-Asserted-Identity header field
      [RFC3325].

   RFC 4567, Key Management Extensions for Session Description Protocol
   (XCAP)
   (SDP) and Real Time Streaming Protocol (RTSP) (S):  RFC XXXX [63]  [RFC4567] defines an extension
      extensions to [62] SDP that allow tunneling of an key management
      protocol, namely MIKEY [RFC3830], through offer/answer exchanges.
      This mechanism is one of three SRTP keying techniques specified
      for learning
      about changes in documents managed by XCAP. SIP, with DTLS-SRTP [I-D.ietf-sip-dtls-srtp-framework] having
      been selected as the final solution.

   RFC XXXX, SIP Event Package 4568, Session Description Protocol (SDP) Security Descriptions
   for Voice Quality Reporting Media Streams (S):  RFC
      XXXX [58]  [RFC4568] defines a SIP event package extensions to SDP that enables
      allow for the collection
      and reporting negotiation of metrics keying material directly through
      offer/answer, without a separate key management protocol.  This
      mechanism, sometimes called sdescriptions, has the drawback that measure
      the quality for Voice over
      Internet Protocol (VoIP) sessions.

13.  SIP Compression

   Sigcomp [6] was defined media keys are available to allow compression of SIP messages over low
   bandwidth links.  Sigcomp any entity that has visibility to
      the SDP.  It is not formally part of SIP.  However,
   usage one of Sigcomp three SRTP keying techniques specified for
      SIP, with DTLS-SRTP [I-D.ietf-sip-dtls-srtp-framework] having been
      selected as the final solution.

   draft-ietf-sip-dtls-srtp-framework, Framework for Establishing an
   SRTP Security Context using DTLS (S):
      [I-D.ietf-sip-dtls-srtp-framework] defines the overall framework
      and SDP and SIP has processing required extensions to SIP. perform key management for
      RTP using Datagram TLS (DTLS) [RFC4347] directly between
      endpoints, over the media path.  It is one of three SRTP keying
      techniques specified for SIP, with DTLS-SRTP
      [I-D.ietf-sip-dtls-srtp-framework] having been selected as the
      final solution.

   RFC 3486, Compressing 3853, S/MIME AES Requirement for SIP (S):  [RFC3853] formally
      updates RFC 3486 [64] defines 3261.  It is a SIP URI
      parameter brief specification that can be updates the
      cryptography mechanisms used to indicate that a in SIP server supports
      Sigcomp.

14. S/MIME.  However, SIP S/MIME
      has seen very little deployment.

   draft-ietf-sip-certs, Certificate Management Service URIs

   Several extensions define well-known services that can be invoked by
   constructing requests with the specific structures for The Session
   Initiation Protocol (SIP) (S):  [I-D.ietf-sip-certs] defines a
      certificate service for SIP whose purpose is to facilitate the Request
   URI, resulting in specific behaviors at the UAS.

   RFC 3087, Control of Service Context using Request URI (I):  RFC 3087
      [66] introduced the context
      deployment of using Request URIs, encoded
      appropriately, S/MIME.  The certificate service allows clients to invoke services.

   RFC 4662, A SIP Event Notification Extension
      store and retrieve their own certificates, in addition to
      obtaining the certificates for Resource Lists (S): other users.

   RFC 4662 [67] 3893, Session Initiation Protocol (SIP) Authenticated Identity
   Body (AIB) Format (S):  [RFC3893] defines a resource called a Resource List Server.  A
      client SIP message fragment
      which can send a subscribe be signed in order to this server.  The server will
      generate provide an authenticated identity
      over a series of subscriptions, request.  It was an early predecessor to [RFC4474], and compile the resulting
      information
      consequently AIB has seen no deployment.

   draft-ietf-sip-saml, SIP SAML Profile and send it back to Binding (S):
      [I-D.ietf-sip-saml] defines the subscriber.  The set usage of
      resources that the RLS will subscribe Security Assertion
      Markup Language (SAML) within SIP, and describes how to is use it in
      conjunction with SIP identity [RFC4474] to provide authenticated
      assertions about a property of the
      request URI users role or attributes.

   draft-ietf-sip-consent-framework, A Framework for Consent-Based
   Communications in  the SUBSCRIBE request.

   RFC XXXX, Subscriptions To Request-Contained Resource Lists in SIP Session Initiation Protocol (SIP) (S):  RFC XXXX [68] allows a client to subscribe
      [I-D.ietf-sip-consent-framework] defines several extensions to a resource called
      a Resource List Server.  This server will generate a series of
      subscriptions, and compile
      SIP, including the resulting information Trigger-Consent and send it
      back Permission-Missing header
      fields.  These header fields, in addition to the subscriber.  For this specification, other procedures
      defined in the list of
      things to subscribe document, define a way to is in manage membership on "SIP
      mailing lists" used for instant messaging or conferencing.  In
      particular, it helps avoid the body problem of using such amplification
      services for the SUBSCRIBE request.

   RFC XXXX, Multiple-Recipient MESSAGE Requests in SIP (S):  RFC XXXX
      [69] is similar to [68].  However, instead purposes of subscribing to an attack on the
      resource, network, by making
      sure a MESSAGE request is sent to user authorizes the resource, and it will
      send addition of their address onto such a copy to each recipient.

   RFC XXXX, Conference Establishment Using Request-Contained Lists in
   SIP
      service.

   draft-ietf-sipping-pending-additions, The Session Initiation Protocol
   (SIP) Pending  Additions Event Package (S):  RFC XXXX [70] is similar to [68].  However, instead of
      subscribing
      [I-D.ietf-sipping-pending-additions] defines a SIP event package
      that allows a UA to learn whether consent has been given for the resource,
      addition of an INVITE request is sent address to the
      resource, and it will act as a conference focus and generate an
      invitation to each recipient SIP "mailing list".  It is used in the list.

   RFC 4240, Basic Network Media Services
      conjunction with the SIP (I):  RFC 4240 [99]
      defines a way framework for SIP application servers to invoke announcement
      and conferencing services from a media server.  This is
      accomplished through a set of defined URI parameters which tell
      the media server what to do, such as what file to play and what
      language to render it in.

15.  Security Mechanisms

   Several extensions provide additional security features to SIP. consent
      [I-D.ietf-sip-consent-framework].

   RFC 3853, S/MIME AES Requirement 3329, Security Mechanism Agreement for SIP (S):  RFC 3853 [71] is  [RFC3329]
      defines a
      brief specification that updates the cryptography mechanisms used mechanism to prevent bid-down attacks in conjunction
      with SIP S/MIME.  However, SIP S/MIME authentication.  The mechanism has seen very little limited
      deployment.

   RFC XXXX, Certificate Management Service for The Session Initiation
   Protocol (SIP)  It was defined as part of the 3gpp IMS specification
      suite [3GPP.24.229], and is needed only when there is a
      multiplicity of security mechanisms deployed at a particular
      server.  In practice, this has not been the case.

   draft-ietf-sip-e2m-sec, End-to-Middle Security in SIP (S):  RFC XXXX [100]
      [I-D.ietf-sip-e2m-sec] defines a certificate service mechanisms for providing
      confidentiality and integrity for SIP whose purpose is message bodies sent from
      user agents to facilitate specific network intermediaries.

   RFC 4572, Connection-Oriented Media Transport over the deployment of S/MIME.  The
      certificate service allows clients to store and retrieve their own
      certificates, Transport
   Layer Security (TLS) Protocol in addition to obtaining the certificates for other
      users.

   RFC 3893, Session Initiation Description Protocol (SIP) Authenticated Identity
   Body (AIB) Format
   (SDP) (S):  RFC 3893 [7] defines a SIP message fragment
      which can be signed in order to provide an authenticated identity
      over  [RFC4572] specifies a request. mechanism for signaling TLS-based
      media streams between endpoints.  It was an early predecessor to [19], and
      consequently AIB has seen no deployment.

   RFC XXXX, SIP SAML Profile and Binding (S):  RFC XXXX [102] defines
      the usage of expands the Security Assertion Markup Language (SAML) within
      SIP, and describes how to use it TCP-based media
      signaling parameters defined in conjunction with SIP identity
      [19] [RFC4145] to provide authenticated assertions about a users role or
      attributes.

   RFC XXXX, A Framework include fingerprint
      information for TLS streams, so that TLS can operate between end
      hosts using self-signed certificates.

   draft-ietf-mmusic-secruityprecondition, Security Preconditions for Consent-Based Communications in the
   Session
   Initiation Description  Protocol (SIP) Media Streams (S):  RFC XXX [101]
      [I-D.ietf-mmusic-securityprecondition] defines several
      extensions to SIP, including a precondition for
      use with the Trigger-Consent preconditions framework [RFC3312].  The security
      precondition prevents a session from being established until a
      security media stream is set up.

16.  Conferencing

   Numerous SIP and Permission-
      Missing header fields. SDP extensions are aimed at conferencing as their
   primary application.

   RFC 4574, The SDP (Session Description Protocol) Label Attribute
   (S):  [RFC4574] defines an SDP attribute for providing an opaque
      label for media streams.  These header fields, in addition labels can be referred to the
      other procedures defined by
      external documents, and in the document, define particular, by conference policy
      documents.  This allows a way UA to manage
      membership on "SIP mailing lists" used for instant messaging or
      conferencing.  In particular, tie together documents it helps avoid the problem of using
      such amplification services for may
      obtain through conferencing mechanisms to media streams to which
      they refer.

   RFC 3911, The SIP Join Header Field (S):  [RFC3911] defines the purposes of Join
      header field.  When sent in an attack on INVITE, it causes the
      network, by making sure a user authorizes recipient to
      join the addition of their
      address onto such resulting dialog into a service. conference with another dialog in
      progress.

   RFC XXXX, The Session Initiation Protocol (SIP) Pending Additions 4575, A SIP Event Package for Conference State (S):  RFC XXXX [103]  [RFC4575]
      defines a mechanism for learning about changes in conference
      state, including conference membership.

   draft-ietf-sip-multiple-refer, Referring to Multiple Resources in SIP event package that
   (S):  [I-D.ietf-sip-multiple-refer] allows a UA sending a REFER to learn whether consent has been given for
      ask the
      addition recipient of an address to a SIP "mailing list".  It is used in
      conjunction with the SIP framework for consent [101].

   RFC 3329, Security Mechanism Agreement for SIP (S):  RFC 3329 [72]
      defines a mechanism REFER to prevent bid-down attacks in conjunction
      with generate multiple SIP authentication.  The mechanism has seen very limited
      deployment.  It was defined as part of the 3gpp IMS specification
      suite [109], and requests,
      not just one.  This is needed only when there are a multiplicity of
      security mechanisms deployed at useful for conferencing, where a particular server.  In practice,
      this has not been the case.

   RFC XXXX, End-to-Middle Security client
      would like to ask a conference server to eject multiple users.

   draft-ietf-sip-uri-list-conferencing, Conference Establishment Using
   Request-Contained Lists in SIP (S):  RFC XXXX [73] defines
      mechanisms for providing confidentiality and integrity for SIP
      message bodies
      [I-D.ietf-sip-uri-list-conferencing] is similar to
      [I-D.ietf-sip-uri-list-subscribe].  However, instead of
      subscribing to the resource, an INVITE request is sent from user agents to specific network
      intermediaries.

   RFC 4572, Connection-Oriented Media Transport over the Transport
   Layer Security (TLS) Protocol
      resource, and it will act as a conference focus and generate an
      invitation to each recipient in the list.

   RFC 4583, Session Description Protocol (SDP) (S):  RFC 4572 [104] specifies a mechanism for signaling TLS-
      based media streams between endpoints.  It expands the TCP-based
      media signaling parameters defined in [86] to include fingerprint
      information for TLS streams, so that TLS can operate between end
      hosts using self-signed certificates.

   RFC XXXX, Security Preconditions Format for Session Description Binary Floor
   Control Protocol
   Media (BFCP) Streams (S):  RFC XXXX [92]  [RFC4583] defines a precondition for mechanism
      in SDP to signal floor control streams that use with
      the preconditions framework [59].  The security precondition
      prevents a session from being established until a security media
      stream BFCP.  It is set up.

16. used
      for Push-To-Talk and conference floor control.

17.  Instant Messaging, Presence and Multimedia

   SIP provides extensions for instant messaging, presence, and
   multimedia.

   RFC 3428, SIP Extension for Instant Messaging (S):  RFC 3428 [74]  [RFC3428] defines
      the MESSAGE method, used for sending an instant message without
      setting up a session (sometimes called "page mode").

   RFC 3856, A Presence Event Package for SIP (S):  RFC 3856 [53]  [RFC3856] defines an
      event package for indicating user presence through SIP.

   RFC 3857, A Watcher Information Event Template Package for SIP (S):
      RFC 3857 [54],
      [RFC3857], also known as winfo, provides a mechanism for a user
      agent to find out what subscriptions are in place for a particular
      event package.  Its primary usage is with presence, but it can be
      used with any event package.

   RFC XXXX,

   draft-ietf-mmusic-file-transfer-mech, A Session Description Protocol
   (SDP)  Offer/Answer Mechanism to Enable File Transfer (S):  RFC XXXX [107]
      [I-D.ietf-mmusic-file-transfer-mech] defines a mechanism for
      signaling a file transfer session with SIP.

17.

18.  Emergency Services

   Emergency services here covers both emergency calling (for example,
   911 in the United States), and pre-emption services, which allow
   authorized individuals to gain access to network resources in time of
   emergency.

   RFC 4411, Extending the SIP Reason Header for Preemption Events (S):
      RFC 4411 [75]
      [RFC4411] defines an extension to the Reason header, allowing a UA
      to know that its dialog was torn down because a higher priority
      session came through.

   RFC 4412, Communications Resource Priority for SIP (S):  RFC 4412
      [76]  [RFC4412]
      defines a new header field, Resource-Priority, that allows a
      session to get priority treatment from the network.

18.

19.  Security Considerations

   This specification is an overview of existing specifications, and
   does not introduce any security considerations on its own.  Of
   course, the world would be far more secure if everyone would follow
   one simple rule: "Don't Panic!" [42].

19.  [HGTTG].

20.  IANA Considerations

   None.

20.

21.  Acknowledgements

   The author would like to thank Spencer Dawkins Dawkins, Brian Stucker, John
   Elwell and Avshalom Houri for his their comments on this specification.

21. document.

22.  Informative References

   [1]

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [2]

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [3]

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", RFC 3550, July 2003.

   [4]

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [5]

   [I-D.ietf-mmusic-ice]
              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address  Translator (NAT)
              Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-16
              draft-ietf-mmusic-ice-19 (work in progress), June October 2007.

   [6]

   [RFC3320]  Price, R., Bormann, C., Christoffersson, J., Hannu, H.,
              Liu, Z., and J. Rosenberg, "Signaling Compression
              (SigComp)", RFC 3320, January 2003.

   [7]

   [RFC3893]  Peterson, J., "Session Initiation Protocol (SIP)
              Authenticated Identity Body (AIB) Format", RFC 3893,
              September 2004.

   [8]

   [RFC3427]  Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J.,
              and B. Rosen, "Change Process for the Session Initiation
              Protocol (SIP)", BCP 67, RFC 3427, December 2002.

   [9]

   [RFC2543]  Handley, M., Schulzrinne, H., Schooler, E., and J.
              Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
              March 1999.

   [10]

   [RFC3263]  Rosenberg, J. and H. Schulzrinne, "Session Initiation
              Protocol (SIP): Locating SIP Servers", RFC 3263,
              June 2002.

   [11]

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [12]

   [RFC2915]  Mealling, M. and R. Daniel, "The Naming Authority Pointer
              (NAPTR) DNS Resource Record", RFC 2915, September 2000.

   [13]

   [RFC3265]  Roach, A., "Session Initiation Protocol (SIP)-Specific
              Event Notification", RFC 3265, June 2002.

   [14]

   [RFC3323]  Peterson, J., "A Privacy Mechanism for the Session
              Initiation Protocol (SIP)", RFC 3323, November 2002.

   [15]

   [RFC3325]  Jennings, C., Peterson, J., and M. Watson, "Private
              Extensions to the Session Initiation Protocol (SIP) for
              Asserted Identity within Trusted Networks", RFC 3325,
              November 2002.

   [16]

   [RFC3327]  Willis, D. and B. Hoeneisen, "Session Initiation Protocol
              (SIP) Extension Header Field for Registering Non-Adjacent
              Contacts", RFC 3327, December 2002.

   [17]

   [RFC3581]  Rosenberg, J. and H. Schulzrinne, "An Extension to the
              Session Initiation Protocol (SIP) for Symmetric Response
              Routing", RFC 3581, August 2003.

   [18]

   [RFC4320]  Sparks, R., "Actions Addressing Identified Issues with the
              Session Initiation Protocol's (SIP) Non-INVITE
              Transaction", RFC 4320, January 2006.

   [19]

   [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
              Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", RFC 4474, August 2006.

   [20]

   [I-D.ietf-sip-gruu]
              Rosenberg, J., "Obtaining and Using Globally Routable User
              Agent (UA) URIs (GRUU) in the  Session Initiation Protocol
              (SIP)", draft-ietf-sip-gruu-14 draft-ietf-sip-gruu-15 (work in progress), June
              October 2007.

   [21]

   [I-D.ietf-sip-outbound]
              Jennings, C. and R. Mahy, "Managing Client Initiated
              Connections in the Session Initiation Protocol  (SIP)",
          draft-ietf-sip-outbound-09
              draft-ietf-sip-outbound-10 (work in progress), June July 2007.

   [22]

   [RFC2848]  Petrack, S. and L. Conroy, "The PINT Service Protocol:
              Extensions to SIP and SDP for IP Access to Telephone Call
              Services", RFC 2848, June 2000.

   [23]

   [RFC3910]  Gurbani, V., Brusilovsky, A., Faynberg, I., Gato, J., Lu,
              H., and M. Unmehopa, "The SPIRITS (Services in PSTN
              requesting Internet Services) Protocol", RFC 3910,
              October 2004.

   [24]

   [RFC3372]  Vemuri, A. and J. Peterson, "Session Initiation Protocol
              for Telephones (SIP-T): Context and Architectures",
              BCP 63, RFC 3372, September 2002.

   [25]

   [RFC3398]  Camarillo, G., Roach, A., Peterson, J., and L. Ong,
              "Integrated Services Digital Network (ISDN) User Part
              (ISUP) to Session Initiation Protocol (SIP) Mapping",
              RFC 3398, December 2002.

   [26]

   [RFC3578]  Camarillo, G., Roach, A., Peterson, J., and L. Ong,
              "Mapping of Integrated Services Digital Network (ISDN)
              User Part (ISUP) Overlap Signalling to the Session
              Initiation Protocol (SIP)", RFC 3578, August 2003.

   [27]

   [RFC3960]  Camarillo, G. and H. Schulzrinne, "Early Media and Ringing
              Tone Generation in the Session Initiation Protocol (SIP)",
              RFC 3960, December 2004.

   [28]

   [RFC3262]  Rosenberg, J. and H. Schulzrinne, "Reliability of
              Provisional Responses in Session Initiation Protocol
              (SIP)", RFC 3262, June 2002.

   [29]

   [RFC3311]  Rosenberg, J., "The Session Initiation Protocol (SIP)
              UPDATE Method", RFC 3311, October 2002.

   [30]

   [RFC2976]  Donovan, S., "The SIP INFO Method", RFC 2976,
              October 2000.

   [31]

   [RFC3326]  Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
              Header Field for the Session Initiation Protocol (SIP)",
              RFC 3326, December 2002.

   [32]

   [RFC3608]  Willis, D. and B. Hoeneisen, "Session Initiation Protocol
              (SIP) Extension Header Field for Service Route Discovery
              During Registration", RFC 3608, October 2003.

   [33]

   [RFC3840]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
              "Indicating User Agent Capabilities in the Session
              Initiation Protocol (SIP)", RFC 3840, August 2004.

   [34]

   [RFC3841]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
              Preferences for the Session Initiation Protocol (SIP)",
              RFC 3841, August 2004.

   [35]

   [RFC4028]  Donovan, S. and J. Rosenberg, "Session Timers in the
              Session Initiation Protocol (SIP)", RFC 4028, April 2005.

   [36]

   [RFC4168]  Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The
              Stream Control Transmission Protocol (SCTP) as a Transport
              for the Session Initiation Protocol (SIP)", RFC 4168,
              October 2005.

   [37]

   [RFC4244]  Barnes, M., "An Extension to the Session Initiation
              Protocol (SIP) for Request History Information", RFC 4244,
              November 2005.

   [38]

   [RFC4488]  Levin, O., "Suppression of Session Initiation Protocol
              (SIP) REFER Method Implicit Subscription", RFC 4488,
              May 2006.

   [39]

   [RFC4538]  Rosenberg, J., "Request Authorization through Dialog
              Identification in the Session Initiation Protocol (SIP)",
              RFC 4538, June 2006.

   [40]

   [RFC4508]  Levin, O. and A. Johnston, "Conveying Feature Tags with
              the Session Initiation Protocol (SIP) REFER Method",
              RFC 4508, May 2006.

   [41]

   [I-D.ietf-sip-answermode]
              Willis, D. and A. Allen, "Requesting Answering Modes for
              the Session Initiation Protocol (SIP)",
          draft-ietf-sip-answermode-04
              draft-ietf-sip-answermode-06 (work in progress), June
              September 2007.

   [42]

   [HGTTG]    Adams, D., "The Hitchhiker's Guide to the Galaxy",
              September 1979.

   [43]

   [I-D.ietf-sip-acr-code]
              Rosenberg, J., "Rejecting Anonymous Requests in the
              Session Initiation Protocol (SIP)", draft-ietf-sip-acr-code-04
              draft-ietf-sip-acr-code-05 (work in progress), March July 2007.

   [44]

   [I-D.ietf-sip-multiple-refer]
              Camarillo, G., Niemi, A., Isomaki, M., Garcia-Martin, M.,
              and H. Khartabil, "Referring to Multiple Resources in the
              Session Initiation Protocol (SIP)", draft-ietf-sip-multiple-refer-01
              draft-ietf-sip-multiple-refer-02 (work in progress), January
              November 2007.

   [45]

   [RFC3515]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
              Method", RFC 3515, April 2003.

   [46]

   [RFC3725]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
              Camarillo, "Best Current Practices for Third Party Call
              Control (3pcc) in the Session Initiation Protocol (SIP)",
              BCP 85, RFC 3725, April 2004.

   [47]

   [RFC3891]  Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
              Protocol (SIP) "Replaces" Header", RFC 3891,
              September 2004.

   [48]

   [RFC3892]  Sparks, R., "The Session Initiation Protocol (SIP)
              Referred-By Mechanism", RFC 3892, September 2004.

   [49]

   [RFC3911]  Mahy, R. and D. Petrie, "The Session Initiation Protocol
              (SIP) "Join" Header", RFC 3911, October 2004.

   [50]

   [RFC4117]  Camarillo, G., Burger, E., Schulzrinne, H., and A. van
              Wijk, "Transcoding Services Invocation in the Session
              Initiation Protocol (SIP) Using Third Party Call Control
              (3pcc)", RFC 4117, June 2005.

   [51]

   [RFC3903]  Niemi, A., "Session Initiation Protocol (SIP) Extension
              for Event State Publication", RFC 3903, October 2004.

   [52]

   [RFC3680]  Rosenberg, J., "A Session Initiation Protocol (SIP) Event
              Package for Registrations", RFC 3680, March 2004.

   [53]

   [RFC3856]  Rosenberg, J., "A Presence Event Package for the Session
              Initiation Protocol (SIP)", RFC 3856, August 2004.

   [54]

   [RFC3857]  Rosenberg, J., "A Watcher Information Event Template-Package Template-
              Package for the Session Initiation Protocol (SIP)",
              RFC 3857, August 2004.

   [55]

   [RFC4235]  Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
              Initiated Dialog Event Package for the Session Initiation
              Protocol (SIP)", RFC 4235, November 2005.

   [56]

   [RFC4575]  Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
              Initiation Protocol (SIP) Event Package for Conference
              State", RFC 4575, August 2006.

   [57]

   [RFC4730]  Burger, E. and M. Dolly, "A Session Initiation Protocol
              (SIP) Event Package for Key Press Stimulus (KPML)",
              RFC 4730, November 2006.

   [58]

   [I-D.ietf-sipping-rtcp-summary]
              Pendleton, A., "Session Initiation Protocol Package for
              Voice Quality Reporting Event",
              draft-ietf-sipping-rtcp-summary-02 (work in progress),
              May 2007.

   [59]

   [RFC3312]  Camarillo, G., Marshall, W., and J. Rosenberg,
              "Integration of Resource Management and Session Initiation
              Protocol (SIP)", RFC 3312, October 2002.

   [60]

   [RFC4032]  Camarillo, G. and P. Kyzivat, "Update to the Session
              Initiation Protocol (SIP) Preconditions Framework",
              RFC 4032, March 2005.

   [61]

   [RFC3313]  Marshall, W., "Private Session Initiation Protocol (SIP)
              Extensions for Media Authorization", RFC 3313,
              January 2003.

   [62]   Petrie, D. and S.

   [I-D.ietf-sipping-config-framework]
              Channabasappa, "A Framework for Session
          Initiation Protocol User Agent Profile Delivery",
          draft-ietf-sipping-config-framework-12 (work in progress),
          June 2007.

   [63]   Petrie, D., "Extensions to the Session Initiation Protocol
          (SIP) User Agent Profile  Delivery Change Notification Event
          Package for the Extensible Markup Language Language
          Configuration Access S., "A Framework for Session Initiation
              Protocol (XCAP)",
          draft-ietf-sip-xcap-config-00 User Agent Profile Delivery",
              draft-ietf-sipping-config-framework-13 (work in progress),
              October 2006.

   [64] 2007.

   [RFC3486]  Camarillo, G., "Compressing the Session Initiation
              Protocol (SIP)", RFC 3486, February 2003.

   [65]

   [RFC3482]  Foster, M., McGarry, T., and J. Yu, "Number Portability in
              the Global Switched Telephone Network (GSTN): An
              Overview", RFC 3482, February 2003.

   [66]

   [RFC3087]  Campbell, B. and R. Sparks, "Control of Service Context
              using SIP Request-URI", RFC 3087, April 2001.

   [67]

   [RFC4662]  Roach, A., Campbell, B., and J. Rosenberg, "A Session
              Initiation Protocol (SIP) Event Notification Extension for
              Resource Lists", RFC 4662, August 2006.

   [68]

   [I-D.ietf-sip-uri-list-subscribe]
              Camarillo, G., Roach, A., and O. Levin, "Subscriptions to
              Request-Contained Resource Lists in the Session Initiation
              Protocol (SIP)",
          draft-ietf-sip-uri-list-subscribe-01 draft-ietf-sip-uri-list-subscribe-02
              (work in progress),
          January November 2007.

   [69]

   [I-D.ietf-sip-uri-list-message]
              Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient
              MESSAGE Requests in the Session Initiation Protocol
              (SIP)",
          draft-ietf-sip-uri-list-message-01 draft-ietf-sip-uri-list-message-02 (work in
              progress),
          January November 2007.

   [70]

   [I-D.ietf-sip-uri-list-conferencing]
              Camarillo, G. and A. Johnston, "Conference Establishment
              Using Request-Contained Lists in the Session  Initiation
              Protocol (SIP)", draft-ietf-sip-uri-list-conferencing-01 draft-ietf-sip-uri-list-conferencing-02
              (work in progress), January November 2007.

   [71]

   [RFC3853]  Peterson, J., "S/MIME Advanced Encryption Standard (AES)
              Requirement for the Session Initiation Protocol (SIP)",
              RFC 3853, July 2004.

   [72]

   [RFC3329]  Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T.
              Haukka, "Security Mechanism Agreement for the Session
              Initiation Protocol (SIP)", RFC 3329, January 2003.

   [73]

   [I-D.ietf-sip-e2m-sec]
              Ono, K. and S. Tachimoto, "End-to-middle Security in the
              Session Initiation Protocol (SIP)", draft-ietf-sip-e2m-sec-05
              draft-ietf-sip-e2m-sec-06 (work in progress), March July 2007.

   [74]

   [RFC3428]  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
              and D. Gurle, "Session Initiation Protocol (SIP) Extension
              for Instant Messaging", RFC 3428, December 2002.

   [75]

   [RFC4411]  Polk, J., "Extending the Session Initiation Protocol (SIP)
              Reason Header for Preemption Events", RFC 4411,
              February 2006.

   [76]

   [RFC4412]  Schulzrinne, H. and J. Polk, "Communications Resource
              Priority for the Session Initiation Protocol (SIP)",
              RFC 4412, February 2006.

   [77]

   [I-D.ietf-sipping-app-interaction-framework]
              Rosenberg, J., "A Framework for Application Interaction in
              the Session Initiation Protocol  (SIP)",
              draft-ietf-sipping-app-interaction-framework-05 (work in
              progress), July 2005.

   [78]

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [79]

   [RFC3388]  Camarillo, G., Eriksson, G., Holler, J., and H.
              Schulzrinne, "Grouping of Media Lines in the Session
              Description Protocol (SDP)", RFC 3388, December 2002.

   [80]

   [RFC3605]  Huitema, C., "Real Time Control Protocol (RTCP) attribute
              in Session Description Protocol (SDP)", RFC 3605,
              October 2003.

   [81]

   [RFC4916]  Elwell, J., "Connected Identity in the Session Initiation
              Protocol (SIP)", RFC 4916, June 2007.

   [82]

   [I-D.ietf-sip-fork-loop-fix]
              Sparks, R., "Addressing an Amplification Vulnerability in
              Session Initiation Protocol  (SIP) Forking Proxies",
              draft-ietf-sip-fork-loop-fix-05 (work in progress),
              March 2007.

   [83]

   [RFC3959]  Camarillo, G., "The Early Session Disposition Type for the
              Session Initiation Protocol (SIP)", RFC 3959,
              December 2004.

   [84]

   [RFC3204]  Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet,
              F., Watson, M., and M. Zonoun, "MIME media types for ISUP
              and QSIG Objects", RFC 3204, December 2001.

   [85]

   [RFC3420]  Sparks, R., "Internet Media Type message/sipfrag",
              RFC 3420, November 2002.

   [86]

   [RFC4145]  Yon, D. and G. Camarillo, "TCP-Based Media Transport in
              the Session Description Protocol (SDP)", RFC 4145,
              September 2005.

   [87]

   [RFC4091]  Camarillo, G. and J. Rosenberg, "The Alternative Network
              Address Types (ANAT) Semantics for the Session Description
              Protocol (SDP) Grouping Framework", RFC 4091, June 2005.

   [88]

   [I-D.ietf-mmusic-ice-tcp]
              Rosenberg, J., "TCP Candidates with Interactive
              Connectivity Establishment (ICE", draft-ietf-mmusic-ice-tcp-03
              draft-ietf-mmusic-ice-tcp-04 (work in progress), March
              July 2007.

   [89]

   [RFC4483]  Burger, E., "A Mechanism for Content Indirection in
              Session Initiation Protocol (SIP) Messages", RFC 4483,
              May 2006.

   [90]

   [RFC3890]  Westerlund, M., "A Transport Independent Bandwidth
              Modifier for the Session Description Protocol (SDP)",
              RFC 3890, September 2004.

   [91]

   [RFC4583]  Camarillo, G., "Session Description Protocol (SDP) Format
              for Binary Floor Control Protocol (BFCP) Streams",
              RFC 4583, November 2006.

   [92]

   [I-D.ietf-mmusic-securityprecondition]
              Andreasen, F. and D. Wing, "Security Preconditions for
              Session Description Protocol (SDP) Media  Streams",
          draft-ietf-mmusic-securityprecondition-03
              draft-ietf-mmusic-securityprecondition-04 (work in
              progress),
          October 2006.

   [93] July 2007.

   [I-D.ietf-mmusic-connectivity-precon]
              Andreasen, F., "Connectivity Preconditions for Session
              Description Protocol Media Streams",
              draft-ietf-mmusic-connectivity-precon-02 (work in
              progress), June 2006.

   [94]

   [RFC4796]  Hautakorpi, J. and G. Camarillo, "The Session Description
              Protocol (SDP) Content Attribute", RFC 4796,
              February 2007.

   [95]

   [RFC4574]  Levin, O. and G. Camarillo, "The Session Description
              Protocol (SDP) Label Attribute", RFC 4574, August 2006.

   [96]

   [I-D.ietf-sipping-policy-package]
              Hilt, V. and G. Camarillo, "A Session Initiation Protocol
              (SIP) Event Package for Session-Specific  Session Policies.",
          draft-ietf-sipping-policy-package-03
              Policies", draft-ietf-sipping-policy-package-04 (work in
              progress),
          February August 2007.

   [97]

   [RFC3524]  Camarillo, G. and A. Monrad, "Mapping of Media Streams to
              Resource Reservation Flows", RFC 3524, April 2003.

   [98]   Lawrence, S., "Diagnostic Responses for Session Initiation
          Protocol Hop Limit Errors",
          draft-ietf-sip-hop-limit-diagnostics-03 (work in progress),
          June 2006.

   [99]

   [RFC4240]  Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
              Media Services with SIP", RFC 4240, December 2005.

   [100]

   [I-D.ietf-sip-certs]
              Jennings, C., "Certificate Management Service for The
              Session Initiation Protocol (SIP)", draft-ietf-sip-certs-03
              draft-ietf-sip-certs-04 (work in progress), March July 2007.

   [101]

   [I-D.ietf-sip-consent-framework]
              Rosenberg, J., Camarillo, G., and D. Willis, "A Framework
              for Consent-Based Consent-based Communications in the Session Initiation
              Protocol (SIP)",
          draft-ietf-sip-consent-framework-01 draft-ietf-sip-consent-framework-03 (work
              in progress), November 2006.

   [102] 2007.

   [I-D.ietf-sip-saml]
              Tschofenig, H., "SIP SAML Profile and Binding",
              draft-ietf-sip-saml-02 (work in progress), May 2007.

   [103]

   [I-D.ietf-sipping-pending-additions]
              Camarillo, G., "The Session Initiation Protocol (SIP)
              Pending Additions Event Package",
          draft-ietf-sipping-pending-additions-02
              draft-ietf-sipping-pending-additions-03 (work in
              progress),
          April November 2007.

   [104]

   [RFC4572]  Lennox, J., "Connection-Oriented Media Transport over the
              Transport Layer Security (TLS) Protocol in the Session
              Description Protocol (SDP)", RFC 4572, July 2006.

   [105]

   [I-D.ietf-mmusic-sdp-capability-negotiation]
              Andreasen, F., "SDP Capability Negotiation",
          draft-ietf-mmusic-sdp-capability-negotiation-05
              draft-ietf-mmusic-sdp-capability-negotiation-07 (work in
              progress), March October 2007.

   [106]

   [I-D.ietf-mmusic-sdp-media-capabilities]
              Andreasen, F., "SDP media capabilities Negotiation",
              draft-ietf-mmusic-sdp-media-capabilities-01 (work in
              progress), February 2007.

   [107]

   [I-D.ietf-mmusic-file-transfer-mech]
              Garcia-Martin, M., Isomaki, M., Camarillo, G., and S.
              Loreto, "A Session Description Protocol (SDP) Offer/Answer
              Mechanism to Enable File  Transfer",
          draft-ietf-mmusic-file-transfer-mech-03
              draft-ietf-mmusic-file-transfer-mech-04 (work in
              progress),
          June October 2007.

   [108]

   [I-D.ietf-sip-ice-option-tag]
              Rosenberg, J., "Indicating Support for Interactive
              Connectivity Establishment (ICE) in the  Session
              Initiation Protocol (SIP)",
              draft-ietf-sip-ice-option-tag-02 (work in progress),
              June 2007.

   [109]

   [3GPP.24.229]
              3GPP, "Internet Protocol (IP) multimedia call control
              protocol based on Session Initiation Protocol (SIP) and
              Session Description Protocol (SDP); Stage 3", 3GPP
              TS 24.229 5.19.0,
          June 5.20.0, September 2007.

   [110]

   [I-D.ietf-sip-record-route-fix]
              Froment, T. and C. Lebel, "Addressing Record-Route issues
              in the Session Initiation Protocol (SIP)",
          draft-ietf-sip-record-route-fix-00
              draft-ietf-sip-record-route-fix-01 (work in progress),
          July
              November 2007.

   [111]

   [I-D.ietf-sip-subnot-etags]
              Niemi, A., "An Extension to Session Initiation Protocol
              (SIP) Events for Conditional  Event Notification",
          draft-ietf-sip-subnot-etags-00
              draft-ietf-sip-subnot-etags-01 (work in progress), May
              August 2007.

   [112]

   [I-D.ietf-sip-sips]
              Audet, F., "The use of the SIPS URI Scheme in the Session
              Initiation Protocol (SIP)", draft-ietf-sip-sips-05 draft-ietf-sip-sips-06 (work
              in progress), August 2007.

   [RFC4896]  Surtees, A., West, M., and A. Roach, "Signaling
              Compression (SigComp) Corrections and Clarifications",
              RFC 4896, June 2007.

   [I-D.ietf-rohc-sigcomp-sip]
              Bormann, C., Liu, Z., Price, R., and G. Camarillo,
              "Applying Signaling Compression (SigComp) to the Session
              Initiation Protocol  (SIP)",
              draft-ietf-rohc-sigcomp-sip-08 (work in progress),
              September 2007.

   [I-D.ietf-simple-simple]
              Rosenberg, J., "SIMPLE made Simple: An Overview of the
              IETF Specifications for Instant  Messaging and Presence
              using the Session Initiation Protocol (SIP)",
              draft-ietf-simple-simple-00 (work in progress), July 2007.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

   [RFC4567]  Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
              Carrara, "Key Management Extensions for Session
              Description Protocol (SDP) and Real Time Streaming
              Protocol (RTSP)", RFC 4567, July 2006.

   [RFC4568]  Andreasen, F., Baugher, M., and D. Wing, "Session
              Description Protocol (SDP) Security Descriptions for Media
              Streams", RFC 4568, July 2006.

   [I-D.ietf-sip-dtls-srtp-framework]
              Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
              for Establishing an SRTP Security Context using DTLS",
              draft-ietf-sip-dtls-srtp-framework-00 (work in progress),
              November 2007.

   [I-D.ietf-ecrit-framework]
              Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
              "Framework for Emergency Calling using Internet
              Multimedia", draft-ietf-ecrit-framework-03 (work in
              progress), September 2007.

   [RFC2833]  Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF
              Digits, Telephony Tones and Telephony Signals", RFC 2833,
              May 2000.

   [RFC4458]  Jennings, C., Audet, F., and J. Elwell, "Session
              Initiation Protocol (SIP) URIs for Applications such as
              Voicemail and Interactive Voice Response (IVR)", RFC 4458,
              April 2006.

   [RFC3830]  Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
              Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
              August 2004.

   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security", RFC 4347, April 2006.

Author's Address

   Jonathan Rosenberg
   Cisco
   Edison, NJ
   US

   Email: jdrosen@cisco.com
   URI:   http://www.jdrosen.net

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

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