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

["Hutton, Andrew" <[e-mail]>]

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
Siemens Enterprise Communications Limited.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.




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

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]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[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