Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-use-cases-and-requirements-03.txt

From: [email-masked]
Date: Sun, 28 Aug 2011 08:28:36 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF.

	Title           : Web Real-Time Communication Use-cases and Requirements
	Author(s)       : Christer Holmberg
                          Stefan Hakansson
                          Goran AP Eriksson
	Filename        : draft-ietf-rtcweb-use-cases-and-requirements-03.txt
	Pages           : 16
	Date            : 2011-08-28

   This document describes web based real-time communication use-cases.
   Based on the use-cases, the document also derives requirements
   related to the browser, and the API used by web applications to
   request and control media stream services provided by the browser.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-use-cases-and-requirements-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-use-cases-and-requirements-03.txt

---

From: Stephan Wenger <[email-masked]>
Date: Sun, 28 Aug 2011 16:07:37 -0400

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

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 28 Aug 2011 20:33:20 -0700

> solution allows to "dial" an E.164 phone number.  

[BA] The following FAQ describes some of the current obligations of "interconnected VoIP" services within the US:
http://transition.fcc.gov/voip/

While the current definition requires the ability to make outbound calls as well as receive inbound calls, there is a proceeding in progress to amend the definition:
http://www.fcc.gov/document/amending-definition-interconnected-voip-service-section-93-commissions-rules-wireless-e911-

>From a technical perspective, it isn't clear to me that the difference 
between the existing and proposed definitions of "interconnected VoIP" 
will have much impact on the RTCWEB requirements.  

> does not make sense to stick our collective heads in the sand and ignore the issue.  

I don't think that the WG is ignoring the issue.  It's just that there are quite a few proceedings in progress in the US, EU and other places around the globe right now, and it's likely that we'll have a better picture of the regulatory requirements within a year (or even 6 months) compared to where we are today.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Tue, 30 Aug 2011 12:49:42 +0200

Stephan,

thanks for very good input! I have made some answers below, and look 
forward to your, and the group's, feedback to them.

Br,
Stefan

> check your grooming before establishing a videoconference session (or

That is right. We might re-phrase it a bit. But what we really was after 
was the flexibility for the web app to display, or not, a self view (and 
to add and remove it at any time).

> case independent from the "previous one" (4.2.3), and rather refer to

The reason for pointing at 4.2.3 was to say that QoS capabilities for 
different accesses should be possible to use. If we refer to 4.2.1 this 
is much more unclear. The users in 4.2.1 may very well be in a situation 
where there is no possibility to offer QoS.

> even API work is necessary.

We were after the first case (two independent video streams). That is 
also the requirement derived from this use case.

> cameras simultaneously are rather exotic today (only telepresence rooms

I have a different view. The average device (smartphone, tablet) is to a 
higher and higher degree equipped with two cameras. I think it should be 
possible to use both.

> Spatial arrangement is not very complex for stereo as well...

That is a very valid comment. Should we just remove 'mono' and be silent 
on that aspect?

> for uncompressed or lossless audio if this use case takes off.

I think there is a lot to be investigated for this use case really. I 
got the tip that this research group as Stanford: 
https://ccrma.stanford.edu/groups/soundwire/
has done a lot and have a lot of real-life experience. Probably we 
should get in contact with them. As you suspect, they seem to use 
uncompressed audio.

> user experience rather than technology choice.

I think this is a valid point. Let's see if we can come up with something.

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

Right. It should not say "stereo", but something like "stereo, 5.1, or 
similar".

> the communication cannot be eavesdropped" would apply to pretty much all

I guess that depends. If you have a leisure conversation, maybe you do 
not care that much. This was a case where we could clearly say that "not 
being eavesdropped" is essential.

But we could say something about it already in the very first use case 
(the most basic one), and derive the requirement already there. Perhaps 
we could say that the conversation in that use case is about planning a 
bank robbery:)

> only relevant factor here.

Use cases 4.3.1 and 4.3.2 do say that you should be able to dial E.164 
using the rtcweb standard IMO. But we never really discussed to what 
extent this means E911 must be supported, and in turn what requirements 
it puts on the rtcweb standard. One aspect is of course location; but 
this is in a web browser context handled by the W3C geolocation WG 
(http://www.w3.org/2008/geolocation/).

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Randell Jesup <[email-masked]>
Date: Tue, 30 Aug 2011 11:06:40 -0400

> cameras simultaneously are rather exotic today (only telepresence rooms
I think this directly talks to a common case that would interest many news
organizations: personal news reporting.  CNN iReport, even local news channels -
they love having users act as reporters-on-the spot, and having the video from
both cameras is a big win for them (and for the producers working from such
footage, who could swap the PIPs or suppress one or the other on the fly).
And most newer Android phones and iPhones have two cameras.

Could I live with losing this use-case?  Yes, with pain.  I do want to support
multiple streams so you can have the user and a local video (either a file, a
camera, or a video encoding of a desktop or window).  I'll note this usecase
only hits the two-cameras part of what I'd like to see, but I don't know
we need to go into that detail here (i.e. where other than a camera a stream
can come from is not something we need to mandate here - I think we just need
to call out the need for two streams).

> for uncompressed or lossless audio if this use case takes off.
Distributed music band - that needs TIGHT N-browser N-stream sync and
VERY LOW (and virtually constant i.e. lan) delay.  I do not believe this is
likely to be technically feasible such that users would accept it.

It would likely need ultra-low delay jitter buffers, much lower packetization
sizes, uncompressed audio, etc.

Distribution of music to multiple playback stations: more possible; the sync
requirements are somewhat relaxed, and the ultra-low delay is relaxed much more.

Let's drop this one, please.

> user experience rather than technology choice.
Generally I agree.  The use case can be more user-oriented.  What are we targeting
for the space here: a conference system tightly tied to an application on the
browser, or a generic conference system which would allow better operation when
you have "interop" calls between services - i.e. can someone on Facebook join
a rtcweb Hangout hosted on Google?  These choices would drive different requirements
to be derived from the usecase.

Also, we're describing things an application *could* do with the system, not the only
or even preferred way to do a conference.  This usecase states that someone *could*
build a "dumb" conference server that does no re-encoding, just stream selection and
forwarding.  It doesn't prevent a conference server that re-encodes, nor a conference
system using SVC or equivalent that subsets the incoming stream.

The application could request that a second smaller stream be sent, though obviously
this presumes the implementation, so it would be more tied to the conference server
implementation.  I'm wondering if there would be a good way to say "find a way to
deliver a low and high resolution image", and let the system (rtcweb) figure out how
to do it given the shared codecs available.  (I.e. SVC in a particular config if both
the conf server and browser support it, simulcast streams if they don't.)

> Second, why is audio mixed to stereo and not to something else, such as
Remove reference to the number of channels.  That's handled via negotiation as
normal.

> the communication cannot be eavesdropped" would apply to pretty much all
Per someone else's comment: we can drop this and add a separate usecase for
planning a bank robbery.  :-)  Better, though, might be a lawyer-client
conversation or a secret agent. :-)

> lifetime of an webrtc solution, but probably even during its introducer
Agreed.  I've dealt with FCC rulings (and I'm sure other countries will have
similar and possibly even stricter requirements).  Basically, it will be very
likely that a provider will want to connect rtcweb to the PSTN (even if through
a gateway), and once that's done they'll need to support E911 services.

I could even see future expansion of the technologies for emergency calling;
you're seeing this now with emergency centers looking to support text messages.
So you might have emergency centers with rtcweb support directly or via a
translation/forwarding service (as voip is generally done today).  There is
significant advantage to an emergency center to be able to support video calls,
for example (though obviously there would be issues surrounding that).

> therefore not quite as politically loaded.)

Yes.  :-)

-- 
Randell Jesup
[email-masked]

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 30 Aug 2011 14:03:39 -0700

> conversation or a secret agent. :-)

In regards to PIP, if A signs B's security certificate, and the media 
swaps, then there should exist A's security certificate signed by B. By 
yesterday's standard, that was not done automatically. The full duplex 
automation of such process is evidence as people's source of anxiety. 
Maybe that the generic feature for that, or to enable that process, is 
available on the "ribbon-end-point".

Can we make this toy-story stack more obvious? Stacked in this order, 
hypervisor(or grub), linux, X11, Xfce (GNOME/compiz optional), 
Mono/.NET, winelib/wine/winnt(co-op), Internet Browser, Win 7/8 File 
Manager. I think that is  clearer on exactly what is "the client" 
framework. Personnally, I want to "the client" to know schema-only, SSRC 
aware, with reflection built-into iNET, which I think is given (YMMV), 
yet not so obvious what is being accomplished with such stack overall. 
We can make wider use out of device driver certificates, under such 
stack, if we consider tablets (with "pen") as client-only.

Under RTP, I can imagine the pen certify itself with the "ink"'d media, 
and continue certification of any gesture recognition. Well, I have 
imagined this for dozen years now, yet realized my homework got done and 
turned-in... do municipal banks invest in student tablets? Yes! That is 
about what is left of municipalities, so now they like (or only can 
afford) the fire-n-forget "upgrade when you break it" mode loaded with 
academic licenses. Sound familiar?

I tried to get one grant written such that one local college had 
real-time DNS of local tablets and routers, so that homework and email 
could be sent around on campus with zero-config, but the procurement 
process stopped our non-faculty vote. Dummy me: "___ ate my pen."

You know why war-dialing started...  accessibilities and solutions clean 
of plagiarism.

-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant