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

[Dan York <[e-mail]>]

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:

> 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: 
> 
>> -----Original Message-----
>> From: Dan York [mailto:[e-mail]] 
>> Sent: 23 August 2011 16:23
>> To: Elwell, John
>> Cc: [e-mail]; [e-mail]
>> 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:
>> 
>> 
>> 	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?
> [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
> 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.
> 
>> 
>> 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
>> 
>> 
>> On Aug 23, 2011, at 3:58 AM, Elwell, John wrote:
>> 
>> 
>> 	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: [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.
>> 	_______________________________________________
>> 	rtcweb mailing list
>> 	[e-mail]
>> 	https://www.ietf.org/mailman/listinfo/rtcweb
>> 	
>> 
>> 
>> -- 
>> Dan York, CISSP, Director of Conversations
>> Voxeo Corporation   http://www.voxeo.com  [e-mail]
>> Phone: [phone]  skype: danyork  sip:[e-mail]
>> 
>> Join the Voxeo conversation:
>> Blogs: http://blogs.voxeo.com
>> Twitter: http://twitter.com/voxeo  http://twitter.com/danyork
>> Facebook: http://www.facebook.com/voxeo
>> 
>> 

-- 
Dan York, CISSP, Director of Conversations
Voxeo Corporation   http://www.voxeo.com  [e-mail]
Phone: [phone]  skype: danyork  sip:[e-mail]

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