SIP D.R. Worley Internet-Draft Bluesocket Expires: May 10, 2008 November 7, 2007 Session Initiation Protocol Service Example -- Music on Hold draft-worley-service-example-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 10, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The "music on hold" feature is one of the most desired features of telephone systems in the business environment. "Music on hold" is, when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party. Architectural features of SIP make it difficult to implement music-on-hold in a way that is fully compliant with the standards. The implementation of music-on-hold described in this document is fully standards-compliant, but is simpler than the methods previously documented. Worley Expires May 10, 2008 [Page 1] Internet-Draft Music on Hold November 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Technique . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Placing a Call on Hold and Providing an External Media Stream . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Taking a Call off Hold and Terminating the External Media Stream . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Example Message Flow . . . . . . . . . . . . . . . . . . . 5 2.4. Alternative Example Message Flow . . . . . . . . . . . . . 13 3. Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4. Security Considerations . . . . . . . . . . . . . . . . . . . 23 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.1. Normative References . . . . . . . . . . . . . . . . . . . 24 5.2. Informative References . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 26 Worley Expires May 10, 2008 [Page 2] Internet-Draft Music on Hold November 2007 1. Introduction Within SIP[1]-based systems, it is desirable to be able to provide features that are similar to those provided by traditional telephony systems. A frequently requested feature is "music on hold": The music-on-hold feature, when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party. Architectural features of SIP make it difficult to implement music- on-hold in a way that is fully compliant with the standards. The purpose of this document is to describe a method that is reasonably simple and fully standards-compliant. Worley Expires May 10, 2008 [Page 3] Internet-Draft Music on Hold November 2007 2. Technique The essence of the technique is that when the executing UA performs a re-INVITE of the remote UA to establish the hold state, it extracts the answer SDP[2], and uses that as the offer SDP in a new INVITE to the external media source. The external media source is thus directed to provide media directly to the remote UA. 2.1. Placing a Call on Hold and Providing an External Media Stream 1. The user instructs the user's UA to put the conversation on-hold. 2. The user's UA sends a re-INVITE to the remote UA with SDP that declines to receive media. This establishes the on-hold state (in that direction). 3. The remote UA responds 200 to the re-INVITE, and includes SDP giving its own listening address/port, which should indicate that it will not send media. 4. The user's UA composes and sends a new INVITE to the configured external music-on-hold (MOH) source. The SDP in this request is largely copied from the SDP returned by the remote UA in the previous step, particularly regarding the provided listening address/port and codec numbers. 5. The MOH source responds 200 to the INVITE. 6. After this point, the MOH source generates RTP containing the music-on-hold media, and sends it directly to the listening address/port of the remote UA. The UA maintains two dialogs (one to the remote UA, one to the MOH source), but does not see or handle the MOH RTP. 2.2. Taking a Call off Hold and Terminating the External Media Stream 1. The user instructs the user's UA to take the conversation off- hold. 2. The user's UA sends a re-INVITE to the remote UA with SDP that requests to receive media. 3. When the remote UA responds 200 to the re-INVITE, the user's UA sends BYE on dialog to the MOH source. 4. After this point, the MOH source does not generate RTP and ordinary RTP flow is re-established in the original dialog. Worley Expires May 10, 2008 [Page 4] Internet-Draft Music on Hold November 2007 2.3. Example Message Flow This section shows a message flow which is an example of this technique. The scenario is: Alice establishes a call with Bob. Bob then places the call on hold, with music-on-hold provided from an external server. Bob then takes the call off hold. Note that this is just one possible message flow that illustrates this technique; numerous variations on these operations are allowed by the applicable standards. Alice Bob Music Server Alice establishes the call: | | | | INVITE F1 | | |--------------->| | | 180 Ringing F2 | | |<---------------| | | 200 OK F3 | | |<---------------| | | ACK F4 | | |--------------->| | | RTP | | |<==============>| | | | | Bob places Alice on hold: | | | |INVITE (hold) F5| | |<---------------| | | 200 OK F6 | | |--------------->| | | ACK F7 | | |<---------------| | | no RTP | | | | | Bob's UA initiates music-on-hold: | | | | | INVITE F8 | | |------------->| | | 200 OK F9 | | |<-------------| | | ACK F10 | Worley Expires May 10, 2008 [Page 5] Internet-Draft Music on Hold November 2007 | |------------->| | Music-on-hold RTP | |<==============================| | | | The music on hold is active. Bob takes Alice off hold: | | | | INVITE F11 | | |<---------------| | | 200 OK F12 | | |--------------->| | | ACK F13 | | |<---------------| | | | BYE F14 | | |------------->| | | 200 F15 | | |<-------------| | RTP | | |<==============>| | | | | The normal media session between Alice and Bob is resumed. Message Details /* Alice calls Bob. */ F1 INVITE Alice -> Bob INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS atlanta.example.com:5061 ;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice ;tag=1234567 To: Bob Call-ID: 12345600@atlanta.example.com CSeq: 1 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Content-Type: application/sdp Content-Length: [omitted] v=0 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com Worley Expires May 10, 2008 [Page 6] Internet-Draft Music on Hold November 2007 s= c=IN IP4 atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F2 180 Ringing Bob -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/TLS atlanta.example.com:5061 ;branch=z9hG4bK74bf9 ;received=192.0.2.103 From: Alice ;tag=1234567 To: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 1 INVITE Contact: Content-Length: 0 F3 200 OK Bob -> Alice SIP/2.0 200 OK Via: SIP/2.0/TLS atlanta.example.com:5061 ;branch=z9hG4bK74bf9 ;received=192.0.2.103 From: Alice ;tag=1234567 To: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 1 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Type: application/sdp Content-Length: [omitted] v=0 o=bob 2890844527 2890844527 IN IP4 biloxi.example.com s= c=IN IP4 biloxi.example.com t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F4 ACK Alice -> Bob Worley Expires May 10, 2008 [Page 7] Internet-Draft Music on Hold November 2007 ACK sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS atlanta.example.com:5061 ;branch=z9hG4bK74bfd Max-Forwards: 70 From: Alice ;tag=1234567 To: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 1 ACK Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Length: 0 /* Bob places Alice on hold. */ F5 INVITE Bob -> Alice INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bK874bk To: Alice ;tag=1234567 From: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 712 INVITE Contact: ;+sip.rendering="no" Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Type: application/sdp Content-Length: [omitted] v=0 o=bob 2890844527 2890844528 IN IP4 biloxi.example.com s= c=IN IP4 biloxi.example.com t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendonly F6 200 OK Alice -> Bob SIP/2.0 200 OK Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bK874bk ;received=192.0.2.105 To: Alice ;tag=1234567 From: Bob ;tag=23431 Worley Expires May 10, 2008 [Page 8] Internet-Draft Music on Hold November 2007 Call-ID: 12345600@atlanta.example.com CSeq: 712 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Content-Type: application/sdp Content-Length: [omitted] v=0 o=alice 2890844526 2890844527 IN IP4 atlanta.example.com s= c=IN IP4 atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=recvonly F7 ACK Bob -> Alice ACK sips:a8342043f@atlanta.example.com;gr SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bKq874b To: Alice ;tag=1234567 From: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 712 ACK Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Length: 0 /* Bob's UA initiates music-on-hold. */ F8 INVITE Bob -> Music Server INVITE sips:music@server.example.com SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bKnashds9 Max-Forwards: 70 From: Bob ;tag=02134 To: Music Server Call-ID: 4802029847@biloxi.example.com CSeq: 1 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Content-Type: application/sdp Worley Expires May 10, 2008 [Page 9] Internet-Draft Music on Hold November 2007 Content-Length: [omitted] v=0 o=bob 2890844534 2890844534 IN IP4 atlanta.example.com s= c=IN IP4 atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=recvonly F9 200 OK Music Server -> Bob SIP/2.0 200 OK Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bKnashds9 ;received=192.0.2.105 From: Bob ;tag=02134 To: Music Server ;tag=56323 Call-ID: 4802029847@biloxi.example.com Contact: CSeq: 1 INVITE Content-Length: [omitted] v=0 o=MusicServer 2890844576 2890844576 IN IP4 server.example.com s= c=IN IP4 server.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendonly F10 ACK Bob -> Music Server ACK sips:music@server.example.com SIP/2.0 Via: SIP/2.0/TLS server.example.com:5061 ;branch=z9hG4bK74bT6 From: Bob ;tag=02134 To: Music Server ;tag=56323 Max-Forwards: 70 Call-ID: 4802029847@biloxi.example.com CSeq: 1 ACK Content-Length: 0 Worley Expires May 10, 2008 [Page 10] Internet-Draft Music on Hold November 2007 /* Bob picks up the call by sending a re-INVITE to Alice. */ F11 INVITE Bob -> Alice INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bK874bk To: Alice ;tag=1234567 From: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 713 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Type: application/sdp Content-Length: [omitted] v=0 o=bob 2890844527 2890844529 IN IP4 biloxi.example.com s= c=IN IP4 biloxi.example.com t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F12 200 OK Alice -> Bob SIP/2.0 200 OK Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bK874bk ;received=192.0.2.105 To: Alice ;tag=1234567 From: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 713 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Content-Type: application/sdp Content-Length: [omitted] v=0 o=alice 2890844526 2890844528 IN IP4 atlanta.example.com s= c=IN IP4 atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 Worley Expires May 10, 2008 [Page 11] Internet-Draft Music on Hold November 2007 a=rtpmap:0 PCMU/8000 F13 ACK Bob -> Alice ACK sips:a8342043f@atlanta.example.com;gr SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bKq874b To: Alice ;tag=1234567 From: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 713 ACK Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Length: 0 F14 BYE Bob -> Music Server INVITE sips:music@server.example.com SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bK74rf Max-Forwards: 70 From: Bob ;tag=02134 To: Music Server ;tag=56323 Call-ID: 4802029847@biloxi.example.com CSeq: 2 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Content-Length: [omitted] F15 200 OK Music Server -> Alice SIP/2.0 200 OK Via: SIP/2.0/TLS atlanta.example.com:5061 ;branch=z9hG4bK74rf ;received=192.0.2.103 From: Bob ;tag=02134 To: Music Server ;tag=56323 Call-ID: 4802029847@biloxi.example.com CSeq: 2 BYE Content-Length: 0 /* Normal media session between Alice and Bob is resumed */ Worley Expires May 10, 2008 [Page 12] Internet-Draft Music on Hold November 2007 2.4. Alternative Example Message Flow A disadvantage of the previous message flow is that the RTP is sent to the remote UA from an address that is different from that which is given in the offer SDP of the re-INVITE. This can trigger SPIT- prevention behavior in some UA's.[Section 4] This section shows an alternative example message flow which avoids this problem. Again, this is just one possible message flow that illustrates this technique; numerous variations on these operations are allowed by the applicable standards. This technique involves interleaving the SDP offer/answer sequences of the two dialogs (original call and MOH): 1. The executing UA sends the re-INVITE without SDP, forcing the remote UA to provide an SDP offer in the 200 response. 2. The executing UA sends this offer as the SDP of the INVITE that it sends to the music-on-hold server. (The offer is modified to have a suitable o= line, and the media directionality is set to "recvonly", the reverse of "on-hold".) 3. The music-on-hold server provides an SDP answer, which (we assume) includes its media source address as its listening address. 4. The executing UA sends this SDP answer as its SDP answer in the ACK for the re-INVITE. (The answer is modified to have a suitable o= line.) Alice Bob Music Server Alice establishes the call: | | | | INVITE F1 | | |--------------->| | | 180 Ringing F2 | | |<---------------| | | 200 OK F3 | | |<---------------| | | ACK F4 | | |--------------->| | | RTP | | |<==============>| | | | | Worley Expires May 10, 2008 [Page 13] Internet-Draft Music on Hold November 2007 Bob places Alice on hold, compelling Alice's UA to provide SDP: | | | | INVITE F5 | | | (no SDP) | | |<---------------| | | 200 OK F6 | | | (SDP offer) | | |--------------->| | | | | Bob's UA initiates music-on-hold: | | | | | INVITE F7 | | | (SDP offer, | | | rev. hold) | | |------------->| | | 200 OK F8 | | | (SDP answer, | | | hold) | | |<-------------| | | ACK F9 | | |------------->| | | | Bob's UA provides SDP answer containing the address/port of the Music Server: | | | | ACK (hold) F10 | | | (SDP answer) | | |<---------------| | | no RTP | | | | | | Music-on-hold RTP | |<==============================| | | | The music on hold is active. Bob takes Alice off hold: | | | | INVITE F11 | | | (SDP offer) | | |<---------------| | | 200 OK F12 | | Worley Expires May 10, 2008 [Page 14] Internet-Draft Music on Hold November 2007 | (SDP answer) | | |--------------->| | | ACK F13 | | |<---------------| | | | BYE F14 | | |------------->| | | 200 F15 | | |<-------------| | RTP | | |<==============>| | | | | The normal media session between Alice and Bob is resumed. Message Details /* Alice calls Bob. */ F1 INVITE Alice -> Bob INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS atlanta.example.com:5061 ;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice ;tag=1234567 To: Bob Call-ID: 12345600@atlanta.example.com CSeq: 1 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Content-Type: application/sdp Content-Length: [omitted] v=0 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com s= c=IN IP4 atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F2 180 Ringing Bob -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/TLS atlanta.example.com:5061 ;branch=z9hG4bK74bf9 Worley Expires May 10, 2008 [Page 15] Internet-Draft Music on Hold November 2007 ;received=192.0.2.103 From: Alice ;tag=1234567 To: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 1 INVITE Contact: Content-Length: 0 F3 200 OK Bob -> Alice SIP/2.0 200 OK Via: SIP/2.0/TLS atlanta.example.com:5061 ;branch=z9hG4bK74bf9 ;received=192.0.2.103 From: Alice ;tag=1234567 To: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 1 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Type: application/sdp Content-Length: [omitted] v=0 o=bob 2890844527 2890844527 IN IP4 biloxi.example.com s= c=IN IP4 biloxi.example.com t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F4 ACK Alice -> Bob ACK sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS atlanta.example.com:5061 ;branch=z9hG4bK74bfd Max-Forwards: 70 From: Alice ;tag=1234567 To: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 1 ACK Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Length: 0 Worley Expires May 10, 2008 [Page 16] Internet-Draft Music on Hold November 2007 /* Bob places Alice on hold. */ /* The re-INVITE contains no SDP, thus compelling Alice's UA to provide an offer. */ F5 INVITE Bob -> Alice INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bK874bk To: Alice ;tag=1234567 From: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 712 INVITE Contact: ;+sip.rendering="no" Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Length: 0 /* Alice's UA provides an SDP offer. Since it does not know that it is being put on hold, the offer is the same as the original offer and describes bidirectional media. */ F6 200 OK Alice -> Bob SIP/2.0 200 OK Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bK874bk ;received=192.0.2.105 To: Alice ;tag=1234567 From: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 712 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Content-Type: application/sdp Content-Length: [omitted] v=0 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com s= c=IN IP4 atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=active Worley Expires May 10, 2008 [Page 17] Internet-Draft Music on Hold November 2007 /* Bob's UA initiates music-on-hold. */ /* This INVITE contains Alice's offer, but with the media direction set to "reverse hold", receive-only. */ F7 INVITE Bob -> Music Server INVITE sips:music@server.example.com SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bKnashds9 Max-Forwards: 70 From: Bob ;tag=02134 To: Music Server Call-ID: 4802029847@biloxi.example.com CSeq: 1 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Content-Type: application/sdp Content-Length: [omitted] v=0 o=bob 2890844534 2890844534 IN IP4 atlanta.example.com s= c=IN IP4 atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=recvonly F8 200 OK Music Server -> Bob SIP/2.0 200 OK Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bKnashds9 ;received=192.0.2.105 From: Bob ;tag=02134 To: Music Server ;tag=56323 Call-ID: 4802029847@biloxi.example.com Contact: CSeq: 1 INVITE Content-Length: [omitted] v=0 o=MusicServer 2890844576 2890844576 IN IP4 server.example.com s= c=IN IP4 server.example.com Worley Expires May 10, 2008 [Page 18] Internet-Draft Music on Hold November 2007 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendonly F9 ACK Bob -> Music Server ACK sips:music@server.example.com SIP/2.0 Via: SIP/2.0/TLS server.example.com:5061 ;branch=z9hG4bK74bT6 From: Bob ;tag=02134 To: Music Server ;tag=56323 Max-Forwards: 70 Call-ID: 4802029847@biloxi.example.com CSeq: 1 ACK Content-Length: 0 /* Bob's UA now sends the ACK that completes the re-INVITE to Alice and completes the SDP offer/answer. The ACK contains the SDP received from the Music Server, and thus contains the address/port from which the Music Server will send media. */ F10 ACK Bob -> Alice ACK sips:a8342043f@atlanta.example.com;gr SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bKq874b To: Alice ;tag=1234567 From: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 712 ACK Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Length: [omitted] v=0 o=bob 2890844527 2890844528 IN IP4 biloxi.example.com s= c=IN IP4 server.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendonly /* Bob picks up the call by sending a re-INVITE to Alice. */ Worley Expires May 10, 2008 [Page 19] Internet-Draft Music on Hold November 2007 F11 INVITE Bob -> Alice INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bK874bk To: Alice ;tag=1234567 From: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 713 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Type: application/sdp Content-Length: [omitted] v=0 o=bob 2890844527 2890844529 IN IP4 biloxi.example.com s= c=IN IP4 biloxi.example.com t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F12 200 OK Alice -> Bob SIP/2.0 200 OK Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bK874bk ;received=192.0.2.105 To: Alice ;tag=1234567 From: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 713 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Content-Type: application/sdp Content-Length: [omitted] v=0 o=alice 2890844526 2890844527 IN IP4 atlanta.example.com s= c=IN IP4 atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Worley Expires May 10, 2008 [Page 20] Internet-Draft Music on Hold November 2007 F13 ACK Bob -> Alice ACK sips:a8342043f@atlanta.example.com;gr SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bKq874b To: Alice ;tag=1234567 From: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 713 ACK Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Length: 0 F14 BYE Bob -> Music Server INVITE sips:music@server.example.com SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bK74rf Max-Forwards: 70 From: Bob ;tag=02134 To: Music Server ;tag=56323 Call-ID: 4802029847@biloxi.example.com CSeq: 2 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Content-Length: [omitted] F15 200 OK Music Server -> Alice SIP/2.0 200 OK Via: SIP/2.0/TLS atlanta.example.com:5061 ;branch=z9hG4bK74rf ;received=192.0.2.103 From: Bob ;tag=02134 To: Music Server ;tag=56323 Call-ID: 4802029847@biloxi.example.com CSeq: 2 BYE Content-Length: 0 /* Normal media session between Alice and Bob is resumed */ Worley Expires May 10, 2008 [Page 21] Internet-Draft Music on Hold November 2007 3. Advantages This technique for providing music-on-hold has advantages over other methods now in use: 1. The original dialog is not transferred to another UA, so the "remote endpoint URI" displayed by the remote endpoint does not change during the call.[3] 2. The music-on-hold media is sent directly from the music-on-hold source to the remote UA, rather than being relayed through the holding UA. 3. The technique does not require complex manipulation of SDP, and particularly does not require a SIP agent to modify received SDP to be acceptable to be sent within an already established sequence of SDP (which can require a complex accounting of the m= lines). Worley Expires May 10, 2008 [Page 22] Internet-Draft Music on Hold November 2007 4. Security Considerations SDP, by its organization, specifies what address and port a UA will use to listen for media, but implicitly allows media to be sent to that address and port from any address and port. Some UAs, in order to avoid SPIT, will refuse to render media that are sent from an address which is not the listening address for the remote UA. That policy will also block music-on-hold that is provided using this technique. This problem can be circumvented in at least three ways: The first method is to disable the media-address restriction. Since this brings the UA's behavior into alignment with the common SIP model, it is probably the most reliable for overall interoperability. The second method is for the holding UA to obtain knowledge of the media sending address of the music-on-hold server by some means, and substitute that address for its own in the SDP in the re-INVITE that places the dialog on-hold. This technique requires that the holding UA can obtain this sending address, and that the technique for specifying the "on-hold" condition in the re-INVITE is not that of setting the listening address in the c= line to 0.0.0.0. The third method is to use the more complex interleaved SDP offer/ answer system illustrated in Section 2.4. This technique requires that the executing UA can coordinate the SDP offer/answer mechanism between two dialogs. Worley Expires May 10, 2008 [Page 23] Internet-Draft Music on Hold November 2007 5. References 5.1. Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002. 5.2. Informative References [3] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", I-D draft-ietf-sipping-service-examples-13, July 2007. Worley Expires May 10, 2008 [Page 24] Internet-Draft Music on Hold November 2007 Author's Address Dale R. Worley Bluesocket Inc. 10 North Ave. Burlington, MA 01803 US Phone: +1 781 229 0533 x173 Email: dworley@pingtel.com URI: http://www.pingtel.com Worley Expires May 10, 2008 [Page 25] Internet-Draft Music on Hold November 2007 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Worley Expires May 10, 2008 [Page 26]