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", that party's telephone provides an audio stream (often music) to be heard by the other party. Architectural features of SIP make it difficult to implement music-on-hold in a way that is fully compliant with the standards. The implementation of music-on-hold described in this document is fully standards-compliant, but is simpler than the methods previously documented.

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, when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party. Architectural features of SIP make it difficult to implement music-on-hold in a way that is fully compliant with the standards. The purpose of this document is to describe a method that is reasonably simple and fully standards-compliant.

The essence of the technique is that when the executing UA performs a re-INVITE of the remote UA to establish the hold state, it extracts the answer SDP, 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 user instructs the user's UA to put the conversation on-hold. The user's UA sends a re-INVITE to the remote UA with SDP that declines to receive media. This establishes the on-hold state (in that direction). The remote UA responds 200 to the re-INVITE, and includes SDP giving its own listening address/port, which should indicate that it will not send media. The user's UA composes and sends a new INVITE to the configured external music-on-hold (MOH) source. The SDP in this request is largely copied from the SDP returned by the remote UA in the previous step, particularly regarding the provided listening address/port and codec numbers. The MOH source responds 200 to the INVITE. After this point, the MOH source generates RTP containing the music-on-hold media, and sends it directly to the listening address/port of the remote UA. The UA maintains two dialogs (one to the remote UA, one to the MOH source), but does not see or handle the MOH RTP.

The user instructs the user's UA to take the conversation off-hold. The user's UA sends a re-INVITE to the remote UA with SDP that requests to receive media. When the remote UA responds 200 to the re-INVITE, the user's UA sends BYE on dialog to the MOH source. 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: | | | |INVITE (hold) F5| | |<---------------| | | 200 OK F6 | | |--------------->| | | ACK F7 | | |<---------------| | | no RTP | | | | | Bob's UA initiates music-on-hold: | | | | | INVITE F8 | | |------------->| | | 200 OK F9 | | |<-------------| | | ACK F10 | | |------------->| | Music-on-hold RTP | |<==============================| | | | The music on hold is active. Bob takes Alice off hold: | | | | INVITE F11 | | |<---------------| | | 200 OK F12 | | |--------------->| | | ACK F13 | | |<---------------| | | | BYE F14 | | |------------->| | | 200 F15 | | |<-------------| | RTP | | |<==============>| | | | | The normal media session between Alice and Bob is resumed. ]]>

Message Details 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. */ F5 INVITE Bob -> Alice INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bK874bk To: Alice ;tag=1234567 From: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 712 INVITE Contact: ;+sip.rendering="no" Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Type: application/sdp Content-Length: [omitted] v=0 o=bob 2890844527 2890844528 IN IP4 biloxi.example.com s= c=IN IP4 biloxi.example.com t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendonly F6 200 OK Alice -> Bob SIP/2.0 200 OK Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bK874bk ;received=192.0.2.105 To: Alice ;tag=1234567 From: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 712 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Content-Type: application/sdp Content-Length: [omitted] v=0 o=alice 2890844526 2890844527 IN IP4 atlanta.example.com s= c=IN IP4 atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=recvonly F7 ACK Bob -> Alice ACK sips:a8342043f@atlanta.example.com;gr SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bKq874b To: Alice ;tag=1234567 From: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 712 ACK Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Length: 0 /* Bob's UA initiates music-on-hold. */ F8 INVITE Bob -> Music Server INVITE sips:music@server.example.com SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bKnashds9 Max-Forwards: 70 From: Bob ;tag=02134 To: Music Server Call-ID: 4802029847@biloxi.example.com CSeq: 1 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Content-Type: application/sdp Content-Length: [omitted] v=0 o=bob 2890844534 2890844534 IN IP4 atlanta.example.com s= c=IN IP4 atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=recvonly F9 200 OK Music Server -> Bob SIP/2.0 200 OK Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bKnashds9 ;received=192.0.2.105 From: Bob ;tag=02134 To: Music Server ;tag=56323 Call-ID: 4802029847@biloxi.example.com Contact: CSeq: 1 INVITE Content-Length: [omitted] v=0 o=MusicServer 2890844576 2890844576 IN IP4 server.example.com s= c=IN IP4 server.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendonly F10 ACK Bob -> Music Server ACK sips:music@server.example.com SIP/2.0 Via: SIP/2.0/TLS server.example.com:5061 ;branch=z9hG4bK74bT6 From: Bob ;tag=02134 To: Music Server ;tag=56323 Max-Forwards: 70 Call-ID: 4802029847@biloxi.example.com CSeq: 1 ACK Content-Length: 0 /* Bob picks up the call by sending a re-INVITE to Alice. */ F11 INVITE Bob -> Alice INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bK874bk To: Alice ;tag=1234567 From: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 713 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Type: application/sdp Content-Length: [omitted] v=0 o=bob 2890844527 2890844529 IN IP4 biloxi.example.com s= c=IN IP4 biloxi.example.com t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F12 200 OK Alice -> Bob SIP/2.0 200 OK Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bK874bk ;received=192.0.2.105 To: Alice ;tag=1234567 From: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 713 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Content-Type: application/sdp Content-Length: [omitted] v=0 o=alice 2890844526 2890844528 IN IP4 atlanta.example.com s= c=IN IP4 atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F13 ACK Bob -> Alice ACK sips:a8342043f@atlanta.example.com;gr SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bKq874b To: Alice ;tag=1234567 From: Bob ;tag=23431 Call-ID: 12345600@atlanta.example.com CSeq: 713 ACK Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Length: 0 F14 BYE Bob -> Music Server INVITE sips:music@server.example.com SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bK74rf Max-Forwards: 70 From: Bob ;tag=02134 To: Music Server ;tag=56323 Call-ID: 4802029847@biloxi.example.com CSeq: 2 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Content-Length: [omitted] F15 200 OK Music Server -> Alice SIP/2.0 200 OK Via: SIP/2.0/TLS atlanta.example.com:5061 ;branch=z9hG4bK74rf ;received=192.0.2.103 From: Bob ;tag=02134 To: Music Server ;tag=56323 Call-ID: 4802029847@biloxi.example.com CSeq: 2 BYE Content-Length: 0 /* Normal media session between Alice and Bob is resumed */ ]]>

