On 8/4/2011 3:57 AM, Stefan Håkansson LK wrote:

>
> B. New use cases
> ===========
> I noted (as not immediately dismissed) the following proposals:
>
>      1. Distributed music band, discussed at the webrtc meeting
>      2. Use cases regarding different situations when being invited to a “session”, e.g. browser open, browser open but another tab active, browser open but active in session, browser closed, …. (Matthew Kaufman); discussed at webrtc meeting
>      3. Different TURN provider scenarios (Cullen Jennings); discussed at the webrtc meeting
>      4. More challenging NAT case (Matthew Kaufman); UDP blocked http://www.ietf.org/mail-archive/web/rtcweb/current/msg00468.html
>      5. E911 (Paul Beaumont) http://www.ietf.org/mail-archive/web/rtcweb/current/msg00525.html
>      6. Local Recording (John Ewell) at webrtc meeting

Would this cover all "voicemail" and "videomail" cases?  I.e. having a client
accept connections in the background if the call is not answered, optionally
play a message, and record incoming audio/video, and allow the remote user to
interact with it.  Also remote playback of messages.  If not (and if it's not
covered by the current document, we need to add this usecase.

Note that there are two variants: one local (local client handles it, which
has more security issues around camera access and pre-approval), and one for
remote recording (after some time with no answer or if not "registered" call
is forwarded to a message server that answers it).  Note that there are
security identity issues here (key chains, etc).


>
>      7. Remote recording (John)  http://www.ietf.org/mail-archive/web/rtcweb/current/msg00472.html
>      8. Emergency access for disabled (Bernard Aboba) http://www.ietf.org/mail-archive/web/rtcweb/current/msg00478.html
>      9. Clue use cases (Roni Even) http://tools.ietf.org/html/draft-ietf-clue-telepresence-use-cases-01
>      10. Rohan red cross (Cullen Jennings); proposed a bit earlier http://www.ietf.org/mail-archive/web/rtcweb/current/msg00323.html
>
> Probably I have missed a few.

I'd add:


11. Remote assistance (ala VNC or RDP) - User is helping another user on
their computer with either view-only or view-with-control, either of just
the browser of the the entire screen.  Computer audio is optionally sent
as well.  They are optionally talking and/or viewing each other while this
is occurring.  They may be transferring files over a reliable data
connection during this session.


Commentary: How often have you talked to your father/mother/brother/etc
and tried to debug their computer problems remotely?  And getting them to
install a specific remote-assistance package, and to use it, and get it to
work through firewalls, can be very painful.  (There are other uses of this
ability to copilot as well, including classroom instruction, distance learning,
etc.)  This use-case enables someone to build a JS app to provide this
functionality.  (Note that for the W3 and browser vendors there will be
significant security issues to resolve.)  I think this is actually a fairly
important use-case.


Additional resulting requirements:

* Need to be able to select a "video" source other than a camera (window or
screen) (W3 issue)

* Need to be able to send multiple video and audio streams from different
sources (probably already covered, mostly W3 issue)

* Need to be able to use a reliable data connection (for mouse/keyboard/etc
control, plus file transfer)


12. Security camera/baby monitor usage - use a persistent or temporary
connection to provide basic security camera operation, including switching
cameras or mics, or with the ability to remotely request review of recent
data recorded.  Should be able to switch to 2-way audio and/or video remotely.


Additional requirements:

* Need to be able to select a "video" source other than a camera (file)
(W3 issue)

* Remote control of camera/mic selection and enabling (W3 issue) - may
require reliable data connection

* May need control from JS over codecs used, at least voice vs audio, etc,
and max video framerate/resolution/bandwidth (W3 issue largely?)


>
>
> E. Opinion as individual
> ===============
> My personal opinion is that we at this stage should focus on the basic use cases, and solve those in a good way. To me that would mean that we should add 3 (to allow different providers) and 4 (if you can’t connect no use case can be supported). I think that these use cases can be added as twists of/extensions to the first use case (Simple Video Communication Service).
>
> In my view it also means that we should add text and requirements for 2 to make sure that the communication capabilites we are adding to the browser is usable in everyday scenarios. Presumable this would lead requirements (e.g. background execution capability) that are transferred to other W3C WGs - not to requirements in the webrtc/rtcweb space.
>
> > From a W3C perspective it could also make sense to add a recording use case (as it seems that other W3C WGs rely on webrtc to provide an API for recording).
>
> The rest of the new proposed use cases, IMO, could be looked into in a second stage when we've established the basics.

I'd very much want to include the "remote assistance" case, and I think the
voicemail cases could be very important in overall acceptance and utility, especially
given the issues over whether someone's machine is running and accepting calls.

Security cam/baby-monitor is less important, but highlights some controls that
we may want to expose to the JS over maximum bitrate/framerate/resolution/etc,
and of course a slew of security issues for W3 to think about.

-- 
Randell Jesup
randell-ietf@jesup.org