Re: [dispatch] Session recording in SIP

Alan Johnston <alan@sipstation.com> Wed, 10 June 2009 13:42 UTC

Return-Path: <alan@sipstation.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849D43A6E7E for <dispatch@core3.amsl.com>; Wed, 10 Jun 2009 06:42:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmOgvpfzAqjX for <dispatch@core3.amsl.com>; Wed, 10 Jun 2009 06:42:28 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 2B5163A6841 for <dispatch@ietf.org>; Wed, 10 Jun 2009 06:42:28 -0700 (PDT)
Received: from 24-107-193-18.dhcp.stls.mo.charter.com ([24.107.193.18] helo=aidan-DS.sipserver.homeip.net) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <alan@sipstation.com>) id 1MEO4W-000IME-NV; Wed, 10 Jun 2009 13:42:33 +0000
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 24.107.193.18
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX18T/ADTDpu6MO0nMoq3rXplQpX+9gS+JWU=
Message-ID: <4A2FB842.7050302@sipstation.com>
Date: Wed, 10 Jun 2009 08:42:26 -0500
From: Alan Johnston <alan@sipstation.com>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
References: <4A2ECDB2.7000601@alcatel-lucent.com> <EDC652A26FB23C4EB6384A4584434A04017901E7@307622ANEX5.global.avaya.com>
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A04017901E7@307622ANEX5.global.avaya.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 10 Jun 2009 07:03:31 -0700
Cc: Leon Portman <Leon.Portman@nice.com>, dispatch@ietf.org, "Jain, Rajnish" <Rajnish.Jain@ipc.com>, Hadriel Kaplan <HKaplan@acmepacket.com>
Subject: Re: [dispatch] Session recording in SIP
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jun 2009 13:42:29 -0000

This is important work to be done in RAI.  Key management for secure 
recording is an important component that needs to be addressed.

draft-wing-sipping-srtp-key-04 addresses many of these topics.

Thanks,
Alan


Romascanu, Dan (Dan) wrote:
> I believe that this is an important application, and I support doing
> work in this direction. 
>
> Three comments on the preliminary words: 
>
> 1. The requirement is for both signaling and media recording, right?
> Probably good to say it. 
> 2. Security and regulations on how the information is accessed and
> protected are of high importance. They would probably be reflected in
> the requirements, but explicit wording in the future charter can help.
> 3. I suggest that we look at the IPFIX protocol as a possible technology
> to re-use
>
> Dan
>  
>
>   
>> -----Original Message-----
>> From: dispatch-bounces@ietf.org 
>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Vijay K. Gurbani
>> Sent: Wednesday, June 10, 2009 12:02 AM
>> To: dispatch@ietf.org
>> Cc: Leon Portman; Jain,Rajnish; Hadriel Kaplan
>> Subject: [dispatch] Session recording in SIP
>>
>> Hi: I realize that the deadline for charter proposals was 
>> yesterday, but I hope that it is not too late to submit one more.
>>
>> A few interested people (Hadriel Kaplan, Dan Wing, Rajnish 
>> Jain, Leon Portman, Andrew Hutton and I) have been interested 
>> in RTP session recording in SIP.  The requirement draft will 
>> be released shortly.
>>
>> We would like to request agenda time in dispatch to propose 
>> the formation of a new working group to define protocol 
>> extensions and an architecture for RTP recording.
>>
>> Session recording in SIP
>> Mailing Lists: TBD
>> Chairs: TBD
>> Area Directorate: Real Time Applications (RAI)
>>
>> Purpose:
>>
>> Session recording is a critical operational requirement in 
>> many businesses, especially where voice is used as a medium 
>> for commerce and customer support. A prime example where 
>> voice is used for trade is the financial industry. The call 
>> recording requirements in this industry are quite stringent. 
>> The recorded calls are used for dispute resolution and 
>> regulatory compliance. Other businesses such as customer 
>> support call centers typically employ call recording for 
>> quality control or business analytics.
>>
>> Depending on the country and its regulatory requirements, 
>> financial trading floors typically must record all calls. The 
>> recorded media content must be an exact copy of the actual 
>> conversation (i.e.
>> clipping and loss of media are unacceptable).  Some 
>> deployments and regulations require that calls be aborted or 
>> rejected if the recording device is unavailable.
>>
>> This group will specify requirements for a SIP based protocol 
>> interface between a communications system and a recorder. The 
>> Communications System is responsible for establishing media 
>> sessions where the actual business is conducted. The Recorder 
>> is the sink of the recorded media.
>>
>> The recorded sessions can be of any kind such as voice, video 
>> and instant messaging. A recorded session is typically 
>> comprised of actual media content and the call metadata. The 
>> call metadata allows recording archives to be searched and 
>> filtered at a later time.
>> The conveyance of call metadata from the communications 
>> system to the recorder is outside the scope of this document.
>>
>> This group will only looks into active recording, where the 
>> recorded system purposefully streams media to a recording 
>> device. Passive recording, where a recording device detects 
>> media directly from the network, is outside the scope of this 
>> document. In addition, lawful intercept is outside the scope 
>> of the group.
>>
>> Proposed deliverables:
>>
>> 1) Requirements document;
>> 2) Solutions document, including reference architecture.
>>
>> Thanks,
>>
>> - vijay
>> --
>> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 
>> Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
>> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
>> Web:   http://ect.bell-labs.com/who/vkg/
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>>     
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
>