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

Versions: (draft-rosenberg-sip-hitchhikers-guide) 00 01 02 03 04 05 06 RFC 5411

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


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

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




Rosenberg                Expires January 6, 2008                [Page 1]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


Table of Contents

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


























Rosenberg                Expires January 6, 2008                [Page 2]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


1.  Introduction

   The Session Initiation Protocol (SIP) [1] 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] 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].  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, 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 to RFC 3261 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 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, where
      an extension is a mechanism that changes or updates in some way a
      behavior specified in RFC 3261

   o  Any specification that defines an extension to SDP whose primary
      purpose is to support SIP




Rosenberg                Expires January 6, 2008                [Page 3]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


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


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

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






Rosenberg                Expires January 6, 2008                [Page 4]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


   RFC 3263, Locating SIP Servers (S):  RFC 3263 [10] 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] and NAPTR records [12].

   RFC 3264, An Offer/Answer Model with the Session Description Protocol
   (S):  RFC 3264 [4] defines how the Session Description Protocol (SDP)
      [78] 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] 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], which defines the
      P-Asserted-ID header field has been widely deployed.  It is used
      as the basic mechanism for providing secure caller ID services.

   RFC 3327, SIP Extension Header Field for Registering Non-Adjacent
   Contacts (S):  RFC 3327 [16] 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] defines the rport parameter of the Via header.  It
      is an essential piece of getting SIP through NAT.  NAT traversal
      for SIP is considered a core part of the specifications.

   RFC 3840, Indicating User Agent Capabilities in SIP (S):  RFC 3840
      [33] 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.





Rosenberg                Expires January 6, 2008                [Page 5]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


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

   RFC 4474, Enhancements for Authenticated Identity Management in SIP
   (S):  RFC 4474 [19] 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
      makes it a core part of the SIP specifications.

   RFC XXXX, Obtaining and Using Globally Routable User Agent
   Identifiers (GRUU) in SIP (S):  RFC XXXX [20] 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, Managing Client Initiated Connections through SIP (S):  RFC
      XXXX [21], 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] 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, SDP Capability Negotiation (S):  RFC XXXX [105] 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.







Rosenberg                Expires January 6, 2008                [Page 6]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


   RFC XXXX, Interactive Connectivity Establishment (ICE) (S):  RFC XXXX
      [5] 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] 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] 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].  It is needed for devices behind NAT
      and used by ICE.

   RFC 4916, Connected Identity in the Session Initiation Protocol (SIP)
   (S):  RFC 4916 [81] defines an extension to SIP that allows a UAC to
      determine the identity of the UAS.  Due to forwarding and
      retargeting services, this may not be the same as the user that
      the UAC was originally trying to reach.  The mechanism works in
      tandem with the SIP identity specification [19] to provide
      signatures over the connected party identity.

   RFC XXXX, The use of the SIPS URI Scheme in the Session Initiation
   Protocol (SIP) (S):  RFC XXXX [112] 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] and a
      clarification on how record-routing works [110].


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





Rosenberg                Expires January 6, 2008                [Page 7]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


   RFC 3910, The SPIRITS Protocol (S):  Continuing the trend of naming
      PSTN related extensions with alcohol references, SPIRITS [23]
      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].

   RFC 3372, SIP for Telephones (SIP-T): Context and Architectures (I):
      SIP-T [24] 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].  SIP-T has seen widespread
      implementation.

   RFC 3398, ISUP to SIP Mapping (S):  RFC 3398 [25] 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] 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] defines some guidelines for handling early media - the
      practice of sending media from the called party towards the caller
      - prior to acceptance of the call.  Early media is generated only
      from the PSTN.

   RFC 3959, Early Session Disposition Type for the Session Initiation
   Protocol (SIP) (S):  RFC 3959 [83] 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.

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







