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

Paul Kyzivat <pkyzivat@cisco.com> Wed, 27 October 2010 20:47 UTC

Return-Path: <pkyzivat@cisco.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 101003A63D2 for <sipcore@core3.amsl.com>; Wed, 27 Oct 2010 13:47:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.474
X-Spam-Level:
X-Spam-Status: No, score=-110.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCHKfssmKp5Z for <sipcore@core3.amsl.com>; Wed, 27 Oct 2010 13:47:26 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0FF2F3A63CB for <sipcore@ietf.org>; Wed, 27 Oct 2010 13:47:26 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAK0syEyrRN+J/2dsb2JhbAChRHGkQ5wyhUgEilODCA
X-IronPort-AV: E=Sophos;i="4.58,247,1286150400"; d="scan'208";a="610631188"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2010 20:49:16 +0000
Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o9RKnGX2015697; Wed, 27 Oct 2010 20:49:16 GMT
Message-ID: <4CC8904B.2080307@cisco.com>
Date: Wed, 27 Oct 2010 16:49:15 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: "Worley, Dale R (Dale)" <dworley@avaya.com>
References: <CD5674C3CD99574EBA7432465FC13C1B2202288994@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B2202288994@DC-US1MBEX4.global.avaya.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [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: Wed, 27 Oct 2010 20:47:27 -0000

I'm quite sure the constraint isn't there for the pain or benefit of an 
MOH server. Its a constraint that applies on a single session between a 
single pair of UAs that are using reINVITE to renegotiate the codec they 
are using. In that context it makes sense, for one o/a cycle.

What doesn't make sense is extending it for the life of the session.

	Thanks,
	Paul

On 10/27/2010 2:15 PM, Worley, Dale R (Dale) wrote:
> [second attempt to send]
>
> ________________________________________
> From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@cisco.com]
>
> [as individual]
>
> 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.
> _______________________________________________
>
> You are quite correct about this.  But re-reading my draft, I notice that the problem is remarkably theoretical:  In this case, the UA that does not execute the hold generates an offer to which the MOH server generates an answer.  The MOH server sends RTP using the codecs specified in the UA's offer.  Thus, there can be no confusion when the UA decodes the RTP, as the RTP is being sent based on what the UA specified.  The problem is the requirement that the codecs that the MOH server lists in its answer must meet the non-reuse requirement (despite that no media will be sent to the MOH server).  In practice I am sure that the hold-executing phone does not need to worry about this problem at all.
>
> Dale
>