Re: [MMUSIC] [rtcweb] Working Group Last Call: draft-ietf-rtcweb-jsep-19.txt - Appendix B

Magnus Westerlund <> Sun, 26 March 2017 15:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E58712947C; Sun, 26 Mar 2017 08:45:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5C04osQ4itSy; Sun, 26 Mar 2017 08:45:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A5C5E129479; Sun, 26 Mar 2017 08:44:59 -0700 (PDT)
X-AuditID: c1b4fb30-3dbff7000000628e-eb-58d7e1f7b365
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id D8.29.25230.7F1E7D85; Sun, 26 Mar 2017 17:44:58 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id 14.3.339.0; Sun, 26 Mar 2017 17:44:54 +0200
To: Peter Thatcher <>, Ted Hardie <>, "" <>, Sean Turner <>, Cullen Jennings <>, "mmusic (E-mail)" <>
References: <> <> <>
From: Magnus Westerlund <>
Message-ID: <>
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: <>
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: <>
Subject: Re: [MMUSIC] [rtcweb] Working Group Last Call: draft-ietf-rtcweb-jsep-19.txt - Appendix B
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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:
> 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.



> On Fri, Mar 24, 2017 at 3:49 AM Magnus Westerlund
> < <>>
> 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:
>     <>
>     ----------------------------------------------------------------------
>     _______________________________________________
>     mmusic mailing list
> <>


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: