Re: [dispatch] Session recording in SIP

Alan Johnston <alan@sipstation.com> Thu, 18 June 2009 21:26 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 A00743A6C45 for <dispatch@core3.amsl.com>; Thu, 18 Jun 2009 14:26:25 -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=[AWL=0.000, 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 iZ2qNWX75zDe for <dispatch@core3.amsl.com>; Thu, 18 Jun 2009 14:26:24 -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 925183A67E2 for <dispatch@ietf.org>; Thu, 18 Jun 2009 14:26:24 -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 1MHP80-000P8G-JU; Thu, 18 Jun 2009 21:26:36 +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: U2FsdGVkX19zx3NbNDwTW+Vchhd8FE2MpOdu95P9fkY=
Message-ID: <4A3AB109.9080409@sipstation.com>
Date: Thu, 18 Jun 2009 16:26:33 -0500
From: Alan Johnston <alan@sipstation.com>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
References: <4A2ECDB2.7000601@alcatel-lucent.com> <EDC652A26FB23C4EB6384A4584434A04017901E7@307622ANEX5.global.avaya.com> <4A2FB842.7050302@sipstation.com> <023d01c9e9e7$1b015880$51040980$%roni@huawei.com> <40730EBC-4923-4EB1-A3E7-3234888F48FB@cisco.com>
In-Reply-To: <40730EBC-4923-4EB1-A3E7-3234888F48FB@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: dispatch@ietf.org
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: Thu, 18 Jun 2009 21:26:25 -0000

Cullen Jennings wrote:
>
> I look forward to reading the requirements draft when that comes out 
> as it may answer this but ...
>
>>>> 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.
>
> So in the case where a customer is talking to an agent, my 
> understanding is that some of the deployments (often legal compliance 
> type situations) require an accurate recording of what the agent heard 
> while other sorts of deployments may (perhaps a post call statistical 
> analysis) only care about  an best effort approximation of the call. 
> So in the first case, if the call could not be recorded, the call 
> would not be set up but in the second case, the call would go ahead 
> regardless.
>
> I'm assuming the scope of the work would cover both case. Does that 
> sound about right to others?
>

Yes - we need to cover the various modes.  We described four in our 
draft (http://tools.ietf.org/html/draft-wing-sipping-srtp-key):

1. Always On Recording
2. Recording On Demand
3. Required Recording
4. Pause and Resume Recording

There may be others as well, but these cover all the ones we support in 
our systems today.  Some are different by policy, others are different 
in actual call flows.

Thanks,
Alan

> Cullen <with my individual contributor hat on>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>