TOC 
SIPD.R. Worley
Internet-DraftBluesocket
Expires: May 10, 2008November 7, 2007

Session Initiation Protocol Service Example -- Music on Hold

draft-worley-service-example-00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 10, 2008.

Copyright Notice

Copyright © The IETF Trust (2007).

Abstract

The "music on hold" feature is one of the most desired features of telephone systems in the business environment. "Music on hold" is, when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party. Architectural features of SIP make it difficult to implement music-on-hold in a way that is fully compliant with the standards. The implementation of music-on-hold described in this document is fully standards-compliant, but is simpler than the methods previously documented.


Table of Contents

1.  Introduction
2.  Technique
    2.1.  Placing a Call on Hold and Providing an External Media Stream
    2.2.  Taking a Call off Hold and Terminating the External Media Stream
    2.3.  Example Message Flow
    2.4.  Alternative Example Message Flow
3.  Advantages
4.  Security Considerations
5.  References
    5.1.  Normative References
    5.2.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements



 TOC 

1. Introduction

Within SIP[1] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)-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.


 TOC 

2. Technique

The essence of the technique is that when the executing UA performs a re-INVITE of the remote UA to establish the hold state, it extracts the answer SDP[2] (Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with the Session Description Protocol (SDP),” June 2002.), 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.


 TOC 

2.1. Placing a Call on Hold and Providing an External Media Stream

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


 TOC 

2.2. Taking a Call off Hold and Terminating the External Media Stream

  1. The user instructs the user's UA to take the conversation off-hold.
  2. The user's UA sends a re-INVITE to the remote UA with SDP that requests to receive media.
  3. When the remote UA responds 200 to the re-INVITE, the user's UA sends BYE on dialog to the MOH source.
  4. After this point, the MOH source does not generate RTP and ordinary RTP flow is re-established in the original dialog.


 TOC 

2.3. Example Message Flow

This section shows a message flow which is an example of this technique. The scenario is: Alice establishes a call with Bob. Bob then places the call on hold, with music-on-hold provided from an external server. Bob then takes the call off hold.

Note that this is just one possible message flow that illustrates this technique; numerous variations on these operations are allowed by the applicable standards. 

Alice             Bob       Music Server

Alice establishes the call:

  |                |              |
  |    INVITE F1   |              |
  |--------------->|              |
  | 180 Ringing F2 |              |
  |<---------------|              |
  |    200 OK F3   |              |
  |<---------------|              |
  |     ACK F4     |              |
  |--------------->|              |
  |       RTP      |              |
  |<==============>|              |
  |                |              |

Bob places Alice on hold:

  |                |              |
  |INVITE (hold) F5|              |
  |<---------------|              |
  |    200 OK F6   |              |
  |--------------->|              |
  |     ACK F7     |              |
  |<---------------|              |
  |    no RTP      |              |
  |                |              |

Bob's UA initiates music-on-hold:

  |                |              |
  |                |   INVITE F8  |
  |                |------------->|
  |                |   200 OK F9  |
  |                |<-------------|
  |                |    ACK F10   |
  |                |------------->|
  |     Music-on-hold RTP         |
  |<==============================|
  |                |              |

The music on hold is active.

Bob takes Alice off hold:

  |                |              |
  |  INVITE F11    |              |
  |<---------------|              |
  |   200 OK F12   |              |
  |--------------->|              |
  |     ACK F13    |              |
  |<---------------|              |
  |                |    BYE F14   |
  |                |------------->|
  |                |    200 F15   |
  |                |<-------------|
  |       RTP      |              |
  |<==============>|              |
  |                |              |

The normal media session between Alice and Bob is resumed.