Rosenberg                Expires January 6, 2008                [Page 8]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


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] 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 levels of deployment.

   RFC 3323, A Privacy Mechanism for the Session Initiation Protocol
   (SIP) (S):  RFC 3323 [14] defines the Privacy header field, used by
      clients to request anonymity for their requests.  Though it
      defines numerous 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].

   RFC 2976, The INFO Method (S):  RFC 2976 [30] was defined as an
      extension to RFC 2543.  It defines a method, INFO, used to
      transport 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].  It has been used to support numerous
      proprietary and non-interoperable extensions due to its poorly
      defined scope.







Rosenberg                Expires January 6, 2008                [Page 9]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


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

   RFC 3420, Internet Media Type message/sipfrag (S):  RFC 3420 [85]
      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] allows a client to determine,
      from a REGISTER response, a path of proxies to use in requests it
      sends outside of a dialog.  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] 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.

   RFC 4028, Session Timers in SIP (S):  RFC 4028 [35] 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 seen little deployment.

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

   RFC 4244, An Extension to SIP for Request History Information (S):
      RFC 4244 [37] defines the History-Info header field, which
      indicates information on how 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] 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



Rosenberg                Expires January 6, 2008               [Page 10]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


      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] defines a mechanism for including both IPv4 and IPv6
      addresses for a media session as alternates.

   RFC XXXX, SDP Media Capabilities Negotiation (S):  RFC XXXX [106]
      defines an extension to the SDP capability negotiation framework
      [105] 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, Interactive Connectivity Establishment (ICE) (S):  RFC XXXX
      [5] 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] have been defined for use with
      ICE.

   RFC XXXX, TCP Candidates with Interactive Connectivity Establishment
   (ICE) (S):  RFC XXXX [88] 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] 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].  It is needed for devices behind NAT
      and used by ICE.

   RFC XXXX, Managing Client Initiated Connections through SIP (S):  RFC
      XXXX [21], 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] defines the rport parameter of the Via header.  It
      is an essential piece of getting SIP through NAT.  NAT traversal
      for SIP is considered a core part of the specifications.



Rosenberg                Expires January 6, 2008               [Page 11]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


   RFC XXXX, Obtaining and Using Globally Routable User Agent
   Identifiers (GRUU) in SIP (S):  RFC XXXX [20] 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.


7.  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):
      RFC 4488 [38] 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):  RFC 4538 [39] 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 [77].

   RFC 4508, Conveying Feature Tags with the REFER Method in SIP (S):
      RFC 4508 [40] 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 REFER target.

   RFC XXXX, Requesting Answer Modes for SIP (S):  RFC XXXX [41] 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 XXXX, Rejecting Anonymous Requests in SIP (S):  RFC XXXX [43]
      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 XXXX, Referring to Multiple Resources in SIP (S):  RFC XXXX [44]
      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.




Rosenberg                Expires January 6, 2008               [Page 12]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


   RFC 4483, A Mechanism for Content Indirection in Session Initiation
   Protocol (SIP) Messages (S):  RFC 4483 [89] 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):  RFC 3890 [90] specifies an SDP
      extension that allows for the description of the bandwidth for a
      media session that is independent of 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 a
      mechanism in SDP to signal floor control streams that use BFCP.
      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 the
      session doesn't get established until actual packet connectivity
      is checked.

   RFC 4796, The SDP (Session Description Protocol) Content Attribute
   (S):  RFC 4796 [94] 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.


8.  Conferencing

   Numerous SIP and SDP extensions are aimed at conferencing as their
   primary application.

   RFC 4574, The SDP (Session Description Protocol) Label Attribute
   (S):  RFC 4574 [95] 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):  RFC 3911 [49] 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.



