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

From: Magnus Westerlund <[email-masked]>
Date: Fri, 24 Mar 2017 11:49:21 +0100

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: [email-masked]
----------------------------------------------------------------------

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 24 Mar 2017 21:46:06 +0000

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 <
[email-masked]> wrote:

> <+46%2010%20714%2082%2087>
> <+46%2073%20094%2090%2079>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Magnus Westerlund <[email-masked]>
Date: Sun, 26 Mar 2017 10:44:51 -0500

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

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.

> 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-masked] <mailto:[email-masked]>>
> wrote:
>
>     Hi,
>
>     <tel:+46%2010%20714%2082%2087>
>     <tel:+46%2073%20094%2090%2079>
>     <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 

Magnus Westerlund