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
----------------------------------------------------------------------