Message Details 

 /* Alice calls Bob. */

 F1 INVITE Alice -> Bob

 INVITE sips:bob@biloxi.example.com SIP/2.0
 Via: SIP/2.0/TLS atlanta.example.com:5061
  ;branch=z9hG4bK74bf9
 Max-Forwards: 70
 From: Alice <sips:alice@atlanta.example.com>;tag=1234567
 To: Bob <sips:bob@biloxi.example.com>
 Call-ID: 12345600@atlanta.example.com
 CSeq: 1 INVITE
 Contact: <sips:a8342043f@atlanta.example.com;gr>
 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
 Supported: replaces, gruu
 Content-Type: application/sdp
 Content-Length: [omitted]

 v=0
 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
 s=
 c=IN IP4 atlanta.example.com
 t=0 0
 m=audio 49170 RTP/AVP 0
 a=rtpmap:0 PCMU/8000


 F2 180 Ringing Bob -> Alice

 SIP/2.0 180 Ringing
 Via: SIP/2.0/TLS atlanta.example.com:5061
  ;branch=z9hG4bK74bf9
  ;received=192.0.2.103
 From: Alice <sips:alice@atlanta.example.com>;tag=1234567
 To: Bob <sips:bob@biloxi.example.com>;tag=23431
 Call-ID: 12345600@atlanta.example.com
 CSeq: 1 INVITE
 Contact: <sips:bob@biloxi.example.com>
 Content-Length: 0


 F3 200 OK Bob -> Alice

 SIP/2.0 200 OK
 Via: SIP/2.0/TLS atlanta.example.com:5061
  ;branch=z9hG4bK74bf9
  ;received=192.0.2.103
 From: Alice <sips:alice@atlanta.example.com>;tag=1234567
 To: Bob <sips:bob@biloxi.example.com>;tag=23431
 Call-ID: 12345600@atlanta.example.com
 CSeq: 1 INVITE
 Contact: <sips:bob@biloxi.example.com>
 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
 Supported: replaces
 Content-Type: application/sdp
 Content-Length: [omitted]

 v=0
 o=bob 2890844527 2890844527 IN IP4 biloxi.example.com
 s=
 c=IN IP4 biloxi.example.com
 t=0 0
 m=audio 3456 RTP/AVP 0
 a=rtpmap:0 PCMU/8000


 F4 ACK Alice -> Bob

 ACK sips:bob@biloxi.example.com SIP/2.0
 Via: SIP/2.0/TLS atlanta.example.com:5061
  ;branch=z9hG4bK74bfd
 Max-Forwards: 70
 From: Alice <sips:alice@atlanta.example.com>;tag=1234567
 To: Bob <sips:bob@biloxi.example.com>;tag=23431
 Call-ID: 12345600@atlanta.example.com
 CSeq: 1 ACK
 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
 Supported: replaces
 Content-Length: 0


 /* Bob places Alice on hold. */

 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-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 <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 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 <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
 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 <sips:bob@biloxi.example.com>;tag=02134
 To: Music Server <sips:music@server.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


 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 <sips:bob@biloxi.example.com>;tag=02134
 To: Music Server <sips:music@server.example.com>;tag=56323
 Call-ID: 4802029847@biloxi.example.com
 Contact: <sips:music@server.example.com>
 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 <sips:bob@biloxi.example.com>;tag=02134
 To: Music Server <sips:music@server.example.com>;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 <sips:alice@atlanta.example.com>;tag=1234567
 From: Bob <sips:bob@biloxi.example.com>;tag=23431
 Call-ID: 12345600@atlanta.example.com
 CSeq: 713 INVITE
 Contact: <sips:bob@biloxi.example.com>
 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
 Supported: replaces
 Content-Type: application/sdp
 Content-Length: [omitted]

 v=0
 o=bob 2890844527 2890844529 IN IP4 biloxi.example.com
 s=
 c=IN IP4 biloxi.example.com
 t=0 0
 m=audio 3456 RTP/AVP 0
 a=rtpmap:0 PCMU/8000


 F12 200 OK Alice -> Bob

 SIP/2.0 200 OK
 Via: SIP/2.0/TLS biloxi.example.com:5061
  ;branch=z9hG4bK874bk
  ;received=192.0.2.105
 To: Alice <sips:alice@atlanta.example.com>;tag=1234567
 From: Bob <sips:bob@biloxi.example.com>;tag=23431
 Call-ID: 12345600@atlanta.example.com
 CSeq: 713 INVITE
 Contact: <sips:a8342043f@atlanta.example.com;gr>
 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
 Supported: replaces, gruu
 Content-Type: application/sdp
 Content-Length: [omitted]

 v=0
 o=alice 2890844526 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 <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
 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 <sips:bob@biloxi.example.com>;tag=02134
 To: Music Server <sips:music@server.example.com>;tag=56323
 Call-ID: 4802029847@biloxi.example.com
 CSeq: 2 INVITE
 Contact: <sips:bob@biloxi.example.com>
 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 <sips:bob@biloxi.example.com>;tag=02134
 To: Music Server <sips:music@server.example.com>;tag=56323
 Call-ID: 4802029847@biloxi.example.com
 CSeq: 2 BYE
 Content-Length: 0


 /* Normal media session between Alice and Bob is resumed */

 TOC 

