[siprec] User notification/privacy questions

Alissa Cooper <acooper@cdt.org> Thu, 24 June 2010 11:24 UTC

Return-Path: <acooper@cdt.org>
X-Original-To: siprec@core3.amsl.com
Delivered-To: siprec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B07873A67E5 for <siprec@core3.amsl.com>; Thu, 24 Jun 2010 04:24:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.432
X-Spam-Level:
X-Spam-Status: No, score=-0.432 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001]
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 84dUprfjx1Xt for <siprec@core3.amsl.com>; Thu, 24 Jun 2010 04:24:06 -0700 (PDT)
Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id BB2D43A63D3 for <siprec@ietf.org>; Thu, 24 Jun 2010 04:24:05 -0700 (PDT)
Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for siprec@ietf.org; Thu, 24 Jun 2010 07:24:10 -0400
Message-Id: <F2D661C2-378A-43EE-8A42-F9415DDA5709@cdt.org>
From: Alissa Cooper <acooper@cdt.org>
To: siprec@ietf.org
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 24 Jun 2010 12:24:10 +0100
X-Mailer: Apple Mail (2.936)
Subject: [siprec] User notification/privacy questions
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Jun 2010 11:24:06 -0000

I have a couple of questions about requirements 23 and 24 in draft- 
ietf-siprec-req-00 and related text in draft-hutton-siprec-session- 
recording-arch-01.
> o REQ-023 The mechanism MUST support a means for a SIP UA to request
>    that a session is not recorded.

Is it envisioned that the negotiation of this kind of request would  
happen before recording starts (section 4.5 of -session-recording-arch  
seems to intimate this)? Or is it left open-ended, so that recording  
may start and sometime later the UA can request not to have it  
recorded (or to stop the recording)? If it's the former, I wonder if  
"prior to recording" should be added to the end of the sentence.

> o REQ-024 The mechanism MUST provide a means of indicating to the end
>    users of a Communication Session that the session in which they are
>    participating is being recorded.

> Examples include: inject tones into the Communication Session from
>    the SRC, play a message at the beginning of a session, a visual
>    indicator on a display, etc.

On timing again, would it make sense to say that the indication needs  
to be possible upon establishment of the session? Maybe this is  
overkill, but an indication that comes right before everyone hangs up  
is pretty useless.

I'm also wondering about where the notion of injecting tones comes  
from. Obviously without some out-of-band understanding about what a  
tone means, hearing a tone during a session isn't going to tell end  
users much of anything. Unless there are particular use cases where  
particular tones are already well understood (e.g., all financial  
traders know that a particular tone means they're being recorded), it  
seems like a tone isn't really sufficient notification.

Alissa