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

Paul Kyzivat <> Fri, 22 October 2010 00:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 05B4D3A67D7 for <>; Thu, 21 Oct 2010 17:20:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.497
X-Spam-Status: No, score=-110.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id liWB+YShKFbG for <>; Thu, 21 Oct 2010 17:20:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0463D3A67D0 for <>; Thu, 21 Oct 2010 17:20:14 -0700 (PDT)
Authentication-Results:; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAEN2wExAZnwN/2dsb2JhbAChXnGjApwyhUoEik2DBA
X-IronPort-AV: E=Sophos;i="4.58,220,1286150400"; d="scan'208";a="173588347"
Received: from ([]) by with ESMTP; 22 Oct 2010 00:21:51 +0000
Received: from [] ( []) by (8.13.8/8.14.3) with ESMTP id o9M0LpR6002311; Fri, 22 Oct 2010 00:21:51 GMT
Message-ID: <>
Date: Thu, 21 Oct 2010 20:21:51 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: Dale Worley <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [sipcore] Reviewers needed for new music-on-hold technique
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Oct 2010 00:20:16 -0000

[as individual]


This is quite nice. You have covered a lot of obscure cases.

Obviously the constraint about reusing payload numbers is problematic. I 
think we should consider the possibility of relaxing it, though I don't 
know if we can get away with that after the fact or not.

ISTM that the fundamental reason for such a constraint is transient. 
When you have an existing session and then modify it, the change in the 
signaling and the change in the media packets do not happen 
synchronously. So when you make the offer you must be ready to receive 
media based on the new offer while you are still receiving media on the 
old offer. Similarly for sending.

If the codec associated with a payload type is changed then when a 
packet arrives it will be impossible to know which codec applies for it.

So, for a particular o/a exchange I think this rule must hold. But once 
that is in effect, and we know all media according to the old o/a has 
cleared the system, those old payload numbers no longer need be 
reserved. In reasonable cases, things should stabilize from one o/a 
before another o/a begins. (Though we can probably contrive a case where 
this is not so.)

Would such a change be sufficient to simplify the problems you have been 
dealing with in this draft?


On 10/21/2010 4:00 PM, Worley, Dale R (Dale) wrote:
> 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
>                      draft-worley-service-example-05
>     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.
> Thanks,
> Dale
> _______________________________________________
> sipcore mailing list