[sipcore] Reviewers needed for new music-on-hold technique

"Worley, Dale R (Dale)" <dworley@avaya.com> Thu, 21 October 2010 19:59 UTC

Return-Path: <dworley@avaya.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 6C7C43A67DF for <sipcore@core3.amsl.com>; Thu, 21 Oct 2010 12:59:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.453
X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6Zed-7XC14Sa for <sipcore@core3.amsl.com>; Thu, 21 Oct 2010 12:58:59 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com []) by core3.amsl.com (Postfix) with ESMTP id 744623A686A for <sipcore@ietf.org>; Thu, 21 Oct 2010 12:58:58 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.58,219,1286164800"; d="scan'208";a="243938920"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([]) by co300216-co-outbound.net.avaya.com with ESMTP; 21 Oct 2010 16:00:16 -0400
X-IronPort-AV: E=Sophos;i="4.58,219,1286164800"; d="scan'208";a="525455065"
Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 21 Oct 2010 16:00:16 -0400
Received: from DC-US1MBEX4.global.avaya.com ([]) by DC-US1HCEX3.global.avaya.com ([]) with mapi; Thu, 21 Oct 2010 16:00:16 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "sipcore@ietf.org" <sipcore@ietf.org>
Date: Thu, 21 Oct 2010 16:00:15 -0400
Thread-Topic: Reviewers needed for new music-on-hold technique
Thread-Index: AQHLcVqTV/CZQEsmuUSbuxTZrQzVUg==
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B220228896D@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [sipcore] Reviewers needed for new music-on-hold technique
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Oct 2010 19:59:00 -0000

I've written draft-worley-service-example to describe a music-on-hold technique which has some advantages over the technique in RFC 5359.  (The two are mutually compatible, and both are compatible with almost all SIP UAs.)  I am advancing this as an AD-sponsored RFC.  I think I've fixed the last wrinkles and would like people to review the draft.

The -05 changes describe that (as in other third-party situations) it is not possible to handle codec numbers exactly correctly in all situations.  But following certain guidelines provides correct behavior in the vast majority of cases.

      Session Initiation Protocol Service Example -- 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
   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
   method of RFC 5359.