Re: [MMUSIC] Offer/Answer PT Questions

Paul Kyzivat <pkyzivat@alum.mit.edu> Sat, 20 February 2016 17:16 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 000D71A9124 for <mmusic@ietfa.amsl.com>; Sat, 20 Feb 2016 09:16:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 igFY1Vvpauyz for <mmusic@ietfa.amsl.com>; Sat, 20 Feb 2016 09:16:58 -0800 (PST)
Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8910F1A8747 for <mmusic@ietf.org>; Sat, 20 Feb 2016 09:16:56 -0800 (PST)
Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-04v.sys.comcast.net with comcast id LhGn1s00327uzMh01hGv9Q; Sat, 20 Feb 2016 17:16:55 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-02v.sys.comcast.net with comcast id LhGv1s00H3KdFy101hGvjV; Sat, 20 Feb 2016 17:16:55 +0000
To: mmusic@ietf.org
References: <E42CCDDA6722744CB241677169E8365615E419C0@MISOUT7MSGUSRDB.ITServices.sbc.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56C89F86.7020401@alum.mit.edu>
Date: Sat, 20 Feb 2016 12:16:54 -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: <E42CCDDA6722744CB241677169E8365615E419C0@MISOUT7MSGUSRDB.ITServices.sbc.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1455988615; bh=/xWzx2Dtwp4HFWDjWQMPZb1eCLKW99K38+9mYB/YHKI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=UtkBdWA5jYQGvDYZCCJGbqEEQMTks2Ch2eWPypzLb4rpTBnn+TW6cpmYdyXwwNUDl Gtx6pLm1USXLoWUBwzFQa43LkUzCfKqwe36uF/6IYeXUs99kBaKxm0/VJ0lFKdH0KT VSV5rdFQ1L117PqRQh3vTsLsY4ChwAEpNU3gzpooixQMywAgLQl6gYz5nLrgeR98ik QjYEv0onDC4JlxZ4TnwohZLYniSAvXl5I5Z/KawIGp+sveMabAguKi1379fv7iavOw HWiPA2v20WfOLsBg27KpXw/B6azauaCcVmwb735+sYilnEctkDYcdyXWo7aWGubH6t YWI/RdrZDQE9A==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/O-fbYmV2rMYfORaMkzV-CEZK_XY>
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: Sat, 20 Feb 2016 17:17:00 -0000

On 2/19/16 11:30 PM, DOLLY, MARTIN C wrote:
> Hello O/A lovers,
>
> Section 8.3.2 of RFC 3264 says the following:
>
>     “However, in the case of RTP, the mapping from a particular dynamic
> payload type
>
>     number to a particular codec within that media stream MUST NOT change
>
>     for the duration of a session.  For example, if A generates an offer
>
>     with G.711 assigned to dynamic payload type number 46, payload type
>
>     number 46 MUST refer to G.711 from that point forward in any offers
>
>     or answers for that media stream within the session.”

As you know, this area is not well defined.

> Now, assume the following case:
>
> 1.Alice sends an Offer, with the following PT values:
>
> PT 100: AMR-WB(mode-set=2)
>
> PT 111: AMR-WB(mode-set=2, OA)
>
> PT 0: PCMU
>
> 2.Bob sends the associated Answer:
>
> PT 100: AMR-WB (mode-set=2)
>
> PT 0: PCMU

At this point, I think there is an open question of whether the "must 
not change" even applies for a PT that was offered but not accepted in 
the answer.

One might argue that the real point of the requirement is that it can't 
be reused once there might be packets in flight using it. But that isn't 
true in this case. So IMO it is uncharted territory.

> 3.Later Bob sends the following subsequent Offer:
>
> PT 111: AMR(mode-set=0,2,5,7)

You mean the new offer no longer mentions 0 and 100, only 111 with this 
new mapping? (Though I don't think the answer to that affects your 
questions.)

> QUESTION 1: Is it allowed for Bob to offer PT 111 for AMR in the
> subsequent Offer, as Alice used PT 111 for AMR-WG in the initial Offer?
> In other words, does the
> pt-value-must-only-refer-to-a-specific-payload-for-the-stream-within-the-session
> text in section 8.3.2 apply to user A only, or to **all** users within
> the session?

While it is *recommended* that the answer use the same PT as the offer 
for a given codec configuration, that isn't *required*. The answer may 
accept the codec from the offer using a different PT.

So, in the first answer Bob *could* have accepted the offer for 
AMR-WB(mode-set=2, OA) using some other PT (say 112). If so, when Bob 
subsequently sent an offer reusing the same codecs it would have used 
100, 112, and 0. (111 would not have been used.) In that case it seems 
like Bob would be free to use 111 for something else. Alice, in her 
answer, would be free to map it to a different PT in order to avoid a 
clash with 111 on her end.

All of that seems equally applicable in your example, where Bob never 
accepted AMR-WB(mode-set=2, OA).

> QUESTION 2:   Assuming the text applies to all users, is it allowed to
> re-use a PT value for the same codec, but for a different CODEC
> CONFIGURATION? The text only talks about codec.

I think use of "codec" was just sloppy, and that it always meant codec 
configuration.

> Now, I agree that the easiest way to avoid trouble is simply to make
> sure PT values aren’t re-used by any party. But, the text still needs to
> be clear, because this is causing problems in real deployments.

Agree.

The spec is far from clear on this subject. A starting point for 
clarifying it to ascertain as best we can the original intent. But then 
we also need to try to understand common practice. Where this has been 
unclear there may well be conflicting interpretations in the wild. 
*Somebody* is likely to be negatively affected by whatever decision we 
come to.

	Thanks,
	Paul

P.S. Martin: maybe you have found a subject where we can agree.