idnits 2.17.1 draft-worley-service-example-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 751: '...load type number SHOULD be used for th...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 13, 2012) is 4450 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'Sipping' on line 1347 looks like a reference -- Missing reference section? 'Sip-implementors' on line 1337 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dispatch D. Worley 3 Internet-Draft Avaya 4 Intended status: Informational February 13, 2012 5 Expires: August 16, 2012 7 Session Initiation Protocol Service Example -- Music on Hold 8 draft-worley-service-example-09 10 Abstract 12 The "music on hold" feature is one of the most desired features of 13 telephone systems in the business environment. "Music on hold" is 14 where, when one party to a call has the call "on hold", that party's 15 telephone provides an audio stream (often music) to be heard by the 16 other party. Architectural features of SIP make it difficult to 17 implement music-on-hold in a way that is fully compliant with the 18 standards. The implementation of music-on-hold described in this 19 document is fully effective and standards-compliant, and has a number 20 of advantages over the methods previously documented. In particular, 21 it is less likely to produce peculiar user interface effects and more 22 likely to work in systems which perform authentication than the 23 method of RFC 5359. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 16, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Intended Status . . . . . . . . . . . . . . . . . . . . . 4 61 2. Technique . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.1. Placing a Call on Hold and Establishing an External 63 Media Stream . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.2. Taking a Call off Hold and Terminating the External 65 Media Stream . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.3. Example Message Flow . . . . . . . . . . . . . . . . . . . 7 67 2.4. Re-INVITE and UPDATE from the Remote UA . . . . . . . . . 15 68 2.5. INVITE with Replaces . . . . . . . . . . . . . . . . . . . 16 69 2.6. Re-INVITE and UPDATE from the Music-On-Hold Source . . . . 16 70 2.7. Handling Payload Type Numbers . . . . . . . . . . . . . . 17 71 2.7.1. Analysis . . . . . . . . . . . . . . . . . . . . . . . 17 72 2.7.2. Solution to the Problem . . . . . . . . . . . . . . . 18 73 2.7.3. Example of the Solution . . . . . . . . . . . . . . . 19 74 2.8. Dialog/Session Timers . . . . . . . . . . . . . . . . . . 22 75 2.9. When the Media Stream Directionality is "inactive" . . . . 22 76 2.10. Multiple Media Streams . . . . . . . . . . . . . . . . . . 23 77 3. Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . 24 78 4. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 79 4.1. Offering All Available Media Formats . . . . . . . . . . . 25 80 4.2. Handling re-INVITES in a B2BUA . . . . . . . . . . . . . . 25 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 82 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 83 7. Revision History . . . . . . . . . . . . . . . . . . . . . . . 29 84 7.1. Changes from draft-worley-service-example-00 to 85 draft-worley-service-example-01 . . . . . . . . . . . . . 29 86 7.2. Changes from draft-worley-service-example-01 to 87 draft-worley-service-example-02 . . . . . . . . . . . . . 29 88 7.3. Changes from draft-worley-service-example-02 to 89 draft-worley-service-example-03 . . . . . . . . . . . . . 29 90 7.4. Changes from draft-worley-service-example-03 to 91 draft-worley-service-example-04 . . . . . . . . . . . . . 29 92 7.5. Changes from draft-worley-service-example-04 to 93 draft-worley-service-example-05 . . . . . . . . . . . . . 30 94 7.6. Changes from draft-worley-service-example-05 to 95 draft-worley-service-example-06 . . . . . . . . . . . . . 30 97 7.7. Changes from draft-worley-service-example-06 to 98 draft-worley-service-example-07 . . . . . . . . . . . . . 30 99 7.8. Changes from draft-worley-service-example-07 to 100 draft-worley-service-example-08 . . . . . . . . . . . . . 30 101 7.9. Changes from draft-worley-service-example-08 to 102 draft-worley-service-example-09 . . . . . . . . . . . . . 31 103 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 104 8.1. Normative References . . . . . . . . . . . . . . . . . . . 32 105 8.2. Informative References . . . . . . . . . . . . . . . . . . 32 106 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 108 1. Introduction 110 Within SIP[sip]-based systems, it is desirable to be able to provide 111 features that are similar to those provided by traditional telephony 112 systems. A frequently requested feature is "music on hold": The 113 music-on-hold feature is where, when one party to a call has the call 114 "on hold", that party's telephone provides an audio stream (often 115 music) to be heard by the other party. 117 Architectural features of SIP make it difficult to implement music- 118 on-hold in a way that is fully compliant with the standards. The 119 purpose of this document is to describe a method that is reasonably 120 simple yet fully effective and standards-compliant. 122 1.1. Intended Status 124 The "intended status" of this document is "Informational". The 125 reason that it is not "Best Current Practice" is that this method is 126 not specified as "best", nor is this specification intended to 127 supersede all other methods for implementing music-on-hold. Indeed, 128 the two user agents in a call can use different methods for 129 implementing music-on-hold, as can different user agents within a 130 telephone system, and a single user agent can use different methods 131 within different calls, or at different times within one call. 133 2. Technique 135 The essence of the technique is that when the executing UA (the 136 user's UA) performs a re-INVITE of the remote UA (the other user's 137 UA) to establish the hold state, it provides no SDP[sdp] 138 offer[offer-answer][offer-answer-bis], thus compelling the remote UA 139 to provide an SDP offer. The executing UA then extracts the offer 140 SDP from the remote UA's 2xx response, and uses that as the offer SDP 141 in a new INVITE to the external media source. The external media 142 source is thus directed to provide media directly to the remote UA. 143 The media source's answer SDP is returned to the remote UA in the ACK 144 to the re-INVITE. 146 2.1. Placing a Call on Hold and Establishing an External Media Stream 148 1. The executing user instructs the executing UA to put the dialog 149 on-hold. 151 2. The executing UA sends a re-INVITE without SDP to the remote UA, 152 which forces the remote UA to provide an SDP offer in its 2xx 153 response. The Contact header of the re-INVITE includes the 154 '+sip.rendering="no"' field parameter to indicate that it is 155 putting the call on hold. ([dialog-event] section 5.2) 157 3. The remote UA sends a 2xx to the re-INVITE, and includes an SDP 158 offer giving its own listening address/port. If the remote UA 159 understands the sip.rendering feature parameter, the offer may 160 indicate that it will not send media by specifying the media 161 directionalities as "recvonly" (the reverse of "on-hold") or 162 "inactive". But the remote UA may offer to send media. 164 4. The executing UA uses this offer to derive the offer SDP of an 165 initial INVITE that it sends to the configured music-on-hold 166 (MOH) source. The SDP in this request is largely copied from the 167 SDP returned by the remote UA in the previous step, particularly 168 regarding the provided listening address/port and payload type 169 numbers. But the media directionalities are restricted to 170 "recvonly" or "inactive" as appropriate. The executing UA may 171 want or need to change the o= line. In addition, some a=rtpmap 172 lines may need to be added to control the assignment of RTP 173 payload type numbers.[Section 2.7] 175 5. The MOH source sends a 2xx response to the INVITE, which contains 176 an SDP answer that should include its media source address as its 177 listening address/port. This SDP must necessarily[offer-answer] 178 specify "sendonly" or "inactive" as the directionality for all 179 media streams. 181 Although this address/port should receive no RTP, the specified 182 port determines the port for receiving RTCP (and conventionally, 183 for sending RTCP). 185 By convention, UAs use their declared RTP listening ports as 186 their RTP source ports as well. The answer SDP will reach the 187 remote UA, thus informing it of the address/port from which the 188 MOH media will come, and presumably preventing the remote UA from 189 ignoring the MOH media if the remote UA filters media packets 190 based on the source address. This functionality requires the SDP 191 answer to contain the sending address in the c= line, even though 192 the MOH source does not receive RTP.) 194 6. The executing UA sends this SDP answer as its SDP answer in the 195 ACK for the re-INVITE to the remote UA. The o= line in the 196 answer must be modified to be within the sequence of o= lines 197 previously generated by the executing UA in the dialog. Any 198 dynamic payload type number assignments that have been created in 199 the answer must be recorded in the state of the original dialog. 201 7. Due to the sip.rendering feature parameter in the Contact of the 202 re-INVITE and the media directionality in the SDP answer 203 contained in the ACK, the on-hold state of the dialog is 204 established (at the executing end). 206 8. After this point, the MOH source generates RTP containing the 207 music-on-hold media, and sends it directly to the listening 208 address/port of the remote UA. The executing UA maintains two 209 dialogs (one to the remote UA, one to the MOH source), but does 210 not see or handle the MOH RTP. 212 2.2. Taking a Call off Hold and Terminating the External Media Stream 214 1. The executing user instructs the executing UA to take the dialog 215 off-hold. 217 2. The executing UA sends a re-INVITE to the remote UA with SDP that 218 requests to receive media. The Contact header of the re-INVITE 219 does not include the '+sip.rendering="no"' field parameter. (It 220 may contain a sip.rendering field parameter with value "yes" or 221 "unknown", or it may omit the field parameter.) Thus this INVITE 222 removes the on-hold state of the dialog (at the executing end). 223 (Note that the version in o= line of the offered SDP must account 224 for the SDP versions that were passed through from the MOH 225 source. Also note that any payload type numbers that were 226 assigned in SDP provided by the MOH source must be respected.) 228 3. When the remote UA sends a 2xx response to the re-INVITE, the 229 executing UA sends a BYE request in the dialog to the MOH source. 231 4. After this point, the MOH source does not generate RTP and 232 ordinary RTP flow is reestablished in the original dialog. 234 2.3. Example Message Flow 236 This section shows a message flow which is an example of this 237 technique. The scenario is: Alice establishes a call with Bob. Bob 238 then places the call on hold, with music-on-hold provided from an 239 external source. Bob then takes the call off hold. Note that this 240 is just one possible message flow that illustrates this technique; 241 numerous variations on these operations are allowed by the applicable 242 standards. 244 Alice Bob Music Source 246 Alice establishes the call: 248 | | | 249 | INVITE F1 | | 250 |--------------->| | 251 | 180 Ringing F2 | | 252 |<---------------| | 253 | 200 OK F3 | | 254 |<---------------| | 255 | ACK F4 | | 256 |--------------->| | 257 | RTP | | 258 |<==============>| | 259 | | | 261 Bob places Alice on hold, compelling Alice's UA to provide SDP: 263 | | | 264 | INVITE F5 | | 265 | (no SDP) | | 266 |<---------------| | 267 | 200 OK F6 | | 268 | (SDP offer) | | 269 |--------------->| | 270 | | | 272 Bob's UA initiates music-on-hold: 274 | | | 275 | | INVITE F7 | 276 | | (SDP offer, | 277 | | rev. hold) | 278 | |------------->| 279 | | 200 OK F8 | 280 | | (SDP answer, | 281 | | hold) | 282 | |<-------------| 283 | | ACK F9 | 284 | |------------->| 285 | | | 287 Bob's UA provides an SDP answer containing the address/port 288 of the Music Source: 290 | | | 291 | ACK F10 | | 292 | (SDP answer, | | 293 | hold | | 294 |<---------------| | 295 | no RTP | | 296 |<..............>| | 297 | Music-on-hold RTP | 298 |<==============================| 299 | | | 301 The music on hold is active. 303 Bob takes Alice off hold: 305 | | | 306 | INVITE F11 | | 307 | (SDP offer) | | 308 |<---------------| | 309 | 200 OK F12 | | 310 | (SDP answer) | | 311 |--------------->| | 312 | ACK F13 | | 313 |<---------------| | 314 | | BYE F14 | 315 | |------------->| 316 | | 200 F15 | 317 | |<-------------| 318 | RTP | | 319 |<==============>| | 320 | | | 322 The normal media session between Alice and Bob is resumed. 324 /* Alice calls Bob. */ 326 F1 INVITE Alice -> Bob 328 INVITE sips:bob@biloxi.example.com SIP/2.0 329 Via: SIP/2.0/TLS atlanta.example.com:5061 330 ;branch=z9hG4bK74bf9 331 Max-Forwards: 70 332 From: Alice ;tag=1234567 333 To: Bob 334 Call-ID: 12345600@atlanta.example.com 335 CSeq: 1 INVITE 336 Contact: 337 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 338 Supported: replaces, gruu 339 Content-Type: application/sdp 340 Content-Length: [omitted] 342 v=0 343 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 344 s= 345 c=IN IP4 atlanta.example.com 346 t=0 0 347 m=audio 49170 RTP/AVP 0 348 a=rtpmap:0 PCMU/8000 350 F2 180 Ringing Bob -> Alice 352 SIP/2.0 180 Ringing 353 Via: SIP/2.0/TLS atlanta.example.com:5061 354 ;branch=z9hG4bK74bf9 355 ;received=192.0.2.103 356 From: Alice ;tag=1234567 357 To: Bob ;tag=23431 358 Call-ID: 12345600@atlanta.example.com 359 CSeq: 1 INVITE 360 Contact: 361 Content-Length: 0 363 F3 200 OK Bob -> Alice 365 SIP/2.0 200 OK 366 Via: SIP/2.0/TLS atlanta.example.com:5061 367 ;branch=z9hG4bK74bf9 368 ;received=192.0.2.103 369 From: Alice ;tag=1234567 370 To: Bob ;tag=23431 371 Call-ID: 12345600@atlanta.example.com 372 CSeq: 1 INVITE 373 Contact: 374 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 375 Supported: replaces 376 Content-Type: application/sdp 377 Content-Length: [omitted] 379 v=0 380 o=bob 2890844527 2890844527 IN IP4 biloxi.example.com 381 s= 382 c=IN IP4 biloxi.example.com 383 t=0 0 384 m=audio 3456 RTP/AVP 0 385 a=rtpmap:0 PCMU/8000 387 F4 ACK Alice -> Bob 389 ACK sips:bob@biloxi.example.com SIP/2.0 390 Via: SIP/2.0/TLS atlanta.example.com:5061 391 ;branch=z9hG4bK74bfd 392 Max-Forwards: 70 393 From: Alice ;tag=1234567 394 To: Bob ;tag=23431 395 Call-ID: 12345600@atlanta.example.com 396 CSeq: 1 ACK 397 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 398 Supported: replaces 399 Content-Length: 0 401 /* Bob places Alice on hold. */ 403 /* The re-INVITE contains no SDP, thus compelling Alice's UA 404 to provide an offer. */ 406 F5 INVITE Bob -> Alice 408 INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0 409 Via: SIP/2.0/TLS biloxi.example.com:5061 410 ;branch=z9hG4bK874bk 411 To: Alice ;tag=1234567 412 From: Bob ;tag=23431 413 Call-ID: 12345600@atlanta.example.com 414 CSeq: 712 INVITE 415 Contact: ;+sip.rendering="no" 416 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 417 Supported: replaces 418 Content-Length: 0 420 /* Alice's UA provides an SDP offer. 421 Since it does not know that it is being put on hold, 422 the offer is the same as the original offer and describes 423 bidirectional media. */ 425 F6 200 OK Alice -> Bob 427 SIP/2.0 200 OK 428 Via: SIP/2.0/TLS biloxi.example.com:5061 429 ;branch=z9hG4bK874bk 430 ;received=192.0.2.105 431 To: Alice ;tag=1234567 432 From: Bob ;tag=23431 433 Call-ID: 12345600@atlanta.example.com 434 CSeq: 712 INVITE 435 Contact: 436 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 437 Supported: replaces, gruu 438 Content-Type: application/sdp 439 Content-Length: [omitted] 441 v=0 442 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 443 s= 444 c=IN IP4 atlanta.example.com 445 t=0 0 446 m=audio 49170 RTP/AVP 0 447 a=rtpmap:0 PCMU/8000 448 a=active 450 /* Bob's UA initiates music-on-hold. */ 452 /* This INVITE contains Alice's offer, but with the media 453 direction set to "reverse hold", receive-only. */ 455 F7 INVITE Bob -> Music Source 457 INVITE sips:music@source.example.com SIP/2.0 458 Via: SIP/2.0/TLS biloxi.example.com:5061 459 ;branch=z9hG4bKnashds9 460 Max-Forwards: 70 461 From: Bob ;tag=02134 462 To: Music Source 463 Call-ID: 4802029847@biloxi.example.com 464 CSeq: 1 INVITE 465 Contact: 466 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 467 Supported: replaces, gruu 468 Content-Type: application/sdp 469 Content-Length: [omitted] 471 v=0 472 o=bob 2890844534 2890844534 IN IP4 atlanta.example.com 473 s= 474 c=IN IP4 atlanta.example.com 475 t=0 0 476 m=audio 49170 RTP/AVP 0 477 a=rtpmap:0 PCMU/8000 478 a=recvonly 480 F8 200 OK Music Source -> Bob 482 SIP/2.0 200 OK 483 Via: SIP/2.0/TLS biloxi.example.com:5061 484 ;branch=z9hG4bKnashds9 485 ;received=192.0.2.105 486 From: Bob ;tag=02134 487 To: Music Source ;tag=56323 488 Call-ID: 4802029847@biloxi.example.com 489 Contact: ;automaton 490 ;+sip.byeless;+sip.rendering="no" 491 CSeq: 1 INVITE 492 Content-Length: [omitted] 494 v=0 495 o=MusicSource 2890844576 2890844576 IN IP4 source.example.com 496 s= 497 c=IN IP4 source.example.com 498 t=0 0 499 m=audio 49170 RTP/AVP 0 500 a=rtpmap:0 PCMU/8000 501 a=sendonly 503 F9 ACK Bob -> Music Source 505 ACK sips:music@source.example.com SIP/2.0 506 Via: SIP/2.0/TLS source.example.com:5061 507 ;branch=z9hG4bK74bT6 508 From: Bob ;tag=02134 509 To: Music Source ;tag=56323 510 Max-Forwards: 70 511 Call-ID: 4802029847@biloxi.example.com 512 CSeq: 1 ACK 513 Content-Length: 0 515 /* Bob's UA now sends the ACK that completes the re-INVITE 516 to Alice and completes the SDP offer/answer. 517 The ACK contains the SDP received from the Music Source, 518 and thus contains the address/port from which the Music Source 519 will send media, and implies the address/port which the Music 520 Source will use to send/receive RTCP. */ 522 F10 ACK Bob -> Alice 524 ACK sips:a8342043f@atlanta.example.com;gr SIP/2.0 525 Via: SIP/2.0/TLS biloxi.example.com:5061 526 ;branch=z9hG4bKq874b 527 To: Alice ;tag=1234567 528 From: Bob ;tag=23431 529 Call-ID: 12345600@atlanta.example.com 530 CSeq: 712 ACK 531 Contact: ;+sip.rendering="no" 532 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 533 Supported: replaces 534 Content-Length: [omitted] 536 v=0 537 o=bob 2890844527 2890844528 IN IP4 biloxi.example.com 538 s= 539 c=IN IP4 source.example.com 540 t=0 0 541 m=audio 49170 RTP/AVP 0 542 a=rtpmap:0 PCMU/8000 543 a=sendonly 545 /* Bob picks up the call by sending a re-INVITE to Alice. */ 547 F11 INVITE Bob -> Alice 549 INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0 550 Via: SIP/2.0/TLS biloxi.example.com:5061 551 ;branch=z9hG4bK874bk 552 To: Alice ;tag=1234567 553 From: Bob ;tag=23431 554 Call-ID: 12345600@atlanta.example.com 555 CSeq: 713 INVITE 556 Contact: 557 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 558 Supported: replaces 559 Content-Type: application/sdp 560 Content-Length: [omitted] 562 v=0 563 o=bob 2890844527 2890844529 IN IP4 biloxi.example.com 564 s= 565 c=IN IP4 biloxi.example.com 566 t=0 0 567 m=audio 3456 RTP/AVP 0 568 a=rtpmap:0 PCMU/8000 570 F12 200 OK Alice -> Bob 572 SIP/2.0 200 OK 573 Via: SIP/2.0/TLS biloxi.example.com:5061 574 ;branch=z9hG4bK874bk 575 ;received=192.0.2.105 576 To: Alice ;tag=1234567 577 From: Bob ;tag=23431 578 Call-ID: 12345600@atlanta.example.com 579 CSeq: 713 INVITE 580 Contact: 581 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 582 Supported: replaces, gruu 583 Content-Type: application/sdp 584 Content-Length: [omitted] 586 v=0 587 o=alice 2890844526 2890844527 IN IP4 atlanta.example.com 588 s= 589 c=IN IP4 atlanta.example.com 590 t=0 0 591 m=audio 49170 RTP/AVP 0 592 a=rtpmap:0 PCMU/8000 594 F13 ACK Bob -> Alice 596 ACK sips:a8342043f@atlanta.example.com;gr SIP/2.0 597 Via: SIP/2.0/TLS biloxi.example.com:5061 598 ;branch=z9hG4bKq874b 599 To: Alice ;tag=1234567 600 From: Bob ;tag=23431 601 Call-ID: 12345600@atlanta.example.com 602 CSeq: 713 ACK 603 Contact: 604 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 605 Supported: replaces 606 Content-Length: 0 608 F14 BYE Bob -> Music Source 610 BYE sips:music@source.example.com SIP/2.0 611 Via: SIP/2.0/TLS biloxi.example.com:5061 612 ;branch=z9hG4bK74rf 613 Max-Forwards: 70 614 From: Bob ;tag=02134 615 To: Music Source ;tag=56323 616 Call-ID: 4802029847@biloxi.example.com 617 CSeq: 2 BYE 618 Contact: 619 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 620 Supported: replaces, gruu 621 Content-Length: [omitted] 623 F15 200 OK Music Source -> Bob 625 SIP/2.0 200 OK 626 Via: SIP/2.0/TLS atlanta.example.com:5061 627 ;branch=z9hG4bK74rf 628 ;received=192.0.2.103 629 From: Bob ;tag=02134 630 To: Music Source ;tag=56323 631 Call-ID: 4802029847@biloxi.example.com 632 Contact: ;automaton 633 ;+sip.byeless;+sip.rendering="no" 634 CSeq: 2 BYE 635 Content-Length: 0 637 /* Normal media session between Alice and Bob is resumed */ 639 2.4. Re-INVITE and UPDATE from the Remote UA 641 While the call is on-hold, the remote UA can send a request to modify 642 the SDP or the feature parameters of its Contact header. This can be 643 done with either an INVITE or UPDATE method, both of which have much 644 the same effect in regard to MOH. 646 A common reason for a re-INVITE is when the remote UA desires to put 647 the dialog on hold on its end. And because of the need to support 648 this case, an implementation must process INVITEs and UPDATEs during 649 the on-hold state as described below. 651 The executing UA handles these requests by echoing requests and 652 responses: an incoming request from the remote UA causes the 653 executing UA to send a similar request to the MOH source and an 654 incoming response from the MOH source causes the executing UA to send 655 a similar response to the remote UA. In all cases, SDP offers or 656 answers that are received are added as bodies to the stimulated 657 request or response to the other UA. 659 The passed-through SDP will usually need its o= line modified. The 660 directionality attributes may need to be restricted. In regard to 661 payload type numbers, since the mapping has already been established 662 within the MOH dialog, a=rtpmap lines need not be added. 664 2.5. INVITE with Replaces 666 The executing UA must be prepared to receive INVITE requests with 667 Replaces headers that replace the original dialog, and similarly it 668 must be prepared to receive REFER requests within the dialog. The 669 SDP within the new dialog is negotiated by being passed through to 670 the MOH source within a new dialog with the MOH source. The SDP 671 offer or answer can be passed to the MOH source with only 672 modification to the o= line and directionality attributes. 674 In some cases, the previous dialog with the MOH source can be reused, 675 but only if the executing UA presents the first offer within the new 676 dialog, as otherwise there is no way to force the RTP payload types 677 that have been used previously in the MOH dialog to be mapped to the 678 correct codecs in the new dialog. 680 2.6. Re-INVITE and UPDATE from the Music-On-Hold Source 682 It is possible for the MOH source to send an INVITE or UPDATE 683 request, and the executing UA can support doing so in similar manner 684 as requests from the remote UA. However, if the MOH source is within 685 the same administrative domain as the executing UA, the executing UA 686 may have knowledge that the MOH source will not (or need not) make 687 such requests, and so can respond to any such request with a failure 688 response, avoiding the need to pass the request through. 690 However, in an environment in which ICE[ice] is supported, the MOH 691 source may need to send requests as part of ICE negotiation with the 692 remote UA. Hence, in environments that support ICE, the executing UA 693 must be able to pass through requests from the MOH source as well as 694 requests from the remote UA. 696 Again, as SDP is passed through, its o= line will need to be 697 modified. In some cases, the directionality attributes will need to 698 be restricted. 700 2.7. Handling Payload Type Numbers 702 2.7.1. Analysis 704 In this technique, the MOH source generates an SDP answer that the 705 executing UA presents to the remote UA as an answer within the 706 original dialog. In basic functionality, this presents no problem, 707 because [offer-answer] (section 6.1, at the very end) specifies that 708 the payload type numbers used in either direction of RTP are the ones 709 specified in the SDP sent by the recipient of the RTP. Thus, the MOH 710 source will send RTP to the remote UA using the payload type numbers 711 specified in the offer SDP it received (ultimately) from the remote 712 UA. 714 But strict compliance to [offer-answer] (section 8.3.2) requires that 715 payload type numbers used in SDP may only duplicate the payload type 716 numbers used in any previous SDP sent in the same direction if the 717 payload type numbers represent the same media format (codec) as they 718 did previously. However, the MOH source has no knowledge of the 719 payload type numbers previously used in the original dialog, and it 720 may accidentally specify a different media format for a previously 721 used payload type number in its answer (or in a subsequently 722 generated INVITE or UPDATE). This would cause no problem with media 723 decoding, as it cannot send any format that was not in the remote 724 UA's offer, but it would violate [offer-answer]. 726 Strictly speaking, it is impossible to avoid this problem because the 727 generator of a first answer in its dialog can choose the payload 728 numbers independently of the payload numbers in the offer, and the 729 MOH server believes that its answer is first in the dialog. Thus the 730 only absolute solution is to have the executing UA rewrite the SDP 731 that passes through it to reassign payload type numbers, which would 732 also require it to rewrite the payload type numbers in the RTP 733 packets -- a very undesirable solution. 735 The difficulty solving this problem (and similar problems in other 736 situations) argues that strict adherence should not be required to 737 the rule that payload type numbers not be reused for different 738 codecs. 740 The remainder of this section is devoted to describing a technique to 741 eliminate this problem, in case it is of practical significance in 742 some application. We do not expect that user agents would need to 743 implement it in most applications. 745 2.7.2. Solution to the Problem 747 However, we can construct a technique that will strictly adhere to 748 the payload type rule by exploiting a SHOULD-level requirement in 749 [offer-answer] (section 6.1): "In the case of RTP, if a particular 750 codec was referenced with a specific payload type number in the 751 offer, that same payload type number SHOULD be used for that codec in 752 the answer." Or rather, we exploit the "implied requirement" that if 753 a specific payload number in the offer is used for a particular 754 codec, then the answer should not use that payload number for a 755 different codec. If the MOH source obeys this restriction, the 756 executing UA can modify the offer SDP to "reserve" all payload type 757 numbers that have ever been offered by the executing UA to prevent 758 the MOH source from using them for different media formats. 760 When the executing UA is composing the INVITE to the MOH source, it 761 compiles a list of all the (dynamically-assigned) payload type 762 numbers and associated media formats which have been used by it (or 763 by MOH sources on its behalf) in the original dialog. (The executing 764 UA must be maintaining a list of all previously used payload type 765 numbers anyway, in order to comply with [offer-answer].) 767 Any payload type number that is present in the offer but has been 768 used previously by the executing UA in the original dialog for a 769 different media format is rewritten to describe a dummy media format. 770 A payload type number is added to describe the deleted media format, 771 the number being either previously unused or previously used by the 772 executing UA for that media format. 774 Any further payload type numbers which have been used by the 775 executing UA in the original dialog but which are not mapped to a 776 media format in the current offer are then mapped to a dummy media 777 format. 779 The result is that the modified offer SDP: 781 1. offers the same set of media formats (ignoring dummies) as the 782 original offer SDP (though possibly with different payload type 783 numbers), 785 2. associates every payload type number either with a dummy media 786 format or with the media format that the executing UA has 787 previously used it for, and 789 3. provides a (real or dummy) media format for every payload type 790 number that the executing UA has previously used. 792 These properties are sufficient to force an MOH server that obeys the 793 implied requirement to generate an answer that is a correct answer to 794 the original offer and is also compatible with previous SDP from the 795 executing UA. 797 Note that any re-INVITEs from the remote UA that the executing UA 798 passes through to the MOH server require similar modification, as 799 payload type numbers that the MOH server receives in past offers are 800 not absolutely reserved against its use (as they have not been sent 801 in SDP by the MOH server) nor is there a SHOULD-level proscription 802 against using them in the current answer (as they do not appear in 803 the current offer). 805 This should provide an adequate solution to the problems with payload 806 type numbers, as it will fail only if (1) the remote UA is particular 807 that other UAs follow the rule about not redefining payload type 808 numbers, and (2) the MOH server does not follow the implied 809 requirement of [offer-answer] section 6.1. 811 2.7.3. Example of the Solution 813 Let us show how this process works by modifying the example of 814 Section 2.3 with this specific assignment of supported codecs: 816 Alice supports formats X and Y 818 Bob supports formats X and Z 820 Music Source supports formats Y and Z 822 In this case, the SDP exchanges are: 824 F1 offers X and Y, F3 answers X and Z (which cannot be used) 826 F6 offers X and Y, but F7 offers X, Y, and a place-holder to block 827 use of type 92 829 F8/F10 answers Y 831 The messages that are changed from Section 2.3 are: 833 F1 INVITE Alice -> Bob 835 INVITE sips:bob@biloxi.example.com SIP/2.0 836 Via: SIP/2.0/TLS atlanta.example.com:5061 837 ;branch=z9hG4bK74bf9 838 Max-Forwards: 70 839 From: Alice ;tag=1234567 840 To: Bob 841 Call-ID: 12345600@atlanta.example.com 842 CSeq: 1 INVITE 843 Contact: 844 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 845 Supported: replaces, gruu 846 Content-Type: application/sdp 847 Content-Length: [omitted] 849 v=0 850 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 851 s= 852 c=IN IP4 atlanta.example.com 853 t=0 0 854 m=audio 49170 RTP/AVP 90 91 855 a=rtpmap:90 X/8000 856 a=rtpmap:91 Y/8000 858 F3 200 OK Bob -> Alice 860 SIP/2.0 200 OK 861 Via: SIP/2.0/TLS atlanta.example.com:5061 862 ;branch=z9hG4bK74bf9 863 ;received=192.0.2.103 864 From: Alice ;tag=1234567 865 To: Bob ;tag=23431 866 Call-ID: 12345600@atlanta.example.com 867 CSeq: 1 INVITE 868 Contact: 869 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 870 Supported: replaces 871 Content-Type: application/sdp 872 Content-Length: [omitted] 874 v=0 875 o=bob 2890844527 2890844527 IN IP4 biloxi.example.com 876 s= 877 c=IN IP4 biloxi.example.com 878 t=0 0 879 m=audio 3456 RTP/AVP 90 92 880 a=rtpmap:90 X/8000 881 a=rtpmap:92 Z/8000 883 F6 200 OK Alice -> Bob 885 SIP/2.0 200 OK 886 Via: SIP/2.0/TLS biloxi.example.com:5061 887 ;branch=z9hG4bK874bk 888 ;received=192.0.2.105 889 To: Alice ;tag=1234567 890 From: Bob ;tag=23431 891 Call-ID: 12345600@atlanta.example.com 892 CSeq: 712 INVITE 893 Contact: 894 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 895 Supported: replaces, gruu 896 Content-Type: application/sdp 897 Content-Length: [omitted] 899 v=0 900 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 901 s= 902 c=IN IP4 atlanta.example.com 903 t=0 0 904 m=audio 49170 RTP/AVP 90 91 905 a=rtpmap:90 X/8000 906 a=rtpmap:91 Y/8000 907 a=active 909 F7 INVITE Bob -> Music Source 911 INVITE sips:music@source.example.com SIP/2.0 912 Via: SIP/2.0/TLS biloxi.example.com:5061 913 ;branch=z9hG4bKnashds9 914 Max-Forwards: 70 915 From: Bob ;tag=02134 916 To: Music Source 917 Call-ID: 4802029847@biloxi.example.com 918 CSeq: 1 INVITE 919 Contact: 920 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 921 Supported: replaces, gruu 922 Content-Type: application/sdp 923 Content-Length: [omitted] 925 v=0 926 o=bob 2890844534 2890844534 IN IP4 atlanta.example.com 927 s= 928 c=IN IP4 atlanta.example.com 929 t=0 0 930 m=audio 49170 RTP/AVP 90 91 92 931 a=rtpmap:90 X/8000 932 a=rtpmap:91 Y/8000 933 a=rtpmap:92 x-reserved/8000 934 a=recvonly 936 F8 200 OK Music Source -> Bob 938 SIP/2.0 200 OK 939 Via: SIP/2.0/TLS biloxi.example.com:5061 940 ;branch=z9hG4bKnashds9 941 ;received=192.0.2.105 942 From: Bob ;tag=02134 943 To: Music Source ;tag=56323 944 Call-ID: 4802029847@biloxi.example.com 945 Contact: ;automaton 946 ;+sip.byeless;+sip.rendering="no" 947 CSeq: 1 INVITE 948 Content-Length: [omitted] 950 v=0 951 o=MusicSource 2890844576 2890844576 IN IP4 source.example.com 952 s= 953 c=IN IP4 source.example.com 954 t=0 0 955 m=audio 49170 RTP/AVP 91 956 a=rtpmap:91 Y/8000 957 a=sendonly 959 2.8. Dialog/Session Timers 961 The executing UA may discover that either the remote UA or the MOH 962 source wishes to use dialog/session liveness timers.[timers] Since 963 the timers verify the liveness of dialogs, not sessions (despite the 964 terminology of [timers]), the executing UA can support the timers on 965 each dialog (to the remote UA and to the MOH source) independently. 966 (If the executing UA becomes obliged to initiate a refresh 967 transaction, it must send an offerless UPDATE or re-INVITE, as if it 968 sends an offer, the remote element has the opportunity to provide an 969 answer which is different from its previous SDP, which could not 970 easily be conveyed to the other remote element.) 972 2.9. When the Media Stream Directionality is "inactive" 974 The directionality of the media stream in the SDP offer in an INVITE 975 or re-INVITE to the music source can be "inactive" if the SDP offer 976 from the remote UA was "sendonly" or "inactive". Generally, this 977 happens when the remote UA also has put the call on hold and provided 978 a directionality of "sendonly". In this situation, the executing UA 979 can omit establishing the dialog with the music source (or can 980 terminate the existing dialog with the music source). 982 If the executing UA uses this optimization, it creates the SDP answer 983 itself, with directionality "inactive" and using its own RTP/RTCP 984 ports, and returns that answer to the remote UA. 986 The executing UA must be prepared for the remote UA to send a re- 987 INVITE with directionality "active" or "recvonly", in which case the 988 executing UA must initiate a dialog with the music source, as 989 described above. 991 2.10. Multiple Media Streams 993 There may be multiple media streams (multiple m= lines) in any of the 994 the SDPs involved in the dialogs. As the SDPs are manipulated, each 995 media description (each starting with an m= line) is manipulated as 996 described above for a single media stream, largely independently of 997 the manipulation of the other media streams. But there are some 998 elaborations that the executing UA may implement to achieve specific 999 effects. 1001 If the executing UA desires to present only certain media types as 1002 on-hold media, when passing the offer SDP through, it can reject any 1003 particular media streams by setting the port number in the m= line to 1004 zero.[offer-answer] This ensures that the answer SDP will also have a 1005 rejection for that m= line. 1007 If the executing UA wishes to provide its own on-hold media for a 1008 particular m= line, it can do so by providing the answer information 1009 for that m= line. The executing UA may decide to do this when the 1010 offer SDP is received (by modifying the m= line to rejected state 1011 when sending it to the music source), or upon receiving the answer 1012 from the music source and discovering that the m= line has been 1013 rejected. 1015 The executing UA may not want to pass a rejected m= line from the 1016 music source to the remote UA (when the remote UA provided a non- 1017 rejected m= line), and instead provide an answer with directionality 1018 "inactive" (and specifying its own RTP/RTCP ports). 1020 3. Advantages 1022 This technique for providing music-on-hold has advantages over other 1023 methods now in use: 1025 1. The original dialog is not transferred to another UA, so the 1026 "remote endpoint URI" displayed by the remote endpoint's user 1027 interface and dialog event package[dialog-event] does not change 1028 during the call, as contrasted to the method in 1029 [service-examples] section 2.3. This URI is usually displayed to 1030 the user as the the name and number of the other party on the 1031 call, and it is desirable for it not to change to that of the MOH 1032 server. 1034 2. Compared to [service-examples], this method does not require use 1035 of an out-of-dialog REFER, which is not otherwise used much in 1036 SIP. Out-of-dialog REFERs may not be routed correctly, since 1037 neither the From nor Contact URI of the original dialog may route 1038 correctly to the remote UA. Also, out-of-dialog requests to UA 1039 URIs may not be handled correctly by authorization mechanisms. 1041 3. The music-on-hold media are sent directly from the music-on-hold 1042 source to the remote UA, rather than being relayed through the 1043 executing UA. This reduces the computational load on the 1044 executing UA and can reduce the load on the network (by 1045 eliminating "hairpinning" of the media through the link serving 1046 the executing UA). 1048 4. The remote UA sees, in the incoming SDP, the address/port that 1049 the MOH source will send MOH media from (assuming that the MOH 1050 source follows the convention of sending its media from its 1051 advertised media listening address/port). Thus the remote UA 1052 will render the MOH media even if is filtering incoming media 1053 based on originating address as a media security measure. 1055 5. The technique requires relatively simple manipulation of SDP, and 1056 in particular: (1) does not require a SIP element to modify 1057 unrelated SDP to be acceptable to be sent within an already 1058 established sequence of SDP (a problem with [service-examples-11] 1059 section 2.3), and (2) does not require converting an SDP answer 1060 into an SDP offer (which was a problem with the -00 version of 1061 this document, as well as with [service-examples-11]). 1063 4. Caveats 1065 4.1. Offering All Available Media Formats 1067 Unnecessary failures can happen if SDP offerers do not always offer 1068 all media formats that they support. Doing so is considered best 1069 practice ([offer-answer-bis] section 5.1 and 5.3), but some elements 1070 offer only formats that have already been in use in the dialog. 1072 An example of how omitting media formats in an offer can lead to 1073 failure is as follows: Suppose that the UAs in Section 2.3 each 1074 support the following media formats: 1076 Alice supports formats X and Y 1078 Bob supports formats X and Z 1080 Music Source supports formats Y and Z 1082 In this case, the SDP exchanges are: 1084 1. Alice calls Bob: 1085 Alice offers X and Y (message F1) 1086 Bob answers X (F3) 1088 2. Bob puts Alice on hold: 1089 Alice (via Bob) offers X and Y (F6 and F7) 1090 Music Source (via Bob) answers Y (F8 and F10) 1092 3. Bob takes Alice off hold: 1093 Bob offers X and Z (F11) 1094 Alice answers X (F12) 1096 Note that in exchange 2, if Alice assumes that because only format X 1097 is in use that she should offer only X, the exchange fails. In 1098 exchange 3, Bob offers formats X and Z, even though neither is in use 1099 at the time (because Bob is not involved in the media streams). 1101 4.2. Handling re-INVITES in a B2BUA 1103 Many UAs provide MOH in the interval during which it is processing a 1104 blind transfer, between receiving the REFER and receiving the final 1105 response to the stimulated INVITE. This process involves switching 1106 the user's interface between three media sources: (1) the session of 1107 the original dialog, (2) the session with the MOH server, and (3) the 1108 session of the new dialog, and involves a number of race conditions 1109 that must be handled correctly. If the UA is a B2BUA whose "other 1110 side" is maintaining a single dialog with another UA, each switching 1111 of media sources potentially causes a re-INVITE transaction within 1112 the other-side dialog. Since re-INVITEs take time and must be 1113 sequenced correctly ([sip] section 14), such a B2BUA must allow the 1114 events on each side to be non-synchronous and must coordinate them 1115 correctly. Failing to do so will lead to "glare" errors (491 or 1116 500), leaving the other-side UA not rendering the correct session. 1118 5. Security Considerations 1120 Some UAs filter incoming media based on the address of origin as a 1121 media security measure. The technique described in this document 1122 ensures that any UA that should render MOH media will be informed of 1123 the source address of the media via the SDP that it receives. This 1124 should allow such UAs to filter without interfering with MOH 1125 operation. 1127 6. Acknowledgments 1129 The original version of this proposal was derived from 1130 [service-examples-11] section 2.3 and the similar implementation of 1131 MOH in the Snom UA. Significant improvements to the sequence of 1132 operations, allowing improvements to the SDP handling, were suggested 1133 by Venkatesh[venkatesh]. 1135 John Elwell[elwell] pointed out the need for the executing UA to pass 1136 through re-INVITEs/UPDATEs in order to allow ICE negotiation, 1137 suggested mentioning the role of RTCP listening ports, suggested the 1138 possibility of omitting the dialog to the music source if the 1139 directionality would be "inactive", and pointed that if there are 1140 multiple media streams, the executing UA may want to select which 1141 streams receive MOH. 1143 Paul Kyzivat[kyzivat-1][kyzivat-2] pointed out the difficulties 1144 regarding reuse of payload type numbers and considerations that could 1145 be used to avoid those difficulties, leading to the writing of 1146 Section 2.7. 1148 Paul Kyzivat suggested adding Section 4.1 showing why offerers should 1149 always include all supported formats. 1151 M. Ranganathan pointed out the difficulties experienced by a B2BUA 1152 (Section 4.2) due to the multiple changes of media source. 1154 Section 4.1 was significantly clarified based on advice from Attila 1155 Sipos[sipos]. 1157 The need to discuss dialog/session timers[Section 2.8] was pointed 1158 out by Rifaat Shekh-Yusef[shekh-yusef]. 1160 Robert Sparks clarified the purpose of the "Best Common Practice" 1161 status, leading to revising the intended status of this document to 1162 "Informational".[Section 1.1] 1164 7. Revision History 1166 (Note to RFC Editor: Please remove this entire section upon 1167 publication as an RFC. 1169 7.1. Changes from draft-worley-service-example-00 to 1170 draft-worley-service-example-01 1172 Removed the original "Example Message Flow" and promoted the 1173 "Alternative Example Message Flow" to replace it because of a number 1174 of flaws that were found during the discussion of -00 on the SIPPING 1175 mailing list. 1177 Described the use of the sip.rendering feature parameter to indicate 1178 on-hold status. 1180 7.2. Changes from draft-worley-service-example-01 to 1181 draft-worley-service-example-02 1183 Added discussion of passing though re-INVITEs and UPDATEs. 1185 Added discussion of payload type numbers. 1187 Added Acknowledgments section. 1189 7.3. Changes from draft-worley-service-example-02 to 1190 draft-worley-service-example-03 1192 Added Section 4.1 showing the importance of the offerer always 1193 including all supported media formats. 1195 Updated references. 1197 Revised handling of payload type numbers when passing offer to MOH 1198 server Section 2.7, based on observations by Paul Kyzivat. 1200 7.4. Changes from draft-worley-service-example-03 to 1201 draft-worley-service-example-04 1203 Added Section 4.2 discussing handling of re-INVITEs by B2BUAs when 1204 using this method. 1206 Added "avoidance of out-of-dialog REFER" as an advantage.Section 3 1208 Added "automaton", "sip.rendering", and "sip.byeless" feature tags to 1209 the Contact URI of the Music Server in the 1210 examples.[dialog-event][ua-capabilities] 1211 Added initial discussion of dialog/session timer support.Section 2.8 1213 Revised handling of payload type numbers based on further 1214 observations by Paul Kyzivat[kyzivat-2]. 1216 7.5. Changes from draft-worley-service-example-04 to 1217 draft-worley-service-example-05 1219 Changed references to "SPIT" to refer to "media security", per 1220 suggestion by Scott Lawrence. 1222 Removed reference to the idea of having the executing UA not maintain 1223 session timers itself, but rather, passing through session timer 1224 negotiation and updates. Examination showed this idea to be much 1225 more complex to implement than having the executing UA terminate 1226 session timers itself for both dialogs. (Suggested by Rifaat Shekh- 1227 Yusef.) 1229 On advice from Robert Sparks, changed the "intended status" from 1230 "BCP" to "Informational", and added a section to explain the change. 1232 Noted that the rule on not reusing payload type numbers is 1233 undesirable because it complicates third-party operations (as noted 1234 by Paul Kyzivat[kyzivat-3]). 1236 7.6. Changes from draft-worley-service-example-05 to 1237 draft-worley-service-example-06 1239 Updated author's contact information. 1241 On suggestion from John Elwell, added mention that the Music Source's 1242 SDP address/port implies its RTCP address/port, which will be used to 1243 receive RTCP. 1245 Updated references to [service-examples] and [service-examples-11] to 1246 specify the sections of documents, which are the ones that discuss 1247 music on hold. 1249 7.7. Changes from draft-worley-service-example-06 to 1250 draft-worley-service-example-07 1252 Update reference to [offer-answer-bis] to refer to the -18 version. 1254 7.8. Changes from draft-worley-service-example-07 to 1255 draft-worley-service-example-08 1257 Sections Section 2.9 and Section 2.10 added at the suggestion of John 1258 Elwell. 1260 7.9. Changes from draft-worley-service-example-08 to 1261 draft-worley-service-example-09 1263 Update reference to [offer-answer-bis] to refer to RFC 6337. 1265 8. References 1267 8.1. Normative References 1269 [offer-answer] 1270 Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1271 with the Session Description Protocol (SDP)", RFC 3264, 1272 June 2002. 1274 [sdp] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1275 Description Protocol", RFC 4566, July 2006. 1277 [sip] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1278 A., Peterson, J., Sparks, R., Handley, M., and E. 1279 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1280 June 2002. 1282 [timers] Donovan, S. and J. Rosenberg, "Session Timers in the 1283 Session Initiation Protocol (SIP)", RFC 4028, April 2005. 1285 8.2. Informative References 1287 [dialog-event] 1288 Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 1289 Initiated Dialog Event Package for the Session Initiation 1290 Protocol (SIP)", RFC 4235, November 2005. 1292 [elwell] Elwell, J., "Subject: [Sipping] RE: I-D 1293 Action:draft-worley-service-example-00.txt", IETF Sipping 1294 mailing list msg14678, November 2007. 1296 [ice] Rosenberg, J., "Interactive Connectivity Establishment 1297 (ICE): A Protocol for Network Address Translator (NAT) 1298 Traversal for Offer/Answer Protocols", RFC 5245, 1299 April 2010. 1301 [kyzivat-1] 1302 Kyzivat, P., "Subject: Re: [Sipping] I-D 1303 ACTION:draft-ietf-sipping-service-examples-11.txt", IETF 1304 Sipping mailing list msg12181, October 2006. 1306 [kyzivat-2] 1307 Kyzivat, P., "[Sip-implementors] 1308 draft-worley-service-example-02", sip-implementors mailing 1309 list 020426, September 2008. 1311 [kyzivat-3] 1312 Kyzivat, P., "[Sip-implementors] 1313 draft-worley-service-example-02", sip-implementors mailing 1314 list 020387, September 2008. 1316 [offer-answer-bis] 1317 Okumura, S., Sawada, T., and P. Kyzivat, "SIP (Session 1318 Initiation Protocol) Usage of the Offer/Answer Model", 1319 RFC 6337, August 2011. 1321 [service-examples] 1322 Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and 1323 K. Summers, "Session Initiation Protocol Service 1324 Examples", RFC 5359, October 200. 1326 [service-examples-11] 1327 Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and 1328 K. Summers, "Session Initiation Protocol Service 1329 Examples", I-D draft-ietf-sipping-service-examples-11, 1330 October 2006. 1332 [shekh-yusef] 1333 Rifaat Shekh-Yusef, "[sipcore] 1334 draft-worley-service-example-03", IETF Sipcore mailing 1335 list msg00580, July 2009. 1337 [sipos] Attila Sipos, "RE: [Sip-implementors] 1338 draft-worley-service-example-02", sip-implementors mailing 1339 list 022002, March 2009. 1341 [ua-capabilities] 1342 Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1343 "Indicating User Agent Capabilities in the Session 1344 Initiation Protocol (SIP)", RFC 3840, August 2004. 1346 [venkatesh] 1347 Venkatesh, "Subject: Re: [Sipping] I-D 1348 ACTION:draft-ietf-sipping-service-examples-11.txt", IETF 1349 Sipping mailing list msg12180, October 2006. 1351 Author's Address 1353 Dale R. Worley 1354 Avaya Inc. 1355 600 Technology Park Dr. 1356 Billerica, MA 01821 1357 US 1359 Email: dworley@avaya.com 1360 URI: http://www.avaya.com