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

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 protected]
----------------------------------------------------------------------