Re: [rtcweb] WGLC review of draft-ietf-rtcweb-rtp-usage-13

Magnus Westerlund <> Tue, 13 May 2014 15:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 77B1B1A0102 for <>; Tue, 13 May 2014 08:08:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xB4LMh0E0Xim for <>; Tue, 13 May 2014 08:08:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CAB711A00DB for <>; Tue, 13 May 2014 08:08:09 -0700 (PDT)
X-AuditID: c1b4fb3a-f79a86d0000010e9-6b-53723552063a
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 28.01.04329.25532735; Tue, 13 May 2014 17:08:02 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Tue, 13 May 2014 17:08:02 +0200
Message-ID: <>
Date: Tue, 13 May 2014 17:07:53 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Ben Campbell <>,
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUyM+JvjW6QaVGwwc4d+hbzO0+zW6z9187u wOSxZMlPJo9ZO5+wBDBFcdmkpOZklqUW6dslcGWc+axU0C5XsXzCc+YGxrfiXYycHBICJhJ7 Pl5ggrDFJC7cW88GYgsJHGWU6FzD2cXIBWQvZ5ToWv8OrIhXQFuio+MFWBGLgKrEj3/dYDab gIXEzR+NYLaoQLDEhod/2SHqBSVOznzCAmKLCJhKzFg0kRHEFhZwlujpf8YMscxOYvP252C9 nAL2EkdW9gL1cgAdJC7R0xgEEmYW0JOYcrWFEcKWl2jeOhuqVVuioamDdQKj4Cwk22YhaZmF pGUBI/MqRtHi1OLi3HQjI73Uoszk4uL8PL281JJNjMBQPbjlt9UOxoPPHQ8xCnAwKvHwKvAU BguxJpYVV+YeYpTmYFES5520yD1YSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2Os8B7BB/vS Hn8oEhQqiL6tavCUIbXjqeurM7teWe6pT2d4xbzAxcHkyAeHgHrx75ZPn81bzCV4hzNn9kTH x07T+L1vXjtT/UXU+tCW+b6KJ7U3H+716JTMmiYtoO4smBze1bXt1MTlul22nPVXtecc2bls 97vknDYdef2WK4ea9rsXRX9LXqLEUpyRaKjFXFScCABM1WlWNgIAAA==
Subject: Re: [rtcweb] WGLC review of 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: Tue, 13 May 2014 15:08:12 -0000

Hi Ben,

Thanks for the review, please see reply inline.

On 2014-05-09 23:56, Ben Campbell wrote:
> Hi,
> This draft seems well constructed. I don't have much in the way of
> technical comments, but do have a few extremely minor/editorial
> comments:
> Thanks!
> /Ben
> ----------------------
> -- 4.1, 2nd to last bullet:
> Can there be a reference for " RTCP timer reconsideration "

Yes we can add a section reference into RFC 3550 for this.
> -- 4.3, last paragraph: "RTP receivers MUST follow the
> recommendations in Section 4.3 of [RFC7160] in order to support ..."
> I assume that you mean that receivers MUST support the
> recommendations because they need to support multiple clock rates. A
> strained interpretation could assume that, if they want to support
> multiple clock rates, they MUST support..."

Correct, will look at reformulating this. Because I believe an WebRTC
receiver must be required to support multiple clock rates.
> -- 4.5, first paragraph: " ... support for multiplexing RTP data
> packets and RTCP control packets on a single transport-layer flow for
> each RTP session is REQUIRED, provided it is negotiated in the
> signalling channel ..."
> I assume the intent is that REQUIRED, but only _used_ if
> negotiated? As written, it seems to say _support_ is both REQUIRED
> and negotiated.

Yes, required to implement support for, use based on negotiation. Will
take a look at proposing another formulation.

> (A similar construction occurs in 4.6, 2nd paragraph)

Will take a look at that too.

> -- 5.2.2, last paragraph:
> If I understand 6904 correctly, you signal the use of encryption for
> each header you want to encrypt, right? If so, then how is
> "explicitly disabled through ... signalling" different than "not
> signalled"? If it's the same thing, then this comes perilously close
> saying "... RECOMMENDED that the encryption be used ... unless you
> don't want to."

Yes, you are correct, assuming that signalling is SDP. Which not all on
this mailing list assumes. One way to resolve this is to actually tease
the two parts apart. First of all it is recommended to encrypt it.
Secondly, this may be controlled through an API or signalling.

> (I have no objection to the "explicitly disabled through the API" )
> -- Figures 1 and 2:
> Any chance of centering these?

This is an bug in the version 2.0 of XML2RFC. Can't do anything about
until someone fixes this, or hand adjust it.

> -- 12.1.3:
> How does (or will) DART fit in here? Seems like it might have
> something to say, but I'm not sure how the timing relates.

So this text is the high level teaser to DART work from my perspective.
The Dart work will have to get into some of the more subtler issues. To
my understanding the DART output will be part of the reference chain
here. This document reference [I-D.ietf-tsvwg-rtcweb-qos]
which in its turn will reference DART. You will also likely to be able
to reach the DART document through draft-ietf-rtcweb-transports.

If the DART document becomes available and seen as ready prior to this
having gone to far down the publication process we can reconsider if
this should have a direct reference or not. For now I would leave it out.


Magnus Westerlund

Services, Media and Network features, Ericsson Research EAB/TXM
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: