Subject: [rtcweb] Proposed text - remote recording use case

From: "Elwell, John" <[email-masked]>
Date: Fri, 9 Sep 2011 18:41:51 +0200

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: [email-masked]
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.

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 09 Sep 2011 10:23:04 -0700

> 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.

Is there some specific need for the use of the words "third party"? I 
think that should be "modem", yet I know that word doesn't work in 
replace as-is. Maybe extend RFC 2198 to indicate the presence of an 
"audio-out" capable of modulation of SSRC media that MAY record. Does 
that hint on something more fair and reusable?

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>    

-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Mon, 12 Sep 2011 01:59:13 +0530

John,

Please let me know whether the updated text works for you:

New requirements:
Fyy1: The browser MUST be able to send in real-time to an another
browser/session recording server(SRS) that are being transmitted to and
received from remote browser.

Ayy1: The web application MUST be able to ask the browser to transmit in
real-time to another browser/session recording server(SRS) that are
being transmitted to and received from remote browser.

Basically I changed "a third party media" to "an another browser/session
recording server (SRS)" because SRS is not required to be third party.
Also, there is a discussion wherein the actual participant is not known
to the browser, so I prefer "browser" rather than "participants".

As I asked in the meeting (but couldn't discuss due to time constraint),
it is possible for browser to do the signaling directly to the SRS
without going through original webserver. The signaling towards
recording is not required to be SIP but it shall be websocket (let
discuss separately). Here, the advantageous in this model is that the
recording signaling hop is reduced to 1 hop (browser to SRS)  from 2
hops (browser to webserver, webserver to SRS).

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf
>Of Elwell, John
>Sent: Friday, September 09, 2011 10:12 PM
>To: [email-masked]
>Subject: [rtcweb] Proposed text - remote recording use case
>
>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.
>
>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

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 12 Sep 2011 10:34:23 +0200

> being transmitted to and received from remote browser.

I still maintain that adding these requirements opens a huge can of 
security and resource utilization worms.

I really think these need to be addressed early before we make this one 
of the mandatory-to-support cases.

Matthew Kaufman

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 12 Sep 2011 10:39:39 +0200

12 sep 2011 kl. 10:34 skrev Matthew Kaufman:

> I still maintain that adding these requirements opens a huge can of security and resource utilization worms.
> 
> I really think these need to be addressed early before we make this one of the mandatory-to-support cases.

Agree. It will be really hard to include this in the rtcweb architecture as a mandatory-to-support case. 

In the cases where "someone else", i.e. not the browser user, wants to control recording, I assume there will always be a media handling server or gateway where recording can happen anyway. Allowing a third-party to initiate duplication of media streams in the browser has huge security impacts.

/O

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 13 Sep 2011 16:18:12 +0200

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.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 13 Sep 2011 14:37:58 +0000

inline...

> received from remote browser.

That doesn't make sense in English - *what* needs to be sent in real-time?  Removing the word "media" broke the meaning.  Also, the media it needs to replicate/fork may not be to/from another "remote browser" - it could be to/from a remote gateway, SIP UA, whatever.  Really what you want to say is to/from a "remote peer".
Same issues/comments go for the next requirement.

> being transmitted to and received from remote browser.

Same as above.

> hops (browser to webserver, webserver to SRS).

Actually, I don't think it is possible for the rtcweb browser to properly do SIPREC, even if it had a SIP stack to do it with.  The reason is the browser doesn't know the full call metadata.  The browser doesn't know the calling/called party info, for example.  Even the javascript itself may not know it, depending on how the application provider does their logic.  They could decide to have some state/logic be handled by the web server, rather than all in the javascript.  For example the javascript may just display a list of friends using aliases or icons, and the web server may be the only one who knows what the friend's AoR/URI actually is for that alias.  

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 13 Sep 2011 16:15:35 +0000

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.

-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 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.
>

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 13 Sep 2011 21:14:42 +0200

> 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 jav…

Correct.

>
> 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.

And I believe that enabling browsers to do that would be a very bad 
idea. That is specifically why the requirement for recording should be 
careful to explain the difference between these two and why one might be 
acceptable while the other not.

Matthew Kaufman

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 14 Sep 2011 07:50:34 +0200

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 13 September 2011 15:38
> To: Ravindran Parthasarathi
> Cc: Elwell, John; <[email-masked]>
> Subject: Re: [rtcweb] Proposed text - remote recording use case
> 
> inline...
> 
> That doesn't make sense in English - *what* needs to be sent 
> in real-time?  Removing the word "media" broke the meaning.  
> Also, the media it needs to replicate/fork may not be to/from 
> another "remote browser" - it could be to/from a remote 
> gateway, SIP UA, whatever.  Really what you want to say is 
> to/from a "remote peer".
[JRE] I agree the modified words don't make sense and would like to stick to the words I proposed at the start of this thread.

> Actually, I don't think it is possible for the rtcweb browser 
> to properly do SIPREC, even if it had a SIP stack to do it 
> with.  The reason is the browser doesn't know the full call 
> metadata.  The browser doesn't know the calling/called party 
> info, for example.  Even the javascript itself may not know 
> it, depending on how the application provider does their 
> logic.  They could decide to have some state/logic be handled 
> by the web server, rather than all in the javascript.  For 
> example the javascript may just display a list of friends 
> using aliases or icons, and the web server may be the only 
> one who knows what the friend's AoR/URI actually is for that alias.  
[JRE] Quite so. Metadata would come from the application, but whether this is server-side or client-side is out of scope for RTC-Web. The important thing is that an application that is able to do the SIP and Metadata part of SIPREC can ask the browser to do the media part.

John

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 14 Sep 2011 07:53:29 +0200

> Sent: 13 September 2011 17:16
> To: Harald Alvestrand; Elwell, John
> Cc: Elwell, John; [email-masked]
> 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?
> 
> 
> > 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 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.
> >> 
> >> 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

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Wed, 14 Sep 2011 11:27:28 +0530

John,

I'm fine with Hadriel proposal of "remote peer" instead "remote browser
or SRS" but not the original wordings.

At this moment, I'm not convinced whether SIPREC SRS will interop with
RTCWeb browser because the signaling protocol is an open item in RTCWeb.
The recording could be done by two websocket from browser wherein one
websocket towards webserver and other towards recorder. How these
entities interact with each other has to be discussed & defined. Please
let me know the reason why this approach may not be followed in RTCWeb.

Thanks
Partha 

>From: Elwell, John [mailto:[email-masked]]
>Sent: Wednesday, September 14, 2011 11:21 AM
>To: Hadriel Kaplan; Ravindran Parthasarathi
>Cc: <[email-masked]>
>Subject: RE: [rtcweb] Proposed text - remote recording use case
>
>
>
>[JRE] I agree the modified words don't make sense and would like to
>stick to the words I proposed at the start of this thread.
>
>>
>> >
>> to transmit in
>[JRE] Quite so. Metadata would come from the application, but whether
>this is server-side or client-side is out of scope for RTC-Web. The
>important thing is that an application that is able to do the SIP and
>Metadata part of SIPREC can ask the browser to do the media part.
>
>John
>
>
>>
>> -hadriel
>>
>>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 14 Sep 2011 09:22:15 +0200

> From: Harald Alvestrand [mailto:[email-masked]] 
> Sent: 13 September 2011 15:18
> To: Elwell, John
> Cc: [email-masked]
[JRE] Yes, in the interests of not holding things up, that would be acceptable. If we decide to promote it at some point to a "must do", we would need to add more text addressing Matthew's concerns.

John

> > 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:

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 15 Sep 2011 17:27:52 +0200

Partha, 

> From: Ravindran Parthasarathi [mailto:[email-masked]] 
> Sent: 14 September 2011 06:57
> To: Elwell, John; Hadriel Kaplan
> Cc: [email-masked]
[JRE] I am not saying it will not work, but I consider this to be outside scope of RTC-Web.

John

> >> > recording signaling hop is reduced to 1 hop (browser to 
> SRS)  from
> 2

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 15 Sep 2011 17:38:27 +0200

On 09/14/11 07:57, Ravindran Parthasarathi wrote:
> entities interact with each other has to be discussed&  defined. Please
My opinion:

If this can be built in JS using the APIs and protocols defined by 
RTCWEB/WEBRTC, there is no need for anything more within these groups.

If it cannot be built using these APIs and protocols, we need to 
consider whether these APIs and protocols need to be extended in order 
to cover this use case.

The detailed building of the application is, in my opinion, out of scope 
for RTCWEB.

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Fri, 16 Sep 2011 03:30:59 +0530

John,

Could you please explain in detail about the reason for two websocket
from browser wherein one towards webserver and another towards recorder
(another webserver) is outside the scope of RTCWeb. Also, I guess that
it would have covered in one of usecase of RTCWeb document already.
AFAIK, there is no restriction on number of websockets from browser.

Thanks
Partha

>Sent: Thursday, September 15, 2011 8:58 PM
>To: Ravindran Parthasarathi; Hadriel Kaplan
>Cc: [email-masked]

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Fri, 16 Sep 2011 03:48:53 +0530

Hi Harlad,

I agree with you in case it is just two socket from JS (app
environment). 

But in this usecase, The websocket towards recorder needs metadata which
is similar to SIPREC metadata
(http://tools.ietf.org/html/draft-ietf-siprec-metadata-04) and also, it
will have the impact on RTP model (RTP translator or mixer) of the
browser (http://tools.ietf.org/id/draft-eckel-siprec-rtp-rec-01.txt).
So, I'm thinking that it is inside the scope of RTCWeb. 

Thanks
Partha

Behalf
>Of Harald Alvestrand
>Sent: Thursday, September 15, 2011 9:08 PM
>To: [email-masked]

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 16 Sep 2011 16:51:14 +0200

RTC-Web is specifying:
- the browser API (W3C); and
- protocols that the browser uses for browser-to-browser communication (IETF).
Any use of WebSockets for communication between JS and elsewhere is not within scope, as far as I understand.

John

> Sent: 15 September 2011 23:01

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 16 Sep 2011 17:24:43 +0200

> - protocols that the browser uses for browser-to-browser communication (IETF).

AFAIK those protocols just cover the media plane, but not the signaling plane.

> Any use of WebSockets for communication between JS and elsewhere is not within scope, as far as I understand.

I agree.

-- 
Iñaki Baz Castillo
<[email-masked]>