Rosenberg                Expires January 6, 2008               [Page 13]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


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

   RFC XXXX, Conference Establishment Using Request-Contained Lists in
   SIP (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 a conference focus and generate an
      invitation to each recipient 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
   to build many SIP-based services.

   RFC 3515, The REFER Method (S):  REFER [45] defines a mechanism for
      asking a user agent to send a SIP request.  Its a form of SIP
      remote control, and is the primary tool used for call transfer in
      SIP.

   RFC 3725, Best Current Practices for Third Party Call Control (3pcc)
   (B):  RFC 3725 [46] defines a number of different call flows that
      allow one SIP entity, called the controller, to create SIP
      sessions amongst other SIP user agents.

   RFC 3911, The SIP Join Header Field (S):  RFC 3911 [49] 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 (S):  RFC 3891 [47] defines a
      mechanism that allows a new dialog to replace an existing dialog.
      It is useful for certain advanced transfer services.

   RFC 3892, The SIP Referred-By Mechanism (S):  RFC 3892 [48] defines
      the Referred-By header field.  It is used in requests triggered by
      REFER, and provides the identity of the referring party to the
      referred-to party.

   RFC 4117, Transcoding Services Invocation in SIP Using Third Party
   Call Control (I):  RFC 4117 [50] defines how to use 3pcc for the
      purposes of invoking transcoding services for a call.







Rosenberg                Expires January 6, 2008               [Page 14]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


10.  Event Framework and Packages

   RFC 3265 defines a basic framework for event notification in SIP.  It
   introduces the notion of an event package, which is a collection of
   related state and event information.  Much of the state and events in
   SIP systems have event packages, allowing other entities to learn
   about changes in that state.

   RFC 3903, SIP Extension for Event State Publication (S):  RFC 3903
      [51] defines the PUBLISH method.  It is not an event package, but
      is used by all event packages as 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 an extension
      to RFC 3265 that allows a client to subscribe to a list of
      resources using a single subscription.  The server, called a
      Resource List Server (RLS) will "expand" the subscription and
      subscribe to each individual member of the list.  It has found
      applicability primarily in the area of presence, but can be used
      with any event package.

   RFC XXXX, An Extension to Session Initiation Protocol (SIP) Events
   for Conditional Event Notification (S):  RFC XXXX [111] defines an
      extension to RFC 3265 to optimize the performance of
      notifications.  When a client subscribes, it can indicate what
      version of a document it has, so that the server can skip sending
      a notification if the client is up to date.  It is applicable to
      any event package.

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

   RFC 3842, A Message Summary and Message Waiting Indication Event
   Package for SIP (S):  RFC 3842 [65] 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):  RFC 3856 [53]
      defines an event package for indicating user presence through SIP.

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



Rosenberg                Expires January 6, 2008               [Page 15]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


   RFC 4235, An INVITE Initiated Dialog Event Package for SIP (S):  RFC
      4235 [55] 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 [42].

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

   RFC 4730, A SIP Event Package for Keypress Stimulus (KPML) (S):  RFC
      4730 [57] defines a way for an application in the network to
      subscribe to the set of keypresses made on the keypad of a
      traditional telephone.

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

   RFC XXXX, A Session Initiation Protocol (SIP) Event Package for
   Session-Specific Session Policies (S):  RFC XXXX [96] defines a SIP
      event package that allows a proxy to notify a user agent about its
      desire for the UA to use certain codecs or generally obey certain
      media session policies.

   RFC XXXX, The Session Initiation Protocol (SIP) Pending Additions
   Event Package (S):  RFC XXXX [103] 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 [101].


11.  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):  RFC 3312
      [59], updated by RFC 4032 [60] 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

   RFC 3313, Private SIP Extensions for Media Authorization (I):  RFC
      3313 [61] 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



Rosenberg                Expires January 6, 2008               [Page 16]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


      only granted if a client has made a SIP call through the same
      providers 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):  RFC 3524 [97] defines a usage of the SDP grouping framework for
      indicating that a set of media streams should be handled by a
      single resource reservation.


12.  Operations and Management

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

   RFC XXXX, Diagnostic Responses for SIP Hop Limit Errors (S):  RFC
      XXXX [98] defines a mechanism for including diagnostic information
      in a 483 response.  This response is sent when the hop-count of a
      SIP request was exceeded.

   RFC XXXX, A Framework for SIP User Agent Profile Delivery (S):  RFC
      XXXX [62] 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.

   RFC XXXX, Extensions to the Session Initiation Protocol (SIP) User
   Agent Profile Delivery Change Notification Event Package for the
   Extensible Markup Language Language Configuration Access Protocol
   (XCAP) (S):  RFC XXXX [63] defines an extension to [62] for learning
      about changes in documents managed by XCAP.

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