2.4. Alternative Example Message Flow

A disadvantage of the previous message flow is that the RTP is sent to the remote UA from an address that is different from that which is given in the offer SDP of the re-INVITE. This can trigger SPIT-prevention behavior in some UA's.[Section 4 (Security Considerations)] This section shows an alternative example message flow which avoids this problem.

Again, this is just one possible message flow that illustrates this technique; numerous variations on these operations are allowed by the applicable standards.

This technique involves interleaving the SDP offer/answer sequences of the two dialogs (original call and MOH):

  1. The executing UA sends the re-INVITE without SDP, forcing the remote UA to provide an SDP offer in the 200 response.
  2. The executing UA sends this offer as the SDP of the INVITE that it sends to the music-on-hold server. (The offer is modified to have a suitable o= line, and the media directionality is set to "recvonly", the reverse of "on-hold".)
  3. The music-on-hold server provides an SDP answer, which (we assume) includes its media source address as its listening address.
  4. The executing UA sends this SDP answer as its SDP answer in the ACK for the re-INVITE. (The answer is modified to have a suitable o= line.) 

Alice             Bob       Music Server

Alice establishes the call:

  |                |              |
  |    INVITE F1   |              |
  |--------------->|              |
  | 180 Ringing F2 |              |
  |<---------------|              |
  |    200 OK F3   |              |
  |<---------------|              |
  |     ACK F4     |              |
  |--------------->|              |
  |       RTP      |              |
  |<==============>|              |
  |                |              |

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 

 /* Alice calls Bob. */

 F1 INVITE Alice -> Bob

 INVITE sips:bob@biloxi.example.com SIP/2.0
 Via: SIP/2.0/TLS atlanta.example.com:5061
  ;branch=z9hG4bK74bf9
 Max-Forwards: 70
 From: Alice <sips:alice@atlanta.example.com>;tag=1234567
 To: Bob <sips:bob@biloxi.example.com>
 Call-ID: 12345600@atlanta.example.com
 CSeq: 1 INVITE
 Contact: <sips:a8342043f@atlanta.example.com;gr>
 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
 Supported: replaces, gruu
 Content-Type: application/sdp
 Content-Length: [omitted]

 v=0
 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
 s=
 c=IN IP4 atlanta.example.com
 t=0 0
 m=audio 49170 RTP/AVP 0
 a=rtpmap:0 PCMU/8000


 F2 180 Ringing Bob -> Alice

 SIP/2.0 180 Ringing
 Via: SIP/2.0/TLS atlanta.example.com:5061
  ;branch=z9hG4bK74bf9
  ;received=192.0.2.103
 From: Alice <sips:alice@atlanta.example.com>;tag=1234567
 To: Bob <sips:bob@biloxi.example.com>;tag=23431
 Call-ID: 12345600@atlanta.example.com
 CSeq: 1 INVITE
 Contact: <sips:bob@biloxi.example.com>
 Content-Length: 0


 F3 200 OK Bob -> Alice

 SIP/2.0 200 OK
 Via: SIP/2.0/TLS atlanta.example.com:5061
  ;branch=z9hG4bK74bf9
  ;received=192.0.2.103
 From: Alice <sips:alice@atlanta.example.com>;tag=1234567
 To: Bob <sips:bob@biloxi.example.com>;tag=23431
 Call-ID: 12345600@atlanta.example.com
 CSeq: 1 INVITE
 Contact: <sips:bob@biloxi.example.com>
 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
 Supported: replaces
 Content-Type: application/sdp
 Content-Length: [omitted]

 v=0
 o=bob 2890844527 2890844527 IN IP4 biloxi.example.com
 s=
 c=IN IP4 biloxi.example.com
 t=0 0
 m=audio 3456 RTP/AVP 0
 a=rtpmap:0 PCMU/8000


 F4 ACK Alice -> Bob

 ACK sips:bob@biloxi.example.com SIP/2.0
 Via: SIP/2.0/TLS atlanta.example.com:5061
  ;branch=z9hG4bK74bfd
 Max-Forwards: 70
 From: Alice <sips:alice@atlanta.example.com>;tag=1234567
 To: Bob <sips:bob@biloxi.example.com>;tag=23431
 Call-ID: 12345600@atlanta.example.com
 CSeq: 1 ACK
 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
 Supported: replaces
 Content-Length: 0


 /* Bob places Alice on hold. */

 /* The re-INVITE contains no SDP, thus compelling Alice's UA
    to provide an offer. */

 F5 INVITE Bob -> Alice

 INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0
 Via: SIP/2.0/TLS biloxi.example.com:5061
  ;branch=z9hG4bK874bk
 To: Alice <sips:alice@atlanta.example.com>;tag=1234567
 From: Bob <sips:bob@biloxi.example.com>;tag=23431
 Call-ID: 12345600@atlanta.example.com
 CSeq: 712 INVITE
 Contact: <sips:bob@biloxi.example.com>;+sip.rendering="no"
 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
 Supported: replaces
 Content-Length: 0

 /* Alice's UA provides an SDP offer.
    Since it does not know that it is being put on hold,
    the offer is the same as the original offer and describes
    bidirectional media. */

 F6 200 OK Alice -> Bob

 SIP/2.0 200 OK
 Via: SIP/2.0/TLS biloxi.example.com:5061
  ;branch=z9hG4bK874bk
  ;received=192.0.2.105
 To: Alice <sips:alice@atlanta.example.com>;tag=1234567
 From: Bob <sips:bob@biloxi.example.com>;tag=23431
 Call-ID: 12345600@atlanta.example.com
 CSeq: 712 INVITE
 Contact: <sips:a8342043f@atlanta.example.com;gr>
 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
 Supported: replaces, gruu
 Content-Type: application/sdp
 Content-Length: [omitted]

 v=0
 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
 s=
 c=IN IP4 atlanta.example.com
 t=0 0
 m=audio 49170 RTP/AVP 0
 a=rtpmap:0 PCMU/8000
 a=active


 /* Bob's UA 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 <sips:bob@biloxi.example.com>;tag=02134
 To: Music Server <sips:music@server.example.com>
 Call-ID: 4802029847@biloxi.example.com
 CSeq: 1 INVITE
 Contact: <sips:bob@biloxi.example.com>
 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
 Supported: replaces, gruu
 Content-Type: application/sdp
 Content-Length: [omitted]

 v=0
 o=bob 2890844534 2890844534 IN IP4 atlanta.example.com
 s=
 c=IN IP4 atlanta.example.com
 t=0 0
 m=audio 49170 RTP/AVP 0
 a=rtpmap:0 PCMU/8000
 a=recvonly


 F8 200 OK Music 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 <sips:bob@biloxi.example.com>;tag=02134
 To: Music Server <sips:music@server.example.com>;tag=56323
 Call-ID: 4802029847@biloxi.example.com
 Contact: <sips:music@server.example.com>
 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 <sips:bob@biloxi.example.com>;tag=02134
 To: Music Server <sips:music@server.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 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 <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
 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 <sips:alice@atlanta.example.com>;tag=1234567
 From: Bob <sips:bob@biloxi.example.com>;tag=23431
 Call-ID: 12345600@atlanta.example.com
 CSeq: 713 INVITE
 Contact: <sips:bob@biloxi.example.com>
 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
 Supported: replaces
 Content-Type: application/sdp
 Content-Length: [omitted]

 v=0
 o=bob 2890844527 2890844529 IN IP4 biloxi.example.com
 s=
 c=IN IP4 biloxi.example.com
 t=0 0
 m=audio 3456 RTP/AVP 0
 a=rtpmap:0 PCMU/8000


 F12 200 OK Alice -> Bob

 SIP/2.0 200 OK
 Via: SIP/2.0/TLS biloxi.example.com:5061
  ;branch=z9hG4bK874bk
  ;received=192.0.2.105
 To: Alice <sips:alice@atlanta.example.com>;tag=1234567
 From: Bob <sips:bob@biloxi.example.com>;tag=23431
 Call-ID: 12345600@atlanta.example.com
 CSeq: 713 INVITE
 Contact: <sips:a8342043f@atlanta.example.com;gr>
 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
 Supported: replaces, gruu
 Content-Type: application/sdp
 Content-Length: [omitted]

 v=0
 o=alice 2890844526 2890844527 IN IP4 atlanta.example.com
 s=
 c=IN IP4 atlanta.example.com
 t=0 0
 m=audio 49170 RTP/AVP 0
 a=rtpmap:0 PCMU/8000


 F13 ACK Bob -> Alice

 ACK sips:a8342043f@atlanta.example.com;gr SIP/2.0
 Via: SIP/2.0/TLS biloxi.example.com:5061
  ;branch=z9hG4bKq874b
 To: Alice <sips:alice@atlanta.example.com>;tag=1234567
 From: Bob <sips:bob@biloxi.example.com>;tag=23431
 Call-ID: 12345600@atlanta.example.com
 CSeq: 713 ACK
 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 <sips:bob@biloxi.example.com>;tag=02134
 To: Music Server <sips:music@server.example.com>;tag=56323
 Call-ID: 4802029847@biloxi.example.com
 CSeq: 2 INVITE
 Contact: <sips:bob@biloxi.example.com>
 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 <sips:bob@biloxi.example.com>;tag=02134
 To: Music Server <sips:music@server.example.com>;tag=56323
 Call-ID: 4802029847@biloxi.example.com
 CSeq: 2 BYE
 Content-Length: 0


 /* Normal media session between Alice and Bob is resumed */

 TOC 

