Re: [rtcweb] Use cases - recording and voicemail

["Elwell, John" <[e-mail]>]

Stefan,

> -----Original Message-----
> From: Stefan Håkansson LK [mailto:[e-mail]] 
> Sent: 19 August 2011 10:50
> To: Elwell, John; [e-mail]; [e-mail]
> Subject: RE: Use cases - recording and voicemail
> 
> John,
> 
> this was a good way sort things up.
> 
> I my view we should definitely support local recording of 
> streams (regardless of if they are generated by local devices 
> or received via RTP), and this could be done in parallel to 
> rendering them or not (up to the app).
> 
> The recorded media should also be possible to render locally 
> (be the source for a video element).
> 
> I'm less sure about that the recorded media should also be an 
> RTP source - couldn't you just as well send the file over and 
> then play it at the remote end?
[JRE] Yes, the file could be streamed across, but there are folks who want it to get across more or less in real time, e.g., where the recorder is performing real-time analytics, perhaps in a contact centre. This is the basis for the work done in the IETF SIPREC WG. The same considerations that require RTP browser-to-browser for RTC-Web also dictate RTP as the transport for sending media to a recorder.

In terms of what impact this would have on the solution, perhaps it would have very little impact. Perhaps it could be treated as two separate sessions:
- one that exchanges audio/video between capture/rendering devices and the remote entity and copies to a local file; and
- one that takes audio/video from the local file and sends it to a remote recorder.
The main requirement then is to be able to read from the local file at the same time as writing to the local file.

John

> 
> Stefan
> ________________________________________
> From: [e-mail] [[e-mail]] On 
> Behalf Of Elwell, John [[e-mail]]
> Sent: Friday, August 19, 2011 9:34 AM
> To: [e-mail]; [e-mail]
> 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: [phone] (office and mobile)
> Email: [e-mail]
> 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: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Randell Jesup
> > Sent: 04 August 2011 16:04
> > To: [e-mail]; [e-mail]
> > 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
> > [e-mail]
> >
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>