Re: [rtcweb] Working Group Last Call: draft-ietf-rtcweb-jsep-19.txt - Appendix B
Magnus Westerlund <[email protected]>
| Newsgroups | gmane.ietf.mmusic |
|---|---|
| Message-ID | <[email protected]> |
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 > <[email protected] <mailto:[email protected]>> > 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: [email protected] > <mailto:[email protected]> > ---------------------------------------------------------------------- > > _______________________________________________ > mmusic mailing list > [email protected] <mailto:[email protected]> > 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: [email protected] ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list [email protected] https://www.ietf.org/mailman/listinfo/mmusic