Session Initiation Protocol Service Example -- Music on Hold

Approval announcement
Draft of message to be sent after approval:

From: The IESG <>
To: IETF-Announce <>
Cc: RFC Editor <>
Subject: Document Action: 'Session Initiation Protocol Service Example -- Music on Hold' to Informational RFC (draft-worley-service-example-14.txt)

The IESG has approved the following document:
- 'Session Initiation Protocol Service Example -- Music on Hold'
  (draft-worley-service-example-14.txt) as Informational RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Richard Barnes.

A URL of this Internet Draft is:

Technical Summary:

*The "music on hold" feature is one of the most desired features of
telephone systems in the business environment.  "Music on hold" is
where, 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 effective and 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 which perform authentication than the
music-on-hold method described in section 2.3 of RFC 5359.*

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was
there controversy about particular points or were there decisions where the
consensus was particularly rough?

*This document is not the product of a working group. However, the document
has been discussed in the SIPPING and SIPCORE working group and got
feedback from the sip-implementors mailing list.*

Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification? Are
there any reviewers that merit special mention as having done a thorough
review, e.g., one that resulted in important changes or a conclusion that
the document had no substantive issues? If there was a MIB Doctor, Media
Type or other expert review, what was its course (briefly)? In the case of
a Media Type review, on what date was the request posted?

*It seems that there are many implementations out there for this mechanism:*

*Dale believes that Polycom SIP phones use this technique.*

* *

*Dale also got the following response from John Riordan at Junction
Networks related to their OnSIP hosted PBX:*

John Riordan at Junction Networks
*> reports:**

>> We've been running production MOH services on this for years now and
>> user agents produced by significant companies have supported it for
>> a while.


>> Good to hear. And I would be happy to be used as a reference.***

*John Riordan (of Junction Networks) reports that Cisco/Linksys SPA**
phones use this system, but apparently Cisco does not document it:

    From: John Riordan <****>**
    Subject: Re: Mail regarding draft-worley-service-example
    Date: Fri, 19 Apr 2013 10:58:55 -0400

    Cisco's "SPA" models implement it, however we are not aware of any
    Cisco documentation that references 'worley'. These models were
    originally sold under the 'Linksys' brand. There are instructions on
    configuring MoH in manuals - for example page 96 of
    - but there is no reference to worley that we've seen. We discovered
    support during our phone evaluation process - we have a little testing
    lab that reviews user agents from all over the place and follows a
    process similar to

*The phone certification process for SIPxecs PBX**
lists draft-worley-service-example-09 as the relevant standard for
music-on-hold.  (-09 is technically the same as -12.)*


*Document Shepherd: Rifaat Shekh-Yusef*

*Responsible Area Director: Richard Barnes*