Re: [AVTCORE] [avtcore] WGLC for mux-category issue of draft-ietf-avtcore-rfc5282-bis-12
Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 04 July 2017 13:39 UTC
Return-Path: <magnus.westerlund@ericsson.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 7C22E1318A3 for <avt@ietfa.amsl.com>; Tue, 4 Jul 2017 06:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 B21Ed8jDhR9k for <avt@ietfa.amsl.com>; Tue, 4 Jul 2017 06:39:56 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 D9EBC13188C for <avt@ietf.org>; Tue, 4 Jul 2017 06:39:55 -0700 (PDT)
X-AuditID: c1b4fb30-aeec49c000001664-bb-595b9aaad0a1
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CA.B9.05732.AAA9B595; Tue, 4 Jul 2017 15:39:54 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.3.352.0; Tue, 4 Jul 2017 15:38:55 +0200
To: "Huangyihong (Rachel)" <rachel.huang@huawei.com>, "avt@ietf.org" <avt@ietf.org>
References: <51E6A56BD6A85142B9D172C87FC3ABBB9C4CBF80@nkgeml513-mbx.china.huawei.com>
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <71a9b15b-dd7e-f736-5be2-dd2bb88cad63@ericsson.com>
Date: Tue, 04 Jul 2017 15:38:54 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB9C4CBF80@nkgeml513-mbx.china.huawei.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms090407050409040809070108"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7qO6qWdGRBltW8Fq87FnJbrG08xS7 A5NHy5G3rB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4vaWo4OMCxoqWlgdMDYyr2hm7GDk5JARM JOZt/8vaxcjFISRwhFHideteJpCEkMAyRolLS5hBbGGBZImNp84DFXFwiAiESjS81IAoCZVY 1dICNodNwELi5o9GNhCbV8Be4v6k9awgNouAisT62dPBbFGBGIlrM++wQtQISpyc+YQFxOYU CJPYPvk3M8gNzALdjBI3P89nhVigLdHQ1ME6gZFvFpKeWcjqZgHdxAw04MNBGZAaZgFxiVtP 5jNB2GYS8zY/ZIawtSWWLXzNDFGuJrGsVQlVGMS2lpjx6yAbhK0oMaX7ITuEbSrx+uhHRgjb SOLdnkb2BYw8qxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjEC4+fglt8GOxhfPnc8xCjAwajE w7tgZnSkEGtiWXFl7iFGFaA5jzasvsAoxZKXn5eqJMLLNRUozZuSWFmVWpQfX1Sak1p8iFGa g0VJnNdx34UIIYH0xJLU7NTUgtQimCwTB6dUAyPrjyiWc9MvirUv+/RGZ0rp6+LoQ0/dzW/l dHpFXbV/ciTJJrRX+sLz2SvOSBytk9SOOps2Qyrc+H3/R3bHJVvfXi76Z7vx1fnE2iuyudxu e39OrHwaxNh0hXV9VP2pCqPoM67P3hb630+atERRpD6htea7XvOWkDecItsN2VeVB+3abidS W6fEUpyRaKjFXFScCABerOdOpwIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/apqmrRyo9bi_bwZ3yLK5Ij_R7pE>
Subject: Re: [AVTCORE] [avtcore] WGLC for mux-category issue of draft-ietf-avtcore-rfc5282-bis-12
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: Tue, 04 Jul 2017 13:39:58 -0000
Hi, As one of the people who raised this before I want to explain why I think it should identical makes more sense in this case. So first the assumptions. We are talking about offers in the context of BUNDLE, i.e. multiple m= blocks are part of the same RTP session. Thus, these RTP streams generated will be received and sent by a particular endpoint on the same transport port. Thus, the RTP stack processing will be done by a single implementation. The single RTP stack implementation in a BUNDLE context is the basis for my argument why it makes sense to use identical for extmap-allow-mixed. The reason is that the entity on the specified IP address + port will be a single implementation. Thus, I assume it is capable of handling the switching between one and two-byte extension header formats without issues. From this perspective identical appears very reasonable. The argument that David Singer brought to the table is that one may have different capabilities for audio and video in an endpoint. So from my perspective, this can only really work if the RTP payload content is forwarded from the media producing entity and processed by the RTP stack in such a way that they fulfill the RTP protocol specification. If necessary, then rewriting could happen in that forwarding. But, that should really not be needed. First the signaling that enable RTP header extension usage can control its side of the negotiation and what IDs are used. Remember that the ID space becomes joint over all extensions in the RTP session, but different RTP streams and media blocks may have only a subset of all header extensions configured. Thus, if audio stream generator have this limitation that it only can process one-byte header extensions, only IDs that fits the short can be assigned, if at all possible. Thus, the only threat would be a sender that uses two-byte headers when it is not needed. So the benefits as I see with identical is the following. For an BUNDLE capable implementation where the implementation that adds header extensions to the RTP packets is common, there is consistent configuration for the RTP session, and the possibility to switch at any point reduces the complexity of the code-base as no attempt to predict or determine future needs are needed. Use what is currently needed. No extra complexity for this modern implementations to deal with legacy implementations into bundle scenario. That complexity of ensuring which IDs are used, and dealing with adopting a legacy implementation to BUNDLE ends up with the ones doing that choice, not everyone else. And this is for a case I at least see as strange as all RTP streams will flow over the same 5-tuple for the different media types. Thus, only implementation that attempts to forward RTP packets without rewriting will have this issue. If one allows Normal, then one pushes the complexities of having to be able to restrict some RTP streams in an RTP session to not switch between one and two-byte headers. This will require code, and also more signaling logic to deal with cases where this is offered. Thus, I think using identical would simplify the system in general. And allow modern BUNDLE capable implementations to becomes simpler, for a little cost for the implementers that attempt to integrate legacy packet generators into a single RTP session without a translation layer, or back to back RTP sessions. Cheers Magnus Den 2017-06-29 kl. 08:05, skrev Huangyihong (Rachel): > > Hi Folks, > > As you may notice that there was a discussion for the mux category > selection for a=extmap-allow-mixed in > draft-ietf-avtcore-rfc5282-bis-12. This issue was raised by Magnus > when he was doing the shepherd work. See > https://mailarchive.ietf.org/arch/msg/avt/BaElJmDlmDtOaAcXKV_Rk5fARgk. > This discussion happened after the WGLC and no formal conclusion was > made then. > > And now the discussion is restarted in IESG review of this draft. The > author thinks it should be Normal to cover multiple cases, while some > people think it’s better to be Identical to make things simple. > > So this email is to have a one-week WGLC for this issue and deliver a > formal conclusion to IESG: > > If you do not agree that “Normal” mux category should be used for > a=extmap-allow-mixed, please express it in the mailing list before > 8^th July. > > Thanks. > > BR, > > Rachel (as the co-chair) > -- Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- [AVTCORE] [avtcore] WGLC for mux-category issue o… Huangyihong (Rachel)
- Re: [AVTCORE] [avtcore] WGLC for mux-category iss… Huangyihong (Rachel)
- Re: [AVTCORE] [avtcore] WGLC for mux-category iss… Magnus Westerlund
- Re: [AVTCORE] [avtcore] WGLC for mux-category iss… Roni Even
- Re: [AVTCORE] [avtcore] WGLC for mux-category iss… Magnus Westerlund