Re: [MMUSIC] [rtcweb] Working Group Last Call: draft-ietf-rtcweb-jsep-19.txt - Appendix B
Magnus Westerlund <magnus.westerlund@ericsson.com> Sun, 26 March 2017 15:45 UTC
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E58712947C; Sun, 26 Mar 2017 08:45:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5C04osQ4itSy; Sun, 26 Mar 2017 08:45:00 -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 A5C5E129479; Sun, 26 Mar 2017 08:44:59 -0700 (PDT)
X-AuditID: c1b4fb30-3dbff7000000628e-eb-58d7e1f7b365
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id D8.29.25230.7F1E7D85; Sun, 26 Mar 2017 17:44:58 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.339.0; Sun, 26 Mar 2017 17:44:54 +0200
To: Peter Thatcher <pthatcher@google.com>, Ted Hardie <ted.ietf@gmail.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, Sean Turner <sean@sn3rd.com>, Cullen Jennings <fluffy@cisco.com>, "mmusic (E-mail)" <mmusic@ietf.org>
References: <CA+9kkMBFXv2H4t2cTUo7Uh4DURYMmkG3VDtwxBfbbwg5i8_jfA@mail.gmail.com> <fa9a59c4-0e4a-24bb-e225-55408949b235@ericsson.com> <CAJrXDUGQM_Uxj6eRTDK_2LuJL4yg9zYiN9vsAnyB1o8GBLOizg@mail.gmail.com>
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <e2b89df6-a6d0-9d8a-5a4f-44be1469be10@ericsson.com>
Date: Sun, 26 Mar 2017 10:44:51 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAJrXDUGQM_Uxj6eRTDK_2LuJL4yg9zYiN9vsAnyB1o8GBLOizg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM2K7tO6vh9cjDN5MZ7bomMxmMXX5YxaL a8tfs1qs/dfObnFlVSOzReNcOwc2jym/N7J67Jx1l91jwaZSjyVLfjJ5HDzIGMAaxWWTkpqT WZZapG+XwJXxfc8F9oIjRhXr975mamCcodbFyMkhIWAi0fdxETuILSSwnlHizZv6LkYuIHs5 o8St22/BEsICKRKNN9czgSREBG4xSpyYuoUFouMso0TDxDwQm03AQuLmj0Y2EJtXwF5iUW8H E4jNIqAqsWjNS2YQW1QgRqJlyQdGiBpBiZMzn4DN4RQIlJi94w1YnBlozsz556FseYnmrbOZ IXZpSzQ0dbBOYOSfhaR9FpKWWUhaFjAyr2IULU4tTspNNzLSSy3KTC4uzs/Ty0st2cQIDN+D W34b7GB8+dzxEKMAB6MSD6/BvmsRQqyJZcWVuYcYJTiYlUR4l1+9HiHEm5JYWZValB9fVJqT WnyIUZqDRUmc13HfhQghgfTEktTs1NSC1CKYLBMHp1QDY7OP/FmbqP28PWYFvV3OCm1Nmbt5 5qYavP6kt2nbHs516/t4RSvPpIjuZiiK89+b/XTTwhsHt+f+ZmoN4V8obHIvr1oyYV670MJz t1/nczxa91ZcpO45k3F6X5NEVWVF0dbop58uy/aEfus23b07e3/COoHNDj1Tarhnzbz2rCUt 6tF0b9ENSizFGYmGWsxFxYkA+pUvrFsCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/kgxLpQXTZKCTsVMs2S4bLKdXVN0>
Subject: Re: [MMUSIC] [rtcweb] Working Group Last Call: draft-ietf-rtcweb-jsep-19.txt - Appendix B
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 26 Mar 2017 15:45:01 -0000
Den 2017-03-24 kl. 16:46, skrev Peter Thatcher: > To address your first two issues, I have made two PRs for JSEP: > > https://github.com/rtcweb-wg/jsep/pull/627 > > https://github.com/rtcweb-wg/jsep/pull/628 > > > Please take a look and see what you think. > See other thread and on these PRs. > > > On the issue of being a packet-based algorithm, I think the existing > text addresses that fairly well: > > Applications can implement RTP stacks in many different ways. > The algorithm below details one way that demultiplexing can be > accomplished, but is not meant to be prescriptive about exactly > how an RTP stack needs to be implemented. Applications MAY use > any algorithm that achieves equivalent results to those described > in the algorithm below. > Yes, that is what I required for being okay with this. And as I said, I accept that is looks like it does, but I would very much have preferred another way of expressing it, that is RTP stream centric. > > On the issue of future extensions of RTCP, I feell confident that the > authors of future extensions can write their text in a way that works > well with this algorithm if it's necessary. Most likely, but there can clearly be cases which doesn't match existing patterns. And I think part of my issue here is there might exist an expectation that an RTP/RTCP extension also needs to update BUNDLE. Which I think is unfortunate. Cheers Magnus > > On Fri, Mar 24, 2017 at 3:49 AM Magnus Westerlund > <magnus.westerlund@ericsson.com <mailto:magnus.westerlund@ericsson.com>> > wrote: > > Hi, > > This email is specifically concerning Appendix B and I CC MMUSIC as the > text is being transfered to BUNDLE. > > First Issues that I think needs to be addressed. > > 1. PT based mapping: > > If the packet's SSRC is in the incoming SSRC mapping table, check > that the packet's PT matches a PT included on the associated "m=" > line. If so, route the packet to that associated "m=" line and > stop; otherwise drop the packet and stop. > > I think the text should be clearer on the limitation of PT based mapping > versus MID based, that following this algorithm, an SSRC is not possible > to move from one media description (m=) to another after the initial > mapping. This probably belong to the earlier discussion of PT based > mapping, but the above quote is the reason for that limitation. > > 2. RTCP BYE handling: > > If the packet is of type BYE, it indicates that the RTP streams > referenced in the packet are ending. Therefore, for each SSRC > indicated in the packet that is found in the incoming SSRC table, > first deliver a copy of the packet to the "m=" line associated > with that SSRC, but then remove the entry for that SSRC from the > incoming SSRC table. > > This has been discussed on the list, but I want to reinforce that the > more reasonable action is to mark the entry for removal, and then after > a short timeout (some seconds), allowing any re-ordered or delayed > packet to arrive and be processed, remove the entry. > > 3. I think it is time that this text is moved into bundle and removed > from JSEP document. > > > Then I have a reservation against this text. I call it a reservation as > it is something I do not require a text change for, but which I wished > was addressed. But at the same time I have been unable to properly > engage and work on an updated text that helps address the issue. > > My reservation is that the text is written from a very RTP/RTCP packet > centric way, and from the perspective of a highly integrated > implementation. I would much have preferred that it was written in an > RTP stream centric way and from the perspective of a modularized RTP > stack implementation with some abstract API between the higher layers > consuming the RTP streams and handling any RTCP feedback messages. That > way the focus could have been on when to create and update the RTP > stream to higher layer "m=" association. RTCP handling is unfortunately > very dependent on what API model one has, and is therefore tricky to > describe as it is dependent on the API, and what it provides versus > hides. > > The risk with the text as it is currently written is that the > implementers of WebRTC endpoints that uses generic RTP/RTCP > implementation modules may have significant issues with mapping the > current text to the API they will see. > > The second aspect of the text which may be problematic is how future > proofing of it in regards to RTCP. If new RTCP feedback messages, > Extended Reports (XR) or other new RTCP functionality is introduced it > may be challenging to map that to the new messages. However, I thank the > authors for especially improving this aspect in regards to RTCP feedback > messages. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Media Technologies, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > <tel:+46%2010%20714%2082%2087> > Färögatan 6 | Mobile +46 73 0949079 > <tel:+46%2073%20094%2090%2079> > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > <mailto:magnus.westerlund@ericsson.com> > ---------------------------------------------------------------------- > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org <mailto:mmusic@ietf.org> > https://www.ietf.org/mailman/listinfo/mmusic > -- 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 ----------------------------------------------------------------------
- Re: [MMUSIC] [rtcweb] Working Group Last Call: dr… Magnus Westerlund
- Re: [MMUSIC] [rtcweb] Working Group Last Call: dr… Peter Thatcher
- Re: [MMUSIC] [rtcweb] Working Group Last Call: dr… Magnus Westerlund