Subject: [rtcweb] Remote recording - RTC-Web client acting as SIPREC session recording client

From: "Elwell, John" <[email-masked]>
Date: Tue, 23 Aug 2011 09:58:30 +0200

There has been some discussion recently on remote recording, mixed to some extent with discussions on local recording and with mailbox, but I would like to focus on remote recording and try to summarize.

First, some background on the IETF SIPREC WG. This is specifying support for SIP-based session recording, whereby a Session Recording Client (SRC) on the path of a call (communication session) can forward media and metadata to a session recording server (SRS) or recording device. In conventional SIP terms, the SRC can exist at an endpoint of the communication session being recorded (i.e., at a SIP UA), or at a B2BUA that has access to the media as well as the signalling. Very often in a contact centre, there are mandatory requirements for recording some or all communication sessions, and often calls are routed through a B2BUA that also provides the SRC. So in this case there is no responsibility on SIP UAs to support SRC functionality, and no issues of additional bandwidth on the device's access. However, it is anticipated in SIPREC that in some deployments UA-located SRCs will be used. How a UA is organized internally to provide SRC functionality is not standardized.

So the question for RTC-Web is whether a SIP UA implemented as an RTC-Web client can provide SRC functionality, i.e., support remote recording. An RTC-Web SIP UA is implemented by a combination of functionality running on the web server, functionality running in client side script (JS) and functionality embedded in the browser. The amount of functionality needed in the browser and needing to be exposed at the browser API in support of SRC will depend to some extent on how much core functionality goes into the browser, in particular whether the browser implements SIP or not. Some of the functions noted to date include:
- ability to take a copy of streams sent to / received from the remote party and send them, in real-time, to a remote recording device (SRS);
- possible need to mix the copied streams before sending (e.g., mix the sent and received audio streams)
- possible need to use a different codec or other parameters when sending to the SRS;
- possible need to use a different encryption/integrity context when sending to the SRS;
- possible need to insert tones / announcements into the original media path being recorded;
- possible need to support SDP enhancements for indicating media that are being recorded or preferences for which media are being recorded;
- possible need to support SIP enhancements for indicating SRC/SRS capability and recording awareness (if SIP is implemented in browser);
- possible need to support the sending of metadata to the SRS (if SIP is implemented in browser).

Clearly there would be a fairly big hurdle for browsers to support SRC functionality. But without this, RTC-Web clients would not be suitable for use in environments where remote recording is required and calls are not forced through some middlebox that provides SRC functionality.

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: Stefan Håkansson LK <[email-masked]>
Date: Tue, 23 Aug 2011 10:44:51 +0200

Hm.

I must admit that my instinctive reaction when reading this is:

1. Say that SRC and SRS functionality is out of scope for rtcweb/webrtc 
version 1.
2. If someone wants to support this, force media through a middlebox 
(which has all media and can do stuff like inserting beeps, mixing, 
recording, ...).

I'm sure there are other opinions....

Cheers,
Stefan

On 2011-08-23 09:58, Elwell, John wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 23 Aug 2011 15:05:05 +0530

Stefan,

As you expect, I have disagreement for not including this usecase in RTCweb 1.0. My reasoning are as follows:

1) As John pointed out and other folks responded, remote recording has importance in few segments like call centre deployment.

2) RTCweb1.0 solution without considering this usecase may end-up in a non-scalable RTCWeb remote recording solution for ever or break RTCWeb1.0 to meet this architectural need of remote recording. 

3) Based on SIPREC discussion, it is very apparent that short-sighted SIP Endpoint implementation which assumes single session for the end-point are forced to interop with SRS using middle box only . I wish that the same situation does not occur for rtcweb clients.

Thanks
Partha 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Stefan Håkansson LK
>Sent: Tuesday, August 23, 2011 2:15 PM
>To: [email-masked]
>Subject: Re: [rtcweb] Remote recording - RTC-Web client acting as SIPREC
>session recording client
>
>Hm.
>
>> There has been some discussion recently on remote recording, mixed to
>some extent with discussions on local recording and with mailbox, but I
>would like to focus on remote recording and try to summarize.
>>
>> First, some background on the IETF SIPREC WG. This is specifying
>support for SIP-based session recording, whereby a Session Recording
>Client (SRC) on the path of a call (communication session) can forward
>media and metadata to a session recording server (SRS) or recording
>device. In conventional SIP terms, the SRC can exist at an endpoint of
>the communication session being recorded (i.e., at a SIP UA), or at a
>B2BUA that has access to the media as well as the signalling. Very often
>in a contact centre, there are mandatory requirements for recording some
>or all communication sessions, and often calls are routed through a
>B2BUA that also provides the SRC. So in this case there is no
>responsibility on SIP UAs to support SRC functionality, and no issues of
>additional bandwidth on the device's access. However, it is anticipated
>in SIPREC that in some deployments UA-located SRCs will be used. How a
>UA is organized internally to provide SRC functionality is not
>standardized.
>>
>> So the question for RTC-Web is whether a SIP UA implemented as an RTC-
>Web client can provide SRC functionality, i.e., support remote
>recording. An RTC-Web SIP UA is implemented by a combination of
>functionality running on the web server, functionality running in client
>side script (JS) and functionality embedded in the browser. The amount
>of functionality needed in the browser and needing to be exposed at the
>browser API in support of SRC will depend to some extent on how much
>core functionality goes into the browser, in particular whether the
>browser implements SIP or not. Some of the functions noted to date
>include:
>> - ability to take a copy of streams sent to / received from the remote
>party and send them, in real-time, to a remote recording device (SRS);
>> - possible need to support SDP enhancements for indicating media that
>are being recorded or preferences for which media are being recorded;
>> - possible need to support SIP enhancements for indicating SRC/SRS
>capability and recording awareness (if SIP is implemented in browser);
>> Clearly there would be a fairly big hurdle for browsers to support SRC
>functionality. But without this, RTC-Web clients would not be suitable
>for use in environments where remote recording is required and calls are
>not forced through some middlebox that provides SRC functionality.
>>
>> John
>>
>> John Elwell

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Aug 2011 10:08:16 -0400

