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

[Peter Thatcher <[e-mail]>]

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.



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.


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.

On Fri, Mar 24, 2017 at 3:49 AM Magnus Westerlund <
[e-mail]> 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  [phone]
> <+46%2010%20714%2082%2087>
> Färögatan 6                 | Mobile [phone]
> <+46%2073%20094%2090%2079>
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>