Re: [dispatch] Session recording in SIP

"James M. Polk" <jmpolk@cisco.com> Wed, 10 June 2009 21:59 UTC

Return-Path: <jmpolk@cisco.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 B83243A6A53 for <dispatch@core3.amsl.com>; Wed, 10 Jun 2009 14:59:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.45
X-Spam-Level:
X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 1n1xecuq7ChQ for <dispatch@core3.amsl.com>; Wed, 10 Jun 2009 14:59:51 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 05A383A6951 for <dispatch@ietf.org>; Wed, 10 Jun 2009 14:59:51 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,197,1243814400"; d="scan'208";a="320825400"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 10 Jun 2009 21:59:58 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n5ALxvwR031030; Wed, 10 Jun 2009 14:59:57 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5ALxvu5020508; Wed, 10 Jun 2009 21:59:57 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Jun 2009 14:59:57 -0700
Received: from jmpolk-wxp01.cisco.com ([10.89.14.21]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Jun 2009 14:59:57 -0700
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 10 Jun 2009 16:59:56 -0500
To: Roni Even <Even.roni@huawei.com>, 'Alan Johnston' <alan@sipstation.com>, "'Romascanu, Dan (Dan)'" <dromasca@avaya.com>
From: "James M. Polk" <jmpolk@cisco.com>
In-Reply-To: <023d01c9e9e7$1b015880$51040980$%roni@huawei.com>
References: <4A2ECDB2.7000601@alcatel-lucent.com> <EDC652A26FB23C4EB6384A4584434A04017901E7@307622ANEX5.global.avaya.com> <4A2FB842.7050302@sipstation.com> <023d01c9e9e7$1b015880$51040980$%roni@huawei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Message-ID: <XFE-SJC-211EaJswFCH00000178@xfe-sjc-211.amer.cisco.com>
X-OriginalArrivalTime: 10 Jun 2009 21:59:57.0377 (UTC) FILETIME=[CB0FF310:01C9EA16]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6352; t=1244671197; x=1245535197; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20<jmpolk@cisco.com> |Subject:=20Re=3A=20[dispatch]=20Session=20recording=20in=2 0SIP |Sender:=20; bh=Sjd9PBxA1oT6PbJMpRZWqt0dd9HGDnp1Cx0UT+9J8dc=; b=B3TscM4eqfmiCKxLTdWfbxh66YalwyDc22nVwSSl8TKP4LTdXYVFzwxBTS Ybcf+I5Fbj8gzEncwLKK0E0OYF+9B8nc0hruI3u39hNnqTlJyhV4VMufCmNT OIkgcAT9un;
Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
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 21:59:52 -0000

Hey

I agree with Roni about this probably being best suited for XCON, 
after all, any point to point recording is likely (merely) adding a 
3rd party (the recorder) to the session.

This brings up probably the most glaring whole (in my mind) that is 
not mentioned below - the ability to have a recorder without at least 
one side knowing it's there.  Not every time, and in fact probably 
most times, you don't want the other person knowing you are recording 
them. It's likely more of a case of not explicitly asking the called 
party "can I record this conversation", it just happens.

James

At 11:18 AM 6/10/2009, Roni Even wrote:
>Hi,
>I agree that this is an important work but I am not sure about a WG. This
>may be done in XCON and AVT.
>Note that the recording is not only for point to point call but at least for
>three parties like in call center scenarios
>
>I also did not notice any mention of the playback part but it should also be
>addressed
>
>Roni Even
>
>-----Original Message-----
>From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf
>Of Alan Johnston
>Sent: Wednesday, June 10, 2009 4:42 PM
>To: Romascanu, Dan (Dan)
>Cc: Leon Portman; dispatch@ietf.org; Jain, Rajnish; Hadriel Kaplan
>Subject: Re: [dispatch] Session recording in SIP
>
>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
> >
> >
>
>_______________________________________________
>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