Bluesocket Inc.

10 North Ave. Burlington MA 01803 US +1 781 229 0533 x173 dworley@pingtel.com http://www.pingtel.com

Transport SIP Music on hold The "music on hold" feature is one of the most desired features of telephone systems in the business environment. "Music on hold" is when one party to a call has the call "on hold", the other party receives a media stream (often either music or advertising). Architectural features of SIP make it difficult to implement music-on-hold in a way that is fully compliant with the standards. The implementation of music-on-hold described in this document is fully effective and standards-compliant, but is simpler than the methods previously documented.

Within SIP-based systems, it is desirable to be able to provide features that are similar to those provided by traditional telephony systems. A frequently requested feature is "music on hold": The music-on-hold feature is when one party to a call has the call "on hold", that party's telephone provides a media stream to be rendered to the other party. Architectural features of SIP make it difficult to implement music-on-hold in a way that is fully compliant with the standards. The purpose of this document is to describe a method that is reasonably simple yet fully effective and standards-compliant.

The essence of the technique is that when the user's UA (referred to hereafter as the "executing UA") establishes the hold state, it uses third party call control mechanisms to direct RTP from an audio source service to the held party. The executing UA establishes a dialog with the service to negotiate the audio stream, but does not act as a media relay; media flows from the service to the held party. In order to accomplish this within the offer/answer model, the executing UA sends a re-INVITE to the remote UA to establish the hold state, but in that INVITE it provides no SDP offer, thus compelling the remote UA to provide an SDP offer. The executing UA then uses that offer (modified as described in ) 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.

The executing user instructs the executing UA to put the dialog on-hold. 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 SHOULD include the '+sip.rendering="no"' field parameter so that the intent is clear and so that any dialog events indicate that it is putting the call on hold. (The sip.rendering feature parameter is not required by the MOH mechanics, but rather to facilitate reporting the on-hold status in dialog events.) 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 perhaps "inactive". But the remote UA may offer to send media. The executing UA uses this offer to construct the offer SDP of an initial INVITE that it sends to the configured music-on-hold (MOH) source. The SDP in this request is, with the exceptions below, copied from the SDP returned by the remote UA in the previous step, particularly regarding the provided listening address/port and payload type numbers. The changes to the SDP offer are: The o= line of the offer is modified according to . Any explicit or implicit media directionality of "sendrecv" is replaced with "recvonly", and any media directionality of "sendonly" is replaced with "inactive". The MOH 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. (Although this address/port should receive no RTP, the answer SDP will reach the remote UA, informing it of the address/port from which the MOH media will come, and presumably preventing it from ignoring the MOH media as SPIT. This requires the SDP answer to provide a real address/port in the c= line, even though the MOH server does not receive RTP.) The executing UA copies the MOH service SDP answer, modifying it as listed below, and sends it as its SDP answer in the ACK for the re-INVITE to the remote UA. The o= line of the answer is modified according to . Due to the sip.rendering feature parameter in the Contact of the re-INVITE and the media directionality in the SDP answer contained in the ACK, the on-hold state (at the executing end) of the dialog is established. (The sip.rendering feature parameter will be reported in the dialog events generated by both UAs, allowing any monitoring application to determine that the call is on hold.) 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.

The executing user instructs the executing UA to take the dialog off-hold. 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 INVITE removes the on-hold state (at the executing end) of the dialog. 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 to terminate the MOH media stream. After this point, the MOH source does not generate RTP and ordinary RTP flow is re-established in the original dialog.

This section shows a message flow which is an example of this technique. The scenario is: Alice establishes a call with Bob. Bob then places the call on hold, with music-on-hold provided from an external server. Bob then takes the call off hold. Note that this is just one possible message flow that illustrates this technique; numerous variations on these operations are allowed by the applicable standards.

| | | 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 | | |------------->| | | | Bob's UA provides SDP answer containing the address/port of the Music Server: | | | | ACK (hold) F10 | | | (SDP answer) | | |<---------------| | | no RTP | | | | | | Music-on-hold RTP | |<==============================| | | | The music on hold is active. Bob takes Alice off hold: | | | | INVITE F11 | | | (SDP offer) | | |<---------------| | | 200 OK F12 | | | (SDP answer) | | |--------------->| | | ACK F13 | | |<---------------| | | | BYE F14 | | |------------->| | | 200 F15 | | |<-------------| | RTP | | |<==============>| | | | | The normal media session between Alice and Bob is resumed. ]]>