Thanks John. You did a much more thorough job of explaining than I did.

	Paul

---

From: Dan York <[email-masked]>
Date: Tue, 23 Aug 2011 11:23:17 -0400

John,

Many thanks for the SIPREC background. I have not had the cycles to follow that group and so your note here is extremely helpful. Thank you!

As I read your summary though, I keep hearing "Danger! Danger!" in my brain. I completely agree with this statement of yours:

> Clearly there would be a fairly big hurdle for browsers to support SRC functionality. 

I think it would be a very large hurdle and really takes us back into basically baking a SIP UA into a web browser - and do we REALLY want to go down that road?

If I go back to the charter of this group ( http://tools.ietf.org/wg/rtcweb/charters ) and why I started following it from the start and reading all the traffic, I think we need to focus on how we enable direct communication between web browsers... or between web browsers and servers... but doing so in the most lightweight and easy way possible.  

My interest has been in how we can do real-time communication *without* extensions or plugins.  Reading all of this, it's sounding like either we do need to have a plugin/extension to support SRC capability - or we need to bake a great amount of functionality directly into browsers.  And that in my mind limits the number of browsers that might support all the capabilities of RTCWEB.  

I think that given the aggressive timelines for the working group deliverables (and the market reality that the longer a "standard" solution takes to come out the more developers will explore proprietary solutions), I agree with Stefan that we should put the recording out of scope for RTCWEB 1.0 and focus on getting a solution out there that lets developers start building RTCWEB apps. 

For those environments that need recording (and I *do* understand the call center need), middleboxes can provide a solution today - or some vendors can support the RTCWEB communication and *also* provide a recording capability. Sure, that's not ideal... and yes, we need to make sure that what we do for RTCWEB 1.0 doesn't preclude adding recording to a RTCWEB 2.0...  but we need to get a spec out there that will be useful to the majority of developers and very easy for them to adopt.  

The more complicated we make it - or the more requirements we impose on browsers - the less adoption we'll see.

My 2 cents,
Dan

-- 
Dan York, CISSP, Director of Conversations
Voxeo Corporation   http://www.voxeo.com  [email-masked]
Phone: +1-321-710-9193  skype: danyork  sip:[email-masked]

Join the Voxeo conversation:
Blogs: http://blogs.voxeo.com
Twitter: http://twitter.com/voxeo  http://twitter.com/danyork
Facebook: http://www.facebook.com/voxeo

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 23 Aug 2011 17:37:15 +0200

Dan,

Thanks for your input. I agree with much of what you say. Like Paul, I think it is good to have the discussion, so that we can at least understand whether or not we are going to specify browser support for remote recording and how such a decision has been reached. However, I would like to comment on one point below: 

> From: Dan York [mailto:[email-masked]] 
> Sent: 23 August 2011 16:23
> To: Elwell, John
> Cc: [email-masked]; [email-masked]
> Subject: Re: [rtcweb] Remote recording - RTC-Web client 
> acting as SIPREC session recording client
> 
> John, 
> 
> Many thanks for the SIPREC background. I have not had the 
> cycles to follow that group and so your note here is 
> extremely helpful. Thank you!
> 
> As I read your summary though, I keep hearing "Danger! 
> Danger!" in my brain. I completely agree with this statement of yours:
> 
> 
> I think it would be a very large hurdle and really takes us 
> back into basically baking a SIP UA into a web browser - and 
> do we REALLY want to go down that road?
[JRE] Some people are still talking about SIP in the browser, I believe. But one of the points I was making is that, assuming SIP is NOT in the browser, there is somewhat less that needs to be done to provide browser support for an SRC (the rest would be up to the web application).

John

John Elwell

> 
> If I go back to the charter of this group ( 
> http://tools.ietf.org/wg/rtcweb/charters ) and why I started 
> following it from the start and reading all the traffic, I 
> think we need to focus on how we enable direct communication 
> between web browsers... or between web browsers and 
> servers... but doing so in the most lightweight and easy way 
> possible.  
> 
> My interest has been in how we can do real-time communication 
> *without* extensions or plugins.  Reading all of this, it's 
> sounding like either we do need to have a plugin/extension to 
> support SRC capability - or we need to bake a great amount of 
> functionality directly into browsers.  And that in my mind 
> limits the number of browsers that might support all the 
> capabilities of RTCWEB.  
> 
> I think that given the aggressive timelines for the working 
> group deliverables (and the market reality that the longer a 
> "standard" solution takes to come out the more developers 
> will explore proprietary solutions), I agree with Stefan that 
> we should put the recording out of scope for RTCWEB 1.0 and 
> focus on getting a solution out there that lets developers 
> start building RTCWEB apps. 
> 
> For those environments that need recording (and I *do* 
> understand the call center need), middleboxes can provide a 
> solution today - or some vendors can support the RTCWEB 
> communication and *also* provide a recording capability. 
> Sure, that's not ideal... and yes, we need to make sure that 
> what we do for RTCWEB 1.0 doesn't preclude adding recording 
> to a RTCWEB 2.0...  but we need to get a spec out there that 
> will be useful to the majority of developers and very easy 
> for them to adopt.  
> 
> The more complicated we make it - or the more requirements we 
> impose on browsers - the less adoption we'll see.
> 
> My 2 cents,
> Dan
> 
> 
> 	There has been some discussion recently on remote 
> recording, mixed to some extent with discussions on local 
> recording and with mailbox, but I would like to focus on 
> remote recording and try to summarize.
> 	
> 	First, some background on the IETF SIPREC WG. This is 
> specifying support for SIP-based session recording, whereby a 
> Session Recording Client (SRC) on the path of a call 
> (communication session) can forward media and metadata to a 
> session recording server (SRS) or recording device. In 
> conventional SIP terms, the SRC can exist at an endpoint of 
> the communication session being recorded (i.e., at a SIP UA), 
> or at a B2BUA that has access to the media as well as the 
> signalling. Very often in a contact centre, there are 
> mandatory requirements for recording some or all 
> communication sessions, and often calls are routed through a 
> responsibility on SIP UAs to support SRC functionality, and 
> no issues of additional bandwidth on the device's access. 
> However, it is anticipated in SIPREC that in some deployments 
> UA-located SRCs will be used. How a UA is organized 
> internally to provide SRC functionality is not standardized.
> 	
> 	So the question for RTC-Web is whether a SIP UA 
> implemented as an RTC-Web client can provide SRC 
> functionality, i.e., support remote recording. An RTC-Web SIP 
> UA is implemented by a combination of functionality running 
> on the web server, functionality running in client side 
> script (JS) and functionality embedded in the browser. The 
> amount of functionality needed in the browser and needing to 
> be exposed at the browser API in support of SRC will depend 
> to some extent on how much core functionality goes into the 
> browser, in particular whether the browser implements SIP or 
> not. Some of the functions noted to date include:
> 	- ability to take a copy of streams sent to / received 
> from the remote party and send them, in real-time, to a 
> remote recording device (SRS);
> 	- possible need to mix the copied streams before 
> sending (e.g., mix the sent and received audio streams)
> 	- possible need to support SDP enhancements for 
> indicating media that are being recorded or preferences for 
> which media are being recorded;
> 	- possible need to support SIP enhancements for 
> indicating SRC/SRS capability and recording awareness (if SIP 
> is implemented in browser);
> 	- possible need to support the sending of metadata to 
> the SRS (if SIP is implemented in browser).
> 	
> 	Clearly there would be a fairly big hurdle for browsers 
> to support SRC functionality. But without this, RTC-Web 
> clients would not be suitable for use in environments where 
> remote recording is required and calls are not forced through 
> some middlebox that provides SRC functionality.
> 	
> 	John
> 	
> 	John Elwell

---

From: Olle E Johansson <[email-masked]>
Date: Tue, 23 Aug 2011 17:40:06 +0200

> The more complicated we make it - or the more requirements we impose on browsers - the less adoption we'll see.
Which we've proven with the large amount of RFCs and drafts for SIP.

We need to be very careful here. 

+1 and "like" on Dan's mail.

/O

---

From: Dan York <[email-masked]>
Date: Tue, 23 Aug 2011 11:49:19 -0400

John,

You're welcome... and I agree with you and Paul on the need to have the discussion and to consciously make a choice as to whether to include or not include some functionality.   I also appreciate that you took the time to draft up text for requirements to add to the use cases... it was seeing that new requirement text that made me start violently twitching here in my home office and lured me out of lurking on the list.  :-)

Dan

P.S. And I agree with your point below.

On Aug 23, 2011, at 11:37 AM, Elwell, John wrote:

>> to support SRC functionality. 
>> 
>>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 23 Aug 2011 19:50:53 +0200

Hi,

Also agree that implementing a full SIP Session Recording Client (SRC) as defined by the SIPREC WG in to the browser would be a tall order and would open the flood gates for a lot of other requests for SIP functionality in the browser.

If however SIP is not in the browser then I think it is a useful and interesting test case to look at whether we could build a decomposed SRC with the browser handling the media and the web server handling the signalling. What I heard a number of times at IETF81 is that what people want is to build innovative new applications with a real time media enabled browser and to it seems clear to me we need a browser API which is flexible and enables applications to do clever things with media streams. So exploring some use cases which require the browser to duplicate and copy media streams is a good idea.

Therefore I think we should keep explore the remote recording use case further.

Regards
Andy

Andrew Hutton

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan York
Sent: 23 August 2011 16:49
To: Elwell, John
Cc: [email-masked]; [email-masked]
Subject: Re: [rtcweb] Remote recording - RTC-Web client acting as SIPREC session recording client

John,

Dan

Dan,

-----Original Message-----
From: Dan York [mailto:[email-masked]]
Sent: 23 August 2011 16:23
To: Elwell, John
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Remote recording - RTC-Web client

John,

John

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: [email-masked]<mailto:[email-masked]>
http://www.siemens-enterprise.com/uk/

My 2 cents,
Dan

          - possible need to use a different codec or other
parameters when sending to the SRS;
          - possible need to use a different encryption/integrity
context when sending to the SRS;
          - possible need to insert tones / announcements into
the original media path being recorded;

          John

          John Elwell

          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
          [email-masked]
          https://www.ietf.org/mailman/listinfo/rtcweb

--
Dan York, CISSP, Director of Conversations
Voxeo Corporation   http://www.voxeo.com  [email-masked]<mailto:[email-masked]>
Phone: +1-321-710-9193  skype: danyork  sip:[email-masked]

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 23 Aug 2011 16:38:58 -0400

On 8/23/2011 1:50 PM, Hutton, Andrew wrote:

> ...

> What I heard a number of times at IETF81 is that what people want is 
> to build innovative new applications with a real time media enabled 
> browser and to it seems clear to me we need a browser API which is 
> flexible and enables applications to do clever things with media 
> streams. So exploring some use cases which require the browser to 
> duplicate and copy media streams is a good idea.
Indeed the browser API must be flexible and it must enable 
applications.  Strong ++ on that.

Inasmuch as we, in the IETF, are not really in control of API, to ensure 
its flexibility we can only make the right protocol selection.   To this 
end, the worst thing would be trying to reinvent the wheel.  People have 
been working on SIPREC for more than a year now--would it be not wise on 
our part to take the output of that work?

Overall, even if the browser does not support the full-blown SIP, I 
think it must support some parts of it (REFER and SUBSCRIBE/NOTIFY, for 
one thing) in order to enable flexibility.

A few thousand messages ago, I asked how (asynchronous) notifications 
could be implemented without having SIP in the browser, and I don't 
think we had a sufficient discussion.

Igor

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Wed, 24 Aug 2011 06:27:36 +0530

I agree with Igor.  It will be good in case the discussion in the line
why SIP MUST NOT be used for browser. I guess that the following are not
the reason for not selecting SIP:

1)       Memory usage in browser is not the limiting factor for SIP. I
know of the SIP application which works well in embedded device with
16MB RAM.

2)      In case the idea is to use the simple alternative protocol for
the basic dialog between browser to browser. It is possible for the same
protocol to become as complex as SIP in 5-10 years while adding more
feature or services.  We end-up with two protocol for real-time
communication from IETF and interact through gateways. 

