Re: [rtcweb] Proposed text

 

> -----Original Message-----
> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] 
> Sent: 13 September 2011 17:16
> To: Harald Alvestrand; Elwell, John
> Cc: Elwell, John; rtcweb@ietf.org
> Subject: Re: [rtcweb] Proposed text - remote recording use case
> 
> Actually, I think remote recording may already be possible 
> without anything new.
> 
> Draft-ietf-rtcweb-use-cases-and-requirements-04 has a 
> use-case 4.2.7 for "Multiparty video communication", and 
> associated requirements.  All you need for remote recording 
> is the ability for the javascript to create a separate media 
> stream to the recorder (SRS), as if the SRS were a third 
> participant, and fork the user's audio/video into both 
> streams.  The 4.2.7 requirement implies that will be possible.
> 
> What's not handled by that is replicating the received 
> audio/video from the peer into the recording stream to the 
> SRS - i.e., the browser will be able to fork the locally 
> generated media, but not the media received from the peer.  
> For sessions between two rtcweb browsers controlled by the 
> same provider this could still work, since both rtcweb 
> browsers could be told to create streams to the SRS for both 
> halves of media to be recorded. For calls to/from another 
> domain, if one uses SIP between the servers then one could do 
> real SIPREC in a logical SIP B2BUA there.
[JRE] I don't think that is good enough - it should not be necessary to rely on a remote peer to send its media to the recorder, particularly in federation cases. Both directions of media should come from the one peer.

John

> 
> -hadriel
> p.s. the ability for rtcweb browsers to create conf calls by 
> doing half-mixing and using a full mesh of media streams is 
> not normal for SIP, and may be rather tricky to get to work 
> right if the participants are not in the same domain and SIP 
> has to be used between.  Was the intention that such 
> inter-domain cases would require a centralized conf server 
> instead of direct media meshing?
> 
> 
> On Sep 13, 2011, at 10:18 AM, Harald Alvestrand wrote:
> 
> > I like this text for capturing the use case.
> > 
> > I agree with Matthew that it seems to come with some 
> special caveats that we should consider whether we can solve 
> before agreeing that this is an use case we MUST solve - but 
> some of those issues may be issues we will face as a natural 
> consequence of the API proposal anyway.
> > 
> > I suggest that Stefan add it to the use case draft under 
> "use cases considered", so that we have the text in the 
> draft, with a note that the WG has not accepted this as a 
> "must do" use case.
> > 
> > On 09/09/11 18:41, Elwell, John wrote:
> >> On yesterday's call it was agreed to work on text to cover 
> the remote recording use case. Below is text, based on an 
> earlier proposal and subsequent input. I have focused on the 
> main requirement derived from this use case, relating to 
> copying to a different peer connection, and skipped any more 
> detailed requirements concerning possible mixing of the two 
> directions of audio or injecting any tones / announcements.
> >> 
> >> 4.2.yy Remote Session Recording
> >> In this use case, the web application user wishes to 
> record a real-time communication at a remote third party 
> (e.g., a recording device), such that transmitted and 
> received audio, video or other real-time media are 
> transmitted in real-time to the third party. The third party 
> can perform recording, archiving, retrieval, playback, etc., 
> but can also perform real-time analytics on the media. A 
> typical deployment might be in a contact centre. The web 
> application also sends metadata that gives context to the 
> stored media. The web application will ensure that 
> appropriate indications are given to participants so that 
> they are aware of recording.
> >> 
> >> New requirements:
> >> Fyy1: The browser MUST be able to send in real-time to a 
> third party media that are being transmitted to and received 
> from remote participants.
> >> 
> >> Ayy1: The web application MUST be able to ask the browser 
> to transmit in real-time to a third party media that are 
> being transmitted to and received from remote participants.
> >> 
> >> Comments?
> >> 
> >> 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.
> >> 
> >> 
> >> _______________________________________________
> >> 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
> 
>