Re: [rtcweb] Spencer Dawkins' Yes on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT)

Magnus Westerlund <> Thu, 11 June 2015 14:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5BD761B2F7B; Thu, 11 Jun 2015 07:45:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DEaTb5wrlu2x; Thu, 11 Jun 2015 07:45:32 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C2471B2F61; Thu, 11 Jun 2015 07:45:31 -0700 (PDT)
X-AuditID: c1b4fb2d-f794d6d000004501-17-55799f098546
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id AF.F2.17665.90F99755; Thu, 11 Jun 2015 16:45:29 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Thu, 11 Jun 2015 16:45:29 +0200
Message-ID: <>
Date: Thu, 11 Jun 2015 16:45:26 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Spencer Dawkins <>, The IESG <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM+JvrS7n/MpQg+UTTCxm/JnIbLH2Xzu7 xbIpe5gdmD12zrrL7rFkyU+mAKYoLpuU1JzMstQifbsEroy+zS2MBT8NK/bf6mFpYNyi1sXI ySEhYCIx7/Q+NghbTOLCvfVANheHkMBRRomH09qYIJzljBKrbr1gAqniFdCW+HypCayDRUBV Yn/nHGYQm03AQuLmj0awuKhAlMTUx+tYIOoFJU7OfAJmiwj4SlyZvBSshllAVOLVwylgvcIC cRLXTrUB2RxAyxwl1u3NBAlzCjhJ/JlzhxUkzCxgL/FgaxlEp7xE89bZYJ1CQNc0NHWwTmAU nIVk2SyEjllIOhYwMq9iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECAzag1t+6+5gXP3a8RCj AAejEg/vgtcVoUKsiWXFlbmHGKU5WJTEeWdszgsVEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnV wKi6Tu6fw92cip3MUfWHr6y+czpng2f5s+9ukz6/fibBYcPye4H7EsnpIZ98cgueT42+UxSR dvqIuz870+FVqVa5tVeTjuzhVO5ZX1jgHr18q4iawLETl4tOz516YkaReOG6gvpTF+4KvJdV 47qoYSu3MehkoFbBI+5TvknBjBafrrvOrzF+e0eJpTgj0VCLuag4EQBuPHqxOwIAAA==
Archived-At: <>
Subject: Re: [rtcweb] Spencer Dawkins' Yes on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT)
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: Thu, 11 Jun 2015 14:45:34 -0000


Please see inlien.

Spencer Dawkins skrev den 2015-06-11 05:07:
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-rtcweb-rtp-usage-24: Yes
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> This draft looks very helpful, and I could understand it pretty well, I
> think.
> I did have a few comments.
> Am I reading this correctly?
>     The following RTP and RTCP features are sometimes omitted in limited
>     functionality implementations of RTP, but are REQUIRED in all WebRTC
>     Endpoints:
> ... skipping down to ...
>     o  Support for sending and receiving RTCP SR, RR, SDES, and BYE
>        packet types, with OPTIONAL support for other RTCP packet types
>        unless mandated by other parts of this specification.
> Is this saying that OPTIONAL support is REQUIRED unless some other part
> of the spec says it's a MUST? or a MUST NOT? or something else entirely?

So RTCP packet type SR, RR ,SDES and BYE are REQUIRED (following the top 
statement), but the other RTCP packet types are OPTIONAL unless mandated 
explicitly further down in the document.

Do you want us to rewrite this so that it is clearer that the second 
part is just a note that the not explicitly enumerated packet types are 

      o  Support for sending and receiving RTCP SR, RR, SDES, and BYE
         packet types. Note, that the other RTCP packet types are
         OPTIONAL to support unless mandated by other parts of this

> In this text,
>     Signalled bandwidth limitations, such as SDP "b=AS:" or
>     "b=CT:" lines received from the peer, MUST be followed when sending
>     RTP packet streams.  A WebRTC Endpoint receiving media SHOULD signal
>                                                            ^^^^^^
> could you help me understand why this is a SHOULD, and not a MUST?
>     its bandwidth limitations.  These limitations have to be based on
>                                                   ^^^^^^^^^^^^^^^^^^^
>     known bandwidth limitations, for example the capacity of the edge
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>     links.
> S0, not a 2119 MUST/REQUIRED ... is this simply recognizing that the
> signaled limitation has to be based on something, and the capacity of the
> edge links is the best upper limit that is easily available without
> probing? Or is it saying something else? I'd think the capacity of the
> edge links wouldn't be a great plan if you end up with a multi-unicast
> mesh with no middleboxes, for instance (but I could be wrong about that),
> but you might be saying that's still as good a limit as anything else.

The reason for a SHOULD is that it may not know. Then signalling a 
limitation it doesn't know is strange. Therefore the should.

If one considers how these figures are created in other applications, 
they are often based on knowledge about the highest intended to be used 
bit-rate for any of the offered codecs and the number of streams are 
usually known. For WebRTC that is less certain. Thus, here one should 
offer a limit that is more related to what one actually know is a 
limitation for what one is capable of receiving. Thus maximum number of 
streams times highest codec rate is possibilities. But that does not 
provide good figures for video either.

So it is fiddly in how an implementation populate the field well.

> In this text,
>     However, implementations that can use
>     detailed performance monitoring data MAY generate RTCP XR packets as
>     appropriate; the use of such packets SHOULD be signalled in advance.
> I wouldn't ask this question except that the draft has an entire section
> on dodgy implementations, but ... is there an unstated assumption that if
> the use of RTCP XR packets is signaled, the sender would respond to this
> information? I'm guessing "yes", and that could be fine, but I wanted to
> ask.

If RTCP XR is signalled, then it is a request to send those RTCP XR 
attributes, i.e. the consumer requests them to be sent. (unless recvonly 
direction where it is informative what one could report) Thus, yes if 
one request them one can assume that endpoint has some use for them. 
However, because of this style of signalling and multiparty scenarios it 
is a possibility that RTCP XR are included and forward to a particular 
endpoint. The intention is that one should signal and agree on what is 
being sent, but it can't be considered erroneous if an RTCP XR packet 
showed up unasked for.

I would note that if any specific response are expected from the 
reception of an RTCP XR that would need to be specified somewhere.

> I think Section 9.  WebRTC Use of RTP: Future Extensions is very good,
> but I wonder if the first paragraph needs to be as 2119-heavy as it is.
> The second paragraph says what it needs to say without 2119 language.

Yes, I agree that these RFC 2119 could be replaced.

MUST -> have to
SHOULD (remove)

Any issues with changing this?

> In this text, I think there's a nit.
>        whereas it would it all three participants were part of a single
>                         ** I'm guessing this is "if"?

Yes, it is a nit.


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: