idnits 2.17.00 (12 Aug 2021) /tmp/idnits4049/draft-stucker-sipping-early-media-indirection-00.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 768. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 779. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 786. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 792. 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 : ---------------------------------------------------------------------------- == There are 29 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 12, 2007) is 5577 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '3' on line 142 == Unused Reference: 'RFC2119' is defined on line 712, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 715, but no explicit reference was found in the text == Unused Reference: 'RFC2327' is defined on line 720, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING B. Stucker 3 Internet-Draft Nortel 4 Intended status: Informational February 12, 2007 5 Expires: August 16, 2007 7 Early Media INDirection (EMIND) in the Session Initiation Protocol (SIP) 8 draft-stucker-sipping-early-media-indirection-00 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 August 16, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document describes models that can be used to manage multiple 42 early media streams in the Session Initiation Protocol (SIP). The 43 model seeks to allow calling party endpoints to be able to better 44 control the rendering of early media to the user, and distinguish 45 early media from final media. 47 Although some of early media challenges are likely to never be 48 overcome, (e.g. when interworking with an ISUP PSTN gateway that does 49 not take into account CPG or ACM messages), the potential to improve 50 on what is already there does exist. The recommendations in this 51 document are intended to be an update to RFC-3960 recommendations and 52 to avoid many of the complications outlined in 53 draft-stucker-sipping-early-media-coping. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Early Media Indirection . . . . . . . . . . . . . . . . . . . 5 62 6. Early Media Indirection Operation . . . . . . . . . . . . . . 6 63 6.1. The Early-Media Header . . . . . . . . . . . . . . . . . . 6 64 6.2. User Agent Client Procedures . . . . . . . . . . . . . . . 7 65 6.2.1. Indicating support for Early Media Indirection 66 (EMIND) . . . . . . . . . . . . . . . . . . . . . . . 7 67 6.2.2. Accepting indirect early-media streams . . . . . . . . 7 68 6.2.3. Closing indirect early-media streams . . . . . . . . . 8 69 6.2.4. Switching from early-media to final-media . . . . . . 8 70 6.3. Proxy/User Agent Server Procedures . . . . . . . . . . . . 8 71 6.3.1. Offering indirect early media streams . . . . . . . . 9 72 6.3.2. Closing indirect early media streams . . . . . . . . . 9 73 6.3.3. Ordering early media streams . . . . . . . . . . . . . 10 74 7. Example Call Flow . . . . . . . . . . . . . . . . . . . . . . 10 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 79 10.2. Informational References . . . . . . . . . . . . . . . . . 17 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 Intellectual Property and Copyright Statements . . . . . . . . . . 18 83 1. Introduction 85 Establishment of one or more media streams within SIP [RFC3261] using 86 the SDP offer/answer model [RFC3264] typically involves two phases: 87 early media and final media. Early media is media that is generated 88 prior to a particular SIP session being accepted by a called 89 endpoint. Final media differs from early media in that it is 90 generated only after the SIP session has been accepted by a called 91 endpoint. It is important to note, that although [RFC3261] does not 92 require that the originator/UAC actually render ANY early media sent 93 to them (just that they be prepared to receive it). However, in 94 order to prevent media clipping (see section 2 of [RFC3960]), UACs 95 nearly universally do try to render early media streams to the 96 originating user in practice. 98 There are many different reasons that early media may be sent to the 99 calling party. For example: to announce their current account 100 balance, to provide customized ringback, or to present a brief tone 101 identifying the service provider. In each of these cases, an 102 application server may intercept the INVITE and involve a media 103 server into the call. As a result of proxy and/or client 104 interactions (which are explained later in this document) the normal 105 negotiation of SDP between the calling party and the called party's 106 endpoint may be impacted negatively. 108 Another potentially troublesome scenario arises when the INVITE for 109 the call is forked by one or more proxies. This can create a 110 condition where multiple early media streams arrive at the UAC, 111 possibly prior to the SDP offer/answer exchange being completed. 112 This scenario has been previously discussed in [RFC3960], and in 113 particular by the definition of the gateway model given in that 114 document. Despite the previous treatment on the topic, there remains 115 room for improvement. 117 Finally, there is the problem of early media and interworking 118 scenarios. This is typically viewed as a problem with SIP to PSTN 119 interworking, but the reverse (where a PSTN user is trying to contact 120 a SIP user) can also cause problems. When other protocols are 121 interworked with SIP it may become difficult or impossible to know 122 the reason why a particular early media stream is being generated and 123 what the correct course of action is at the UAC. For example, ISUP 124 has no indication in the CPG or ACM messages as to what is likely in 125 a particular media stream is being sent to the originator for 126 presentation to the calling party. 128 This document seeks to improve upon each of these scenarios, where 129 possible, by updating the recommendations from [RFC3960], providing a 130 mechanism to help order early media streams when forking has 131 occurred, and separate early media negotiation triggered by proxies 132 from SDP negotiation with the called party's end device(s). Further 133 information about the various problems currently caused by existing 134 early media processing mechanisms can be found in 135 [I-D.stucker-sipping-early-media-coping]. 137 2. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in BCP 14, RFC 2119 [3]. 143 3. Definitions 145 This document uses the following terms: 147 o End-to-end early media - Media generated by the called party's end 148 client device prior to the call being answered at that device. 149 For example, colorful ringback tones streamed to the originator 150 that are generated by the terminating end user's phone. 151 o End-to-middle early media - Media that is generated by an 152 application server that is intended to cease upon arrival of the 153 200 OK to the INVITE by a device controlled by the called party. 154 For example, account balance information, branding, colorful 155 ringback tones, etc. 156 o Transitional media - End-to-end final media generated by the UAS 157 after the 200 OK, but arrives at the UAC before the 200 OK. In 158 effect the signaling is racing with the media to get to the UAC. 159 For example, the called party has answered the call, and is saying 160 "Hello", but the UAC doesn't yet know that the call has been 161 answered due to the decoupled signaling and media paths having 162 different latentcies. 163 o End-to-end in-band signaling - Signaling that is done end-to-end 164 in the media path instead of through SIP. For example, ICE 165 connectivity checks, or in-band SRTP handshake messages. 166 o Non-SDP early media - Ringback information sent in 180 messages to 167 the UAC per [RFC3261]. 169 4. Requirements 171 The following requirements are considered to be the starting point in 172 more formally discussing improvements to SIP for early media 173 interactions: 175 R1: A mechanism should exist by which a UAC can signal to a 176 particular UAS that it is now willing to accept early media, 177 without increasing the likelihood of transitional media 178 clipping. 179 R2: A mechanism should exist by which a proxy or UAS can signal to a 180 particular UAC what type of early media (if known) it wishes to 181 present to the UAC. Additionally the proxy or UAS should be 182 able to denote if it requires one-way, or two-way media flows, 183 and the relative importance of the early media. 184 R3: Any mechanism proposed should try, to the greatest extent 185 possible, be simple to implement, and reuse the existing design 186 patterns within [RFC3261], [RFC3264] and [RFC3960]. 187 R4: The mechanism must be able to deal with recursive forking 188 scenarios. This is where an INVITE passes two or more proxies 189 that both choose to fork the request to two or more endpoints at 190 each proxy in parallel. 191 R5: The mechanism must not require exchange of packets on the media 192 path to identify or coordinate early media streams as this may 193 not interoperate with common network media gating mechanisms. 195 5. Early Media Indirection 197 In order to satisfy all of the requirements outlined in this document 198 and [I-D.stucker-sipping-early-media-coping], a new mechanism is 199 proposed to manage early media negotiation and rendering: early media 200 indirection. Instead of negotiating both early and final media 201 parameters within the same SIP dialog, proxies and endpoints that 202 wish to generate early-media include a special Early-Media header in 203 any 18x response to the original INVITE if the UAC indicated support 204 for this mechanism. The UAC may then choose the time and conditions 205 under which it will contact the URI specified in the Early-Media 206 header to establish a separate (but related) dialog to handle the 207 "early" media. This separate dialog is called an early-media dialog. 208 The original INVITE dialog is called the final-media dialog. 210 By doing so, several benefits accrue to the UAC and the proxy/UAS: 212 o The UAC has total control over when/if it will initiate the early 213 media dialog. 214 o Because the SDP negotiation is separate from final media the early 215 media may have different directionality from the final-media. For 216 instance, the final-media may be recvonly, but the early media may 217 be sendrecv. 218 o The establishment of a separate early-media dialog reuses the same 219 mechanism on the UAC that generates any other INVITE transaction. 220 No new methods or complex negotiation mechanisms are required. 222 o Forking is no longer an issue for early media. The UAC controls 223 the timing and ordering of any early media dialogs explicitly. In 224 can also know which endpoint is generating what media through 225 subtle manipulation of its SDP parameters. 226 o No negotiation is required in the media path. Everything is 227 handled in the open on the signaling path where proxies may 228 enforce network policies regarding early media. 229 o The mechanism is entirely compatible with existing mechanisms. If 230 no Early-Media header is received by the UAC, it follows [RFC3960] 231 rules for early media rendering. 232 o SRTP negotiation is simplified. The final-media offer may include 233 SRTP whereas early-media dialogs may contain an offer that uses 234 regular RTP to conserve resources. 236 6. Early Media Indirection Operation 238 6.1. The Early-Media Header 240 In order to allow proxies and UASs to specify a location that the UAC 241 should contact for early-media, a new header is introduced. This is 242 done instead of adding SDP attributes to ease the ability of a proxy 243 to manage these contacts. For instance, if an Early-Media header is 244 seen coming from an untrusted endpoint, the proxy may strip the 245 header from the message. Likewise, if multiple headers are received 246 on various forked call legs, it is possible that the proxy may store 247 and forward these header values at a later time to facilitate 248 ordering of early media streams to the calling party. 250 The format of the Early-Media header is given as the following 251 (building off of ABNF definitions given in section 25.1 of 252 [RFC3261]): 254 Early-Media = "Early-Media" HCOLON ( contact-param * (COMMA 255 contact-param)) 257 The value of the early media header is one (or more) URIs for the UAC 258 to contact for early-media. In the case that a single URI is 259 specified and the UAC fails to establish a dialog, that early media 260 stream will fail to be rendered. If multiple URIs are specified, the 261 UAC may contact the next URI in the list if it fails to establish an 262 early media stream using a prior entry in the list. Once an early 263 media dialog is established, the remainder of the list (if any) is 264 discarded. 266 6.2. User Agent Client Procedures 268 The following sections describe the procedures that the UAC uses in 269 order to support early media indirection. 271 6.2.1. Indicating support for Early Media Indirection (EMIND) 273 Upon generation of an initial INVITE request, the UAC MUST include 274 the 'emind' option tag in a Supported header as part of the INVITE 275 request being sent. This lets the UAS know that the UAC supports 276 early media indirection and will process the Early-Media header 277 information sent back in any 18x responses. Failure to include this 278 value in the supported header may cause endpoints wishing to generate 279 early media to not use the procedures defined in this document (i.e. 280 revert to baseline behavior). If the initial INVITE request does not 281 include an SDP offer, then the next SIP request message that contains 282 an SDP offer prior to the 200 OK to the INVITE being received MUST 283 include the 'emind' option tag in a Supported header. 285 6.2.2. Accepting indirect early-media streams 287 The following section specifies the mechanism that a UAC uses to 288 accept an indirect (EMIND negotiated) early-media stream. If the UAC 289 is currently rendering any non-EMIND negotiated early-media it MUST 290 stop rendering that early-media. If the UAC is currently rendering 291 any EMIND negotiated early-media it MUST stop rendering that early- 292 media and complete the procedures given in section Section 6.2.3. 294 In order to accept indirect early-media, the UAC creates a separate 295 SIP dialog to handle the negotiation of this early media. This 296 dialog, known as an early-media dialog, allows the UAC to receive 297 early media from endpoints other than the called party's device(s) 298 such as a network media server, does not suffer from the problems of 299 forking (since each indirect early-media session creates a separate 300 early media dialog), allows for the UAC to specify a different RTP 301 payload type (to facilitate discrimination of early-media versus 302 final-media), and gives both the UAC and UAS the ability to 303 explicitly start and stop the early media stream without complicating 304 the SDP negotiations for the final media. 306 1. Create a new "early-media" INVITE request copying information 307 from the original INVITE request. 308 2. Copy the URI information from the 18x Early-Media header into the 309 request URI of the new "early-media" INVITE. 310 3. Create a new SDP offer (may be a copy or subset of the offer in 311 the original INVITE). For each codec offered, specify a new 312 dynamic RTP payload type specified for the offered codecs. The 313 payload number MUST be unique such that it does not duplicate a 314 dynamic payload type currently being offered by the UAC. This 315 dynamic RTP payload type is called the early-media payload type. 316 4. Send the new "early-media" INVITE to the same first-hop as the 317 original INVITE was sent to. 318 5. Render any media received with the matching the early-media 319 payload type. 321 6.2.3. Closing indirect early-media streams 323 The following section specifies the mechanism that a UAC uses to 324 close an indirect (EMIND negotiated) early-media stream. These 325 procedures may be executed in parallel to accepting a new indirect 326 early-media stream or any SIP signaling in relation to the original 327 INVITE request sent by the UAC to initiate the dialog. 329 1. Stop rendering any media matching the early-media payload type 330 used for this indirect early-media stream. 331 2. Send the UAS generating the early media a BYE request to close 332 the dialog for this early-media stream. 334 6.2.4. Switching from early-media to final-media 336 The procedure for knowing when early-media packets should be replaced 337 with final-media packets is straight-forward due to the utilization 338 of unique dynamic RTP payload types for the early-media dialog(s). 339 When the UAC detects media being received containing valid RTP 340 payload types that do not match those of a dynamic RTP payload type 341 specified in an early-media dialog, it simply stops rendering the 342 early-media stream(s) and beings rendering the final-media for the 343 original INVITE dialog. This eliminates problems coordinating 344 signaling between early-media generators and a called-party device 345 answering the original INVITE. 347 Upon receiving a final-media RTP payload type, the UAC SHOULD execute 348 the procedures in section Section 6.2.3 in a timely fashion for any 349 early-media dialog(s) it may have created. 351 6.3. Proxy/User Agent Server Procedures 353 If a proxy or UAS receives an INVITE, and wishes to generate end-to- 354 middle early media towards the UAC, it should first look to see if 355 the UAC has indicated support for early media indirection by the 356 presence of the 'emind' option tag in the Supported header of the 357 INVITE. If it has, then it may use the procedures specified in this 358 section. 360 In order to offer an indirect early media stream, the proxy/UAS 361 creates a secondary dialog. This dialog is called the "early-media 362 dialog". By creating a separate dialog, the negotiation of early- 363 media is separated from the negotiation of final media. 365 Because the early-media is then handled on a separate dialog, there 366 is no reason for it to be "early" anymore. The early-media dialog 367 that is created can be answered or rejected immediately. When either 368 end wishes to discontinue playback of the "early" media stream they 369 simply end the session by sending a BYE request for the early-media 370 dialog. 372 It should be noted that there is no restriction that says that the 373 UAS handling the original INVITE request must also handle the early- 374 media dialog. This allows UASs and proxies to specify media servers 375 which may be available in the network as sources for early-media 376 content. As a result, restrictions placed upon client devices that 377 prevent streaming of media prior to answering the call (i.e. gating 378 of their media) do not interfere with the ability to provide early 379 media services such as colorful ringback. 381 6.3.1. Offering indirect early media streams 383 If a proxy/UAS wishes to offer an early-media stream, they may do so 384 by including the following in a 18x response to the original INVITE 385 request: 386 1. A Requires header that includes the tag value 'emind'. 387 2. Include an Early-Media header that specifies the URI that the 388 originator should contact for early media. This URI may be a SIP 389 URI (possibly a GRUU) that points to the resource that is 390 controlling the early media to be generated. This may be the 391 proxy/UAS itself, or another network element such as a media 392 server. The URI may contain parameters that provide contextual 393 information about what early media is to be played. 395 6.3.2. Closing indirect early media streams 397 If the proxy/UAS wishes to close an early media stream, they may do 398 so by sending a BYE request on the early-media dialog. Closing 399 early-media streams by a proxy/UAS that are being served by third- 400 party network elements is outside the scope of this specification as 401 it is assumed that there is some form of coordination (such as an 402 H.248 interface to the media server from the proxy server) present 403 that makes this possible. 405 Any early-media dialogs that are controlled by the proxy/UAS MUST be 406 closed after sending a 3xx or higher response code to the original 407 INVITE request. If any early-media dialogs were created that are 408 handled by third-party network elements, it is assumed that the UAC 409 will close these dialogs upon receipt of the 3xx or higher response 410 code from the proxy/UAS. 412 6.3.3. Ordering early media streams 414 With the current specifications for early media, issues exist when 415 multiple early media streams are sent to the calling party 416 simultaneously. Because the media path may be decoupled from the 417 signaling path, proxies may have little or no control over the 418 ordering of early-media being sent to the calling party. Because 419 devices generating early-media may not be aware of forking of the SIP 420 signaling, they may not know that a conflict exists at the calling 421 party that prevents proper rendering of early media being generated. 423 Correct ordering of early-media is facilitated by early-media 424 indirection due to the requirement that the calling party explicitly 425 create a separate SIP dialog to handle negotiations. Further, 426 because the passing of indirection information is handled in a SIP 427 header instead of in a message body, it is possible for proxies to 428 inspect requests for early media and facilitate proper ordering. 430 7. Example Call Flow 432 The following call flow is given to show how the early-media 433 indirection procedures operate. In this example User A calls User B. 434 User B has previously instructed their proxy that they wish to have a 435 custom ringtone streamed to the originator. Rather than trying to 436 manage this as an inline operation, the proxy uses early media 437 indirection to handle the media interactions. 439 The call flow for this scenario would be as follows: 441 domain-a.com . domain-b.com 442 . proxy proxy . 443 . . 444 User A's . . . . . . . . . . . . . . . User B's Media 445 device device server 446 | | | | | 447 | INVITE F1 | | | | 448 |------------>| INVITE F2 | | | 449 | |------------>| INVITE F3 | | 450 | | |------------>| | 451 | | | | | 452 | | 180 Ring F4 | | | 453 | 180 Ring F5 |<------------| | | 454 |<------------| | | | 455 | INVITE F6 | | | | 456 |------------>| | INVITE F7 | | 457 | |---------------------------------------->| 458 | | | 200 OK F8 | | 459 | 200 OK F9 |<----------------------------------------| 460 |<------------| | | | 461 | | "Early" Media Session | | 462 |<=====================================================>| 463 | ACK | | | | 464 |------------------------------------------------------>| 465 | | "Final" Media Session | | 466 |<=======================================>| | 467 | | | 200 OK | | 468 | | 200 OK |<------------| | 469 | 200 OK |<------------| | | 470 |<------------| | | | 471 | | BYE | | 472 |------------------------------------------------------>| 473 | | 200 OK | | 474 |<------------------------------------------------------| 475 | | ACK | | | 476 |---------------------------------------->| | 478 Call flow diagram 480 The detailed call flow is as follows: 482 F1: INVITE (User A to Proxy A): 484 INVITE sip:userb@domain-b.com SIP/2.0 485 Via: SIP/2.0/UDP usera.domain-a.com:5060;branch=z9hG4bK12345 486 To: UserB 487 From: UserA ;tag=d7t6d7ftsdf7t6 488 Call-ID: 843817637684230@998sdasdh09 489 CSeq: 1 INVITE 490 Supported: emind 491 Contact: 492 Content-Length: ... 493 Content-Type: application/sdp 495 v=0 496 o=usera 53655765 2353687637 IN IP4 devicea.domain-a.com 497 s=- 498 t=0 0 499 c=IN IP4 devicea.domain-a.com 500 m=audio 3456 RTP/AVP 0 1 3 99 501 a=rtpmap:0 PCMU/8000 502 a=sendrecv 504 User A's proxy forwards the request to User B's proxy. 506 F2: INVITE (Proxy A to Proxy B): 508 INVITE sip:userb@domain-b.com SIP/2.0 509 Via: SIP/2.0/UDP proxy.domain-a.com:5060;branch=z9hG4bKaf88df7 510 Via: SIP/2.0/UDP usera.domain-a.com:5060;branch=z9hG4bK12345 511 To: UserB 512 From: UserA ;tag=d7t6d7ftsdf7t6 513 Call-ID: 843817637684230@998sdasdh09 514 CSeq: 1 INVITE 515 Supported: emind 516 Contact: 517 Content-Length: ... 518 Content-Type: application/sdp 520 v=0 521 o=usera 53655765 2353687637 IN IP4 devicea.domain-a.com 522 s=- 523 t=0 0 524 c=IN IP4 devicea.domain-a.com 525 m=audio 3456 RTP/AVP 0 1 3 99 526 a=rtpmap:0 PCMU/8000 527 a=sendrecv 529 User B's proxy forwards the request from User A to User B's device. 531 F3: INVITE Proxy B to User B): 533 INVITE sip:userb@deviceb.domain-b.com SIP/2.0 534 Via: SIP/2.0/UDP proxy.domain-b.com:5060;branch=z9hG4bK87yfgd8g 535 Via: SIP/2.0/UDP proxy.domain-a.com:5060;branch=z9hG4bKaf88df7 536 Via: SIP/2.0/UDP usera.domain-a.com:5060;branch=z9hG4bK12345 537 To: UserB 538 From: UserA ;tag=d7t6d7ftsdf7t6 539 Call-ID: 843817637684230@998sdasdh09 540 CSeq: 1 INVITE 541 Supported: emind 542 Contact: 543 Content-Length: ... 544 Content-Type: application/sdp 546 v=0 547 o=usera 53655765 2353687637 IN IP4 devicea.domain-a.com 548 s=- 549 t=0 0 550 c=IN IP4 devicea.domain-a.com 551 m=audio 3456 RTP/AVP 0 1 3 99 552 a=rtpmap:0 PCMU/8000 553 a=sendrecv 555 Meanwhile, user B's proxy wishes to invoke early media from a media 556 server in domain-b.com to User A's device to provide custom ringback: 558 F4: 180 Ringing (Proxy B to Proxy A): 560 SIP 2.0 180 Ringing 561 Via: SIP/2.0/UDP proxy.domain-a.com:5060;branch=z9hG4bKaf88df7 562 Via: SIP/2.0/UDP usera.domain-a.com:5060;branch=z9hG4bK12345 563 To: UserB ;tag=s12td12tr3t2 564 From: UserA ;tag=d7t6d7ftsdf7t6 565 Call-ID: 843817637684230@998sdasdh09 566 CSeq: 1 INVITE 567 Required: emind 568 Early-Media: 570 Content-Length: 0 572 User A's proxy validates that User B's proxy is trusted for early 573 media and leaves the Early-Media header alone. The 180 is forwarded 574 to User A's device: 576 F5: 180 Ringing (Proxy A to User A): 578 SIP 2.0 180 Ringing 579 Via: SIP/2.0/UDP usera.domain-a.com:5060;branch=z9hG4bK12345 580 To: UserB ;tag=s12td12tr3t2 581 From: UserA ;tag=d7t6d7ftsdf7t6 582 Call-ID: 843817637684230@998sdasdh09 583 CSeq: 1 INVITE 584 Required: emind 585 Early-Media: 587 Content-Length: 0 589 User A's device sees that an Early-Media header is present in the 180 590 response and executes the procedures in section Section 6.2.2 to 591 initiate the requested early-media dialog. It selects the dynamic 592 RTP payload type of 96 for the early-media payload type: 594 F6: INVITE (User A to Proxy A): 596 INVITE sip:service@media-server.domain-b.com:5060 597 ;service=ringback;user=userb SIP/2.0 598 Via: SIP/2.0/UDP usera.domain-a.com:5060;branch=z9hG4bK12345aaa 599 To: Service 600 From: UserA 601 Call-ID: 843230@998sdasdh09 602 CSeq: 1 INVITE 603 Contact: 604 Content-Length: ... 605 Content-Type: application/sdp 607 v=0 608 o=usera 53655765 2353687637 IN IP4 devicea.domain-a.com 609 s=- 610 t=0 0 611 c=IN IP4 devicea.domain-a.com 612 m=audio 3456 RTP/AVP 96 613 a=rtpmap:96 PCMU/8000 614 a=recvonly 616 User A's proxy forwards the request to the media server in domain- 617 b.com: 619 F7: INVITE (Proxy A to Media Server): 621 INVITE sip:service@media-server.domain-b.com:5060 622 ;service=ringback;user=userb SIP/2.0 623 Via: SIP/2.0/UDP proxy.domain-a.com:5060;branch=z9hG4bkdfsd8fysdf 624 Via: SIP/2.0/UDP usera.domain-a.com:5060;branch=z9hG4bK12345aaa 625 To: Service 626 From: UserA ;tag=d87fysdf8sdfy 627 Call-ID: 843230@998sdasdh09 628 CSeq: 1 INVITE 629 Contact: 630 Content-Length: ... 631 Content-Type: application/sdp 633 v=0 634 o=usera 53655765 2353687637 IN IP4 devicea.domain-a.com 635 s=- 636 t=0 0 637 c=IN IP4 devicea.domain-a.com 638 m=audio 3456 RTP/AVP 96 639 a=rtpmap:96 PCMU/8000 640 a=recvonly 642 The media server in domain-b accepts the incoming request for media 643 and accepts the offer from User A's device. 645 F8: 200 OK (Media Server to Proxy A): 647 SIP 2.0 200 OK 648 Via: SIP/2.0/UDP proxy.domain-a.com:5060;branch=z9hG4bkdfsd8fysdf 649 Via: SIP/2.0/UDP usera.domain-a.com:5060;branch=z9hG4bK12345 650 To: Service 651 From: UserA ;tag=d87fysdf8sdfy 652 Call-ID: 843230@998sdasdh09 653 CSeq: 1 INVITE 654 Content-Length: ... 655 Content-Type: application/sdp 657 v=0 658 o=media 53655765 2353687637 IN IP4 media-server.domain-b.com 659 s=- 660 t=0 0 661 c=IN IP4 media-server.domain-b.com 662 m=audio 7890 RTP/AVP 0 663 a=rtpmap:0 PCMU/8000 664 a=sendonly 666 User A's proxy forwards the response from User B's media server to 667 User A's device. 669 F9: 200 OK (Proxy A to User A): 671 SIP 2.0 200 OK 672 Via: SIP/2.0/UDP usera.domain-a.com:5060;branch=z9hG4bK12345 673 To: Service 674 From: UserA ;tag=d87fysdf8sdfy 675 Call-ID: 843230@998sdasdh09 676 CSeq: 1 INVITE 677 Content-Length: ... 678 Content-Type: application/sdp 680 v=0 681 o=media 53655765 2353687637 IN IP4 media-server.domain-b.com 682 s=- 683 t=0 0 684 c=IN IP4 media-server.domain-b.com 685 m=audio 7890 RTP/AVP 0 686 a=rtpmap:0 PCMU/8000 687 a=sendonly 689 Early media is now flowing from User B's media server to User A's 690 device. Some time later, User B answers the phone and begins sending 691 RTP packets to User A's device. These packets arrive ahead of the 692 200 OK to the INVITE sent to User B's device. User A's device 693 detects packets with an RTP payload type of other than 96 (the 694 selected early media payload type). Accordingly, it sends a BYE to 695 the early-media dialog (not shown). The remaining messaging on the 696 original INVITE dialog follows the normal SIP call setup procedures 697 (not shown). 699 8. Security Considerations 701 This document is a work in progress. Security considerations will be 702 added as various recommendations become more concrete. 704 9. IANA Considerations 706 This document defines the option-tag of "emind" which will require 707 IANA registration. 709 10. References 710 10.1. Normative References 712 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 713 Requirement Levels", BCP 14, RFC 2119, March 1997. 715 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 716 Specifications: ABNF", RFC 2234, November 1997. 718 10.2. Informational References 720 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 721 Protocol", RFC 2327, April 1998. 723 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 724 A., Peterson, J., Sparks, R., Handley, M., and E. 725 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 726 June 2002. 728 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 729 with Session Description Protocol (SDP)", RFC 3264, 730 June 2002. 732 [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing 733 Tone Generation in the Session Initiation Protocol (SIP)", 734 RFC 3960, December 2004. 736 [I-D.stucker-sipping-early-media-coping] 737 Stucker, B., "Coping with Early Media in the Session 738 Initiation Protocol (SIP)", 739 draft-stucker-sipping-early-media-coping-03 (work in 740 progress), October 2006. 742 Author's Address 744 Brian Stucker 745 Nortel 746 2201 Lakeside 747 Richardson, TX 75082 748 US 750 Phone: +1 972 685 7724 751 Email: bstucker@nortel.com 752 URI: http://www.nortel.com/ 754 Full Copyright Statement 756 Copyright (C) The IETF Trust (2007). 758 This document is subject to the rights, licenses and restrictions 759 contained in BCP 78, and except as set forth therein, the authors 760 retain all their rights. 762 This document and the information contained herein are provided on an 763 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 764 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 765 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 766 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 767 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 768 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 770 Intellectual Property 772 The IETF takes no position regarding the validity or scope of any 773 Intellectual Property Rights or other rights that might be claimed to 774 pertain to the implementation or use of the technology described in 775 this document or the extent to which any license under such rights 776 might or might not be available; nor does it represent that it has 777 made any independent effort to identify any such rights. Information 778 on the procedures with respect to rights in RFC documents can be 779 found in BCP 78 and BCP 79. 781 Copies of IPR disclosures made to the IETF Secretariat and any 782 assurances of licenses to be made available, or the result of an 783 attempt made to obtain a general license or permission for the use of 784 such proprietary rights by implementers or users of this 785 specification can be obtained from the IETF on-line IPR repository at 786 http://www.ietf.org/ipr. 788 The IETF invites any interested party to bring to its attention any 789 copyrights, patents or patent applications, or other proprietary 790 rights that may cover technology that may be required to implement 791 this standard. Please address the information to the IETF at 792 ietf-ipr@ietf.org. 794 Acknowledgment 796 Funding for the RFC Editor function is provided by the IETF 797 Administrative Support Activity (IASA).