A disadvantage of the previous message flow is that the RTP is sent to the remote UA from an address that is different from that which is given in the offer SDP of the re-INVITE. This can trigger SPIT-prevention behavior in some UA's.[] This section shows an alternative example message flow which avoids this problem. Again, this is just one possible message flow that illustrates this technique; numerous variations on these operations are allowed by the applicable standards. This technique involves interleaving the SDP offer/answer sequences of the two dialogs (original call and MOH): The executing UA sends the re-INVITE without SDP, forcing the remote UA to provide an SDP offer in the 200 response. The executing UA sends this offer as the SDP of the INVITE that it sends to the music-on-hold server. (The offer is modified to have a suitable o= line, and the media directionality is set to "recvonly", the reverse of "on-hold".) The music-on-hold server provides an SDP answer, which (we assume) includes its media source address as its listening address. The executing UA sends this SDP answer as its SDP answer in the ACK for the re-INVITE. (The answer is modified to have a suitable o= line.)

| | | 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 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 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Length: 0 F14 BYE Bob -> Music Server INVITE sips:music@server.example.com SIP/2.0 Via: SIP/2.0/TLS biloxi.example.com:5061 ;branch=z9hG4bK74rf Max-Forwards: 70 From: Bob ;tag=02134 To: Music Server ;tag=56323 Call-ID: 4802029847@biloxi.example.com CSeq: 2 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces, gruu Content-Length: [omitted] F15 200 OK Music Server -> Alice SIP/2.0 200 OK Via: SIP/2.0/TLS atlanta.example.com:5061 ;branch=z9hG4bK74rf ;received=192.0.2.103 From: Bob ;tag=02134 To: Music Server ;tag=56323 Call-ID: 4802029847@biloxi.example.com CSeq: 2 BYE Content-Length: 0 /* Normal media session between Alice and Bob is resumed */ ]]>

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 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 technique does not require complex manipulation of SDP, and particularly does not require a SIP agent to modify received SDP to be acceptable to be sent within an already established sequence of SDP (which can require a complex accounting of the m= lines).

SDP, by its organization, specifies what address and port a UA will use to listen for media, but implicitly allows media to be sent to that address and port from any address and port. Some UAs, in order to avoid SPIT, will refuse to render media that are sent from an address which is not the listening address for the remote UA. That policy will also block music-on-hold that is provided using this technique. This problem can be circumvented in at least three ways: The first method is to disable the media-address restriction. Since this brings the UA's behavior into alignment with the common SIP model, it is probably the most reliable for overall interoperability. The second method is for the holding UA to obtain knowledge of the media sending address of the music-on-hold server by some means, and substitute that address for its own in the SDP in the re-INVITE that places the dialog on-hold. This technique requires that the holding UA can obtain this sending address, and that the technique for specifying the "on-hold" condition in the re-INVITE is not that of setting the listening address in the c= line to 0.0.0.0. The third method is to use the more complex interleaved SDP offer/answer system illustrated in . This technique requires that the executing UA can coordinate the SDP offer/answer mechanism between two dialogs.