DispatchInternet Engineering Task Force (IETF) D. WorleyInternet-DraftRequest for Comments: 7088 AriadneIntended status:Category: InformationalNovember 08, 2013 Expires: May 12,February 2014 ISSN: 2070-1721 Session Initiation Protocol Service Example -- Music on Holddraft-worley-service-example-15AbstractThe "music"Music on hold"featureis one of the features of telephone systems that is most desired by buyers of business telephone systems."MusicMusic onhold" is where,hold means that 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 implementmusic-on-holdmusic on hold in a way that is fullycompliant with the standards.standards- compliant. The implementation ofmusic-on-holdmusic on hold described in this document is fullyeffective and standards- compliant,effective, is standards-compliant, and has a number of advantages over the methods previously documented. In particular, it is less likely to produce peculiar user interface effects and more likely to work in systemswhichthat perform authentication than themusic-on-holdmusic- on-hold method described insectionSection 2.3 of RFC 5359. Status of This Memo ThisInternet-Draftdocument issubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsnot an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are amaximumcandidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status ofsix monthsthis document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 12, 2014.http://www.rfc-editor.org/info/rfc7088. Copyright Notice Copyright (c)20132014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . 3....................................................3 1.1. Requirements Language ......................................3 2. Technique. . . . . . . . . . . . . . . . . . . . . . . . . . 4.......................................................3 2.1. Placing a Call on Hold and Establishing an External Media Stream. . . . . . . . . . . . . . . . . . . . . . . . . 4...............................................3 2.2. Taking a Call off Hold and Terminating the External Media Stream. . . . . . . . . . . . . . . . . . . . . . . . . 5...............................................5 2.3. Example Message Flow. . . . . . . . . . . . . . . . . . 6.......................................5 2.4. Receiving Re-INVITE and UPDATE from the Remote UA. . . . 15.........14 2.5. Receiving INVITE with Replaces. . . . . . . . . . . . . 15............................15 2.6. Receiving REFER from the Remote UA. . . . . . . . . . . 17........................17 2.7. Receiving Re-INVITE and UPDATE from theMusic-On-HoldMusic-on-Hold Source. . . . . . . . . . . . . . . . . . . . . . . . . 19......................................19 2.8. Handling Payload Type Numbers. . . . . . . . . . . . . . 19.............................19 2.8.1. Analysis. . . . . . . . . . . . . . . . . . . . . . 19...........................................19 2.8.2. Solution to the Problem. . . . . . . . . . . . . . . 20............................20 2.8.3. Example of the Solution. . . . . . . . . . . . . . . 21............................22 2.9. Dialog/Session Timers. . . . . . . . . . . . . . . . . . 25.....................................25 2.10. When the Media Stream Directionality is "inactive". . . 25.......25 2.11. Multiple Media Streams. . . . . . . . . . . . . . . . . 25...................................26 3. Advantages. . . . . . . . . . . . . . . . . . . . . . . . . 26.....................................................26 4. Caveats. . . . . . . . . . . . . . . . . . . . . . . . . . . 27........................................................27 4.1. Offering All Available Media Formats. . . . . . . . . . 27......................27 4.2. Handling Re-INVITES in a B2BUA. . . . . . . . . . . . . 28............................28 5. Security Considerations. . . . . . . . . . . . . . . . . . . 28........................................29 5.1. Networksecurity . . . . . . . . . . . . . . . . . . . . 28Security ..........................................29 5.2. SIP(signaling) security . . . . . . . . . . . . . . . . 29(Signaling) Security ..................................29 5.3. RTP(media) security . . . . . . . . . . . . . . . . . . 29(Media) Security ......................................30 5.4. Mediafiltering . . . . . . . . . . . . . . . . . . . . . 29Filtering ...........................................30 6.IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 7.Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 30 8. Revision History . . . . . . . . . . . . . . . . . . . . . . 31 8.1. Changes from draft-worley-service-example-00 to draft- worley-service-example-01 . . . . . . . . . . . . . . . . 31 8.2. Changes from draft-worley-service-example-01 to draft- worley-service-example-02 . . . . . . . . . . . . . . . . 31 8.3. Changes from draft-worley-service-example-02 to draft- worley-service-example-03 . . . . . . . . . . . . . . . . 31 8.4. Changes from draft-worley-service-example-03 to draft- worley-service-example-04 . . . . . . . . . . . . . . . . 31 8.5. Changes from draft-worley-service-example-04 to draft- worley-service-example-05 . . . . . . . . . . . . . . . . 32 8.6. Changes from draft-worley-service-example-05 to draft- worley-service-example-06 . . . . . . . . . . . . . . . . 32 8.7. Changes from draft-worley-service-example-06 to draft- worley-service-example-07 . . . . . . . . . . . . . . . . 32 8.8. Changes from draft-worley-service-example-07 to draft- worley-service-example-08 . . . . . . . . . . . . . . . . 33 8.9. Changes from draft-worley-service-example-08 to draft- worley-service-example-09 . . . . . . . . . . . . . . . . 33 8.10. Changes from draft-worley-service-example-09 to draft- worley-service-example-10 . . . . . . . . . . . . . . . . 33 8.11. Changes from draft-worley-service-example-10 to draft- worley-service-example-11 . . . . . . . . . . . . . . . . 33 8.12. Changes from draft-worley-service-example-11 to draft- worley-service-example-12 . . . . . . . . . . . . . . . . 33 8.13. Changes from draft-worley-service-example-12 to draft- worley-service-example-13 . . . . . . . . . . . . . . . . 33 8.14. Changes from draft-worley-service-example-13 to draft- worley-service-example-14 . . . . . . . . . . . . . . . . 33 8.15. Changes from draft-worley-service-example-14 to draft- worley-service-example-15 . . . . . . . . . . . . . . . . 34 9.................................................30 7. References. . . . . . . . . . . . . . . . . . . . . . . . . 34 9.1......................................................31 7.1. Normative References. . . . . . . . . . . . . . . . . . 34 9.2.......................................31 7.2. Informative References. . . . . . . . . . . . . . . . . 34 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36....................................32 1. Introduction WithinSIP[RFC3261]-based systems,systems based on SIP [RFC3261], 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 is where,with this 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 implementmusic- on-holdmusic on hold in a way that is fullycompliant with the standards.standards-compliant. The purpose of this document is to describe a method that is reasonably simple yet fully effective and standards-compliant. This method has significant advantages over other methods now in use, as described in Section 3. All current methods of implementingmusic-on-holdmusic on hold interoperate with each other, in that the two user agents in a call can use different methods for implementingmusic-on-holdmusic on hold with the same functionality as if either of the methods was used by both user agents. Thus, there is no loss of functionality if different music-on-hold methods are used by different user agents within a telephonesystem,system or if a single user agent uses different methods within differentcalls,calls or at different times within one call. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Technique The essence of the technique is that when the executingUAuser agent (UA) (the user's UA) performs a re-INVITE of the remote UA (the other user's UA) to establish the hold state, it provides noSDP[RFC4566] offer[RFC3264][RFC6337],Session Description Protocol (SDP) [RFC4566] offer [RFC3264] [RFC6337], thus compelling the remote UA to provide an SDP offer. The executing UA then extracts the offer SDP from the remote UA's 2xxresponse,response 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. The media source's answer SDP is returned to the remote UA in the ACK to the re-INVITE. 2.1. Placing a Call on Hold and Establishing an External Media Stream 1. The executing user instructs the executing UA to put the dialogon-hold.on hold. 2. The executing UA sends a re-INVITE without SDP to the remote UA, which forces the remote UA to provide an SDP offer in its 2xx response. The Contact header of the re-INVITE includes the '+sip.rendering="no"' field parameter to indicate that it is putting the call onhold. ([RFC4235] section 5.2)hold ([RFC4235], Section 5.2). 3. The remote UA sends a 2xx to there-INVITE,re-INVITE and includes an SDP offer giving its own listening address/port. If the remote UA understands the sip.rendering feature parameter, the offer may indicate that it will not send media by specifying the media directionalities as "recvonly" (the reverse of"on-hold")"on hold") or "inactive". But the remote UA may offer to send media. 4. The executing UA uses this offer to derive the offer SDP of an initial INVITE that it sends to the configured 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 payload type numbers. But the media directionalities are restricted to "recvonly" or "inactive" as appropriate. The executing UA may want or need to change theo="o=" line. In addition, somea=rtpmap"a=rtpmap" lines may need to be added to control the assignment of RTP payload typenumbers.[Section 2.8]numbers (Section 2.8). 5. The MOH source sends a 2xx response to the INVITE, which contains an SDP answer that should include its media source address as its listening address/port. This SDP mustnecessarily[RFC3264]necessarily specify "sendonly" or "inactive" as the directionality for all mediastreams.streams [RFC3264]. Although this address/port should receive no RTP, the specified port determines the port for receivingRTCPthe RTP Control Protocol (RTCP) (and conventionally, for sendingRTCP[RFC4961]).RTCP [RFC4961]). By convention, UAs use their declared RTP listening ports as their RTP source ports aswell.[RFC4961]well [RFC4961]. The answer SDP will reach the remote UA, thus informing it of the address/port from which the MOH media willcome,come and presumably preventing the remote UA from ignoring the MOH media if the remote UA filters media packets based on the source address. This functionality requires the SDP answer to contain the sending address in thec="c=" line, even though the MOH source does not receiveRTP.)RTP. 6. The executing UA sends this SDP answer as its SDP answer in the ACK for the re-INVITE to the remote UA. Theo="o=" line in the answer must be modified to be within the sequence ofo="o=" lines previously generated by the executing UA in the dialog. Any dynamic payload type number assignments that have been created in the answer must be recorded in the state of the original dialog. 7. Due to the sip.rendering feature parameter in the Contact header of the re-INVITE and the media directionality in the SDP answer contained in the ACK, the on-hold state of the dialog is established (at the executing end). 8. After this point, the MOH source generates RTP containing the music-on-holdmedia,media and sends it directly to the listening address/port of the remote UA. The executing UA maintains two dialogs (one to the remote UA, one to the MOHsource),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 executing user instructs the executing UA to take the dialogoff-hold.off hold. 2. The executing UA sends a re-INVITE to the remote UA with SDP that requests to receive media. The Contact header of the re-INVITE does not include the '+sip.rendering="no"' field parameter. (It may contain a sip.rendering field parameter with value "yes" or "unknown", or it may omit the field parameter.)ThusThus, this re- INVITE removes the on-hold state of the dialog (at the executing end). (Note that the version ino="o=" line of the offered SDP must account for the SDP versions that were passed through from the MOH source. Also note that any payload type numbers that were assigned in SDP provided by the MOH source must be respected.) 3. When the remote UA sends a 2xx response to the re-INVITE, the executing UA sends a BYE request in the dialog to the MOH source. 4. After this point, the MOH source does not generate RTP and ordinary RTP flow is reestablished in the original dialog. 2.3. Example Message Flow This section shows a message flowwhichthat is an example of this technique. The scenariois:is as follows. Alice establishes a call with Bob. Bob then places the call on hold, withmusic-on-holdmusic on hold provided from an external source. Bob then takes the call off hold. In this scenario, Bob's user agent is the executing UA, while Alice's UA is the remote UA. 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 Source Alice establishes the call: | | | | INVITE F1 | | |--------------->| | | 180 Ringing F2 | | |<---------------| | | 200 OK F3 | | |<---------------| | | ACK F4 | | |--------------->| | | RTP | | |<==============>| | | | | Bob places Alice on hold, compelling Alice's UA to provide SDP: | | | | INVITE F5 | | | (no SDP) | | |<---------------| | | 200 OK F6 | | | (SDP offer) | | |--------------->| | | | | Bob's UA initiatesmusic-on-hold:music on hold: | | | | | INVITE F7 | | | (SDP offer, | | | rev. hold) | | |------------->| | | 200 OK F8 | | | (SDP answer, | | | hold) | | |<-------------| | | ACK F9 | | |------------->| | | | Bob's UA provides an SDP answer containing the address/port oftheMusic Source: | | | | ACK F10 | | | (SDP answer, | | | hold) | | |<---------------| | | no RTP | | |<..............>| | | Music-on-hold RTP | |<==============================| | | | The music on hold is active. Bob takes Alice off hold: | | | | INVITE F11 | | | (SDP offer) | | |<---------------| | | 200 OK F12 | | | (SDP answer) | | |--------------->| | | ACK F13 | | |<---------------| | | | BYE F14 | | |------------->| | | 200 F15 | | |<-------------| | RTP | | |<==============>| | | | | The normal media session between Alice and Bob is resumed. /* 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 <sips:alice@atlanta.example.com>;tag=1234567 To: Bob <sips:bob@biloxi.example.com> Call-ID: 12345600@atlanta.example.com CSeq: 1 INVITE Contact: <sips:a8342043f@atlanta.example.com;gr> 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 ;received=192.0.2.103 From: Alice <sips:alice@atlanta.example.com>;tag=1234567 To: Bob <sips:bob@biloxi.example.com>;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 1 INVITE Contact: <sips:bob@biloxi.example.com> 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 <sips:alice@atlanta.example.com>;tag=1234567 To: Bob <sips:bob@biloxi.example.com>;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 1 INVITE Contact: <sips:bob@biloxi.example.com> 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 <sips:alice@atlanta.example.com>;tag=1234567 To: Bob <sips:bob@biloxi.example.com>;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. */ /* 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 <sips:alice@atlanta.example.com>;tag=1234567 From: Bob <sips:bob@biloxi.example.com>;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 712 INVITE Contact: <sips:bob@biloxi.example.com>;+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 <sips:alice@atlanta.example.com>;tag=1234567 From: Bob <sips:bob@biloxi.example.com>;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 712 INVITE Contact: <sips:a8342043f@atlanta.example.com;gr> 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 /* Bob's UA initiatesmusic-on-hold.music on hold. */ /* This INVITE contains Alice's offer, but with the media direction set to "reverse hold", receive-only. */ F7 INVITE Bob -> Music Source INVITE sips:music@source.example.com SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bKnashds9 Max-Forwards: 70 From: Bob <sips:bob@biloxi.example.com>;tag=02134 To: Music Source <sips:music@source.example.com> Call-ID: 4802029847@biloxi.example.com CSeq: 1 INVITE Contact: <sips:bob@biloxi.example.com> 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 Source -> Bob SIP/2.0 200 OK Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bKnashds9 ;received=192.0.2.105 From: Bob <sips:bob@biloxi.example.com>;tag=02134 To: Music Source <sips:music@source.example.com>;tag=56323 Call-ID: 4802029847@biloxi.example.com Contact: <sips:music@source.example.com>;automaton ;+sip.byeless;+sip.rendering="no" CSeq: 1 INVITE Content-Length: [omitted] v=0 o=MusicSource 2890844576 2890844576 IN IP4 source.example.com s= c=IN IP4 source.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendonly F9 ACK Bob -> Music Source ACK sips:music@source.example.com SIP/2.0 Via: SIP/2.0/TLS source.example.com:5061 ;branch=z9hG4bK74bT6 From: Bob <sips:bob@biloxi.example.com>;tag=02134 To: Music Source <sips:music@source.example.com>;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 fromtheMusicSource,Source and thus contains the address/port from whichtheMusic Source will send media, and implies the address/portwhich thethat Music Source will use to send/receive RTCP. */ 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 <sips:alice@atlanta.example.com>;tag=1234567 From: Bob <sips:bob@biloxi.example.com>;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 712 ACK Contact: <sips:bob@biloxi.example.com>;+sip.rendering="no" 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 source.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. */ 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 <sips:alice@atlanta.example.com>;tag=1234567 From: Bob <sips:bob@biloxi.example.com>;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 713 INVITE Contact: <sips:bob@biloxi.example.com> 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 <sips:alice@atlanta.example.com>;tag=1234567 From: Bob <sips:bob@biloxi.example.com>;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 713 INVITE Contact: <sips:a8342043f@atlanta.example.com;gr> 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 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 <sips:alice@atlanta.example.com>;tag=1234567 From: Bob <sips:bob@biloxi.example.com>;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 713 ACK Contact: <sips:bob@biloxi.example.com> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Length: 0 F14 BYE Bob -> Music Source BYE sips:music@source.example.com SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bK74rf Max-Forwards: 70 From: Bob <sips:bob@biloxi.example.com>;tag=02134 To: Music Source <sips:music@source.example.com>;tag=56323 Call-ID: 4802029847@biloxi.example.com CSeq: 2 BYE Contact: <sips:bob@biloxi.example.com> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Content-Length: [omitted] F15 200 OK Music Source -> Bob SIP/2.0 200 OK Via: SIP/2.0/TLS atlanta.example.com:5061 ;branch=z9hG4bK74rf ;received=192.0.2.103 From: Bob <sips:bob@biloxi.example.com>;tag=02134 To: Music Source <sips:music@source.example.com>;tag=56323 Call-ID: 4802029847@biloxi.example.com Contact: <sips:music@source.example.com>;automaton ;+sip.byeless;+sip.rendering="no" CSeq: 2 BYE Content-Length: 0 /* Normal media session between Alice and Bob isresumedresumed. */ 2.4. Receiving Re-INVITE and UPDATE from the Remote UA While the call ison-hold,on hold, the remote UA can send a request to modify the SDP or the feature parameters of its Contact header. This can be done with either an INVITE or UPDATE method, both of which have much the same effect in regard to MOH. A common reason for a re-INVITE is when the remote UA desires to put the dialog on hold on its end. And because of the need to support this case, an implementation must process INVITEs and UPDATEs during the on-hold state as described below. The executing UA handles these requests by echoing requests and responses: an incoming request from the remote UA causes the executing UA to send a similar request to the MOHsourcesource, and an incoming response from the MOH source causes the executing UA to send a similar response to the remote UA. In all cases, SDP offers or answers that are received are added as bodies to the stimulated request or response to the other UA. The passed-through SDP will usually need itso="o=" line modified. The directionality attributes may need to be restricted by changing "active" to "recvonly" and "sendonly" to "inactive", as the executing UA will not render media from the remote UA. (If all passed-through directionality attributes are "inactive", the optimization described insectionSection 2.10 may be applied.) In regard to payload type numbers, since the mapping has already been established within the MOH dialog,a=rtpmap"a=rtpmap" lines need not be added. 2.5. Receiving INVITE with Replaces The executing UA must be prepared to receive an INVITE request with a Replaces header that specifies the dialog with the remote UA. If the executing UA wants to create this new dialog in the on-hold state, it creates a new dialog with the MOH source to obtain MOH. The executing UA negotiates the SDP within the dialog created by theINVITE-with-ReplacesINVITE with Replaces by passing the offer through to the new MOH dialog (if the INVITE contains anoffer),offer) or by creating the new MOH dialog with an offerless INVITE (if the INVITE does not contain an offer). Continuing the example of Section 2.3, the executing UA receives anINVITE-with-ReplacesINVITE with Replaces that contains an offer: Alice Bob Music Source Carol (For example, Alice has called Carol and initiates an attended transfer by sending a REFER to Carol, causing Carol to send anINVITE-with-ReplacesINVITE with Replaces to Bob.) Bob receivesINVITE-with-ReplacesINVITE with Replaces from Carol: | | | | | | | INVITE/Replaces | | | | From: Carol | | | | To: Bob | | | | (SDP offer) | | |<-------------------------------| | | INVITE | | | | From: Bob | | | | To: Music Source | | | (SDP offer, | | | | rev. hold) | | | |------------->| | | | 200 OK | | | | From: Bob | | | | To: Music Source | | | (SDP answer, | | | | hold) | | | |<-------------| | | | ACK | | | | From: Bob | | | | To: Music Source | | |------------->| | | | | 200 OK | | | | From: Carol | | | | To: Bob | | | | (SDP answer, | | | | hold) | | |------------------------------->| | | | ACK | | | | From: Carol | | | | To: Bob | | |<-------------------------------| | | | Music-on-hold RTP | | |================>| | | | | Bob terminates the previous dialog with Alice: | | | | | BYE | | | | From: Bob | | | | To: Alice | | | |<---------------| | | | 200 OK | | | | From: Bob | | | | To: Alice | | | |--------------->| | | | | | | Bob terminates the MOH dialog for the dialog with Alice: | | | | | | BYE | | | | From: Bob | | | | To: Music Source | | |------------->| | | | 200 OK | | | | From: Music Source | | | To: Bob | | | |<-------------| | | | | | The new session continues on hold, between Bob and Carol. 2.6. Receiving REFER from the Remote UA The executing UA must be prepared to receive a REFER request within the dialog with the remote UA. The SDP within the dialog created by the REFER is negotiated by sending an offerless INVITE (or offerless re-INVITE) to the MOH source to obtain anoffer,offer and then using that offer in the INVITE to the refer target. Similar processing is used for an out-of-dialog REFER whose Target- Dialog header refers to the dialog with the remote UA. Continuing the example of Section 2.3, the executing UA receives anINVITE-with-ReplacesINVITE with Replaces that contains an offer: Alice Bob Music Source Carol (For example, Alice initiates an unattended transfer of the call to Carol by sending a REFER to Bob.) Bob receives REFER from Alice: | | | | | REFER | | | | From: Bob | | | | To: Alice | | | | Refer-To: Carol| | | |--------------->| | | | | re-INVITE | | | | From: Bob | | | | To: Music Source | | | (no SDP) | | | |------------->| | | | 200 OK | | | | From: Bob | | | | To: Music Source | | | (SDP offer, | | | | hold) | | | |<-------------| | | | | INVITE | | | | From: Bob | | | | To: Carol | | | | (SDP offer, | | | | hold) | | |------------------------------->| | | | 200 OK | | | | From: Bob | | | | To: Carol | | | | (SDP answer, | | | | rev. hold) | | |------------------------------->| | | ACK | | | | From: Bob | | | | To: Music Source | | | (SDP answer, | | | | rev. hold) | | | |------------->| | | | | ACK | | | | From: Bob | | | | To: Carol | | |------------------------------->| | | | Music-on-hold RTP | | |================>| | | | | Bob terminates the previous dialog with Alice: | | | | | BYE | | | | From: Bob | | | | To: Alice | | | |<---------------| | | | 200 OK | | | | From: Bob | | | | To: Alice | | | |--------------->| | | | | | | 2.7. Receiving Re-INVITE and UPDATE from theMusic-On-HoldMusic-on-Hold Source It is possible for the MOH source to send a re-INVITE or UPDATE request, and the executing UA can support doing so in similar manner as requests from the remote UA. However, if the MOH source is within the same administrative domain as the executing UA, the executing UA may have knowledge that the MOH source will not (or need not) make suchrequests,requests and so can respond to any such request with a failure response, avoiding the need to pass the request through. The 403 (Forbidden) response is suitable for this purpose because [RFC3261] specifies that this response indicates "the request SHOULD NOT be repeated". However, in an environment in whichICE[RFC5245]Interactive Connectivity Establishment (ICE) [RFC5245] is supported, the MOH source may need to send requests as part of ICE negotiation with the remote UA. Hence, in environments that support ICE, the executing UA must be able to pass through requests from the MOH source as well as requests from the remote UA. Again, as SDP is passed through, itso="o=" line will need to be modified. In some cases, the directionality attributes will need to be restricted. 2.8. Handling Payload Type Numbers 2.8.1. Analysis In this technique, the MOH source generates an SDP answer that the executing UA presents to the remote UA as an answer within the original dialog. In basic functionality, this presents no problem, because[RFC3264] (section 6.1, at[RFC3264], Section 6.1 (at the very end) specifies that the payload type numbers used in either direction of RTP are the ones specified in the SDP sent by the recipient of the RTP. Thus, the MOH source will send RTP to the remote UA using the payload type numbers specified in the offer SDP it received (ultimately) from the remote UA. But strict compliance to[RFC3264] (section 8.3.2)[RFC3264], Section 8.3.2 requires that payload type numbers used in SDP may only duplicate the payload type numbers used in any previous SDP sent in the same direction if the payload type numbers represent the same media format (codec) as they did previously. However, the MOH source has no knowledge of the payload type numbers previously used in the original dialog, and it may accidentally specify a different media format for a previously used payload type number in its answer (or in a subsequently generated INVITE or UPDATE). This would cause no problem with media decoding, as it cannot send any format that was not in the remote UA's offer, but it would violate [RFC3264]. Strictly speaking, it is impossible to avoid this problem because the generator of a first answer in its dialog can choose the payload numbers independently of the payload numbers in the offer, and the MOH server believes that its answer is first in the dialog.ThusThus, the only absolute solution is to have the executing UA rewrite the SDP that passes through it to reassign payload type numbers, which would also require it to rewrite the payload type numbers in the RTP packets -- a very undesirable solution. The difficulty solving this problem (and similar problems in other situations) argues that strict adherence should not be required to the rule that payload type numbers not be reused for different codecs. If an implementation of this technique were to interact with a remote UA that requires strict compliance to [RFC3264], the remote UA might reject the SDP provided by the MOH server. (InsectionSection 2.3, this SDP is in message F10.) As a result, the MOH session will not be established, and the call will remain in its initial state. Implementors that wish to avoid this situation need to implement the solution in Section 2.8.2. 2.8.2. Solution to the Problem We can construct a technique that will strictly adhere to the payload type rule by exploiting a SHOULD-level requirement in[RFC3264] (section 6.1):[RFC3264], Section 6.1: "In the case of RTP, if a particular codec was referenced with a specific payload type number in the offer, that same payload type number SHOULD be used for that codec in theanswer."answer". Or rather, we exploit the "implied requirement" that if a specific payload number in the offer is used for a particular codec, then the answer should not use that payload number for a different codec. If the MOH source obeys this restriction, the executing UA can modify the offer SDP to "reserve" all payload type numbers that have ever been offered by the executing UA to prevent the MOH source from using them for different media formats. When the executing UA is composing the INVITE to the MOH source, it compiles a list of all the(dynamically-assigned)(dynamically assigned) payload type numbers and associated media formatswhichthat have been used by it (or by MOH sources on its behalf) in the original dialog. (The executing UA mustbe maintainingmaintain a list of all previously used payload type numbers anyway, in order to comply with [RFC3264].) Any payload type number that is present in the offer but has been used previously by the executing UA in the original dialog for a different media format is rewritten to describe a dummy media format. (One dummy media format name can be used for many payload type numbers as multiple payload type numbers can refer to the same media format.) A payload type number is added to describe the deleted media format, the number being either previously unused or previously used by the executing UA for that media format. Any further payload type numberswhichthat have been used by the executing UA in the original dialog butwhichthat are not mapped to a media format in the current offer are then mapped to a dummy media format. The result is that the modified offer SDP: 1. offers the same set of media formats (ignoring dummies) as the original offer SDP (though possibly with different payload type numbers), 2. associates every payload type number either with a dummy media format or with the media format that the executing UA has previously used it for, and 3. provides a (real or dummy) media format for every payload type number that the executing UA has previously used. These properties are sufficient to force an MOH server that obeys the implied requirement to generate an answer that is a correct answer to the original offer and is also compatible with previous SDP from the executing UA. Note that any re-INVITEs from the remote UA that the executing UA passes through to the MOH server require similar modification, as payload type numbers that the MOH server receives in past offers are not absolutely reserved against its use (as they have not been sent in SDP by the MOH server) nor is there a SHOULD-level proscription against using them in the current answer (as they do not appear in the current offer). This should provide an adequate solution to the problems with payload type numbers, as it will fail only if (1) the remote UA is particular that other UAs follow the rule about not redefining payload type numbers, and (2) the MOH server does not follow the implied requirement of[RFC3264] section[RFC3264], Section 6.1. 2.8.3. Example of the Solution Let us show how this process works by modifying the example of Section 2.3 with this specific assignment of supported codecs: Alice supports formats X andYY. Bob supports formats X andZZ. Music Source supports formats Y andZZ. In this case, the SDP exchanges are: F1 offers X and Y, F3 answers X andZ (which cannotZ. (Only X can beused)used.) F6 offers X and Y, but F7 offers X, Y, and a place-holder to block use of type9292. F8/F10 answersYY. The messages that are changed from Section 2.3 are: 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 <sips:alice@atlanta.example.com>;tag=1234567 To: Bob <sips:bob@biloxi.example.com> Call-ID: 12345600@atlanta.example.com CSeq: 1 INVITE Contact: <sips:a8342043f@atlanta.example.com;gr> 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 90 91 a=rtpmap:90 X/8000 a=rtpmap:91 Y/8000 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 <sips:alice@atlanta.example.com>;tag=1234567 To: Bob <sips:bob@biloxi.example.com>;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 1 INVITE Contact: <sips:bob@biloxi.example.com> 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 90 92 a=rtpmap:90 X/8000 a=rtpmap:92 Z/8000 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 <sips:alice@atlanta.example.com>;tag=1234567 From: Bob <sips:bob@biloxi.example.com>;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 712 INVITE Contact: <sips:a8342043f@atlanta.example.com;gr> 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 90 91 a=rtpmap:90 X/8000 a=rtpmap:91 Y/8000 a=active F7 INVITE Bob -> Music Source INVITE sips:music@source.example.com SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bKnashds9 Max-Forwards: 70 From: Bob <sips:bob@biloxi.example.com>;tag=02134 To: Music Source <sips:music@source.example.com> Call-ID: 4802029847@biloxi.example.com CSeq: 1 INVITE Contact: <sips:bob@biloxi.example.com> 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 90 91 92 a=rtpmap:90 X/8000 a=rtpmap:91 Y/8000 a=rtpmap:92 x-reserved/8000 a=recvonly F8 200 OK Music Source -> Bob SIP/2.0 200 OK Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bKnashds9 ;received=192.0.2.105 From: Bob <sips:bob@biloxi.example.com>;tag=02134 To: Music Source <sips:music@source.example.com>;tag=56323 Call-ID: 4802029847@biloxi.example.com Contact: <sips:music@source.example.com>;automaton ;+sip.byeless;+sip.rendering="no" CSeq: 1 INVITE Content-Length: [omitted] v=0 o=MusicSource 2890844576 2890844576 IN IP4 source.example.com s= c=IN IP4 source.example.com t=0 0 m=audio 49170 RTP/AVP 91 a=rtpmap:91 Y/8000 a=sendonly 2.9. Dialog/Session Timers The executing UA may discover that either the remote UA or the MOH source wishes to use dialog/session livenesstimers.[RFC4028]timers [RFC4028]. Since the timers verify the liveness of dialogs, not sessions (despite the terminology of [RFC4028]), the executing UA can support the timers on each dialog (to the remote UA and to the MOH source) independently. (If the executing UA becomes obliged to initiate a refresh transaction, it must send an offerless UPDATE or re-INVITE, as if it sends an offer, the remote element has the opportunity to provide an answerwhichthat is different from its previous SDP, which could not easily be conveyed to the other remote element.) 2.10. When the Media Stream Directionality is "inactive" The directionality of the media stream in the SDP offer in an INVITE or re-INVITE to the music source can be "inactive" if the SDP offer from the remote UA was "sendonly" or "inactive". Generally, this happens when the remote UA also has put the call on hold and provided a directionality of "sendonly". In this situation, the executing UA can omit establishing the dialog with the music source (or can terminate the existing dialog with the music source). If the executing UA uses this optimization, it creates the SDP answer itself, with directionality "inactive" and using its own RTP/RTCP ports, and returns that answer to the remote UA. The executing UA must be prepared for the remote UA to send a re- INVITE with directionality "active" or "recvonly", in which case the executing UA must initiate a dialog with the music source, as described above. 2.11. Multiple Media Streams There may be multiple media streams (multiplem="m=" lines) in any of thetheSDPs involved in the dialogs. As the SDPs are manipulated, each media description (each starting with anm="m=" line) is manipulated as described above for a single media stream, largely independently of the manipulation of the other media streams. But there are some elaborations that the executing UA may implement to achieve specific effects. If the executing UA desires to present only certain media types as on-hold media, when passing the offer SDP through, it can reject any particular media streams by setting the port number in them="m=" line tozero.[RFC3264]zero [RFC3264]. This ensures that the answer SDP will also have a rejection for thatm="m=" line. If the executing UA wishes to provide its own on-hold media for a particularm="m=" line, it can do so by providing the answer information for thatm="m=" line. The executing UA may decide to do this when the offer SDP is received (by modifying them="m=" line to rejected state when sending it to the musicsource),source) or upon receiving the answer from the music source and discovering that them="m=" line has been rejected. The executing UA may not want to pass a rejectedm="m=" line from the music source to the remote UA (when the remote UA provided a non- rejectedm= line),"m=" line) and may instead provide an answer with directionality "inactive" (and specifying its own RTP/RTCP ports). 3. Advantages This technique for providingmusic-on-holdmusic on hold has advantages over other methods now inuse:use, including: 1. The original dialog is not transferred to another UA, so the "remote endpoint URI" displayed by the remote endpoint's user interface and dialog eventpackage[RFC4235]package [RFC4235] does not change during the call, as contrasted to the method in[RFC5359] section[RFC5359], Section 2.3. This URI is usually displayed to the user as thethename and number of the other party on the call, and it is desirable for it not to change to that of the MOH server. 2. Compared to [RFC5359], this method does not require use of an out-of-dialog REFER, which is not otherwise used much in SIP. Out-of-dialog REFERs may not be routed correctly, since neither the From nor Contact URI of the original dialog may route correctly to the remote UA. Also, out-of-dialog requests to UA URIs may not be handled correctly by authorization mechanisms. 3. The music-on-hold media are sent directly from the music-on-hold source to the remote UA, rather than being relayed through the executing UA. This reduces the computational load on the executing UA and can reduce the load on the network (by eliminating "hairpinning" of the media through the link serving the executing UA). 4. The remote UA sees, in the incoming SDP, the address/port that the MOH source will send MOH media from (assuming that the MOH source follows the convention of sending its media from its advertisedmedia listeningmedia-listening address/port).ThusThus, the remote UA will render the MOH media even if it is filtering incoming media based on originating address as a media security measure. 5. The technique requires relatively simple manipulation ofSDP, andSDP; inparticular:particular, (1) it does not require a SIP element to modify unrelated SDP to be acceptable to be sent within an already established sequence of SDP (a problem with[I-D.ietf-sipping-service-examples-11] section[SIP-SERV-EX], Section 2.3), and (2) it does not require converting an SDP answer into an SDP offer (which was a problem with the-00initial draft version of this document, as well as with[I-D.ietf-sipping-service-examples-11]).[SIP-SERV-EX]). 4. Caveats 4.1. Offering All Available Media Formats Unnecessary failures can happen if SDP offerers do not always offer all media formats that they support. Doing so is considered best practice([RFC6337] sections([RFC6337], Sections 5.1 and 5.3), but some SIP elements offer only formats that have already been in use in the dialog. An example of how omitting media formats in an offer can lead to failure is asfollows:follows. Suppose that the UAs in Section 2.3 each support the following media formats: Alice supports formats X andYY. Bob supports formats X andZZ. Music Source supports formats Y andZZ. In this case, the SDP exchanges are: 1. Alice calls Bob: Alice offers X and Y (messageF1)F1). Bob answers X(F3)(F3). 2. Bob puts Alice on hold: Alice (via Bob) offers X and Y (F6 andF7)F7). Music Source (via Bob) answers Y (F8 andF10)F10). 3. Bob takes Alice off hold: Bob offers X and Z(F11)(F11). Alice answers X(F12)(F12). Note that in exchange 2, if Alice assumes that because only format X is currently in use that she should offer only X, the exchange fails. In exchange 3, Bob offers formats X and Z, even though neither is in use at the time (because Bob is not involved in the media streams). 4.2. Handling Re-INVITES in a B2BUA Many UAs provide MOH in the interval during which it is processing a blind transfer, between receiving the REFER and receiving the final response to the stimulated INVITE. This process involves switching the user's interface between three media sources: (1) the session of the original dialog, (2) the session with the MOH server, and (3) the session of the newdialog; itdialog. It also involves a number of race conditions that must be handled correctly. If the UA is aB2BUAback-to- back user agent (B2BUA) whose "other side" is maintaining a single dialog with another UA, each switching of media sources potentially causes a re-INVITE transaction within the other-side dialog. Since re-INVITEs take time and must be sequenced correctly([RFC3261] section([RFC3261], Section 14), such a B2BUA must allow the events on each side to be non-synchronous and must coordinate them correctly. Failing to do so will lead to "glare" errors (491 or 500), leaving the other-side UA not rendering the correct session. 5. Security Considerations 5.1. NetworksecuritySecurity Some mechanism outside the scope of this document must inform the executing UA of the MOH server that it should use. Care must be exercised in selecting the MOH server, because signaling informationwhichthat is part of the original dialog will be transmitted along the path from the executing UA to the server. If the path between the executing UA and the server is not entirely contained within every network domain that contains the executing UA, the signaling between the UA and the server may be protected by different network security than is applied to the original dialog. Care must also be exercised because media information that is part of the original dialog will be transmitted along the path between the remote UA and the server. If the path between the remote UA and the server does not pass through the same network domains as the path between the remote UA and the executing UA, the media between the UA and the server may be protected by different network security than is applied to the original dialog. These requirements may be satisfied by selectingaan MOH server that is in the same administrative and network domain as the executingUA,UA and whose path to all external addresses is the same as the UA's path to those addresses. 5.2. SIP(signaling) security(Signaling) Security The executing UA and the MOH server will usually be within the same administrativedomaindomain, and the SIP signaling path between them will lie entirely within that domain. In this case, the administrator of the domain should configure the UA and server to apply to the dialog between them a level of security that is appropriate for the administrative domain. If the executing UA and the MOH server are not within the same administrative domain, the SIP signaling between them should be at least as secure as the SIP signaling between the executing UA and the remote UA. Thus, the MOH server should support all of the SIP security facilities that are supported by the executing UA, and the executing UA should use in its dialog with the MOH server all SIP security facilities that are used in its dialog with the remote UA. 5.3. RTP(media) security(Media) Security The RTP for the MOH media will pass directly between the MOH server and the remoteUA,UA and thus may pass outside the administrative domain of the executing UA. While it is uncommon for the contents of the MOH media to be sensitive (and the remote UA will not usually be generating RTP when it ison-hold),on hold), the MOH RTP should be at least as secure as the RTP between the executing UA and the remote UA. In order to make this possible, the MOH server should support all of the RTP security facilities that are supported by the executing UA. It is possible that the remote UA and the MOH server support an RTP security facility that the executing UA does notsupport,support and that it is desirable to use this facility for the MOH RTP. To enable doing so, the executing UA should pass the SDP between the remote UA and the MOH server completely, not omitting elements that it does not understand. 5.4. MediafilteringFiltering Some UAs filter incoming RTP based on the address of origin as a media security measure, refusing to render the contents of RTP packets that originate from an address that is not shown in the remote SDP as an RTP destination address. The remote UA in the original dialog may use this form of media filtering, and if the executing UA does not update the SDP to inform the remote UA of the source address of the MOH media, the remote UA may not render the MOH media. Note that the executing UA has no means for detecting that the remote UA uses media filtering, so the executing UA must assume that any remote UA uses media filtering. The technique described in this document ensures that any UA that should render MOH media will be informed of the source address of the media via the SDP that it receives. This allows such UAs to filter media without interfering with MOH operation. 6.IANA Considerations There are no IANA considerations. 7.Acknowledgments The original version of this proposal was derived from[I-D.ietf-sipping-service-examples-11] sectionSection 2.3 of [SIP-SERV-EX] and the similar implementation of MOH in theSnomsnom UA. Significant improvements to the sequence of operations, allowing improvements to the SDP handling, were suggested byVenkatesh[venkatesh].Venkatesh [VENKATESH]. JohnElwell[elwell]Elwell [ELWELL] pointed out the need for the executing UA to pass through re-INVITEs/UPDATEs in order to allow ICE negotiation, suggested mentioning the role of RTCP listening ports, suggested the possibility of omitting the dialog to the music source if the directionality would be "inactive", and pointed out that if there are multiple media streams, the executing UA may want to select which streams receive MOH. PaulKyzivat[kyzivat-1][kyzivat-2]Kyzivat [KYZIVAT-1] [KYZIVAT-2] pointed out the difficulties regarding reuse of payload type numbers and considerations that could be used to avoid those difficulties, leading to the writing of Section 2.8. Paul Kyzivat suggested adding Section 4.1 showing why offerers should always include all supported formats. M. Ranganathan pointed out the difficulties experienced by a B2BUA (Section 4.2) due to the multiple changes of media source. Section 4.1 was significantly clarified based on advice from AttilaSipos[sipos].Sipos [SIPOS]. The need to discuss dialog/sessiontimers[Section 2.9]timers (Section 2.9) was pointed out by RifaatShekh-Yusef[shekh-yusef].Shekh-Yusef [SHEKH-YUSEF]. Robert Sparks clarified the purpose of the "BestCommonCurrent Practice" status, leading to revising the intended status of this document to "Informational". In hisSecdirSecDir review, Stephen Kent pointed out that the Security Considerations should discuss the use of SIP and SDP security features by the MOH server. Numerous improvements to the text were due to reviewers, including Rifaat Shekh-Yusef and Richard Barnes.8. Revision History [Note7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFCEditor: Please remove this entire section upon publication as an RFC.] 8.1. Changes from draft-worley-service-example-00 to draft-worley- service-example-01 Removed the original "Example Message Flow"2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., andpromoted the "Alternative Example Message Flow" to replace it because of a number of flaws that were found during the discussion of -00 on the SIPPING mailing list. Described the use of the sip.rendering feature parameter to indicate on-hold status. 8.2. Changes from draft-worley-service-example-01 to draft-worley- service-example-02 Added discussion of passing though re-INVITEs and UPDATEs. Added discussion of payload type numbers. Added Acknowledgments section. 8.3. Changes from draft-worley-service-example-02 to draft-worley- service-example-03 Added Section 4.1 showing the importance of the offerer always including all supported media formats. Updated references. Revised handling of payload type numbers when passing offer to MOH server Section 2.8, based on observations by Paul Kyzivat. 8.4. Changes from draft-worley-service-example-03 to draft-worley- service-example-04 Added Section 4.2 discussing handling of re-INVITEs by B2BUAs when using this method. Added "avoidance of out-of-dialog REFER" as an advantage.Section 3 Added "automaton", "sip.rendering", and "sip.byeless" feature tags to the Contact URI of the Music Server in the examples.[RFC4235][RFC3840] Added initial discussion of dialog/session timer support.Section 2.9 Revised handling of payload type numbers based on further observations by Paul Kyzivat[kyzivat-2]. 8.5. Changes from draft-worley-service-example-04 to draft-worley- service-example-05 Changed references to "SPIT" to refer to "media security", per suggestion by Scott Lawrence. Removed reference to the idea of having the executing UA not maintain session timers itself, but rather, passing through session timer negotiation and updates. Examination showed this idea to be much more complex to implement than having the executing UA terminate session timers itself for both dialogs. (Suggested by Rifaat Shekh- Yusef.) On advice from Robert Sparks, changed the "intended status" from "BCP" to "Informational", and added a section to explain the change. Noted that the rule on not reusing payload type numbers is undesirable because it complicates third-party operations (as noted by Paul Kyzivat[kyzivat-3]). 8.6. Changes from draft-worley-service-example-05 to draft-worley- service-example-06 Updated author's contact information. On suggestion from John Elwell, added mention that the Music Source's SDP address/port implies its RTCP address/port, which will be used to receive RTCP. Updated references to [RFC5359] and [I-D.ietf-sipping-service-examples-11] to specify the sections of documents, which are the ones that discuss music on hold. 8.7. Changes from draft-worley-service-example-06 to draft-worley- service-example-07 Update reference to [RFC6337] to refer to the -18 version. 8.8. Changes from draft-worley-service-example-07 to draft-worley- service-example-08 Sections Section 2.10 and Section 2.11 added at the suggestion of John Elwell. 8.9. Changes from draft-worley-service-example-08 to draft-worley- service-example-09 Update reference to [RFC6337] to refer to RFC 6337. 8.10. Changes from draft-worley-service-example-09 to draft-worley- service-example-10 Renew Internet-Draft, no changes. 8.11. Changes from draft-worley-service-example-10 to draft-worley- service-example-11 Renew Internet-Draft, no changes. 8.12. Changes from draft-worley-service-example-11 to draft-worley- service-example-12 Numerous improvements resulting from Rifaat Shekh-Yusef's review, including: Adding examples for how the executing UA processes INVITE-with- Replaces and REFER directed toward the dialog with the remote UA. Recommending a 403 response to a re-INVITE/UPDATE request from the MOH server if the UA knows that it need not be acted upon. 8.13. Changes from draft-worley-service-example-12 to draft-worley- service-example-13 Improvements resulting from Richard Barnes' review. Update the Acknowledgments to credit the reviewers. 8.14. Changes from draft-worley-service-example-13 to draft-worley- service-example-14 Update RFC and Internet-Draft references to use tags giving their numbers/names rather than describing their contents, as suggested in the Secdir review by Stephen Kent. As suggested in the Secdir review by Stephen Kent, add sections to Security Considerations regarding use of SIP and SDP security by the MOH server. 8.15. Changes from draft-worley-service-example-14 to draft-worley- service-example-15 Several minor revisions from reviews by IESG and Gen-Art. 9. References 9.1. Normative References [RFC3261] 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. [RFC3264] Rosenberg, J.E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.9.2.7.2. Informative References[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005. [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, July 2007. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", BCP 144, RFC 5359, October 2008. [RFC6337] Okumura, S., Sawada, T., and P. Kyzivat, "Session Initiation Protocol (SIP) Usage of the Offer/Answer Model", RFC 6337, August 2011.[elwell][ELWELL] Elwell, J., "Subject: [Sipping] RE: I-D Action:draft- worley-service-example-00.txt", message to the IETF Sipping mailinglist msg14678,list, November 2007, <http://www1.ietf.org/mail- archive/web/sipping/current/msg14678.html>.[I-D.ietf-sipping-service-examples-11] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", I-D draft-ietf-sipping-service-examples-11, October 2006, <http://tools.ietf.org/id/draft-ietf- sipping-service-examples-11.txt>. [kyzivat-1][KYZIVAT-1] Kyzivat, P., "Subject: Re: [Sipping] I-D ACTION:draft- ietf-sipping-service-examples-11.txt", message to the IETF Sipping mailinglist msg12181,list, October 2006,<http://www1.ietf.org /mail-archive/web/sipping/current/msg12181.html>. [kyzivat-2] Kyzivat, P., "[Sip-implementors] draft-worley-service- example-02", sip-implementors mailing list 020426, September 2008, <http://lists.cs.columbia.edu/pipermail/ sip-implementors/2008-September/020426.html>. [kyzivat-3]<http://www1.ietf.org/ mail-archive/web/sipping/current/msg12181.html>. [KYZIVAT-2] Kyzivat, P.,"[Sip-implementors] draft-worley-service- example-02","Subject: [Sip-implementors] draft-worley- service-example-02", message to the sip-implementors mailinglist 020387,list, September 2008,<http://lists.cs.columbia.edu/pipermail/ sip-implementors/2008-September/020387.html>. [shekh-yusef]<http://lists.cs.columbia.edu/pipermail/sip-implementors/ 2008-September/020394.html>. [SHEKH-YUSEF] Shekh-Yusef, R.,"[sipcore]"Subject: [sipcore] draft-worley-service- example-03", message to the IETF Sipcore mailinglist msg00580,list, July 2009, <http://www.ietf.org/mail-archive/web/sipcore/ current/msg00580.html>.[sipos][SIPOS] Sipos, A.,"RE:"Subject: [Sip-implementors]draft-worley-service- example-02",draft-worley- service-example-02", message to the sip-implementors mailinglist 022002,list, March 2009,<http://lists.cs.columbia.edu/pipermail/sip- implementors/2009-March/022002.html>. [venkatesh]<http://lists.cs.columbia.edu/ pipermail/sip-implementors/2009-March/021970.html>. [SIP-SERV-EX] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", Work in Progress, October 2006. [VENKATESH] Venkatesh,.,"Subject: Re: [Sipping] I-D ACTION:draft- ietf-sipping-service-examples-11.txt", message to the IETF Sipping mailinglist msg12180,list, October 2006,<http://www1.ietf.org /mail-archive/web/sipping/current/msg12180.html>.<http://www1.ietf.org/ mail-archive/web/sipping/current/msg12180.html>. Author's Address Dale R. Worley Ariadne Internet Services, Inc. 738 Main St. Waltham, MA 02451 US Phone: +1 781 647 9199Email:EMail: worley@ariadne.com