Re: [MMUSIC] Offer/Answer PT Questions

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 24 February 2016 17:55 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 817B11B3AD9 for <mmusic@ietfa.amsl.com>; Wed, 24 Feb 2016 09:55:47 -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 rZB0slGc-S8w for <mmusic@ietfa.amsl.com>; Wed, 24 Feb 2016 09:55:44 -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 A8B2B1B3B1A for <mmusic@ietf.org>; Wed, 24 Feb 2016 09:55:44 -0800 (PST)
Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-04v.sys.comcast.net with comcast id NHua1s0032GyhjZ01Hvjr5; Wed, 24 Feb 2016 17:55:43 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-09v.sys.comcast.net with comcast id NHvi1s00P3KdFy101Hvj89; Wed, 24 Feb 2016 17:55:43 +0000
To: Christer Holmberg <christer.holmberg@ericsson.com>, Colin Perkins <csp@csperkins.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> <7C0829C0-0BA2-482B-91FD-9A3ED97977E7@csperkins.org> <7594FB04B1934943A5C02806D1A2204B37E3F63F@ESESSMB209.ericsson.se>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56CDEE9D.2050708@alum.mit.edu>
Date: Wed, 24 Feb 2016 12:55:41 -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: <7594FB04B1934943A5C02806D1A2204B37E3F63F@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456336543; bh=6CHn7Wsbg9o2qFw7cwpIW7tP2bqFwqzLGd72an7Kgy4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=gEnZ6ib8S+EUuRCKhZSGbfYwT2cXR2SHzkROa6g0I07WFUOVodd7lTtsg0m6OIITp WtZsKFgtaDJTI7fycjz0qLmIFzUkzAKtWZ4e0e+unZLYShZ08Uf8KmSK5DBSfFHsbL eAn0UUI5QTtQFu2xrgq4ESsLnqzoN3c2REwIusDj+6++Vp5PR204I/SaBHf2/ey2w5 DXUTPOZasvA3pylEkT8WsUhj3zDp+MKjxJPhjuFwYPlb5RgN3rhNu0NSvZTq9jC9JB TM8RaBdXX9/VGqseAX0TAihJCzKB7q/CYD+vIg7E2wh9rZfRKzunB0BTBBHA6kSkhl bYjWB/sqFIutQ==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/j2GuzwrKyL7D2UU2-Cot3nkjUPc>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
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: Wed, 24 Feb 2016 17:55:48 -0000

Christer,

See inline.

On 2/24/16 6:08 AM, Christer Holmberg wrote:
> Hi Colin,
>
>>>>> No objection in principle, but it’s not as simple as “a few network RTTs”:
>>>>>
>>>>> No ambiguity in decoding means that the packets need to have been
>>>>> played out, so the codec state for that PT can be discarded. Some
>>>>> systems can have large (multi-second) playout buffers.
>>>>>
>>>>> Any packets referring to the old PT also need to be gone. Formats
>>>>> like RFC 6354 allow large offsets between streams, referenced by PT
>>>>> (the example in Section 5 has a 5.1 second offset).
>>>>
>>>> Thanks for the insight. It helps to ground the discussion.
>>>>
>>>> I'm also interested in hearing if there might be *other* reasons behind the rules as they are written.
>>>>
>>>> The advantage of the current rule is that it is easy to explain, and
>>>> is sufficient to deal with the problem you describe above.
>>>> Unfortunately it is also difficult/impossible to comply with in some cases. If we are to replace it, we need to find something else to replace it with.
>>>
>>> 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.
>>
>> RFC 3551 (the RTP/AVP profile), section 3, top of page 7, says:
>>
>>    mechanisms for defining dynamic payload type bindings have been
>>    specified in the Session Description Protocol (SDP) and in other
>>    protocols such as ITU-T Recommendation H.323/H.245.  These mechanisms
>>    associate the registered name of the encoding/payload format, along
>>    with any additional required parameters, such as the RTP timestamp
>>    clock rate and number of channels, with a payload type number.  This
>>    association is effective only for the duration of the RTP session in
>>    which the dynamic payload type binding is made.  This association
>>    applies only to the RTP session for which it is made, thus the
>>    numbers can be re-used for different encodings in different sessions
>>    so the number space limitation is avoided.
>>
>>
>> I always interpreted that as RTP payload types being per RTP session, not per SSRC. That may, or may not, be consistent with the SDP specifications.
>
> Q1: Then my next question is: when is the BINDING created? Is a binding created once a user has indicated (in an offer or answer) a PT/codec mapping - no matter if the other endpoint will use the same codec to begin with, or PT value for that codec?

I agree this is an important question.

The way 3264 was written it seems to mostly imply that the O/A is 
*negotiating* two-way usage of codecs rather than *declaring* 
independent usage of codecs in each direction. That made sense for a 
long time when usage focused on single stream audio.

But it sometimes seems to waffle on that and subsequently, IIUC, has 
been interpreted to be more flexible than that. This has become much 
more important with multi-stream usage, such as webrtc and clue.

I have the impression that initially it was expected that the same PT 
would be used on both ends. Later that got clarified so that the 
answerer can use a different PT than the offerer for the same codec 
configuration. With that, I think it is necessary that the PT reuse rule 
be applied independently on each end.

In your questions below I'm assuming sendrecv applies to all the 
m-lines. (the other cases need to be analyzed separately.)

> Example #1:
> ----------------
>
> Alice offers:
>
> PT 100: (AMR-WB)
> PT 111: (VP8)
>
> Bob answers:
>
> PT 111: (VP8)
>
> Q2: Now, eventhough did not indicate support of AMR-WR, the BINDING between PT 100 and AMR-WR has still been created, and neither Alice or Bob is allowed to re-use PT 100 for anything else within the session?

As noted above, I think bindings must be managed independently for each 
end. PT 100 is locked in on Alice's end, because Bob is allowed to send 
to it even though he didn't mention it in the answer. Alice can't use it 
for some other codec because Bob might have packets in flight that could 
then be misunderstood by Alice.

But Alice is forbidden from sending PT 111 to Bob. So if Bob 
subsequently offers PT 111 with some other coded and Alice starts 
sending to it there can be no ambiguity about what is being received. So 
it seems ok to allow *that*.

> Example #2:
> ----------------
>
> Alice offers:
>
> PT 100: (AMR-WB)
>
> Bob answers:
>
> PT 111: (AMR-WB)
>
>
> Q3: Now, two bindings have been created: one binding between PT 100 and AMR-WB, and one binding between PT 111 and AMR-WB. After this, neither Alice or Bob is allowed to re-use PT 100 or PT 111 for anything else within the session?

As I noted above, I think it must be the case that the bindings are 
managed independently on each end.

> Q4: HOWEVER, even if Bob indicated PT 111 and AMR-WB, I assume Bob would still be allowed to indicate PT 100 and AMR-WB, as it does not conflict with the existing binding?

Yes. It is explicitly allowed (I forget where) to map the same codec 
config to more than one PT (on the same end). (It isn't clear to me 
*why* one would do that.)

	Thanks,
	Paul