3)      As per IETF recommendation,  standalone application in endpoint
has to use SIP for real-time communication whereas the same application
running in browser has to use RTCWeb recommended protocol. It is tough
for each application to support both protocols or its related
infrastructure to make it work. Or the intention is not to use SIP
anywhere in endpoint?

I'm interested in hearing the reasons for why SIP MUST NOT be used in
browser.

Thanks

Partha

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Igor Faynberg
Sent: Wednesday, August 24, 2011 2:09 AM
To: [email-masked]
Subject: Re: [rtcweb] Remote recording - RTC-Web client acting as SIPREC
session recording client

...

What I heard a number of times at IETF81 is that what people want is to
build innovative new applications with a real time media enabled browser
and to it seems clear to me we need a browser API which is flexible and
enables applications to do clever things with media streams. So
exploring some use cases which require the browser to duplicate and copy
media streams is a good idea. 

Indeed the browser API must be flexible and it must enable applications.
Strong ++ on that.  

Igor

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 24 Aug 2011 00:39:43 -0400

Actually, I don't think that the "must not" decision has ever been made 
by the WG. In fact, two implementation reports from the last meeting 
cited SIP implementation...

I actually thought that the need for supporting SIP in the browser was 
well articulated in Quebec...

Igor

On 8/23/2011 8:57 PM, Ravindran Parthasarathi wrote:
> why SIP MUST NOT be used for browser. I guess that the following are 
> not the reason for not selecting SIP:
>
> 1) Memory usage in browser is not the limiting factor for SIP. I know 
> of the SIP application which works well in embedded device with 16MB RAM.
>
> 2)In case the idea is to use the simple alternative protocol for the 
> basic dialog between browser to browser. It is possible for the same 
> 3)As per IETF recommendation,  standalone application in endpoint has 
> to use SIP for real-time communication whereas the same application 
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Igor Faynberg
> *Sent:* Wednesday, August 24, 2011 2:09 AM
> *To:* [email-masked]
> *Subject:* Re: [rtcweb] Remote recording - RTC-Web client acting as 
> SIPREC session recording client
>
>
>
> Inasmuch as we, in the IETF, are not really in control of API, to 
> ensure its flexibility we can only make the right protocol 
> selection.   To this end, the worst thing would be trying to reinvent 
> the wheel.  People have been working on SIPREC for more than a year 
> now--would it be not wise on our part to take the output of that work?
>
> think it must support some parts of it (REFER and SUBSCRIBE/NOTIFY, 
> for one thing) in order to enable flexibility.
>

---

From: Randell Jesup <[email-masked]>
Date: Wed, 24 Aug 2011 03:43:23 -0400

On 8/23/2011 1:50 PM, Hutton, Andrew wrote:

> Hi,
>   
> Also agree that implementing a full SIP Session Recording Client (SRC) as defined ]
> by the SIPREC WG in to the browser would be a tall order and would open the flood
> gates for a lot of other requests for SIP functionality in the browser.

Agreed

> If however SIP is not in the browser then I think it is a useful and interesting test case
> to look at whether we could build a decomposed SRC with the browser handling the
> media and the web server handling the signalling. What I heard a number of times at
> IETF81 is that what people want is to build innovative new applications with a real time
> media enabled browser and to it seems clear to me we need a browser API which is
> flexible and enables applications to do clever things with media streams. So exploring
> some use cases which require the browser to duplicate and copy media streams is a good idea.
>   

My personal (not Mozilla's) opinion is that SIPREC-style recording is 
out-of-scope,
and would be handled in this context by a webrtc-B2BUA (i.e. something 
that sits on the
signalling and media paths), or something that interacts directly with 
the app.

What I do want to consider for in-scope are local recording options.  
This can cover the "local
answering machine" case, but also "I want to record my call with Dad", 
"I want to record
my team's chatter in the game", "I want to interview someone for 
genealogy research", etc, etc.
Yes, these can be done (poorly) by using some external app to capture 
the screen and
speaker/mic audio - I don't consider that a replacement for local recording.

Local recording is far less problematical protocol-wise than SIPREC, and 
doesn't require
mandating SIP.

-- 
Randell Jesup
[email-masked]

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 24 Aug 2011 10:23:36 +0200

Randell, 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Randell Jesup
> Sent: 24 August 2011 08:43
> To: [email-masked]
[JRE] I am not advocating supporting SIP in the browser just for the purpose of supporting SIPREC SRC functionality. What I am saying is that if the browser is concerned only with media aspects, then only the media aspects of SRC functionality need to be considered in the browser (e.g., copying the media streams). On the other hand, if, for other reasons, SIP is implemented in the browser, it would require additional enhancements to support SIP aspects of SIPREC SRC functionality.

John

John Elwell

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 24 Aug 2011 11:32:08 +0200

Randell,

I would like to make it clear that I am not saying that SIPREC is a reason for putting SIP in the browser but if SIP is not in the browser then we need to be able to build applications like a SIPREC SRC using a combination of the browser and the web application. 

Therefore I do think that the remote recording case is a useful use case to explore and should not be out of scope as it helps us understand the type of media handling requirements that the browser needs to support innovative applications.  

Of course as John stated if a decision is made to put SIP in the browser then there would be additional browser and API requirements to support SIPREC.

Regards
Andy

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Elwell, John
> Sent: 24 August 2011 09:24
> To: Randell Jesup; [email-masked]
> [JRE] I am not advocating supporting SIP in the browser just for the
> purpose of supporting SIPREC SRC functionality. What I am saying is
> that if the browser is concerned only with media aspects, then only the
> media aspects of SRC functionality need to be considered in the browser
> (e.g., copying the media streams). On the other hand, if, for other
> reasons, SIP is implemented in the browser, it would require additional
> enhancements to support SIP aspects of SIPREC SRC functionality.
> 
> John
> 
> John Elwell

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 24 Aug 2011 14:04:08 +0200

> for one thing) in order to enable flexibility.

I would like to focus on the functionality you think we need for this 
flexibility - if we really need it, I would like to capture it in an use 
case; if it's not vitally needed, I would like to leave it for further work.

I don't know what it would mean to support SUBSCRIBE/NOTIFY without 
supporting SIP. I'm not sure I want to have that discussion - it seems 
to me that some applications will require presence and subscription to 
presence, but that little of this has to be built into the browser; the 
Gmail chat function, which indeed exposes presence and subscription, has 
no browser component at all.

> think we had a sufficient discussion.

have you absorbed this?

http://dev.w3.org/2006/webapi/WebNotifications/publish/

"Notification" is not a term that can be used without context - it means 
very many different things to different people. So one reason why you 
did not get sufficient discussion might be that we didn't have a shared 
understanding of what you were asking.

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 24 Aug 2011 08:15:14 -0700

On 08/24/2011 12:43 AM, Randell Jesup wrote:
>> streams. So exploring
> Local recording is far less problematical protocol-wise than SIPREC, 
> and doesn't require
> mandating SIP.
>

Real-Time systems still imply static content. The source of that static 
content may be directly from such cases above, from client protocols, or 
from servers. How the capture is of static content done and distributed 
affects overall performance, yet that capture is useless to others in 
public cases if it packs credentials; we are redundancy aware.

Consider the blind user in 3D world (or earthquake survivor that NEEDS 
updated and accessible haptic maps), we shouldn't have to override 
SIP/vox-mixer or continue to call them ghosts in the machine to the 
non-blind. The word "incognito" (used instead) may seem like an 
evolutionary step forward for inclusion of such "accessibility" modes 
where before implementers thought the famous-dazzled words had no use. 
(Echo-location/sonar-simulation... anything but mere "ghosts" that pass 
through virtual walls because they can see them.)

Example: "This audio stream *beep* is in incognito mode while *beep* 
search and rescue is underway *beep*." If there is no emergency (or 
eavesdrop) then the beeps aren't mandatory in incognito usage.

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

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 24 Aug 2011 12:43:48 -0400

On 8/24/2011 8:04 AM, Harald Alvestrand wrote:
> flexibility - if we really need it, I would like to capture it in an 
> use case; if it's not vitally needed, I would like to leave it for 
> further work.

I agree. A written use case is a must and it is the first thing to do. 
The ball is in my yard.
> supporting SIP. 

To me, that would mean supporting only REGISTER, SUBSCRIBE/NOTIFY, and 
REFER.

> I'm not sure I want to have that discussion - it seems to me that some 
> applications will require presence and subscription to presence, but 
> that little of this has to be built into the browser; the Gmail chat 
> function, which indeed exposes presence and subscription, has no 
> browser component at all.
>