3. Advantages

This technique for providing music-on-hold has advantages over other methods now in use:

  1. The original dialog is not transferred to another UA, so the "remote endpoint URI" displayed by the remote endpoint does not change during the call.[3] (Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, “Session Initiation Protocol Service Examples,” July 2007.)
  2. The music-on-hold media is sent directly from the music-on-hold source to the remote UA, rather than being relayed through the holding UA.
  3. The technique does not require complex manipulation of SDP, and particularly does not require a SIP agent to modify received SDP to be acceptable to be sent within an already established sequence of SDP (which can require a complex accounting of the m= lines).


 TOC 

4. Security Considerations

SDP, by its organization, specifies what address and port a UA will use to listen for media, but implicitly allows media to be sent to that address and port from any address and port. Some UAs, in order to avoid SPIT, will refuse to render media that are sent from an address which is not the listening address for the remote UA. That policy will also block music-on-hold that is provided using this technique.

This problem can be circumvented in at least three ways:

The first method is to disable the media-address restriction. Since this brings the UA's behavior into alignment with the common SIP model, it is probably the most reliable for overall interoperability.

The second method is for the holding UA to obtain knowledge of the media sending address of the music-on-hold server by some means, and substitute that address for its own in the SDP in the re-INVITE that places the dialog on-hold. This technique requires that the holding UA can obtain this sending address, and that the technique for specifying the "on-hold" condition in the re-INVITE is not that of setting the listening address in the c= line to 0.0.0.0.

The third method is to use the more complex interleaved SDP offer/answer system illustrated in Section 2.4 (Alternative Example Message Flow). This technique requires that the executing UA can coordinate the SDP offer/answer mechanism between two dialogs.


 TOC 

5. References


 TOC 

5.1. Normative References

[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” RFC 3261, June 2002.
[2] Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with the Session Description Protocol (SDP),” RFC 3264, June 2002.

 TOC 

5.2. Informative References

[3] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, “Session Initiation Protocol Service Examples,” I-D draft-ietf-sipping-service-examples-13, July 2007.

 TOC 

Author's Address

  Dale R. Worley
  Bluesocket Inc.
  10 North Ave.
  Burlington, MA 01803
  US
Phone:  +1 781 229 0533 x173
Email:  dworley@pingtel.com
URI:  http://www.pingtel.com

 TOC 

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Disclaimer of Validity

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

Copyright © The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

Acknowledgment

Funding for the RFC Editor function is currently provided by the Internet Society.