Session Initiation Protocol Service Example -- Music on Hold
RFC 7088

 
Document Type RFC - Informational (February 2014; No errata)
Last updated 2014-02-10
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd Rifaat Shekh-Yusef
Shepherd write-up Show (last changed 2013-08-16)
IESG IESG state RFC 7088 (Informational)
Telechat date
Responsible AD Richard Barnes
IESG note Rifaat Shekh-Yusef (rifaat.sy@gmail.com) is the document shepherd.
Send notices to worley@ariadne.com, draft-worley-service-example@ietf.org, rifaat.sy@gmail.com
IANA IANA review state Version Changed - Review Needed
IANA action state No IC

Email authors IPR References Referenced by Nits Search lists

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
Show full document text