There is a huge SIP-based legacy out there.  For the case where the 
browser is the de-facto OS on an Internet appliance, applications will 
need to be re-written to rely on WebRTC API and rely on RTCWeb 
protocol.  The question is whether SIP client can be efficiently 
implemented without the browser taking care of some critical pieces.  (I 
don't know the answer.)  This is what has been the gist of my intervention.

> "Notification" is not a term that can be used without context - it 
> means very many different things to different people. So one reason 
> why you did not get sufficient discussion might be that we didn't have 
> a shared understanding of what you were asking.

I will need to read this. Thanks for the pointer!

Igor

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Aug 2011 15:06:54 -0400

> Of course as John stated if a decision is made to put SIP in the browser then there would be additional browser and API requirements to support SIPREC.

I agree with John and Andrew.

Certainly it is possible to punt and say that if you want recording then 
you need to insert a B2BUA that is in the media path and that serves as 
the SRC. But before deciding that is "the story" for recording with 
RTCWEB, it would be good to understand the implications of that approach.

Since this is RTCWEB, I guess we can assume that there is a web server 
interacting with a browser. The browser will provide one end to some 
media streams. There will be another end to those media streams, which 
might be in another browser talking to the same web server, or the web 
server might have those media streams attached to a sip session. In some 
of the cases of interest, the web server won't itself ever touch the 
actual media.

If the web server wants to record the media, it needs to get an SRC into 
the signaling and media paths. If the session is already going to a sip 
server, then its probably not to hard to integrate SRC functionality 
there or juggle the signaling paths to involve a free standing SRC into 
the call path.

But if the web server is orchestrating media streams between browsers 
talking to it, without any sip, then adding recording will be more 
complex. It may need to pull in a sip server that can be an SRC, reroute 
the media through it, etc. Its not evident to me if this would be 
straightforward or not. I suspect not. It would be good to understand 
what would need to be done.

As John and/or Andrew mentioned, it could be advantageous if there were 
primitives by which the JavaScript in the browser had simple ways to 
fork the media and direct it different ways. That could eliminate the 
need to perturb the normal media path in order to do recording.

	Thanks,
	Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 25 Aug 2011 14:01:34 +0200

On 08/24/11 21:06, Paul Kyzivat wrote:
>> I would like to make it clear that I am not saying that SIPREC is a 
>> reason for putting SIP in the browser but if SIP is not in the 
>> browser then we need to be able to build applications like a SIPREC 
>> SRC using a combination of the browser and the web application.
>>
>> Therefore I do think that the remote recording case is a useful use 
>> case to explore and should not be out of scope as it helps us 
>> understand the type of media handling requirements that the browser 
>> needs to support innovative applications.
>>
>> Of course as John stated if a decision is made to put SIP in the 
>> browser then there would be additional browser and API requirements 
>> to support SIPREC.
>
> Certainly it is possible to punt and say that if you want recording 
> then you need to insert a B2BUA that is in the media path and that 
> serves as the SRC. But before deciding that is "the story" for 
> recording with RTCWEB, it would be good to understand the implications 
> of that approach.
>
> server might have those media streams attached to a sip session. In 
> some of the cases of interest, the web server won't itself ever touch 
> the actual media.
>
> If the web server wants to record the media, it needs to get an SRC 
> into the signaling and media paths. If the session is already going to 
> a sip server, then its probably not to hard to integrate SRC 
> functionality there or juggle the signaling paths to involve a free 
> standing SRC into the call path.
>
> complex. It may need to pull in a sip server that can be an SRC, 
> reroute the media through it, etc. Its not evident to me if this would 
> be straightforward or not. I suspect not. It would be good to 
> understand what would need to be done.
>
> As John and/or Andrew mentioned, it could be advantageous if there 
> were primitives by which the JavaScript in the browser had simple ways 
> to fork the media and direct it different ways. That could eliminate 
> the need to perturb the normal media path in order to do recording.
If we can get the signalling part done through some channel that doesn't 
touch the RTCWEB API, it may be enough to say something like:

The API MUST allow the application to specify that a copy of a media 
stream (incoming or outgoing) is sent out to some other correspondent.

In PeerConnection API terms, that means that some construct like this 
should work:

    mainConn = new PeerConnection(...)
<connect mainConn to remote participant, producing remoteStream and 
localStream>
    recorderConn = new PeerConnection(...)
<connect recorderConn to remote recorder>
    recorderConn.addStream(remoteStream)
    recorderConn.addStream(localStream)

The important part of this, implementation-wise, is that one stream 
needs to be able to have several destinations. What that means for codec 
negotiations, transcoding-or-not and so on may perhaps best be kept 
under the covers.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 25 Aug 2011 14:51:23 +0200

> [mailto:[email-masked]] On Behalf Of Harald Alvestrand
> Sent: 25 August 2011 13:02
> To: [email-masked]
[JRE] This is the essential part of what I was trying to get across when I originally proposed text for the use cases document. I reproduce it below, with a slight change to refer to a third party rather than a recording device:
===================
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. For a given medium, the two directions of transmission can be transmitted together (mixed) or separately. The web application also sends metadata that gives context to the stored media.

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 and, in the case of audio at least, ask for the two directions of transmission to be transmitted to the remote recording device mixed or separately.
====================

I think it desirable that the application have control over whether to send mixed or unmixed, but we can certainly discuss that. It also has implications for the RTP model, because mixing implies an RTP mixer or endpoint model, rather than just relaying RTP packets. Other aspects such as whether a different security context is needed will also have impact.

> negotiations, transcoding-or-not and so on may perhaps best be kept 
[JRE] By "under covers", I assume you mean not exposed at the API. That might be sufficient, but the implications need thinking about.

John

> >>> Registered office: Brickhill Street, Willen Lake, Milton 
> Keynes, MK15
> >>> 0DJ.
> >>> Siemens Enterprise Communications Limited is a Trademark 
> Licensee of
> >>> Siemens AG.
> >>>
> >>>
> >>>>
> >>>> -- 
> >>>> Randell Jesup
> >>>> [email-masked]
> >>>>

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 25 Aug 2011 10:14:05 -0700

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

This is a bad idea.

> 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

Yes. It should be possible for the browser to send two copies of the 
same media to two different places, possibly even with different encoders.

>   and received from remote participants

But this is a bad idea. Providing APIs that let a browser send audio 
that is being received from the other end to a third party open several 
different cans of worms simultaneously. One is that there's now another 
path by which a user's media may be sent, possibly without the same 
security constraints, without their knowledge. Sure, a B2BUA can do this 
as well, but it makes doing the wrong thing easier.

The bigger issue is that this essentially allows you to use a browser as 
a media relay. This will be objected to in corporate (and some 
education) environments where there are sound reasons for disallowing 
user applications to take advantage of a high-bandwidth connection to 
relay media for third parties. It also may result in unexpected resource 
consumption on mobile platforms, where the user is paying in bandwidth 
charges and battery life to relay media for a third party. And unless 
implemented carefully, it can lead to relaying that is very unexpected 
(a banner ad that doesn't ask for permission to use your camera and 
microphone but does relay media for a third party while running).

Not to mention all the protocol-level implications of being an RTP 
mixer, if we're trying to stay true to that particular choice of protocols.

Matthew Kaufman

---

From: Dzonatas Sol <[email-masked]>
Date: Thu, 25 Aug 2011 11:08:39 -0700

On 08/25/2011 10:14 AM, Matthew Kaufman wrote:
>> 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.
>
> This is a bad idea.
>
>> 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
>
> that is being received from the other end to a third party open 
> several different cans of worms simultaneously. One is that there's 
> now another path by which a user's media may be sent, possibly without 
> the same security constraints, without their knowledge. Sure, a B2BUA 
> can do this as well, but it makes doing the wrong thing easier.
>
> The bigger issue is that this essentially allows you to use a browser 
> as a media relay.

Or, ... picture in picture capability.

> This will be objected to in corporate (and some education) 
> environments where there are sound reasons for disallowing user 
> applications to take advantage of a high-bandwidth connection to relay 
> media for third parties. It also may result in unexpected resource 

The internet does not end at hyper-commercials over your regularly 
broadcasted network series.

Maybe browsers should be aware of the ads in prime schedules; pinpoint 
that junction.

> mixer, if we're trying to stay true to that particular choice of 

My tone-deafness still desires "crystal-clear auido" (above 192Kbps per 
speaker), yet the browser narrowed that down to 192Kbps per stream and 
then that divides furthers into only some fraction per speaker. This has 
been hell with dysfunctional lectures due to sound quality, especially 
when ad-streams appear after links of interest activate.

Each speaker needs it's own IPv6 address, so we should imagine the 
browser provided by the speaker device, and paravirtualize for multiple 
speakers.

Oh the days of elementary schools that use any speaker as two way 
communication seems almost over.

--

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Thu, 25 Aug 2011 23:59:30 +0530

Matthew,

Please read inline.

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On
Behalf
>Of Dzonatas Sol
>Sent: Thursday, August 25, 2011 11:39 PM
>To: [email-masked]
[Partha] Please provide good idea if you have any.

>> can do this as well, but it makes doing the wrong thing easier.
[Partha] In case your concern is "security consideration", let us work
for it to solve the security issues. Please specific the list of
security concerns related to this.

>> The bigger issue is that this essentially allows you to use a browser
[Partha] why it is issue?
>> media for third parties. 
[Partha] It is just a policy mechanism within the particular corporate
or education environment. Of course, any real-time application will
undergo the same policy constraints. For example, I know of couple of
corporate which does not permit Skype audio application to execute
within the corporate because it consumes lot of bandwidth. IMO, the
bandwidth consumption should not be stopping factor for adding the
requirement.

It also may result in unexpected resource
>> microphone but does relay media for a third party while running).
[Partha] Same banner ad may send stream from your camera and microphone
when you are not ask for it as it is malicious script. I agree that you
concern is related to security in browser but your concern is not
related to recording requirement. Please clarify in case I'm missing
something.

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Thu, 25 Aug 2011 11:50:43 -0700

