idnits 2.17.1 draft-ietf-sip-hitchhikers-guide-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1405. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1416. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1423. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1429. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 5, 2007) is 6111 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-16 -- Obsolete informational reference (is this intentional?): RFC 3427 (ref. '8') (Obsoleted by RFC 5727) -- Obsolete informational reference (is this intentional?): RFC 2543 (ref. '9') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Obsolete informational reference (is this intentional?): RFC 2915 (ref. '12') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '13') (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 4474 (ref. '19') (Obsoleted by RFC 8224) == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-14 == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-09 -- Obsolete informational reference (is this intentional?): RFC 2976 (ref. '30') (Obsoleted by RFC 6086) -- Obsolete informational reference (is this intentional?): RFC 4244 (ref. '37') (Obsoleted by RFC 7044) == Outdated reference: A later version (-07) exists of draft-ietf-sip-answermode-04 == Outdated reference: A later version (-05) exists of draft-ietf-sip-acr-code-04 == Outdated reference: A later version (-03) exists of draft-ietf-sip-multiple-refer-01 == Outdated reference: A later version (-13) exists of draft-ietf-sipping-rtcp-summary-02 == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-12 == Outdated reference: A later version (-02) exists of draft-ietf-sip-uri-list-subscribe-01 == Outdated reference: A later version (-03) exists of draft-ietf-sip-uri-list-message-01 == Outdated reference: A later version (-02) exists of draft-ietf-sip-uri-list-conferencing-01 == Outdated reference: A later version (-06) exists of draft-ietf-sip-e2m-sec-05 -- Obsolete informational reference (is this intentional?): RFC 4566 (ref. '78') (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 3388 (ref. '79') (Obsoleted by RFC 5888) == Outdated reference: A later version (-08) exists of draft-ietf-sip-fork-loop-fix-05 -- Obsolete informational reference (is this intentional?): RFC 4091 (ref. '87') (Obsoleted by RFC 5245) == Outdated reference: A later version (-16) exists of draft-ietf-mmusic-ice-tcp-03 -- Obsolete informational reference (is this intentional?): RFC 4583 (ref. '91') (Obsoleted by RFC 8856) == Outdated reference: A later version (-04) exists of draft-ietf-mmusic-securityprecondition-03 == Outdated reference: A later version (-07) exists of draft-ietf-mmusic-connectivity-precon-02 == Outdated reference: A later version (-08) exists of draft-ietf-sipping-policy-package-03 == Outdated reference: A later version (-15) exists of draft-ietf-sip-certs-03 == Outdated reference: A later version (-04) exists of draft-ietf-sip-consent-framework-01 == Outdated reference: A later version (-08) exists of draft-ietf-sip-saml-02 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-pending-additions-02 -- Obsolete informational reference (is this intentional?): RFC 4572 (ref. '104') (Obsoleted by RFC 8122) == Outdated reference: A later version (-13) exists of draft-ietf-mmusic-sdp-capability-negotiation-05 == Outdated reference: A later version (-17) exists of draft-ietf-mmusic-sdp-media-capabilities-01 == Outdated reference: A later version (-11) exists of draft-ietf-mmusic-file-transfer-mech-03 == Outdated reference: A later version (-10) exists of draft-ietf-sip-record-route-fix-00 == Outdated reference: A later version (-03) exists of draft-ietf-sip-subnot-etags-00 == Outdated reference: A later version (-09) exists of draft-ietf-sip-sips-05 Summary: 1 error (**), 0 flaws (~~), 28 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP J. Rosenberg 3 Internet-Draft Cisco 4 Intended status: Informational July 5, 2007 5 Expires: January 6, 2008 7 A Hitchhiker's Guide to the Session Initiation Protocol (SIP) 8 draft-ietf-sip-hitchhikers-guide-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 6, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The Session Initiation Protocol (SIP) is the subject of numerous 42 specifications that have been produced by the IETF. It can be 43 difficult to locate the right document, or even to determine the set 44 of Request for Comments (RFC) about SIP. This specification serves 45 as a guide to the SIP RFC series. It lists the specifications under 46 the SIP umbrella, briefly summarizes each, and groups them into 47 categories. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Scope of this Document . . . . . . . . . . . . . . . . . . . . 3 53 3. Core SIP Specifications . . . . . . . . . . . . . . . . . . . 4 54 4. Public Switched Telephone Network (PSTN) Interworking . . . . 7 55 5. General Purpose Infrastructure Extensions . . . . . . . . . . 9 56 6. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 11 57 7. Minor Extensions . . . . . . . . . . . . . . . . . . . . . . . 12 58 8. Conferencing . . . . . . . . . . . . . . . . . . . . . . . . . 13 59 9. Call Control Primitives . . . . . . . . . . . . . . . . . . . 14 60 10. Event Framework and Packages . . . . . . . . . . . . . . . . . 15 61 11. Quality of Service . . . . . . . . . . . . . . . . . . . . . . 16 62 12. Operations and Management . . . . . . . . . . . . . . . . . . 17 63 13. SIP Compression . . . . . . . . . . . . . . . . . . . . . . . 17 64 14. SIP Service URIs . . . . . . . . . . . . . . . . . . . . . . . 18 65 15. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 19 66 16. Instant Messaging, Presence and Multimedia . . . . . . . . . . 20 67 17. Emergency Services . . . . . . . . . . . . . . . . . . . . . . 21 68 18. Security Considerations . . . . . . . . . . . . . . . . . . . 21 69 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 70 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 71 21. Informative References . . . . . . . . . . . . . . . . . . . . 21 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30 73 Intellectual Property and Copyright Statements . . . . . . . . . . 32 75 1. Introduction 77 The Session Initiation Protocol (SIP) [1] is the subject of numerous 78 specifications that have been produced by the IETF. It can be 79 difficult to locate the right document, or even to determine the set 80 of Request for Comments (RFC) about SIP. Don't Panic! [42] This 81 specification serves as a guide to the SIP RFC series. It lists the 82 specifications under the SIP umbrella. For each specification, a 83 paragraph or so description is included that summarizes the purpose 84 of the specification. Each specification also includes a letter that 85 designates its category in the standards track [2]. These values 86 are: 88 S: Standards Track (Proposed Standard, Draft Standard, or Standard) 90 E: Experimental 92 B: Best Current Practice 94 I: Informational 96 The specifications are grouped together by topic. Typically, SIP 97 extensions fit naturally into topic areas, and implementations 98 interested in a particular topic often implement many or all of the 99 specifications in that area. There are some specifications which 100 fall into multiple topic areas, in which case they are listed more 101 than once. 103 This document itself is not an update to RFC 3261 or an extension to 104 SIP. It is an informational document, meant to guide newcomers, 105 implementors and deployers to the SIP suite of specifications. 107 2. Scope of this Document 109 It is very difficult to enumerate the set of SIP specifications. 110 This is because there are many protocols that are intimately related 111 to SIP and used by nearly all SIP implementations, but are not 112 formally SIP extensions. As such, this document formally defines a 113 "SIP specification" as: 115 o Any specification that defines an extension to SIP itself, where 116 an extension is a mechanism that changes or updates in some way a 117 behavior specified in RFC 3261 119 o Any specification that defines an extension to SDP whose primary 120 purpose is to support SIP 122 o Any specification that defines a MIME object whose primary purpose 123 is to support SIP 125 Excluded from this list are requirements, architectures, registry 126 definitions, non-normative frameworks, and processes. Best Current 127 Practices are included when they normatively define mechanisms for 128 accomplishing a task. 130 The SIP change process [8] defines two types of extensions to SIP. 131 These are normal extensions and the so-called P-headers (where P 132 stands for "preliminary", "private", or "proprietary", and the "P-" 133 prefix is included in the header field name) are meant to be used in 134 areas of limited applicability. P-headers cannot be defined in the 135 standards track. For the most part, P-headers are not included in 136 the listing here, with the exception of those which have seen general 137 usage despite their P-header status. 139 3. Core SIP Specifications 141 The core SIP specifications represent the set of specifications whose 142 functionality is broadly applicable. An extension is broadly 143 applicable if it fits into one of the following categories: 145 o For specifications that impact SIP session management, the 146 extension would be used for almost every session initiated by a 147 user agent 149 o For specifications that impact SIP registrations, the extension 150 would be used for almost every registration initiated by a user 151 agent 153 o For specifications that impact SIP subscriptions, the extension 154 would be used for almost every subscription initiated by a user 155 agent 157 In other words, these are not specifications that are used just for 158 some requests and not others; they are specifications that would 159 apply to each and every request that the extension is relevant for. 160 In the galaxy of SIP, these specifications are like towels [42]. 162 RFC 3261, The Session Initiation Protocol (S): RFC 3261 [1] is the 163 core SIP protocol itself. RFC 3261 is an update to RFC 2543 [9]. 164 It is the president of the galaxy [42] as far as the suite of SIP 165 specifications is concerned. 167 RFC 3263, Locating SIP Servers (S): RFC 3263 [10] provides DNS 168 procedures for taking a SIP URI, and determining a SIP server that 169 is associated with that SIP URI. RFC 3263 is essential for any 170 implementation using SIP with DNS. RFC 3263 makes use of both DNS 171 SRV records [11] and NAPTR records [12]. 173 RFC 3264, An Offer/Answer Model with the Session Description Protocol 174 (S): RFC 3264 [4] defines how the Session Description Protocol (SDP) 175 [78] is used with SIP to negotiate the parameters of a media 176 session. It is in widespread usage and an integral part of the 177 behavior of RFC 3261. 179 RFC 3265, SIP-Specific Event Notification (S): RFC 3265 [13] defines 180 the SUBSCRIBE and NOTIFY methods. These two methods provide a 181 general event notification framework for SIP. To actually use the 182 framework, extensions need to be defined for specific event 183 packages. An event package defines a schema for the event data, 184 and describes other aspects of event processing specific to that 185 schema. An RFC 3265 implementation is required when any event 186 package is used. 188 RFC 3325, Private Extensions to SIP for Asserted Identity within 189 Trusted Networks (I): Though its P-header status implies that it has 190 limited applicability, RFC 3325 [15], which defines the 191 P-Asserted-ID header field has been widely deployed. It is used 192 as the basic mechanism for providing secure caller ID services. 194 RFC 3327, SIP Extension Header Field for Registering Non-Adjacent 195 Contacts (S): RFC 3327 [16] defines the Path header field. This 196 field is inserted by proxies between a client and their registrar. 197 It allows inbound requests towards that client to traverse these 198 proxies prior to being delivered to the user agent. It is 199 essential in any SIP deployment that has edge proxies, which are 200 proxies between the client and the home proxy or SIP registrar. 202 RFC 3581, An Extension to SIP for Symmetric Response Routing (S): 203 RFC 3581 [17] defines the rport parameter of the Via header. It 204 is an essential piece of getting SIP through NAT. NAT traversal 205 for SIP is considered a core part of the specifications. 207 RFC 3840, Indicating User Agent Capabilities in SIP (S): RFC 3840 208 [33] defines a mechanism for carrying capability information about 209 a user agent in REGISTER requests and in dialog-forming requests 210 like INVITE. It has found use with conferencing (the isfocus 211 parameter declares that a user agent is a conference server) and 212 with applications like push-to-talk. 214 RFC 4320, Actions Addressing Issues Identified with the Non-INVITE 215 Transaction in SIP (S): RFC 4320 [18] formally updates RFC 3261, and 216 modifies some of the behaviors associated with non-INVITE 217 transactions. These address some problems found in timeout and 218 failure cases. 220 RFC 4474, Enhancements for Authenticated Identity Management in SIP 221 (S): RFC 4474 [19] defines a mechanism for providing a 222 cryptographically verifiable identity of the calling party in a 223 SIP request. Known as "SIP Identity", this mechanism provides an 224 alternative to RFC 3325. It has seen little deployment so far, 225 but its importance as a key construct for anti-spam techniques 226 makes it a core part of the SIP specifications. 228 RFC XXXX, Obtaining and Using Globally Routable User Agent 229 Identifiers (GRUU) in SIP (S): RFC XXXX [20] defines a mechanism for 230 directing requests towards a specific UA instance. GRUU is 231 essential for features like transfer and provides another piece of 232 the SIP NAT traversal story. 234 RFC XXXX, Managing Client Initiated Connections through SIP (S): RFC 235 XXXX [21], also known as SIP outbound, defines important changes 236 to the SIP registration mechanism which enable delivery of SIP 237 messages towards a UA when it is behind a NAT. This specification 238 is the cornerstone of the SIP NAT traversal strategy. 240 RFC 4566, Session Description Protocol (S): RFC 4566 [78] defines a 241 format for representing multimedia sessions. SDP objects are 242 carried in the body of SIP messages, and based on the offer/answer 243 model, are used to negotiate the media characteristics of a 244 session between users. 246 RFC XXXX, SDP Capability Negotiation (S): RFC XXXX [105] defines a 247 set of extensions to SDP that allow for capability negotiation 248 within SDP. Capability negotiation can be used to select between 249 different profiles of RTP (secure vs. unsecure) or to negotiate 250 codecs such that an agent has to select one amongst a set of 251 supported codecs. 253 RFC 3388, Grouping of Media Lines in the Session Description Protocol 254 (S): RFC 3388 [79] defines a framework for grouping together media 255 streams in an SDP message. Such a grouping allows relationships 256 between these streams, such as which stream is the audio for a 257 particular video feed, to be expressed. 259 RFC XXXX, Interactive Connectivity Establishment (ICE) (S): RFC XXXX 260 [5] defines a technique for NAT traversal of media sessions for 261 protocols that make use of the offer/answer model. This 262 specification is the IETF recommended mechanism for NAT traversal 263 for SIP media streams, and is meant to be used even by endpoints 264 which are themselves never behind a NAT. A SIP option tag and 265 media feature tag RFC XXXX [108] have been defined for use with 266 ICE. 268 RFC 3605, Real Time Control Protocol (RTCP) Attribute in the Session 269 Description Protocol (SDP) (S): RFC 3605 [80] defines a way to 270 explicitly signal, within an SDP message, the IP address and port 271 for RTCP, rather than using the port+1 rule in the Real Time 272 Transport Protocol (RTP) [3]. It is needed for devices behind NAT 273 and used by ICE. 275 RFC 4916, Connected Identity in the Session Initiation Protocol (SIP) 276 (S): RFC 4916 [81] defines an extension to SIP that allows a UAC to 277 determine the identity of the UAS. Due to forwarding and 278 retargeting services, this may not be the same as the user that 279 the UAC was originally trying to reach. The mechanism works in 280 tandem with the SIP identity specification [19] to provide 281 signatures over the connected party identity. 283 RFC XXXX, The use of the SIPS URI Scheme in the Session Initiation 284 Protocol (SIP) (S): RFC XXXX [112] revises the processing of the 285 SIPS URI, originally defined in RFC 3261, to fix many errors and 286 problems that have been encountered with that mechanism. 288 Essential Corrections to SIP: A collection of fixes to SIP that 289 address important bugs and vulnerabilities. These include a fix 290 requiring loop detection in any proxy that forks [82] and a 291 clarification on how record-routing works [110]. 293 4. Public Switched Telephone Network (PSTN) Interworking 295 Numerous extensions and usages of SIP related to interoperability and 296 communications with or through the PSTN. 298 RFC 2848, The PINT Service Protocol (S): RFC 2848 [22] is one of the 299 earliest extensions to SIP. It defines procedures for using SIP 300 to invoke services that actually execute on the PSTN. Its main 301 application is for third party call control, allowing an IP host 302 to set up a call between two PSTN endpoints. PINT has a 303 relatively narrow focus and has not seen widespread deployment. 305 RFC 3910, The SPIRITS Protocol (S): Continuing the trend of naming 306 PSTN related extensions with alcohol references, SPIRITS [23] 307 defines the inverse of PINT. It allows a switch in the PSTN to 308 ask an IP element about how to proceed with call waiting. It was 309 developed primarily to support Internet Call Waiting (ICW). 310 Perhaps the next specification will be called the Pan Galactic 311 Gargle Blaster [42]. 313 RFC 3372, SIP for Telephones (SIP-T): Context and Architectures (I): 314 SIP-T [24] defines a mechanism for using SIP between pairs of PSTN 315 gateways. Its essential idea is to tunnel ISUP signaling between 316 the gateways in the body of SIP messages. SIP-T motivated the 317 development of INFO [30]. SIP-T has seen widespread 318 implementation. 320 RFC 3398, ISUP to SIP Mapping (S): RFC 3398 [25] defines how to do 321 protocol mapping from the SS7 ISDN User Part (ISUP) signaling to 322 SIP. It is widely used in SS7 to SIP gateways and is part of the 323 SIP-T framework. 325 RFC 3578, Mapping of ISUP Overlap Signaling to SIP (S): RFC 3578 326 [26] defines a mechanism to map overlap dialing into SIP. This 327 specification is widely regarded as the ugliest SIP specification, 328 as the introduction to the specification itself advises that it 329 has many problems. Overlap signaling (the practice of sending 330 digits into the network as dialed instead of waiting for complete 331 collection of the called party number) is largely incompatible 332 with SIP at some fairly fundamental levels. That said, RFC 3578 333 is mostly harmless and has seen some usage. 335 RFC 3960, Early Media and Ringtone Generation in SIP (I): RFC 3960 336 [27] defines some guidelines for handling early media - the 337 practice of sending media from the called party towards the caller 338 - prior to acceptance of the call. Early media is generated only 339 from the PSTN. 341 RFC 3959, Early Session Disposition Type for the Session Initiation 342 Protocol (SIP) (S): RFC 3959 [83] defines a new session disposition 343 type for use with early media. It indicates that the SDP in the 344 body is for a special early media session. 346 RFC 3204, MIME Media Types for ISUP and QSIG Objects (S): RFC 3204 347 [84] defines MIME objects for representing SS7 signaling messages. 348 These are carried in the body of SIP messages when SIP-T is used. 350 5. General Purpose Infrastructure Extensions 352 These extensions are general purpose enhancements to SIP, SDP and 353 MIME that can serve a wide variety of uses. However, they are not as 354 widely used or as essential as the core specifications. 356 RFC 3262, Reliability of Provisional Responses in SIP (S): SIP 357 defines two types of responses to a request - final and 358 provisional. Provisional responses are numbered from 100 to 199. 359 In SIP, these responses are not sent reliably. This choice was 360 made in RFC 2543 since the messages were meant to just be truly 361 informational, and rendered to the user. However, subsequent work 362 on PSTN interworking demonstrated a need to map provisional 363 responses to PSTN messages that needed to be sent reliably. RFC 364 3262 [28] was developed to allow reliability of provisional 365 responses. The specification defines the PRACK method, used for 366 indicating that a provisional response was received. Though it 367 provides a generic capability for SIP, RFC 3262 implementations 368 have been most common in PSTN interworking devices. However, 369 PRACK brings a great deal of complication for relatively small 370 benefit. As such, it has seen only mild levels of deployment. 372 RFC 3323, A Privacy Mechanism for the Session Initiation Protocol 373 (SIP) (S): RFC 3323 [14] defines the Privacy header field, used by 374 clients to request anonymity for their requests. Though it 375 defines numerous privacy services, the only one broadly used is 376 the one that supports privacy of the P-Asserted-ID header field 377 [15]. 379 RFC 3311, The SIP UPDATE Method (S): RFC 3311 [29] defines the 380 UPDATE method for SIP. This method is meant as a means for 381 updating session information prior to the completion of the 382 initial INVITE transaction. It was developed primarily to support 383 RFC 3312 [59]. 385 RFC 2976, The INFO Method (S): RFC 2976 [30] was defined as an 386 extension to RFC 2543. It defines a method, INFO, used to 387 transport mid-dialog information that has no impact on SIP itself. 388 Its driving application was the transport of PSTN related 389 information when using SIP between a pair of gateways. Though 390 originally conceived for broader use, it only found standardized 391 usage with SIP-T [24]. It has been used to support numerous 392 proprietary and non-interoperable extensions due to its poorly 393 defined scope. 395 RFC 3326, The Reason header field for SIP (S): RFC 3326 [31] defines 396 the Reason header field. It is used in requests, such as BYE, to 397 indicate the reason that the request is being sent. 399 RFC 3420, Internet Media Type message/sipfrag (S): RFC 3420 [85] 400 defines a MIME object that contains a SIP message fragment. Only 401 certain header fields and parts of the SIP message are present. 402 For example, it is used to report back on the responses received 403 to a request sent as a consequence of a REFER. 405 RFC 3608, SIP Extension Header Field for Service Route Discovery 406 During Registration (S): RFC 3608 [32] allows a client to determine, 407 from a REGISTER response, a path of proxies to use in requests it 408 sends outside of a dialog. In many respects, it is the inverse of 409 the Path header field, but has seen less usage since default 410 outbound proxies have been sufficient in many deployments. 412 RFC 3841, Caller Preferences for SIP (S): RFC 3841 [34] defines a 413 set of headers that a client can include in a request to control 414 the way in which the request is routed downstream. It allows a 415 client to direct a request towards a UA with specific 416 capabilities. 418 RFC 4028, Session Timers in SIP (S): RFC 4028 [35] defines a 419 keepalive mechanism for SIP signaling. It is primarily meant to 420 provide a way to cleanup old state in proxies that are holding 421 call state for calls from failed endpoints which were never 422 terminated normally. Despite its name, the session timer is not a 423 mechanism for detecting a network failure mid-call. Session 424 timers introduces a fair bit of complexity for relatively little 425 gain, and has thus seen little deployment. 427 RFC 4168, SCTP as a Transport for SIP (S): RFC 4168 [36] defines how 428 to carry SIP messages over the Stream Control Transmission 429 Protocol (SCTP). SCTP has seen very limited usage for SIP 430 transport. 432 RFC 4244, An Extension to SIP for Request History Information (S): 433 RFC 4244 [37] defines the History-Info header field, which 434 indicates information on how a call came to be routed to a 435 particular destination. Its primary application was in support of 436 voicemail services. 438 RFC 4145, TCP-Based Media Transport in the Session Description 439 Protocol (SDP) (S): RFC 4145 [86] defines an extension to SDP for 440 setting up TCP-based sessions between user agents. It defines who 441 sets up the connection and how its lifecycle is managed. It has 442 seen relatively little usage due to the small number of media 443 types to date which use TCP. 445 RFC 4091, The Alternative Network Address Types (ANAT) Semantics for 446 the Session Description Protocol (SDP) Grouping Framework (S): RFC 447 4091 [87] defines a mechanism for including both IPv4 and IPv6 448 addresses for a media session as alternates. 450 RFC XXXX, SDP Media Capabilities Negotiation (S): RFC XXXX [106] 451 defines an extension to the SDP capability negotiation framework 452 [105] for negotiating codecs, codec parameters, and media streams. 454 6. NAT Traversal 456 These SIP extensions are primarily aimed at addressing NAT traversal 457 for SIP. 459 RFC XXXX, Interactive Connectivity Establishment (ICE) (S): RFC XXXX 460 [5] defines a technique for NAT traversal of media sessions for 461 protocols that make use of the offer/answer model. This 462 specification is the IETF recommended mechanism for NAT traversal 463 for SIP media streams, and is meant to be used even by endpoints 464 which are themselves never behind a NAT. A SIP option tag and 465 media feature tag RFC XXXX [108] have been defined for use with 466 ICE. 468 RFC XXXX, TCP Candidates with Interactive Connectivity Establishment 469 (ICE) (S): RFC XXXX [88] specifies the usage of ICE for TCP streams. 470 This allows for selection of RTP-based voice ontop of TCP only 471 when NAT or firewalls would prevent UDP-based voice from working. 473 RFC 3605, Real Time Control Protocol (RTCP) Attribute in the Session 474 Description Protocol (SDP) (S): RFC 3605 [80] defines a way to 475 explicitly signal, within an SDP message, the IP address and port 476 for RTCP, rather than using the port+1 rule in the Real Time 477 Transport Protocol (RTP) [3]. It is needed for devices behind NAT 478 and used by ICE. 480 RFC XXXX, Managing Client Initiated Connections through SIP (S): RFC 481 XXXX [21], also known as SIP outbound, defines important changes 482 to the SIP registration mechanism which enable delivery of SIP 483 messages towards a UA when it is behind a NAT. This specification 484 is the cornerstone of the SIP NAT traversal strategy. 486 RFC 3581, An Extension to SIP for Symmetric Response Routing (S): 487 RFC 3581 [17] defines the rport parameter of the Via header. It 488 is an essential piece of getting SIP through NAT. NAT traversal 489 for SIP is considered a core part of the specifications. 491 RFC XXXX, Obtaining and Using Globally Routable User Agent 492 Identifiers (GRUU) in SIP (S): RFC XXXX [20] defines a mechanism for 493 directing requests towards a specific UA instance. GRUU is 494 essential for features like transfer and provides another piece of 495 the SIP NAT traversal story. 497 7. Minor Extensions 499 These SIP extensions don't fit easily into a single specific use 500 case. They have somewhat general applicability, but they solve a 501 relatively small problem or provide an optimization. 503 RFC 4488, Suppression of the SIP REFER Implicit Subscription (S): 504 RFC 4488 [38] defines an enhancement to REFER. REFER normally 505 creates an implicit subscription to the target of the REFER. This 506 subscription is used to pass back updates on the progress of the 507 referral. This extension allows that implicit subscription to be 508 bypassed as an optimization. 510 RFC 4538, Request Authorization through Dialog Identification in SIP 511 (S): RFC 4538 [39] provides a mechanism that allows a UAS to 512 authorize a request because the requestor proves it knows a dialog 513 that is in progress with the UAS. The specification is useful in 514 conjunction with the SIP application interaction framework [77]. 516 RFC 4508, Conveying Feature Tags with the REFER Method in SIP (S): 517 RFC 4508 [40] defines a mechanism for carrying RFC 3840 feature 518 tags in REFER. It is useful for informing the target of the REFER 519 about the characteristics of the REFER target. 521 RFC XXXX, Requesting Answer Modes for SIP (S): RFC XXXX [41] defines 522 an extension for indicating to the called party whether or not the 523 phone should ring and/or be answered immediately. This is useful 524 for push-to-talk and for diagnostic applications. 526 RFC XXXX, Rejecting Anonymous Requests in SIP (S): RFC XXXX [43] 527 defines a mechanism for a called party to indicate to the calling 528 party that a call was rejected since the caller was anonymous. 529 This is needed for implementation of the Anonymous Call Rejection 530 (ACR) feature in SIP. 532 RFC XXXX, Referring to Multiple Resources in SIP (S): RFC XXXX [44] 533 allows a UA sending a REFER to ask the recipient of the REFER to 534 generate multiple SIP requests, not just one. This is useful for 535 conferencing, where a client would like to ask a conference server 536 to eject multiple users. 538 RFC 4483, A Mechanism for Content Indirection in Session Initiation 539 Protocol (SIP) Messages (S): RFC 4483 [89] defines a mechanism for 540 content indirection. Instead of carrying an object within a SIP 541 body, a URL reference is carried instead, and the recipient 542 dereferences the URL to obtain the object. The specification has 543 potential applicability for sending large instant messages, but 544 has yet to find much actual use. 546 RFC 3890, A Transport Independent Bandwidth Modifier for the Session 547 Description Protocol (SDP) (S): RFC 3890 [90] specifies an SDP 548 extension that allows for the description of the bandwidth for a 549 media session that is independent of the underlying transport 550 mechanism. It has seen relatively little usage. 552 RFC 4583, Session Description Protocol (SDP) Format for Binary Floor 553 Control Protocol (BFCP) Streams (S): RFC 4583 [91] defines a 554 mechanism in SDP to signal floor control streams that use BFCP. 555 It is used for Push-To-Talk and conference floor control. 557 RFC XXXX, Connectivity Preconditions for Session Description Protocol 558 Media Streams (S): RFC XXXX [93] defines a usage of the precondition 559 framework [59]. The connectivity precondition makes sure that the 560 session doesn't get established until actual packet connectivity 561 is checked. 563 RFC 4796, The SDP (Session Description Protocol) Content Attribute 564 (S): RFC 4796 [94] defines an SDP attribute for describing the 565 purpose of a media stream. Examples include a slide view, the 566 speaker, a sign language feed, and so on. 568 8. Conferencing 570 Numerous SIP and SDP extensions are aimed at conferencing as their 571 primary application. 573 RFC 4574, The SDP (Session Description Protocol) Label Attribute 574 (S): RFC 4574 [95] defines an SDP attribute for providing an opaque 575 label for media streams. These labels can be referred to by 576 external documents, and in particular, by conference policy 577 documents. This allows a UA to tie together documents it may 578 obtain through conferencing mechanisms to media streams to which 579 they refer. 581 RFC 3911, The SIP Join Header Field (S): RFC 3911 [49] defines the 582 Join header field. When sent in an INVITE, it causes the 583 recipient to join the resulting dialog into a conference with 584 another dialog in progress. 586 RFC 4575, A SIP Event Package for Conference State (S): RFC 4575 587 [56] defines a mechanism for learning about changes in conference 588 state, including group membership. 590 RFC XXXX, Conference Establishment Using Request-Contained Lists in 591 SIP (S): RFC XXXX [70] is similar to [68]. However, instead of 592 subscribing to the resource, an INVITE request is sent to the 593 resource, and it will act as a conference focus and generate an 594 invitation to each recipient in the list. 596 9. Call Control Primitives 598 Numerous SIP extensions provide a toolkit of dialog and call 599 management techniques. These techniques have been combined together 600 to build many SIP-based services. 602 RFC 3515, The REFER Method (S): REFER [45] defines a mechanism for 603 asking a user agent to send a SIP request. Its a form of SIP 604 remote control, and is the primary tool used for call transfer in 605 SIP. 607 RFC 3725, Best Current Practices for Third Party Call Control (3pcc) 608 (B): RFC 3725 [46] defines a number of different call flows that 609 allow one SIP entity, called the controller, to create SIP 610 sessions amongst other SIP user agents. 612 RFC 3911, The SIP Join Header Field (S): RFC 3911 [49] defines the 613 Join header field. When sent in an INVITE, it causes the 614 recipient to join the resulting dialog into a conference with 615 another dialog in progress. 617 RFC 3891, The SIP Replaces Header (S): RFC 3891 [47] defines a 618 mechanism that allows a new dialog to replace an existing dialog. 619 It is useful for certain advanced transfer services. 621 RFC 3892, The SIP Referred-By Mechanism (S): RFC 3892 [48] defines 622 the Referred-By header field. It is used in requests triggered by 623 REFER, and provides the identity of the referring party to the 624 referred-to party. 626 RFC 4117, Transcoding Services Invocation in SIP Using Third Party 627 Call Control (I): RFC 4117 [50] defines how to use 3pcc for the 628 purposes of invoking transcoding services for a call. 630 10. Event Framework and Packages 632 RFC 3265 defines a basic framework for event notification in SIP. It 633 introduces the notion of an event package, which is a collection of 634 related state and event information. Much of the state and events in 635 SIP systems have event packages, allowing other entities to learn 636 about changes in that state. 638 RFC 3903, SIP Extension for Event State Publication (S): RFC 3903 639 [51] defines the PUBLISH method. It is not an event package, but 640 is used by all event packages as a mechanism for pushing an event 641 into the system. 643 RFC 4662, A Session Initiation Protocol (SIP) Event Notification 644 Extension for Resource Lists (S): RFC 4662 [67] defines an extension 645 to RFC 3265 that allows a client to subscribe to a list of 646 resources using a single subscription. The server, called a 647 Resource List Server (RLS) will "expand" the subscription and 648 subscribe to each individual member of the list. It has found 649 applicability primarily in the area of presence, but can be used 650 with any event package. 652 RFC XXXX, An Extension to Session Initiation Protocol (SIP) Events 653 for Conditional Event Notification (S): RFC XXXX [111] defines an 654 extension to RFC 3265 to optimize the performance of 655 notifications. When a client subscribes, it can indicate what 656 version of a document it has, so that the server can skip sending 657 a notification if the client is up to date. It is applicable to 658 any event package. 660 RFC 3680, A SIP Event Package for Registrations (S): RFC 3680 [52] 661 defines an event package for finding out about changes in 662 registration state. 664 RFC 3842, A Message Summary and Message Waiting Indication Event 665 Package for SIP (S): RFC 3842 [65] defines a way for a user agent to 666 find out about voicemails and other messages that are waiting for 667 it. Its primary purpose is to enable the voicemail waiting lamp 668 on most business telephones. 670 RFC 3856, A Presence Event Package for SIP (S): RFC 3856 [53] 671 defines an event package for indicating user presence through SIP. 673 RFC 3857, A Watcher Information Event Template Package for SIP (S): 674 RFC 3857 [54], also known as winfo, provides a mechanism for a 675 user agent to find out what subscriptions are in place for a 676 particular event package. Its primary usage is with presence, but 677 it can be used with any event package. 679 RFC 4235, An INVITE Initiated Dialog Event Package for SIP (S): RFC 680 4235 [55] defines an event package for learning the state of the 681 dialogs in progress at a user agent, and is one of several RFCs 682 starting with the important number 42 [42]. 684 RFC 4575, A SIP Event Package for Conference State (S): RFC 4575 685 [56] defines a mechanism for learning about changes in conference 686 state, including group membership. 688 RFC 4730, A SIP Event Package for Keypress Stimulus (KPML) (S): RFC 689 4730 [57] defines a way for an application in the network to 690 subscribe to the set of keypresses made on the keypad of a 691 traditional telephone. 693 RFC XXXX, SIP Event Package for Voice Quality Reporting (S): RFC 694 XXXX [58] defines a SIP event package that enables the collection 695 and reporting of metrics that measure the quality for Voice over 696 Internet Protocol (VoIP) sessions. 698 RFC XXXX, A Session Initiation Protocol (SIP) Event Package for 699 Session-Specific Session Policies (S): RFC XXXX [96] defines a SIP 700 event package that allows a proxy to notify a user agent about its 701 desire for the UA to use certain codecs or generally obey certain 702 media session policies. 704 RFC XXXX, The Session Initiation Protocol (SIP) Pending Additions 705 Event Package (S): RFC XXXX [103] defines a SIP event package that 706 allows a UA to learn whether consent has been given for the 707 addition of an address to a SIP "mailing list". It is used in 708 conjunction with the SIP framework for consent [101]. 710 11. Quality of Service 712 Several specifications concern themselves with the interactions of 713 SIP with network Quality of Service (QoS) mechanisms. 715 RFC 3312, Integration of Resource Management and SIP (S): RFC 3312 716 [59], updated by RFC 4032 [60] defines a way to make sure that the 717 phone of the called party doesn't ring until a QoS reservation has 718 been installed in the network. It does so by defining a general 719 preconditions framework, which defines conditions that must be 720 true in order for a SIP session to proceed 722 RFC 3313, Private SIP Extensions for Media Authorization (I): RFC 723 3313 [61] defines a P-header that provides a mechanism for passing 724 an authorization token between SIP and a network QoS reservation 725 protocol like RSVP. Its purpose is to make sure network QoS is 726 only granted if a client has made a SIP call through the same 727 providers network. This specification is sometimes referred to as 728 the SIP walled garden specification by the truly paranoid androids 729 in the SIP community. This is because it requires coupling of 730 signaling and the underlying IP network. 732 RFC 3524, Mapping of Media Streams to Resource Reservation Flows 733 (S): RFC 3524 [97] defines a usage of the SDP grouping framework for 734 indicating that a set of media streams should be handled by a 735 single resource reservation. 737 12. Operations and Management 739 Several specifications have been defined to support operations and 740 management of SIP systems. These include mechanisms for 741 configuration and network diagnostics. 743 RFC XXXX, Diagnostic Responses for SIP Hop Limit Errors (S): RFC 744 XXXX [98] defines a mechanism for including diagnostic information 745 in a 483 response. This response is sent when the hop-count of a 746 SIP request was exceeded. 748 RFC XXXX, A Framework for SIP User Agent Profile Delivery (S): RFC 749 XXXX [62] defines a mechanism that allows a SIP user agent to 750 bootstrap its configuration from the network, and receive updates 751 to its configuration should it change. This is considered an 752 essential piece of deploying a usable SIP network. 754 RFC XXXX, Extensions to the Session Initiation Protocol (SIP) User 755 Agent Profile Delivery Change Notification Event Package for the 756 Extensible Markup Language Language Configuration Access Protocol 757 (XCAP) (S): RFC XXXX [63] defines an extension to [62] for learning 758 about changes in documents managed by XCAP. 760 RFC XXXX, SIP Event Package for Voice Quality Reporting (S): RFC 761 XXXX [58] defines a SIP event package that enables the collection 762 and reporting of metrics that measure the quality for Voice over 763 Internet Protocol (VoIP) sessions. 765 13. SIP Compression 767 Sigcomp [6] was defined to allow compression of SIP messages over low 768 bandwidth links. Sigcomp is not formally part of SIP. However, 769 usage of Sigcomp with SIP has required extensions to SIP. 771 RFC 3486, Compressing SIP (S): RFC 3486 [64] defines a SIP URI 772 parameter that can be used to indicate that a SIP server supports 773 Sigcomp. 775 14. SIP Service URIs 777 Several extensions define well-known services that can be invoked by 778 constructing requests with the specific structures for the Request 779 URI, resulting in specific behaviors at the UAS. 781 RFC 3087, Control of Service Context using Request URI (I): RFC 3087 782 [66] introduced the context of using Request URIs, encoded 783 appropriately, to invoke services. 785 RFC 4662, A SIP Event Notification Extension for Resource Lists (S): 786 RFC 4662 [67] defines a resource called a Resource List Server. A 787 client can send a subscribe to this server. The server will 788 generate a series of subscriptions, and compile the resulting 789 information and send it back to the subscriber. The set of 790 resources that the RLS will subscribe to is a property of the 791 request URI in the SUBSCRIBE request. 793 RFC XXXX, Subscriptions To Request-Contained Resource Lists in SIP 794 (S): RFC XXXX [68] allows a client to subscribe to a resource called 795 a Resource List Server. This server will generate a series of 796 subscriptions, and compile the resulting information and send it 797 back to the subscriber. For this specification, the list of 798 things to subscribe to is in the body of the SUBSCRIBE request. 800 RFC XXXX, Multiple-Recipient MESSAGE Requests in SIP (S): RFC XXXX 801 [69] is similar to [68]. However, instead of subscribing to the 802 resource, a MESSAGE request is sent to the resource, and it will 803 send a copy to each recipient. 805 RFC XXXX, Conference Establishment Using Request-Contained Lists in 806 SIP (S): RFC XXXX [70] is similar to [68]. However, instead of 807 subscribing to the resource, an INVITE request is sent to the 808 resource, and it will act as a conference focus and generate an 809 invitation to each recipient in the list. 811 RFC 4240, Basic Network Media Services with SIP (I): RFC 4240 [99] 812 defines a way for SIP application servers to invoke announcement 813 and conferencing services from a media server. This is 814 accomplished through a set of defined URI parameters which tell 815 the media server what to do, such as what file to play and what 816 language to render it in. 818 15. Security Mechanisms 820 Several extensions provide additional security features to SIP. 822 RFC 3853, S/MIME AES Requirement for SIP (S): RFC 3853 [71] is a 823 brief specification that updates the cryptography mechanisms used 824 in SIP S/MIME. However, SIP S/MIME has seen very little 825 deployment. 827 RFC XXXX, Certificate Management Service for The Session Initiation 828 Protocol (SIP) (S): RFC XXXX [100] defines a certificate service for 829 SIP whose purpose is to facilitate the deployment of S/MIME. The 830 certificate service allows clients to store and retrieve their own 831 certificates, in addition to obtaining the certificates for other 832 users. 834 RFC 3893, Session Initiation Protocol (SIP) Authenticated Identity 835 Body (AIB) Format (S): RFC 3893 [7] defines a SIP message fragment 836 which can be signed in order to provide an authenticated identity 837 over a request. It was an early predecessor to [19], and 838 consequently AIB has seen no deployment. 840 RFC XXXX, SIP SAML Profile and Binding (S): RFC XXXX [102] defines 841 the usage of the Security Assertion Markup Language (SAML) within 842 SIP, and describes how to use it in conjunction with SIP identity 843 [19] to provide authenticated assertions about a users role or 844 attributes. 846 RFC XXXX, A Framework for Consent-Based Communications in the Session 847 Initiation Protocol (SIP) (S): RFC XXX [101] defines several 848 extensions to SIP, including the Trigger-Consent and Permission- 849 Missing header fields. These header fields, in addition to the 850 other procedures defined in the document, define a way to manage 851 membership on "SIP mailing lists" used for instant messaging or 852 conferencing. In particular, it helps avoid the problem of using 853 such amplification services for the purposes of an attack on the 854 network, by making sure a user authorizes the addition of their 855 address onto such a service. 857 RFC XXXX, The Session Initiation Protocol (SIP) Pending Additions 858 Event Package (S): RFC XXXX [103] defines a SIP event package that 859 allows a UA to learn whether consent has been given for the 860 addition of an address to a SIP "mailing list". It is used in 861 conjunction with the SIP framework for consent [101]. 863 RFC 3329, Security Mechanism Agreement for SIP (S): RFC 3329 [72] 864 defines a mechanism to prevent bid-down attacks in conjunction 865 with SIP authentication. The mechanism has seen very limited 866 deployment. It was defined as part of the 3gpp IMS specification 867 suite [109], and is needed only when there are a multiplicity of 868 security mechanisms deployed at a particular server. In practice, 869 this has not been the case. 871 RFC XXXX, End-to-Middle Security in SIP (S): RFC XXXX [73] defines 872 mechanisms for providing confidentiality and integrity for SIP 873 message bodies sent from user agents to specific network 874 intermediaries. 876 RFC 4572, Connection-Oriented Media Transport over the Transport 877 Layer Security (TLS) Protocol in the Session Description Protocol 878 (SDP) (S): RFC 4572 [104] specifies a mechanism for signaling TLS- 879 based media streams between endpoints. It expands the TCP-based 880 media signaling parameters defined in [86] to include fingerprint 881 information for TLS streams, so that TLS can operate between end 882 hosts using self-signed certificates. 884 RFC XXXX, Security Preconditions for Session Description Protocol 885 Media Streams (S): RFC XXXX [92] defines a precondition for use with 886 the preconditions framework [59]. The security precondition 887 prevents a session from being established until a security media 888 stream is set up. 890 16. Instant Messaging, Presence and Multimedia 892 SIP provides extensions for instant messaging, presence, and 893 multimedia. 895 RFC 3428, SIP Extension for Instant Messaging (S): RFC 3428 [74] 896 defines the MESSAGE method, used for sending an instant message 897 without setting up a session (sometimes called "page mode"). 899 RFC 3856, A Presence Event Package for SIP (S): RFC 3856 [53] 900 defines an event package for indicating user presence through SIP. 902 RFC 3857, A Watcher Information Event Template Package for SIP (S): 903 RFC 3857 [54], also known as winfo, provides a mechanism for a 904 user agent to find out what subscriptions are in place for a 905 particular event package. Its primary usage is with presence, but 906 it can be used with any event package. 908 RFC XXXX, A Session Description Protocol (SDP) Offer/Answer Mechanism 909 to Enable File Transfer (S): RFC XXXX [107] defines a mechanism for 910 signaling a file transfer session with SIP. 912 17. Emergency Services 914 Emergency services here covers both emergency calling (for example, 915 911 in the United States), and pre-emption services, which allow 916 authorized individuals to gain access to network resources in time of 917 emergency. 919 RFC 4411, Extending the SIP Reason Header for Preemption Events (S): 920 RFC 4411 [75] defines an extension to the Reason header, allowing 921 a UA to know that its dialog was torn down because a higher 922 priority session came through. 924 RFC 4412, Communications Resource Priority for SIP (S): RFC 4412 925 [76] defines a new header field, Resource-Priority, that allows a 926 session to get priority treatment from the network. 928 18. Security Considerations 930 This specification is an overview of existing specifications, and 931 does not introduce any security considerations on its own. Of 932 course, the world would be far more secure if everyone would follow 933 one simple rule: "Don't Panic!" [42]. 935 19. IANA Considerations 937 None. 939 20. Acknowledgements 941 The author would like to thank Spencer Dawkins for his comments on 942 this specification. 944 21. Informative References 946 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 947 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 948 Session Initiation Protocol", RFC 3261, June 2002. 950 [2] Bradner, S., "The Internet Standards Process -- Revision 3", 951 BCP 9, RFC 2026, October 1996. 953 [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 954 "RTP: A Transport Protocol for Real-Time Applications", 955 RFC 3550, July 2003. 957 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 958 Session Description Protocol (SDP)", RFC 3264, June 2002. 960 [5] Rosenberg, J., "Interactive Connectivity Establishment (ICE): 961 A Protocol for Network Address Translator (NAT) Traversal for 962 Offer/Answer Protocols", draft-ietf-mmusic-ice-16 (work in 963 progress), June 2007. 965 [6] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, 966 Z., and J. Rosenberg, "Signaling Compression (SigComp)", 967 RFC 3320, January 2003. 969 [7] Peterson, J., "Session Initiation Protocol (SIP) Authenticated 970 Identity Body (AIB) Format", RFC 3893, September 2004. 972 [8] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. 973 Rosen, "Change Process for the Session Initiation Protocol 974 (SIP)", BCP 67, RFC 3427, December 2002. 976 [9] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, 977 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 979 [10] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 980 (SIP): Locating SIP Servers", RFC 3263, June 2002. 982 [11] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 983 specifying the location of services (DNS SRV)", RFC 2782, 984 February 2000. 986 [12] Mealling, M. and R. Daniel, "The Naming Authority Pointer 987 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 989 [13] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 990 Notification", RFC 3265, June 2002. 992 [14] Peterson, J., "A Privacy Mechanism for the Session Initiation 993 Protocol (SIP)", RFC 3323, November 2002. 995 [15] Jennings, C., Peterson, J., and M. Watson, "Private Extensions 996 to the Session Initiation Protocol (SIP) for Asserted Identity 997 within Trusted Networks", RFC 3325, November 2002. 999 [16] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 1000 (SIP) Extension Header Field for Registering Non-Adjacent 1001 Contacts", RFC 3327, December 2002. 1003 [17] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session 1004 Initiation Protocol (SIP) for Symmetric Response Routing", 1005 RFC 3581, August 2003. 1007 [18] Sparks, R., "Actions Addressing Identified Issues with the 1008 Session Initiation Protocol's (SIP) Non-INVITE Transaction", 1009 RFC 4320, January 2006. 1011 [19] Peterson, J. and C. Jennings, "Enhancements for Authenticated 1012 Identity Management in the Session Initiation Protocol (SIP)", 1013 RFC 4474, August 2006. 1015 [20] Rosenberg, J., "Obtaining and Using Globally Routable User 1016 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 1017 (SIP)", draft-ietf-sip-gruu-14 (work in progress), June 2007. 1019 [21] Jennings, C. and R. Mahy, "Managing Client Initiated 1020 Connections in the Session Initiation Protocol (SIP)", 1021 draft-ietf-sip-outbound-09 (work in progress), June 2007. 1023 [22] Petrack, S. and L. Conroy, "The PINT Service Protocol: 1024 Extensions to SIP and SDP for IP Access to Telephone Call 1025 Services", RFC 2848, June 2000. 1027 [23] Gurbani, V., Brusilovsky, A., Faynberg, I., Gato, J., Lu, H., 1028 and M. Unmehopa, "The SPIRITS (Services in PSTN requesting 1029 Internet Services) Protocol", RFC 3910, October 2004. 1031 [24] Vemuri, A. and J. Peterson, "Session Initiation Protocol for 1032 Telephones (SIP-T): Context and Architectures", BCP 63, 1033 RFC 3372, September 2002. 1035 [25] Camarillo, G., Roach, A., Peterson, J., and L. Ong, 1036 "Integrated Services Digital Network (ISDN) User Part (ISUP) 1037 to Session Initiation Protocol (SIP) Mapping", RFC 3398, 1038 December 2002. 1040 [26] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Mapping 1041 of Integrated Services Digital Network (ISDN) User Part (ISUP) 1042 Overlap Signalling to the Session Initiation Protocol (SIP)", 1043 RFC 3578, August 2003. 1045 [27] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing 1046 Tone Generation in the Session Initiation Protocol (SIP)", 1047 RFC 3960, December 2004. 1049 [28] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 1050 Responses in Session Initiation Protocol (SIP)", RFC 3262, 1051 June 2002. 1053 [29] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 1054 Method", RFC 3311, October 2002. 1056 [30] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. 1058 [31] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 1059 Header Field for the Session Initiation Protocol (SIP)", 1060 RFC 3326, December 2002. 1062 [32] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 1063 (SIP) Extension Header Field for Service Route Discovery 1064 During Registration", RFC 3608, October 2003. 1066 [33] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating 1067 User Agent Capabilities in the Session Initiation Protocol 1068 (SIP)", RFC 3840, August 2004. 1070 [34] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1071 Preferences for the Session Initiation Protocol (SIP)", 1072 RFC 3841, August 2004. 1074 [35] Donovan, S. and J. Rosenberg, "Session Timers in the Session 1075 Initiation Protocol (SIP)", RFC 4028, April 2005. 1077 [36] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The Stream 1078 Control Transmission Protocol (SCTP) as a Transport for the 1079 Session Initiation Protocol (SIP)", RFC 4168, October 2005. 1081 [37] Barnes, M., "An Extension to the Session Initiation Protocol 1082 (SIP) for Request History Information", RFC 4244, 1083 November 2005. 1085 [38] Levin, O., "Suppression of Session Initiation Protocol (SIP) 1086 REFER Method Implicit Subscription", RFC 4488, May 2006. 1088 [39] Rosenberg, J., "Request Authorization through Dialog 1089 Identification in the Session Initiation Protocol (SIP)", 1090 RFC 4538, June 2006. 1092 [40] Levin, O. and A. Johnston, "Conveying Feature Tags with the 1093 Session Initiation Protocol (SIP) REFER Method", RFC 4508, 1094 May 2006. 1096 [41] Willis, D. and A. Allen, "Requesting Answering Modes for the 1097 Session Initiation Protocol (SIP)", 1098 draft-ietf-sip-answermode-04 (work in progress), June 2007. 1100 [42] Adams, D., "The Hitchhiker's Guide to the Galaxy", 1101 September 1979. 1103 [43] Rosenberg, J., "Rejecting Anonymous Requests in the Session 1104 Initiation Protocol (SIP)", draft-ietf-sip-acr-code-04 (work 1105 in progress), March 2007. 1107 [44] Camarillo, G., "Referring to Multiple Resources in the Session 1108 Initiation Protocol (SIP)", draft-ietf-sip-multiple-refer-01 1109 (work in progress), January 2007. 1111 [45] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1112 Method", RFC 3515, April 2003. 1114 [46] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 1115 Camarillo, "Best Current Practices for Third Party Call 1116 Control (3pcc) in the Session Initiation Protocol (SIP)", 1117 BCP 85, RFC 3725, April 2004. 1119 [47] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1120 Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. 1122 [48] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By 1123 Mechanism", RFC 3892, September 2004. 1125 [49] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) 1126 "Join" Header", RFC 3911, October 2004. 1128 [50] Camarillo, G., Burger, E., Schulzrinne, H., and A. van Wijk, 1129 "Transcoding Services Invocation in the Session Initiation 1130 Protocol (SIP) Using Third Party Call Control (3pcc)", 1131 RFC 4117, June 2005. 1133 [51] Niemi, A., "Session Initiation Protocol (SIP) Extension for 1134 Event State Publication", RFC 3903, October 2004. 1136 [52] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 1137 Package for Registrations", RFC 3680, March 2004. 1139 [53] Rosenberg, J., "A Presence Event Package for the Session 1140 Initiation Protocol (SIP)", RFC 3856, August 2004. 1142 [54] Rosenberg, J., "A Watcher Information Event Template-Package 1143 for the Session Initiation Protocol (SIP)", RFC 3857, 1144 August 2004. 1146 [55] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 1147 Initiated Dialog Event Package for the Session Initiation 1148 Protocol (SIP)", RFC 4235, November 2005. 1150 [56] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 1151 Initiation Protocol (SIP) Event Package for Conference State", 1152 RFC 4575, August 2006. 1154 [57] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) 1155 Event Package for Key Press Stimulus (KPML)", RFC 4730, 1156 November 2006. 1158 [58] Pendleton, A., "Session Initiation Protocol Package for Voice 1159 Quality Reporting Event", draft-ietf-sipping-rtcp-summary-02 1160 (work in progress), May 2007. 1162 [59] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of 1163 Resource Management and Session Initiation Protocol (SIP)", 1164 RFC 3312, October 2002. 1166 [60] Camarillo, G. and P. Kyzivat, "Update to the Session 1167 Initiation Protocol (SIP) Preconditions Framework", RFC 4032, 1168 March 2005. 1170 [61] Marshall, W., "Private Session Initiation Protocol (SIP) 1171 Extensions for Media Authorization", RFC 3313, January 2003. 1173 [62] Petrie, D. and S. Channabasappa, "A Framework for Session 1174 Initiation Protocol User Agent Profile Delivery", 1175 draft-ietf-sipping-config-framework-12 (work in progress), 1176 June 2007. 1178 [63] Petrie, D., "Extensions to the Session Initiation Protocol 1179 (SIP) User Agent Profile Delivery Change Notification Event 1180 Package for the Extensible Markup Language Language 1181 Configuration Access Protocol (XCAP)", 1182 draft-ietf-sip-xcap-config-00 (work in progress), 1183 October 2006. 1185 [64] Camarillo, G., "Compressing the Session Initiation Protocol 1186 (SIP)", RFC 3486, February 2003. 1188 [65] Foster, M., McGarry, T., and J. Yu, "Number Portability in the 1189 Global Switched Telephone Network (GSTN): An Overview", 1190 RFC 3482, February 2003. 1192 [66] Campbell, B. and R. Sparks, "Control of Service Context using 1193 SIP Request-URI", RFC 3087, April 2001. 1195 [67] Roach, A., Campbell, B., and J. Rosenberg, "A Session 1196 Initiation Protocol (SIP) Event Notification Extension for 1197 Resource Lists", RFC 4662, August 2006. 1199 [68] Camarillo, G., "Subscriptions to Request-Contained Resource 1200 Lists in the Session Initiation Protocol (SIP)", 1201 draft-ietf-sip-uri-list-subscribe-01 (work in progress), 1202 January 2007. 1204 [69] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient 1205 MESSAGE Requests in the Session Initiation Protocol (SIP)", 1206 draft-ietf-sip-uri-list-message-01 (work in progress), 1207 January 2007. 1209 [70] Camarillo, G. and A. Johnston, "Conference Establishment Using 1210 Request-Contained Lists in the Session Initiation Protocol 1211 (SIP)", draft-ietf-sip-uri-list-conferencing-01 (work in 1212 progress), January 2007. 1214 [71] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 1215 Requirement for the Session Initiation Protocol (SIP)", 1216 RFC 3853, July 2004. 1218 [72] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. 1219 Haukka, "Security Mechanism Agreement for the Session 1220 Initiation Protocol (SIP)", RFC 3329, January 2003. 1222 [73] Ono, K. and S. Tachimoto, "End-to-middle Security in the 1223 Session Initiation Protocol (SIP)", draft-ietf-sip-e2m-sec-05 1224 (work in progress), March 2007. 1226 [74] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 1227 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1228 Instant Messaging", RFC 3428, December 2002. 1230 [75] Polk, J., "Extending the Session Initiation Protocol (SIP) 1231 Reason Header for Preemption Events", RFC 4411, February 2006. 1233 [76] Schulzrinne, H. and J. Polk, "Communications Resource Priority 1234 for the Session Initiation Protocol (SIP)", RFC 4412, 1235 February 2006. 1237 [77] Rosenberg, J., "A Framework for Application Interaction in the 1238 Session Initiation Protocol (SIP)", 1239 draft-ietf-sipping-app-interaction-framework-05 (work in 1240 progress), July 2005. 1242 [78] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1243 Description Protocol", RFC 4566, July 2006. 1245 [79] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, 1246 "Grouping of Media Lines in the Session Description Protocol 1247 (SDP)", RFC 3388, December 2002. 1249 [80] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 1250 Session Description Protocol (SDP)", RFC 3605, October 2003. 1252 [81] Elwell, J., "Connected Identity in the Session Initiation 1253 Protocol (SIP)", RFC 4916, June 2007. 1255 [82] Sparks, R., "Addressing an Amplification Vulnerability in 1256 Session Initiation Protocol (SIP) Forking Proxies", 1257 draft-ietf-sip-fork-loop-fix-05 (work in progress), 1258 March 2007. 1260 [83] Camarillo, G., "The Early Session Disposition Type for the 1261 Session Initiation Protocol (SIP)", RFC 3959, December 2004. 1263 [84] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., 1264 Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG 1265 Objects", RFC 3204, December 2001. 1267 [85] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 1268 November 2002. 1270 [86] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the 1271 Session Description Protocol (SDP)", RFC 4145, September 2005. 1273 [87] Camarillo, G. and J. Rosenberg, "The Alternative Network 1274 Address Types (ANAT) Semantics for the Session Description 1275 Protocol (SDP) Grouping Framework", RFC 4091, June 2005. 1277 [88] Rosenberg, J., "TCP Candidates with Interactive Connectivity 1278 Establishment (ICE", draft-ietf-mmusic-ice-tcp-03 (work in 1279 progress), March 2007. 1281 [89] Burger, E., "A Mechanism for Content Indirection in Session 1282 Initiation Protocol (SIP) Messages", RFC 4483, May 2006. 1284 [90] Westerlund, M., "A Transport Independent Bandwidth Modifier 1285 for the Session Description Protocol (SDP)", RFC 3890, 1286 September 2004. 1288 [91] Camarillo, G., "Session Description Protocol (SDP) Format for 1289 Binary Floor Control Protocol (BFCP) Streams", RFC 4583, 1290 November 2006. 1292 [92] Andreasen, F. and D. Wing, "Security Preconditions for Session 1293 Description Protocol (SDP) Media Streams", 1294 draft-ietf-mmusic-securityprecondition-03 (work in progress), 1295 October 2006. 1297 [93] Andreasen, F., "Connectivity Preconditions for Session 1298 Description Protocol Media Streams", 1299 draft-ietf-mmusic-connectivity-precon-02 (work in progress), 1300 June 2006. 1302 [94] Hautakorpi, J. and G. Camarillo, "The Session Description 1303 Protocol (SDP) Content Attribute", RFC 4796, February 2007. 1305 [95] Levin, O. and G. Camarillo, "The Session Description Protocol 1306 (SDP) Label Attribute", RFC 4574, August 2006. 1308 [96] Hilt, V. and G. Camarillo, "A Session Initiation Protocol 1309 (SIP) Event Package for Session-Specific Session Policies.", 1310 draft-ietf-sipping-policy-package-03 (work in progress), 1311 February 2007. 1313 [97] Camarillo, G. and A. Monrad, "Mapping of Media Streams to 1314 Resource Reservation Flows", RFC 3524, April 2003. 1316 [98] Lawrence, S., "Diagnostic Responses for Session Initiation 1317 Protocol Hop Limit Errors", 1318 draft-ietf-sip-hop-limit-diagnostics-03 (work in progress), 1319 June 2006. 1321 [99] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media 1322 Services with SIP", RFC 4240, December 2005. 1324 [100] Jennings, C., "Certificate Management Service for The Session 1325 Initiation Protocol (SIP)", draft-ietf-sip-certs-03 (work in 1326 progress), March 2007. 1328 [101] Rosenberg, J., "A Framework for Consent-Based Communications 1329 in the Session Initiation Protocol (SIP)", 1330 draft-ietf-sip-consent-framework-01 (work in progress), 1331 November 2006. 1333 [102] Tschofenig, H., "SIP SAML Profile and Binding", 1334 draft-ietf-sip-saml-02 (work in progress), May 2007. 1336 [103] Camarillo, G., "The Session Initiation Protocol (SIP) Pending 1337 Additions Event Package", 1338 draft-ietf-sipping-pending-additions-02 (work in progress), 1339 April 2007. 1341 [104] Lennox, J., "Connection-Oriented Media Transport over the 1342 Transport Layer Security (TLS) Protocol in the Session 1343 Description Protocol (SDP)", RFC 4572, July 2006. 1345 [105] Andreasen, F., "SDP Capability Negotiation", 1346 draft-ietf-mmusic-sdp-capability-negotiation-05 (work in 1347 progress), March 2007. 1349 [106] Andreasen, F., "SDP media capabilities Negotiation", 1350 draft-ietf-mmusic-sdp-media-capabilities-01 (work in 1351 progress), February 2007. 1353 [107] Garcia-Martin, M., "A Session Description Protocol (SDP) 1354 Offer/Answer Mechanism to Enable File Transfer", 1355 draft-ietf-mmusic-file-transfer-mech-03 (work in progress), 1356 June 2007. 1358 [108] Rosenberg, J., "Indicating Support for Interactive 1359 Connectivity Establishment (ICE) in the Session Initiation 1360 Protocol (SIP)", draft-ietf-sip-ice-option-tag-02 (work in 1361 progress), June 2007. 1363 [109] 3GPP, "Internet Protocol (IP) multimedia call control protocol 1364 based on Session Initiation Protocol (SIP) and Session 1365 Description Protocol (SDP); Stage 3", 3GPP TS 24.229 5.19.0, 1366 June 2007. 1368 [110] Froment, T. and C. Lebel, "Addressing Record-Route issues in 1369 the Session Initiation Protocol (SIP)", 1370 draft-ietf-sip-record-route-fix-00 (work in progress), 1371 July 2007. 1373 [111] Niemi, A., "An Extension to Session Initiation Protocol (SIP) 1374 Events for Conditional Event Notification", 1375 draft-ietf-sip-subnot-etags-00 (work in progress), May 2007. 1377 [112] Audet, F., "The use of the SIPS URI Scheme in the Session 1378 Initiation Protocol (SIP)", draft-ietf-sip-sips-05 (work in 1379 progress), June 2007. 1381 Author's Address 1383 Jonathan Rosenberg 1384 Cisco 1385 Edison, NJ 1386 US 1388 Email: jdrosen@cisco.com 1389 URI: http://www.jdrosen.net 1391 Full Copyright Statement 1393 Copyright (C) The IETF Trust (2007). 1395 This document is subject to the rights, licenses and restrictions 1396 contained in BCP 78, and except as set forth therein, the authors 1397 retain all their rights. 1399 This document and the information contained herein are provided on an 1400 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1401 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1402 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1403 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1404 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1405 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1407 Intellectual Property 1409 The IETF takes no position regarding the validity or scope of any 1410 Intellectual Property Rights or other rights that might be claimed to 1411 pertain to the implementation or use of the technology described in 1412 this document or the extent to which any license under such rights 1413 might or might not be available; nor does it represent that it has 1414 made any independent effort to identify any such rights. Information 1415 on the procedures with respect to rights in RFC documents can be 1416 found in BCP 78 and BCP 79. 1418 Copies of IPR disclosures made to the IETF Secretariat and any 1419 assurances of licenses to be made available, or the result of an 1420 attempt made to obtain a general license or permission for the use of 1421 such proprietary rights by implementers or users of this 1422 specification can be obtained from the IETF on-line IPR repository at 1423 http://www.ietf.org/ipr. 1425 The IETF invites any interested party to bring to its attention any 1426 copyrights, patents or patent applications, or other proprietary 1427 rights that may cover technology that may be required to implement 1428 this standard. Please address the information to the IETF at 1429 ietf-ipr@ietf.org. 1431 Acknowledgment 1433 Funding for the RFC Editor function is provided by the IETF 1434 Administrative Support Activity (IASA).