Re: [rtcweb] Use cases - recording and voicemail

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

Paul,

I agree file might not be the right term. What we need is a way of passing the stream, within the browser, between one session and a second session (in SIPREC terms, between the communication session and the recording session).

John

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> Sent: 19 August 2011 14:08
> To: [e-mail]
> Subject: Re: [rtcweb] Use cases - recording and voicemail
> 
> On 8/19/11 5:49 AM, Stefan Håkansson LK wrote:
> > 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?
> 
> I think discussing this in terms of a "file" is an over 
> simplification.
> While it could be a file, it could also be synthesized, or assembled 
> from pieces, interactively as a result of received media or 
> signaling. 
> In such cases you can't just "send the file".
> 
> Also, sending the file only works if the recipient can always 
> deal with 
> a file equally to receiving an RTP stream. That seems like a 
> burden to 
> levy on all possible recipients. For instance, it would mean that 
> rtcweb:pstn gateways would all require the capability to buffer and 
> playback audio/video files.
> 
> So perhaps what is needed is the concept of a software agent that can 
> take on the role of a local source/sink of media streams.
> 
> 	Thanks,
> 	Paul
> 
> > 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
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>