> different cans of worms simultaneously. One is that there's now another

The currently proposed MediaStream Processing API 
(http://hg.mozilla.org/users/rocallahan_mozilla.com/specs/raw-file/tip/StreamProcessing/StreamProcessing.html) 
essentially allows exactly this (including mixing). It doesn't make any 
distinction about whether the source of a MediaStream is a local camera, 
a <video> tag, or a remote stream from a PeerConnection object. So if 
you want to prevent this kind of thing, you need to have an active 
method of doing so, because by default the API will allow it.

> mixer, if we're trying to stay true to that particular choice of protocols.

That's a good point, and it's important to think about what the 
implications of those are, especially for a ProcessedMediaStream. This 
is not something I, personally, have thought all the way through yet.

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Fri, 26 Aug 2011 00:28:09 +0530

John,

I like remote recording requirement. IMO, few changes may be required.

In SIPREC architecture, decomposed SRC with signaling handling in one
physical device (webserver in RTCWeb) and media handling in another
physical device(browser in RTCWeb) is possible but the communication
protocol between signaling server (webserver) and media server (browser)
is outside the scope of SIPREC. I agree that IETF Megaco (H.248) or IETF
Mediactrl of or equivalent proprietary mechanism between webserver &
browser will serve the purpose. IMO, it is better to spelt out
explicitly protocol mechanism between webserver & browser if this
architecture is chosen.

Actually, I thought of using browser as SIP UA & SRC which is not
consume more bandwidth compare to browser acts as media server because
number of signaling message compare to media messages are very low. I'm
discussing SIP UA based architecture because SIP as a protocol choice is
an open item in RTCWeb
(http://www.ietf.org/mail-archive/web/rtcweb/current/msg00730.html)

Thanks
Partha

Behalf
>Of Elwell, John
>Sent: Thursday, August 25, 2011 6:21 PM
>To: Harald Alvestrand; [email-masked]
>[JRE] This is the essential part of what I was trying to get across
when
>I originally proposed text for the use cases document. I reproduce it
>below, with a slight change to refer to a third party rather than a
>recording device:
>===================
>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. For a given medium, the two directions of transmission
>can be transmitted together (mixed) or separately. The web application
>also sends metadata that gives context to the stored media.
>
>New requirements:
in
>real-time to a third party media that are being transmitted to and
>received from remote participants and, in the case of audio at least,
>ask for the two directions of transmission to be transmitted to the
>remote recording device mixed or separately.
>====================
>
>I think it desirable that the application have control over whether to
>send mixed or unmixed, but we can certainly discuss that. It also has
>implications for the RTP model, because mixing implies an RTP mixer or
>endpoint model, rather than just relaying RTP packets. Other aspects
>such as whether a different security context is needed will also have
>impact.
>
>>
>[JRE] By "under covers", I assume you mean not exposed at the API. That
>might be sufficient, but the implications need thinking about.
>
>John
>
>> >
>> >     Thanks,
>> >     Paul
>> >
>> >> Regards
>> >> Andy
>> >>
>> >>
>> >>

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Fri, 26 Aug 2011 00:37:30 +0530

Hi Timothy,

In principle, mixing is not required to be done by browser because lot
of real-time media analytical tool will be interested in un-mixed media
stream. Browser shall act as RTP translator or RTP end-point to meet the
requirement of recording and You may wish to look into Real-time
Transport Protocol (RTP) Recommendations for SIPREC draft
(https://datatracker.ietf.org/doc/draft-eckel-siprec-rtp-rec/). 

Thanks
Partha

Behalf
>Of Timothy B. Terriberry
>Sent: Friday, August 26, 2011 12:21 AM
>Cc: [email-masked]
>several
>(http://hg.mozilla.org/users/rocallahan_mozilla.com/specs/raw-
>file/tip/StreamProcessing/StreamProcessing.html)

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 25 Aug 2011 14:18:18 -0700

> [Partha] Please provide good idea if you have any.

Remove the part of the requirement that a browser be able to send to a 
third party media that is being received from anywhere but the 
microphone and camera.

> security concerns related to this.

The primary security concern is that it allows for untrusted endpoints 
(browsers) to be trivially manipulated into sending data they receive 
onward. This is worse than manipulating my local browser, because I can 
at least observe the operation of my local browser (how much traffic it 
sends, what connections are brought up, etc.).

> [Partha] why it is issue?

I already enumerated this in my previous email. For some examples:

1. Browser in a high-upload-bandwidth environment (like a corporation or 
university) will be used to relay media for many other participants who 
do not have sufficient bandwidth, transferring the cost from the service 
provider to users in those environments.

2. Browser in an expensive-upload-bandwidth environment (metered 
billing) may relay media without its knowledge, increasing the bandwidth 
bill.

3. Mobile browser may relay media without its knowledge, decreasing 
battery life, possibly reaching provider bandwidth caps or charges for 
metered bandwidth.

> bandwidth consumption should not be stopping factor for adding the

Do you really want certain web browsers banned from the same 
environments because of the same concerns?

Getting ubiquitous deployment will require complying with norms about 
what a browser does and doesn't do. Right now one of the things it 
*doesn't* do is relay media unexpectedly.

> when you are not ask for it as it is malicious script.

Disagree. These will cause your camera and microphone to be accessed, 
which will cause a permission dialog to appear. ALSO, there is no 
financial benefit to causing your own media to be sent when you're not 
on a call (even if it was possible) but a huge financial benefit to use 
nodes with excess bandwidth as relays.

>   I agree that you

It is related to being able to command a browser to send media *that it 
is receiving* to another place. I have no problem with a call from A to 
B being recording by having A send a copy of its media to C and B send a 
copy of its media to C. But recording should not be accomplished by 
having B send a copy of its media *and what it receives from A* to C.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 25 Aug 2011 14:19:45 -0700

On 8/25/2011 11:50 AM, Timothy B. Terriberry wrote:
> essentially allows exactly this (including mixing). It doesn't make 
> any distinction about whether the source of a MediaStream is a local 
> camera, a <video> tag, or a remote stream from a PeerConnection 
> object. So if you want to prevent this kind of thing, you need to have 
> an active method of doing so, because by default the API will allow it.

I think you need to seriously consider the security implications here. 
Any media that originates from somewhere other than a local camera that 
has given permission or a local microphone that has given permission 
needs to be marked as not sendable elsewhere.
> is not something I, personally, have thought all the way through yet.

Agree, though less of an issue if it isn't possible.

Matthew Kaufman

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 25 Aug 2011 15:33:07 -0700

> >> different cans of worms simultaneously.

> needs to be marked as not sendable elsewhere.

[BA] Right.  As an example, the ability to send pre-recorded audio/video within an emergency call could be used to launch "swatting" attacks with frightening realism.

---

From: "Robert O'Callahan" <[email-masked]>
Date: Fri, 26 Aug 2011 17:13:14 +1200

On Fri, Aug 26, 2011 at 9:19 AM, Matthew Kaufman
<[email-masked]>wrote:

>> The currently proposed MediaStream Processing API (
>> http://hg.mozilla.org/users/**rocallahan_mozilla.com/specs/**
>> raw-file/tip/StreamProcessing/**StreamProcessing.html<http://hg.mozilla.org/users/rocallahan_mozilla.com/specs/raw-file/tip/StreamProcessing/StreamProcessing.html>)
>> distinction about whether the source of a MediaStream is a local camera, a
>> <video> tag, or a remote stream from a PeerConnection object. So if you want
>> to prevent this kind of thing, you need to have an active method of doing
>> so, because by default the API will allow it.
>>
>
> I think you need to seriously consider the security implications here. Any
> media that originates from somewhere other than a local camera that has
> given permission or a local microphone that has given permission needs to be
> marked as not sendable elsewhere.

We could do that on top of the above API, e.g. by having a PeerConnection
examine the stream graph to determine whether a MediaStream comes directly
from a local sensor.

However, such a restriction would prevent many useful applications and does
not solve the security problems that arise from a malicious Web app setting
up a connection between you and the PSTN. If that can happen, you're in all
kinds of trouble whether the app can control the contents of your outgoing
stream or not.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]

---

From: "Robert O'Callahan" <[email-masked]>
Date: Fri, 26 Aug 2011 17:25:43 +1200

On Fri, Aug 26, 2011 at 9:18 AM, Matthew Kaufman
<[email-masked]>wrote:

> Getting ubiquitous deployment will require complying with norms about what
> a browser does and doesn't do. Right now one of the things it *doesn't* do
> is relay media unexpectedly.

Browsers *do* consume arbitrary quantities of downstream bandwidth, and
sometimes upstream bandwidth too. Opera even built BitTorrent into their
browser. Most "browsers don't do X" norms have already fallen by the
wayside. "Browsers don't act as relays" will too.

Given browsers are general-purpose application platforms, it makes more
sense to ban specific Web sites than browsers if you're worried about
excessive bandwidth usage.

Rob

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 26 Aug 2011 09:20:44 +0200

> From: Matthew Kaufman [mailto:[email-masked]] 
> Sent: 25 August 2011 18:14
> To: Elwell, John
> Cc: Harald Alvestrand; [email-masked]
> > 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.
> 
> This is a bad idea.
> 
> > 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
> 
[JRE] I would assume it would be possible for an application to take previously received media from a remote endpoint and use that as the source for sending to a third party. Will there be anything to stop the application doing that? For example, would there be constraints in place to ensure that the source of media sent is an original source (microphone, camera), as opposed to a file, say? I hope not, because this would prevent me sending a pre-recorded announcement to callers, e.g., when I am not present in person.

I don't have a particular preference whether it is the browser or the application doing the relaying, provided it can be more or less in real-time.

> One is that there's 
> now another 
[JRE] There are regulations in most places that require a user to be notified if a conversation is being recorded. I don't believe it is possible to enforce such regulations technically or prevent recording in the absence of such notifications.

> relay media for third parties. 
[JRE] In such corporate environments, where they want recording, they could do it centrally, thereby forcing all media through a middlebox. Doing it at the endpoint removes the need for that middlebox.

> charges and battery life to relay media for a third party. 
[JRE] Indeed, so in this sort of environment you wouldn't want to use this capability, and if recording is required it would need to be done from a middlebox.

> And unless 
[JRE] Perhaps permission is needed to relay media from a third party, and likewise to relay information from a local file, etc..

> mixer, if we're trying to stay true to that particular choice 
[JRE] Even if you do mixing (which helps save uplink bandwidth), you are not forced to use the RTP mixer model, you could use the endpoint model. So each PeerConnection would use RTP/RTCP in the normal manner, without interacting with the other one.

John

John Elwell