From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5411.txt | 2185 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2185 insertions(+) create mode 100644 doc/rfc/rfc5411.txt (limited to 'doc/rfc/rfc5411.txt') diff --git a/doc/rfc/rfc5411.txt b/doc/rfc/rfc5411.txt new file mode 100644 index 0000000..b021f8c --- /dev/null +++ b/doc/rfc/rfc5411.txt @@ -0,0 +1,2185 @@ + + + +Network Working Group J. Rosenberg +Request for Comments: 5411 Cisco +Category: Informational January 2009 + + + A Hitchhiker's Guide to the Session Initiation Protocol (SIP) + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +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 a current snapshot of the + specifications under the SIP umbrella, briefly summarizes each, and + groups them into categories. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Scope of This Document . . . . . . . . . . . . . . . . . . . . 4 + 3. Core SIP Specifications . . . . . . . . . . . . . . . . . . . 5 + 4. Public Switched Telephone Network (PSTN) Interworking . . . . 8 + 5. General Purpose Infrastructure Extensions . . . . . . . . . . 10 + 6. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 12 + 7. Call Control Primitives . . . . . . . . . . . . . . . . . . . 13 + 8. Event Framework . . . . . . . . . . . . . . . . . . . . . . . 14 + 9. Event Packages . . . . . . . . . . . . . . . . . . . . . . . . 15 + 10. Quality of Service . . . . . . . . . . . . . . . . . . . . . . 16 + 11. Operations and Management . . . . . . . . . . . . . . . . . . 17 + 12. SIP Compression . . . . . . . . . . . . . . . . . . . . . . . 17 + 13. SIP Service URIs . . . . . . . . . . . . . . . . . . . . . . . 17 + 14. Minor Extensions . . . . . . . . . . . . . . . . . . . . . . . 19 + 15. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 20 + 16. Conferencing . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 17. Instant Messaging, Presence, and Multimedia . . . . . . . . . 24 + 18. Emergency Services . . . . . . . . . . . . . . . . . . . . . . 25 + 19. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 + 21. Informative References . . . . . . . . . . . . . . . . . . . . 26 + + + + + +Rosenberg Informational [Page 1] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + +1. Introduction + + The Session Initiation Protocol (SIP) [RFC3261] is the subject of + numerous specifications that have been produced by the IETF. It can + be difficult to locate the right document, or even to determine the + set of Request for Comments (RFC) about SIP. "Don't Panic!" [HGTTG] + This specification serves as a guide to the SIP RFC series. It is a + current snapshot of the specifications under the SIP umbrella at the + time of publication. It is anticipated that this document itself + will be regularly updated as SIP specifications mature. Furthermore, + it references many specifications, which, at the time of publication + of this document, were not yet finalized, and may eventually be + completed or abandoned. Therefore, the enumeration of specifications + here is a work-in-progress and subject to change. + + 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 [RFC2026]. These values are: + + S: Standards Track (Proposed Standard, Draft Standard, or Standard) + + E: Experimental + + B: Best Current Practice + + I: Informational + + The specifications are grouped together by topic. The topics are: + + Core: The SIP specifications that are expected to be utilized for + each session or registration an endpoint participates in. + + Public Switched Telephone Network (PSTN) Interop: Specifications + related to interworking with the telephone network. + + General Purpose Infrastructure: General purpose extensions to SIP, + SDP (Session Description Protocol), and MIME, but ones that are + not expected to always be used. + + NAT Traversal: Specifications to deal with firewall and NAT + traversal. + + Call Control Primitives: Specifications for manipulating SIP dialogs + and calls. + + + + + + +Rosenberg Informational [Page 2] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + Event Framework: Definitions of the core specifications for the SIP + event framework, providing for pub/sub capability. + + Event Packages: Packages that utilize the SIP event framework. + + Quality of Service: Specifications related to multimedia quality of + service (QoS). + + Operations and Management: Specifications related to configuration + and monitoring of SIP deployments. + + SIP Compression: Specifications to facilitate usage of SIP with the + Signaling Compression (Sigcomp) framework. + + SIP Service URIs: Specifications on how to use SIP URIs to address + multimedia services. + + Minor Extensions: Specifications that solve a narrow problem space + or provide an optimization. + + Security Mechanisms: Specifications providing security functionality + for SIP. + + Conferencing: Specifications for multimedia conferencing. + + Instant Messaging, Presence, and Multimedia: SIP extensions related + to IM, presence, and multimedia. This covers only the SIP + extensions related to these topics. See [SIMPLE] for a full + treatment of SIP for IM and Presence (SIMPLE). + + Emergency Services: SIP extensions related to emergency services. + See [ECRIT-FRAME] for a more complete treatment of additional + functionality related to emergency services. + + Typically, SIP extensions fit naturally into topic areas, and + implementors interested in a particular topic often implement many or + all of the specifications in that area. There are some + specifications that fall into multiple topic areas, in which case + they are listed more than once. + + Do not print all the specs cited here at once, as they might share + the fate of the rules of Brockian Ultracricket when bound together: + collapse under their own gravity and form a black hole [HGTTG]. + + This document itself is not an update to RFC 3261 or an extension to + SIP. It is an informational document, meant to guide newcomers, + implementors, and deployers to the many specifications associated + with SIP. + + + +Rosenberg Informational [Page 3] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + +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 RFC 3261 and any specification that defines an extension to it, + where an extension is a mechanism that changes or updates in some + way a behavior specified there. + + o The basic SDP specification [RFC4566] and any specification that + defines an extension to SDP whose primary purpose is to support + SIP. + + o Any specification that defines a MIME object whose primary purpose + is to support SIP. + + Excluded from this list are requirements, architectures, registry + definitions, non-normative frameworks, and processes. Best Current + Practices are included when they normatively define mechanisms for + accomplishing a task, or provide significant description of the usage + of the normative specifications, such as call flows. + + The SIP change process [RFC3427] defines two types of extensions to + SIP: 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), which are meant to be used in + areas of limited applicability. P-headers cannot be defined in the + Standards Track. For the most part, P-headers are not included in + the listing here, with the exception of those that have seen general + usage despite their P-header status. + + This document includes specifications, which have already been + approved by the IETF and granted an RFC number, in addition to + Internet Drafts, which are still under development within the IETF + and will eventually finish and get an RFC number. Inclusion of + Internet Drafts here helps encourage early implementation and + demonstrations of interoperability of the protocol, and thus aids in + the standards-setting process. Inclusion of these also identifes + where the IETF is targetting a solution at a particular problem + space. Note that final IANA assignment of codepoints (such as option + tags and header field names) does not take place until shortly before + publication as an RFC, and thus codepoint assignments may change. + + + + + + +Rosenberg Informational [Page 4] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + +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 for which the extension is relevant. + In the galaxy of SIP, these specifications are like towels [HGTTG]. + + RFC 3261, The Session Initiation Protocol (S): [RFC3261] is the core + SIP protocol itself. RFC 3261 obsoletes [RFC2543]. It is the + president of the galaxy [HGTTG] as far as the suite of SIP + specifications is concerned. + + RFC 3263, Locating SIP Servers (S): [RFC3263] provides DNS + procedures for taking a SIP URI and determining a SIP server that + is associated with that SIP URI. RFC 3263 is essential for any + implementation using SIP with DNS. RFC 3263 makes use of both DNS + SRV records [RFC2782] and NAPTR records [RFC3401]. + + RFC 3264, An Offer/Answer Model with the Session Description Protocol + (S): [RFC3264] defines how the Session Description Protocol (SDP) + [RFC4566] is used with SIP to negotiate the parameters of a media + session. It is in widespread usage and an integral part of the + behavior of RFC 3261. + + RFC 3265, SIP-Specific Event Notification (S): [RFC3265] defines the + SUBSCRIBE and NOTIFY methods. These two methods provide a general + event notification framework for SIP. To actually use the + framework, extensions need to be defined for specific event + packages. An event package defines a schema for the event data + and describes other aspects of event processing specific to that + schema. An RFC 3265 implementation is required when any event + package is used. + + + +Rosenberg Informational [Page 5] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + RFC 3325, Private Extensions to SIP for Asserted Identity within + Trusted Networks (I): Though its P-header status implies that it has + limited applicability, [RFC3325], which defines the P-Asserted- + Identity header field, has been widely deployed. It is used as + the basic mechanism for providing network-asserted caller ID + services. Its intended update, [UPDATE-PAI], clarifies its usage + for connected party identification as well. + + RFC 3327, SIP Extension Header Field for Registering Non-Adjacent + Contacts (S): [RFC3327] defines the Path header field. This field + is inserted by proxies between a client and their registrar. It + allows inbound requests towards that client to traverse these + proxies prior to being delivered to the user agent. It is + essential in any SIP deployment that has edge proxies, which are + proxies between the client and the home proxy or SIP registrar. + + RFC 3581, An Extension to SIP for Symmetric Response Routing (S): + [RFC3581] defines the rport parameter of the Via header. It + allows SIP responses to traverse NAT. It is one of several + specifications that are utilized for NAT traversal (see + Section 6). + + RFC 3840, Indicating User Agent Capabilities in SIP (S): [RFC3840] + defines a mechanism for carrying capability information about a + user agent in REGISTER requests and in dialog-forming requests + like INVITE. It has found use with conferencing (the isfocus + parameter declares that a user agent is a conference server) and + with applications like push-to-talk. + + RFC 4320, Actions Addressing Issues Identified with the Non-INVITE + Transaction in SIP (S): [RFC4320] formally updates RFC 3261 and + modifies some of the behaviors associated with non-INVITE + transactions. This addresses some problems found in timeout and + failure cases. + + RFC 4474, Enhancements for Authenticated Identity Management in SIP + (S): [RFC4474] defines a mechanism for providing a cryptographically + verifiable identity of the calling party in a SIP request. Known + as "SIP Identity", this mechanism provides an alternative to RFC + 3325. It has seen little deployment so far, but its importance as + a key construct for anti-spam techniques and new security + mechanisms makes it a core part of the SIP specifications. + + GRUU, Obtaining and Using Globally Routable User Agent Identifiers + (GRUU) in SIP (S): [GRUU] defines a mechanism for directing requests + towards a specific UA instance. GRUU is essential for features + like transfer and provides another piece of the SIP NAT traversal + story. + + + +Rosenberg Informational [Page 6] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + OUTBOUND, Managing Client Initiated Connections through SIP (S): + [OUTBOUND], also known as SIP outbound, defines important changes + to the SIP registration mechanism that 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): [RFC4566] defines a + format for representing multimedia sessions. SDP objects are + carried in the body of SIP messages and, based on the offer/answer + model, are used to negotiate the media characteristics of a + session between users. + + SDP-CAP, SDP Capability Negotiation (S): [SDP-CAP] defines a set of + extensions to SDP that allows 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. + + ICE, Interactive Connectivity Establishment (ICE) (S): [ICE] defines + a technique for NAT traversal of media sessions for protocols that + make use of the offer/answer model. This specification is the + IETF-recommended mechanism for NAT traversal for SIP media + streams, and is meant to be used even by endpoints that are + themselves never behind a NAT. A SIP option tag and media feature + tag [OPTION-TAG] (also a core specification) have been defined for + use with ICE. + + RFC 3605, Real Time Control Protocol (RTCP) Attribute in the Session + Description Protocol (SDP) (S): [RFC3605] defines a way to + explicitly signal, within an SDP message, the IP address and port + for RTCP, rather than using the port+1 rule in the Real Time + Transport Protocol (RTP) [RFC3550]. It is needed for devices + behind NAT, and the specification is required by ICE. + + RFC 4916, Connected Identity in the Session Initiation Protocol (SIP) + (S): [RFC4916] formally updates RFC 3261. It defines an extension + to SIP that allows a calling user to determine the identity of the + final called user (connected party). Due to forwarding and + retargeting services, this may not be the same as the user that + the caller was originally trying to reach. The mechanism works in + tandem with the SIP identity specification [RFC4474] to provide + signatures over the connected party identity. It can also be used + if a party identity changes mid-call due to third-party call + control actions or PSTN behavior. + + + + + + +Rosenberg Informational [Page 7] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + RFC 3311, The SIP UPDATE Method (S): [RFC3311] defines the UPDATE + method for SIP. This method is meant as a means for updating + session information prior to the completion of the initial INVITE + transaction. It can also be used to update other information, + such as the identity of the participant [RFC4916], without + involving an updated offer/answer exchange. It was developed + initially to support [RFC3312], but has found other uses. In + particular, its usage with RFC 4916 means it will typically be + used as part of every session, to convey a secure, connected + identity. + + SIPS-URI, The Use of the SIPS URI Scheme in the Session Initiation + Protocol (SIP) (S): [SIPS-URI] is intended to update RFC 3261. It + revises the processing of the SIPS URI, originally defined in RFC + 3261, to fix many errors and problems that have been encountered + with that mechanism. + + RFC 3665, Session Initiation Protocol (SIP) Basic Call Flow Examples + (B): [RFC3665] contains best-practice call flow examples for basic + SIP interactions -- call establishment, termination, and + registration. + + 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 [LOOP-FIX], a + clarification on how record-routing works [RECORD-ROUTE], and a + correction to the IPv6 BNF [ABNF-FIX]. + +4. Public Switched Telephone Network (PSTN) Interworking + + Numerous extensions and usages of SIP are related to interoperability + and communications with or through the PSTN. + + RFC 2848, The PINT Service Protocol (S): [RFC2848] is one of the + earliest extensions to SIP. It defines procedures for using SIP + to invoke services that actually execute on the PSTN. Its main + application is for third-party call control, allowing an IP host + to set up a call between two PSTN endpoints. PINT (PSTN/Internet + Interworking) 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 (Services + in PSTN Requesting Internet Services) [RFC3910] defines the + inverse of PINT. It allows a switch in the PSTN to ask an IP + element 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 + + + +Rosenberg Informational [Page 8] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + [HGTTG]. + + RFC 3372, SIP for Telephones (SIP-T): Context and Architectures (I): + SIP-T [RFC3372] defines a mechanism for using SIP between pairs of + PSTN gateways. Its essential idea is to tunnel ISDN User Part + (ISUP) signaling between the gateways in the body of SIP messages. + SIP-T motivated the development of INFO [RFC2976]. SIP-T has seen + widespread implementation for the limited deployment model that it + addresses. As ISUP endpoints disappear from the network, the need + for this mechanism will decrease. + + RFC 3398, ISUP to SIP Mapping (S): [RFC3398] defines how to do + protocol mapping from the SS7 ISDN User Part (ISUP) signaling to + SIP. It is widely used in SS7 to SIP gateways and is part of the + SIP-T framework. + + RFC 4497, Interworking between the Session Initiation Protocol (SIP) + and QSIG (B): [RFC4497] defines how to do protocol mapping from + Q.SIG, used for Private Branch Exchange (PBX) signaling, to SIP. + + RFC 3578, Mapping of ISUP Overlap Signaling to SIP (S): [RFC3578] + defines a mechanism to map overlap dialing into SIP. This + specification is widely regarded as the ugliest SIP specification, + as the introduction to the specification itself advises that it + has many problems. Overlap signaling (the practice of sending + digits into the network as dialed instead of waiting for complete + collection of the called party number) is largely incompatible + with SIP at some fairly fundamental levels. That said, RFC 3578 + is mostly harmless and has seen some usage. + + RFC 3960, Early Media and Ringtone Generation in SIP (I): [RFC3960] + defines some guidelines for handling early media -- the practice + of sending media from the called party or an application server + towards the caller prior to acceptance of the call. Early media + is often generated from the PSTN. Early media is a complex topic, + and this specification does not fully address the problems + associated with it. + + RFC 3959, Early Session Disposition Type for the Session Initiation + Protocol (SIP) (S): [RFC3959] defines a new session disposition type + for use with early media. It indicates that the SDP in the body + is for a special early media session. This has seen little usage. + + RFC 3204, MIME Media Types for ISUP and QSIG Objects (S): [RFC3204] + defines MIME objects for representing SS7 and QSIG signaling + messages. SS7 signaling messages are carried in the body of SIP + messages when SIP-T is used. QSIG signaling messages can be + carried in a similar way. + + + +Rosenberg Informational [Page 9] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + RFC3666, Session Initiation Protocol (SIP) Public Switched Telephone + Network (PSTN) Call Flows (B): [RFC3666] provides best practice call + flows around interworking with the PSTN. + +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 + used for every session or registration, as the core specifications + are. + + 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. + [RFC3262] was developed to allow reliability of provisional + responses. The specification defines the PRACK method, used for + indicating that a provisional response was received. Though it + provides a generic capability for SIP, RFC 3262 implementations + have been most common in PSTN interworking devices. However, + PRACK brings a great deal of complication for relatively small + benefit. As such, it has seen only moderate levels of deployment. + + RFC 3323, A Privacy Mechanism for the Session Initiation Protocol + (SIP) (S): [RFC3323] defines the Privacy header field, used by + clients to request anonymity for their requests. Though it + defines several privacy services, the only one broadly used is the + one that supports privacy of the P-Asserted-Identity header field + [RFC3325]. + + UA-PRIVACY, UA-Driven Privacy Mechanism for SIP (S): [UA-PRIVACY] + defines a mechanism for achieving anonymous calls in SIP. It is + an alternative to [RFC3323], and instead places more intelligence + in the endpoint to craft anonymous messages by directly accessing + network services. + + RFC 2976, The INFO Method (S): [RFC2976] 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 + [RFC3372]. It has been used to support numerous proprietary and + non-interoperable extensions due to its poorly defined scope. + + + +Rosenberg Informational [Page 10] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + RFC 3326, The Reason Header Field for SIP (S): [RFC3326] defines the + Reason header field. It is used in requests, such as BYE, to + indicate the reason that the request is being sent. + + RFC 3388, Grouping of Media Lines in the Session Description Protocol + (S): RFC 3388 [RFC3388] defines a framework for grouping together + media streams in an SDP message. Such a grouping allows + relationships between these streams, such as which stream is the + audio for a particular video feed, to be expressed. + + RFC 3420, Internet Media Type message/sipfrag (S): [RFC3420] defines + a MIME object that contains a SIP message fragment. Only certain + header fields and parts of the SIP message are present. For + example, it is used to report back on the responses received to a + request sent as a consequence of a REFER. + + RFC 3608, SIP Extension Header Field for Service Route Discovery + During Registration (S): [RFC3608] allows a client to determine, + from a REGISTER response, a path of proxies to use in requests it + sends outside of a dialog. It can also be used by proxies to + verify the Route header in client-initiated requests. In many + respects, it is the inverse of the Path header field, but has seen + less usage since default outbound proxies have been sufficient in + many deployments. + + RFC 3841, Caller Preferences for SIP (S): [RFC3841] defines a set of + headers that a client can include in a request to control the way + in which the request is routed downstream. It allows a client to + direct a request towards a UA with specific capabilities, which a + UA indicates using [RFC3840]. + + RFC 4028, Session Timers in SIP (S): [RFC4028] defines a keepalive + mechanism for SIP signaling. It is primarily meant to provide a + way to clean up old state in proxies that are holding call state + for calls from failed endpoints that were never terminated + normally. Despite its name, the session timer is not a mechanism + for detecting a network failure mid-call. Session timers + introduce a fair bit of complexity for relatively little gain, and + have seen moderate deployment. + + RFC 4168, SCTP as a Transport for SIP (S): [RFC4168] defines how to + carry SIP messages over the Stream Control Transmission Protocol + (SCTP) [RFC4960]. SCTP has seen very limited usage for SIP + transport. + + + + + + + +Rosenberg Informational [Page 11] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + RFC 4244, An Extension to SIP for Request History Information (S): + [RFC4244] defines the History-Info header field, which indicates + information on how and why a call came to be routed to a + particular destination. + + RFC 4145, TCP-Based Media Transport in the Session Description + Protocol (SDP) (S): [RFC4145] defines an extension to SDP for + setting up TCP-based sessions between user agents. It defines who + sets up the connection and how its lifecycle is managed. It has + seen relatively little usage due to the small number of media + types to date that use TCP. + + RFC 4091, The Alternative Network Address Types (ANAT) Semantics for + the Session Description Protocol (SDP) Grouping Framework (S): + [RFC4091] defines a mechanism for including both IPv4 and IPv6 + addresses for a media session as alternates. This mechanism has + been deprecated in favor of ICE [ICE]. + + SDP-MEDIA, SDP Media Capabilities Negotiation (S): [SDP-MEDIA] + defines an extension to the SDP capability negotiation framework + [SDP-CAP] for negotiating codecs, codec parameters, and media + streams. + + BODY-HANDLING, Message Body Handling in the Session Initiation + Protocol (SIP): [BODY-HANDLING] clarifies handling of bodies in SIP, + focusing primarily on multi-part behavior, which was under- + specified in SIP. + +6. NAT Traversal + + These SIP extensions are primarily aimed at addressing NAT traversal + for SIP. + + ICE, Interactive Connectivity Establishment (ICE) (S): [ICE] defines + a technique for NAT traversal of media sessions for protocols that + make use of the offer/answer model. This specification is the + IETF-recommended mechanism for NAT traversal for SIP media + streams, and is meant to be used even by endpoints that are + themselves never behind a NAT. A SIP option tag and media feature + tag [OPTION-TAG] have been defined for use with ICE. + + ICE-TCP, TCP Candidates with Interactive Connectivity Establishment + (ICE) (S): [ICE-TCP] specifies the usage of ICE for TCP streams. + This allows for selection of RTP-based voice on top of TCP only + when NAT or firewalls would prevent UDP-based voice from working. + + + + + + +Rosenberg Informational [Page 12] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + RFC 3605, Real Time Control Protocol (RTCP) Attribute in the Session + Description Protocol (SDP) (S): [RFC3605] defines a way to + explicitly signal, within an SDP message, the IP address and port + for RTCP, rather than using the port+1 rule in the Real Time + Transport Protocol (RTP) [RFC3550]. It is needed for devices + behind NAT, and the specification is required by ICE. + + OUTBOUND, Managing Client Initiated Connections through SIP (S): + [OUTBOUND], also known as SIP outbound, defines important changes + to the SIP registration mechanism that enable delivery of SIP + messages towards a UA when it is behind a NAT. + + RFC 3581, An Extension to SIP for Symmetric Response Routing (S): + [RFC3581] defines the rport parameter of the Via header. It + allows SIP responses to traverse NAT. + + GRUU, Obtaining and Using Globally Routable User Agent Identifiers + (GRUU) in SIP (S): [GRUU] defines a mechanism for directing requests + towards a specific UA instance. GRUU is essential for features + like transfer and provides another piece of the SIP NAT traversal + story. + +7. Call Control Primitives + + Numerous SIP extensions provide a toolkit of dialog- and call- + management techniques. These techniques have been combined together + to build many SIP-based services. + + RFC 3515, The REFER Method (S): REFER [RFC3515] defines a mechanism + for asking a user agent to send a SIP request. It's a form of SIP + remote control, and is the primary tool used for call transfer in + SIP. Beware that not all potential uses of REFER (neither for all + methods nor for all URI schemes) are well defined. Implementors + should only use the well-defined ones, and should not second guess + or freely assume behavior for the others to avoid unexpected + behavior of remote UAs, interoperability issues, and other bad + surprises. + + RFC 3725, Best Current Practices for Third Party Call Control (3pcc) + (B): [RFC3725] 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): [RFC3911] defines the Join + header field. When sent in an INVITE, it causes the recipient to + join the resulting dialog into a conference with another dialog in + progress. + + + + +Rosenberg Informational [Page 13] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + RFC 3891, The SIP Replaces Header (S): [RFC3891] 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): [RFC3892] 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): [RFC4117] defines how to use 3pcc for the purposes + of invoking transcoding services for a call. + +8. Event Framework + + RFC 3265, SIP-Specific Event Notification (S): [RFC3265] defines the + SUBSCRIBE and NOTIFY methods. These two methods provide a general + event notification framework for SIP. To actually use the + framework, extensions need to be defined for specific event + packages. An event package defines a schema for the event data + and describes other aspects of event processing specific to that + schema. An RFC 3265 implementation is required when any event + package is used. + + RFC 3903, SIP Extension for Event State Publication (S): [RFC3903] + 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): [RFC4662] 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. + + SUBNOT-ETAGS, An Extension to Session Initiation Protocol (SIP) + Events for Conditional Event Notification (S): [SUBNOT-ETAGS] + 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. + + + + + + +Rosenberg Informational [Page 14] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + +9. Event Packages + + These are event packages defined to utilize the SIP events framework. + Many of these are also listed elsewhere in their respective areas. + + RFC 3680, A SIP Event Package for Registrations (S): [RFC3680] + defines an event package for finding out about changes in + registration state. + + GRUU-REG (S): [GRUU-REG] is an extension to the registration event + package [RFC3680] that allows user agents to learn about their + GRUUs. It is particularly useful in helping to synchronize a + client and its registrar with their currently valid temporary + GRUU. + + RFC 3842, A Message Summary and Message Waiting Indication Event + Package for SIP (S): [RFC3842] defines a way for a user agent to + find out about voicemails and other messages that are waiting for + it. Its primary purpose is to enable the voicemail waiting lamp + on most business telephones. + + RFC 3856, A Presence Event Package for SIP (S): [RFC3856] defines an + event package for indicating user presence through SIP. + + RFC 3857, A Watcher Information Event Template Package for SIP (S): + [RFC3857], also known as winfo, provides a mechanism for a user + agent to find out what subscriptions are in place for a particular + event package. Its primary usage is with presence, but it can be + used with any event package. + + RFC 4235, An INVITE-Initiated Dialog Event Package for SIP (S): + [RFC4235] defines an event package for learning the state of the + dialogs in progress at a user agent, and is one of several RFCs + starting with the important number 42 [HGTTG]. + + RFC 4575, A SIP Event Package for Conference State (S): [RFC4575] + defines a mechanism for learning about changes in conference + state, including conference membership. + + RFC 4730, A SIP Event Package for Key Press Stimulus (KPML) (S): + [RFC4730] defines a way for an application in the network to + subscribe to the set of key presses made on the keypad of a + traditional telephone. It, along with RFC 4733 [RFC4733], are the + two mechanisms defined for handling DTMF. RFC 4730 is a + signaling-path solution, and RFC 4733 is a media-path solution. + + + + + + +Rosenberg Informational [Page 15] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + RTCP-SUM, SIP Event Package for Voice Quality Reporting (S): + [RTCP-SUM] defines a SIP event package that enables the collection + and reporting of metrics that measure the quality for Voice over + Internet Protocol (VoIP) sessions. + + SESSION-POLICY, A Framework for Session Initiation Protocol (SIP) + Session Policies (S): [SESSION-POLICY] defines a framework for + session policies. In this framework, policy servers are used to + tell user agents about the media characteristics required for a + particular session. The session policy framework has not been + widely implemented. + + POLICY-PACK, A Session Initiation Protocol (SIP) Event Package for + Session-Specific Session Policies (S): [POLICY-PACK] defines a SIP + event package used in conjunction with the session policy + framework [SESSION-POLICY]. + + RFC 5362, The Session Initiation Protocol (SIP) Pending Additions + Event Package (S): [RFC5362] defines a SIP event package that allows + a UA to learn whether consent has been given for the addition of + an address to a SIP "mailing list". It is used in conjunction + with the SIP framework for consent [RFC5360]. + +10. Quality of Service + + Several specifications concern themselves with the interactions of + SIP with network Quality of Service (QoS) mechanisms. + + RFC 3312, Integration of Resource Management and SIP (S): [RFC3312], + updated by [RFC4032], defines a way to make sure that the phone of + the called party doesn't ring until a QoS reservation has been + installed in the network. It does so by defining a general + preconditions framework, which defines conditions that must be + true in order for a SIP session to proceed. + + QoS-ID, Quality of Service (QoS) Mechanism Selection in the Session + Description Protocol (SDP) (S): [QoS-ID] defines a way for user + agents to negotiate what type of end-to-end QoS mechanism to use + for a session. At this time, there are two that can be used: the + Resource Reservation Protocol (RSVP) and Next Steps in Signaling + (NSIS). This negotiation is done through an SDP extension. Due + to limited deployment of RSVP and even more limited deployment of + NSIS, this extension has not been widely used. + + RFC 3313, Private SIP Extensions for Media Authorization (I): + [RFC3313] defines a P-header that provides a mechanism for passing + an authorization token between SIP and a network QoS reservation + protocol like RSVP. Its purpose is to make sure network QoS is + + + +Rosenberg Informational [Page 16] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + only granted if a client has made a SIP call through the same + provider's network. This specification is sometimes referred to + as the SIP walled-garden specification by the truly paranoid + androids in the SIP community. This is because it requires + coupling of signaling and the underlying IP network. + + RFC 3524, Mapping of Media Streams to Resource Reservation Flows + (S): [RFC3524] defines a usage of the SDP grouping framework for + indicating that a set of media streams should be handled by a + single resource reservation. + +11. Operations and Management + + Several specifications have been defined to support operations and + management of SIP systems. These include mechanisms for + configuration and network diagnostics. + + CONFIG-FRAME, A Framework for SIP User Agent Profile Delivery (S): + [CONFIG-FRAME] defines a mechanism that allows a SIP user agent to + bootstrap its configuration from the network and receive updates + to its configuration, should it change. This is considered an + essential piece of deploying a usable SIP network. + + RTCP-SUM, SIP Event Package for Voice Quality Reporting (S): + [RTCP-SUM] defines a SIP event package that enables the collection + and reporting of metrics that measure the quality for Voice over + Internet Protocol (VoIP) sessions. + +12. SIP Compression + + Sigcomp [RFC3320] [RFC4896] was defined to allow compression of SIP + messages over low bandwidth links. Sigcomp is not formally part of + SIP. However, usage of Sigcomp with SIP has required extensions to + SIP. + + RFC 3486, Compressing SIP (S): [RFC3486] defines a SIP URI parameter + that can be used to indicate that a SIP server supports Sigcomp. + + RFC 5049, Applying Signaling Compression (SigComp) to the Session + Initiation Protocol (SIP) (S): [RFC5049] defines how to apply + Sigcomp to SIP. + +13. SIP Service URIs + + Several extensions define well-known services that can be invoked by + constructing requests with specific structures for the Request URI, + resulting in specific behaviors at the User Agent Server (UAS). + + + + +Rosenberg Informational [Page 17] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + RFC 3087, Control of Service Context using Request URI (I): + [RFC3087] introduced the context of using Request URIs, encoded + appropriately, to invoke services. + + RFC 4662, A SIP Event Notification Extension for Resource Lists (S): + [RFC4662] defines a resource called a Resource List Server (RLS). + A client can send a subscribe to this server. The server will + generate a series of subscriptions, compile the resulting + information, and send it back to the subscriber. The set of + resources that the RLS will subscribe to is a property of the + request URI in the SUBSCRIBE request. + + RFC 5363, Framework and Security Considerations for Session + Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List + Services (S): [RFC5363] defines the framework for list services in + SIP. In this framework, a UA can include an XML list object in + the body of various requests and the server will provide list- + oriented services as a consequence. For example, a SUBSCRIBE with + a list subscribes to the URI in the list. + + RFC 5367, Subscriptions To Request-Contained Resource Lists in SIP + (S): [RFC5367] uses the URI-list framework [RFC5363] and allows a + client to subscribe to a resource called a Resource List Server. + This server will generate subscriptions to the URI in the list, + compile the resulting information, and send it back to the + subscriber. + + RFC 5365, Multiple-Recipient MESSAGE Requests in SIP (S): [RFC5365] + uses the URI-list framework [RFC5363] and allows a client to send + a MESSAGE to a number of recipients. + + RFC 5366, Conference Establishment Using Request-Contained Lists in + SIP (S): [RFC5366] uses the URI-list framework [RFC5363]. It allows + a client to ask the server to act as a conference focus and send + an invitation to each recipient in the list. + + RFC 4240, Basic Network Media Services with SIP (I): [RFC4240] + defines a way for SIP application servers to invoke announcement + and conferencing services from a media server. This is + accomplished through a set of defined URI parameters that tell the + media server what to do, such as what file to play and what + language to render it in. + + RFC 4458, Session Initiation Protocol (SIP) URIs for Applications + such as Voicemail and Interactive Voice Response (IVR) (I): + [RFC4458] defines a way to invoke voicemail and IVR services by + using a SIP URI constructed in a particular way. + + + + +Rosenberg Informational [Page 18] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + +14. Minor Extensions + + These SIP extensions don't fit easily into a single specific use + case. They have somewhat general applicability, but they solve a + relatively small problem or provide an optimization. + + RFC 4488, Suppression of the SIP REFER Implicit Subscription (S): + [RFC4488] defines an enhancement to REFER. REFER normally creates + an implicit subscription to the target of the REFER. This + subscription is used to pass back updates on the progress of the + referral. This extension allows that implicit subscription to be + bypassed as an optimization. + + RFC 4538, Request Authorization through Dialog Identification in SIP + (S): [RFC4538] provides a mechanism that allows a UAS to authorize a + request because the requestor proves it knows a dialog that is in + progress with the UAS. The specification is useful in conjunction + with the SIP application interaction framework [INTERACT-FRAME]. + + RFC 4508, Conveying Feature Tags with the REFER Method in SIP (S): + [RFC4508] defines a mechanism for carrying RFC 3840 feature tags + in REFER. It is useful for informing the target of the REFER + about the characteristics of the intended target of the referred + request. + + RFC 5373, Requesting Answer Modes for SIP (S): [RFC5373] defines an + extension for indicating to the called party whether or not the + phone should ring and/or be answered immediately. This is useful + for push-to-talk and for diagnostic applications. + + RFC 5079, Rejecting Anonymous Requests in SIP (S): [RFC5079] defines + a mechanism for a called party to indicate to the calling party + that a call was rejected since the caller was anonymous. This is + needed for implementation of the Anonymous Call Rejection (ACR) + feature in SIP. + + RFC 5368, Referring to Multiple Resources in SIP (S): [RFC5368] + allows a UA sending a REFER to ask the recipient of the REFER to + generate multiple SIP requests, not just one. This is useful for + conferencing, where a client would like to ask a conference server + to eject multiple users. + + RFC 4483, A Mechanism for Content Indirection in Session Initiation + Protocol (SIP) Messages (S): [RFC4483] defines a mechanism for + content indirection. Instead of carrying an object within a SIP + body, a URL reference is carried instead, and the recipient + dereferences the URL to obtain the object. The specification has + potential applicability for sending large instant messages, but + + + +Rosenberg Informational [Page 19] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + has yet to find much actual use. + + RFC 3890, A Transport Independent Bandwidth Modifier for the Session + Description Protocol (SDP) (S): [RFC3890] specifies an SDP extension + that allows for the description of the bandwidth for a media + session that is independent of the underlying transport mechanism. + + RFC 4583, Session Description Protocol (SDP) Format for Binary Floor + Control Protocol (BFCP) Streams (S): [RFC4583] defines a mechanism + in SDP to signal floor control streams that use BFCP. It is used + for push-to-talk and conference floor control. + + CONNECT-PRECON, Connectivity Preconditions for Session Description + Protocol Media Streams (S): [CONNECT-PRECON] defines a usage of the + precondition framework [RFC3312]. The connectivity precondition + makes sure that the session doesn't get established until actual + packet connectivity is checked. + + RFC 4796, The SDP (Session Description Protocol) Content Attribute + (S): [RFC4796] defines an SDP attribute for describing the purpose + of a media stream. Examples include a slide view, the speaker, a + sign language feed, and so on. + + IPv6-TRANS, IPv6 Transition in the Session Initiation Protocol (SIP) + (S): [IPv6-TRANS] defines practices for interworking between IPv6 + and IPv6 user agents. This is done through multi-homed proxies + that interwork IPv4 and IPv6, along with ICE [ICE] for media + traversal. The specification includes some minor extensions and + clarifications to SDP in order to cover some additional cases. + + CONNECT-REUSE, Connection Reuse in the Session Initiation Protocol + (SIP) (S): [CONNECT-REUSE] defines an extension to SIP that allows a + Transport Layer Security (TLS) connection between servers to be + reused for requests in both directions. Normally, two connections + are set up between a pair of servers, one for requests in each + direction. + +15. Security Mechanisms + + Several extensions provide additional security features to SIP. + + RFC 4474, Enhancements for Authenticated Identity Management in SIP + (S): [RFC4474] defines a mechanism for providing a cryptographically + verifiable identity of the calling party in a SIP request. Known + as "SIP Identity", this mechanism provides an alternative to RFC + 3325. It has seen little deployment so far, but its importance as + a key construct for anti-spam techniques and new security + mechanisms makes it a core part of the SIP specifications. + + + +Rosenberg Informational [Page 20] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + RFC 4916, Connected Identity in the Session Initiation Protocol (SIP) + (S): [RFC4916] formally updates RFC 3261. It defines an extension + to SIP that allows a calling user to determine the identity of the + final called user (connected party). Due to forwarding and + retargeting services, this may not be the same as the user that + the caller was originally trying to reach. The mechanism works in + tandem with the SIP identity specification [RFC4474] to provide + signatures over the connected party identity. It can also be used + if a party identity changes mid call due to third party call + control actions or PSTN behavior. + + SIPS-URI, The Use of the SIPS URI Scheme in the Session Initiation + Protocol (SIP) (S): [SIPS-URI] is intended to update RFC 3261. It + revises the processing of the SIPS URI, originally defined in RFC + 3261, to fix many errors and problems that have been encountered + with that mechanism. + + DOMAIN-CERTS, Domain Certificates in the Session Initiation Protocol + (SIP) (B): [DOMAIN-CERTS] clarifies the usage of SIP over TLS with + regards to certificate handling, and defines additional procedures + needed for interoperability. + + RFC 3323, A Privacy Mechanism for the Session Initiation Protocol + (SIP) (S): [RFC3323] defines the Privacy header field, used by + clients to request anonymity for their requests. Though it + defines several privacy services, the only one broadly used is the + one that supports privacy of the P-Asserted-Identity header field + [RFC3325]. + + RFC 4567, Key Management Extensions for Session Description Protocol + (SDP) and Real Time Streaming Protocol (RTSP) (S): [RFC4567] defines + extensions to SDP that allow tunneling of a key management + protocol, namely MIKEY [RFC3830], through offer/answer exchanges. + This mechanism is one of three Secure Realtime Transport Protocol + (SRTP) keying techniques specified for SIP, with Datagram + Transport Layer Security (DTLS)-SRTP [SRTP-FRAME] having been + selected as the final solution. + + RFC 4568, Session Description Protocol (SDP) Security Descriptions + for Media Streams (S): [RFC4568] defines extensions to SDP that + allow for the negotiation of keying material directly through + offer/answer, without a separate key management protocol. This + mechanism, sometimes called sdescriptions, has the drawback that + the media keys are available to any entity that has visibility to + the SDP. It is one of three SRTP keying techniques specified for + SIP, with DTLS-SRTP [SRTP-FRAME] having been selected as the final + solution. + + + + +Rosenberg Informational [Page 21] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + SRTP-FRAME, Framework for Establishing an SRTP Security Context using + DTLS (S): [SRTP-FRAME] defines the overall framework and SDP and SIP + processing required to perform key management for RTP using + Datagram TLS (DTLS) [RFC4347] directly between endpoints, over the + media path. It is one of three SRTP keying techniques specified + for SIP, with DTLS-SRTP [SRTP-FRAME] having been selected as the + final solution. + + RFC 3853, S/MIME Advanced Encryption Standard (AES) Requirement for + SIP (S): [RFC3853] formally updates RFC 3261. It is a brief + specification that updates the cryptography mechanisms used in SIP + S/MIME. However, SIP S/MIME has seen very little deployment. + + CERTS, Certificate Management Service for the Session Initiation + Protocol (SIP) (S): [CERTS] defines a certificate service for SIP + whose purpose is to facilitate the deployment of S/MIME. The + certificate service allows clients to store and retrieve their own + certificates, in addition to obtaining the certificates for other + users. + + RFC 3893, Session Initiation Protocol (SIP) Authenticated Identity + Body (AIB) Format (S): [RFC3893] defines a SIP message fragment that + can be signed in order to provide an authenticated identity over a + request. It was an early predecessor to [RFC4474], and + consequently AIB has seen no deployment. + + SAML, SIP SAML Profile and Binding (S): [SAML] defines the usage of + the Security Assertion Markup Language (SAML) within SIP, and + describes how to use it in conjunction with SIP identity [RFC4474] + to provide authenticated assertions about a user's role or + attributes. + + RFC 5360, A Framework for Consent-Based Communications in the Session + Initiation Protocol (SIP) (S): [RFC5360] defines several extensions + to SIP, including the Trigger-Consent and Permission-Missing + header fields. These header fields, in addition to the other + procedures defined in the document, define a way to manage + membership on "SIP mailing lists" used for instant messaging or + conferencing. In particular, it helps avoid the problem of using + such amplification services for the purposes of an attack on the + network by making sure a user authorizes the addition of their + address onto such a service. + + RFC 5361, A Document Format for Requesting Consent (S): [RFC5361] + defines an XML object used by the consent framework. Consent + documents are sent from SIP "mailing list servers" to users to + allow them to manage their membership on lists. + + + + +Rosenberg Informational [Page 22] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + RFC 5362, The Session Initiation Protocol (SIP) Pending Additions + Event Package (S): [RFC5362] defines a SIP event package that allows + a UA to learn whether consent has been given for the addition of + an address to a SIP "mailing list". It is used in conjunction + with the SIP framework for consent [RFC5360]. + + RFC 3329, Security Mechanism Agreement for SIP (S): [RFC3329] + defines a mechanism to prevent bid-down attacks in conjunction + with SIP authentication. The mechanism has seen very limited + deployment. It was defined as part of the 3GPP IP Multimedia + Subsystem (IMS) specification suite [3GPP.24.229], and is needed + only when there is a multiplicity of security mechanisms deployed + at a particular server. In practice, this has not been the case. + + RFC 4572, Connection-Oriented Media Transport over the Transport + Layer Security (TLS) Protocol in the Session Description Protocol + (SDP) (S): [RFC4572] specifies a mechanism for signaling TLS-based + media streams between endpoints. It expands the TCP-based media + signaling parameters defined in [RFC4145] to include fingerprint + information for TLS streams so that TLS can operate between end + hosts using self-signed certificates. + + RFC 5027, Security Preconditions for Session Description Protocol + Media Streams (S): [RFC5027] defines a precondition for use with the + preconditions framework [RFC3312]. The security precondition + prevents a session from being established until a security media + stream is set up. + + RFC 3310, Hypertext Transfer Protocol (HTTP) Digest Authentication + Using Authentication and Key Agreement (S): [RFC3310] defines an + extension to digest authentication to allow it to work with the + credentials stored in cell phones. Though technically it is an + extension to HTTP digest, its primary application is SIP. This + extension is useful primarily to implementors of IMS. + + RFC 4169, Hypertext Transfer Protocol (HTTP) Digest Authentication + Using Authentication and Key Agreement (AKA) Version-2 (S): + [RFC4169] is an enhancement to [RFC3310] that further improves + security of the authentication. + +16. Conferencing + + Numerous SIP and SDP extensions are aimed at conferencing as their + primary application. + + + + + + + +Rosenberg Informational [Page 23] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + RFC 4574, The SDP (Session Description Protocol) Label Attribute + (S): [RFC4574] defines an SDP attribute for providing an opaque + label for media streams. These labels can be referred to by + external documents, and in particular, by conference policy + documents. This allows a UA to tie together documents it may + obtain through conferencing mechanisms to media streams to which + they refer. + + RFC 3911, The SIP Join Header Field (S): [RFC3911] defines the Join + header field. When sent in an INVITE, it causes the recipient to + join the resulting dialog into a conference with another dialog in + progress. + + RFC 4575, A SIP Event Package for Conference State (S): [RFC4575] + defines a mechanism for learning about changes in conference + state, including conference membership. + + RFC 5368, Referring to Multiple Resources in SIP (S): [RFC5368] + allows a UA sending a REFER to ask the recipient of the REFER to + generate multiple SIP requests, not just one. This is useful for + conferencing, where a client would like to ask a conference server + to eject multiple users. + + RFC 5366, Conference Establishment Using Request-Contained Lists in + SIP (S): [RFC5366] is similar to [RFC5367]. However, instead of + subscribing to the resource, an INVITE request is sent to the + resource, and it will act as a conference focus and generate an + invitation to each recipient in the list. + + RFC4579, Session Initiation Protocol (SIP) Call Control - + Conferencing for User Agents (B): [RFC4579] defines best practice + procedures and call flows for conferencing. This includes + conference creation, joining, and dial out, amongst other + capabilities. + + RFC 4583, Session Description Protocol (SDP) Format for Binary Floor + Control Protocol (BFCP) Streams (S): [RFC4583] defines a mechanism + in SDP to signal floor control streams that use BFCP. It is used + for push-to-talk and conference floor control. + +17. Instant Messaging, Presence, and Multimedia + + SIP provides extensions for instant messaging, presence, and + multimedia. + + + + + + + +Rosenberg Informational [Page 24] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + RFC 3428, SIP Extension for Instant Messaging (S): [RFC3428] defines + the MESSAGE method, used for sending an instant message without + setting up a session (sometimes called "page mode"). + + RFC 3856, A Presence Event Package for SIP (S): [RFC3856] defines an + event package for indicating user presence through SIP. + + RFC 3857, A Watcher Information Event Template Package for SIP (S): + [RFC3857], also known as winfo, provides a mechanism for a user + agent to find out what subscriptions are in place for a particular + event package. Its primary usage is with presence, but it can be + used with any event package. + + TRANSFER-MECH, A Session Description Protocol (SDP) Offer/Answer + Mechanism to Enable File Transfer (S): [TRANSFER-MECH] defines a + mechanism for signaling a file transfer session with SIP. + +18. Emergency Services + + Emergency services include preemption features, which allow + authorized individuals to gain access to network resources in time of + emergency, along with traditional emergency calling. + + RFC 4411, Extending the SIP Reason Header for Preemption Events (S): + [RFC4411] defines an extension to the Reason header, allowing a UA + to know that its dialog was torn down because a higher priority + session came through. + + RFC 4412, Communications Resource Priority for SIP (S): [RFC4412] + defines a new header field, Resource-Priority, that allows a + session to get priority treatment from the network. + + LOCATION, Location Conveyance for the Session Initiation Protocol + (S): [LOCATION] defines a mechanism for carrying location objects in + SIP messages. This is used to convey location from a UA to an + emergency call taker. + +19. Security Considerations + + This specification is an overview of existing specifications and does + not introduce any security considerations on its own. Of course, the + world would be far more secure if everyone would follow one simple + rule: "Don't Panic!" [HGTTG]. + +20. Acknowledgements + + The author would like to thank Spencer Dawkins, Brian Stucker, Keith + Drage, John Elwell, and Avshalom Houri for their comments on this + + + +Rosenberg Informational [Page 25] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + document. + +21. Informative References + + [3GPP.24.229] 3GPP, "Internet Protocol (IP) multimedia call + control protocol based on Session Initiation + Protocol (SIP) and Session Description Protocol + (SDP); Stage 3", 3GPP TS 24.229 5.22.0, + September 2008. + + [ABNF-FIX] Gurbani, V. and B. Carpenter, "Essential correction + for IPv6 ABNF in RFC3261", Work in Progress, + November 2007. + + [BODY-HANDLING] Camarillo, G., "Message Body Handling in the + Session Initiation Protocol (SIP)", Work + in Progress, November 2008. + + [CERTS] Jennings, C. and J. Fischl, "Certificate Management + Service for The Session Initiation Protocol (SIP)", + Work in Progress, November 2008. + + [CONFIG-FRAME] Channabasappa, S., "A Framework for Session + Initiation Protocol User Agent Profile Delivery", + Work in Progress, February 2008. + + [CONNECT-PRECON] Andreasen, F., Camarillo, G., Oran, D., and D. + Wing, "Connectivity Preconditions for Session + Description Protocol Media Streams", Work + in Progress, October 2008. + + [CONNECT-REUSE] Gurbani, V., Mahy, R., and B. Tate, "Connection + Reuse in the Session Initiation Protocol (SIP)", + Work in Progress, October 2008. + + [DOMAIN-CERTS] Gurbani, V., Lawrence, S., and B. Laboratories, + "Domain Certificates in the Session Initiation + Protocol (SIP)", Work in Progress, October 2008. + + [ECRIT-FRAME] Rosen, B., Schulzrinne, H., Polk, J., and A. + Newton, "Framework for Emergency Calling using + Internet Multimedia", Work in Progress, July 2008. + + [GRUU] Rosenberg, J., "Obtaining and Using Globally + Routable User Agent (UA) URIs (GRUU) in the Session + Initiation Protocol (SIP)", Work in Progress, + October 2007. + + + + +Rosenberg Informational [Page 26] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + [GRUU-REG] Kyzivat, P., "Registration Event Package Extension + for Session Initiation Protocol (SIP) Globally + Routable User Agent URIs (GRUUs)", Work + in Progress, July 2007. + + [HGTTG] Adams, D., "The Hitchhiker's Guide to the Galaxy", + September 1979. + + [ICE] Rosenberg, J., "Interactive Connectivity + Establishment (ICE): A Protocol for Network Address + Translator (NAT) Traversal for Offer/Answer + Protocols", Work in Progress, October 2007. + + [ICE-TCP] Rosenberg, J., "TCP Candidates with Interactive + Connectivity Establishment (ICE)", Work + in Progress, July 2008. + + [INTERACT-FRAME] Rosenberg, J., "A Framework for Application + Interaction in the Session Initiation Protocol + (SIP)", Work in Progress, July 2005. + + [IPv6-TRANS] Camarillo, G., "IPv6 Transition in the Session + Initiation Protocol (SIP)", Work in Progress, + August 2007. + + [LOCATION] Polk, J. and B. Rosen, "Location Conveyance for the + Session Initiation Protocol", Work in Progress, + November 2008. + + [LOOP-FIX] Sparks, R., Lawrence, S., Hawrylyshen, A., and B. + Campen, "Addressing an Amplification Vulnerability + in Session Initiation Protocol (SIP) Forking + Proxies", Work in Progress, October 2008. + + [OPTION-TAG] Rosenberg, J., "Indicating Support for Interactive + Connectivity Establishment (ICE) in the Session + Initiation Protocol (SIP)", Work in Progress, + June 2007. + + [OUTBOUND] Jennings, C. and R. Mahy, "Managing Client + Initiated Connections in the Session Initiation + Protocol (SIP)", Work in Progress, October 2008. + + [POLICY-PACK] Hilt, V. and G. Camarillo, "A Session Initiation + Protocol (SIP) Event Package for Session-Specific + Session Policies.", Work in Progress, July 2008. + + [QoS-ID] Polk, J., Dhesikan, S., and G. Camarillo, "Quality + + + +Rosenberg Informational [Page 27] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + of Service (QoS) Mechanism Selection in the Session + Description Protocol (SDP)", Work in Progress, + November 2008. + + [RECORD-ROUTE] Froment, T., Lebel, C., and B. Bonnaerens, + "Addressing Record-Route issues in the Session + Initiation Protocol (SIP)", Work in Progress, + October 2008. + + [RFC2026] Bradner, S., "The Internet Standards Process -- + Revision 3", BCP 9, RFC 2026, October 1996. + + [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. + Rosenberg, "SIP: Session Initiation Protocol", + RFC 2543, March 1999. + + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS + RR for specifying the location of services (DNS + SRV)", RFC 2782, February 2000. + + [RFC2848] Petrack, S. and L. Conroy, "The PINT Service + Protocol: Extensions to SIP and SDP for IP Access + to Telephone Call Services", RFC 2848, June 2000. + + [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, + October 2000. + + [RFC3087] Campbell, B. and R. Sparks, "Control of Service + Context using SIP Request-URI", RFC 3087, + April 2001. + + [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., + Audet, F., Watson, M., and M. Zonoun, "MIME media + types for ISUP and QSIG Objects", RFC 3204, + December 2001. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., + Johnston, A., Peterson, J., Sparks, R., Handley, + M., and E. Schooler, "SIP: Session Initiation + Protocol", RFC 3261, June 2002. + + [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of + Provisional Responses in Session Initiation + Protocol (SIP)", RFC 3262, June 2002. + + [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session + Initiation Protocol (SIP): Locating SIP Servers", + RFC 3263, June 2002. + + + +Rosenberg Informational [Page 28] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer + Model with Session Description Protocol (SDP)", + RFC 3264, June 2002. + + [RFC3265] Roach, A., "Session Initiation Protocol (SIP)- + Specific Event Notification", RFC 3265, June 2002. + + [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext + Transfer Protocol (HTTP) Digest Authentication + Using Authentication and Key Agreement (AKA)", + RFC 3310, September 2002. + + [RFC3311] Rosenberg, J., "The Session Initiation Protocol + (SIP) UPDATE Method", RFC 3311, October 2002. + + [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, + "Integration of Resource Management and Session + Initiation Protocol (SIP)", RFC 3312, October 2002. + + [RFC3313] Marshall, W., "Private Session Initiation Protocol + (SIP) Extensions for Media Authorization", + RFC 3313, January 2003. + + [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, + H., Liu, Z., and J. Rosenberg, "Signaling + Compression (SigComp)", RFC 3320, January 2003. + + [RFC3323] Peterson, J., "A Privacy Mechanism for the Session + Initiation Protocol (SIP)", RFC 3323, + November 2002. + + [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private + Extensions to the Session Initiation Protocol (SIP) + for Asserted Identity within Trusted Networks", + RFC 3325, November 2002. + + [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The + Reason Header Field for the Session Initiation + Protocol (SIP)", RFC 3326, December 2002. + + [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation + Protocol (SIP) Extension Header Field for + Registering Non-Adjacent Contacts", RFC 3327, + December 2002. + + [RFC3329] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., + and T. Haukka, "Security Mechanism Agreement for + the Session Initiation Protocol (SIP)", RFC 3329, + + + +Rosenberg Informational [Page 29] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + January 2003. + + [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation + Protocol for Telephones (SIP-T): Context and + Architectures", BCP 63, RFC 3372, September 2002. + + [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. + Schulzrinne, "Grouping of Media Lines in the + Session Description Protocol (SDP)", RFC 3388, + December 2002. + + [RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong, + "Integrated Services Digital Network (ISDN) User + Part (ISUP) to Session Initiation Protocol (SIP) + Mapping", RFC 3398, December 2002. + + [RFC3401] Mealling, M., "Dynamic Delegation Discovery System + (DDDS) Part One: The Comprehensive DDDS", RFC 3401, + October 2002. + + [RFC3420] Sparks, R., "Internet Media Type message/sipfrag", + RFC 3420, November 2002. + + [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, + J., and B. Rosen, "Change Process for the Session + Initiation Protocol (SIP)", BCP 67, RFC 3427, + December 2002. + + [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., + Huitema, C., and D. Gurle, "Session Initiation + Protocol (SIP) Extension for Instant Messaging", + RFC 3428, December 2002. + + [RFC3482] Foster, M., McGarry, T., and J. Yu, "Number + Portability in the Global Switched Telephone + Network (GSTN): An Overview", RFC 3482, + February 2003. + + [RFC3486] Camarillo, G., "Compressing the Session Initiation + Protocol (SIP)", RFC 3486, February 2003. + + [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) + Refer Method", RFC 3515, April 2003. + + [RFC3524] Camarillo, G. and A. Monrad, "Mapping of Media + Streams to Resource Reservation Flows", RFC 3524, + April 2003. + + + + +Rosenberg Informational [Page 30] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, July 2003. + + [RFC3578] Camarillo, G., Roach, A., Peterson, J., and L. Ong, + "Mapping of Integrated Services Digital Network + (ISDN) User Part (ISUP) Overlap Signalling to the + Session Initiation Protocol (SIP)", RFC 3578, + August 2003. + + [RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to + the Session Initiation Protocol (SIP) for Symmetric + Response Routing", RFC 3581, August 2003. + + [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) + attribute in Session Description Protocol (SDP)", + RFC 3605, October 2003. + + [RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation + Protocol (SIP) Extension Header Field for Service + Route Discovery During Registration", RFC 3608, + October 2003. + + [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, + C., and K. Summers, "Session Initiation Protocol + (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, + December 2003. + + [RFC3666] Johnston, A., Donovan, S., Sparks, R., Cunningham, + C., and K. Summers, "Session Initiation Protocol + (SIP) Public Switched Telephone Network (PSTN) Call + Flows", BCP 76, RFC 3666, December 2003. + + [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) + Event Package for Registrations", RFC 3680, + March 2004. + + [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and + G. Camarillo, "Best Current Practices for Third + Party Call Control (3pcc) in the Session Initiation + Protocol (SIP)", BCP 85, RFC 3725, April 2004. + + [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., + and K. Norrman, "MIKEY: Multimedia Internet + KEYing", RFC 3830, August 2004. + + [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, + "Indicating User Agent Capabilities in the Session + + + +Rosenberg Informational [Page 31] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + Initiation Protocol (SIP)", RFC 3840, August 2004. + + [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, + "Caller Preferences for the Session Initiation + Protocol (SIP)", RFC 3841, August 2004. + + [RFC3842] Mahy, R., "A Message Summary and Message Waiting + Indication Event Package for the Session Initiation + Protocol (SIP)", RFC 3842, August 2004. + + [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard + (AES) Requirement for the Session Initiation + Protocol (SIP)", RFC 3853, July 2004. + + [RFC3856] Rosenberg, J., "A Presence Event Package for the + Session Initiation Protocol (SIP)", RFC 3856, + August 2004. + + [RFC3857] Rosenberg, J., "A Watcher Information Event + Template-Package for the Session Initiation + Protocol (SIP)", RFC 3857, August 2004. + + [RFC3890] Westerlund, M., "A Transport Independent Bandwidth + Modifier for the Session Description Protocol + (SDP)", RFC 3890, September 2004. + + [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session + Initiation Protocol (SIP) "Replaces" Header", + RFC 3891, September 2004. + + [RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) + Referred-By Mechanism", RFC 3892, September 2004. + + [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) + Authenticated Identity Body (AIB) Format", + RFC 3893, September 2004. + + [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) + Extension for Event State Publication", RFC 3903, + October 2004. + + [RFC3910] Gurbani, V., Brusilovsky, A., Faynberg, I., Gato, + J., Lu, H., and M. Unmehopa, "The SPIRITS (Services + in PSTN requesting Internet Services) Protocol", + RFC 3910, October 2004. + + [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation + Protocol (SIP) "Join" Header", RFC 3911, + + + +Rosenberg Informational [Page 32] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + October 2004. + + [RFC3959] Camarillo, G., "The Early Session Disposition Type + for the Session Initiation Protocol (SIP)", + RFC 3959, December 2004. + + [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and + Ringing Tone Generation in the Session Initiation + Protocol (SIP)", RFC 3960, December 2004. + + [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in + the Session Initiation Protocol (SIP)", RFC 4028, + April 2005. + + [RFC4032] Camarillo, G. and P. Kyzivat, "Update to the + Session Initiation Protocol (SIP) Preconditions + Framework", RFC 4032, March 2005. + + [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative + Network Address Types (ANAT) Semantics for the + Session Description Protocol (SDP) Grouping + Framework", RFC 4091, June 2005. + + [RFC4117] Camarillo, G., Burger, E., Schulzrinne, H., and A. + van Wijk, "Transcoding Services Invocation in the + Session Initiation Protocol (SIP) Using Third Party + Call Control (3pcc)", RFC 4117, June 2005. + + [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media + Transport in the Session Description Protocol + (SDP)", RFC 4145, September 2005. + + [RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, + "The Stream Control Transmission Protocol (SCTP) as + a Transport for the Session Initiation Protocol + (SIP)", RFC 4168, October 2005. + + [RFC4169] Torvinen, V., Arkko, J., and M. Naslund, "Hypertext + Transfer Protocol (HTTP) Digest Authentication + Using Authentication and Key Agreement (AKA) + Version-2", RFC 4169, November 2005. + + [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An + INVITE-Initiated Dialog Event Package for the + Session Initiation Protocol (SIP)", RFC 4235, + November 2005. + + [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic + + + +Rosenberg Informational [Page 33] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + Network Media Services with SIP", RFC 4240, + December 2005. + + [RFC4244] Barnes, M., "An Extension to the Session Initiation + Protocol (SIP) for Request History Information", + RFC 4244, November 2005. + + [RFC4320] Sparks, R., "Actions Addressing Identified Issues + with the Session Initiation Protocol's (SIP) Non- + INVITE Transaction", RFC 4320, January 2006. + + [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport + Layer Security", RFC 4347, April 2006. + + [RFC4411] Polk, J., "Extending the Session Initiation + Protocol (SIP) Reason Header for Preemption + Events", RFC 4411, February 2006. + + [RFC4412] Schulzrinne, H. and J. Polk, "Communications + Resource Priority for the Session Initiation + Protocol (SIP)", RFC 4412, February 2006. + + [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session + Initiation Protocol (SIP) URIs for Applications + such as Voicemail and Interactive Voice Response + (IVR)", RFC 4458, April 2006. + + [RFC4474] Peterson, J. and C. Jennings, "Enhancements for + Authenticated Identity Management in the Session + Initiation Protocol (SIP)", RFC 4474, August 2006. + + [RFC4483] Burger, E., "A Mechanism for Content Indirection in + Session Initiation Protocol (SIP) Messages", + RFC 4483, May 2006. + + [RFC4488] Levin, O., "Suppression of Session Initiation + Protocol (SIP) REFER Method Implicit Subscription", + RFC 4488, May 2006. + + [RFC4497] Elwell, J., Derks, F., Mourot, P., and O. Rousseau, + "Interworking between the Session Initiation + Protocol (SIP) and QSIG", BCP 117, RFC 4497, + May 2006. + + [RFC4508] Levin, O. and A. Johnston, "Conveying Feature Tags + with the Session Initiation Protocol (SIP) REFER + Method", RFC 4508, May 2006. + + + + +Rosenberg Informational [Page 34] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + [RFC4538] Rosenberg, J., "Request Authorization through + Dialog Identification in the Session Initiation + Protocol (SIP)", RFC 4538, June 2006. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: + Session Description Protocol", RFC 4566, July 2006. + + [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., + and E. Carrara, "Key Management Extensions for + Session Description Protocol (SDP) and Real Time + Streaming Protocol (RTSP)", RFC 4567, July 2006. + + [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session + Description Protocol (SDP) Security Descriptions + for Media Streams", RFC 4568, July 2006. + + [RFC4572] Lennox, J., "Connection-Oriented Media Transport + over the Transport Layer Security (TLS) Protocol in + the Session Description Protocol (SDP)", RFC 4572, + July 2006. + + [RFC4574] Levin, O. and G. Camarillo, "The Session + Description Protocol (SDP) Label Attribute", + RFC 4574, August 2006. + + [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A + Session Initiation Protocol (SIP) Event Package for + Conference State", RFC 4575, August 2006. + + [RFC4579] Johnston, A. and O. Levin, "Session Initiation + Protocol (SIP) Call Control - Conferencing for User + Agents", BCP 119, RFC 4579, August 2006. + + [RFC4583] Camarillo, G., "Session Description Protocol (SDP) + Format for Binary Floor Control Protocol (BFCP) + Streams", RFC 4583, November 2006. + + [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A + Session Initiation Protocol (SIP) Event + Notification Extension for Resource Lists", + RFC 4662, August 2006. + + [RFC4730] Burger, E. and M. Dolly, "A Session Initiation + Protocol (SIP) Event Package for Key Press Stimulus + (KPML)", RFC 4730, November 2006. + + [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for + DTMF Digits, Telephony Tones, and Telephony + + + +Rosenberg Informational [Page 35] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + Signals", RFC 4733, December 2006. + + [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session + Description Protocol (SDP) Content Attribute", + RFC 4796, February 2007. + + [RFC4896] Surtees, A., West, M., and A. Roach, "Signaling + Compression (SigComp) Corrections and + Clarifications", RFC 4896, June 2007. + + [RFC4916] Elwell, J., "Connected Identity in the Session + Initiation Protocol (SIP)", RFC 4916, June 2007. + + [RFC4960] Stewart, R., "Stream Control Transmission + Protocol", RFC 4960, September 2007. + + [RFC5027] Andreasen, F. and D. Wing, "Security Preconditions + for Session Description Protocol (SDP) Media + Streams", RFC 5027, October 2007. + + [RFC5049] Bormann, C., Liu, Z., Price, R., and G. Camarillo, + "Applying Signaling Compression (SigComp) to the + Session Initiation Protocol (SIP)", RFC 5049, + December 2007. + + [RFC5079] Rosenberg, J., "Rejecting Anonymous Requests in the + Session Initiation Protocol (SIP)", RFC 5079, + December 2007. + + [RFC5360] Rosenberg, J., Camarillo, G., and D. Willis, "A + Framework for Consent-Based Communications in the + Session Initiation Protocol (SIP)", RFC 5360, + October 2008. + + [RFC5361] Camarillo, G., "A Document Format for Requesting + Consent", RFC 5361, October 2008. + + [RFC5362] Camarillo, G., "The Session Initiation Protocol + (SIP) Pending Additions Event Package", RFC 5362, + October 2008. + + [RFC5363] Camarillo, G. and A. Roach, "Framework and Security + Considerations for Session Initiation Protocol + (SIP) URI-List Services", RFC 5363, October 2008. + + [RFC5365] Garcia-Martin, M. and G. Camarillo, "Multiple- + Recipient MESSAGE Requests in the Session + Initiation Protocol (SIP)", RFC 5365, October 2008. + + + +Rosenberg Informational [Page 36] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + [RFC5366] Camarillo, G. and A. Johnston, "Conference + Establishment Using Request-Contained Lists in the + Session Initiation Protocol (SIP)", RFC 5366, + October 2008. + + [RFC5367] Camarillo, G., Roach, A., and O. Levin, + "Subscriptions to Request-Contained Resource Lists + in the Session Initiation Protocol (SIP)", + RFC 5367, October 2008. + + [RFC5368] Camarillo, G., Niemi, A., Isomaki, M., Garcia- + Martin, M., and H. Khartabil, "Referring to + Multiple Resources in the Session Initiation + Protocol (SIP)", RFC 5368, October 2008. + + [RFC5373] Willis, D. and A. Allen, "Requesting Answering + Modes for the Session Initiation Protocol (SIP)", + RFC 5373, November 2008. + + [RTCP-SUM] Clark, A., Pendleton, A., Johnston, A., and H. + Sinnreich, "Session Initiation Protocol Package for + Voice Quality Reporting Event", Work in Progress, + October 2008. + + [SAML] Tschofenig, H., Hodges, J., Peterson, J., Polk, J., + and D. Sicker, "SIP SAML Profile and Binding", Work + in Progress, November 2008. + + [SDP-CAP] Andreasen, F., "SDP Capability Negotiation", Work + in Progress, July 2008. + + [SDP-MEDIA] Gilman, R., Even, R., and F. Andreasen, "SDP media + capabilities Negotiation", Work in Progress, + July 2008. + + [SESSION-POLICY] Hilt, V., Camarillo, G., and J. Rosenberg, "A + Framework for Session Initiation Protocol (SIP) + Session Policies", Work in Progress, November 2008. + + [SIMPLE] Rosenberg, J., "SIMPLE made Simple: An Overview of + the IETF Specifications for Instant Messaging and + Presence using the Session Initiation Protocol + (SIP)", Work in Progress, October 2008. + + [SIPS-URI] Audet, F., "The Use of the SIPS URI Scheme in the + Session Initiation Protocol (SIP)", Work + in Progress, November 2008. + + + + +Rosenberg Informational [Page 37] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + + [SRTP-FRAME] Fischl, J., Tschofenig, H., and E. Rescorla, + "Framework for Establishing an SRTP Security + Context using DTLS", Work in Progress, + October 2008. + + [SUBNOT-ETAGS] Niemi, A., "An Extension to Session Initiation + Protocol (SIP) Events for Conditional Event + Notification", Work in Progress, July 2008. + + [TRANSFER-MECH] Garcia, M., Isomaki, M., Camarillo, G., Loreto, S., + and P. Kyzivat, "A Session Description Protocol + (SDP) Offer/Answer Mechanism to Enable File + Transfer", Work in Progress, November 2008. + + [UA-PRIVACY] Munakata, M., Schubert, S., and T. Ohba, "UA-Driven + Privacy Mechanism for SIP", Work in Progress, + October 2008. + + [UPDATE-PAI] Elwell, J., "Updates to Asserted Identity in the + Session Initiation Protocol (SIP)", Work + in Progress, October 2008. + +Author's Address + + Jonathan Rosenberg + Cisco + Iselin, NJ + US + + EMail: jdrosen@cisco.com + URI: http://www.jdrosen.net + + + + + + + + + + + + + + + + + + + + +Rosenberg Informational [Page 38] + +RFC 5411 Hitchhiker's Guide to SIP January 2009 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2009). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +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. + + + + + + + + + + + + +Rosenberg Informational [Page 39] + + -- cgit v1.2.3