Subject: [rtcweb] Focused Review of RTP usage draft

From: "Bran, Cary" <[email-masked]>
Date: Fri, 1 Jun 2012 23:00:31 +0000

Hello RTC-Web WG,

Below are some comments/feedback that Charles Eckel and I had from our
focused review of the WebRTC RTP usage draft -
http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-02

Regards,

Cary and Charles

Overall feedback:

The draft covers some very important topics and is very thorough and well
written.

A theme throughout the draft is supporting legacy devices. From our read
we were unsure what position this draft is is with regards to interworking
with legacy devices/systems, sections 3.1 (translator), 4.2, 4.5 do not
seem to readily support interworking, while section 4.4 does.  We would
ask the authors to please clarify their position.

Section: Abstract
Please consider revising the first sentence of the abstract and first
sentence of paragraph two of the introduction as it is a little unclear to
the reader.
A possible suggestion for revision would be (take it or leave it): The Web
Real-Time Communication (WebRTC) framework provides support for native
interactive voice and video communications between web browsers.

Section: 2
For the terminology section - why not just adopt the usual RFC 2119
language?

Assuming the decision moving forward is to define new terms, please note
the following comment.
Currently RECOMMENDED is defined as, "Should be included as its brings
significant benefit, but the solution can potentially work without it."
This definition is too vague.
A suggested rewording is, RECOMMENDED: "Should be included as it brings
significant benefit; however, the solution can work without it, though
potentially in a more limited manner."

Section: 3.1
Supported RTP Topologies

Overall: To educate the reader with some of the issues with the proposed
topologies, it may be worthwhile (but maybe not possible in ASCII art) to
show the number of sessions instead of a bidirectional <----> notation.
For example in Figure 4: RTP Translator (Relay) with Only Unicast Paths I
my mental model of the topology was this (I removed the "D" endpoint for
clarity).

+---+                          +---+

|   |----> +------------+ <----|   |
                    | A | <-C--|            | --A->| B |
+---+ <-B--|            | --C->+---+
           | Translator |
+---+----> |            |
|   |<-B-- |            |
                    | C |<-A-- |            |
                    +---+      +------------+

Multi-unicast:
It may be worth expanding this topology to include scenarios in which it
is not a full mesh, such as a sender sending to a subset of 2 or more
receivers, or a few senders sending to the complete set of receivers. The
basic idea being that you may have some participants that are receive
only, or send only.
An example scenario could be using a recording service to record a Google
hangout session.

Mixer: Another downside is that there is a typically a loss of information
(e.g. the loss of video or a participant that is not speaking, or a loss
of audio of speaker not selected as an active
speaker)

Transport Translator: Where the draft reads, "It simply forwards the media
from all other to all the other", it should instead read, "It simply
forwards the media from each endpoint to all other endpoints."The
scalability and bandwidth concerns are similar to the multi-unicast
topology, with merely the distribution burden shifted to a centralized
node.

Near the end of the section, it reads, "The intention is that the presence
of the translator is transparent to A, however it is not certain that is
possible." This is a good goal. Hopefully subsequent versions of this
draft can expand on it.  The very last sentence of the this section may
want to be reworded, a suggestion here would be: "The scenario above is
included as a reference and discussion point for future mechanisms using a
Translator to support legacy end-points interoperating within a WebRTC
environment."

Section: 3.2

Perhaps add a reference to section 5 here?

Section: 4.3
Choice of RTP Payload Formats
This section is not clear, particularly the exception related to
multiplexing. One thing that needs to be kept in mind, and perhaps should
be stated explicitly, is the handling outlined in RFC 3264:

   7. Offerer Processing of the Answer

   When the offerer receives the answer, it MAY send media on the
   accepted stream(s) (assuming it is listed as sendrecv or recvonly in
   the answer).  It MUST send using a media format listed in the answer,
   and it SHOULD use the first media format listed in the answer when it
   does send.
   :
   :
   The offerer MAY immediately cease listening for media formats that
   were listed in the initial offer, but not present in the answer.

Section: 5
Overall feedback.  This is a great section and very informative.  As I
understand RTP, both sides have to implement the extensions in order for
the extensions to be used.  This currently this section is not requiring
any of the extensions to be implemented, my question to the authors is
what is the future purpose for this section?  Are some of these extensions
going to become mandatory in a future revision of the draft?

Section: 5.2
Header Extensions
The last two paragraphs of this section include introductory text for
sections 5.2.1-5.2.3.  The information contained within these paragraphs
is redundant to and could fall out of sync with sections 5.2.1-5.2.3. We
would recommend that the authors chop out introductory text to avoid
duplication and potential contradictions in future revisions of the draft.

Section: 6.1
Retransmission
Expand the last paragraph to include avoiding overly aggressive
retransmission schemes at the expense of being a bad internet citizen.

Section: 6.2.3
Recommendations for FEC
The recommendation for FEC is not clearly stated in this section.  It
would be valuable to the reader to have a recommendation based upon
results from experiments/analysis of FIR/PLI vs. retransmission/FEC, plus
some guidance as to when either rmethod is appropriate.

Section: 7.2
Some expansion for the reader is needed here.  A big help would be to
clarify the problem via example and then to propose (if there is) a
solution to the problem.

________________________________

CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain information that is confidential and/or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, please DO NOT disclose the contents to another person, store or copy the information in any medium, or use any of the information contained in or attached to this transmission for any purpose. If you have received this transmission in error, please immediately notify the sender by reply email or at [email-masked], and destroy the original transmission and its attachments without reading or saving in any manner.

For further information about Plantronics - the Company, its products, brands, partners, please visit our website www.plantronics.com.