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

Cullen Jennings <> Fri, 09 May 2014 14:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 19FE41A02B3 for <>; Fri, 9 May 2014 07:42:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I6MJ7bIiMkxi for <>; Fri, 9 May 2014 07:42:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DFE661A02B0 for <>; Fri, 9 May 2014 07:42:00 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 76DFA50A86 for <>; Fri, 9 May 2014 10:41:54 -0400 (EDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Cullen Jennings <>
In-Reply-To: <>
Date: Fri, 09 May 2014 08:41:52 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "" <>
X-Mailer: Apple Mail (2.1874)
Subject: Re: [rtcweb] Working Group Last Call for draft-ietf-rtcweb-rtp-usage-13
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 09 May 2014 14:42:03 -0000

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. 

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


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.