[rtcweb] Comments on use case draft

[Stephan Wenger <[e-mail]>]

Hi,

I have a couple of comments related to
draft-ietf-rtcweb-use-cases-and-requirements-03.txt.

1. There are a number of editorial issues that need to be addressed; I
will communicate those to the editors in private.

2. Section 4.2.1.1: in a typical system, self-view is enabled well before
connection establishment, not after.  For obvious reasons: you want to
check your grooming before establishing a videoconference session (or
taking a video call).

3. Section 4.2.4.1.: QoS related issues do not only occur in "roaming"
scenarios; therefore, I would suggest to make the description of this use
case independent from the "previous one" (4.2.3), and rather refer to
4.2.1.

4. Section 4.2.6.1: This use case is not described in sufficient detail.
At least two scenarios are possible.  First, both front and rear camera
send individual video streams (potentially at different resolutions), and
the PIP mixing happens in the receiving browser.  This would be a user
interface issue and no mechanisms need to be specified in the IETF beyond
being bale to send more than one video stream (though there may be need
for related API work).  Second, the PIP mixing happens in the sending
phone, and only one stream is being sent.  In this case, I believe not
even API work is necessary.
Suggest to reconsider whether this use case is relevant enough for being
kept.  Multi-camera systems being able to send coded samples from both
cameras simultaneously are rather exotic today (only telepresence rooms
come to my mind).

5. Section 4.2.7.1.: Why are the sending peers restricted to mono audio?
Spatial arrangement is not very complex for stereo as well...

6. Section 4.2.9.1.: What's really necessary here is a mechanism that
allows a user to tell a browser that VERY tight cross-signal sync and VERY
low delay is required, which may trigger different jitter buffer handling
and such.  Beyond that, I believe that audio codec negotiation may be
helpful.  Audio professionals (like musicians) are somewhat more picky
when it comes to these technology selections than normal users.  I would
not be surprised if we would learn that there is a real market requirement
for uncompressed or lossless audio if this use case takes off.

Section 4.3.3.1: I have a number of issues with this use case.

First, in contrast to most other use cases, this one enters solution space
quite prominently.  That wouldn't be an issue for me if the solution my
employer is favoring were mentioned here, but it is not :-(.  To cure my
immediate concern, one suggestion would be to remove references to
simulcast and/or add references to spatial scalability.  However, perhaps
it's better to describe the behavior of the multipoint system in terms of
user experience rather than technology choice.

Second, why is audio mixed to stereo and not to something else, such as
5.1?  

Third, the security stuff is not in any way technically bound to the rest
of the use case, so I would farm it out into its own use case, and/or
mention it as a "generic" feature... Remarks like "it is essential that
the communication cannot be eavesdropped" would apply to pretty much all
use cases, right?

7. Missing use case:

It is my understanding that for regulatory compliance, in many developed
countries, there will be a need for an E911 type of service *IF* the
solution allows to "dial" an E.164 phone number.  I remember a controversy
involving SKYPE in ca. 2005, and also having read about recent FCC
hearings about this issue; for example,
http://www.broadbandlawadvisor.com/2011/07/articles/voip/fcc-seeks-comment-
on-extending-e911-rules-to-oneway-outboundonly-voip-improve-location-capabi
lity-of-inteconnected-voip/.
If there is a reasonable expectation that a webrtc service with outbound
dialing capability in E.164 number-space requires E911 handling, then it
does not make sense to stick our collective heads in the sand and ignore
the issue.  I believe there is such an expectation; surely during the
lifetime of an webrtc solution, but probably even during its introducer
phase.
If E911 is relevant in this sense, then this issue needs to be addressed
in section 4.3.1, 4.3.2, and perhaps 4.2.5.
I understand that the editors did not address those use cases yet based on
(presumably) lack of consensus, but I fear that IETF consensus is not the
only relevant factor here.

(I could mention "legal intercept" in the same context, but suggest to
focus on emergency calls first, because a) they are easier to handle, b)
more widely applicable, and c) generally agreed to be a useful thing, and
therefore not quite as politically loaded.)

Stephan