Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rfc5285-bis-11.txt

David Singer <singer@apple.com> Thu, 04 May 2017 21:01 UTC

Return-Path: <singer@apple.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A728A12946C for <avt@ietfa.amsl.com>; Thu, 4 May 2017 14:01:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 NfaZKxfvOv9X for <avt@ietfa.amsl.com>; Thu, 4 May 2017 14:01:51 -0700 (PDT)
Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB0A12702E for <avt@ietf.org>; Thu, 4 May 2017 14:01:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1493931697; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lNsFLI7pKTsxSmcl9Cn54ehbeLt9ocVlk9c2PTjkVWA=; b=QPaHBvGscXMitZNCMaE4FB9tXNM8c/L7L+Fww5/4u/jEho5SWgOR4BipB8gHAtT+ eMGUqLtezukFjcvVALihnueRXu5gXG7wb4RYRJrltv3Rh6ZkQVHbKHL+JGCjuqI6 U6T1/M7XOhkH32RCjYHpywimBJsNuywOMr0nQK+dJW0QFV2C39b50ppPrgM+Ur7Z W142F5Y4X3cV0u5UwdQttuJxoyjsBDjtmeFV7qHx1yNfd+O84MEnpIdkzA5freyz OVXDC/xEGTbmuX1FCydwKG5S/B5enbUUSAH6djYi5e/CY1LKxE2SW8LhDef2JD0U MoX8gfMFPtG1Pd3VqK0RxQ==;
Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 75.2F.08351.1B69B095; Thu, 4 May 2017 14:01:37 -0700 (PDT)
X-AuditID: 11973e16-efb529a00000209f-00-590b96b15a40
Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay4.apple.com (Apple SCV relay) with SMTP id AA.50.02523.1B69B095; Thu, 4 May 2017 14:01:37 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset="utf-8"
Received: from singda.apple.com (singda.apple.com [17.212.152.248]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OPG00BVL52PFG60@nwk-mmpp-sz09.apple.com>; Thu, 04 May 2017 14:01:37 -0700 (PDT)
Sender: singer@apple.com
From: David Singer <singer@apple.com>
In-reply-to: <6E58094ECC8D8344914996DAD28F1CCD7B263E@DGGEMM506-MBX.china.huawei.com>
Date: Thu, 04 May 2017 14:01:37 -0700
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, "avt@ietf.org" <avt@ietf.org>, "draft-ietf-avtcore-rfc5285-bis@ietf.org" <draft-ietf-avtcore-rfc5285-bis@ietf.org>, Ben Campbell <ben@nostrum.com>
Content-transfer-encoding: quoted-printable
Message-id: <304C0BEE-D2E6-4F87-A79E-65144C846934@apple.com>
References: <149379320405.21536.1248894768571572774@ietfa.amsl.com> <e6f713a7-dcc7-7090-811e-93d7de654e01@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD7B263E@DGGEMM506-MBX.china.huawei.com>
To: Roni Even <roni.even@huawei.com>
X-Mailer: Apple Mail (2.3273)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUi2FAYrrtxGnekwf4V5hYve1ayW8zvPM1u seP1KxaLS+vvMVl8OnaexYHV49fXq2weLUfesnosWfKTyWPWzicsASxRXDYpqTmZZalF+nYJ XBmLL39gKphtWHHtzAL2BsZrql2MnBwSAiYSV06uY+xi5OIQEljNJLFr5Vx2mMStaZeZIRIH GSV6XkxkAUnwCghK/Jh8D8jm4GAWUJeYMiUXomYOk8T6HfsYQWqEBSQkPn6czAJhe0gc/LuY CcRmE1CVeDDnGFgNp0CYxJxrnxlB5rAAxc8crQCZwyxwjlHi8csvbCA1zALaEk/eXWAFqeEV sJF4sdoKYtdhRonnL9eDzRQRUJE4dH4NM8TRshK3Zl8CO1pC4DKbxORzM1gnMArPQnL3LIS7 ZyFZsYCReRWjUG5iZo5uZp65XmJBQU6qXnJ+7iZGUDRMtxPbwfhwldUhRgEORiUe3gVu3JFC rIllxZW5hxilOViUxHn5NTkjhQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTAuNz/tfl7bcVHG n8Ay77BJHKdNV98+cbXuR9ES9jvG8XrLnxxQeBxvcUsx/7dY7Uadl/Pj3pTu1bJNk2a0MHuk zvVt5byEXTe0DquaCpre+S1nFfHjg8YE3i8homuefXu1e4LzigsV0QKPX92o27RRwaLLx8GW 2eRD/4bWZ+F2RemPludonzipxFKckWioxVxUnAgA4xdQnmcCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUi2FAcoLtxGnekwZwZ+hYve1ayW8zvPM1u seP1KxaLS+vvMVl8OnaexYHV49fXq2weLUfesnosWfKTyWPWzicsASxRXDYpqTmZZalF+nYJ XBmLL39gKphtWHHtzAL2BsZrql2MnBwSAiYSt6ZdZu5i5OIQEjjIKNHzYiILSIJXQFDix+R7 QDYHB7OAusSUKbkQNXOYJNbv2McIUiMsICHx8eNkFgjbQ+Lg38VMIDabgKrEgznHwGo4BcIk 5lz7zAgyhwUofuZoBcgcZoFzjBKPX35hA6lhFtCWePLuAitIDa+AjcSL1VYQuw4zSjx/uR5s poiAisSh82uYIY6Wlbg1+xLzBEaBWUhOnYVw6iwkUxcwMq9iFChKzUmsNNFLLCjISdVLzs/d xAgO3sLwHYz/llkdYhTgYFTi4V3gxh0pxJpYVlyZe4hRgoNZSYT3wgSgEG9KYmVValF+fFFp TmrxIcYqoF8mMkuJJucDIyuvJN7QxMTAxNjYzNjY3MScKsJK4rzTspkihQTSE0tSs1NTC1KL YJYzcXBKNTCuXsEz862e+5JMjn/LFt/pKm7XDP5qIi6Tub/ul2NricXFR70fJXXzXmx6pJ6k IH1nvVLo8q7LdwzDLkY+P3E3St78+OoL8yf6WWUmHs2eec9YcmlggvG0gov3l4QdeHpQ6b5u 9oSgRxP5WOat/v0n5KXIdENGdheXZbemCZy52/2xva6HqbFViaU4I9FQi7moOBEAm1lUabkC AAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/LQhQ49oG5Qd9N18ZdQyH9Czqyds>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rfc5285-bis-11.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 May 2017 21:01:54 -0000

> On May 3, 2017, at 3:56 , Roni Even <roni.even@huawei.com> wrote:
> 
> inline
> 
>> -----Original Message-----
>> From: avt [mailto:avt-bounces@ietf.org] On Behalf Of Magnus Westerlund
>> Sent: יום ד 03 מאי 2017 11:27
>> To: avt@ietf.org; draft-ietf-avtcore-rfc5285-bis@ietf.org; Ben Campbell
>> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rfc5285-bis-11.txt
>> 
>> WG,
>> 
>> So this latest update was done, based on the IANA expert reviewer for the
>> SDP registrations. Roni quickly updated the template to resolve contact and
>> muxing category for the SDP attributes. However, I think we do need to do a
>> bit more here, and I think the WG needs to review this.
>> So below are my comments, and what I think need to be included.
>> 
>> First, is really "Normal" the mux category for a=extmap-allow-mixed?
>> 
>> To me "Identical" would make much more sense. Either you are capable of
>> support mixed or one is not. Having some m= lines in a mux saying yes it is
>> possible, and others saying no, I can't. That do not make any sense to me, at
>> least across RTP m= lines.
>> 
> 
> [Roni Even] I am not sure, currently you can have some m-lines support mixed and some not (use session level for all). 
> Why do you want to enforce identical for bundle. One can repeat the allowed mixed or use session level if this is what he wants.
> By your logic why do we need to allow in the not bundles case to support some with allowed mixed and some without? We could have used only session level for not bundled case.

I am not sure we need to enforce consistency, since either end can insist on it is they wish. Maybe my video demuxer copes and my audio one doesn’t.

>> 
>> Secondly, I wonder if there needs to be more discussion and spec text on
>> muxing for extmap. So draft-ietf-mmusic-sdp-mux-attributes says on special:
>> 
>> 4.8.  Category: SPECIAL
>> 
>>    For the attributes in the SPECIAL category, the text in the
>>    specification defining the attribute MUST be consulted for further
>>    handling when multiplexed.
>> 
>>    As an exampel,

s/exampel/example/

>> for the attribute extmap [RFC5285], the specification
>>    defining the extension needs to be referred to understand the
>>    multiplexing implications.
>> 
>> and
>> 
>> 5.13.  RFC5285: RTP Header Extensions
>> 
>>    [RFC5285] provides a general mechanism to use the header extension
>>    feature of RTP.  It provides the option to use a small number of
>>    small extensions in each RTP packet, where the universe of possible
>>    extensions is large and registration is de-centralized.  The actual
>>    extensions in use in a session are signaled in the setup information
>>    for that session.
>> 
>>    +---------+--------------------------------------+-------+----------+
>>    | Name    | Notes                                | Level | Mux      |
>>    |         |                                      |       | Category |
>>    +---------+--------------------------------------+-------+----------+
>>    | extmap  | Refer to the document defining the   | B     | SPECIAL  |
>>    |         | specific RTP Extension               |       |          |
>>    |         |                                      |       |          |
>>    +---------+--------------------------------------+-------+----------+
>> 
>>                       5.13 RFC5285 Attribute Analysis
>> 
>> 
>> 
> 
> [Roni Even] I assumed that the behavior is similar to session level extmap except that the RTP extension is only for the m-line
> 
>> To my understanding the properties that applies to extmap when muxing a
>> set of RTP m= lines are the following:
>> 
>> 1. The ID space is common across all m= lines (using RTP) in a BUNDLE group.
>> 
> [Roni Even] this is like session level
> 
>> 2. Each m= block can define a subset of the total defined ID numbers
>> indicating limits in use for a particular media source. This allows for example
>> audio and video media sources to use different set of header extensions.
>> 
> 
> [Roni Even] so you are saying that if you use media level, the support for this extensions are only for this specific m-line
> 
> 
>> 3. An ID number that is defined in multiple m= blocks MUST have identical
>> extmap configuration, i.e. the same URL and any extension attributes that
>> effect the usage or form of the RTP header extension.
>> 
> 
> [Roni Even] My suggestion is to not repeat ID in different m-lines even if use the same extension, one space with unique IDs. This will be simpler. I do not think we have a problem with the number of IDs.
> 
>> 4. The extmap direction setting for a particular ID number MAY be
>> independently set per media source (m= block). This as some media source
>> may be unidirectional and other bi-directional.
>> 
>> I think there is need that we actually document this in this level of detail so
>> that we get consistent implementation support.
>> 
>> So, WG opinions, or comments on my proposal of how one needs to deal
>> with extmap?
>> 
>> I have recommend to Ben that we don't put this document onto the IESG
>> agenda until the above is resolved.
>> 
>> Cheers
>> 
>> Magnus Westerlund
>> Doc shepherd
>> 
>> 
>> 
>> --
>> 
>> Magnus Westerlund
>> 
>> ----------------------------------------------------------------------
>> Media Technologies, Ericsson Research
>> ----------------------------------------------------------------------
>> Ericsson AB                 | Phone  +46 10 7148287
>> Färögatan 6                 | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>> ----------------------------------------------------------------------
>> 
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> avt@ietf.org
>> https://www.ietf.org/mailman/listinfo/avt

David Singer
Manager, Software Standards, Apple Inc.