idnits 2.17.1 draft-ietf-sip-hitchhikers-guide-01.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1311. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1288. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1295. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1301. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 17, 2006) is 6401 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-11 -- 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-10 == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-04 -- 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-01 == Outdated reference: A later version (-05) exists of draft-ietf-sip-acr-code-03 == Outdated reference: A later version (-03) exists of draft-ietf-sip-multiple-refer-00 -- Obsolete informational reference (is this intentional?): RFC 4325 (ref. '55') (Obsoleted by RFC 5280) == Outdated reference: A later version (-13) exists of draft-ietf-sipping-rtcp-summary-01 == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-09 == Outdated reference: A later version (-02) exists of draft-ietf-sip-uri-list-subscribe-00 == Outdated reference: A later version (-03) exists of draft-ietf-sip-uri-list-message-00 == Outdated reference: A later version (-02) exists of draft-ietf-sip-uri-list-conferencing-00 == Outdated reference: A later version (-06) exists of draft-ietf-sip-e2m-sec-03 -- 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 (-05) exists of draft-ietf-sip-connected-identity-02 == Outdated reference: A later version (-08) exists of draft-ietf-sip-fork-loop-fix-03 -- 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-01 == Outdated reference: A later version (-04) exists of draft-ietf-mmusic-securityprecondition-02 == 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-01 == Outdated reference: A later version (-15) exists of draft-ietf-sip-certs-01 == Outdated reference: A later version (-04) exists of draft-ietf-sip-consent-framework-00 == Outdated reference: A later version (-08) exists of draft-ietf-sip-saml-00 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-pending-additions-00 -- Obsolete informational reference (is this intentional?): RFC 4572 (ref. '104') (Obsoleted by RFC 8122) Summary: 3 errors (**), 0 flaws (~~), 24 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 Systems 4 Expires: April 20, 2007 October 17, 2006 6 A Hitchhikers Guide to the Session Initiation Protocol (SIP) 7 draft-ietf-sip-hitchhikers-guide-01 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 20, 2007. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 The Session Initiation Protocol (SIP) is the subject of numerous 41 specifications that have been produced by the IETF. It can be 42 difficult to locate the right document, or even to determine the set 43 of Request for Comments (RFC) about SIP. Don't Panic! This 44 specification serves as a guide to the SIP RFC series. It lists the 45 specifications under the SIP umbrella, briefly summarizes each, and 46 groups them into categories. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Scope of this Document . . . . . . . . . . . . . . . . . . . . 3 52 3. Core SIP Specifications . . . . . . . . . . . . . . . . . . . 4 53 4. Public Switched Telephone Network (PSTN) Interworking . . . . 7 54 5. General Purpose Infrastructure Extensions . . . . . . . . . . 8 55 6. Minor Extensions . . . . . . . . . . . . . . . . . . . . . . . 10 56 7. Conferencing . . . . . . . . . . . . . . . . . . . . . . . . . 12 57 8. Call Control Primitives . . . . . . . . . . . . . . . . . . . 12 58 9. Event Framework and Packages . . . . . . . . . . . . . . . . . 13 59 10. Quality of Service . . . . . . . . . . . . . . . . . . . . . . 15 60 11. Operations and Management . . . . . . . . . . . . . . . . . . 15 61 12. SIP Compression . . . . . . . . . . . . . . . . . . . . . . . 16 62 13. SIP Service URIs . . . . . . . . . . . . . . . . . . . . . . . 16 63 14. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 17 64 15. Instant Messaging and Presence . . . . . . . . . . . . . . . . 19 65 16. Emergency Services . . . . . . . . . . . . . . . . . . . . . . 19 66 17. Security Considerations . . . . . . . . . . . . . . . . . . . 19 67 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 68 19. Informative References . . . . . . . . . . . . . . . . . . . . 20 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 70 Intellectual Property and Copyright Statements . . . . . . . . . . 30 72 1. Introduction 74 The Session Initiation Protocol (SIP) [1] is the subject of numerous 75 specifications that have been produced by the IETF. It can be 76 difficult to locate the right document, or even to determine the set 77 of Request for Comments (RFC) about SIP. Don't Panic! [42] This 78 specification serves as a guide to the SIP RFC series. It lists the 79 specifications under the SIP umbrella. For each specification, a 80 paragraph or so description is included that summarizes the purpose 81 of the specification. Each specification also includes a letter that 82 designates its category in the standards track [2]. These values 83 are: 85 S: Standards Track (Proposed Standard, Draft Standard, or Standard) 87 E: Experimental 89 B: Best Current Practice 91 I: Informational 93 The specifications are grouped together by topic. Typically, SIP 94 extensions fit naturally into topic areas, and implementations 95 interested in a particular topic often implement many or all of the 96 specifications in that area. There are some specifications which 97 fall into multiple topic areas, in which case they are listed more 98 than once. 100 This document itself is not an update to RFC 3261 or an extension to 101 SIP. It is an informational document, meant to guide newcomers and 102 implementors to the SIP suite of specifications. 104 2. Scope of this Document 106 It is very difficult to enumerate the set of SIP specifications. 107 This is because there are many protocols that are intimately related 108 to SIP and used by nearly all SIP implementations, but are not 109 formally SIP extensions. As such, this document formally defines a 110 "SIP specification" as: 112 o Any specification that defines an extension to SIP itself, where 113 an extension is a mechanism that changes or updates in some way a 114 behavior specified in RFC 3261 116 o Any specification that defines an extension to SDP whose primary 117 purpose is to support SIP 119 o Any specification that defines a MIME object whose primary purpose 120 is to support SIP 122 Excluded from this list are requirements, architectures, registry 123 definitions, non-normative frameworks, and processes. Best Current 124 Practices are included when they are effectively standard mechanisms 125 for accomplishing a task. 127 The SIP change process [8] defines two types of extensions to SIP. 128 These are normal extensions and the so-called P-headers, which are 129 meant to be used in areas of limited applicability. P-headers cannot 130 be defined in the standards track. For the most part, P-headers are 131 not included in the listing here, with the exception of those which 132 have seen general usage despite their P-header status. 134 3. Core SIP Specifications 136 The core SIP specifications represent the set of specifications whose 137 functionality is broadly applicable. An extension is broadly 138 applicable if it fits into one of the following categories: 140 o For specifications that impact SIP session management, the 141 extension would be used for almost every session initiated by a 142 user agent 144 o For specifications that impact SIP registrations, the extension 145 would be used for almost every registration initiated by a user 146 agent 148 o For specifications that impact SIP subscriptions, the extension 149 would be used for almost every subscription initiated by a user 150 agent 152 In other words, these are not specifications that are used just for 153 some requests and not others; they are specifications that would 154 apply to each and every request that the extension is relevant for. 155 In the galaxy of SIP, these specifications are like towels [42]. 157 RFC 3261, The Session Initiation Protocol (S): RFC 3261 [1] is the 158 core SIP protocol itself. RFC 3261 is an update to RFC 2543 [9]. 159 It is the president of the galaxy [42] as far as the suite of SIP 160 specifications is concerned. 162 RFC 3263, Locating SIP Servers (S): RFC 3263 [10] provides DNS 163 procedures for taking a SIP URI, and determining a SIP server that 164 is associated with that SIP URI. RFC 3263 is essential for any 165 implementation using SIP with DNS. RFC 3263 makes use of both DNS 166 SRV records [11] and NAPTR records [12]. 168 RFC 3264, An Offer/Answer Model with the Session Description Protocol 169 (S): RFC 3264 [4] defines how the Session Description Protocol (SDP) 170 [78] is used with SIP to negotiate the parameters of a media 171 session. It is in widespread usage and an integral part of the 172 behavior of RFC 3261. 174 RFC 3265, SIP-Specific Event Notification (S): RFC 3265 [13] defines 175 the SUBSCRIBE and NOTIFY methods. These two methods provide a 176 general event notification framework for SIP. To actually use the 177 framework, extensions need to be defined for specific event 178 packages. An event package defines a schema for the event data, 179 and describes other aspects of event processing specific to that 180 schema. An RFC 3265 implementation is required when any event 181 package is used. 183 RFC 3325, Private Extensions to SIP for Asserted Identity within 184 Trusted Networks (I): Though its P-header status implies that it has 185 limited applicability, RFC 3325 [15], which defines the 186 P-Asserted-ID header field has been widely deployed. It is used 187 as the basic mechanism for providing secure caller ID services. 189 RFC 3327, SIP Extension Header Field for Registering Non-Adjacent 190 Contacts (S): RFC 3327 [16] defines the Path header field. This 191 field is inserted by proxies between a client and their registrar. 192 It allows inbound requests towards that client to traverse these 193 proxies prior to being delivered to the user agent. It is 194 essential in any SIP deployment that has edge proxies, which are 195 proxies between the client and the home proxy or SIP registrar. 196 It is also instrumental in the SIP NAT traversal specifications. 198 RFC 3581, An Extension to SIP for Symmetric Response Routing (S): RFC 199 3581 [17] defines the rport parameter of the Via header. It is an 200 essential piece of getting SIP through NAT. NAT traversal for SIP 201 is considered a core part of the specifications. 203 RFC 3840, Indicating User Agent Capabilities in SIP (S): RFC 3840 204 [33] defines a mechanism for carrying capability information about 205 a user agent in REGISTER requests and in dialog-forming requests 206 like INVITE. It has found use with conferencing (the isfocus 207 parameter declares that a user agent is a conference server) and 208 with applications like push-to-talk. 210 RFC 4320, Actions Addressing Issues Identified with the Non-INVITE 211 Transaction in SIP (S): RFC 4320 [18] formally updates RFC 3261, and 212 modifies some of the behaviors associated with non-INVITE 213 transactions. These address some problems found in timeout and 214 failure cases. 216 RFC 4474, Enhancements for Authenticated Identity Management in SIP 217 (S): RFC 4474 [19] defines a mechanism for providing a 218 cryptographically verifiable identity of the calling party in a 219 SIP request. Also known as "SIP Identity", this mechanism 220 provides an alternative to RFC 3325. It has seen little 221 deployment so far, but its importance as a key construct for 222 almost also anti-spam techniques makes it a core part of the SIP 223 specifications. 225 RFC XXXX, Obtaining and Using Globally Routable User Agent 226 Identifiers (GRUU) in SIP (S): RFC XXXX [20] defines a mechanism for 227 directing requests towards a specific UA instance. GRUU is 228 essential for features like transfer and provides another piece of 229 the SIP NAT traversal story. 231 RFC XXXX, Managing Client Initiated Connections through SIP (S): RFC 232 XXXX [21], also known as SIP outbound, defines important changes 233 to the SIP registration mechanism which enable delivery of SIP 234 messages towards a UA when it is behind a NAT. This specification 235 is the cornerstone of the SIP NAT traversal strategy. 237 RFC 4566, Session Description Protocol (S): RFC 4566 [78] defines a 238 format for representing multimedia sessions. SDP objects are 239 carried in the body of SIP messages, and based on the offer/answer 240 model, are used to negotiate the media characteristics of a 241 session between users. 243 RFC 3388, Grouping of Media Lines in the Session Description Protocol 244 (S): RFC 3388 [79] defines a framework for grouping together media 245 streams in an SDP message. Such a grouping allows relationships 246 between these streams, such as which stream is the audio for a 247 particular video feed, to be expressed. 249 RFC XXXX, Interactive Connectivity Establishment (ICE) (S): RFC XXXX 250 [5] defines a technique for NAT traversal of media sessions for 251 protocols that make use of the offer/answer model. This 252 specification is the IETF recommended mechanism for NAT traversal 253 for SIP media streams, and is meant to be used even by endpoints 254 which are themselves never behind a NAT. 256 RFC 3605, Real Time Control Protocol (RTCP) Attribute in the Session 257 Description Protocol (SDP) (S): RFC 3605 [80] defines a way to 258 explicitly signal, within an SDP message, the IP address and port 259 for RTCP, rather than using the port+1 rule in the Real Time 260 Transport Protocol (RTP) [3]. It is needed for devices behind NAT 261 and used by ICE. 263 RFC XXXX, Connected Identity in the Session Initiation Protocol (SIP) 264 (S): RFC XXXX [81] defines an extension to SIP that allows a UAC to 265 determine the identity of the UAS. Due to forwarding and 266 retargeting services, this may not be the same as the user that 267 the UAC was originally trying to reach. The mechanism works in 268 tandem with the SIP identity specification [19] to provide 269 signatures over the connected party identity. 271 RFC XXXX, Addressing an Amplification Vulnerability in Forking 272 Proxies (S): RFC XXXX [82] makes a small normative change to RFC 273 3261, requiring loop detection in any proxy that forks a request. 274 It addresses a vulnerability uncovered in RFC 3261. 276 4. Public Switched Telephone Network (PSTN) Interworking 278 Numerous extensions and usages of SIP related to interoperability and 279 communications with or through the PSTN. 281 RFC 2848, The PINT Service Protocol (S): RFC 2848 [22] is one of the 282 earliest extensions to SIP. It defines procedures for using SIP 283 to invoke services that actually execute on the PSTN. Its main 284 application is for third party call control, allowing an IP host 285 to set up a call between two PSTN endpoints. PINT has a 286 relatively narrow focus and has not seen widespread deployment. 288 RFC 3910, The SPIRITS Protocol (S): Continuing the trend of naming 289 PSTN related extensions with alcohol references, SPIRITS [23] 290 defines the inverse of PINT. It allows a switch in the PSTN to 291 ask an IP element about how to proceed with call waiting. It was 292 developed primarily to support Internet Call Waiting (ICW). 293 Perhaps the next specification will be called the Pan Galactic 294 Gargle Blaster [42]. 296 RFC 3372, SIP for Telephones (SIP-T): Context and Architectures 297 (I): SIP-T [24] defines a mechanism for using SIP between pairs of 298 PSTN gateways. Its essential idea is to tunnel ISUP signaling 299 between the gateways in the body of SIP messages. SIP-T motivated 300 the development of INFO [30]. SIP-T has seen widespread 301 implementation. 303 RFC 3398, ISUP to SIP Mapping (S): RFC 3398 [25] defines how to do 304 protocol mapping from the SS7 ISDN User Part (ISUP) signaling to 305 SIP. It is widely used in SS7 to SIP gateways and is part of the 306 SIP-T framework. 308 RFC 3578, Mapping of ISUP Overlap Signaling to SIP (S): RFC 3578 [26] 309 defines a mechanism to map overlap dialing into SIP. This 310 specification is widely regarded as the ugliest SIP specification, 311 as the introduction to the specification itself advises that it 312 has many problems. Overlap signaling (the practice of sending 313 digits into the network as dialed instead of waiting for complete 314 collection of the called party number) is largely incompatible 315 with SIP at some fairly fundamental levels. That said, RFC 3578 316 is mostly harmless and has seen some usage. 318 RFC 3960, Early Media and Ringtone Generation in SIP (I): RFC 3960 319 [27] defines some guidelines for handling early media - the 320 practice of sending media from the called party towards the caller 321 - prior to acceptance of the call. Early media is generated only 322 from the PSTN. 324 RFC 3959, Early Session Disposition Type for the Session Initiation 325 Protocol (SIP) (S): RFC 3959 [83] defines a new session disposition 326 type for use with early media. It indicates that the SDP in the 327 body is for a special early media session. 329 RFC 3204, MIME Media Types for ISUP and QSIG Objects (S): RFC 3204 330 [84] defines MIME objects for representing SS7 signaling messages. 331 These are carried in the body of SIP messages when SIP-T is used. 333 5. General Purpose Infrastructure Extensions 335 These extensions are general purpose enhancements to SIP, SDP and 336 MIME that can serve a wide variety of uses. However, they are not as 337 widely used or as essential as the core specifications. 339 RFC 3262, Reliability of Provisional Responses in SIP (S): SIP 340 defines two types of responses to a request - final and 341 provisional. Provisional responses are numbered from 100 to 199. 342 In SIP, these responses are not sent reliably. This choice was 343 made in RFC 2543 since the messages were meant to just be truly 344 informational, and rendered to the user. However, subsequent work 345 on PSTN interworking demonstrated a need to map provisional 346 responses to PSTN messages that needed to be sent reliably. RFC 347 3262 [28] was developed to allow reliability of provisional 348 responses. The specification defines the PRACK method, used for 349 indicating that a provisional response was received. Though it 350 provides a generic capability for SIP, RFC 3262 implementations 351 have been most common in PSTN interworking devices. However, 352 PRACK brings a great deal of complication for relatively small 353 benefit. As such, it has seen only mild levels of deployment. 355 RFC 3323, A Privacy Mechanism for the Session Initiation Protocol 356 (SIP) (S): RFC 3323 [14] defines the Privacy header field, used by 357 clients to request anonymity for their requests. Though it 358 defines numerous privacy services, the only one broadly used is 359 the one that supports privacy of the P-Asserted-ID header field 360 [15]. 362 RFC 3311, The SIP UPDATE Method (S): RFC 3311 [29] defines the UPDATE 363 method for SIP. This method is meant as a means for updating 364 session information prior to the completion of the initial INVITE 365 transaction. It was developed primarily to support RFC 3312 [59]. 367 RFC 2976, The INFO Method (S): RFC 2976 [30] was defined as an 368 extension to RFC 2543. It defines a method, INFO, used to 369 transport mid-dialog information that has no impact on SIP itself. 370 Its driving application was the transport of PSTN related 371 information when using SIP between a pair of gateways. Though 372 originally conceived for broader use, it only found standardized 373 usage with SIP-T [24]. It has been used to support numerous 374 proprietary and non-interoperable extensions due to its poorly 375 defined scope. 377 RFC 3326, The Reason header field for SIP (S): RFC 3326 [31] defines 378 the Reason header field. It is used in requests, such as BYE, to 379 indicate the reason that the request is being sent. 381 RFC 3420, Internet Media Type message/sipfrag (S): RFC 3420 [85] 382 defines a MIME object that contains a SIP message fragment. Only 383 certain header fields and parts of the SIP message are present. 384 For example, it is used to report back on the responses received 385 to a request sent as a consequence of a REFER. 387 RFC 3608, SIP Extension Header Field for Service Route Discovery 388 During Registration (S): RFC 3608 [32] allows a client to determine, 389 from a REGISTER response, a path of proxies to use in requests it 390 sends outside of a dialog. In many respects, it is the inverse of 391 the Path header field, but has seen less usage since default 392 outbound proxies have been sufficient in many deployments. 394 RFC 3841, Caller Preferences for SIP (S): RFC 3841 [34] defines a set 395 of headers that a client can include in a request to control the 396 way in which the request is routed downstream. It allows a client 397 to direct a request towards a UA with specific capabilities. 399 RFC 4028, Session Timers in SIP (S): RFC 4028 [35] defines a 400 keepalive mechanism for SIP signaling. It is primarily meant to 401 provide a way to cleanup old state in proxies that are holding 402 call state for calls from failed endpoints which were never 403 terminated normally. Despite its name, the session timer is not a 404 mechanism for detecting a network failure mid-call. Session 405 timers introduces a fair bit of complexity for relatively little 406 gain, and has thus seen little deployment. 408 RFC 4168, SCTP as a Transport for SIP (S): RFC 4168 [36] defines how 409 to carry SIP messages over the Stream Control Transmission 410 Protocol (SCTP). SCTP has seen very limited usage for SIP 411 transport. 413 RFC 4244, An Extension to SIP for Request History Information 414 (S): RFC 4244 [37] defines the History-Info header field, which 415 indicates information on how a call came to be routed to a 416 particular destination. Its primary application was in support of 417 voicemail services. 419 RFC 4145, TCP-Based Media Transport in the Session Description 420 Protocol (SDP) (S): RFC 4145 [86] defines an extension to SDP for 421 setting up TCP-based sessions between user agents. It defines who 422 sets up the connection and how its lifecycle is managed. It has 423 seen relatively little usage due to the small number of media 424 types to date which use TCP. 426 RFC 4091, The Alternative Network Address Types (ANAT) Semantics for 427 the Session Description Protocol (SDP) Grouping Framework (S): RFC 428 4091 [87] defines a mechanism for including both IPv4 and IPv6 429 addresses for a media session as alternates. 431 RFC XXXX, TCP Candidates with Interactive Connectivity Establishment 432 (ICE) (S): RFC XXXX [88] specifies the usage of ICE for TCP streams. 433 This allows for selection of RTP-based voice ontop of TCP only 434 when NAT or firewalls would prevent UDP-based voice from working. 436 6. Minor Extensions 438 These SIP extensions don't fit easily into a single specific use 439 case. They have somewhat general applicability, but they solve a 440 relatively small problem or provide an optimization. 442 RFC 4488, Suppression of the SIP REFER Implicit Subscription (S): RFC 443 4488 [38] defines an enhancement to REFER. REFER normally creates 444 an implicit subscription to the target of the REFER. This 445 subscription is used to pass back updates on the progress of the 446 referral. This extension allows that implicit subscription to be 447 bypassed as an optimization. 449 RFC 4538, Request Authorization through Dialog Identification in SIP 450 (S): RFC 4538 [39] provides a mechanism that allows a UAS to 451 authorize a request because the requestor proves it knows a dialog 452 that is in progress with the UAS. The specification is useful in 453 conjunction with the SIP application interaction framework [77]. 455 RFC 4508, Conveying Feature Tags with the REFER Method in SIP 456 (S): RFC 4508 [40] defines a mechanism for carrying RFC 3840 457 feature tags in REFER. It is useful for informing the target of 458 the REFER about the characteristics of the REFER target. 460 RFC XXXX, Requesting Answer Modes for SIP (S): RFC XXXX [41] defines 461 an extension for indicating to the called party whether or not the 462 phone should ring and/or be answered immediately. This is useful 463 for push-to-talk and for diagnostic applications. 465 RFC XXXX, Rejecting Anonymous Requests in SIP (S): RFC XXXX [43] 466 defines a mechanism for a called party to indicate to the calling 467 party that a call was rejected since the caller was anonymous. 468 This is needed for implementation of the Anonymous Call Rejection 469 (ACR) feature in SIP. 471 RFC XXXX, Referring to Multiple Resources in SIP (S): RFC XXXX [44] 472 allows a UA sending a REFER to ask the recipient of the REFER to 473 generate multiple SIP requests, not just one. This is useful for 474 conferencing, where a client would like to ask a conference server 475 to eject multiple users. 477 RFC 4483, A Mechanism for Content Indirection in Session Initiation 478 Protocol (SIP) Messages (S): RFC 4483 [89] defines a mechanism for 479 content indirection. Instead of carrying an object within a SIP 480 body, a URL reference is carried instead, and the recipient 481 dereferences the URL to obtain the object. The specification has 482 potential applicability for sending large instant messages, but 483 has yet to find much actual use. 485 RFC 3890, A Transport Independent Bandwidth Modifier for the Session 486 Description Protocol (SDP) (S): RFC 3890 [90] specifies an SDP 487 extension that allows for the description of the bandwidth for a 488 media session that is independent of the underlying transport 489 mechanism. It has seen relatively little usage. 491 RFC XXXX, Session Description Protocol (SDP) Format for Binary Floor 492 Control Protocol (BFCP) Streams (S): RFC XXXX [91] defines a 493 mechanism in SDP to signal floor control streams that use BFCP. 494 It is used for Push-To-Talk and conference floor control. 496 RFC XXXX, Connectivity Preconditions for Session Description Protocol 497 Media Streams (S): RFC XXXX [93] defines a usage of the precondition 498 framework [59]. The connectivity precondition makes sure that the 499 session doesn't get established until actual packet connectivity 500 is checked. 502 RFC XXXX, The SDP (Session Description Protocol) Content Attribute 503 (S): RFC XXXX [94] defines an SDP attribute for describing the 504 purpose of a media stream. Examples include a slide view, the 505 speaker, a sign language feed, and so on. 507 7. Conferencing 509 Numerous SIP and SDP extensions are aimed at conferencing as their 510 primary application. 512 RFC 4574, The SDP (Session Description Protocol) Label Attribute 513 (S): RFC 4574 [95] defines an SDP attribute for providing an opaque 514 label for media streams. These labels can be referred to by 515 external documents, and in particular, by conference policy 516 documents. This allows a UA to tie together documents it may 517 obtain through conferencing mechanisms to media streams to which 518 they refer. 520 RFC 3911, The SIP Join Header Field (S): RFC 3911 [49] defines the 521 Join header field. When sent in an INVITE, it causes the 522 recipient to join the resulting dialog into a conference with 523 another dialog in progress. 525 RFC 4575, A SIP Event Package for Conference State (S): RFC 4575 [56] 526 defines a mechanism for learning about changes in conference 527 state, including group membership. 529 RFC XXXX, Conference Establishment Using Request-Contained Lists in 530 SIP (S): RFC XXXX [70] is similar to [68]. However, instead of 531 subscribing to the resource, an INVITE request is sent to the 532 resource, and it will act as a conference focus and generate an 533 invitation to each recipient in the list. 535 8. Call Control Primitives 537 Numerous SIP extensions provide a toolkit of dialog and call 538 management techniques. These techniques have been combined together 539 to build many SIP-based services. 541 RFC 3515, The REFER Method (S): REFER [45] defines a mechanism for 542 asking a user agent to send a SIP request. Its a form of SIP 543 remote control, and is the primary tool used for call transfer in 544 SIP. 546 RFC 3725, Best Current Practices for Third Party Call Control (3pcc) 547 (B): RFC 3725 [46] defines a number of different call flows that 548 allow one SIP entity, called the controller, to create SIP 549 sessions amongst other SIP user agents. 551 RFC 3911, The SIP Join Header Field (S): RFC 3911 [49] defines the 552 Join header field. When sent in an INVITE, it causes the 553 recipient to join the resulting dialog into a conference with 554 another dialog in progress. 556 RFC 3891, The SIP Replaces Header (S): RFC 3891 [47] defines a 557 mechanism that allows a new dialog to replace an existing dialog. 558 It is useful for certain advanced transfer services. 560 RFC 3892, The SIP Referred-By Mechanism (S): RFC 3892 [48] defines 561 the Referred-By header field. It is used in requests triggered by 562 REFER, and provides the identity of the referring party to the 563 referred-to party. 565 RFC 4117, Transcoding Services Invocation in SIP Using Third Party 566 Call Control (I): RFC 4117 [50] defines how to use 3pcc for the 567 purposes of invoking transcoding services for a call. 569 9. Event Framework and Packages 571 RFC 3265 defines a basic framework for event notification in SIP. It 572 introduces the notion of an event package, which is a collection of 573 related state and event information. Much of the state and events in 574 SIP systems have event packages, allowing other entities to learn 575 about changes in that state. 577 RFC 3903, SIP Extension for Event State Publication (S): RFC 3903 578 [51] defines the PUBLISH method. It is not an event package, but 579 is used by all event packages as a mechanism for pushing an event 580 into the system. 582 RFC 4662, A Session Initiation Protocol (SIP) Event Notification 583 Extension for Resource Lists (S): RFC 4662 [67] defines an extension 584 to RFC 3265 that allows a client to subscribe to a list of 585 resources using a single subscription. The server, called a 586 Resource List Server (RLS) will "expand" the subscription and 587 subscribe to each individual member of the list. It has found 588 applicability primarily in the area of presence, but can be used 589 with any event package. 591 RFC 3680, A SIP Event Package for Registrations (S): RFC 3680 [52] 592 defines an event package for finding out about changes in 593 registration state. 595 RFC 3842, A Message Summary and Message Waiting Indication Event 596 Package for SIP (S): RFC 3842 [65] defines a way for a user agent to 597 find out about voicemails and other messages that are waiting for 598 it. Its primary purpose is to enable the voicemail waiting lamp 599 on most business telephones. 601 RFC 3856, A Presence Event Package for SIP (S): RFC 3856 [53] defines 602 an event package for indicating user presence through SIP. 604 RFC 3857, A Watcher Information Event Template Package for SIP 605 (S): RFC 3857 [54], also known as winfo, provides a mechanism for 606 a user agent to find out what subscriptions are in place for a 607 particular event package. Its primary usage is with presence, but 608 it can be used with any event package. 610 RFC 4235, An INVITE Initiated Dialog Event Package for SIP (S): RFC 611 4235 [55] defines an event package for learning the state of the 612 dialogs in progress at a user agent. 614 RFC 4575, A SIP Event Package for Conference State (S): RFC 4575 [56] 615 defines a mechanism for learning about changes in conference 616 state, including group membership. 618 RFC XXXX, A SIP Event Package for Keypress Stimulus (KPML) (S): RFC 619 XXXX [57] defines a way for an application in the network to 620 subscribe to the set of keypresses made on the keypad of a 621 traditional telephone. 623 RFC XXXX, SIP Event Package for Voice Quality Reporting (S): RFC XXXX 624 [58] defines a SIP event package that enables the collection and 625 reporting of metrics that measure the quality for Voice over 626 Internet Protocol (VoIP) sessions. 628 RFC XXXX, A Session Initiation Protocol (SIP) Event Package for 629 Session-Specific Session Policies (S): RFC XXXX [96] defines a SIP 630 event package that allows a proxy to notify a user agent about its 631 desire for the UA to use certain codecs or generally obey certain 632 media session policies. 634 RFC XXXX, The Session Initiation Protocol (SIP) Pending Additions 635 Event Package (S): RFC XXXX [103] defines a SIP event package that 636 allows a UA to learn whether consent has been given for the 637 addition of an address to a SIP "mailing list". It is used in 638 conjunction with the SIP framework for consent [101]. 640 10. Quality of Service 642 Several specifications concern themselves with the interactions of 643 SIP with network Quality of Service (QoS) mechanisms. 645 RFC 3312, Integration of Resource Management and SIP (S): RFC 3312 646 [59], updated by RFC 4032 [60] defines a way to make sure that the 647 phone of the called party doesn't ring until a QoS reservation has 648 been installed in the network. It does so by defining a general 649 preconditions framework, which defines conditions that must be 650 true in order for a SIP session to proceed 652 RFC 3313, Private SIP Extensions for Media Authorization (I): RFC 653 3313 [61] defines a P-header that provides a mechanism for passing 654 an authorization token between SIP and a network QoS reservation 655 protocol like RSVP. Its purpose is to make sure network QoS is 656 only granted if a client has made a SIP call through the same 657 providers network. This specification is sometimes referred to as 658 the SIP walled garden specification by the truly paranoid androids 659 in the SIP community. This is because it requires coupling of 660 signaling and the underlying IP network. 662 RFC 3524, Mapping of Media Streams to Resource Reservation Flows 663 (S): RFC 3524 [97] defines a usage of the SDP grouping framework for 664 indicating that a set of media streams should be handled by a 665 single resource reservation. 667 11. Operations and Management 669 Several specifications have been defined to support operations and 670 management of SIP systems. These include mechanisms for 671 configuration and network diagnostics. 673 RFC XXXX, Diagnostic Responses for SIP Hop Limit Errors (S): RFC XXXX 674 [98] defines a mechanism for including diagnostic information in a 675 483 response. This response is sent when the hop-count of a SIP 676 request was exceeded. 678 RFC XXXX, A Framework for SIP User Agent Profile Delivery (S): RFC 679 XXXX [62] defines a mechanism that allows a SIP user agent to 680 bootstrap its configuration from the network, and receive updates 681 to its configuration should it change. This is considered an 682 essential piece of deploying a usable SIP network. 684 RFC XXXX, Extensions to the Session Initiation Protocol (SIP) User 685 Agent Profile Delivery Change Notification Event Package for the 686 Extensible Markup Language Language Configuration Access Protocol 687 (XCAP) (S): RFC XXXX [63] defines an extension to [62] for learning 688 about changes in documents managed by XCAP. 690 RFC XXXX, SIP Event Package for Voice Quality Reporting (S): RFC XXXX 691 [58] defines a SIP event package that enables the collection and 692 reporting of metrics that measure the quality for Voice over 693 Internet Protocol (VoIP) sessions. 695 12. SIP Compression 697 Sigcomp [6] was defined to allow compression of SIP messages over low 698 bandwidth links. Sigcomp is not formally part of SIP. However, 699 usage of Sigcomp with SIP has required extensions to SIP. 701 RFC 3486, Compressing SIP (S): RFC 3486 [64] defines a SIP URI 702 parameter that can be used to indicate that a SIP server supports 703 Sigcomp. 705 13. SIP Service URIs 707 Several extensions define well-known services that can be invoked by 708 constructing requests with the specific structures for the Request 709 URI, resulting in specific behaviors at the UAS. 711 RFC 3087, Control of Service Context using Request URI (I): RFC 3087 712 [66] introduced the context of using Request URIs, encoded 713 appropriately, to invoke services. 715 RFC 4662, A SIP Event Notification Extension for Resource Lists 716 (S): RFC 4662 [67] defines a resource called a Resource List 717 Server. A client can send a subscribe to this server. The server 718 will generate a series of subscriptions, and compile the resulting 719 information and send it back to the subscriber. The set of 720 resources that the RLS will subscribe to is a property of the 721 request URI in the SUBSCRIBE request. 723 RFC XXXX, Subscriptions To Request-Contained Resource Lists in SIP 724 (S): RFC XXXX [68] allows a client to subscribe to a resource called 725 a Resource List Server. This server will generate a series of 726 subscriptions, and compile the resulting information and send it 727 back to the subscriber. For this specification, the list of 728 things to subscribe to is in the body of the SUBSCRIBE request. 730 RFC XXXX, Multiple-Recipient MESSAGE Requests in SIP (S): RFC XXXX 731 [69] is similar to [68]. However, instead of subscribing to the 732 resource, a MESSAGE request is sent to the resource, and it will 733 send a copy to each recipient. 735 RFC XXXX, Conference Establishment Using Request-Contained Lists in 736 SIP (S): RFC XXXX [70] is similar to [68]. However, instead of 737 subscribing to the resource, an INVITE request is sent to the 738 resource, and it will act as a conference focus and generate an 739 invitation to each recipient in the list. 741 RFC 4240, Basic Network Media Services with SIP (I): RFC 4240 [99] 742 defines a way for SIP application servers to invoke announcement 743 and conferencing services from a media server. This is 744 accomplished through a set of defined URI parameters which tell 745 the media server what to do, such as what file to play and what 746 language to render it in. 748 14. Security Mechanisms 750 Several extensions provide additional security features to SIP. 752 RFC 3853, S/MIME AES Requirement for SIP (S): RFC 3853 [71] is a 753 brief specification that updates the cryptography mechanisms used 754 in SIP S/MIME. However, SIP S/MIME has seen very little 755 deployment. 757 RFC XXXX, Certificate Management Service for The Session Initiation 758 Protocol (SIP) (S): RFC XXXX [100] defines a certificate service for 759 SIP whose purpose is to facilitate the deployment of S/MIME. The 760 certificate service allows clients to store and retrieve their own 761 certificates, in addition to obtaining the certificates for other 762 users. 764 RFC 3893, Session Initiation Protocol (SIP) Authenticated Identity 765 Body (AIB) Format (S): RFC 3893 [7] defines a SIP message fragment 766 which can be signed in order to provide an authenticated identity 767 over a request. It was an early predecessor to [19], and 768 consequently AIB has seen no deployment. 770 RFC XXXX, SIP SAML Profile and Binding (S): RFC XXXX [102] defines 771 the usage of the Security Assertion Markup Language (SAML) within 772 SIP, and describes how to use it in conjunction with SIP identity 773 [19] to provide authenticated assertions about a users role or 774 attributes. 776 RFC XXXX, A Framework for Consent-Based Communications in the Session 777 Initiation Protocol (SIP) (S): RFC XXX [101] defines several 778 extensions to SIP, including the Trigger-Consent and Permission- 779 Missing header fields. These header fields, in addition to the 780 other procedures defined in the document, define a way to manage 781 membership on "SIP mailing lists" used for instant messaging or 782 conferencing. In particular, it helps avoid the problem of using 783 such amplification services for the purposes of an attack on the 784 network, by making sure a user authorizes the addition of their 785 address onto such a service. 787 RFC XXXX, The Session Initiation Protocol (SIP) Pending Additions 788 Event Package (S): RFC XXXX [103] defines a SIP event package that 789 allows a UA to learn whether consent has been given for the 790 addition of an address to a SIP "mailing list". It is used in 791 conjunction with the SIP framework for consent [101]. 793 RFC 3329, Security Mechanism Agreement for SIP (S): RFC 3329 [72] 794 defines a mechanism to prevent bid-down attacks in conjunction 795 with SIP authentication. The mechanism has seen very limited 796 deployment. It was defined as part of the 3gpp IMS specification 797 suite, and is needed only when there are a multiplicity of 798 security mechanisms deployed at a particular server. In practice, 799 this has not been the case. 801 RFC XXXX, End-to-Middle Security in SIP (S): RFC XXXX [73] defines 802 mechanisms for encrypting content from user agents to specific 803 network intermediaries. 805 RFC 4572, Connection-Oriented Media Transport over the Transport 806 Layer Security (TLS) Protocol in the Session Description Protocol 807 (SDP) (S): RFC 4572 [104] specifies a mechanism for signaling TLS- 808 based media streams between endpoints. It expands the TCP-based 809 media signaling parameters defined in [86] to include fingerprint 810 information for TLS streams, so that TLS can operate between end 811 hosts using self-signed certificates. 813 RFC XXXX, Security Preconditions for Session Description Protocol 814 Media Streams (S): RFC XXXX [92] defines a precondition for use with 815 the preconditions framework [59]. The security precondition 816 prevents a session from being established until a security media 817 stream is set up. 819 15. Instant Messaging and Presence 821 SIP provides extensions for instant messaging and presence. 823 RFC 3428, SIP Extension for Instant Messaging (S): RFC 3428 [74] 824 defines the MESSAGE method, used for sending a page mode instant 825 message. 827 RFC 3856, A Presence Event Package for SIP (S): RFC 3856 [53] defines 828 an event package for indicating user presence through SIP. 830 RFC 3857, A Watcher Information Event Template Package for SIP 831 (S): RFC 3857 [54], also known as winfo, provides a mechanism for 832 a user agent to find out what subscriptions are in place for a 833 particular event package. Its primary usage is with presence, but 834 it can be used with any event package. 836 16. Emergency Services 838 Emergency services here covers both emergency calling (for example, 839 911 in the United States), and pre-emption services, which allow 840 authorized individuals to gain access to network resources in time of 841 emergency. 843 RFC 4411, Extending the SIP Reason Header for Preemption Events 844 (S): RFC 4411 [75] defines an extension to the Reason header, 845 allowing a UA to know that its dialog was torn down because a 846 higher priority session came through. 848 RFC 4412, Communications Resource Priority for SIP (S): RFC 4412 [76] 849 defines a new header field, Resource-Priority, that allows a 850 session to get priority treatment from the network. 852 17. Security Considerations 854 This specification is an overview of existing specifications, and 855 does not introduce any security considerations on its own. 857 18. IANA Considerations 859 None. 861 19. Informative References 863 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 864 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 865 Session Initiation Protocol", RFC 3261, June 2002. 867 [2] Bradner, S., "The Internet Standards Process -- Revision 3", 868 BCP 9, RFC 2026, October 1996. 870 [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 871 "RTP: A Transport Protocol for Real-Time Applications", 872 RFC 3550, July 2003. 874 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 875 Session Description Protocol (SDP)", RFC 3264, June 2002. 877 [5] Rosenberg, J., "Interactive Connectivity Establishment (ICE): 878 A Methodology for Network Address Translator (NAT) Traversal 879 for Offer/Answer Protocols", draft-ietf-mmusic-ice-11 (work in 880 progress), October 2006. 882 [6] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, 883 Z., and J. Rosenberg, "Signaling Compression (SigComp)", 884 RFC 3320, January 2003. 886 [7] Peterson, J., "Session Initiation Protocol (SIP) Authenticated 887 Identity Body (AIB) Format", RFC 3893, September 2004. 889 [8] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. 890 Rosen, "Change Process for the Session Initiation Protocol 891 (SIP)", BCP 67, RFC 3427, December 2002. 893 [9] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, 894 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 896 [10] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 897 (SIP): Locating SIP Servers", RFC 3263, June 2002. 899 [11] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 900 specifying the location of services (DNS SRV)", RFC 2782, 901 February 2000. 903 [12] Mealling, M. and R. Daniel, "The Naming Authority Pointer 904 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 906 [13] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 907 Notification", RFC 3265, June 2002. 909 [14] Peterson, J., "A Privacy Mechanism for the Session Initiation 910 Protocol (SIP)", RFC 3323, November 2002. 912 [15] Jennings, C., Peterson, J., and M. Watson, "Private Extensions 913 to the Session Initiation Protocol (SIP) for Asserted Identity 914 within Trusted Networks", RFC 3325, November 2002. 916 [16] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 917 (SIP) Extension Header Field for Registering Non-Adjacent 918 Contacts", RFC 3327, December 2002. 920 [17] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session 921 Initiation Protocol (SIP) for Symmetric Response Routing", 922 RFC 3581, August 2003. 924 [18] Sparks, R., "Actions Addressing Identified Issues with the 925 Session Initiation Protocol's (SIP) Non-INVITE Transaction", 926 RFC 4320, January 2006. 928 [19] Peterson, J. and C. Jennings, "Enhancements for Authenticated 929 Identity Management in the Session Initiation Protocol (SIP)", 930 RFC 4474, August 2006. 932 [20] Rosenberg, J., "Obtaining and Using Globally Routable User 933 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 934 (SIP)", draft-ietf-sip-gruu-10 (work in progress), 935 August 2006. 937 [21] Jennings, C. and R. Mahy, "Managing Client Initiated 938 Connections in the Session Initiation Protocol (SIP)", 939 draft-ietf-sip-outbound-04 (work in progress), June 2006. 941 [22] Petrack, S. and L. Conroy, "The PINT Service Protocol: 942 Extensions to SIP and SDP for IP Access to Telephone Call 943 Services", RFC 2848, June 2000. 945 [23] Gurbani, V., Brusilovsky, A., Faynberg, I., Gato, J., Lu, H., 946 and M. Unmehopa, "The SPIRITS (Services in PSTN requesting 947 Internet Services) Protocol", RFC 3910, October 2004. 949 [24] Vemuri, A. and J. Peterson, "Session Initiation Protocol for 950 Telephones (SIP-T): Context and Architectures", BCP 63, 951 RFC 3372, September 2002. 953 [25] Camarillo, G., Roach, A., Peterson, J., and L. Ong, 954 "Integrated Services Digital Network (ISDN) User Part (ISUP) 955 to Session Initiation Protocol (SIP) Mapping", RFC 3398, 956 December 2002. 958 [26] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Mapping 959 of Integrated Services Digital Network (ISDN) User Part (ISUP) 960 Overlap Signalling to the Session Initiation Protocol (SIP)", 961 RFC 3578, August 2003. 963 [27] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing 964 Tone Generation in the Session Initiation Protocol (SIP)", 965 RFC 3960, December 2004. 967 [28] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 968 Responses in Session Initiation Protocol (SIP)", RFC 3262, 969 June 2002. 971 [29] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 972 Method", RFC 3311, October 2002. 974 [30] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. 976 [31] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 977 Header Field for the Session Initiation Protocol (SIP)", 978 RFC 3326, December 2002. 980 [32] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 981 (SIP) Extension Header Field for Service Route Discovery 982 During Registration", RFC 3608, October 2003. 984 [33] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating 985 User Agent Capabilities in the Session Initiation Protocol 986 (SIP)", RFC 3840, August 2004. 988 [34] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 989 Preferences for the Session Initiation Protocol (SIP)", 990 RFC 3841, August 2004. 992 [35] Donovan, S. and J. Rosenberg, "Session Timers in the Session 993 Initiation Protocol (SIP)", RFC 4028, April 2005. 995 [36] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The Stream 996 Control Transmission Protocol (SCTP) as a Transport for the 997 Session Initiation Protocol (SIP)", RFC 4168, October 2005. 999 [37] Barnes, M., "An Extension to the Session Initiation Protocol 1000 (SIP) for Request History Information", RFC 4244, 1001 November 2005. 1003 [38] Levin, O., "Suppression of Session Initiation Protocol (SIP) 1004 REFER Method Implicit Subscription", RFC 4488, May 2006. 1006 [39] Rosenberg, J., "Request Authorization through Dialog 1007 Identification in the Session Initiation Protocol (SIP)", 1008 RFC 4538, June 2006. 1010 [40] Levin, O. and A. Johnston, "Conveying Feature Tags with the 1011 Session Initiation Protocol (SIP) REFER Method", RFC 4508, 1012 May 2006. 1014 [41] Willis, D. and A. Allen, "Requesting Answering Modes for the 1015 Session Initiation Protocol (SIP)", 1016 draft-ietf-sip-answermode-01 (work in progress), May 2006. 1018 [42] Adams, D., "The Hitchhikers Guide to the Galaxy", 1019 September 1979. 1021 [43] Rosenberg, J., "Rejecting Anonymous Requests in the Session 1022 Initiation Protocol (SIP)", draft-ietf-sip-acr-code-03 (work 1023 in progress), October 2006. 1025 [44] Camarillo, G., "Refering to Multiple Resources in the Session 1026 Initiation Protocol (SIP)", draft-ietf-sip-multiple-refer-00 1027 (work in progress), September 2006. 1029 [45] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1030 Method", RFC 3515, April 2003. 1032 [46] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 1033 Camarillo, "Best Current Practices for Third Party Call 1034 Control (3pcc) in the Session Initiation Protocol (SIP)", 1035 BCP 85, RFC 3725, April 2004. 1037 [47] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1038 Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. 1040 [48] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By 1041 Mechanism", RFC 3892, September 2004. 1043 [49] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) 1044 "Join" Header", RFC 3911, October 2004. 1046 [50] Camarillo, G., Burger, E., Schulzrinne, H., and A. van Wijk, 1047 "Transcoding Services Invocation in the Session Initiation 1048 Protocol (SIP) Using Third Party Call Control (3pcc)", 1049 RFC 4117, June 2005. 1051 [51] Niemi, A., "Session Initiation Protocol (SIP) Extension for 1052 Event State Publication", RFC 3903, October 2004. 1054 [52] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 1055 Package for Registrations", RFC 3680, March 2004. 1057 [53] Rosenberg, J., "A Presence Event Package for the Session 1058 Initiation Protocol (SIP)", RFC 3856, August 2004. 1060 [54] Rosenberg, J., "A Watcher Information Event Template-Package 1061 for the Session Initiation Protocol (SIP)", RFC 3857, 1062 August 2004. 1064 [55] Santesson, S. and R. Housley, "Internet X.509 Public Key 1065 Infrastructure Authority Information Access Certificate 1066 Revocation List (CRL) Extension", RFC 4325, December 2005. 1068 [56] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 1069 Initiation Protocol (SIP) Event Package for Conference State", 1070 RFC 4575, August 2006. 1072 [57] Dolly, M. and E. Burger, "A Session Initiation Protocol (SIP) 1073 Event Package for Key Press Stimulus (KPML)", 1074 draft-ietf-sipping-kpml-08 (work in progress), July 2006. 1076 [58] Pendleton, A., "Session Initiation Protocol Package for Voice 1077 Quality Reporting Event", draft-ietf-sipping-rtcp-summary-01 1078 (work in progress), February 2006. 1080 [59] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of 1081 Resource Management and Session Initiation Protocol (SIP)", 1082 RFC 3312, October 2002. 1084 [60] Camarillo, G. and P. Kyzivat, "Update to the Session 1085 Initiation Protocol (SIP) Preconditions Framework", RFC 4032, 1086 March 2005. 1088 [61] Marshall, W., "Private Session Initiation Protocol (SIP) 1089 Extensions for Media Authorization", RFC 3313, January 2003. 1091 [62] Petrie, D., "A Framework for Session Initiation Protocol User 1092 Agent Profile Delivery", 1093 draft-ietf-sipping-config-framework-09 (work in progress), 1094 October 2006. 1096 [63] Petrie, D., "Extensions to the Session Initiation Protocol 1097 (SIP) User Agent Profile Delivery Change Notification Event 1098 Package for the Extensible Markup Language Language 1099 Configuration Access Protocol (XCAP)", 1100 draft-ietf-sip-xcap-config-00 (work in progress), 1101 October 2006. 1103 [64] Camarillo, G., "Compressing the Session Initiation Protocol 1104 (SIP)", RFC 3486, February 2003. 1106 [65] Foster, M., McGarry, T., and J. Yu, "Number Portability in the 1107 Global Switched Telephone Network (GSTN): An Overview", 1108 RFC 3482, February 2003. 1110 [66] Campbell, B. and R. Sparks, "Control of Service Context using 1111 SIP Request-URI", RFC 3087, April 2001. 1113 [67] Roach, A., Campbell, B., and J. Rosenberg, "A Session 1114 Initiation Protocol (SIP) Event Notification Extension for 1115 Resource Lists", RFC 4662, August 2006. 1117 [68] Camarillo, G., "Subscriptions to Request-Contained Resource 1118 Lists in the Session Initiation Protocol (SIP)", 1119 draft-ietf-sip-uri-list-subscribe-00 (work in progress), 1120 September 2006. 1122 [69] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient 1123 MESSAGE Requests in the Session Initiation Protocol (SIP)", 1124 draft-ietf-sip-uri-list-message-00 (work in progress), 1125 September 2006. 1127 [70] Camarillo, G. and A. Johnston, "Conference Establishment Using 1128 Request-Contained Lists in the Session Initiation Protocol 1129 (SIP)", draft-ietf-sip-uri-list-conferencing-00 (work in 1130 progress), September 2006. 1132 [71] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 1133 Requirement for the Session Initiation Protocol (SIP)", 1134 RFC 3853, July 2004. 1136 [72] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. 1137 Haukka, "Security Mechanism Agreement for the Session 1138 Initiation Protocol (SIP)", RFC 3329, January 2003. 1140 [73] Ono, K. and S. Tachimoto, "End-to-middle Security in the 1141 Session Initiation Protocol (SIP)", draft-ietf-sip-e2m-sec-03 1142 (work in progress), September 2006. 1144 [74] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 1145 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1146 Instant Messaging", RFC 3428, December 2002. 1148 [75] Polk, J., "Extending the Session Initiation Protocol (SIP) 1149 Reason Header for Preemption Events", RFC 4411, February 2006. 1151 [76] Schulzrinne, H. and J. Polk, "Communications Resource Priority 1152 for the Session Initiation Protocol (SIP)", RFC 4412, 1153 February 2006. 1155 [77] Rosenberg, J., "A Framework for Application Interaction in the 1156 Session Initiation Protocol (SIP)", 1157 draft-ietf-sipping-app-interaction-framework-05 (work in 1158 progress), July 2005. 1160 [78] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1161 Description Protocol", RFC 4566, July 2006. 1163 [79] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, 1164 "Grouping of Media Lines in the Session Description Protocol 1165 (SDP)", RFC 3388, December 2002. 1167 [80] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 1168 Session Description Protocol (SDP)", RFC 3605, October 2003. 1170 [81] Elwell, J., "Connected Identity in the Session Initiation 1171 Protocol (SIP)", draft-ietf-sip-connected-identity-02 (work in 1172 progress), October 2006. 1174 [82] Sparks, R., "Addressing an Amplification Vulnerability in 1175 Session Initiation Protocol (SIP) Forking Proxies", 1176 draft-ietf-sip-fork-loop-fix-03 (work in progress), 1177 September 2006. 1179 [83] Camarillo, G., "The Early Session Disposition Type for the 1180 Session Initiation Protocol (SIP)", RFC 3959, December 2004. 1182 [84] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., 1183 Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG 1184 Objects", RFC 3204, December 2001. 1186 [85] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 1187 November 2002. 1189 [86] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the 1190 Session Description Protocol (SDP)", RFC 4145, September 2005. 1192 [87] Camarillo, G. and J. Rosenberg, "The Alternative Network 1193 Address Types (ANAT) Semantics for the Session Description 1194 Protocol (SDP) Grouping Framework", RFC 4091, June 2005. 1196 [88] Rosenberg, J., "TCP Candidates with Interactive Connectivity 1197 Establishment (ICE)", draft-ietf-mmusic-ice-tcp-01 (work in 1198 progress), June 2006. 1200 [89] Burger, E., "A Mechanism for Content Indirection in Session 1201 Initiation Protocol (SIP) Messages", RFC 4483, May 2006. 1203 [90] Westerlund, M., "A Transport Independent Bandwidth Modifier 1204 for the Session Description Protocol (SDP)", RFC 3890, 1205 September 2004. 1207 [91] Camarillo, G., "Session Description Protocol (SDP) Format for 1208 Binary Floor Control Protocol (BFCP) Streams", 1209 draft-ietf-mmusic-sdp-bfcp-03 (work in progress), 1210 December 2005. 1212 [92] Andreasen, F. and D. Wing, "Security Preconditions for Session 1213 Description Protocol (SDP) Media Streams", 1214 draft-ietf-mmusic-securityprecondition-02 (work in progress), 1215 June 2006. 1217 [93] Andreasen, F., "Connectivity Preconditions for Session 1218 Description Protocol Media Streams", 1219 draft-ietf-mmusic-connectivity-precon-02 (work in progress), 1220 June 2006. 1222 [94] Hautakorpi, J. and G. Camarillo, "The SDP (Session Description 1223 Protocol) Content Attribute", 1224 draft-ietf-mmusic-sdp-media-content-06 (work in progress), 1225 September 2006. 1227 [95] Levin, O. and G. Camarillo, "The Session Description Protocol 1228 (SDP) Label Attribute", RFC 4574, August 2006. 1230 [96] Hilt, V. and G. Camarillo, "A Session Initiation Protocol 1231 (SIP) Event Package for Session-Specific Session Policies", 1232 draft-ietf-sipping-policy-package-01 (work in progress), 1233 June 2006. 1235 [97] Camarillo, G. and A. Monrad, "Mapping of Media Streams to 1236 Resource Reservation Flows", RFC 3524, April 2003. 1238 [98] Lawrence, S., "Diagnostic Responses for Session Initiation 1239 Protocol Hop Limit Errors", 1240 draft-ietf-sip-hop-limit-diagnostics-03 (work in progress), 1241 June 2006. 1243 [99] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media 1244 Services with SIP", RFC 4240, December 2005. 1246 [100] Jennings, C., "Certificate Management Service for The Session 1247 Initiation Protocol (SIP)", draft-ietf-sip-certs-01 (work in 1248 progress), June 2006. 1250 [101] Rosenberg, J., "A Framework for Consent-Based Communications 1251 in the Session Initiation Protocol (SIP)", 1252 draft-ietf-sip-consent-framework-00 (work in progress), 1253 September 2006. 1255 [102] Tschofenig, H., "SIP SAML Profile and Binding", 1256 draft-ietf-sip-saml-00 (work in progress), June 2006. 1258 [103] Camarillo, G., "The Session Initiation Protocol (SIP) Pending 1259 Additions Event Package", 1260 draft-ietf-sipping-pending-additions-00 (work in progress), 1261 September 2006. 1263 [104] Lennox, J., "Connection-Oriented Media Transport over the 1264 Transport Layer Security (TLS) Protocol in the Session 1265 Description Protocol (SDP)", RFC 4572, July 2006. 1267 Author's Address 1269 Jonathan Rosenberg 1270 Cisco Systems 1271 600 Lanidex Plaza 1272 Parsippany, NJ 07054 1273 US 1275 Phone: +1 973 952-5000 1276 Email: jdrosen@cisco.com 1277 URI: http://www.jdrosen.net 1279 Intellectual Property Statement 1281 The IETF takes no position regarding the validity or scope of any 1282 Intellectual Property Rights or other rights that might be claimed to 1283 pertain to the implementation or use of the technology described in 1284 this document or the extent to which any license under such rights 1285 might or might not be available; nor does it represent that it has 1286 made any independent effort to identify any such rights. Information 1287 on the procedures with respect to rights in RFC documents can be 1288 found in BCP 78 and BCP 79. 1290 Copies of IPR disclosures made to the IETF Secretariat and any 1291 assurances of licenses to be made available, or the result of an 1292 attempt made to obtain a general license or permission for the use of 1293 such proprietary rights by implementers or users of this 1294 specification can be obtained from the IETF on-line IPR repository at 1295 http://www.ietf.org/ipr. 1297 The IETF invites any interested party to bring to its attention any 1298 copyrights, patents or patent applications, or other proprietary 1299 rights that may cover technology that may be required to implement 1300 this standard. Please address the information to the IETF at 1301 ietf-ipr@ietf.org. 1303 Disclaimer of Validity 1305 This document and the information contained herein are provided on an 1306 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1307 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1308 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1309 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1310 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1311 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1313 Copyright Statement 1315 Copyright (C) The Internet Society (2006). This document is subject 1316 to the rights, licenses and restrictions contained in BCP 78, and 1317 except as set forth therein, the authors retain all their rights. 1319 Acknowledgment 1321 Funding for the RFC Editor function is currently provided by the 1322 Internet Society.