13.  SIP Compression

   Sigcomp [6] 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.





Rosenberg                Expires January 6, 2008               [Page 17]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


   RFC 3486, Compressing SIP (S):  RFC 3486 [64] defines a SIP URI
      parameter that can be used to indicate that a SIP server supports
      Sigcomp.


14.  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):  RFC 3087
      [66] introduced the context of using Request URIs, encoded
      appropriately, to invoke services.

   RFC 4662, A SIP Event Notification Extension for Resource Lists (S):
      RFC 4662 [67] defines a resource called a Resource List Server.  A
      client can send a subscribe to this server.  The server will
      generate a series of subscriptions, and 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 XXXX, Subscriptions To Request-Contained Resource Lists in SIP
   (S):  RFC XXXX [68] allows a 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.

   RFC XXXX, Multiple-Recipient MESSAGE Requests in SIP (S):  RFC XXXX
      [69] is similar to [68].  However, instead of subscribing to the
      resource, a MESSAGE request is sent to the resource, and it will
      send a copy to each recipient.

   RFC XXXX, Conference Establishment Using Request-Contained Lists in
   SIP (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 a conference focus and generate an
      invitation to each recipient in the list.

   RFC 4240, Basic Network Media Services with SIP (I):  RFC 4240 [99]
      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 which tell
      the media server what to do, such as what file to play and what
      language to render it in.




Rosenberg                Expires January 6, 2008               [Page 18]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


15.  Security Mechanisms

   Several extensions provide additional security features to SIP.

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

   RFC XXXX, Certificate Management Service for The Session Initiation
   Protocol (SIP) (S):  RFC XXXX [100] 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):  RFC 3893 [7] defines a SIP message fragment
      which can be signed in order to provide an authenticated identity
      over a request.  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 the Security Assertion Markup Language (SAML) within
      SIP, and describes how to use it in conjunction with SIP identity
      [19] to provide authenticated assertions about a users role or
      attributes.

   RFC XXXX, A Framework for Consent-Based Communications in the Session
   Initiation Protocol (SIP) (S):  RFC XXX [101] 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 XXXX, The Session Initiation Protocol (SIP) Pending Additions
   Event Package (S):  RFC XXXX [103] 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 [101].







Rosenberg                Expires January 6, 2008               [Page 19]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


   RFC 3329, Security Mechanism Agreement for SIP (S):  RFC 3329 [72]
      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 IMS specification
      suite [109], and is needed only when there are a multiplicity of
      security mechanisms deployed at a particular server.  In practice,
      this has not been the case.

   RFC XXXX, End-to-Middle Security in SIP (S):  RFC XXXX [73] defines
      mechanisms for providing confidentiality and integrity for SIP
      message bodies sent from user agents to specific network
      intermediaries.

   RFC 4572, Connection-Oriented Media Transport over the Transport
   Layer Security (TLS) Protocol in the 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 for Session Description Protocol
   Media Streams (S):  RFC XXXX [92] defines a precondition for use with
      the preconditions framework [59].  The security precondition
      prevents a session from being established until a security media
      stream is set up.


16.  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]
      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]
      defines an event package for indicating user presence through SIP.

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






Rosenberg                Expires January 6, 2008               [Page 20]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


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


17.  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] 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] defines a new header field, Resource-Priority, that allows a
      session to get priority treatment from the network.


18.  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.  IANA Considerations

   None.


20.  Acknowledgements

   The author would like to thank Spencer Dawkins for his comments on
   this specification.


21.  Informative References

   [1]    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]    Bradner, S., "The Internet Standards Process -- Revision 3",



