RE: Use cases - recording and voicemail

John,

I was just uploading an updated version of the use case doc when receiving this, so it is not taken into account in that version.

Stefan
________________________________________
From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Elwell, John [john.elwell@siemens-enterprise.com]
Sent: Friday, August 19, 2011 9:34 AM
To: rtcweb@ietf.org; public-webrtc@w3.org
Subject: [rtcweb] Use cases - recording and voicemail

Sorry for lateness catching up on this thread.

I did indeed propose recording use cases. I see that Randell has applied that to mail (voicemail / videomail) use cases. I would like to try to provide some separation here.

The recording use cases I had in mind were cases where audio/video are captured/rendered locally (through camera/mic/display/speaker) and IN ADDITION are recorded, either locally or remotely. I tend to think of voicemail/videomail as being a replacement for local capture/rendering, or to put it another way, the storage device acts as the capture/rendering device. So in the voicemail/videomail case, recording is INSTEAD OF conventional capture/rendering.

Voicemail/videomail can be local or remote. In the remote case, the inbound call is diverted to a remote mailbox device. This is a signalling plane matter, and outside the scope of RTC-Web, I believe.

So the interesting case is local voicemail/videomail. It simply means that a mailboxes or files replace the conventional capture rendering devices. So received audio and video can be sent to files, and files can be used as the source of prompts or other information to be fed back to a caller. The basic requirement seems to be to use files as sources and sinks of media sent/received over RTP. One additional requirement is some means by which the caller can control the mailbox - this is conventionally done by DTMF or voice recognition - in fact these are the only methods available when a call comes from PSTN. So this could also lead to a requirement for receiving DTMF.

Local recording, on the other hand, means that media captured from local devices and sent via RTP and media received via RTP and rendered at local devices are also copied to local files.

Remote recording means that media captured from local devices and sent via RTP and media received via RTP and rendered at local devices are also sent via RTP to a remote recording device.

Basically, all these use cases, if we choose to progress them, have a general impact on requirements - some sort of flexibility in terms of where media is sourced and sunk, including the ability to use a file as a source/sink and the ability to have multiple sinks. It seems that a well chosen API architecture could accommodate these, but leaving these requirements until later might mean that the chosen API architecture is not sufficiently flexible to accommodate these requirements later. DTMF reception, if we decide we need it, would be a separate requirement.

So I would welcome feedback on which of these use cases are interesting (I have already heard some support for recording use cases), and I could propose text if necessary.

John

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: john.elwell@siemens-enterprise.com
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.


> -----Original Message-----
> From: rtcweb-bounces@ietf.org
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Randell Jesup
> Sent: 04 August 2011 16:04
> To: rtcweb@ietf.org; public-webrtc@w3.org
> Subject: Re: [rtcweb] Use cases: summary of status
>
> 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
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

Received on Friday, 19 August 2011 08:11:29 UTC