Re: [MMUSIC] [rtcweb] Working Group Last Call: draft-ietf-rtcweb-jsep-19.txt - Appendix B
Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 24 March 2017 10:49 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 A2823129466; Fri, 24 Mar 2017 03:49:26 -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 k8NdwE0wSfE8; Fri, 24 Mar 2017 03:49:25 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 BB36C12940A; Fri, 24 Mar 2017 03:49:24 -0700 (PDT)
X-AuditID: c1b4fb3a-0dfff70000003958-f6-58d4f9b274a3
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id 5D.C1.14680.2B9F4D85; Fri, 24 Mar 2017 11:49:23 +0100 (CET)
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.319.2; Fri, 24 Mar 2017 11:49:21 +0100
To: 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>
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <fa9a59c4-0e4a-24bb-e225-55408949b235@ericsson.com>
Date: Fri, 24 Mar 2017 11:49:21 +0100
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: <CA+9kkMBFXv2H4t2cTUo7Uh4DURYMmkG3VDtwxBfbbwg5i8_jfA@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM2K7qO7mn1ciDA7OZrXomMxmMXX5YxaL tf/a2S2urGpktmica+fA6jHl90ZWj52z7rJ7LFnyk8nj4EHGAJYoLpuU1JzMstQifbsEroyV vx+yFzyTqfjx6Q5bA+MJsS5GTg4JAROJpSfOsHcxcnEICaxjlHi2t58JwlnOKLF/2i0mkCph gWiJLVOmsIIkRAQ2M0psedHPCJIQEgiQ+D3jFCuIzSZgIXHzRyMbiM0rYC+x/tt+dhCbRUBV 4uvNQ8wgtqhAjETLkg+MEDWCEidnPmEBsTkFAiXuXHoKtIyDgxmo98HWMpAws4C8RPPW2cwQ q7QlGpo6WCcw8s9C0j0LoWMWko4FjMyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQJD9eCW 31Y7GA8+dzzEKMDBqMTDWzDxUoQQa2JZcWXuIUYJDmYlEV7RFVcihHhTEiurUovy44tKc1KL DzFKc7AoifM67LsQISSQnliSmp2aWpBaBJNl4uCUamBcrf+z3fmTteB+f5GIzn6RqTPyL7o/ Fq26fpdd32rRjZ7WeuMJN79OeseZJeQhNGmZoXO4x22LqqWPXar5bi2qnxduWHy45vHcEx3n tZjuqKdKc7Jze3uIm87/3ij1upg1WqC6SozzU/3nSW1WW50OxfBckfZ5VX404iP3E43k7vVz Jty8JqDEUpyRaKjFXFScCADqvM+ZUQIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/ywdd2rFiFBytIeCzsVIDkAR5rW8>
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: Fri, 24 Mar 2017 10:49:27 -0000
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 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