Message Details Bob INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS atlanta.example.com:5061 ;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice ;tag=1234567 To: Bob Call-ID: 12345600@atlanta.example.com CSeq: 1 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Content-Type: application/sdp Content-Length: [omitted] v=0 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com s= c=IN IP4 atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F2 180 Ringing Bob -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/TLS atlanta.example.com:5061 ;branch=z9hG4bK74bf9 ;received=192.0.2.103 From: Alice ;tag=1234567 To: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 1 INVITE Contact: Content-Length: 0 F3 200 OK Bob -> Alice SIP/2.0 200 OK Via: SIP/2.0/TLS atlanta.example.com:5061 ;branch=z9hG4bK74bf9 ;received=192.0.2.103 From: Alice ;tag=1234567 To: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 1 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Type: application/sdp Content-Length: [omitted] v=0 o=bob 2890844527 2890844527 IN IP4 biloxi.example.com s= c=IN IP4 biloxi.example.com t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F4 ACK Alice -> Bob ACK sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS atlanta.example.com:5061 ;branch=z9hG4bK74bfd Max-Forwards: 70 From: Alice ;tag=1234567 To: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 1 ACK Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Length: 0 /* Bob places Alice on hold. */ /* The re-INVITE contains no SDP, thus compelling Alice's UA to provide an offer. */ F5 INVITE Bob -> Alice INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bK874bk To: Alice ;tag=1234567 From: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 712 INVITE Contact: ;+sip.rendering="no" Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Length: 0 /* Alice's UA provides an SDP offer. Since it does not know that it is being put on hold, the offer is the same as the original offer and describes bidirectional media. */ F6 200 OK Alice -> Bob SIP/2.0 200 OK Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bK874bk ;received=192.0.2.105 To: Alice ;tag=1234567 From: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 712 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Content-Type: application/sdp Content-Length: [omitted] v=0 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com s= c=IN IP4 atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=active /* Bob's UA initiates music-on-hold. */ /* This INVITE contains Alice's offer, but with the media direction set to "reverse hold", receive-only. */ F7 INVITE Bob -> Music Server INVITE sips:music@server.example.com SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bKnashds9 Max-Forwards: 70 From: Bob ;tag=02134 To: Music Server Call-ID: 4802029847@biloxi.example.com CSeq: 1 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Content-Type: application/sdp Content-Length: [omitted] v=0 o=bob 2890844534 2890844534 IN IP4 atlanta.example.com s= c=IN IP4 atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=recvonly F8 200 OK Music Server -> Bob SIP/2.0 200 OK Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bKnashds9 ;received=192.0.2.105 From: Bob ;tag=02134 To: Music Server ;tag=56323 Call-ID: 4802029847@biloxi.example.com Contact: CSeq: 1 INVITE Content-Length: [omitted] v=0 o=MusicServer 2890844576 2890844576 IN IP4 server.example.com s= c=IN IP4 server.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendonly F9 ACK Bob -> Music Server ACK sips:music@server.example.com SIP/2.0 Via: SIP/2.0/TLS server.example.com:5061 ;branch=z9hG4bK74bT6 From: Bob ;tag=02134 To: Music Server ;tag=56323 Max-Forwards: 70 Call-ID: 4802029847@biloxi.example.com CSeq: 1 ACK Content-Length: 0 /* Bob's UA now sends the ACK that completes the re-INVITE to Alice and completes the SDP offer/answer. The ACK contains the SDP received from the Music Server, and thus contains the address/port from which the Music Server will send media. */ F10 ACK Bob -> Alice ACK sips:a8342043f@atlanta.example.com;gr SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bKq874b To: Alice ;tag=1234567 From: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 712 ACK Contact: ;+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 server.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendonly /* Bob picks up the call by sending a re-INVITE to Alice. */ F11 INVITE Bob -> Alice INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bK874bk To: Alice ;tag=1234567 From: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 713 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Type: application/sdp Content-Length: [omitted] v=0 o=bob 2890844527 2890844529 IN IP4 biloxi.example.com s= c=IN IP4 biloxi.example.com t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F12 200 OK Alice -> Bob SIP/2.0 200 OK Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bK874bk ;received=192.0.2.105 To: Alice ;tag=1234567 From: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 713 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Content-Type: application/sdp Content-Length: [omitted] v=0 o=alice 2890844526 2890844527 IN IP4 atlanta.example.com s= c=IN IP4 atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F13 ACK Bob -> Alice ACK sips:a8342043f@atlanta.example.com;gr SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bKq874b To: Alice ;tag=1234567 From: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 713 ACK Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Length: 0 F14 BYE Bob -> Music Server BYE sips:music@server.example.com SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bK74rf Max-Forwards: 70 From: Bob ;tag=02134 To: Music Server ;tag=56323 Call-ID: 4802029847@biloxi.example.com CSeq: 2 BYE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Content-Length: [omitted] F15 200 OK Music Server -> Alice SIP/2.0 200 OK Via: SIP/2.0/TLS atlanta.example.com:5061 ;branch=z9hG4bK74rf ;received=192.0.2.103 From: Bob ;tag=02134 To: Music Server ;tag=56323 Call-ID: 4802029847@biloxi.example.com CSeq: 2 BYE Content-Length: 0 /* Normal media session between Alice and Bob is resumed */ ]]>

The rules regarding the use of o= lines in successive SDP offers/answers during a dialog are quit strict. In particular, successive SDPs sent by one UA in the dialog must have identical o= lines, other than that the version number field must be incremented by 1. The single exception is that if two or more successive SDPs are exactly the same, they may have the same version number. In order for the executing UA to conform to these rules, it must modify the o= lines in any SDP that it passes from one dialog to the other. In particular: The SDP in the initial INVITE to to the MOH server must have its o= line replaced with a newly constructed o= line that is valid within the dialog with the MOH server -- See for the details. Within any later SDP copied from the original dialog to the MOH dialog, the o= line must be replaced with a copy of the o= line that the executing UA used in the previous SDP that it sent in the MOH dialog, with the version number incremented by 1. Within any SDP copied from the MOH dialog to the original dialog, the o= line must be replaced with a copy of the o= line that the executing UA used in the previous SDP that it sent in the original dialog, with the version number incremented by 1. When the executing UA takes the call off-hold, the o= line of the SDP that it sends in the re-INVITE must have a version number one greater than in the o= line of the last SDP the executing UA copied from the MOH dialog.

This technique for providing music-on-hold has advantages over other methods now in use: 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 does not change during the call. The music-on-hold media is sent directly from the music-on-hold source to the remote UA, rather than being relayed through the holding UA. The remote UA sees, in the incoming SDP, the address/port that the MOH server will send MOH media from, thus allowing it to render the media, even if it is filtering incoming media based on originating address as a SPIT preventative. The technique requires relatively simple manipulation of SDP, and in particular: (1) does not require a SIP agent to modify unrelated SDP to be acceptable to be sent within an already established sequence of SDP (a problem with ), and (2) does not require converting an SDP answer into an SDP offer (which was a problem with the -00 version of this document, as well as with ).

Some UAs filter incoming media based on the address of origin in order to avoid SPIT. This technique ensures that any UA that should render MOH media will be informed of the source address via the SDP that it receives. This should allow such UAs to filter without interfering with MOH operation.

The original version of this proposal was derived from and the similar implementation of MOH in the Snom UA. Significant improvements to sequence of operations, allowing improvements to the SDP handling, were suggested by Venkatesh. John Elwell pointed out the need for the executing UA to pass through re-INVITEs/UPDATEs in order to allow ICE negotiation, which suggested to me the need for pass-through to handle the remote UA placing its end of the call on-hold. This version benefitted from Scott Lawrence's careful reading and comments.

Removed the original "Example Message Flow" and promoted the "Alternative Example Message Flow" to replace it because of a number of flaws that were described in the discussion of -00 on the SIPPING mailing list. Described the use of the sip.rendering feature parameter to indicate on-hold status. Added Acknowledgments section. Added separate section on the management of o= lines.