Re: [MMUSIC] Offer/Answer PT Questions

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 23 February 2016 19:01 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8F81A885B for <mmusic@ietfa.amsl.com>; Tue, 23 Feb 2016 11:01:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.635
X-Spam-Level:
X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_21=0.6, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJGXVrQzAeRH for <mmusic@ietfa.amsl.com>; Tue, 23 Feb 2016 11:01:57 -0800 (PST)
Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 443181A1B6D for <mmusic@ietf.org>; Tue, 23 Feb 2016 11:01:57 -0800 (PST)
Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-05v.sys.comcast.net with comcast id Mv0F1s0052N9P4d01v1wvq; Tue, 23 Feb 2016 19:01:56 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-13v.sys.comcast.net with comcast id Mv1w1s0013KdFy101v1wqr; Tue, 23 Feb 2016 19:01:56 +0000
To: mmusic@ietf.org
References: <E42CCDDA6722744CB241677169E8365615E419C0@MISOUT7MSGUSRDB.ITServices.sbc.com> <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <CAD5OKxsDGhSA1WpzVVEvdd0CQdbnFn+ST+ZP_=aYVWBVdKKs4g@mail.gmail.com> <7A0EA65A-83B0-4596-89D8-2E59F5AEA70F@csperkins.org> <56CC7E68.4040103@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E3C787@ESESSMB209.ericsson.se> <CAD5OKxuV2Z_Ae18sGo5=pry4==jeBK22FtG_dKQfBh-1RjOdLQ@mail.gmail.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56CCACA3.4030007@alum.mit.edu>
Date: Tue, 23 Feb 2016 14:01:55 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <CAD5OKxuV2Z_Ae18sGo5=pry4==jeBK22FtG_dKQfBh-1RjOdLQ@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456254116; bh=LeJ3B0qCt2UEkiyFkPui81/Nvy787nuV2nfJO97IlcI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=gkjL1lgKS8V0+1bDQNloxmjsRg0YvGB5YXa52vNa7dw9tQGOSTCa4K4TSqOtZ07IB 1DXSOPyoTwfNRtD6fOwyMKnn5XQyjd+j/3zZT2NrbaFRVIU4U2soxow7qKD6qPCS8M mbuFW17okymh+R9/W9MTuDRia3N44uJu6dNFPOoTB6udGp5pWRDPakhG+XMfhhlAuY 2LSGk+T/gkGJCCAZ1dmWRhdkZ35aCwHoeZUtoVaGcHvrjLW2TkC4uEvR1OOosIADqM jxG7tJ2ZGRvQYgCrxP5bWzUV7HwlSjrZwNamXR2vIWtW5mh0RrSaXh7UpGb74w/p1X pwpIsVyjtyokA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/JNMlDejV_cM8jPaJZ6rweT1vEXg>
Subject: Re: [MMUSIC] Offer/Answer PT Questions
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Feb 2016 19:01:58 -0000

On 2/23/16 1:22 PM, Roman Shpount wrote:
> On Tue, Feb 23, 2016 at 1:04 PM, Christer Holmberg
> <christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com>>
> wrote:
>
>     The current rule may be easy to understand, but it's difficult to
>     understand - and that's what triggered this discussion :)
>
>     So, while we can discuss possible rules/guidelines on when a PT
>     value can be used, I still think we need to answer the first question:
>
>     - If Alice allocates PT=X for codec 1, is Bob allowed to allocate
>     PT=X for codec 2 within the same session? The current text is
>     unclear on that, and I think that is the first question we need to
>     sort out.
>
>     After that, we can discuss whether e.g. Alice at some point can
>     allocate PT=X for codec 3, and what the criteria for that is.
>
>
> As far as I can see there are 3 question/clarifications that are required:
>
> 1. PT is allocated per codec profile (codec and all associated
> parameters), not codec. For instance, if end point uses PT=100 for
> SILK/8000, it cannot reuse it for SILK/16000
>
> 2. Is PT blocked from each direction independently or both directions at
> the same time. For instance if A sent an offer with PT=100, but B never
> sent an offer or an answer with PT=100, can B sent an offer with PT=100?
>
> 3. PT reuse in sessions such as one triggered by 3pcc where it would be
> impossible to enforce PT from ever being reused.

Note that in general the 3pcc case has other issues besides PT reuse. It 
is only "simple" if we assume that everybody is using only a single 
audio session. If we get beyond that there is the matter of matching the 
number of m-lines and their media types.

So it may be that we should separate it from the others.

	Thanks,
	Paul