9.  Event Packages

   These are event packages defined to utilize the SIP events framework.
   Many of these are also listed elsewhere in their respective areas.

   RFC 3680, A SIP Event Package for Registrations (S):  [RFC3680]
      defines an event package for finding out about changes in
      registration state.

   GRUU-REG (S):  [GRUU-REG] is an extension to the registration event
      package [RFC3680] that allows user agents to learn about their
      GRUUs.  It is particularly useful in helping to synchronize a
      client and its registrar with their currently valid temporary
      GRUU.

   RFC 3842, A Message Summary and Message Waiting Indication Event
   Package for SIP (S):  [RFC3842] defines a way for a user agent to
      find out about voicemails and other messages that are waiting for
      it.  Its primary purpose is to enable the voicemail waiting lamp
      on most business telephones.

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

   RFC 3857, A Watcher Information Event Template Package for SIP (S):
      [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 4235, An INVITE-Initiated Dialog Event Package for SIP (S):
      [RFC4235] defines an event package for learning the state of the
      dialogs in progress at a user agent, and is one of several RFCs
      starting with the important number 42 [HGTTG].

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

   RFC 4730, A SIP Event Package for Key Press Stimulus (KPML) (S):
      [RFC4730] defines a way for an application in the network to
      subscribe to the set of key presses made on the keypad of a
      traditional telephone.  It, along with RFC 4733 [RFC4733], are the
      two mechanisms defined for handling DTMF.  RFC 4730 is a
      signaling-path solution, and RFC 4733 is a media-path solution.

   RTCP-SUM, SIP Event Package for Voice Quality Reporting  (S):
      [RTCP-SUM] defines a SIP event package that enables the collection
      and reporting of metrics that measure the quality for Voice over
      Internet Protocol (VoIP) sessions.

   SESSION-POLICY, A Framework for Session Initiation Protocol (SIP)
   Session Policies (S):  [SESSION-POLICY] defines a framework for
      session policies.  In this framework, policy servers are used to
      tell user agents about the media characteristics required for a
      particular session.  The session policy framework has not been
      widely implemented.

   POLICY-PACK, A Session Initiation Protocol (SIP) Event Package for
   Session-Specific Session Policies (S):  [POLICY-PACK] defines a SIP
      event package used in conjunction with the session policy
      framework [SESSION-POLICY].

   RFC 5362, The Session Initiation Protocol (SIP) Pending Additions
   Event Package (S):  [RFC5362] defines a SIP event package that allows
      a UA to learn whether consent has been given for the addition of
      an address to a SIP "mailing list".  It is used in conjunction
      with the SIP framework for consent [RFC5360].

10.  Quality of Service

   Several specifications concern themselves with the interactions of
   SIP with network Quality of Service (QoS) mechanisms.

   RFC 3312, Integration of Resource Management and SIP (S):  [RFC3312],
      updated by [RFC4032], defines a way to make sure that the phone of
      the called party doesn't ring until a QoS reservation has been
      installed in the network.  It does so by defining a general
      preconditions framework, which defines conditions that must be
      true in order for a SIP session to proceed.

   QoS-ID, Quality of Service (QoS) Mechanism Selection in the Session
   Description Protocol (SDP) (S):  [QoS-ID] defines a way for user
      agents to negotiate what type of end-to-end QoS mechanism to use
      for a session.  At this time, there are two that can be used: the
      Resource Reservation Protocol (RSVP) and Next Steps in Signaling
      (NSIS).  This negotiation is done through an SDP extension.  Due
      to limited deployment of RSVP and even more limited deployment of
      NSIS, this extension has not been widely used.

   RFC 3313, Private SIP Extensions for Media Authorization (I):
      [RFC3313] defines a P-header that provides a mechanism for passing
      an authorization token between SIP and a network QoS reservation
      protocol like RSVP.  Its purpose is to make sure network QoS is

      only granted if a client has made a SIP call through the same
      provider's network.  This specification is sometimes referred to
      as the SIP walled-garden specification by the truly paranoid
      androids in the SIP community.  This is because it requires
      coupling of signaling and the underlying IP network.

   RFC 3524, Mapping of Media Streams to Resource Reservation Flows
   (S):  [RFC3524] defines a usage of the SDP grouping framework for
      indicating that a set of media streams should be handled by a
      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.

   CONFIG-FRAME, A Framework for SIP User Agent Profile Delivery (S):
      [CONFIG-FRAME] defines a mechanism that allows a SIP user agent to
      bootstrap its configuration from the network and receive updates
      to its configuration, should it change.  This is considered an
      essential piece of deploying a usable SIP network.

   RTCP-SUM, SIP Event Package for Voice Quality Reporting  (S):
      [RTCP-SUM] defines a SIP event package that enables the collection
      and reporting of metrics that measure the quality for Voice over
      Internet Protocol (VoIP) sessions.

12.  SIP 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 3486, Compressing SIP (S):  [RFC3486] defines a SIP URI parameter
      that can be used to indicate that a SIP server supports Sigcomp.

   RFC 5049, Applying Signaling Compression (SigComp) to the Session
   Initiation Protocol (SIP) (S):  [RFC5049] defines how to apply
      Sigcomp to SIP.

13.  SIP Service URIs

   Several extensions define well-known services that can be invoked by
   constructing requests with specific structures for the Request URI,
   resulting in specific behaviors at the User Agent Server (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 4662, A SIP Event Notification Extension for Resource Lists (S):
      [RFC4662] defines a resource called a Resource List Server (RLS).
      A client can send a subscribe to this server.  The server will
      generate a series of subscriptions, compile the resulting
      information, and send it back to the subscriber.  The set of
      resources that the RLS will subscribe to is a property of the
      request URI in the SUBSCRIBE request.

   RFC 5363, Framework and Security Considerations for Session
   Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List
   Services (S):  [RFC5363] defines the framework for list services in
      SIP.  In this framework, a UA can include an XML list object in
      the body of various requests and the server will provide list-
      oriented services as a consequence.  For example, a SUBSCRIBE with
      a list subscribes to the URI in the list.

   RFC 5367, Subscriptions To Request-Contained Resource Lists in SIP
   (S):  [RFC5367] uses the URI-list framework [RFC5363] and allows a
      client to subscribe to a resource called a Resource List Server.
      This server will generate subscriptions to the URI in the list,
      compile the resulting information, and send it back to the
      subscriber.

   RFC 5365, Multiple-Recipient MESSAGE Requests in SIP (S):  [RFC5365]
      uses the URI-list framework [RFC5363] and allows a client to send
      a MESSAGE to a number of recipients.

   RFC 5366, Conference Establishment Using Request-Contained Lists in
   SIP (S):  [RFC5366] uses the URI-list framework [RFC5363].  It allows
      a client to ask the server to act as a conference focus and send
      an invitation to each recipient in the list.

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

   RFC 4458, Session Initiation Protocol (SIP) URIs for Applications
   such as Voicemail and Interactive Voice Response (IVR) (I):
      [RFC4458] defines a way to invoke voicemail and IVR services by
      using a SIP URI constructed in a particular way.

14.  Minor Extensions

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

   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 4538, Request Authorization through Dialog Identification in SIP
   (S):  [RFC4538] provides a mechanism that allows a UAS to authorize a
      request because the requestor proves it knows a dialog that is in
      progress with the UAS.  The specification is useful in conjunction
      with the SIP application interaction framework [INTERACT-FRAME].

   RFC 4508, Conveying Feature Tags with the REFER Method in SIP (S):
      [RFC4508] defines a mechanism for carrying RFC 3840 feature tags
      in REFER.  It is useful for informing the target of the REFER
      about the characteristics of the intended target of the referred
      request.

   RFC 5373, Requesting Answer Modes for SIP (S):  [RFC5373] defines an
      extension for indicating to the called party whether or not the
      phone should ring and/or be answered immediately.  This is useful
      for push-to-talk and for diagnostic applications.

   RFC 5079, Rejecting Anonymous Requests in SIP (S):  [RFC5079] defines
      a mechanism for a called party to indicate to the calling party
      that a call was rejected since the caller was anonymous.  This is
      needed for implementation of the Anonymous Call Rejection (ACR)
      feature in SIP.

   RFC 5368, Referring to Multiple Resources in SIP (S):  [RFC5368]
      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 client would like to ask a conference server
      to eject multiple users.

   RFC 4483, A Mechanism for Content Indirection in Session Initiation
   Protocol (SIP) Messages (S):  [RFC4483] defines a mechanism for
      content indirection.  Instead of carrying an object within a SIP
      body, a URL reference is carried instead, and the recipient
      dereferences the URL to obtain the object.  The specification has
      potential applicability for sending large instant messages, but

      has yet to find much actual use.

   RFC 3890, A Transport Independent Bandwidth Modifier for the Session
   Description Protocol (SDP) (S):  [RFC3890] specifies an SDP extension
      that allows for the description of the bandwidth for a media
      session that is independent of the underlying transport mechanism.

   RFC 4583, Session Description Protocol (SDP) Format for Binary Floor
   Control Protocol (BFCP) Streams (S):  [RFC4583] defines a mechanism
      in SDP to signal floor control streams that use BFCP.  It is used
      for push-to-talk and conference floor control.

   CONNECT-PRECON, Connectivity Preconditions for Session Description
   Protocol Media Streams (S):  [CONNECT-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 4796, The SDP (Session Description Protocol) Content Attribute
   (S):  [RFC4796] defines an SDP attribute for describing the purpose
      of a media stream.  Examples include a slide view, the speaker, a
      sign language feed, and so on.

   IPv6-TRANS, IPv6 Transition in the Session Initiation Protocol (SIP)
   (S):  [IPv6-TRANS] defines practices for interworking between IPv6
      and IPv6 user agents.  This is done through multi-homed proxies
      that interwork IPv4 and IPv6, along with ICE [ICE] for media
      traversal.  The specification includes some minor extensions and
      clarifications to SDP in order to cover some additional cases.

   CONNECT-REUSE, Connection Reuse in the Session Initiation Protocol
   (SIP) (S):  [CONNECT-REUSE] defines an extension to SIP that allows a
      Transport Layer Security (TLS) connection between servers to be
      reused for requests in both directions.  Normally, two connections
      are set up between a pair of servers, one for requests in each
      direction.

15.  Security Mechanisms

   Several extensions provide additional security features to SIP.

   RFC 4474, Enhancements for Authenticated Identity Management in SIP
   (S):  [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 4916, Connected Identity in the Session Initiation Protocol (SIP)
   (S):  [RFC4916] formally updates RFC 3261.  It defines an extension
      to SIP that allows a calling user to determine the identity of the
      final called user (connected party).  Due to forwarding and
      retargeting services, this may not be the same as the user that
      the caller was originally trying to reach.  The mechanism works in
      tandem with the SIP identity specification [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.

   SIPS-URI, The Use of the SIPS URI Scheme in the Session Initiation
   Protocol (SIP) (S):  [SIPS-URI] is intended to update RFC 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.

   DOMAIN-CERTS, Domain Certificates in the Session Initiation Protocol
   (SIP) (B):  [DOMAIN-CERTS] clarifies the usage of SIP over TLS with
      regards to certificate handling, and defines additional procedures
      needed for interoperability.

   RFC 3323, A Privacy Mechanism for the Session Initiation Protocol
   (SIP) (S):  [RFC3323] defines the Privacy header field, used by
      clients to request anonymity for their requests.  Though it
      defines several privacy services, the 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
   (SDP) and Real Time Streaming Protocol (RTSP) (S):  [RFC4567] defines
      extensions to SDP that allow tunneling of a key management
      protocol, namely MIKEY [RFC3830], through offer/answer exchanges.
      This mechanism is one of three Secure Realtime Transport Protocol
      (SRTP) keying techniques specified for SIP, with Datagram
      Transport Layer Security (DTLS)-SRTP [SRTP-FRAME] having been
      selected as the final solution.

   RFC 4568, Session Description Protocol (SDP) Security Descriptions
   for Media Streams (S):  [RFC4568] defines extensions to SDP that
      allow for the negotiation of keying material directly through
      offer/answer, without a separate key management protocol.  This
      mechanism, sometimes called sdescriptions, has the drawback that
      the media keys are available to any entity that has visibility to
      the SDP.  It is one of three SRTP keying techniques specified for
      SIP, with DTLS-SRTP [SRTP-FRAME] having been selected as the final
      solution.

   SRTP-FRAME, Framework for Establishing an SRTP Security Context using
   DTLS (S):  [SRTP-FRAME] defines the overall framework and SDP and SIP
      processing required to 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 [SRTP-FRAME] having been selected as the
      final solution.

   RFC 3853, S/MIME Advanced Encryption Standard (AES) Requirement for
   SIP (S):  [RFC3853] formally updates RFC 3261.  It is a brief
      specification that updates the cryptography mechanisms used in SIP
      S/MIME.  However, SIP S/MIME has seen very little deployment.

   CERTS, Certificate Management Service for the Session Initiation
   Protocol (SIP) (S):  [CERTS] defines a certificate service for SIP
      whose purpose is to facilitate the deployment of S/MIME.  The
      certificate service allows clients to store and retrieve their own
      certificates, in addition to obtaining the certificates for other
      users.

   RFC 3893, Session Initiation Protocol (SIP) Authenticated Identity
   Body (AIB) Format (S):  [RFC3893] defines a SIP message fragment that
      can be signed in order to provide an authenticated identity over a
      request.  It was an early predecessor to [RFC4474], and
      consequently AIB has seen no deployment.

   SAML, SIP SAML Profile and Binding (S):  [SAML] defines the usage of
      the Security Assertion Markup Language (SAML) within SIP, and
      describes how to use it in conjunction with SIP identity [RFC4474]
      to provide authenticated assertions about a user's role or
      attributes.

   RFC 5360, A Framework for Consent-Based Communications in the Session
   Initiation Protocol (SIP) (S):  [RFC5360] defines several extensions
      to SIP, including the Trigger-Consent and Permission-Missing
      header fields.  These header fields, in addition to the other
      procedures defined in the document, define a way to manage
      membership on "SIP mailing lists" used for instant messaging or
      conferencing.  In particular, it helps avoid the problem of using
      such amplification services for the purposes of an attack on the
      network by making sure a user authorizes the addition of their
      address onto such a service.

   RFC 5361, A Document Format for Requesting Consent (S):  [RFC5361]
      defines an XML object used by the consent framework.  Consent
      documents are sent from SIP "mailing list servers" to users to
      allow them to manage their membership on lists.

   RFC 5362, The Session Initiation Protocol (SIP) Pending Additions
   Event Package (S):  [RFC5362] defines a SIP event package that allows
      a UA to learn whether consent has been given for the addition of
      an address to a SIP "mailing list".  It is used in conjunction
      with the SIP framework for consent [RFC5360].

   RFC 3329, Security Mechanism Agreement for SIP (S):  [RFC3329]
      defines a mechanism to prevent bid-down attacks in conjunction
      with SIP authentication.  The mechanism has seen very limited
      deployment.  It was defined as part of the 3GPP IP Multimedia
      Subsystem (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.

   RFC 4572, Connection-Oriented Media Transport over the Transport
   Layer Security (TLS) Protocol in the Session Description Protocol
   (SDP) (S):  [RFC4572] specifies a mechanism for signaling TLS-based
      media streams between endpoints.  It expands the TCP-based media
      signaling parameters defined in [RFC4145] to include fingerprint
      information for TLS streams so that TLS can operate between end
      hosts using self-signed certificates.

   RFC 5027, Security Preconditions for Session Description Protocol
   Media Streams (S):  [RFC5027] defines a precondition for use with the
      preconditions framework [RFC3312].  The security precondition
      prevents a session from being established until a security media
      stream is set up.

   RFC 3310, Hypertext Transfer Protocol (HTTP) Digest Authentication
   Using Authentication and Key Agreement (S):  [RFC3310] defines an
      extension to digest authentication to allow it to work with the
      credentials stored in cell phones.  Though technically it is an
      extension to HTTP digest, its primary application is SIP.  This
      extension is useful primarily to implementors of IMS.

   RFC 4169, Hypertext Transfer Protocol (HTTP) Digest Authentication
   Using Authentication and Key Agreement (AKA) Version-2 (S):
      [RFC4169] is an enhancement to [RFC3310] that further improves
      security of the authentication.

16.  Conferencing

   Numerous SIP and 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 labels can be referred to by
      external documents, and in particular, by conference policy
      documents.  This allows a UA to tie together documents it may
      obtain through conferencing mechanisms to media streams to which
      they refer.

   RFC 3911, The SIP Join Header Field (S):  [RFC3911] 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 4575, A SIP Event Package for Conference State (S):  [RFC4575]
      defines a mechanism for learning about changes in conference
      state, including conference membership.

   RFC 5368, Referring to Multiple Resources in SIP (S):  [RFC5368]
      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 client would like to ask a conference server
      to eject multiple users.

   RFC 5366, Conference Establishment Using Request-Contained Lists in
   SIP (S):  [RFC5366] is similar to [RFC5367].  However, instead of
      subscribing to the resource, an INVITE request is sent to the
      resource, and it will act as a conference focus and generate an
      invitation to each recipient in the list.

   RFC4579, Session Initiation Protocol (SIP) Call Control -
   Conferencing for User Agents (B):  [RFC4579] defines best practice
      procedures and call flows for conferencing.  This includes
      conference creation, joining, and dial out, amongst other
      capabilities.

   RFC 4583, Session Description Protocol (SDP) Format for Binary Floor
   Control Protocol (BFCP) Streams (S):  [RFC4583] defines a mechanism
      in SDP to signal floor control streams that use BFCP.  It is 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):  [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):  [RFC3856] defines an
      event package for indicating user presence through SIP.

   RFC 3857, A Watcher Information Event Template Package for SIP (S):
      [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.

   TRANSFER-MECH, A Session Description Protocol (SDP)  Offer/Answer
   Mechanism to Enable File Transfer (S):  [TRANSFER-MECH] defines a
      mechanism for signaling a file transfer session with SIP.

18.  Emergency Services

   Emergency services include preemption features, which allow
   authorized individuals to gain access to network resources in time of
   emergency, along with traditional emergency calling.

   RFC 4411, Extending the SIP Reason Header for Preemption Events (S):
      [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):  [RFC4412]
      defines a new header field, Resource-Priority, that allows a
      session to get priority treatment from the network.

   LOCATION, Location Conveyance for the Session Initiation Protocol
   (S):  [LOCATION] defines a mechanism for carrying location objects in
      SIP messages.  This is used to convey location from a UA to an
      emergency call taker.

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!"  [HGTTG].

20.  Acknowledgements

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

   document.