idnits 2.17.1 draft-ietf-sip-hitchhikers-guide-04.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 1685. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1696. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1703. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1709. 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 == Line 980 has weird spacing: '...ions in the S...' -- 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 (November 15, 2007) is 6007 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3427 (Obsoleted by RFC 5727) -- Obsolete informational reference (is this intentional?): RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Obsolete informational reference (is this intentional?): RFC 2915 (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-10 -- Obsolete informational reference (is this intentional?): RFC 2976 (Obsoleted by RFC 6086) -- Obsolete informational reference (is this intentional?): RFC 4244 (Obsoleted by RFC 7044) == Outdated reference: A later version (-07) exists of draft-ietf-sip-answermode-06 == Outdated reference: A later version (-03) exists of draft-ietf-sip-multiple-refer-02 == 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-13 == Outdated reference: A later version (-03) exists of draft-ietf-sip-uri-list-message-02 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 3388 (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 (Obsoleted by RFC 5245) == Outdated reference: A later version (-16) exists of draft-ietf-mmusic-ice-tcp-04 -- Obsolete informational reference (is this intentional?): RFC 4583 (Obsoleted by RFC 8856) == 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-04 == Outdated reference: A later version (-15) exists of draft-ietf-sip-certs-04 == Outdated reference: A later version (-04) exists of draft-ietf-sip-consent-framework-03 == 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-03 -- Obsolete informational reference (is this intentional?): RFC 4572 (Obsoleted by RFC 8122) == Outdated reference: A later version (-13) exists of draft-ietf-mmusic-sdp-capability-negotiation-07 == 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-04 == Outdated reference: A later version (-10) exists of draft-ietf-sip-record-route-fix-01 == Outdated reference: A later version (-03) exists of draft-ietf-sip-subnot-etags-01 == Outdated reference: A later version (-09) exists of draft-ietf-sip-sips-06 == Outdated reference: A later version (-09) exists of draft-ietf-simple-simple-00 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-07) exists of draft-ietf-sip-dtls-srtp-framework-00 == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-framework-03 -- Obsolete informational reference (is this intentional?): RFC 2833 (Obsoleted by RFC 4733, RFC 4734) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) Summary: 1 error (**), 0 flaws (~~), 25 warnings (==), 22 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 November 15, 2007 5 Expires: May 18, 2008 7 A Hitchhiker's Guide to the Session Initiation Protocol (SIP) 8 draft-ietf-sip-hitchhikers-guide-04 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 May 18, 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 . . . . . . . . . . . . . . . . . . . . 4 53 3. Core SIP Specifications . . . . . . . . . . . . . . . . . . . 5 54 4. Public Switched Telephone Network (PSTN) Interworking . . . . 9 55 5. General Purpose Infrastructure Extensions . . . . . . . . . . 10 56 6. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 13 57 7. Call Control Primitives . . . . . . . . . . . . . . . . . . . 13 58 8. Event Framework . . . . . . . . . . . . . . . . . . . . . . . 14 59 9. Event Packages . . . . . . . . . . . . . . . . . . . . . . . . 15 60 10. Quality of Service . . . . . . . . . . . . . . . . . . . . . . 16 61 11. Operations and Management . . . . . . . . . . . . . . . . . . 17 62 12. SIP Compression . . . . . . . . . . . . . . . . . . . . . . . 17 63 13. SIP Service URIs . . . . . . . . . . . . . . . . . . . . . . . 18 64 14. Minor Extensions . . . . . . . . . . . . . . . . . . . . . . . 19 65 15. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 20 66 16. Conferencing . . . . . . . . . . . . . . . . . . . . . . . . . 23 67 17. Instant Messaging, Presence and Multimedia . . . . . . . . . . 24 68 18. Emergency Services . . . . . . . . . . . . . . . . . . . . . . 24 69 19. Security Considerations . . . . . . . . . . . . . . . . . . . 25 70 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 71 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 72 22. Informative References . . . . . . . . . . . . . . . . . . . . 25 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36 74 Intellectual Property and Copyright Statements . . . . . . . . . . 37 76 1. Introduction 78 The Session Initiation Protocol (SIP) [RFC3261] is the subject of 79 numerous specifications that have been produced by the IETF. It can 80 be difficult to locate the right document, or even to determine the 81 set of Request for Comments (RFC) about SIP. Don't Panic! [HGTTG] 82 This specification serves as a guide to the SIP RFC series. It lists 83 the specifications under the SIP umbrella. For each specification, a 84 paragraph or so description is included that summarizes the purpose 85 of the specification. Each specification also includes a letter that 86 designates its category in the standards track [RFC2026]. These 87 values are: 89 S: Standards Track (Proposed Standard, Draft Standard, or Standard) 91 E: Experimental 93 B: Best Current Practice 95 I: Informational 97 The specifications are grouped together by topic. The topics are: 99 Core: The essential SIP specifications that are expected to be 100 utilized for every session or registration. 102 PSTN Interop: Specifications related to interworking with the 103 telephone network. 105 General Purpose Infrastructure: General purpose extensions to SIP, 106 SDP and MIME, but ones that are not expected to always be used. 108 NAT Traversal: Specifications to deal with firewall and NAT 109 traversal. 111 Minor Extensions: Specifications that solve a narrow problem space 112 or provide an optimization. 114 Conferencing: Specifications for multimedia conferencing. 116 Call Control Primitives: Specifications for manipulating SIP dialogs 117 and calls. 119 Event Framework: Defines the core specifications for the SIP event 120 framework, providing for pub/sub capability. 122 Event Packages: Packages that utilize the SIP event framework. 124 Quality of Service: Specifications related to multimedia quality of 125 service (QoS). 127 Operations and Management: Specifications related to configuration 128 and monitoring of SIP deployments. 130 SIP Compression: Specifications to facilitate usage of SIP with the 131 Signaling Compression (Sigcomp) framework. 133 SIP Service URIs: Specifications on how to use SIP URIs to address 134 multimedia services. 136 Security Mechanisms: Specifications providing security functionality 137 for SIP. 139 Instant Messaging, Presence, and Multimedia: SIP extensions related 140 to IM, presence and multimedia. This covers only the SIP 141 extensions related to these topics. See [I-D.ietf-simple-simple] 142 for a full treatment of SIP for IM and Presence (SIMPLE). 144 Emergency Services: SIP extensions related to emergency services. 145 See [I-D.ietf-ecrit-framework] for a more complete treatment of 146 additional functionality related to emergency services. 148 Typically, SIP extensions fit naturally into topic areas, and 149 implementers interested in a particular topic often implement many or 150 all of the specifications in that area. There are some 151 specifications which fall into multiple topic areas, in which case 152 they are listed more than once. 154 Do not print all the specs cited here at once, as they might share 155 the fate of the rules of Brockian Ultracricket when bound together: 156 collapse under their own gravity and form a black hole [HGTTG]. 158 This document itself is not an update to RFC 3261 or an extension to 159 SIP. It is an informational document, meant to guide newcomers, 160 implementors and deployers to the many of the specifications 161 associated with SIP. 163 2. Scope of this Document 165 It is very difficult to enumerate the set of SIP specifications. 166 This is because there are many protocols that are intimately related 167 to SIP and used by nearly all SIP implementations, but are not 168 formally SIP extensions. As such, this document formally defines a 169 "SIP specification" as: 171 o Any specification that defines an extension to RFC 3261, where an 172 extension is a mechanism that changes or updates in some way a 173 behavior specified there. 175 o The basic SDP specification, RFC 4566 [RFC4566], and any 176 specification that defines an extension to SDP whose primary 177 purpose is to support SIP. 179 o Any specification that defines a MIME object whose primary purpose 180 is to support SIP 182 Excluded from this list are requirements, architectures, registry 183 definitions, non-normative frameworks, and processes. Best Current 184 Practices are included when they normatively define mechanisms for 185 accomplishing a task. 187 The SIP change process [RFC3427] defines two types of extensions to 188 SIP. These are normal extensions and the so-called P-headers (where 189 P stands for "preliminary", "private", or "proprietary", and the "P-" 190 prefix is included in the header field name), which are meant to be 191 used in areas of limited applicability. P-headers cannot be defined 192 in the standards track. For the most part, P-headers are not 193 included in the listing here, with the exception of those which have 194 seen general usage despite their P-header status. 196 This document includes specifications which have already been 197 approved by the IETF and granted an RFC number, in addition to 198 Internet Drafts which are still under development within IETF and 199 will eventually finish and get an RFC number. Inclusion of Internet 200 Drafts here helps encourage early implementation and demonstrations 201 of interoperability of the protocol, and thus aids in the standards 202 setting process. Inclusion of these also identifes where the IETF is 203 targetting a solution at a particular problem space. Note that final 204 IANA assignment of codepoints (such as option tags and header field 205 names) does not take place until shortly before publication as an 206 RFC, and thus codepoint assignments may change. 208 3. Core SIP Specifications 210 The core SIP specifications represent the set of specifications whose 211 functionality is broadly applicable. An extension is broadly 212 applicable if it fits into one of the following categories: 214 o For specifications that impact SIP session management, the 215 extension would be used for almost every session initiated by a 216 user agent 218 o For specifications that impact SIP registrations, the extension 219 would be used for almost every registration initiated by a user 220 agent 222 o For specifications that impact SIP subscriptions, the extension 223 would be used for almost every subscription initiated by a user 224 agent 226 In other words, these are not specifications that are used just for 227 some requests and not others; they are specifications that would 228 apply to each and every request that the extension is relevant for. 229 In the galaxy of SIP, these specifications are like towels [HGTTG]. 231 RFC 3261, The Session Initiation Protocol (S): [RFC3261] is the core 232 SIP protocol itself. RFC 3261 is an update to [RFC2543]. It is 233 the president of the galaxy [HGTTG] as far as the suite of SIP 234 specifications is concerned. 236 RFC 3263, Locating SIP Servers (S): [RFC3263] provides DNS 237 procedures for taking a SIP URI, and determining a SIP server that 238 is associated with that SIP URI. RFC 3263 is essential for any 239 implementation using SIP with DNS. RFC 3263 makes use of both DNS 240 SRV records [RFC2782] and NAPTR records [RFC2915]. 242 RFC 3264, An Offer/Answer Model with the Session Description Protocol 243 (S): [RFC3264] defines how the Session Description Protocol (SDP) 244 [RFC4566] is used with SIP to negotiate the parameters of a media 245 session. It is in widespread usage and an integral part of the 246 behavior of RFC 3261. 248 RFC 3265, SIP-Specific Event Notification (S): [RFC3265] defines the 249 SUBSCRIBE and NOTIFY methods. These two methods provide a general 250 event notification framework for SIP. To actually use the 251 framework, extensions need to be defined for specific event 252 packages. An event package defines a schema for the event data, 253 and describes other aspects of event processing specific to that 254 schema. An RFC 3265 implementation is required when any event 255 package is used. 257 RFC 3325, Private Extensions to SIP for Asserted Identity within 258 Trusted Networks (I): Though its P-header status implies that it has 259 limited applicability, [RFC3325], which defines the P-Asserted- 260 Identity header field, has been widely deployed. It is used as 261 the basic mechanism for providing network asserted caller ID 262 services. 264 RFC 3327, SIP Extension Header Field for Registering Non-Adjacent 265 Contacts (S): [RFC3327] defines the Path header field. This field 266 is inserted by proxies between a client and their registrar. It 267 allows inbound requests towards that client to traverse these 268 proxies prior to being delivered to the user agent. It is 269 essential in any SIP deployment that has edge proxies, which are 270 proxies between the client and the home proxy or SIP registrar. 272 RFC 3581, An Extension to SIP for Symmetric Response Routing (S): 273 [RFC3581] defines the rport parameter of the Via header. It 274 allows SIP responses to traverse NAT. It is one of several 275 specifications that are utilized for NAT traversal (see 276 Section 6). 278 RFC 3840, Indicating User Agent Capabilities in SIP (S): [RFC3840] 279 defines a mechanism for carrying capability information about a 280 user agent in REGISTER requests and in dialog-forming requests 281 like INVITE. It has found use with conferencing (the isfocus 282 parameter declares that a user agent is a conference server) and 283 with applications like push-to-talk. 285 RFC 4320, Actions Addressing Issues Identified with the Non-INVITE 286 Transaction in SIP (S): [RFC4320] formally updates RFC 3261, and 287 modifies some of the behaviors associated with non-INVITE 288 transactions. This addresses some problems found in timeout and 289 failure cases. 291 RFC 4474, Enhancements for Authenticated Identity Management in SIP 292 (S): [RFC4474] defines a mechanism for providing a cryptographically 293 verifiable identity of the calling party in a SIP request. Known 294 as "SIP Identity", this mechanism provides an alternative to RFC 295 3325. It has seen little deployment so far, but its importance as 296 a key construct for anti-spam techniques and new security 297 mechanisms makes it a core part of the SIP specifications. 299 draft-ietf-sip-gruu, Obtaining and Using Globally Routable User Agent 300 Identifiers (GRUU) in SIP (S): [I-D.ietf-sip-gruu] defines a 301 mechanism for directing requests towards a specific UA instance. 302 GRUU is essential for features like transfer and provides another 303 piece of the SIP NAT traversal story. 305 draft-ietf-sip-outbound, Managing Client Initiated Connections 306 through SIP (S): [I-D.ietf-sip-outbound], also known as SIP 307 outbound, defines important changes to the SIP registration 308 mechanism which enable delivery of SIP messages towards a UA when 309 it is behind a NAT. This specification is the cornerstone of the 310 SIP NAT traversal strategy. 312 RFC 4566, Session Description Protocol (S): [RFC4566] defines a 313 format for representing multimedia sessions. SDP objects are 314 carried in the body of SIP messages, and based on the offer/answer 315 model, are used to negotiate the media characteristics of a 316 session between users. 318 draft-ietf-mmusic-sdp-capability-negotiation, SDP Capability 319 Negotiation (S): [I-D.ietf-mmusic-sdp-capability-negotiation] 320 defines a set of extensions to SDP that allow for capability 321 negotiation within SDP. Capability negotiation can be used to 322 select between different profiles of RTP (secure vs. unsecure) or 323 to negotiate codecs such that an agent has to select one amongst a 324 set of supported codecs. 326 draft-ietf-mmusic-ice, Interactive Connectivity Establishment (ICE) 327 (S): [I-D.ietf-mmusic-ice] defines a technique for NAT traversal of 328 media sessions for protocols that make use of the offer/answer 329 model. This specification is the IETF recommended mechanism for 330 NAT traversal for SIP media streams, and is meant to be used even 331 by endpoints which are themselves never behind a NAT. A SIP 332 option tag and media feature tag [I-D.ietf-sip-ice-option-tag] 333 (also a core specification) have been defined for use with ICE. 335 RFC 3605, Real Time Control Protocol (RTCP) Attribute in the Session 336 Description Protocol (SDP) (S): [RFC3605] defines a way to 337 explicitly signal, within an SDP message, the IP address and port 338 for RTCP, rather than using the port+1 rule in the Real Time 339 Transport Protocol (RTP) [RFC3550]. It is needed for devices 340 behind NAT and used by ICE. 342 RFC 4916, Connected Identity in the Session Initiation Protocol (SIP) 343 (S): [RFC4916] formally updates RFC 3261. It defines an extension 344 to SIP that allows a calling user to determine the identity of the 345 final called user (connected party). Due to forwarding and 346 retargeting services, this may not be the same as the user that 347 the caller was originally trying to reach. The mechanism works in 348 tandem with the SIP identity specification [RFC4474] to provide 349 signatures over the connected party identity. It can also be used 350 if a party identity changes mid call due to third party call 351 control actions or PSTN behavior. 353 RFC 3311, The SIP UPDATE Method (S): [RFC3311] defines the UPDATE 354 method for SIP. This method is meant as a means for updating 355 session information prior to the completion of the initial INVITE 356 transaction. It can also be used to update other information, 357 such as the identity of the participant [RFC4916], without 358 involving an updated offer/answer exchange. It was developed 359 initially to support [RFC3312] but has found other uses. In 360 particular, its usage with RFC 4916 means it will typically be 361 used as part of every session, to convey a secure connected 362 identity. 364 draft-ietf-sip-sips, The use of the SIPS URI Scheme in the Session 365 Initiation Protocol (SIP) (S): [I-D.ietf-sip-sips] formally updated 366 RFC 3261. It revises the processing of the SIPS URI, originally 367 defined in RFC 3261, to fix many errors and problems that have 368 been encountered with that mechanism. 370 Essential Corrections to SIP: A collection of fixes to SIP that 371 address important bugs and vulnerabilities. These include a fix 372 requiring loop detection in any proxy that forks 373 [I-D.ietf-sip-fork-loop-fix] and a clarification on how record- 374 routing works [I-D.ietf-sip-record-route-fix]. 376 4. Public Switched Telephone Network (PSTN) Interworking 378 Numerous extensions and usages of SIP related to interoperability and 379 communications with or through the PSTN. 381 RFC 2848, The PINT Service Protocol (S): [RFC2848] is one of the 382 earliest extensions to SIP. It defines procedures for using SIP 383 to invoke services that actually execute on the PSTN. Its main 384 application is for third party call control, allowing an IP host 385 to set up a call between two PSTN endpoints. PINT has a 386 relatively narrow focus and has not seen widespread deployment. 388 RFC 3910, The SPIRITS Protocol (S): Continuing the trend of naming 389 PSTN related extensions with alcohol references, SPIRITS [RFC3910] 390 defines the inverse of PINT. It allows a switch in the PSTN to 391 ask an IP element about how to proceed with call waiting. It was 392 developed primarily to support Internet Call Waiting (ICW). 393 Perhaps the next specification will be called the Pan Galactic 394 Gargle Blaster [HGTTG]. 396 RFC 3372, SIP for Telephones (SIP-T): Context and Architectures (I): 397 SIP-T [RFC3372] defines a mechanism for using SIP between pairs of 398 PSTN gateways. Its essential idea is to tunnel ISUP signaling 399 between the gateways in the body of SIP messages. SIP-T motivated 400 the development of INFO [RFC2976]. SIP-T has seen widespread 401 implementation for the limited deployment model that it addresses. 402 As ISUP endpoints disappear from the network, the need for this 403 mechanism will decrease. 405 RFC 3398, ISUP to SIP Mapping (S): [RFC3398] defines how to do 406 protocol mapping from the SS7 ISDN User Part (ISUP) signaling to 407 SIP. It is widely used in SS7 to SIP gateways and is part of the 408 SIP-T framework. 410 RFC 3578, Mapping of ISUP Overlap Signaling to SIP (S): [RFC3578] 411 defines a mechanism to map overlap dialing into SIP. This 412 specification is widely regarded as the ugliest SIP specification, 413 as the introduction to the specification itself advises that it 414 has many problems. Overlap signaling (the practice of sending 415 digits into the network as dialed instead of waiting for complete 416 collection of the called party number) is largely incompatible 417 with SIP at some fairly fundamental levels. That said, RFC 3578 418 is mostly harmless and has seen some usage. 420 RFC 3960, Early Media and Ringtone Generation in SIP (I): [RFC3960] 421 defines some guidelines for handling early media - the practice of 422 sending media from the called party or an application server 423 towards the caller - prior to acceptance of the call. Early media 424 is often generated from the PSTN. Early media is a complex topic, 425 and this specification does not fully address the problems 426 associated with it. 428 RFC 3959, Early Session Disposition Type for the Session Initiation 429 Protocol (SIP) (S): [RFC3959] defines a new session disposition type 430 for use with early media. It indicates that the SDP in the body 431 is for a special early media session. This has seen little usage. 433 RFC 3204, MIME Media Types for ISUP and QSIG Objects (S): [RFC3204] 434 defines MIME objects for representing SS7 and QSIG signaling 435 messages. SS7 signaling messages are carried in the body of SIP 436 messages when SIP-T is used. QSIG signaling messages can be 437 carried in a similar way. 439 5. General Purpose Infrastructure Extensions 441 These extensions are general purpose enhancements to SIP, SDP and 442 MIME that can serve a wide variety of uses. However, they are not as 443 widely used or as essential as the core specifications. 445 RFC 3262, Reliability of Provisional Responses in SIP (S): SIP 446 defines two types of responses to a request - final and 447 provisional. Provisional responses are numbered from 100 to 199. 448 In SIP, these responses are not sent reliably. This choice was 449 made in RFC 2543 since the messages were meant to just be truly 450 informational, and rendered to the user. However, subsequent work 451 on PSTN interworking demonstrated a need to map provisional 452 responses to PSTN messages that needed to be sent reliably. 453 [RFC3262] was developed to allow reliability of provisional 454 responses. The specification defines the PRACK method, used for 455 indicating that a provisional response was received. Though it 456 provides a generic capability for SIP, RFC 3262 implementations 457 have been most common in PSTN interworking devices. However, 458 PRACK brings a great deal of complication for relatively small 459 benefit. As such, it has seen only moderate levels of deployment. 461 RFC 3323, A Privacy Mechanism for the Session Initiation Protocol 462 (SIP) (S): [RFC3323] defines the Privacy header field, used by 463 clients to request anonymity for their requests. Though it 464 defines several privacy services, the only one broadly used is the 465 one that supports privacy of the P-Asserted-Identity header field 466 [RFC3325]. 468 RFC 2976, The INFO Method (S): [RFC2976] was defined as an extension 469 to RFC 2543. It defines a method, INFO, used to transport mid- 470 dialog information that has no impact on SIP itself. Its driving 471 application was the transport of PSTN related information when 472 using SIP between a pair of gateways. Though originally conceived 473 for broader use, it only found standardized usage with SIP-T 474 [RFC3372]. It has been used to support numerous proprietary and 475 non-interoperable extensions due to its poorly defined scope. 477 RFC 3326, The Reason header field for SIP (S): [RFC3326] defines the 478 Reason header field. It is used in requests, such as BYE, to 479 indicate the reason that the request is being sent. 481 RFC 3388, Grouping of Media Lines in the Session Description Protocol 482 (S): RFC 3388 [RFC3388] defines a framework for grouping together 483 media streams in an SDP message. Such a grouping allows 484 relationships between these streams, such as which stream is the 485 audio for a particular video feed, to be expressed. 487 RFC 3420, Internet Media Type message/sipfrag (S): [RFC3420] defines 488 a MIME object that contains a SIP message fragment. Only certain 489 header fields and parts of the SIP message are present. For 490 example, it is used to report back on the responses received to a 491 request sent as a consequence of a REFER. 493 RFC 3608, SIP Extension Header Field for Service Route Discovery 494 During Registration (S): [RFC3608] allows a client to determine, 495 from a REGISTER response, a path of proxies to use in requests it 496 sends outside of a dialog. It can also be used by proxies to 497 verify the Route header in client initiated requests. In many 498 respects, it is the inverse of the Path header field, but has seen 499 less usage since default outbound proxies have been sufficient in 500 many deployments. 502 RFC 3841, Caller Preferences for SIP (S): [RFC3841] defines a set of 503 headers that a client can include in a request to control the way 504 in which the request is routed downstream. It allows a client to 505 direct a request towards a UA with specific capabilities, which a 506 UA indicates using [RFC3840]. 508 RFC 4028, Session Timers in SIP (S): [RFC4028] defines a keepalive 509 mechanism for SIP signaling. It is primarily meant to provide a 510 way to cleanup old state in proxies that are holding call state 511 for calls from failed endpoints which were never terminated 512 normally. Despite its name, the session timer is not a mechanism 513 for detecting a network failure mid-call. Session timers 514 introduces a fair bit of complexity for relatively little gain, 515 and have seen moderate deployment. 517 RFC 4168, SCTP as a Transport for SIP (S): [RFC4168] defines how to 518 carry SIP messages over the Stream Control Transmission Protocol 519 (SCTP) [RFC4960]. SCTP has seen very limited usage for SIP 520 transport. 522 RFC 4244, An Extension to SIP for Request History Information (S): 523 [RFC4244] defines the History-Info header field, which indicates 524 information on how and why a call came to be routed to a 525 particular destination. 527 RFC 4145, TCP-Based Media Transport in the Session Description 528 Protocol (SDP) (S): [RFC4145] defines an extension to SDP for 529 setting up TCP-based sessions between user agents. It defines who 530 sets up the connection and how its lifecycle is managed. It has 531 seen relatively little usage due to the small number of media 532 types to date which use TCP. 534 RFC 4091, The Alternative Network Address Types (ANAT) Semantics for 535 the Session Description Protocol (SDP) Grouping Framework (S): 536 [RFC4091] defines a mechanism for including both IPv4 and IPv6 537 addresses for a media session as alternates. This mechanism has 538 been deprecated in favor of ICE [I-D.ietf-mmusic-ice]. 540 draft-ietf-mmusic-sdp-media-capabilities, SDP Media Capabilities 541 Negotiation (S): [I-D.ietf-mmusic-sdp-media-capabilities] defines an 542 extension to the SDP capability negotiation framework 543 [I-D.ietf-mmusic-sdp-capability-negotiation] for negotiating 544 codecs, codec parameters, and media streams. 546 6. NAT Traversal 548 These SIP extensions are primarily aimed at addressing NAT traversal 549 for SIP. 551 draft-ietf-mmusic-ice, Interactive Connectivity Establishment (ICE) 552 (S): [I-D.ietf-mmusic-ice] defines a technique for NAT traversal of 553 media sessions for protocols that make use of the offer/answer 554 model. This specification is the IETF recommended mechanism for 555 NAT traversal for SIP media streams, and is meant to be used even 556 by endpoints which are themselves never behind a NAT. A SIP 557 option tag and media feature tag [I-D.ietf-sip-ice-option-tag] 558 have been defined for use with ICE. 560 draft-ietf-mmusic-ice-tcp, TCP Candidates with Interactive 561 Connectivity Establishment (ICE) (S): [I-D.ietf-mmusic-ice-tcp] 562 specifies the usage of ICE for TCP streams. This allows for 563 selection of RTP-based voice ontop of TCP only when NAT or 564 firewalls would prevent UDP-based voice from working. 566 RFC 3605, Real Time Control Protocol (RTCP) Attribute in the Session 567 Description Protocol (SDP) (S): [RFC3605] defines a way to 568 explicitly signal, within an SDP message, the IP address and port 569 for RTCP, rather than using the port+1 rule in the Real Time 570 Transport Protocol (RTP) [RFC3550]. It is needed for devices 571 behind NAT and used by ICE. 573 draft-ietf-sip-outbound, Managing Client Initiated Connections 574 through SIP (S): [I-D.ietf-sip-outbound], also known as SIP 575 outbound, defines important changes to the SIP registration 576 mechanism which enable delivery of SIP messages towards a UA when 577 it is behind a NAT. 579 RFC 3581, An Extension to SIP for Symmetric Response Routing (S): 580 [RFC3581] defines the rport parameter of the Via header. It 581 allows SIP responses to traverse NAT. 583 draft-ietf-sip-gruu, Obtaining and Using Globally Routable User Agent 584 Identifiers (GRUU) in SIP (S): [I-D.ietf-sip-gruu] defines a 585 mechanism for directing requests towards a specific UA instance. 586 GRUU is essential for features like transfer and provides another 587 piece of the SIP NAT traversal story. 589 7. Call Control Primitives 591 Numerous SIP extensions provide a toolkit of dialog and call 592 management techniques. These techniques have been combined together 593 to build many SIP-based services. 595 RFC 3515, The REFER Method (S): REFER [RFC3515] defines a mechanism 596 for asking a user agent to send a SIP request. It's a form of SIP 597 remote control, and is the primary tool used for call transfer in 598 SIP. Beware that not all potential uses of REFER (neither for all 599 methods nor for all URI schemes) are well defined. Implementors 600 should only use the well-defined ones, and should not second guess 601 or freely assume behavior for the others to avoid unexpected 602 behavior of remote UAs, interoperability issues, and other bad 603 surprises. 605 RFC 3725, Best Current Practices for Third Party Call Control (3pcc) 606 (B): [RFC3725] defines a number of different call flows that allow 607 one SIP entity, called the controller, to create SIP sessions 608 amongst other SIP user agents. 610 RFC 3911, The SIP Join Header Field (S): [RFC3911] defines the Join 611 header field. When sent in an INVITE, it causes the recipient to 612 join the resulting dialog into a conference with another dialog in 613 progress. 615 RFC 3891, The SIP Replaces Header (S): [RFC3891] defines a mechanism 616 that allows a new dialog to replace an existing dialog. It is 617 useful for certain advanced transfer services. 619 RFC 3892, The SIP Referred-By Mechanism (S): [RFC3892] defines the 620 Referred-By header field. It is used in requests triggered by 621 REFER, and provides the identity of the referring party to the 622 referred-to party. 624 RFC 4117, Transcoding Services Invocation in SIP Using Third Party 625 Call Control (I): [RFC4117] defines how to use 3pcc for the purposes 626 of invoking transcoding services for a call. 628 8. Event Framework 630 RFC 3265, SIP-Specific Event Notification (S): [RFC3265] defines the 631 SUBSCRIBE and NOTIFY methods. These two methods provide a general 632 event notification framework for SIP. To actually use the 633 framework, extensions need to be defined for specific event 634 packages. An event package defines a schema for the event data, 635 and describes other aspects of event processing specific to that 636 schema. An RFC 3265 implementation is required when any event 637 package is used. 639 RFC 3903, SIP Extension for Event State Publication (S): [RFC3903] 640 defines the PUBLISH method. It is not an event package, but is 641 used by all event packages as a mechanism for pushing an event 642 into the system. 644 RFC 4662, A Session Initiation Protocol (SIP) Event Notification 645 Extension for Resource Lists (S): [RFC4662] defines an extension to 646 RFC 3265 that allows a client to subscribe to a list of resources 647 using a single subscription. The server, called a Resource List 648 Server (RLS) will "expand" the subscription and subscribe to each 649 individual member of the list. It has found applicability 650 primarily in the area of presence, but can be used with any event 651 package. 653 draft-ietf-sip-subnot-etags, An Extension to Session Initiation 654 Protocol (SIP) Events for Conditional Event Notification (S): 655 [I-D.ietf-sip-subnot-etags] defines an extension to RFC 3265 to 656 optimize the performance of notifications. When a client 657 subscribes, it can indicate what version of a document it has, so 658 that the server can skip sending a notification if the client is 659 up to date. It is applicable to any event package. 661 9. Event Packages 663 These are event packages defined to utilize the SIP events framework. 664 Many of these are also listed elsewhere in their respective areas. 666 RFC 3680, A SIP Event Package for Registrations (S): [RFC3680] 667 defines an event package for finding out about changes in 668 registration state. 670 RFC 3842, A Message Summary and Message Waiting Indication Event 671 Package for SIP (S): [RFC3482] defines a way for a user agent to 672 find out about voicemails and other messages that are waiting for 673 it. Its primary purpose is to enable the voicemail waiting lamp 674 on most business telephones. 676 RFC 3856, A Presence Event Package for SIP (S): [RFC3856] defines an 677 event package for indicating user presence through SIP. 679 RFC 3857, A Watcher Information Event Template Package for SIP (S): 680 [RFC3857], also known as winfo, provides a mechanism for a user 681 agent to find out what subscriptions are in place for a particular 682 event package. Its primary usage is with presence, but it can be 683 used with any event package. 685 RFC 4235, An INVITE Initiated Dialog Event Package for SIP (S): 686 [RFC4235] defines an event package for learning the state of the 687 dialogs in progress at a user agent, and is one of several RFCs 688 starting with the important number 42 [HGTTG]. 690 RFC 4575, A SIP Event Package for Conference State (S): [RFC4575] 691 defines a mechanism for learning about changes in conference 692 state, including conference membership. 694 RFC 4730, A SIP Event Package for Keypress Stimulus (KPML) (S): 695 [RFC4730] defines a way for an application in the network to 696 subscribe to the set of keypresses made on the keypad of a 697 traditional telephone. It, along with RFC 2833 [RFC2833], are the 698 two mechanisms defined for handling DTMF. RFC 4730 is a 699 signaling-path solution, and RFC 2833 is a media-path solution. 701 draft-ietf-sipping-rtcp-summary, SIP Event Package for Voice Quality 702 Reporting (S): [I-D.ietf-sipping-rtcp-summary] defines a SIP event 703 package that enables the collection and reporting of metrics that 704 measure the quality for Voice over Internet Protocol (VoIP) 705 sessions. 707 draft-ietf-sipping-policy-package, A Session Initiation Protocol 708 (SIP) Event Package for Session-Specific Session Policies (S): 709 [I-D.ietf-sipping-policy-package] defines a SIP event package that 710 allows a policy server to notify a user agent about its desire for 711 the UA to use certain codecs or generally obey certain media 712 session policies. 714 draft-ietf-sipping-pending-additions, The Session Initiation Protocol 715 (SIP) Pending Additions Event Package (S): 716 [I-D.ietf-sipping-pending-additions] defines a SIP event package 717 that allows a UA to learn whether consent has been given for the 718 addition of an address to a SIP "mailing list". It is used in 719 conjunction with the SIP framework for consent 720 [I-D.ietf-sip-consent-framework]. 722 10. Quality of Service 724 Several specifications concern themselves with the interactions of 725 SIP with network Quality of Service (QoS) mechanisms. 727 RFC 3312, Integration of Resource Management and SIP (S): [RFC3312], 728 updated by [RFC4032] defines a way to make sure that the phone of 729 the called party doesn't ring until a QoS reservation has been 730 installed in the network. It does so by defining a general 731 preconditions framework, which defines conditions that must be 732 true in order for a SIP session to proceed. 734 RFC 3313, Private SIP Extensions for Media Authorization (I): 735 [RFC3313] defines a P-header that provides a mechanism for passing 736 an authorization token between SIP and a network QoS reservation 737 protocol like RSVP. Its purpose is to make sure network QoS is 738 only granted if a client has made a SIP call through the same 739 providers network. This specification is sometimes referred to as 740 the SIP walled garden specification by the truly paranoid androids 741 in the SIP community. This is because it requires coupling of 742 signaling and the underlying IP network. 744 RFC 3524, Mapping of Media Streams to Resource Reservation Flows 745 (S): [RFC3524] defines a usage of the SDP grouping framework for 746 indicating that a set of media streams should be handled by a 747 single resource reservation. 749 11. Operations and Management 751 Several specifications have been defined to support operations and 752 management of SIP systems. These include mechanisms for 753 configuration and network diagnostics. 755 draft-ietf-sipping-config-framework, A Framework for SIP User Agent 756 Profile Delivery (S): [I-D.ietf-sipping-config-framework] defines a 757 mechanism that allows a SIP user agent to bootstrap its 758 configuration from the network, and receive updates to its 759 configuration should it change. This is considered an essential 760 piece of deploying a usable SIP network. 762 draft-ietf-sipping-rtcp-summary, SIP Event Package for Voice Quality 763 Reporting (S): [I-D.ietf-sipping-rtcp-summary] defines a SIP event 764 package that enables the collection and reporting of metrics that 765 measure the quality for Voice over Internet Protocol (VoIP) 766 sessions. 768 12. SIP Compression 770 Sigcomp [RFC3320] [RFC4896] was defined to allow compression of SIP 771 messages over low bandwidth links. Sigcomp is not formally part of 772 SIP. However, usage of Sigcomp with SIP has required extensions to 773 SIP. 775 RFC 3486, Compressing SIP (S): [RFC3486] defines a SIP URI parameter 776 that can be used to indicate that a SIP server supports Sigcomp. 778 draft-ietf-rohc-sigcomp-sip, Applying Signaling Compression (SigComp) 779 to the Session Initiation Protocol (SIP) (S): 780 [I-D.ietf-rohc-sigcomp-sip] defines how to apply Sigcomp to SIP. 782 13. SIP Service URIs 784 Several extensions define well-known services that can be invoked by 785 constructing requests with the specific structures for the Request 786 URI, resulting in specific behaviors at the UAS. 788 RFC 3087, Control of Service Context using Request URI (I): 789 [RFC3087] introduced the context of using Request URIs, encoded 790 appropriately, to invoke services. 792 RFC 4662, A SIP Event Notification Extension for Resource Lists (S): 793 [RFC4662] defines a resource called a Resource List Server. A 794 client can send a subscribe to this server. The server will 795 generate a series of subscriptions, and compile the resulting 796 information and send it back to the subscriber. The set of 797 resources that the RLS will subscribe to is a property of the 798 request URI in the SUBSCRIBE request. 800 draft-ietf-sip-uri-list-subscribe, Subscriptions To Request-Contained 801 Resource Lists in SIP (S): [I-D.ietf-sip-uri-list-subscribe] allows 802 a client to subscribe to a resource called a Resource List Server. 803 This server will generate a series of subscriptions, and compile 804 the resulting information and send it back to the subscriber. For 805 this specification, the list of things to subscribe to is in the 806 body of the SUBSCRIBE request. 808 draft-ietf-sip-uri-list-message, Multiple-Recipient MESSAGE Requests 809 in SIP (S): [I-D.ietf-sip-uri-list-message] is similar to 810 [I-D.ietf-sip-uri-list-subscribe]. However, instead of 811 subscribing to the resource, a MESSAGE request is sent to the 812 resource, and it will send a copy to each recipient. 814 draft-ietf-sip-uri-list-conferencing, Conference Establishment Using 815 Request-Contained Lists in SIP (S): 816 [I-D.ietf-sip-uri-list-conferencing] is similar to 817 [I-D.ietf-sip-uri-list-subscribe]. However, instead of 818 subscribing to the resource, an INVITE request is sent to the 819 resource, and it will act as a conference focus and generate an 820 invitation to each recipient in the list. 822 RFC 4240, Basic Network Media Services with SIP (I): [RFC4240] 823 defines a way for SIP application servers to invoke announcement 824 and conferencing services from a media server. This is 825 accomplished through a set of defined URI parameters which tell 826 the media server what to do, such as what file to play and what 827 language to render it in. 829 RFC 4458, Session Initiation Protocol (SIP) URIs for Applications 830 such as Voicemail and Interactive Voice Response (IVR) (I): 831 [RFC4458] defines a way to invoke voicemail and IVR services by 832 using a SIP URI constructed in a particular way. 834 14. Minor Extensions 836 These SIP extensions don't fit easily into a single specific use 837 case. They have somewhat general applicability, but they solve a 838 relatively small problem or provide an optimization. 840 RFC 4488, Suppression of the SIP REFER Implicit Subscription (S): 841 [RFC4488] defines an enhancement to REFER. REFER normally creates 842 an implicit subscription to the target of the REFER. This 843 subscription is used to pass back updates on the progress of the 844 referral. This extension allows that implicit subscription to be 845 bypassed as an optimization. 847 RFC 4538, Request Authorization through Dialog Identification in SIP 848 (S): [RFC4538] provides a mechanism that allows a UAS to authorize a 849 request because the requestor proves it knows a dialog that is in 850 progress with the UAS. The specification is useful in conjunction 851 with the SIP application interaction framework 852 [I-D.ietf-sipping-app-interaction-framework]. 854 RFC 4508, Conveying Feature Tags with the REFER Method in SIP (S): 855 [RFC4508] defines a mechanism for carrying RFC 3840 feature tags 856 in REFER. It is useful for informing the target of the REFER 857 about the characteristics of the intentended target of the 858 referred request. 860 draft-ietf-sip-answermode, Requesting Answer Modes for SIP (S): 861 [I-D.ietf-sip-answermode] defines an extension for indicating to 862 the called party whether or not the phone should ring and/or be 863 answered immediately. This is useful for push-to-talk and for 864 diagnostic applications. 866 draft-ietf-sip-acr-code, Rejecting Anonymous Requests in SIP (S): 867 [I-D.ietf-sip-acr-code] defines a mechanism for a called party to 868 indicate to the calling party that a call was rejected since the 869 caller was anonymous. This is needed for implementation of the 870 Anonymous Call Rejection (ACR) feature in SIP. 872 draft-ietf-sip-multiple-refer, Referring to Multiple Resources in SIP 873 (S): [I-D.ietf-sip-multiple-refer] allows a UA sending a REFER to 874 ask the recipient of the REFER to generate multiple SIP requests, 875 not just one. This is useful for conferencing, where a client 876 would like to ask a conference server to eject multiple users. 878 RFC 4483, A Mechanism for Content Indirection in Session Initiation 879 Protocol (SIP) Messages (S): [RFC4483] defines a mechanism for 880 content indirection. Instead of carrying an object within a SIP 881 body, a URL reference is carried instead, and the recipient 882 dereferences the URL to obtain the object. The specification has 883 potential applicability for sending large instant messages, but 884 has yet to find much actual use. 886 RFC 3890, A Transport Independent Bandwidth Modifier for the Session 887 Description Protocol (SDP) (S): [RFC3890] specifies an SDP extension 888 that allows for the description of the bandwidth for a media 889 session that is independent of the underlying transport mechanism. 891 RFC 4583, Session Description Protocol (SDP) Format for Binary Floor 892 Control Protocol (BFCP) Streams (S): [RFC4583] defines a mechanism 893 in SDP to signal floor control streams that use BFCP. It is used 894 for Push-To-Talk and conference floor control. 896 draft-ietf-mmusic-connectivity-precon, Connectivity Preconditions for 897 Session Description Protocol Media Streams (S): 898 [I-D.ietf-mmusic-connectivity-precon] defines a usage of the 899 precondition framework [RFC3312]. The connectivity precondition 900 makes sure that the session doesn't get established until actual 901 packet connectivity is checked. 903 RFC 4796, The SDP (Session Description Protocol) Content Attribute 904 (S): [RFC4796] defines an SDP attribute for describing the purpose 905 of a media stream. Examples include a slide view, the speaker, a 906 sign language feed, and so on. 908 15. Security Mechanisms 910 Several extensions provide additional security features to SIP. 912 RFC 4474, Enhancements for Authenticated Identity Management in SIP 913 (S): [RFC4474] defines a mechanism for providing a cryptographically 914 verifiable identity of the calling party in a SIP request. Known 915 as "SIP Identity", this mechanism provides an alternative to RFC 916 3325. It has seen little deployment so far, but its importance as 917 a key construct for anti-spam techniques and new security 918 mechanisms makes it a core part of the SIP specifications. 920 RFC 3323, A Privacy Mechanism for the Session Initiation Protocol 921 (SIP) (S): [RFC3323] defines the Privacy header field, used by 922 clients to request anonymity for their requests. Though it 923 defines several privacy services, the only one broadly used is the 924 one that supports privacy of the P-Asserted-Identity header field 925 [RFC3325]. 927 RFC 4567, Key Management Extensions for Session Description Protocol 928 (SDP) and Real Time Streaming Protocol (RTSP) (S): [RFC4567] defines 929 extensions to SDP that allow tunneling of an key management 930 protocol, namely MIKEY [RFC3830], through offer/answer exchanges. 931 This mechanism is one of three SRTP keying techniques specified 932 for SIP, with DTLS-SRTP [I-D.ietf-sip-dtls-srtp-framework] having 933 been selected as the final solution. 935 RFC 4568, Session Description Protocol (SDP) Security Descriptions 936 for Media Streams (S): [RFC4568] defines extensions to SDP that 937 allow for the negotiation of keying material directly through 938 offer/answer, without a separate key management protocol. This 939 mechanism, sometimes called sdescriptions, has the drawback that 940 the media keys are available to any entity that has visibility to 941 the SDP. It is one of three SRTP keying techniques specified for 942 SIP, with DTLS-SRTP [I-D.ietf-sip-dtls-srtp-framework] having been 943 selected as the final solution. 945 draft-ietf-sip-dtls-srtp-framework, Framework for Establishing an 946 SRTP Security Context using DTLS (S): 947 [I-D.ietf-sip-dtls-srtp-framework] defines the overall framework 948 and SDP and SIP processing required to perform key management for 949 RTP using Datagram TLS (DTLS) [RFC4347] directly between 950 endpoints, over the media path. It is one of three SRTP keying 951 techniques specified for SIP, with DTLS-SRTP 952 [I-D.ietf-sip-dtls-srtp-framework] having been selected as the 953 final solution. 955 RFC 3853, S/MIME AES Requirement for SIP (S): [RFC3853] formally 956 updates RFC 3261. It is a brief specification that updates the 957 cryptography mechanisms used in SIP S/MIME. However, SIP S/MIME 958 has seen very little deployment. 960 draft-ietf-sip-certs, Certificate Management Service for The Session 961 Initiation Protocol (SIP) (S): [I-D.ietf-sip-certs] defines a 962 certificate service for SIP whose purpose is to facilitate the 963 deployment of S/MIME. The certificate service allows clients to 964 store and retrieve their own certificates, in addition to 965 obtaining the certificates for other users. 967 RFC 3893, Session Initiation Protocol (SIP) Authenticated Identity 968 Body (AIB) Format (S): [RFC3893] defines a SIP message fragment 969 which can be signed in order to provide an authenticated identity 970 over a request. It was an early predecessor to [RFC4474], and 971 consequently AIB has seen no deployment. 973 draft-ietf-sip-saml, SIP SAML Profile and Binding (S): 974 [I-D.ietf-sip-saml] defines the usage of the Security Assertion 975 Markup Language (SAML) within SIP, and describes how to use it in 976 conjunction with SIP identity [RFC4474] to provide authenticated 977 assertions about a users role or attributes. 979 draft-ietf-sip-consent-framework, A Framework for Consent-Based 980 Communications in the Session Initiation Protocol (SIP) (S): 981 [I-D.ietf-sip-consent-framework] defines several extensions to 982 SIP, including the Trigger-Consent and Permission-Missing header 983 fields. These header fields, in addition to the other procedures 984 defined in the document, define a way to manage membership on "SIP 985 mailing lists" used for instant messaging or conferencing. In 986 particular, it helps avoid the problem of using such amplification 987 services for the purposes of an attack on the network, by making 988 sure a user authorizes the addition of their address onto such a 989 service. 991 draft-ietf-sipping-pending-additions, The Session Initiation Protocol 992 (SIP) Pending Additions Event Package (S): 993 [I-D.ietf-sipping-pending-additions] defines a SIP event package 994 that allows a UA to learn whether consent has been given for the 995 addition of an address to a SIP "mailing list". It is used in 996 conjunction with the SIP framework for consent 997 [I-D.ietf-sip-consent-framework]. 999 RFC 3329, Security Mechanism Agreement for SIP (S): [RFC3329] 1000 defines a mechanism to prevent bid-down attacks in conjunction 1001 with SIP authentication. The mechanism has seen very limited 1002 deployment. It was defined as part of the 3gpp IMS specification 1003 suite [3GPP.24.229], and is needed only when there is a 1004 multiplicity of security mechanisms deployed at a particular 1005 server. In practice, this has not been the case. 1007 draft-ietf-sip-e2m-sec, End-to-Middle Security in SIP (S): 1008 [I-D.ietf-sip-e2m-sec] defines mechanisms for providing 1009 confidentiality and integrity for SIP message bodies sent from 1010 user agents to specific network intermediaries. 1012 RFC 4572, Connection-Oriented Media Transport over the Transport 1013 Layer Security (TLS) Protocol in the Session Description Protocol 1014 (SDP) (S): [RFC4572] specifies a mechanism for signaling TLS-based 1015 media streams between endpoints. It expands the TCP-based media 1016 signaling parameters defined in [RFC4145] to include fingerprint 1017 information for TLS streams, so that TLS can operate between end 1018 hosts using self-signed certificates. 1020 draft-ietf-mmusic-secruityprecondition, Security Preconditions for 1021 Session Description Protocol Media Streams (S): 1022 [I-D.ietf-mmusic-securityprecondition] defines a precondition for 1023 use with the preconditions framework [RFC3312]. The security 1024 precondition prevents a session from being established until a 1025 security media stream is set up. 1027 16. Conferencing 1029 Numerous SIP and SDP extensions are aimed at conferencing as their 1030 primary application. 1032 RFC 4574, The SDP (Session Description Protocol) Label Attribute 1033 (S): [RFC4574] defines an SDP attribute for providing an opaque 1034 label for media streams. These labels can be referred to by 1035 external documents, and in particular, by conference policy 1036 documents. This allows a UA to tie together documents it may 1037 obtain through conferencing mechanisms to media streams to which 1038 they refer. 1040 RFC 3911, The SIP Join Header Field (S): [RFC3911] defines the Join 1041 header field. When sent in an INVITE, it causes the recipient to 1042 join the resulting dialog into a conference with another dialog in 1043 progress. 1045 RFC 4575, A SIP Event Package for Conference State (S): [RFC4575] 1046 defines a mechanism for learning about changes in conference 1047 state, including conference membership. 1049 draft-ietf-sip-multiple-refer, Referring to Multiple Resources in SIP 1050 (S): [I-D.ietf-sip-multiple-refer] allows a UA sending a REFER to 1051 ask the recipient of the REFER to generate multiple SIP requests, 1052 not just one. This is useful for conferencing, where a client 1053 would like to ask a conference server to eject multiple users. 1055 draft-ietf-sip-uri-list-conferencing, Conference Establishment Using 1056 Request-Contained Lists in SIP (S): 1057 [I-D.ietf-sip-uri-list-conferencing] is similar to 1058 [I-D.ietf-sip-uri-list-subscribe]. However, instead of 1059 subscribing to the resource, an INVITE request is sent to the 1060 resource, and it will act as a conference focus and generate an 1061 invitation to each recipient in the list. 1063 RFC 4583, Session Description Protocol (SDP) Format for Binary Floor 1064 Control Protocol (BFCP) Streams (S): [RFC4583] defines a mechanism 1065 in SDP to signal floor control streams that use BFCP. It is used 1066 for Push-To-Talk and conference floor control. 1068 17. Instant Messaging, Presence and Multimedia 1070 SIP provides extensions for instant messaging, presence, and 1071 multimedia. 1073 RFC 3428, SIP Extension for Instant Messaging (S): [RFC3428] defines 1074 the MESSAGE method, used for sending an instant message without 1075 setting up a session (sometimes called "page mode"). 1077 RFC 3856, A Presence Event Package for SIP (S): [RFC3856] defines an 1078 event package for indicating user presence through SIP. 1080 RFC 3857, A Watcher Information Event Template Package for SIP (S): 1081 [RFC3857], also known as winfo, provides a mechanism for a user 1082 agent to find out what subscriptions are in place for a particular 1083 event package. Its primary usage is with presence, but it can be 1084 used with any event package. 1086 draft-ietf-mmusic-file-transfer-mech, A Session Description Protocol 1087 (SDP) Offer/Answer Mechanism to Enable File Transfer (S): 1088 [I-D.ietf-mmusic-file-transfer-mech] defines a mechanism for 1089 signaling a file transfer session with SIP. 1091 18. Emergency Services 1093 Emergency services here covers pre-emption services, which allow 1094 authorized individuals to gain access to network resources in time of 1095 emergency. 1097 RFC 4411, Extending the SIP Reason Header for Preemption Events (S): 1098 [RFC4411] defines an extension to the Reason header, allowing a UA 1099 to know that its dialog was torn down because a higher priority 1100 session came through. 1102 RFC 4412, Communications Resource Priority for SIP (S): [RFC4412] 1103 defines a new header field, Resource-Priority, that allows a 1104 session to get priority treatment from the network. 1106 19. Security Considerations 1108 This specification is an overview of existing specifications, and 1109 does not introduce any security considerations on its own. Of 1110 course, the world would be far more secure if everyone would follow 1111 one simple rule: "Don't Panic!" [HGTTG]. 1113 20. IANA Considerations 1115 None. 1117 21. Acknowledgements 1119 The author would like to thank Spencer Dawkins, Brian Stucker, John 1120 Elwell and Avshalom Houri for their comments on this document. 1122 22. Informative References 1124 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1125 A., Peterson, J., Sparks, R., Handley, M., and E. 1126 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1127 June 2002. 1129 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1130 3", BCP 9, RFC 2026, October 1996. 1132 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1133 Jacobson, "RTP: A Transport Protocol for Real-Time 1134 Applications", RFC 3550, July 2003. 1136 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1137 with Session Description Protocol (SDP)", RFC 3264, 1138 June 2002. 1140 [I-D.ietf-mmusic-ice] 1141 Rosenberg, J., "Interactive Connectivity Establishment 1142 (ICE): A Protocol for Network Address Translator (NAT) 1143 Traversal for Offer/Answer Protocols", 1144 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 1146 [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., 1147 Liu, Z., and J. Rosenberg, "Signaling Compression 1148 (SigComp)", RFC 3320, January 2003. 1150 [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) 1151 Authenticated Identity Body (AIB) Format", RFC 3893, 1152 September 2004. 1154 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., 1155 and B. Rosen, "Change Process for the Session Initiation 1156 Protocol (SIP)", BCP 67, RFC 3427, December 2002. 1158 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1159 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1160 March 1999. 1162 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1163 Protocol (SIP): Locating SIP Servers", RFC 3263, 1164 June 2002. 1166 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1167 specifying the location of services (DNS SRV)", RFC 2782, 1168 February 2000. 1170 [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer 1171 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 1173 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1174 Event Notification", RFC 3265, June 2002. 1176 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1177 Initiation Protocol (SIP)", RFC 3323, November 2002. 1179 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1180 Extensions to the Session Initiation Protocol (SIP) for 1181 Asserted Identity within Trusted Networks", RFC 3325, 1182 November 2002. 1184 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 1185 (SIP) Extension Header Field for Registering Non-Adjacent 1186 Contacts", RFC 3327, December 2002. 1188 [RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the 1189 Session Initiation Protocol (SIP) for Symmetric Response 1190 Routing", RFC 3581, August 2003. 1192 [RFC4320] Sparks, R., "Actions Addressing Identified Issues with the 1193 Session Initiation Protocol's (SIP) Non-INVITE 1194 Transaction", RFC 4320, January 2006. 1196 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1197 Authenticated Identity Management in the Session 1198 Initiation Protocol (SIP)", RFC 4474, August 2006. 1200 [I-D.ietf-sip-gruu] 1201 Rosenberg, J., "Obtaining and Using Globally Routable User 1202 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 1203 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 1204 October 2007. 1206 [I-D.ietf-sip-outbound] 1207 Jennings, C. and R. Mahy, "Managing Client Initiated 1208 Connections in the Session Initiation Protocol (SIP)", 1209 draft-ietf-sip-outbound-10 (work in progress), July 2007. 1211 [RFC2848] Petrack, S. and L. Conroy, "The PINT Service Protocol: 1212 Extensions to SIP and SDP for IP Access to Telephone Call 1213 Services", RFC 2848, June 2000. 1215 [RFC3910] Gurbani, V., Brusilovsky, A., Faynberg, I., Gato, J., Lu, 1216 H., and M. Unmehopa, "The SPIRITS (Services in PSTN 1217 requesting Internet Services) Protocol", RFC 3910, 1218 October 2004. 1220 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol 1221 for Telephones (SIP-T): Context and Architectures", 1222 BCP 63, RFC 3372, September 2002. 1224 [RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong, 1225 "Integrated Services Digital Network (ISDN) User Part 1226 (ISUP) to Session Initiation Protocol (SIP) Mapping", 1227 RFC 3398, December 2002. 1229 [RFC3578] Camarillo, G., Roach, A., Peterson, J., and L. Ong, 1230 "Mapping of Integrated Services Digital Network (ISDN) 1231 User Part (ISUP) Overlap Signalling to the Session 1232 Initiation Protocol (SIP)", RFC 3578, August 2003. 1234 [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing 1235 Tone Generation in the Session Initiation Protocol (SIP)", 1236 RFC 3960, December 2004. 1238 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1239 Provisional Responses in Session Initiation Protocol 1240 (SIP)", RFC 3262, June 2002. 1242 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1243 UPDATE Method", RFC 3311, October 2002. 1245 [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, 1246 October 2000. 1248 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 1249 Header Field for the Session Initiation Protocol (SIP)", 1250 RFC 3326, December 2002. 1252 [RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 1253 (SIP) Extension Header Field for Service Route Discovery 1254 During Registration", RFC 3608, October 2003. 1256 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1257 "Indicating User Agent Capabilities in the Session 1258 Initiation Protocol (SIP)", RFC 3840, August 2004. 1260 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1261 Preferences for the Session Initiation Protocol (SIP)", 1262 RFC 3841, August 2004. 1264 [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the 1265 Session Initiation Protocol (SIP)", RFC 4028, April 2005. 1267 [RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The 1268 Stream Control Transmission Protocol (SCTP) as a Transport 1269 for the Session Initiation Protocol (SIP)", RFC 4168, 1270 October 2005. 1272 [RFC4244] Barnes, M., "An Extension to the Session Initiation 1273 Protocol (SIP) for Request History Information", RFC 4244, 1274 November 2005. 1276 [RFC4488] Levin, O., "Suppression of Session Initiation Protocol 1277 (SIP) REFER Method Implicit Subscription", RFC 4488, 1278 May 2006. 1280 [RFC4538] Rosenberg, J., "Request Authorization through Dialog 1281 Identification in the Session Initiation Protocol (SIP)", 1282 RFC 4538, June 2006. 1284 [RFC4508] Levin, O. and A. Johnston, "Conveying Feature Tags with 1285 the Session Initiation Protocol (SIP) REFER Method", 1286 RFC 4508, May 2006. 1288 [I-D.ietf-sip-answermode] 1289 Willis, D. and A. Allen, "Requesting Answering Modes for 1290 the Session Initiation Protocol (SIP)", 1291 draft-ietf-sip-answermode-06 (work in progress), 1292 September 2007. 1294 [HGTTG] Adams, D., "The Hitchhiker's Guide to the Galaxy", 1295 September 1979. 1297 [I-D.ietf-sip-acr-code] 1298 Rosenberg, J., "Rejecting Anonymous Requests in the 1299 Session Initiation Protocol (SIP)", 1300 draft-ietf-sip-acr-code-05 (work in progress), July 2007. 1302 [I-D.ietf-sip-multiple-refer] 1303 Camarillo, G., Niemi, A., Isomaki, M., Garcia-Martin, M., 1304 and H. Khartabil, "Referring to Multiple Resources in the 1305 Session Initiation Protocol (SIP)", 1306 draft-ietf-sip-multiple-refer-02 (work in progress), 1307 November 2007. 1309 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1310 Method", RFC 3515, April 2003. 1312 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 1313 Camarillo, "Best Current Practices for Third Party Call 1314 Control (3pcc) in the Session Initiation Protocol (SIP)", 1315 BCP 85, RFC 3725, April 2004. 1317 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1318 Protocol (SIP) "Replaces" Header", RFC 3891, 1319 September 2004. 1321 [RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) 1322 Referred-By Mechanism", RFC 3892, September 2004. 1324 [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol 1325 (SIP) "Join" Header", RFC 3911, October 2004. 1327 [RFC4117] Camarillo, G., Burger, E., Schulzrinne, H., and A. van 1328 Wijk, "Transcoding Services Invocation in the Session 1329 Initiation Protocol (SIP) Using Third Party Call Control 1330 (3pcc)", RFC 4117, June 2005. 1332 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 1333 for Event State Publication", RFC 3903, October 2004. 1335 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 1336 Package for Registrations", RFC 3680, March 2004. 1338 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1339 Initiation Protocol (SIP)", RFC 3856, August 2004. 1341 [RFC3857] Rosenberg, J., "A Watcher Information Event Template- 1342 Package for the Session Initiation Protocol (SIP)", 1343 RFC 3857, August 2004. 1345 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 1346 Initiated Dialog Event Package for the Session Initiation 1347 Protocol (SIP)", RFC 4235, November 2005. 1349 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 1350 Initiation Protocol (SIP) Event Package for Conference 1351 State", RFC 4575, August 2006. 1353 [RFC4730] Burger, E. and M. Dolly, "A Session Initiation Protocol 1354 (SIP) Event Package for Key Press Stimulus (KPML)", 1355 RFC 4730, November 2006. 1357 [I-D.ietf-sipping-rtcp-summary] 1358 Pendleton, A., "Session Initiation Protocol Package for 1359 Voice Quality Reporting Event", 1360 draft-ietf-sipping-rtcp-summary-02 (work in progress), 1361 May 2007. 1363 [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, 1364 "Integration of Resource Management and Session Initiation 1365 Protocol (SIP)", RFC 3312, October 2002. 1367 [RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session 1368 Initiation Protocol (SIP) Preconditions Framework", 1369 RFC 4032, March 2005. 1371 [RFC3313] Marshall, W., "Private Session Initiation Protocol (SIP) 1372 Extensions for Media Authorization", RFC 3313, 1373 January 2003. 1375 [I-D.ietf-sipping-config-framework] 1376 Channabasappa, S., "A Framework for Session Initiation 1377 Protocol User Agent Profile Delivery", 1378 draft-ietf-sipping-config-framework-13 (work in progress), 1379 October 2007. 1381 [RFC3486] Camarillo, G., "Compressing the Session Initiation 1382 Protocol (SIP)", RFC 3486, February 2003. 1384 [RFC3482] Foster, M., McGarry, T., and J. Yu, "Number Portability in 1385 the Global Switched Telephone Network (GSTN): An 1386 Overview", RFC 3482, February 2003. 1388 [RFC3087] Campbell, B. and R. Sparks, "Control of Service Context 1389 using SIP Request-URI", RFC 3087, April 2001. 1391 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 1392 Initiation Protocol (SIP) Event Notification Extension for 1393 Resource Lists", RFC 4662, August 2006. 1395 [I-D.ietf-sip-uri-list-subscribe] 1396 Camarillo, G., Roach, A., and O. Levin, "Subscriptions to 1397 Request-Contained Resource Lists in the Session Initiation 1398 Protocol (SIP)", draft-ietf-sip-uri-list-subscribe-02 1399 (work in progress), November 2007. 1401 [I-D.ietf-sip-uri-list-message] 1402 Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient 1403 MESSAGE Requests in the Session Initiation Protocol 1404 (SIP)", draft-ietf-sip-uri-list-message-02 (work in 1405 progress), November 2007. 1407 [I-D.ietf-sip-uri-list-conferencing] 1408 Camarillo, G. and A. Johnston, "Conference Establishment 1409 Using Request-Contained Lists in the Session Initiation 1410 Protocol (SIP)", draft-ietf-sip-uri-list-conferencing-02 1411 (work in progress), November 2007. 1413 [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 1414 Requirement for the Session Initiation Protocol (SIP)", 1415 RFC 3853, July 2004. 1417 [RFC3329] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. 1418 Haukka, "Security Mechanism Agreement for the Session 1419 Initiation Protocol (SIP)", RFC 3329, January 2003. 1421 [I-D.ietf-sip-e2m-sec] 1422 Ono, K. and S. Tachimoto, "End-to-middle Security in the 1423 Session Initiation Protocol (SIP)", 1424 draft-ietf-sip-e2m-sec-06 (work in progress), July 2007. 1426 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1427 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1428 for Instant Messaging", RFC 3428, December 2002. 1430 [RFC4411] Polk, J., "Extending the Session Initiation Protocol (SIP) 1431 Reason Header for Preemption Events", RFC 4411, 1432 February 2006. 1434 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 1435 Priority for the Session Initiation Protocol (SIP)", 1436 RFC 4412, February 2006. 1438 [I-D.ietf-sipping-app-interaction-framework] 1439 Rosenberg, J., "A Framework for Application Interaction in 1440 the Session Initiation Protocol (SIP)", 1441 draft-ietf-sipping-app-interaction-framework-05 (work in 1442 progress), July 2005. 1444 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1445 Description Protocol", RFC 4566, July 2006. 1447 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 1448 Schulzrinne, "Grouping of Media Lines in the Session 1449 Description Protocol (SDP)", RFC 3388, December 2002. 1451 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1452 in Session Description Protocol (SDP)", RFC 3605, 1453 October 2003. 1455 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 1456 Protocol (SIP)", RFC 4916, June 2007. 1458 [I-D.ietf-sip-fork-loop-fix] 1459 Sparks, R., "Addressing an Amplification Vulnerability in 1460 Session Initiation Protocol (SIP) Forking Proxies", 1461 draft-ietf-sip-fork-loop-fix-05 (work in progress), 1462 March 2007. 1464 [RFC3959] Camarillo, G., "The Early Session Disposition Type for the 1465 Session Initiation Protocol (SIP)", RFC 3959, 1466 December 2004. 1468 [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, 1469 F., Watson, M., and M. Zonoun, "MIME media types for ISUP 1470 and QSIG Objects", RFC 3204, December 2001. 1472 [RFC3420] Sparks, R., "Internet Media Type message/sipfrag", 1473 RFC 3420, November 2002. 1475 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1476 the Session Description Protocol (SDP)", RFC 4145, 1477 September 2005. 1479 [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network 1480 Address Types (ANAT) Semantics for the Session Description 1481 Protocol (SDP) Grouping Framework", RFC 4091, June 2005. 1483 [I-D.ietf-mmusic-ice-tcp] 1484 Rosenberg, J., "TCP Candidates with Interactive 1485 Connectivity Establishment (ICE", 1486 draft-ietf-mmusic-ice-tcp-04 (work in progress), 1487 July 2007. 1489 [RFC4483] Burger, E., "A Mechanism for Content Indirection in 1490 Session Initiation Protocol (SIP) Messages", RFC 4483, 1491 May 2006. 1493 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 1494 Modifier for the Session Description Protocol (SDP)", 1495 RFC 3890, September 2004. 1497 [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format 1498 for Binary Floor Control Protocol (BFCP) Streams", 1499 RFC 4583, November 2006. 1501 [I-D.ietf-mmusic-securityprecondition] 1502 Andreasen, F. and D. Wing, "Security Preconditions for 1503 Session Description Protocol (SDP) Media Streams", 1504 draft-ietf-mmusic-securityprecondition-04 (work in 1505 progress), July 2007. 1507 [I-D.ietf-mmusic-connectivity-precon] 1508 Andreasen, F., "Connectivity Preconditions for Session 1509 Description Protocol Media Streams", 1510 draft-ietf-mmusic-connectivity-precon-02 (work in 1511 progress), June 2006. 1513 [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description 1514 Protocol (SDP) Content Attribute", RFC 4796, 1515 February 2007. 1517 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1518 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 1520 [I-D.ietf-sipping-policy-package] 1521 Hilt, V. and G. Camarillo, "A Session Initiation Protocol 1522 (SIP) Event Package for Session-Specific Session 1523 Policies", draft-ietf-sipping-policy-package-04 (work in 1524 progress), August 2007. 1526 [RFC3524] Camarillo, G. and A. Monrad, "Mapping of Media Streams to 1527 Resource Reservation Flows", RFC 3524, April 2003. 1529 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 1530 Media Services with SIP", RFC 4240, December 2005. 1532 [I-D.ietf-sip-certs] 1533 Jennings, C., "Certificate Management Service for The 1534 Session Initiation Protocol (SIP)", 1535 draft-ietf-sip-certs-04 (work in progress), July 2007. 1537 [I-D.ietf-sip-consent-framework] 1538 Rosenberg, J., Camarillo, G., and D. Willis, "A Framework 1539 for Consent-based Communications in the Session Initiation 1540 Protocol (SIP)", draft-ietf-sip-consent-framework-03 (work 1541 in progress), November 2007. 1543 [I-D.ietf-sip-saml] 1544 Tschofenig, H., "SIP SAML Profile and Binding", 1545 draft-ietf-sip-saml-02 (work in progress), May 2007. 1547 [I-D.ietf-sipping-pending-additions] 1548 Camarillo, G., "The Session Initiation Protocol (SIP) 1549 Pending Additions Event Package", 1550 draft-ietf-sipping-pending-additions-03 (work in 1551 progress), November 2007. 1553 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 1554 Transport Layer Security (TLS) Protocol in the Session 1555 Description Protocol (SDP)", RFC 4572, July 2006. 1557 [I-D.ietf-mmusic-sdp-capability-negotiation] 1558 Andreasen, F., "SDP Capability Negotiation", 1559 draft-ietf-mmusic-sdp-capability-negotiation-07 (work in 1560 progress), October 2007. 1562 [I-D.ietf-mmusic-sdp-media-capabilities] 1563 Andreasen, F., "SDP media capabilities Negotiation", 1564 draft-ietf-mmusic-sdp-media-capabilities-01 (work in 1565 progress), February 2007. 1567 [I-D.ietf-mmusic-file-transfer-mech] 1568 Garcia-Martin, M., Isomaki, M., Camarillo, G., and S. 1569 Loreto, "A Session Description Protocol (SDP) Offer/Answer 1570 Mechanism to Enable File Transfer", 1571 draft-ietf-mmusic-file-transfer-mech-04 (work in 1572 progress), October 2007. 1574 [I-D.ietf-sip-ice-option-tag] 1575 Rosenberg, J., "Indicating Support for Interactive 1576 Connectivity Establishment (ICE) in the Session 1577 Initiation Protocol (SIP)", 1578 draft-ietf-sip-ice-option-tag-02 (work in progress), 1579 June 2007. 1581 [3GPP.24.229] 1582 3GPP, "Internet Protocol (IP) multimedia call control 1583 protocol based on Session Initiation Protocol (SIP) and 1584 Session Description Protocol (SDP); Stage 3", 3GPP 1585 TS 24.229 5.20.0, September 2007. 1587 [I-D.ietf-sip-record-route-fix] 1588 Froment, T. and C. Lebel, "Addressing Record-Route issues 1589 in the Session Initiation Protocol (SIP)", 1590 draft-ietf-sip-record-route-fix-01 (work in progress), 1591 November 2007. 1593 [I-D.ietf-sip-subnot-etags] 1594 Niemi, A., "An Extension to Session Initiation Protocol 1595 (SIP) Events for Conditional Event Notification", 1596 draft-ietf-sip-subnot-etags-01 (work in progress), 1597 August 2007. 1599 [I-D.ietf-sip-sips] 1600 Audet, F., "The use of the SIPS URI Scheme in the Session 1601 Initiation Protocol (SIP)", draft-ietf-sip-sips-06 (work 1602 in progress), August 2007. 1604 [RFC4896] Surtees, A., West, M., and A. Roach, "Signaling 1605 Compression (SigComp) Corrections and Clarifications", 1606 RFC 4896, June 2007. 1608 [I-D.ietf-rohc-sigcomp-sip] 1609 Bormann, C., Liu, Z., Price, R., and G. Camarillo, 1610 "Applying Signaling Compression (SigComp) to the Session 1611 Initiation Protocol (SIP)", 1612 draft-ietf-rohc-sigcomp-sip-08 (work in progress), 1613 September 2007. 1615 [I-D.ietf-simple-simple] 1616 Rosenberg, J., "SIMPLE made Simple: An Overview of the 1617 IETF Specifications for Instant Messaging and Presence 1618 using the Session Initiation Protocol (SIP)", 1619 draft-ietf-simple-simple-00 (work in progress), July 2007. 1621 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1622 RFC 4960, September 2007. 1624 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 1625 Carrara, "Key Management Extensions for Session 1626 Description Protocol (SDP) and Real Time Streaming 1627 Protocol (RTSP)", RFC 4567, July 2006. 1629 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 1630 Description Protocol (SDP) Security Descriptions for Media 1631 Streams", RFC 4568, July 2006. 1633 [I-D.ietf-sip-dtls-srtp-framework] 1634 Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1635 for Establishing an SRTP Security Context using DTLS", 1636 draft-ietf-sip-dtls-srtp-framework-00 (work in progress), 1637 November 2007. 1639 [I-D.ietf-ecrit-framework] 1640 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1641 "Framework for Emergency Calling using Internet 1642 Multimedia", draft-ietf-ecrit-framework-03 (work in 1643 progress), September 2007. 1645 [RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF 1646 Digits, Telephony Tones and Telephony Signals", RFC 2833, 1647 May 2000. 1649 [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session 1650 Initiation Protocol (SIP) URIs for Applications such as 1651 Voicemail and Interactive Voice Response (IVR)", RFC 4458, 1652 April 2006. 1654 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1655 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1656 August 2004. 1658 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1659 Security", RFC 4347, April 2006. 1661 Author's Address 1663 Jonathan Rosenberg 1664 Cisco 1665 Edison, NJ 1666 US 1668 Email: jdrosen@cisco.com 1669 URI: http://www.jdrosen.net 1671 Full Copyright Statement 1673 Copyright (C) The IETF Trust (2007). 1675 This document is subject to the rights, licenses and restrictions 1676 contained in BCP 78, and except as set forth therein, the authors 1677 retain all their rights. 1679 This document and the information contained herein are provided on an 1680 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1681 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1682 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1683 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1684 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1685 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1687 Intellectual Property 1689 The IETF takes no position regarding the validity or scope of any 1690 Intellectual Property Rights or other rights that might be claimed to 1691 pertain to the implementation or use of the technology described in 1692 this document or the extent to which any license under such rights 1693 might or might not be available; nor does it represent that it has 1694 made any independent effort to identify any such rights. Information 1695 on the procedures with respect to rights in RFC documents can be 1696 found in BCP 78 and BCP 79. 1698 Copies of IPR disclosures made to the IETF Secretariat and any 1699 assurances of licenses to be made available, or the result of an 1700 attempt made to obtain a general license or permission for the use of 1701 such proprietary rights by implementers or users of this 1702 specification can be obtained from the IETF on-line IPR repository at 1703 http://www.ietf.org/ipr. 1705 The IETF invites any interested party to bring to its attention any 1706 copyrights, patents or patent applications, or other proprietary 1707 rights that may cover technology that may be required to implement 1708 this standard. Please address the information to the IETF at 1709 ietf-ipr@ietf.org. 1711 Acknowledgment 1713 Funding for the RFC Editor function is provided by the IETF 1714 Administrative Support Activity (IASA).