Re: [rtcweb] Working Group Last Call for draft-ietf-rtcweb-rtp-usage-13

[Cullen Jennings <[e-mail]>]

Overall the document looks in excellent shape. I do have a bunch of comments but they are all pretty easy to deal with. 

Page 5
I think that draft-ietf-avtcore-rtp-multi-stream-optimisation should be MAY not a MUST. We don’t loose significant interoperability by not having it a MUST. 

Page
Sending correct sync information should be MUST not SHOULD. We can’t make lip sync work without this and I think the flows I have seen already send it. Note people don’t have to deal with correctly implementing lip sync on the receiving end, they just have to send enough information to make it possible that receivers that want to can. 

Has the text "support for RTCP timer reconsideration." but I don’t know what this means or how to implement it - suspect we just need a ref or bit more text. 

I’d refer to see "reduced minimum RTCP reporting interval" be a MUST and I could live with MAY but SHOULD is just lame for this. 


Page 8 

It has the text 

An end-point that has signalled support for multiple RTP payload formats SHOULD be able to accept data in any of those payload formats at any time, unless it has previously signalled limitations on its decoding capability.

I think that has to be a MUST not a SHOULD or else this will not work. 

Page 18

This has RTX (RFC4588) and MUST. RTX has turned out to be close to useless in interactive communications systems because the RTT is just too high to make this viable. You need to set your jitter buffer to be larger than the RTT for this work and I am aware of any significant internet collaborations system that sets the jitter buffer size that high. I think this should be MAY not MUST but that said, I can easily live with MUST, it just seems useless at a time where we are trying to reduce the complexity of the system. 


Page 19

It says FEC is not required. I’m OK with this but my notes have it as the WG previously agreed on this being required. It might be worth putting this up on a slide in the May meeting and checking the WG is good with no FEC. Perhaps my notes are all wrong - I did not try and go back throughout minutes. It’s possible the WG decided different things and different times. 


Page 20

Has the text 

  signalled bandwidth limits SHOULD be used to limit traffic 

I might be reading this the wrong way but given the weak congestion control in general, I feel pretty strongly that the browser can’t ignore signaled bandwidth limits and this needs to say something more like the "MUST not exceed signaled bandwidth"


Page 20-22, 

Section 7.2 - I felt like this section was supposed to convince me it was all OK but the more I read it the more confused I was. What does one do if sending video on says a 768 kbps link? Send every 5 frames? 

I think part of the confusion stemmed from the implication that to do good congestion control, you needed a report once ever say RTT but in RTP we could not do that so we would fall back to a far less frequent reporting of once ever frame. But ever frame is less than the RTT in most internet case so I was just confused by the whole section. 

I don’t think this section is going to help implementors much as it is - perhaps it could just be refactored a bit to help implementers understand how often to send RTCP and why. 


Page 24

Has 

All WebRTC implementations MUST be prepared to receive RTP XR report packets, whether or not they were signaled.

I disagree with this - we are in a non multicast environment with RTP inside DTLS/SRTP. One should not be getting reports for extensions that were not negotiated. 

Similarly on page 25 the text has

The RTP extensions to be used SHOULD be agreed upon, 

I think this needs to be a MUST. 



Page 27 

I think it would be best to just remove the line 

 This document [I-D.ietf-mmusic-msid] also defines, in section 4.1, how to map unknown source packet stream SSRCs to MediaStreamTracks and MediaStreams.

as that is not key to this spec. 


Page 36 - 37 

Section 12.2.2. 

So if I read this right, it says you MUST resolve SSRC collisions but RFC 5576 has no way to do that. What are implementors supposed to do ?

Even ignoring 5576 - it’s just not clear to me how one detects and resolves SSRC collisions. 

 

Cullen with my individual contributor hat on.