Re: [dispatch] Charter proposal: Session Recording Protocol

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

Hi Scott,

I agree that the architecture you described with no middle boxes should be considered and included in the architecture draft.

I think the result of today's Dispatch meeting is that a new WG will be formed which I think is probably the best way forward because session recording is much more than a call control feature which is what I believe BLISS is chartered for.

Regards
Andy



>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]] On Behalf Of Scott Lawrence
>Sent: 09 November 2009 15:01
>To: Vijay K. Gurbani
>Cc: [e-mail]; rai-ads
>Subject: Re: [dispatch] Charter proposal: Session Recording Protocol
>
>On Mon, 2009-09-21 at 08:33 -0500, Vijay K. Gurbani wrote:
>> Hi: The following charter proposal is a continuation of the
>> work presented on the same topic (SIP Session Recording)
>> at the Stockholm IETF.
>>
>> Regards,
>>
>> The Session Recording Protocol (SRP) working group is chartered to
>> define a SIP-based protocol for controlling a session
>(media) recorder.
>>
>> Session recording is a critical requirement in many business
>> communications environments such as call centers and
>financial trading
>> floors.  In some of these environments, all calls must be
>recorded for
>> regulatory and compliance reasons.  In others, calls may be
>recorded for
>> quality control, business analytics, or consumer protection.
> Recording
>> is typically done by sending a copy of the media to the recording
>> devices.  The working group will produce a specification for
>a protocol
>> that will manage delivery of media from an end-point that originates
>> media or that has access to it to a recording device. PBX
>and recording
>> vendors today implement proprietary, incompatible mechanisms to
>> facilitate recording. A standard protocol will reduce the
>complexity and
>> cost of providing such recording services.
>>
>> The Session Recording problem presents certain unique
>requirements that
>> are not addressed in the current SIP protocol specification. These
>> include requirements such as the need for a distinction between the
>> session that is being recorded versus the session that has been
>> established for recording.
>
>I'd like to register my support for this work.  I think that the draft
>does a good job laying out the requirements, and that interoperable
>solutions to these problems would be of benefit to everyone.
>
>I would like to have architectures considered that don't rely on a
>middlebox of any kind for this, with dataflows like:
>
>
> +-------------+                   SIP
>+-------------+
> |             |<------------------------------------------->|
>            |
> |             |                                             |
>            |
> |     UA-B    |<---------+                          +------>|
>    UA-C    |
> |             |          | RTP                  RTP |       |
>            |
> +-------------+          |    +--------------+      |
>+-------------+
>    |                     |    |   Recorder   |      |
>    | Recording Control   +--->|     (RS)     |<-----+
>    | Call Metadata events     |              |
>    +------------------------->+--------------+
>           (SIP)
>
>I won't be able to participate even remotely during the
>DISPATCH session
>on this, but would like to point out that in many ways this fits the
>description of BLISS work items: it is fundamentally a calling feature
>dealing with switching call legs appropriately among participants.
>Whether to establish a dedicated working group or not is up to the ADs;
>whether they decide to send it to BLISS or to charter a new group, I
>look forward to participating.
>
>
>_______________________________________________
>dispatch mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dispatch
>