idnits 2.17.1 draft-worley-service-example-15.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 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 858: '...e indicates "the request SHOULD NOT be...' RFC 2119 keyword, line 925: '...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 (November 08, 2013) is 3794 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: 'Sipping' is mentioned on line 1653, but not defined == Missing Reference: 'Sip-implementors' is mentioned on line 1647, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-15) exists of draft-ietf-sipping-service-examples-11 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dispatch D. Worley 3 Internet-Draft Ariadne 4 Intended status: Informational November 08, 2013 5 Expires: May 12, 2014 7 Session Initiation Protocol Service Example -- Music on Hold 8 draft-worley-service-example-15 10 Abstract 12 The "music on hold" feature is one of the features of telephone 13 systems that is most desired by buyers of business telephone systems. 14 "Music on hold" is where, when one party to a call has the call "on 15 hold", that party's telephone provides an audio stream (often music) 16 to be heard by the other party. Architectural features of SIP make 17 it difficult to implement music-on-hold in a way that is fully 18 compliant with the standards. The implementation of music-on-hold 19 described in this document is fully effective and standards- 20 compliant, and has a number of advantages over the methods previously 21 documented. In particular, it is less likely to produce peculiar 22 user interface effects and more likely to work in systems which 23 perform authentication than the music-on-hold method described in 24 section 2.3 of RFC 5359. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 12, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Technique . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Placing a Call on Hold and Establishing an External Media 63 Stream . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Taking a Call off Hold and Terminating the External Media 65 Stream . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.3. Example Message Flow . . . . . . . . . . . . . . . . . . 6 67 2.4. Receiving Re-INVITE and UPDATE from the Remote UA . . . . 15 68 2.5. Receiving INVITE with Replaces . . . . . . . . . . . . . 15 69 2.6. Receiving REFER from the Remote UA . . . . . . . . . . . 17 70 2.7. Receiving Re-INVITE and UPDATE from the Music-On-Hold 71 Source . . . . . . . . . . . . . . . . . . . . . . . . . 19 72 2.8. Handling Payload Type Numbers . . . . . . . . . . . . . . 19 73 2.8.1. Analysis . . . . . . . . . . . . . . . . . . . . . . 19 74 2.8.2. Solution to the Problem . . . . . . . . . . . . . . . 20 75 2.8.3. Example of the Solution . . . . . . . . . . . . . . . 21 76 2.9. Dialog/Session Timers . . . . . . . . . . . . . . . . . . 25 77 2.10. When the Media Stream Directionality is "inactive" . . . 25 78 2.11. Multiple Media Streams . . . . . . . . . . . . . . . . . 25 79 3. Advantages . . . . . . . . . . . . . . . . . . . . . . . . . 26 80 4. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 81 4.1. Offering All Available Media Formats . . . . . . . . . . 27 82 4.2. Handling Re-INVITES in a B2BUA . . . . . . . . . . . . . 28 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 84 5.1. Network security . . . . . . . . . . . . . . . . . . . . 28 85 5.2. SIP (signaling) security . . . . . . . . . . . . . . . . 29 86 5.3. RTP (media) security . . . . . . . . . . . . . . . . . . 29 87 5.4. Media filtering . . . . . . . . . . . . . . . . . . . . . 29 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 89 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 90 8. Revision History . . . . . . . . . . . . . . . . . . . . . . 31 91 8.1. Changes from draft-worley-service-example-00 to draft- 92 worley-service-example-01 . . . . . . . . . . . . . . . . 31 93 8.2. Changes from draft-worley-service-example-01 to draft- 94 worley-service-example-02 . . . . . . . . . . . . . . . . 31 95 8.3. Changes from draft-worley-service-example-02 to draft- 96 worley-service-example-03 . . . . . . . . . . . . . . . . 31 97 8.4. Changes from draft-worley-service-example-03 to draft- 98 worley-service-example-04 . . . . . . . . . . . . . . . . 31 99 8.5. Changes from draft-worley-service-example-04 to draft- 100 worley-service-example-05 . . . . . . . . . . . . . . . . 32 101 8.6. Changes from draft-worley-service-example-05 to draft- 102 worley-service-example-06 . . . . . . . . . . . . . . . . 32 103 8.7. Changes from draft-worley-service-example-06 to draft- 104 worley-service-example-07 . . . . . . . . . . . . . . . . 32 105 8.8. Changes from draft-worley-service-example-07 to draft- 106 worley-service-example-08 . . . . . . . . . . . . . . . . 33 107 8.9. Changes from draft-worley-service-example-08 to draft- 108 worley-service-example-09 . . . . . . . . . . . . . . . . 33 109 8.10. Changes from draft-worley-service-example-09 to draft- 110 worley-service-example-10 . . . . . . . . . . . . . . . . 33 111 8.11. Changes from draft-worley-service-example-10 to draft- 112 worley-service-example-11 . . . . . . . . . . . . . . . . 33 113 8.12. Changes from draft-worley-service-example-11 to draft- 114 worley-service-example-12 . . . . . . . . . . . . . . . . 33 115 8.13. Changes from draft-worley-service-example-12 to draft- 116 worley-service-example-13 . . . . . . . . . . . . . . . . 33 117 8.14. Changes from draft-worley-service-example-13 to draft- 118 worley-service-example-14 . . . . . . . . . . . . . . . . 33 119 8.15. Changes from draft-worley-service-example-14 to draft- 120 worley-service-example-15 . . . . . . . . . . . . . . . . 34 121 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 122 9.1. Normative References . . . . . . . . . . . . . . . . . . 34 123 9.2. Informative References . . . . . . . . . . . . . . . . . 34 124 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36 126 1. Introduction 128 Within SIP[RFC3261]-based systems, it is desirable to be able to 129 provide features that are similar to those provided by traditional 130 telephony systems. A frequently requested feature is "music on 131 hold": The music-on-hold feature is where, when one party to a call 132 has the call "on hold", that party's telephone provides an audio 133 stream (often music) to be heard by the other party. 135 Architectural features of SIP make it difficult to implement music- 136 on-hold in a way that is fully compliant with the standards. The 137 purpose of this document is to describe a method that is reasonably 138 simple yet fully effective and standards-compliant. This method has 139 significant advantages over other methods now in use, as described in 140 Section 3. 142 All current methods of implementing music-on-hold interoperate with 143 each other, in that the two user agents in a call can use different 144 methods for implementing music-on-hold with the same functionality as 145 if either of the methods was used by both user agents. Thus, there 146 is no loss of functionality if different music-on-hold methods are 147 used by different user agents within a telephone system, or if a 148 single user agent uses different methods within different calls, or 149 at different times within one call. 151 2. Technique 153 The essence of the technique is that when the executing UA (the 154 user's UA) performs a re-INVITE of the remote UA (the other user's 155 UA) to establish the hold state, it provides no SDP[RFC4566] 156 offer[RFC3264][RFC6337], thus compelling the remote UA to provide an 157 SDP offer. The executing UA then extracts the offer SDP from the 158 remote UA's 2xx response, and uses that as the offer SDP in a new 159 INVITE to the external media source. The external media source is 160 thus directed to provide media directly to the remote UA. The media 161 source's answer SDP is returned to the remote UA in the ACK to the 162 re-INVITE. 164 2.1. Placing a Call on Hold and Establishing an External Media Stream 166 1. The executing user instructs the executing UA to put the dialog 167 on-hold. 169 2. The executing UA sends a re-INVITE without SDP to the remote UA, 170 which forces the remote UA to provide an SDP offer in its 2xx 171 response. The Contact header of the re-INVITE includes the 172 '+sip.rendering="no"' field parameter to indicate that it is 173 putting the call on hold. ([RFC4235] section 5.2) 175 3. The remote UA sends a 2xx to the re-INVITE, and includes an SDP 176 offer giving its own listening address/port. If the remote UA 177 understands the sip.rendering feature parameter, the offer may 178 indicate that it will not send media by specifying the media 179 directionalities as "recvonly" (the reverse of "on-hold") or 180 "inactive". But the remote UA may offer to send media. 182 4. The executing UA uses this offer to derive the offer SDP of an 183 initial INVITE that it sends to the configured music-on-hold 184 (MOH) source. The SDP in this request is largely copied from the 185 SDP returned by the remote UA in the previous step, particularly 186 regarding the provided listening address/port and payload type 187 numbers. But the media directionalities are restricted to 188 "recvonly" or "inactive" as appropriate. The executing UA may 189 want or need to change the o= line. In addition, some a=rtpmap 190 lines may need to be added to control the assignment of RTP 191 payload type numbers.[Section 2.8] 193 5. The MOH source sends a 2xx response to the INVITE, which contains 194 an SDP answer that should include its media source address as its 195 listening address/port. This SDP must necessarily[RFC3264] 196 specify "sendonly" or "inactive" as the directionality for all 197 media streams. 199 Although this address/port should receive no RTP, the specified 200 port determines the port for receiving RTCP (and conventionally, 201 for sending RTCP[RFC4961]). 203 By convention, UAs use their declared RTP listening ports as 204 their RTP source ports as well.[RFC4961] The answer SDP will 205 reach the remote UA, thus informing it of the address/port from 206 which the MOH media will come, and presumably preventing the 207 remote UA from ignoring the MOH media if the remote UA filters 208 media packets based on the source address. This functionality 209 requires the SDP answer to contain the sending address in the c= 210 line, even though the MOH source does not receive RTP.) 212 6. The executing UA sends this SDP answer as its SDP answer in the 213 ACK for the re-INVITE to the remote UA. The o= line in the 214 answer must be modified to be within the sequence of o= lines 215 previously generated by the executing UA in the dialog. Any 216 dynamic payload type number assignments that have been created in 217 the answer must be recorded in the state of the original dialog. 219 7. Due to the sip.rendering feature parameter in the Contact of the 220 re-INVITE and the media directionality in the SDP answer 221 contained in the ACK, the on-hold state of the dialog is 222 established (at the executing end). 224 8. After this point, the MOH source generates RTP containing the 225 music-on-hold media, and sends it directly to the listening 226 address/port of the remote UA. The executing UA maintains two 227 dialogs (one to the remote UA, one to the MOH source), but does 228 not see or handle the MOH RTP. 230 2.2. Taking a Call off Hold and Terminating the External Media Stream 232 1. The executing user instructs the executing UA to take the dialog 233 off-hold. 235 2. The executing UA sends a re-INVITE to the remote UA with SDP that 236 requests to receive media. The Contact header of the re-INVITE 237 does not include the '+sip.rendering="no"' field parameter. (It 238 may contain a sip.rendering field parameter with value "yes" or 239 "unknown", or it may omit the field parameter.) Thus this INVITE 240 removes the on-hold state of the dialog (at the executing end). 242 (Note that the version in o= line of the offered SDP must account 243 for the SDP versions that were passed through from the MOH 244 source. Also note that any payload type numbers that were 245 assigned in SDP provided by the MOH source must be respected.) 247 3. When the remote UA sends a 2xx response to the re-INVITE, the 248 executing UA sends a BYE request in the dialog to the MOH source. 250 4. After this point, the MOH source does not generate RTP and 251 ordinary RTP flow is reestablished in the original dialog. 253 2.3. Example Message Flow 255 This section shows a message flow which is an example of this 256 technique. The scenario is: Alice establishes a call with Bob. Bob 257 then places the call on hold, with music-on-hold provided from an 258 external source. Bob then takes the call off hold. In this 259 scenario, Bob's user agent is the executing UA, while Alice's UA is 260 the remote UA. Note that this is just one possible message flow that 261 illustrates this technique; numerous variations on these operations 262 are allowed by the applicable standards. 264 Alice Bob Music Source 266 Alice establishes the call: 268 | | | 269 | INVITE F1 | | 270 |--------------->| | 271 | 180 Ringing F2 | | 272 |<---------------| | 273 | 200 OK F3 | | 274 |<---------------| | 275 | ACK F4 | | 276 |--------------->| | 277 | RTP | | 278 |<==============>| | 279 | | | 281 Bob places Alice on hold, compelling Alice's UA to provide SDP: 283 | | | 284 | INVITE F5 | | 285 | (no SDP) | | 286 |<---------------| | 287 | 200 OK F6 | | 288 | (SDP offer) | | 289 |--------------->| | 290 | | | 292 Bob's UA initiates music-on-hold: 294 | | | 295 | | INVITE F7 | 296 | | (SDP offer, | 297 | | rev. hold) | 298 | |------------->| 299 | | 200 OK F8 | 300 | | (SDP answer, | 301 | | hold) | 302 | |<-------------| 303 | | ACK F9 | 304 | |------------->| 305 | | | 307 Bob's UA provides an SDP answer containing the address/port 308 of the Music Source: 310 | | | 311 | ACK F10 | | 312 | (SDP answer, | | 313 | hold) | | 314 |<---------------| | 315 | no RTP | | 316 |<..............>| | 317 | Music-on-hold RTP | 318 |<==============================| 319 | | | 321 The music on hold is active. 323 Bob takes Alice off hold: 325 | | | 326 | INVITE F11 | | 327 | (SDP offer) | | 328 |<---------------| | 329 | 200 OK F12 | | 330 | (SDP answer) | | 331 |--------------->| | 332 | ACK F13 | | 333 |<---------------| | 334 | | BYE F14 | 335 | |------------->| 336 | | 200 F15 | 337 | |<-------------| 338 | RTP | | 339 |<==============>| | 340 | | | 342 The normal media session between Alice and Bob is resumed. 344 /* Alice calls Bob. */ 346 F1 INVITE Alice -> Bob 348 INVITE sips:bob@biloxi.example.com SIP/2.0 349 Via: SIP/2.0/TLS atlanta.example.com:5061 350 ;branch=z9hG4bK74bf9 351 Max-Forwards: 70 352 From: Alice ;tag=1234567 353 To: Bob 354 Call-ID: 12345600@atlanta.example.com 355 CSeq: 1 INVITE 356 Contact: 357 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 358 Supported: replaces, gruu 359 Content-Type: application/sdp 360 Content-Length: [omitted] 362 v=0 363 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 364 s= 365 c=IN IP4 atlanta.example.com 366 t=0 0 367 m=audio 49170 RTP/AVP 0 368 a=rtpmap:0 PCMU/8000 370 F2 180 Ringing Bob -> Alice 372 SIP/2.0 180 Ringing 373 Via: SIP/2.0/TLS atlanta.example.com:5061 374 ;branch=z9hG4bK74bf9 375 ;received=192.0.2.103 376 From: Alice ;tag=1234567 377 To: Bob ;tag=23431 378 Call-ID: 12345600@atlanta.example.com 379 CSeq: 1 INVITE 380 Contact: 381 Content-Length: 0 382 F3 200 OK Bob -> Alice 384 SIP/2.0 200 OK 385 Via: SIP/2.0/TLS atlanta.example.com:5061 386 ;branch=z9hG4bK74bf9 387 ;received=192.0.2.103 388 From: Alice ;tag=1234567 389 To: Bob ;tag=23431 390 Call-ID: 12345600@atlanta.example.com 391 CSeq: 1 INVITE 392 Contact: 393 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 394 Supported: replaces 395 Content-Type: application/sdp 396 Content-Length: [omitted] 398 v=0 399 o=bob 2890844527 2890844527 IN IP4 biloxi.example.com 400 s= 401 c=IN IP4 biloxi.example.com 402 t=0 0 403 m=audio 3456 RTP/AVP 0 404 a=rtpmap:0 PCMU/8000 406 F4 ACK Alice -> Bob 408 ACK sips:bob@biloxi.example.com SIP/2.0 409 Via: SIP/2.0/TLS atlanta.example.com:5061 410 ;branch=z9hG4bK74bfd 411 Max-Forwards: 70 412 From: Alice ;tag=1234567 413 To: Bob ;tag=23431 414 Call-ID: 12345600@atlanta.example.com 415 CSeq: 1 ACK 416 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 417 Supported: replaces 418 Content-Length: 0 420 /* Bob places Alice on hold. */ 422 /* The re-INVITE contains no SDP, thus compelling Alice's UA 423 to provide an offer. */ 425 F5 INVITE Bob -> Alice 427 INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0 428 Via: SIP/2.0/TLS biloxi.example.com:5061 429 ;branch=z9hG4bK874bk 430 To: Alice ;tag=1234567 431 From: Bob ;tag=23431 432 Call-ID: 12345600@atlanta.example.com 433 CSeq: 712 INVITE 434 Contact: ;+sip.rendering="no" 435 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 436 Supported: replaces 437 Content-Length: 0 439 /* Alice's UA provides an SDP offer. 440 Since it does not know that it is being put on hold, 441 the offer is the same as the original offer and describes 442 bidirectional media. */ 444 F6 200 OK Alice -> Bob 446 SIP/2.0 200 OK 447 Via: SIP/2.0/TLS biloxi.example.com:5061 448 ;branch=z9hG4bK874bk 449 ;received=192.0.2.105 450 To: Alice ;tag=1234567 451 From: Bob ;tag=23431 452 Call-ID: 12345600@atlanta.example.com 453 CSeq: 712 INVITE 454 Contact: 455 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 456 Supported: replaces, gruu 457 Content-Type: application/sdp 458 Content-Length: [omitted] 460 v=0 461 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 462 s= 463 c=IN IP4 atlanta.example.com 464 t=0 0 465 m=audio 49170 RTP/AVP 0 466 a=rtpmap:0 PCMU/8000 467 a=active 469 /* Bob's UA initiates music-on-hold. */ 471 /* This INVITE contains Alice's offer, but with the media 472 direction set to "reverse hold", receive-only. */ 474 F7 INVITE Bob -> Music Source 475 INVITE sips:music@source.example.com SIP/2.0 476 Via: SIP/2.0/TLS biloxi.example.com:5061 477 ;branch=z9hG4bKnashds9 478 Max-Forwards: 70 479 From: Bob ;tag=02134 480 To: Music Source 481 Call-ID: 4802029847@biloxi.example.com 482 CSeq: 1 INVITE 483 Contact: 484 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 485 Supported: replaces, gruu 486 Content-Type: application/sdp 487 Content-Length: [omitted] 489 v=0 490 o=bob 2890844534 2890844534 IN IP4 atlanta.example.com 491 s= 492 c=IN IP4 atlanta.example.com 493 t=0 0 494 m=audio 49170 RTP/AVP 0 495 a=rtpmap:0 PCMU/8000 496 a=recvonly 498 F8 200 OK Music Source -> Bob 500 SIP/2.0 200 OK 501 Via: SIP/2.0/TLS biloxi.example.com:5061 502 ;branch=z9hG4bKnashds9 503 ;received=192.0.2.105 504 From: Bob ;tag=02134 505 To: Music Source ;tag=56323 506 Call-ID: 4802029847@biloxi.example.com 507 Contact: ;automaton 508 ;+sip.byeless;+sip.rendering="no" 509 CSeq: 1 INVITE 510 Content-Length: [omitted] 512 v=0 513 o=MusicSource 2890844576 2890844576 IN IP4 source.example.com 514 s= 515 c=IN IP4 source.example.com 516 t=0 0 517 m=audio 49170 RTP/AVP 0 518 a=rtpmap:0 PCMU/8000 519 a=sendonly 520 F9 ACK Bob -> Music Source 522 ACK sips:music@source.example.com SIP/2.0 523 Via: SIP/2.0/TLS source.example.com:5061 524 ;branch=z9hG4bK74bT6 525 From: Bob ;tag=02134 526 To: Music Source ;tag=56323 527 Max-Forwards: 70 528 Call-ID: 4802029847@biloxi.example.com 529 CSeq: 1 ACK 530 Content-Length: 0 532 /* Bob's UA now sends the ACK that completes the re-INVITE 533 to Alice and completes the SDP offer/answer. 534 The ACK contains the SDP received from the Music Source, 535 and thus contains the address/port from which the Music Source 536 will send media, and implies the address/port which the Music 537 Source will use to send/receive RTCP. */ 539 F10 ACK Bob -> Alice 541 ACK sips:a8342043f@atlanta.example.com;gr SIP/2.0 542 Via: SIP/2.0/TLS biloxi.example.com:5061 543 ;branch=z9hG4bKq874b 544 To: Alice ;tag=1234567 545 From: Bob ;tag=23431 546 Call-ID: 12345600@atlanta.example.com 547 CSeq: 712 ACK 548 Contact: ;+sip.rendering="no" 549 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 550 Supported: replaces 551 Content-Length: [omitted] 553 v=0 554 o=bob 2890844527 2890844528 IN IP4 biloxi.example.com 555 s= 556 c=IN IP4 source.example.com 557 t=0 0 558 m=audio 49170 RTP/AVP 0 559 a=rtpmap:0 PCMU/8000 560 a=sendonly 562 /* Bob picks up the call by sending a re-INVITE to Alice. */ 564 F11 INVITE Bob -> Alice 566 INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0 567 Via: SIP/2.0/TLS biloxi.example.com:5061 568 ;branch=z9hG4bK874bk 569 To: Alice ;tag=1234567 570 From: Bob ;tag=23431 571 Call-ID: 12345600@atlanta.example.com 572 CSeq: 713 INVITE 573 Contact: 574 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 575 Supported: replaces 576 Content-Type: application/sdp 577 Content-Length: [omitted] 579 v=0 580 o=bob 2890844527 2890844529 IN IP4 biloxi.example.com 581 s= 582 c=IN IP4 biloxi.example.com 583 t=0 0 584 m=audio 3456 RTP/AVP 0 585 a=rtpmap:0 PCMU/8000 587 F12 200 OK Alice -> Bob 589 SIP/2.0 200 OK 590 Via: SIP/2.0/TLS biloxi.example.com:5061 591 ;branch=z9hG4bK874bk 592 ;received=192.0.2.105 593 To: Alice ;tag=1234567 594 From: Bob ;tag=23431 595 Call-ID: 12345600@atlanta.example.com 596 CSeq: 713 INVITE 597 Contact: 598 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 599 Supported: replaces, gruu 600 Content-Type: application/sdp 601 Content-Length: [omitted] 603 v=0 604 o=alice 2890844526 2890844527 IN IP4 atlanta.example.com 605 s= 606 c=IN IP4 atlanta.example.com 607 t=0 0 608 m=audio 49170 RTP/AVP 0 609 a=rtpmap:0 PCMU/8000 611 F13 ACK Bob -> Alice 612 ACK sips:a8342043f@atlanta.example.com;gr SIP/2.0 613 Via: SIP/2.0/TLS biloxi.example.com:5061 614 ;branch=z9hG4bKq874b 615 To: Alice ;tag=1234567 616 From: Bob ;tag=23431 617 Call-ID: 12345600@atlanta.example.com 618 CSeq: 713 ACK 619 Contact: 620 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 621 Supported: replaces 622 Content-Length: 0 624 F14 BYE Bob -> Music Source 626 BYE sips:music@source.example.com SIP/2.0 627 Via: SIP/2.0/TLS biloxi.example.com:5061 628 ;branch=z9hG4bK74rf 629 Max-Forwards: 70 630 From: Bob ;tag=02134 631 To: Music Source ;tag=56323 632 Call-ID: 4802029847@biloxi.example.com 633 CSeq: 2 BYE 634 Contact: 635 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 636 Supported: replaces, gruu 637 Content-Length: [omitted] 639 F15 200 OK Music Source -> Bob 641 SIP/2.0 200 OK 642 Via: SIP/2.0/TLS atlanta.example.com:5061 643 ;branch=z9hG4bK74rf 644 ;received=192.0.2.103 645 From: Bob ;tag=02134 646 To: Music Source ;tag=56323 647 Call-ID: 4802029847@biloxi.example.com 648 Contact: ;automaton 649 ;+sip.byeless;+sip.rendering="no" 650 CSeq: 2 BYE 651 Content-Length: 0 653 /* Normal media session between Alice and Bob is resumed */ 655 2.4. Receiving Re-INVITE and UPDATE from the Remote UA 657 While the call is on-hold, the remote UA can send a request to modify 658 the SDP or the feature parameters of its Contact header. This can be 659 done with either an INVITE or UPDATE method, both of which have much 660 the same effect in regard to MOH. 662 A common reason for a re-INVITE is when the remote UA desires to put 663 the dialog on hold on its end. And because of the need to support 664 this case, an implementation must process INVITEs and UPDATEs during 665 the on-hold state as described below. 667 The executing UA handles these requests by echoing requests and 668 responses: an incoming request from the remote UA causes the 669 executing UA to send a similar request to the MOH source and an 670 incoming response from the MOH source causes the executing UA to send 671 a similar response to the remote UA. In all cases, SDP offers or 672 answers that are received are added as bodies to the stimulated 673 request or response to the other UA. 675 The passed-through SDP will usually need its o= line modified. The 676 directionality attributes may need to be restricted by changing 677 "active" to "recvonly" and "sendonly" to "inactive", as the executing 678 UA will not render media from the remote UA. (If all passed-through 679 directionality attributes are "inactive", the optimization described 680 in section Section 2.10 may be applied.) In regard to payload type 681 numbers, since the mapping has already been established within the 682 MOH dialog, a=rtpmap lines need not be added. 684 2.5. Receiving INVITE with Replaces 686 The executing UA must be prepared to receive an INVITE request with a 687 Replaces header that specifies the dialog with the remote UA. If the 688 executing UA wants to create this new dialog in the on-hold state, it 689 creates a new dialog with the MOH source to obtain MOH. The 690 executing UA negotiates the SDP within the dialog created by the 691 INVITE-with-Replaces by passing the offer through to the new MOH 692 dialog (if the INVITE contains an offer), or by creating the new MOH 693 dialog with an offerless INVITE (if the INVITE does not contain an 694 offer). 696 Continuing the example of Section 2.3, the executing UA receives an 697 INVITE-with-Replaces that contains an offer: 699 Alice Bob Music Source Carol 701 (For example, Alice has called Carol and initiates an attended 702 transfer by sending a REFER to Carol, causing Carol to send an 703 INVITE-with-Replaces to Bob.) 705 Bob receives INVITE-with-Replaces from Carol: 707 | | | | 708 | | | INVITE/Replaces | 709 | | | From: Carol | 710 | | | To: Bob | 711 | | | (SDP offer) | 712 | |<-------------------------------| 713 | | INVITE | | 714 | | From: Bob | | 715 | | To: Music Source | 716 | | (SDP offer, | | 717 | | rev. hold) | | 718 | |------------->| | 719 | | 200 OK | | 720 | | From: Bob | | 721 | | To: Music Source | 722 | | (SDP answer, | | 723 | | hold) | | 724 | |<-------------| | 725 | | ACK | | 726 | | From: Bob | | 727 | | To: Music Source | 728 | |------------->| | 729 | | | 200 OK | 730 | | | From: Carol | 731 | | | To: Bob | 732 | | | (SDP answer, | 733 | | | hold) | 734 | |------------------------------->| 735 | | | ACK | 736 | | | From: Carol | 737 | | | To: Bob | 738 | |<-------------------------------| 739 | | | Music-on-hold RTP 740 | | |================>| 741 | | | | 743 Bob terminates the previous dialog with Alice: 745 | | | | 746 | BYE | | | 747 | From: Bob | | | 748 | To: Alice | | | 749 |<---------------| | | 750 | 200 OK | | | 751 | From: Bob | | | 752 | To: Alice | | | 753 |--------------->| | | 754 | | | | 756 Bob terminates the MOH dialog for the dialog with Alice: 758 | | | | 759 | | BYE | | 760 | | From: Bob | | 761 | | To: Music Source | 762 | |------------->| | 763 | | 200 OK | | 764 | | From: Music Source | 765 | | To: Bob | | 766 | |<-------------| | 767 | | | | 769 The new session continues on hold, between Bob and Carol. 771 2.6. Receiving REFER from the Remote UA 773 The executing UA must be prepared to receive a REFER request within 774 the dialog with the remote UA. The SDP within the dialog created by 775 the REFER is negotiated by sending an offerless INVITE (or offerless 776 re-INVITE) to the MOH source to obtain an offer, and then using that 777 offer in the INVITE to the refer target. 779 Similar processing is used for an out-of-dialog REFER whose Target- 780 Dialog header refers to the dialog with the remote UA. 782 Continuing the example of Section 2.3, the executing UA receives an 783 INVITE-with-Replaces that contains an offer: 785 Alice Bob Music Source Carol 787 (For example, Alice initiates an unattended transfer of the call to 788 Carol by sending a REFER to Bob.) 790 Bob receives REFER from Alice: 792 | | | | 793 | REFER | | | 794 | From: Bob | | | 795 | To: Alice | | | 796 | Refer-To: Carol| | | 797 |--------------->| | | 798 | | re-INVITE | | 799 | | From: Bob | | 800 | | To: Music Source | 801 | | (no SDP) | | 802 | |------------->| | 803 | | 200 OK | | 804 | | From: Bob | | 805 | | To: Music Source | 806 | | (SDP offer, | | 807 | | hold) | | 808 | |<-------------| | 809 | | | INVITE | 810 | | | From: Bob | 811 | | | To: Carol | 812 | | | (SDP offer, | 813 | | | hold) | 814 | |------------------------------->| 815 | | | 200 OK | 816 | | | From: Bob | 817 | | | To: Carol | 818 | | | (SDP answer, | 819 | | | rev. hold) | 820 | |------------------------------->| 821 | | ACK | | 822 | | From: Bob | | 823 | | To: Music Source | 824 | | (SDP answer, | | 825 | | rev. hold) | | 826 | |------------->| | 827 | | | ACK | 828 | | | From: Bob | 829 | | | To: Carol | 830 | |------------------------------->| 831 | | | Music-on-hold RTP 832 | | |================>| 833 | | | | 835 Bob terminates the previous dialog with Alice: 837 | | | | 838 | BYE | | | 839 | From: Bob | | | 840 | To: Alice | | | 841 |<---------------| | | 842 | 200 OK | | | 843 | From: Bob | | | 844 | To: Alice | | | 845 |--------------->| | | 846 | | | | 848 2.7. Receiving Re-INVITE and UPDATE from the Music-On-Hold Source 850 It is possible for the MOH source to send a re-INVITE or UPDATE 851 request, and the executing UA can support doing so in similar manner 852 as requests from the remote UA. However, if the MOH source is within 853 the same administrative domain as the executing UA, the executing UA 854 may have knowledge that the MOH source will not (or need not) make 855 such requests, and so can respond to any such request with a failure 856 response, avoiding the need to pass the request through. The 403 857 (Forbidden) response is suitable for this purpose because [RFC3261] 858 specifies that this response indicates "the request SHOULD NOT be 859 repeated". 861 However, in an environment in which ICE[RFC5245] is supported, the 862 MOH source may need to send requests as part of ICE negotiation with 863 the remote UA. Hence, in environments that support ICE, the 864 executing UA must be able to pass through requests from the MOH 865 source as well as requests from the remote UA. 867 Again, as SDP is passed through, its o= line will need to be 868 modified. In some cases, the directionality attributes will need to 869 be restricted. 871 2.8. Handling Payload Type Numbers 873 2.8.1. Analysis 875 In this technique, the MOH source generates an SDP answer that the 876 executing UA presents to the remote UA as an answer within the 877 original dialog. In basic functionality, this presents no problem, 878 because [RFC3264] (section 6.1, at the very end) specifies that the 879 payload type numbers used in either direction of RTP are the ones 880 specified in the SDP sent by the recipient of the RTP. Thus, the MOH 881 source will send RTP to the remote UA using the payload type numbers 882 specified in the offer SDP it received (ultimately) from the remote 883 UA. 885 But strict compliance to [RFC3264] (section 8.3.2) requires that 886 payload type numbers used in SDP may only duplicate the payload type 887 numbers used in any previous SDP sent in the same direction if the 888 payload type numbers represent the same media format (codec) as they 889 did previously. However, the MOH source has no knowledge of the 890 payload type numbers previously used in the original dialog, and it 891 may accidentally specify a different media format for a previously 892 used payload type number in its answer (or in a subsequently 893 generated INVITE or UPDATE). This would cause no problem with media 894 decoding, as it cannot send any format that was not in the remote 895 UA's offer, but it would violate [RFC3264]. 897 Strictly speaking, it is impossible to avoid this problem because the 898 generator of a first answer in its dialog can choose the payload 899 numbers independently of the payload numbers in the offer, and the 900 MOH server believes that its answer is first in the dialog. Thus the 901 only absolute solution is to have the executing UA rewrite the SDP 902 that passes through it to reassign payload type numbers, which would 903 also require it to rewrite the payload type numbers in the RTP 904 packets -- a very undesirable solution. 906 The difficulty solving this problem (and similar problems in other 907 situations) argues that strict adherence should not be required to 908 the rule that payload type numbers not be reused for different 909 codecs. 911 If an implementation of this technique were to interact with a remote 912 UA that requires strict compliance to [RFC3264], the remote UA might 913 reject the SDP provided by the MOH server. (In section Section 2.3, 914 this SDP is in message F10.) As a result, the MOH session will not 915 be established, and the call will remain in its initial state. 916 Implementors that wish to avoid this situation need to implement the 917 solution in Section 2.8.2. 919 2.8.2. Solution to the Problem 921 We can construct a technique that will strictly adhere to the payload 922 type rule by exploiting a SHOULD-level requirement in [RFC3264] 923 (section 6.1): "In the case of RTP, if a particular codec was 924 referenced with a specific payload type number in the offer, that 925 same payload type number SHOULD be used for that codec in the 926 answer." Or rather, we exploit the "implied requirement" that if a 927 specific payload number in the offer is used for a particular codec, 928 then the answer should not use that payload number for a different 929 codec. If the MOH source obeys this restriction, the executing UA 930 can modify the offer SDP to "reserve" all payload type numbers that 931 have ever been offered by the executing UA to prevent the MOH source 932 from using them for different media formats. 934 When the executing UA is composing the INVITE to the MOH source, it 935 compiles a list of all the (dynamically-assigned) payload type 936 numbers and associated media formats which have been used by it (or 937 by MOH sources on its behalf) in the original dialog. (The executing 938 UA must be maintaining a list of all previously used payload type 939 numbers anyway, in order to comply with [RFC3264].) 940 Any payload type number that is present in the offer but has been 941 used previously by the executing UA in the original dialog for a 942 different media format is rewritten to describe a dummy media format. 943 (One dummy media format name can be used for many payload type 944 numbers as multiple payload type numbers can refer to the same media 945 format.) A payload type number is added to describe the deleted 946 media format, the number being either previously unused or previously 947 used by the executing UA for that media format. 949 Any further payload type numbers which have been used by the 950 executing UA in the original dialog but which are not mapped to a 951 media format in the current offer are then mapped to a dummy media 952 format. 954 The result is that the modified offer SDP: 956 1. offers the same set of media formats (ignoring dummies) as the 957 original offer SDP (though possibly with different payload type 958 numbers), 960 2. associates every payload type number either with a dummy media 961 format or with the media format that the executing UA has 962 previously used it for, and 964 3. provides a (real or dummy) media format for every payload type 965 number that the executing UA has previously used. 967 These properties are sufficient to force an MOH server that obeys the 968 implied requirement to generate an answer that is a correct answer to 969 the original offer and is also compatible with previous SDP from the 970 executing UA. 972 Note that any re-INVITEs from the remote UA that the executing UA 973 passes through to the MOH server require similar modification, as 974 payload type numbers that the MOH server receives in past offers are 975 not absolutely reserved against its use (as they have not been sent 976 in SDP by the MOH server) nor is there a SHOULD-level proscription 977 against using them in the current answer (as they do not appear in 978 the current offer). 980 This should provide an adequate solution to the problems with payload 981 type numbers, as it will fail only if (1) the remote UA is particular 982 that other UAs follow the rule about not redefining payload type 983 numbers, and (2) the MOH server does not follow the implied 984 requirement of [RFC3264] section 6.1. 986 2.8.3. Example of the Solution 987 Let us show how this process works by modifying the example of 988 Section 2.3 with this specific assignment of supported codecs: 990 Alice supports formats X and Y 992 Bob supports formats X and Z 994 Music Source supports formats Y and Z 996 In this case, the SDP exchanges are: 998 F1 offers X and Y, F3 answers X and Z (which cannot be used) 1000 F6 offers X and Y, but F7 offers X, Y, and a place-holder to block 1001 use of type 92 1003 F8/F10 answers Y 1005 The messages that are changed from Section 2.3 are: 1007 F1 INVITE Alice -> Bob 1009 INVITE sips:bob@biloxi.example.com SIP/2.0 1010 Via: SIP/2.0/TLS atlanta.example.com:5061 1011 ;branch=z9hG4bK74bf9 1012 Max-Forwards: 70 1013 From: Alice ;tag=1234567 1014 To: Bob 1015 Call-ID: 12345600@atlanta.example.com 1016 CSeq: 1 INVITE 1017 Contact: 1018 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1019 Supported: replaces, gruu 1020 Content-Type: application/sdp 1021 Content-Length: [omitted] 1023 v=0 1024 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1025 s= 1026 c=IN IP4 atlanta.example.com 1027 t=0 0 1028 m=audio 49170 RTP/AVP 90 91 1029 a=rtpmap:90 X/8000 1030 a=rtpmap:91 Y/8000 1032 F3 200 OK Bob -> Alice 1033 SIP/2.0 200 OK 1034 Via: SIP/2.0/TLS atlanta.example.com:5061 1035 ;branch=z9hG4bK74bf9 1036 ;received=192.0.2.103 1037 From: Alice ;tag=1234567 1038 To: Bob ;tag=23431 1039 Call-ID: 12345600@atlanta.example.com 1040 CSeq: 1 INVITE 1041 Contact: 1042 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1043 Supported: replaces 1044 Content-Type: application/sdp 1045 Content-Length: [omitted] 1047 v=0 1048 o=bob 2890844527 2890844527 IN IP4 biloxi.example.com 1049 s= 1050 c=IN IP4 biloxi.example.com 1051 t=0 0 1052 m=audio 3456 RTP/AVP 90 92 1053 a=rtpmap:90 X/8000 1054 a=rtpmap:92 Z/8000 1056 F6 200 OK Alice -> Bob 1058 SIP/2.0 200 OK 1059 Via: SIP/2.0/TLS biloxi.example.com:5061 1060 ;branch=z9hG4bK874bk 1061 ;received=192.0.2.105 1062 To: Alice ;tag=1234567 1063 From: Bob ;tag=23431 1064 Call-ID: 12345600@atlanta.example.com 1065 CSeq: 712 INVITE 1066 Contact: 1067 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1068 Supported: replaces, gruu 1069 Content-Type: application/sdp 1070 Content-Length: [omitted] 1072 v=0 1073 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1074 s= 1075 c=IN IP4 atlanta.example.com 1076 t=0 0 1077 m=audio 49170 RTP/AVP 90 91 1078 a=rtpmap:90 X/8000 1079 a=rtpmap:91 Y/8000 1080 a=active 1082 F7 INVITE Bob -> Music Source 1084 INVITE sips:music@source.example.com SIP/2.0 1085 Via: SIP/2.0/TLS biloxi.example.com:5061 1086 ;branch=z9hG4bKnashds9 1087 Max-Forwards: 70 1088 From: Bob ;tag=02134 1089 To: Music Source 1090 Call-ID: 4802029847@biloxi.example.com 1091 CSeq: 1 INVITE 1092 Contact: 1093 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 1094 Supported: replaces, gruu 1095 Content-Type: application/sdp 1096 Content-Length: [omitted] 1098 v=0 1099 o=bob 2890844534 2890844534 IN IP4 atlanta.example.com 1100 s= 1101 c=IN IP4 atlanta.example.com 1102 t=0 0 1103 m=audio 49170 RTP/AVP 90 91 92 1104 a=rtpmap:90 X/8000 1105 a=rtpmap:91 Y/8000 1106 a=rtpmap:92 x-reserved/8000 1107 a=recvonly 1109 F8 200 OK Music Source -> Bob 1111 SIP/2.0 200 OK 1112 Via: SIP/2.0/TLS biloxi.example.com:5061 1113 ;branch=z9hG4bKnashds9 1114 ;received=192.0.2.105 1115 From: Bob ;tag=02134 1116 To: Music Source ;tag=56323 1117 Call-ID: 4802029847@biloxi.example.com 1118 Contact: ;automaton 1119 ;+sip.byeless;+sip.rendering="no" 1120 CSeq: 1 INVITE 1121 Content-Length: [omitted] 1123 v=0 1124 o=MusicSource 2890844576 2890844576 IN IP4 source.example.com 1125 s= 1126 c=IN IP4 source.example.com 1127 t=0 0 1128 m=audio 49170 RTP/AVP 91 1129 a=rtpmap:91 Y/8000 1130 a=sendonly 1132 2.9. Dialog/Session Timers 1134 The executing UA may discover that either the remote UA or the MOH 1135 source wishes to use dialog/session liveness timers.[RFC4028] Since 1136 the timers verify the liveness of dialogs, not sessions (despite the 1137 terminology of [RFC4028]), the executing UA can support the timers on 1138 each dialog (to the remote UA and to the MOH source) independently. 1139 (If the executing UA becomes obliged to initiate a refresh 1140 transaction, it must send an offerless UPDATE or re-INVITE, as if it 1141 sends an offer, the remote element has the opportunity to provide an 1142 answer which is different from its previous SDP, which could not 1143 easily be conveyed to the other remote element.) 1145 2.10. When the Media Stream Directionality is "inactive" 1147 The directionality of the media stream in the SDP offer in an INVITE 1148 or re-INVITE to the music source can be "inactive" if the SDP offer 1149 from the remote UA was "sendonly" or "inactive". Generally, this 1150 happens when the remote UA also has put the call on hold and provided 1151 a directionality of "sendonly". In this situation, the executing UA 1152 can omit establishing the dialog with the music source (or can 1153 terminate the existing dialog with the music source). 1155 If the executing UA uses this optimization, it creates the SDP answer 1156 itself, with directionality "inactive" and using its own RTP/RTCP 1157 ports, and returns that answer to the remote UA. 1159 The executing UA must be prepared for the remote UA to send a re- 1160 INVITE with directionality "active" or "recvonly", in which case the 1161 executing UA must initiate a dialog with the music source, as 1162 described above. 1164 2.11. Multiple Media Streams 1166 There may be multiple media streams (multiple m= lines) in any of the 1167 the SDPs involved in the dialogs. As the SDPs are manipulated, each 1168 media description (each starting with an m= line) is manipulated as 1169 described above for a single media stream, largely independently of 1170 the manipulation of the other media streams. But there are some 1171 elaborations that the executing UA may implement to achieve specific 1172 effects. 1174 If the executing UA desires to present only certain media types as 1175 on-hold media, when passing the offer SDP through, it can reject any 1176 particular media streams by setting the port number in the m= line to 1177 zero.[RFC3264] This ensures that the answer SDP will also have a 1178 rejection for that m= line. 1180 If the executing UA wishes to provide its own on-hold media for a 1181 particular m= line, it can do so by providing the answer information 1182 for that m= line. The executing UA may decide to do this when the 1183 offer SDP is received (by modifying the m= line to rejected state 1184 when sending it to the music source), or upon receiving the answer 1185 from the music source and discovering that the m= line has been 1186 rejected. 1188 The executing UA may not want to pass a rejected m= line from the 1189 music source to the remote UA (when the remote UA provided a non- 1190 rejected m= line), and instead provide an answer with directionality 1191 "inactive" (and specifying its own RTP/RTCP ports). 1193 3. Advantages 1195 This technique for providing music-on-hold has advantages over other 1196 methods now in use: 1198 1. The original dialog is not transferred to another UA, so the 1199 "remote endpoint URI" displayed by the remote endpoint's user 1200 interface and dialog event package[RFC4235] does not change 1201 during the call, as contrasted to the method in [RFC5359] section 1202 2.3. This URI is usually displayed to the user as the the name 1203 and number of the other party on the call, and it is desirable 1204 for it not to change to that of the MOH server. 1206 2. Compared to [RFC5359], this method does not require use of an 1207 out-of-dialog REFER, which is not otherwise used much in SIP. 1208 Out-of-dialog REFERs may not be routed correctly, since neither 1209 the From nor Contact URI of the original dialog may route 1210 correctly to the remote UA. Also, out-of-dialog requests to UA 1211 URIs may not be handled correctly by authorization mechanisms. 1213 3. The music-on-hold media are sent directly from the music-on-hold 1214 source to the remote UA, rather than being relayed through the 1215 executing UA. This reduces the computational load on the 1216 executing UA and can reduce the load on the network (by 1217 eliminating "hairpinning" of the media through the link serving 1218 the executing UA). 1220 4. The remote UA sees, in the incoming SDP, the address/port that 1221 the MOH source will send MOH media from (assuming that the MOH 1222 source follows the convention of sending its media from its 1223 advertised media listening address/port). Thus the remote UA 1224 will render the MOH media even if it is filtering incoming media 1225 based on originating address as a media security measure. 1227 5. The technique requires relatively simple manipulation of SDP, and 1228 in particular: (1) does not require a SIP element to modify 1229 unrelated SDP to be acceptable to be sent within an already 1230 established sequence of SDP (a problem with 1231 [I-D.ietf-sipping-service-examples-11] section 2.3), and (2) does 1232 not require converting an SDP answer into an SDP offer (which was 1233 a problem with the -00 version of this document, as well as with 1234 [I-D.ietf-sipping-service-examples-11]). 1236 4. Caveats 1238 4.1. Offering All Available Media Formats 1240 Unnecessary failures can happen if SDP offerers do not always offer 1241 all media formats that they support. Doing so is considered best 1242 practice ([RFC6337] sections 5.1 and 5.3), but some SIP elements 1243 offer only formats that have already been in use in the dialog. 1245 An example of how omitting media formats in an offer can lead to 1246 failure is as follows: Suppose that the UAs in Section 2.3 each 1247 support the following media formats: 1249 Alice supports formats X and Y 1251 Bob supports formats X and Z 1253 Music Source supports formats Y and Z 1255 In this case, the SDP exchanges are: 1257 1. Alice calls Bob: 1258 Alice offers X and Y (message F1) 1259 Bob answers X (F3) 1261 2. Bob puts Alice on hold: 1262 Alice (via Bob) offers X and Y (F6 and F7) 1263 Music Source (via Bob) answers Y (F8 and F10) 1265 3. Bob takes Alice off hold: 1266 Bob offers X and Z (F11) 1267 Alice answers X (F12) 1269 Note that in exchange 2, if Alice assumes that because only format X 1270 is currently in use that she should offer only X, the exchange fails. 1271 In exchange 3, Bob offers formats X and Z, even though neither is in 1272 use at the time (because Bob is not involved in the media streams). 1274 4.2. Handling Re-INVITES in a B2BUA 1276 Many UAs provide MOH in the interval during which it is processing a 1277 blind transfer, between receiving the REFER and receiving the final 1278 response to the stimulated INVITE. This process involves switching 1279 the user's interface between three media sources: (1) the session of 1280 the original dialog, (2) the session with the MOH server, and (3) the 1281 session of the new dialog; it involves a number of race conditions 1282 that must be handled correctly. If the UA is a B2BUA whose "other 1283 side" is maintaining a single dialog with another UA, each switching 1284 of media sources potentially causes a re-INVITE transaction within 1285 the other-side dialog. Since re-INVITEs take time and must be 1286 sequenced correctly ([RFC3261] section 14), such a B2BUA must allow 1287 the events on each side to be non-synchronous and must coordinate 1288 them correctly. Failing to do so will lead to "glare" errors (491 or 1289 500), leaving the other-side UA not rendering the correct session. 1291 5. Security Considerations 1293 5.1. Network security 1295 Some mechanism outside the scope of this document must inform the 1296 executing UA of the MOH server that it should use. Care must be 1297 exercised in selecting the MOH server, because signaling information 1298 which is part of the original dialog will be transmitted along the 1299 path from the executing UA to the server. If the path between the 1300 executing UA and the server is not entirely contained within every 1301 network domain that contains the executing UA, the signaling between 1302 the UA and the server may be protected by different network security 1303 than is applied to the original dialog. 1305 Care must also be exercised because media information that is part of 1306 the original dialog will be transmitted along the path between the 1307 remote UA and the server. If the path between the remote UA and the 1308 server does not pass through the same network domains as the path 1309 between the remote UA and the executing UA, the media between the UA 1310 and the server may be protected by different network security than is 1311 applied to the original dialog. 1313 These requirements may be satisfied by selecting a MOH server that is 1314 in the same administrative and network domain as the executing UA, 1315 and whose path to all external addresses is the same as the UA's path 1316 to those addresses. 1318 5.2. SIP (signaling) security 1320 The executing UA and the MOH server will usually be within the same 1321 administrative domain and the SIP signaling path between them will 1322 lie entirely within that domain. In this case, the administrator of 1323 the domain should configure the UA and server to apply to the dialog 1324 between them a level of security that is appropriate for the 1325 administrative domain. 1327 If the executing UA and the MOH server are not within the same 1328 administrative domain, the SIP signaling between them should be at 1329 least as secure as the SIP signaling between the executing UA and the 1330 remote UA. Thus, the MOH server should support all of the SIP 1331 security facilities that are supported by the executing UA, and the 1332 executing UA should use in its dialog with the MOH server all SIP 1333 security facilities that are used in its dialog with the remote UA. 1335 5.3. RTP (media) security 1337 The RTP for the MOH media will pass directly between the MOH server 1338 and the remote UA, and thus may pass outside the administrative 1339 domain of the executing UA. While it is uncommon for the contents of 1340 the MOH media to be sensitive (and the remote UA will not usually be 1341 generating RTP when it is on-hold), the MOH RTP should be at least as 1342 secure as the RTP between the executing UA and the remote UA. In 1343 order to make this possible, the MOH server should support all of the 1344 RTP security facilities that are supported by the executing UA. 1346 It is possible that the remote UA and the MOH server support an RTP 1347 security facility that the executing UA does not support, and that it 1348 is desirable to use this facility for the MOH RTP. To enable doing 1349 so, the executing UA should pass the SDP between the remote UA and 1350 the MOH server completely, not omitting elements that it does not 1351 understand. 1353 5.4. Media filtering 1355 Some UAs filter incoming RTP based on the address of origin as a 1356 media security measure, refusing to render the contents of RTP 1357 packets that originate from an address that is not shown in the 1358 remote SDP as an RTP destination address. The remote UA in the 1359 original dialog may use this form of media filtering, and if the 1360 executing UA does not update the SDP to inform the remote UA of the 1361 source address of the MOH media, the remote UA may not render the MOH 1362 media. Note that the executing UA has no means for detecting that 1363 the remote UA uses media filtering, so the executing UA must assume 1364 that any remote UA uses media filtering. 1366 The technique described in this document ensures that any UA that 1367 should render MOH media will be informed of the source address of the 1368 media via the SDP that it receives. This allows such UAs to filter 1369 media without interfering with MOH operation. 1371 6. IANA Considerations 1373 There are no IANA considerations. 1375 7. Acknowledgments 1377 The original version of this proposal was derived from 1378 [I-D.ietf-sipping-service-examples-11] section 2.3 and the similar 1379 implementation of MOH in the Snom UA. Significant improvements to 1380 the sequence of operations, allowing improvements to the SDP 1381 handling, were suggested by Venkatesh[venkatesh]. 1383 John Elwell[elwell] pointed out the need for the executing UA to pass 1384 through re-INVITEs/UPDATEs in order to allow ICE negotiation, 1385 suggested mentioning the role of RTCP listening ports, suggested the 1386 possibility of omitting the dialog to the music source if the 1387 directionality would be "inactive", and pointed that if there are 1388 multiple media streams, the executing UA may want to select which 1389 streams receive MOH. 1391 Paul Kyzivat[kyzivat-1][kyzivat-2] pointed out the difficulties 1392 regarding reuse of payload type numbers and considerations that could 1393 be used to avoid those difficulties, leading to the writing of 1394 Section 2.8. 1396 Paul Kyzivat suggested adding Section 4.1 showing why offerers should 1397 always include all supported formats. 1399 M. Ranganathan pointed out the difficulties experienced by a B2BUA 1400 (Section 4.2) due to the multiple changes of media source. 1402 Section 4.1 was significantly clarified based on advice from Attila 1403 Sipos[sipos]. 1405 The need to discuss dialog/session timers[Section 2.9] was pointed 1406 out by Rifaat Shekh-Yusef[shekh-yusef]. 1408 Robert Sparks clarified the purpose of the "Best Common Practice" 1409 status, leading to revising the intended status of this document to 1410 "Informational". 1412 In his Secdir review, Stephen Kent pointed out that the Security 1413 Considerations should discuss the use of SIP and SDP security 1414 features by the MOH server. 1416 Numerous improvements to the text were due to reviewers, including 1417 Rifaat Shekh-Yusef and Richard Barnes. 1419 8. Revision History 1421 [Note to RFC Editor: Please remove this entire section upon 1422 publication as an RFC.] 1424 8.1. Changes from draft-worley-service-example-00 to draft-worley- 1425 service-example-01 1427 Removed the original "Example Message Flow" and promoted the 1428 "Alternative Example Message Flow" to replace it because of a number 1429 of flaws that were found during the discussion of -00 on the SIPPING 1430 mailing list. 1432 Described the use of the sip.rendering feature parameter to indicate 1433 on-hold status. 1435 8.2. Changes from draft-worley-service-example-01 to draft-worley- 1436 service-example-02 1438 Added discussion of passing though re-INVITEs and UPDATEs. 1440 Added discussion of payload type numbers. 1442 Added Acknowledgments section. 1444 8.3. Changes from draft-worley-service-example-02 to draft-worley- 1445 service-example-03 1447 Added Section 4.1 showing the importance of the offerer always 1448 including all supported media formats. 1450 Updated references. 1452 Revised handling of payload type numbers when passing offer to MOH 1453 server Section 2.8, based on observations by Paul Kyzivat. 1455 8.4. Changes from draft-worley-service-example-03 to draft-worley- 1456 service-example-04 1458 Added Section 4.2 discussing handling of re-INVITEs by B2BUAs when 1459 using this method. 1461 Added "avoidance of out-of-dialog REFER" as an advantage.Section 3 1463 Added "automaton", "sip.rendering", and "sip.byeless" feature tags to 1464 the Contact URI of the Music Server in the 1465 examples.[RFC4235][RFC3840] 1467 Added initial discussion of dialog/session timer support.Section 2.9 1469 Revised handling of payload type numbers based on further 1470 observations by Paul Kyzivat[kyzivat-2]. 1472 8.5. Changes from draft-worley-service-example-04 to draft-worley- 1473 service-example-05 1475 Changed references to "SPIT" to refer to "media security", per 1476 suggestion by Scott Lawrence. 1478 Removed reference to the idea of having the executing UA not maintain 1479 session timers itself, but rather, passing through session timer 1480 negotiation and updates. Examination showed this idea to be much 1481 more complex to implement than having the executing UA terminate 1482 session timers itself for both dialogs. (Suggested by Rifaat Shekh- 1483 Yusef.) 1485 On advice from Robert Sparks, changed the "intended status" from 1486 "BCP" to "Informational", and added a section to explain the change. 1488 Noted that the rule on not reusing payload type numbers is 1489 undesirable because it complicates third-party operations (as noted 1490 by Paul Kyzivat[kyzivat-3]). 1492 8.6. Changes from draft-worley-service-example-05 to draft-worley- 1493 service-example-06 1495 Updated author's contact information. 1497 On suggestion from John Elwell, added mention that the Music Source's 1498 SDP address/port implies its RTCP address/port, which will be used to 1499 receive RTCP. 1501 Updated references to [RFC5359] and 1502 [I-D.ietf-sipping-service-examples-11] to specify the sections of 1503 documents, which are the ones that discuss music on hold. 1505 8.7. Changes from draft-worley-service-example-06 to draft-worley- 1506 service-example-07 1508 Update reference to [RFC6337] to refer to the -18 version. 1510 8.8. Changes from draft-worley-service-example-07 to draft-worley- 1511 service-example-08 1513 Sections Section 2.10 and Section 2.11 added at the suggestion of 1514 John Elwell. 1516 8.9. Changes from draft-worley-service-example-08 to draft-worley- 1517 service-example-09 1519 Update reference to [RFC6337] to refer to RFC 6337. 1521 8.10. Changes from draft-worley-service-example-09 to draft-worley- 1522 service-example-10 1524 Renew Internet-Draft, no changes. 1526 8.11. Changes from draft-worley-service-example-10 to draft-worley- 1527 service-example-11 1529 Renew Internet-Draft, no changes. 1531 8.12. Changes from draft-worley-service-example-11 to draft-worley- 1532 service-example-12 1534 Numerous improvements resulting from Rifaat Shekh-Yusef's review, 1535 including: 1537 Adding examples for how the executing UA processes INVITE-with- 1538 Replaces and REFER directed toward the dialog with the remote UA. 1540 Recommending a 403 response to a re-INVITE/UPDATE request from the 1541 MOH server if the UA knows that it need not be acted upon. 1543 8.13. Changes from draft-worley-service-example-12 to draft-worley- 1544 service-example-13 1546 Improvements resulting from Richard Barnes' review. 1548 Update the Acknowledgments to credit the reviewers. 1550 8.14. Changes from draft-worley-service-example-13 to draft-worley- 1551 service-example-14 1553 Update RFC and Internet-Draft references to use tags giving their 1554 numbers/names rather than describing their contents, as suggested in 1555 the Secdir review by Stephen Kent. 1557 As suggested in the Secdir review by Stephen Kent, add sections to 1558 Security Considerations regarding use of SIP and SDP security by the 1559 MOH server. 1561 8.15. Changes from draft-worley-service-example-14 to draft-worley- 1562 service-example-15 1564 Several minor revisions from reviews by IESG and Gen-Art. 1566 9. References 1568 9.1. Normative References 1570 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1571 A., Peterson, J., Sparks, R., Handley, M., and E. 1572 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1573 June 2002. 1575 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1576 with Session Description Protocol (SDP)", RFC 3264, June 1577 2002. 1579 [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the 1580 Session Initiation Protocol (SIP)", RFC 4028, April 2005. 1582 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1583 Description Protocol", RFC 4566, July 2006. 1585 9.2. Informative References 1587 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1588 "Indicating User Agent Capabilities in the Session 1589 Initiation Protocol (SIP)", RFC 3840, August 2004. 1591 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 1592 Initiated Dialog Event Package for the Session Initiation 1593 Protocol (SIP)", RFC 4235, November 2005. 1595 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 1596 BCP 131, RFC 4961, July 2007. 1598 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1599 (ICE): A Protocol for Network Address Translator (NAT) 1600 Traversal for Offer/Answer Protocols", RFC 5245, April 1601 2010. 1603 [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and 1604 K. Summers, "Session Initiation Protocol Service 1605 Examples", BCP 144, RFC 5359, October 2008. 1607 [RFC6337] Okumura, S., Sawada, T., and P. Kyzivat, "Session 1608 Initiation Protocol (SIP) Usage of the Offer/Answer 1609 Model", RFC 6337, August 2011. 1611 [elwell] Elwell, J., "Subject: [Sipping] RE: I-D Action:draft- 1612 worley-service-example-00.txt", IETF Sipping mailing list 1613 msg14678, November 2007, . 1616 [I-D.ietf-sipping-service-examples-11] 1617 Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and 1618 K. Summers, "Session Initiation Protocol Service 1619 Examples", I-D draft-ietf-sipping-service-examples-11, 1620 October 2006, . 1623 [kyzivat-1] 1624 Kyzivat, P., "Subject: Re: [Sipping] I-D ACTION:draft- 1625 ietf-sipping-service-examples-11.txt", IETF Sipping 1626 mailing list msg12181, October 2006, . 1629 [kyzivat-2] 1630 Kyzivat, P., "[Sip-implementors] draft-worley-service- 1631 example-02", sip-implementors mailing list 020426, 1632 September 2008, . 1635 [kyzivat-3] 1636 Kyzivat, P., "[Sip-implementors] draft-worley-service- 1637 example-02", sip-implementors mailing list 020387, 1638 September 2008, . 1641 [shekh-yusef] 1642 Shekh-Yusef, R., "[sipcore] draft-worley-service- 1643 example-03", IETF Sipcore mailing list msg00580, July 1644 2009, . 1647 [sipos] Sipos, A., "RE: [Sip-implementors] draft-worley-service- 1648 example-02", sip-implementors mailing list 022002, March 1649 2009, . 1652 [venkatesh] 1653 Venkatesh, ., "Subject: Re: [Sipping] I-D ACTION:draft- 1654 ietf-sipping-service-examples-11.txt", IETF Sipping 1655 mailing list msg12180, October 2006, . 1658 Author's Address 1660 Dale R. Worley 1661 Ariadne Internet Services, Inc. 1662 738 Main St. 1663 Waltham, MA 02451 1664 US 1666 Phone: +1 781 647 9199 1667 Email: worley@ariadne.com