SIP J. Rosenberg Internet-Draft Cisco Intended status: Informational March 5, 2007 Expires: September 6, 2007 A Hitchhiker's Guide to the Session Initiation Protocol (SIP) draft-ietf-sip-hitchhikers-guide-02 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 September 6, 2007. 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 September 6, 2007 [Page 1] Internet-Draft Hitchhiker's Guide to SIP March 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 . . . . . . . . . . 8 6. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Minor Extensions . . . . . . . . . . . . . . . . . . . . . . . 12 8. Conferencing . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Call Control Primitives . . . . . . . . . . . . . . . . . . . 14 10. Event Framework and Packages . . . . . . . . . . . . . . . . . 14 11. Quality of Service . . . . . . . . . . . . . . . . . . . . . . 16 12. Operations and Management . . . . . . . . . . . . . . . . . . 17 13. SIP Compression . . . . . . . . . . . . . . . . . . . . . . . 17 14. SIP Service URIs . . . . . . . . . . . . . . . . . . . . . . . 17 15. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 18 16. Instant Messaging, Presence and Multimedia . . . . . . . . . . 20 17. Emergency Services . . . . . . . . . . . . . . . . . . . . . . 20 18. Security Considerations . . . . . . . . . . . . . . . . . . . 21 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 21. Informative References . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . . . 31 Rosenberg Expires September 6, 2007 [Page 2] Internet-Draft Hitchhiker's Guide to SIP March 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 September 6, 2007 [Page 3] Internet-Draft Hitchhiker's Guide to SIP March 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 September 6, 2007 [Page 4] Internet-Draft Hitchhiker's Guide to SIP March 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 September 6, 2007 [Page 5] Internet-Draft Hitchhiker's Guide to SIP March 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 September 6, 2007 [Page 6] Internet-Draft Hitchhiker's Guide to SIP March 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 XXXX, Connected Identity in the Session Initiation Protocol (SIP) (S): RFC XXXX [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, Addressing an Amplification Vulnerability in Forking Proxies (S): RFC XXXX [82] makes a small normative change to RFC 3261, requiring loop detection in any proxy that forks a request. It addresses a vulnerability uncovered in RFC 3261. 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. 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 Rosenberg Expires September 6, 2007 [Page 7] Internet-Draft Hitchhiker's Guide to SIP March 2007 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. 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. Rosenberg Expires September 6, 2007 [Page 8] Internet-Draft Hitchhiker's Guide to SIP March 2007 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. 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. Rosenberg Expires September 6, 2007 [Page 9] Internet-Draft Hitchhiker's Guide to SIP March 2007 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 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. Rosenberg Expires September 6, 2007 [Page 10] Internet-Draft Hitchhiker's Guide to SIP March 2007 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. 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. Rosenberg Expires September 6, 2007 [Page 11] Internet-Draft Hitchhiker's Guide to SIP March 2007 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. 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. Rosenberg Expires September 6, 2007 [Page 12] Internet-Draft Hitchhiker's Guide to SIP March 2007 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. 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. Rosenberg Expires September 6, 2007 [Page 13] Internet-Draft Hitchhiker's Guide to SIP March 2007 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. 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 Rosenberg Expires September 6, 2007 [Page 14] Internet-Draft Hitchhiker's Guide to SIP March 2007 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 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. 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. Rosenberg Expires September 6, 2007 [Page 15] Internet-Draft Hitchhiker's Guide to SIP March 2007 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 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. Rosenberg Expires September 6, 2007 [Page 16] Internet-Draft Hitchhiker's Guide to SIP March 2007 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. 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. Rosenberg Expires September 6, 2007 [Page 17] Internet-Draft Hitchhiker's Guide to SIP March 2007 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. 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. Rosenberg Expires September 6, 2007 [Page 18] Internet-Draft Hitchhiker's Guide to SIP March 2007 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]. 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. Rosenberg Expires September 6, 2007 [Page 19] Internet-Draft Hitchhiker's Guide to SIP March 2007 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. 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. Rosenberg Expires September 6, 2007 [Page 20] Internet-Draft Hitchhiker's Guide to SIP March 2007 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", 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 Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-13 (work in Rosenberg Expires September 6, 2007 [Page 21] Internet-Draft Hitchhiker's Guide to SIP March 2007 progress), January 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. [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. Rosenberg Expires September 6, 2007 [Page 22] Internet-Draft Hitchhiker's Guide to SIP March 2007 [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-11 (work in progress), October 2006. [21] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", draft-ietf-sip-outbound-07 (work in progress), January 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)", 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. Rosenberg Expires September 6, 2007 [Page 23] Internet-Draft Hitchhiker's Guide to SIP March 2007 [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. [41] Willis, D. and A. Allen, "Requesting Answering Modes for the Session Initiation Protocol (SIP)", draft-ietf-sip-answermode-01 (work in progress), May 2006. [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. Rosenberg Expires September 6, 2007 [Page 24] Internet-Draft Hitchhiker's Guide to SIP 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, 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) Rosenberg Expires September 6, 2007 [Page 25] Internet-Draft Hitchhiker's Guide to SIP March 2007 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-01 (work in progress), February 2006. [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-10 (work in progress), January 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. [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. Rosenberg Expires September 6, 2007 [Page 26] Internet-Draft Hitchhiker's Guide to SIP March 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-04 (work in progress), December 2006. [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 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. Rosenberg Expires September 6, 2007 [Page 27] Internet-Draft Hitchhiker's Guide to SIP March 2007 [81] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", draft-ietf-sip-connected-identity-05 (work in progress), February 2007. [82] Sparks, R., "Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies", draft-ietf-sip-fork-loop-fix-04 (work in progress), October 2006. [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-02 (work in progress), October 2006. [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. [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", Rosenberg Expires September 6, 2007 [Page 28] Internet-Draft Hitchhiker's Guide to SIP March 2007 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-02 (work in progress), October 2006. [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-01 (work in progress), October 2006. [103] Camarillo, G., "The Session Initiation Protocol (SIP) Pending Additions Event Package", draft-ietf-sipping-pending-additions-01 (work in progress), November 2006. [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-04 (work in Rosenberg Expires September 6, 2007 [Page 29] Internet-Draft Hitchhiker's Guide to SIP March 2007 progress), February 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-00 (work in progress), December 2006. [108] Rosenberg, J., "Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP)", draft-ietf-sip-ice-option-tag-00 (work in progress), January 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.18.0, October 2006. Author's Address Jonathan Rosenberg Cisco Edison, NJ US Email: jdrosen@cisco.com URI: http://www.jdrosen.net Rosenberg Expires September 6, 2007 [Page 30] Internet-Draft Hitchhiker's Guide to SIP March 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 September 6, 2007 [Page 31]