Subject: [siprec] User notification/privacy questions

From: Alissa Cooper <[email-masked]>
Date: Thu, 24 Jun 2010 12:24:10 +0100

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

---

From: Leon Portman <[email-masked]>
Date: Thu, 24 Jun 2010 15:00:56 +0300

Please see below

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alissa Cooper
Sent: Thursday, June 24, 2010 2:24 PM
To: [email-masked]
Subject: [siprec] User notification/privacy questions

recording-arch-01.

 [LeonP] It is a good comment. The indication for not to be recorded is

supposed to be part of the original CS, meaning prior of the recording.

In addition, I don't think that we want to define a mechanism where

SRC will start asking UAs if they allowed to be recorded upon receiving recording request

is pretty useless.

[LeonP] There was some discussion on the list if indication supposed

to be only during the actual recording session or also even it can be recorded potentially - during the complete CS.

Alissa

_______________________________________________

siprec mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/siprec

---

From: Brian Rosen <[email-masked]>
Date: Thu, 24 Jun 2010 08:44:39 -0400

With respect to tones, the normal sip mechanism is that the "recording in progress" is signaled in the SIP transaction, and the UA does the UI, whatever it is.  That means whatever the alert mechanism is, it's generated locally, and likely has local significance.  That could include displays, tones, vibration or other mechanisms, and may have some user configurability.

Brian

On Jun 24, 2010, at 8:00 AM, Leon Portman wrote:

> In addition, I don’t think that we want to define a mechanism where

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 24 Jun 2010 15:29:13 +0200

I agree, except that this relies on having a SIPREC-compliant UA, so do we need a fallback mechanism for cases where we cannot rely on the UA? For audio, an announcement from a media server would suffice (I agree with Alissa that tones would work only within a closed environment). In particular, when one of the parties is connected via PSTN, an announcement is the only viable option. In this case it could be injected by the PSTN gateway (the UA), or from some other media server.

Finally, the particular announcement that needs to be given might depend on policy of the domain where recording occurs (e.g., "Please be aware that calls may be recorded for training and quality purposes...", so sending a SIP indication to a UA in another domain would be unlikely to result in precisely the right indication to the user.

So I think there IS a need for announcements not necessarily provided locally at the UA.

John (as individual)

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brian Rosen
> Sent: 24 June 2010 13:45
> To: Leon Portman
> Cc: [email-masked]
> Subject: Re: [siprec] User notification/privacy questions
> 
> With respect to tones, the normal sip mechanism is that the 
> "recording in progress" is signaled in the SIP transaction, 
> and the UA does the UI, whatever it is.  That means whatever 
> the alert mechanism is, it's generated locally, and likely 
> has local significance.  That could include displays, tones, 
> vibration or other mechanisms, and may have some user 
> configurability. 
> 
> Brian
> 
> 	From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alissa Cooper
> 	SRC will start asking UAs if they allowed to be 
> recorded upon receiving recording request
> 	to be only during the actual recording session or also 
> even it can be recorded potentially - during the complete CS.

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 25 Jun 2010 11:52:45 +0100

> receiving recording request

In that case I think it makes sense to clarify that the requirement is  
for support for requests prior to recording.

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 25 Jun 2010 11:55:09 +0100

On Jun 24, 2010, at 2:29 PM, Elwell, John wrote:

> I agree, except that this relies on having a SIPREC-compliant UA, so  
> do we need a fallback mechanism for cases where we cannot rely on  
> the UA? For audio, an announcement from a media server would suffice  
> (I agree with Alissa that tones would work only within a closed  
> environment). In particular, when one of the parties is connected  
> via PSTN, an announcement is the only viable option. In this case it  
> could be injected by the PSTN gateway (the UA), or from some other  
> media server.
>
> Finally, the particular announcement that needs to be given might  
> depend on policy of the domain where recording occurs (e.g., "Please  
> be aware that calls may be recorded for training and quality  
> purposes...", so sending a SIP indication to a UA in another domain  
> would be unlikely to result in precisely the right indication to the  
> user.
>

+1

I don't think this has implications for the requirements, but going  
forward I think making sure that notification works across the  
different deployment scenarios is important.

Alissa