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

Bernard Aboba <> Fri, 09 May 2014 23:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C70D21A010D for <>; Fri, 9 May 2014 16:47:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tIU9uF3KaKkP for <>; Fri, 9 May 2014 16:47:46 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::232]) by (Postfix) with ESMTP id 9B82E1A010C for <>; Fri, 9 May 2014 16:47:45 -0700 (PDT)
Received: by with SMTP id x12so4518196wgg.33 for <>; Fri, 09 May 2014 16:47:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Aw8rj3Ix3TNUfH1k+jhkQ6oh1Tli3UBm7Co33wQaCHc=; b=liLTgILBOoi2FxNXfoG4xSwBXNu/a99OfWFCvM4AeYwXvaouvmCUoBVmutgromWBlB K8R8077He67VvTRvTw9LrXDxf8/Pz85Ge0q1aDjCD6vrbVlyzPdcJ6pk/t/4lAa1YwEZ 25pWWQ9k5MAJVMF+ZUnA2b/FF2RKyWCx4OQNt8PudZQwmB1mqf+8iV4jwPCGxP4VFE2y 6qy2SoOM8v3gGGFGapDmsfecaGVTDi+7pL//YAj02jI6sYwgAb7DTvBHc2RZLsHbvWuO CgGlgQcy6zUPuw8XdcWfTwQTMh+vcqUspRPjW4s6Sv65kfi8bCIh38TE8piPktCKH+fG taWQ==
X-Received: by with SMTP id q15mr5370651wik.4.1399679259990; Fri, 09 May 2014 16:47:39 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 9 May 2014 16:47:19 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Bernard Aboba <>
Date: Fri, 09 May 2014 16:47:19 -0700
Message-ID: <>
To: Cullen Jennings <>
Content-Type: multipart/alternative; boundary="001a11c2283a17617704f900394e"
Cc: "" <>
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 23:47:50 -0000

Cullen said:

"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. "

[BA] Where temporal scaling is used, RTX can be useful in protecting the
base layer.  So it's not universally useless.  I do agree that MUST is too
strict, though.

"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. "

[BA] Yeah, I wondered about that, too.

On Fri, May 9, 2014 at 7:41 AM, Cullen Jennings <> wrote:

> 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.
> _______________________________________________
> rtcweb mailing list