summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7088.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7088.txt')
-rw-r--r--doc/rfc/rfc7088.txt2019
1 files changed, 2019 insertions, 0 deletions
diff --git a/doc/rfc/rfc7088.txt b/doc/rfc/rfc7088.txt
new file mode 100644
index 0000000..e0194f2
--- /dev/null
+++ b/doc/rfc/rfc7088.txt
@@ -0,0 +1,2019 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) D. Worley
+Request for Comments: 7088 Ariadne
+Category: Informational February 2014
+ISSN: 2070-1721
+
+
+ Session Initiation Protocol Service Example -- Music on Hold
+
+Abstract
+
+ "Music on hold" is one of the features of telephone systems that is
+ most desired by buyers of business telephone systems. Music on 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 implement music on hold in a way that is fully standards-
+ compliant. The implementation of music on hold described in this
+ document is fully 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 systems that perform authentication than the music-
+ on-hold method described in Section 2.3 of RFC 5359.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the 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 a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7088.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Worley Informational [Page 1]
+
+RFC 7088 Music on Hold February 2014
+
+
+Copyright Notice
+
+ Copyright (c) 2014 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Worley Informational [Page 2]
+
+RFC 7088 Music on Hold February 2014
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Requirements Language ......................................4
+ 2. Technique .......................................................4
+ 2.1. Placing a Call on Hold and Establishing an External
+ Media Stream ...............................................5
+ 2.2. Taking a Call off Hold and Terminating the External
+ Media Stream ...............................................6
+ 2.3. Example Message Flow .......................................6
+ 2.4. Receiving Re-INVITE and UPDATE from the Remote UA .........17
+ 2.5. Receiving INVITE with Replaces ............................17
+ 2.6. Receiving REFER from the Remote UA ........................19
+ 2.7. Receiving Re-INVITE and UPDATE from the
+ Music-on-Hold Source ......................................21
+ 2.8. Handling Payload Type Numbers .............................22
+ 2.8.1. Analysis ...........................................22
+ 2.8.2. Solution to the Problem ............................23
+ 2.8.3. Example of the Solution ............................24
+ 2.9. Dialog/Session Timers .....................................28
+ 2.10. When the Media Stream Directionality is "inactive" .......28
+ 2.11. Multiple Media Streams ...................................28
+ 3. Advantages .....................................................29
+ 4. Caveats ........................................................30
+ 4.1. Offering All Available Media Formats ......................30
+ 4.2. Handling Re-INVITES in a B2BUA ............................31
+ 5. Security Considerations ........................................31
+ 5.1. Network Security ..........................................31
+ 5.2. SIP (Signaling) Security ..................................32
+ 5.3. RTP (Media) Security ......................................32
+ 5.4. Media Filtering ...........................................32
+ 6. Acknowledgments ................................................33
+ 7. References .....................................................34
+ 7.1. Normative References ......................................34
+ 7.2. Informative References ....................................34
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Worley Informational [Page 3]
+
+RFC 7088 Music on Hold February 2014
+
+
+1. Introduction
+
+ Within 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": 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 implement music on
+ hold in a way that is fully 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 implementing music on hold interoperate with
+ each other, in that the two user agents in a call can use different
+ methods for implementing music 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 telephone system or if a
+ single user agent uses different methods within different 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 executing user 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 no 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 2xx 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.
+
+
+
+
+
+
+
+
+
+Worley Informational [Page 4]
+
+RFC 7088 Music on Hold February 2014
+
+
+2.1. Placing a Call on Hold and Establishing an External Media Stream
+
+ 1. The executing user instructs the executing UA to put the dialog
+ 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 on hold ([RFC4235], Section 5.2).
+
+ 3. The remote UA sends a 2xx to the 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") 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 the "o=" line. In addition, some
+ "a=rtpmap" lines may need to be added to control the assignment
+ of RTP payload type 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 must necessarily specify
+ "sendonly" or "inactive" as the directionality for all media
+ streams [RFC3264].
+
+ Although this address/port should receive no RTP, the specified
+ port determines the port for receiving the RTP Control Protocol
+ (RTCP) (and conventionally, for sending RTCP [RFC4961]).
+
+ By convention, UAs use their declared RTP listening ports as
+ their RTP source ports as well [RFC4961]. The answer SDP will
+ reach the remote UA, thus informing it of the address/port from
+ which the MOH media will 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 the
+ "c=" line, even though the MOH source does not receive RTP.
+
+
+
+
+Worley Informational [Page 5]
+
+RFC 7088 Music on Hold February 2014
+
+
+ 6. The executing UA sends this SDP answer as its SDP answer in the
+ ACK for the re-INVITE to the remote UA. The "o=" line in the
+ answer must be modified to be within the sequence of "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-hold 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 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 executing user instructs the executing UA to take the dialog
+ 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.) Thus, this
+ re-INVITE removes the on-hold state of the dialog (at the
+ executing end). (Note that the version in "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 flow that is an example of this
+ technique. The scenario is as follows. Alice establishes a call
+ with Bob. Bob then places the call on hold, with music 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
+
+
+
+Worley Informational [Page 6]
+
+RFC 7088 Music on Hold February 2014
+
+
+ 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 initiates music on hold:
+
+ | | |
+ | | INVITE F7 |
+ | | (SDP offer, |
+ | | rev. hold) |
+ | |------------->|
+ | | 200 OK F8 |
+ | | (SDP answer, |
+ | | hold) |
+ | |<-------------|
+ | | ACK F9 |
+ | |------------->|
+ | | |
+
+
+
+
+
+Worley Informational [Page 7]
+
+RFC 7088 Music on Hold February 2014
+
+
+ Bob's UA provides an SDP answer containing the address/port
+ of Music 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Worley Informational [Page 8]
+
+RFC 7088 Music on Hold February 2014
+
+
+ /* 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+Worley Informational [Page 9]
+
+RFC 7088 Music on Hold February 2014
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+Worley Informational [Page 10]
+
+RFC 7088 Music on Hold February 2014
+
+
+ /* 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
+
+
+
+Worley Informational [Page 11]
+
+RFC 7088 Music on Hold February 2014
+
+
+ /* 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 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Worley Informational [Page 12]
+
+RFC 7088 Music on Hold February 2014
+
+
+ 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 from Music Source and thus
+ contains the address/port from which Music Source will send media,
+ and implies the address/port that Music
+ Source will use to send/receive RTCP. */
+
+
+
+
+
+
+
+
+Worley Informational [Page 13]
+
+RFC 7088 Music on Hold February 2014
+
+
+ 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
+
+
+
+Worley Informational [Page 14]
+
+RFC 7088 Music on Hold February 2014
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+Worley Informational [Page 15]
+
+RFC 7088 Music on Hold February 2014
+
+
+ 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 is resumed. */
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Worley Informational [Page 16]
+
+RFC 7088 Music on Hold February 2014
+
+
+2.4. Receiving Re-INVITE and UPDATE from the Remote UA
+
+ While the call is 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 MOH source, 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 its "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
+ in Section 2.10 may be applied.) In regard to payload type numbers,
+ since the mapping has already been established within the MOH dialog,
+ "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 the
+ INVITE with Replaces by passing the offer through to the new MOH
+ dialog (if the INVITE contains an offer) or by creating the new MOH
+ dialog with an offerless INVITE (if the INVITE does not contain an
+ offer).
+
+
+
+
+
+
+
+
+
+
+
+Worley Informational [Page 17]
+
+RFC 7088 Music on Hold February 2014
+
+
+ Continuing the example of Section 2.3, the executing UA receives an
+ INVITE 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 an
+ INVITE with Replaces to Bob.)
+
+ Bob receives INVITE 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
+ | | |================>|
+ | | | |
+
+
+
+
+
+Worley Informational [Page 18]
+
+RFC 7088 Music on Hold February 2014
+
+
+ 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 an 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 an
+ INVITE with Replaces that contains an offer:
+
+
+
+
+
+
+
+
+
+
+Worley Informational [Page 19]
+
+RFC 7088 Music on Hold February 2014
+
+
+ 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 |
+ | |------------------------------->|
+
+
+
+
+
+Worley Informational [Page 20]
+
+RFC 7088 Music on Hold February 2014
+
+
+ | | | 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 the Music-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
+ such 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 which 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, its "o=" line will need to be
+ modified. In some cases, the directionality attributes will need to
+ be restricted.
+
+
+
+
+
+
+
+
+
+
+
+Worley Informational [Page 21]
+
+RFC 7088 Music on Hold February 2014
+
+
+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 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 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. Thus,
+ 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. (In Section 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.
+
+
+
+
+Worley Informational [Page 22]
+
+RFC 7088 Music on Hold February 2014
+
+
+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: "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 the
+ 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) payload type
+ numbers and associated media formats that have been used by it (or by
+ MOH sources on its behalf) in the original dialog. (The executing UA
+ must maintain 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 numbers that have been used by the executing
+ UA in the original dialog but that 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.
+
+
+
+
+Worley Informational [Page 23]
+
+RFC 7088 Music on Hold February 2014
+
+
+ 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 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 and Y.
+
+ Bob supports formats X and Z.
+
+ Music Source supports formats Y and Z.
+
+ In this case, the SDP exchanges are:
+
+ F1 offers X and Y, F3 answers X and Z. (Only X can be used.)
+
+ F6 offers X and Y, but F7 offers X, Y, and a place-holder to block
+ use of type 92.
+
+ F8/F10 answers Y.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Worley Informational [Page 24]
+
+RFC 7088 Music on Hold February 2014
+
+
+ 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]
+
+
+
+
+
+
+
+
+Worley Informational [Page 25]
+
+RFC 7088 Music on Hold February 2014
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Worley Informational [Page 26]
+
+RFC 7088 Music on Hold February 2014
+
+
+ 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]
+
+
+
+
+
+
+
+
+
+
+Worley Informational [Page 27]
+
+RFC 7088 Music on Hold February 2014
+
+
+ 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 liveness 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
+ answer that 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 (multiple "m=" lines) in any of
+ the SDPs involved in the dialogs. As the SDPs are manipulated, each
+ media description (each starting with an "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
+
+
+
+Worley Informational [Page 28]
+
+RFC 7088 Music on Hold February 2014
+
+
+ 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 the "m=" line
+ to zero [RFC3264]. This ensures that the answer SDP will also have a
+ rejection for that "m=" line.
+
+ If the executing UA wishes to provide its own on-hold media for a
+ particular "m=" line, it can do so by providing the answer
+ information for that "m=" line. The executing UA may decide to do
+ this when the offer SDP is received (by modifying the "m=" line to
+ rejected state when sending it to the music source) or upon receiving
+ the answer from the music source and discovering that the "m=" line
+ has been rejected.
+
+ The executing UA may not want to pass a rejected "m=" line from the
+ music source to the remote UA (when the remote UA provided a non-
+ rejected "m=" line) and may instead provide an answer with
+ directionality "inactive" (and specifying its own RTP/RTCP ports).
+
+3. Advantages
+
+ This technique for providing music on hold has advantages over other
+ methods now in 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 event package [RFC4235] does not change
+ during the call, as contrasted to the method in [RFC5359],
+ Section 2.3. This URI is usually displayed to the user as the
+ name 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).
+
+
+
+Worley Informational [Page 29]
+
+RFC 7088 Music on Hold February 2014
+
+
+ 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
+ advertised media-listening address/port). Thus, 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 of SDP; in
+ 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 [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 initial
+ draft version of this document, as well as with [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 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 as follows. Suppose that the UAs in Section 2.3 each
+ support the following media formats:
+
+ Alice supports formats X and Y.
+
+ Bob supports formats X and Z.
+
+ Music Source supports formats Y and Z.
+
+ In this case, the SDP exchanges are:
+
+ 1. Alice calls Bob:
+ Alice offers X and Y (message F1).
+ Bob answers X (F3).
+
+ 2. Bob puts Alice on hold:
+ Alice (via Bob) offers X and Y (F6 and F7).
+ Music Source (via Bob) answers Y (F8 and F10).
+
+ 3. Bob takes Alice off hold:
+ Bob offers X and Z (F11).
+ Alice answers X (F12).
+
+
+
+
+Worley Informational [Page 30]
+
+RFC 7088 Music on Hold February 2014
+
+
+ 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 new dialog. It also involves a number of race
+ conditions that must be handled correctly. If the UA is a back-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 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. Network Security
+
+ 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 information
+ that 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.
+
+
+
+
+
+
+
+Worley Informational [Page 31]
+
+RFC 7088 Music on Hold February 2014
+
+
+ These requirements may be satisfied by selecting an MOH server that
+ is in the same administrative and network domain as the executing UA
+ and whose path to all external addresses is the same as the UA's path
+ to those addresses.
+
+5.2. SIP (Signaling) Security
+
+ The executing UA and the MOH server will usually be within the same
+ administrative domain, 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
+
+ The RTP for the MOH media will pass directly between the MOH server
+ and the remote 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 is 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 not 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. Media Filtering
+
+ 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
+
+
+
+Worley Informational [Page 32]
+
+RFC 7088 Music on Hold February 2014
+
+
+ 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. Acknowledgments
+
+ The original version of this proposal was derived from Section 2.3 of
+ [SIP-SERV-EX] and the similar implementation of MOH in the snom UA.
+ Significant improvements to the sequence of operations, allowing
+ improvements to the SDP handling, were suggested by Venkatesh
+ [VENKATESH].
+
+ John 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.
+
+ Paul 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 Attila
+ Sipos [SIPOS].
+
+ The need to discuss dialog/session timers (Section 2.9) was pointed
+ out by Rifaat Shekh-Yusef [SHEKH-YUSEF].
+
+ Robert Sparks clarified the purpose of the "Best Current Practice"
+ status, leading to revising the intended status of this document to
+ "Informational".
+
+
+
+
+
+Worley Informational [Page 33]
+
+RFC 7088 Music on Hold February 2014
+
+
+ In his SecDir 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.
+
+7. References
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [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. 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.
+
+7.2. Informative References
+
+ [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.
+
+
+
+
+
+Worley Informational [Page 34]
+
+RFC 7088 Music on Hold February 2014
+
+
+ [RFC6337] Okumura, S., Sawada, T., and P. Kyzivat, "Session
+ Initiation Protocol (SIP) Usage of the Offer/Answer
+ Model", RFC 6337, August 2011.
+
+ [ELWELL] Elwell, J., "Subject: [Sipping] RE: I-D Action:draft-
+ worley-service-example-00.txt", message to the IETF
+ Sipping mailing list, November 2007,
+ <http://www1.ietf.org/mail-
+ archive/web/sipping/current/msg14678.html>.
+
+ [KYZIVAT-1]
+ Kyzivat, P., "Subject: Re: [Sipping] I-D ACTION:draft-
+ ietf-sipping-service-examples-11.txt", message to the IETF
+ Sipping mailing list, October 2006, <http://www1.ietf.org/
+ mail-archive/web/sipping/current/msg12181.html>.
+
+ [KYZIVAT-2]
+ Kyzivat, P., "Subject: [Sip-implementors] draft-worley-
+ service-example-02", message to the sip-implementors
+ mailing list, September 2008,
+ <http://lists.cs.columbia.edu/pipermail/sip-implementors/
+ 2008-September/020394.html>.
+
+ [SHEKH-YUSEF]
+ Shekh-Yusef, R., "Subject: [sipcore] draft-worley-service-
+ example-03", message to the IETF Sipcore mailing list,
+ July 2009, <http://www.ietf.org/mail-archive/web/sipcore/
+ current/msg00580.html>.
+
+ [SIPOS] Sipos, A., "Subject: [Sip-implementors] draft-worley-
+ service-example-02", message to the sip-implementors
+ mailing list, March 2009, <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 mailing list, October 2006, <http://www1.ietf.org/
+ mail-archive/web/sipping/current/msg12180.html>.
+
+
+
+
+
+
+
+Worley Informational [Page 35]
+
+RFC 7088 Music on Hold February 2014
+
+
+Author's Address
+
+ Dale R. Worley
+ Ariadne Internet Services, Inc.
+ 738 Main St.
+ Waltham, MA 02451
+ US
+
+ Phone: +1 781 647 9199
+ EMail: worley@ariadne.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Worley Informational [Page 36]
+