Rosenberg                Expires January 6, 2008               [Page 21]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


          BCP 9, RFC 2026, October 1996.

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

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

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

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

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

   [8]    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]    Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
          "SIP: Session Initiation Protocol", RFC 2543, March 1999.

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

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

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

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

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

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




Rosenberg                Expires January 6, 2008               [Page 22]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


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

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

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

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

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

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

   [22]   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]   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]   Vemuri, A. and J. Peterson, "Session Initiation Protocol for
          Telephones (SIP-T): Context and Architectures", BCP 63,
          RFC 3372, September 2002.

   [25]   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]   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]   Camarillo, G. and H. Schulzrinne, "Early Media and Ringing
          Tone Generation in the Session Initiation Protocol (SIP)",



Rosenberg                Expires January 6, 2008               [Page 23]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


          RFC 3960, December 2004.

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

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

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

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

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

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

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

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

   [36]   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]   Barnes, M., "An Extension to the Session Initiation Protocol
          (SIP) for Request History Information", RFC 4244,
          November 2005.

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

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

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



Rosenberg                Expires January 6, 2008               [Page 24]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


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

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

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

   [44]   Camarillo, G., "Referring to Multiple Resources in the Session
          Initiation Protocol (SIP)", draft-ietf-sip-multiple-refer-01
          (work in progress), January 2007.

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

   [46]   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]   Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
          Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.

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

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

   [50]   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]   Niemi, A., "Session Initiation Protocol (SIP) Extension for
          Event State Publication", RFC 3903, October 2004.

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

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

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



Rosenberg                Expires January 6, 2008               [Page 25]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


          August 2004.

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

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

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

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

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

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

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

   [62]   Petrie, D. and S. 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 Protocol (XCAP)",
          draft-ietf-sip-xcap-config-00 (work in progress),
          October 2006.

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

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




Rosenberg                Expires January 6, 2008               [Page 26]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


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

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

   [68]   Camarillo, G., "Subscriptions to Request-Contained Resource
          Lists in the Session Initiation  Protocol (SIP)",
          draft-ietf-sip-uri-list-subscribe-01 (work in progress),
          January 2007.

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

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

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

   [72]   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]   Ono, K. and S. Tachimoto, "End-to-middle Security in the
          Session Initiation Protocol (SIP)", draft-ietf-sip-e2m-sec-05
          (work in progress), March 2007.

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

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

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

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



Rosenberg                Expires January 6, 2008               [Page 27]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


          progress), July 2005.

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

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

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

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

   [82]   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]   Camarillo, G., "The Early Session Disposition Type for the
          Session Initiation Protocol (SIP)", RFC 3959, December 2004.

   [84]   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]   Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
          November 2002.

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

   [87]   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]   Rosenberg, J., "TCP Candidates with Interactive Connectivity
          Establishment (ICE", draft-ietf-mmusic-ice-tcp-03 (work in
          progress), March 2007.

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

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




Rosenberg                Expires January 6, 2008               [Page 28]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


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

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

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

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

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

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

   [97]   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]   Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media
          Services with SIP", RFC 4240, December 2005.

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

   [101]  Rosenberg, J., "A Framework for Consent-Based Communications
          in the Session Initiation  Protocol (SIP)",
          draft-ietf-sip-consent-framework-01 (work in progress),
          November 2006.

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




Rosenberg                Expires January 6, 2008               [Page 29]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


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

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

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

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

   [107]  Garcia-Martin, M., "A Session Description Protocol (SDP)
          Offer/Answer Mechanism to Enable File  Transfer",
          draft-ietf-mmusic-file-transfer-mech-03 (work in progress),
          June 2007.

   [108]  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, "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 2007.

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

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

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







Rosenberg                Expires January 6, 2008               [Page 30]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


Author's Address

   Jonathan Rosenberg
   Cisco
   Edison, NJ
   US

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










































Rosenberg                Expires January 6, 2008               [Page 31]

Internet-Draft          Hitchhiker's Guide to SIP              July 2007


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





Rosenberg                Expires January 6, 2008               [Page 32]


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