Subject: Re: [siprec] Requirements #66 (new): Clarification of REQ-018 on indications to participants

From: "Elwell, John" <[email-masked]>
Date: Wed, 2 Mar 2011 12:41:16 +0100

In the interests of getting the requirements document finished, I will set a short deadline for this remaining issue. If I have not heard any objections to the proposal below by 2011-03-07 I will ask the editor to adopt this new text and publish -07.

John (as chair)

> -----Original Message-----
> From: Leon Portman [mailto:[email-masked]] 
> Sent: 28 February 2011 16:17
> To: Elwell, John; siprec issue tracker
> Cc: [email-masked]
> Subject: RE: [siprec] Requirements #66 (new): Clarification 
> of REQ-018 on indications to participants
> 
> +1
> 
> Leon
> 
> -----Original Message-----
> From: Elwell, John [mailto:[email-masked]] 
> Sent: Monday, February 28, 2011 5:35 PM
> To: Leon Portman; siprec issue tracker
> Cc: [email-masked]
> Subject: RE: [siprec] Requirements #66 (new): Clarification 
> of REQ-018 on indications to participants
> 
> There has been little discussion on this, apart from support 
> from Leon. The existing text says:
> "REQ-018 The mechanism MUST provide a means of indicating to the
>    participants involved in a CS that their session is being recorded.
> 
>    Examples include: inject tones into the CS from the SRC, play a
>    message at the beginning of a session, a visual indicator on a
>    display, etc."
> 
> I would suggest the following text:
> "REQ-018 The mechanism MUST provide a means of indicating to 
> the participants involved in a CS that their session is being 
> recorded. Although this can be accomplished using existing 
> SIP techniques for playing an in-band tone, announcement or 
> other media to participants, the mechanism is required also 
> to provide an indication to recording-aware UAs for 
> appropriate rendering at the user interface."
> 
> John (as individual) 
> 
> > -----Original Message-----
> > From: Elwell, John
> > Sent: 23 February 2011 20:36
> > To: 'Leon Portman'; siprec issue tracker
> > Cc: [email-masked]
> > Subject: RE: [siprec] Requirements #66 (new): Clarification 
> of REQ-018 
> > on indications to participants
> > 
> > My feeling too.
> > 
> > John (as individual)
> > 
> > > -----Original Message-----
> > > From: Leon Portman [mailto:[email-masked]]
> > > Sent: 23 February 2011 17:25
> > > To: siprec issue tracker; Elwell, John
> > > Cc: [email-masked]
> > > Subject: RE: [siprec] Requirements #66 (new): Clarification of 
> > > REQ-018 on indications to participants
> > > 
> > > Because supporting of siprec-aware UA indication will 
> require some 
> > > additional protocol changes for CS, we probably should have a 
> > > separate requirement for that
> > > 
> > > Leon
> > > 
> > > -----Original Message-----
> > > From: siprec issue tracker [mailto:[email-masked]]
> > > Sent: Tuesday, February 15, 2011 10:24 AM
> > > To: Leon Portman; [email-masked]
> > > Cc: [email-masked]
> > > Subject: [siprec] Requirements #66 (new): Clarification of
> > > REQ-018 on indications to participants
> > > 
> > > #66: Clarification of REQ-018 on indications to participants
> > > 
> > >  REQ-018 can be satisfied in general by playing media to 
> > > participants, but  do we need a more specific 
> requirement, e.g., for 
> > > siprec-aware UAs to know  whether the CS is being recorded or not?
> > > 
> > >  John
> > > 
> > > --
> > > ------------------------------------------------+-------------
> > > ----------
> > > ------------------------------------------------+----
> > >  Reporter:  john.elwell@...                       |       
> > > Owner:  leon.portman@...       
> > >      Type:  defect                              |      
> > > Status:  new                  
> > >  Priority:  major                               |   
> > > Milestone:                       
> > > Component:  Requirements                        |     
> > > Version:                       
> > >  Severity:  In WG Last Call                     |    
> > > Keywords:                       
> > > ------------------------------------------------+-------------
> > > ----------
> > > ------------------------------------------------+----
> > > 
> > > Ticket URL: <https://trac.tools.ietf.org/wg/siprec/trac/ticket/66>
> > > siprec <http://tools.ietf.org/siprec/>
> > > 
> > > 
>

---

From: "Dave Smith" <[email-masked]>
Date: Wed, 2 Mar 2011 11:57:06 -0800

I do have an input to this requirement.  

I agree that the system should be able to provide an indication to
recording-aware UAs that recording is currently occurring (for
appropriate rendering at the user interface).  
I also believe that the system should be able to provide a "tone" to CS
participants to indicate that recording is currently occurring
(specifically, a distinct "beep tone" signal that is repeated at regular
intervals during the course of the telephone conversation when the
recording device is in use); note that this is consistent with existing
methods from FCC Rules Regarding Telephone Company Recording of
Interstate or International Wireline Telephone Conversations.  
But I do not see a reason to mention "announcements", or "other media"
in this requirement.  
 
Therefore, I recommend the following wording for REQ-018:   

"REQ-018 The mechanism MUST provide a means of indicating to the
participants involved in a CS that their session is being recorded.  To
support this the mechanism MUST provide a means of playing a repeatable
tone to CS participants, and also the mechanism MUST provide a means to
indicate to recording-aware UAs that recording is currently occurring
(for appropriate rendering at the user interface)."

Regards,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
Sent: Wednesday, March 02, 2011 3:41 AM
To: Leon Portman; siprec issue tracker
Cc: [email-masked]
Subject: Re: [siprec] Requirements #66 (new): Clarification of REQ-018
on indications to participants

In the interests of getting the requirements document finished, I will
set a short deadline for this remaining issue. If I have not heard any
objections to the proposal below by 2011-03-07 I will ask the editor to
adopt this new text and publish -07.

John (as chair)

> > > siprec-aware UAs to know  whether the CS is being recorded or not?
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Mar 2011 16:42:30 -0500

Dave,

I recognize that there are environments where this audible tone is a 
requirement. And also environments where it is not, or that there is 
some *other* requirement.

My question is whether rendering such things is "part of the mechanism", 
or simply something that some SRCs must be able to do.

Making this part of the mechanism begs the question of "what mechanism". 
There are mechanisms for capturing the media for recording that do not 
have a device in place that can insert something into the media. Making 
this a requirement on the mechanism would exclude using those techniques.

	Thanks,
	Paul

On 3/2/2011 2:57 PM, Dave Smith wrote:
>>>> Ticket URL:<https://trac.tools.ietf.org/wg/siprec/trac/ticket/66>
>>>> siprec<http://tools.ietf.org/siprec/>
>>>>
>>>>
>>

---

From: "Dave Smith" <[email-masked]>
Date: Wed, 2 Mar 2011 16:50:10 -0800

I think the solution should be able to support these functionalities:
	1.  playing a repeatable tone to CS participants
	2.  indicate to recording-aware UAs that recording is currently
occurring

Although there may be other things that could be done, I believe that
these functionalities are reasonable and sufficient, and would be
universally accepted, and that both are required in order to be able to
addresss most use cases for indicating to the participants involved in a
CS that their session is being recorded.   

I am not sure of what the last paragraph of your response is about
exactly.  A solution to this req't needs to be worked out in another
SIPREC Draft; my current thoughts are that since the SRC is handling and
in the path of CS UA media and is already communicating with these UAs,
probably an SRC-based solution could be more easily used to solve this
req't.  

Regards,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Wednesday, March 02, 2011 1:43 PM
To: [email-masked]
Subject: Re: [siprec] Requirements #66 (new): Clarification of REQ-018
on indications to participants

Dave,

There are mechanisms for capturing the media for recording that do not 
have a device in place that can insert something into the media. Making 
this a requirement on the mechanism would exclude using those
techniques.

	Thanks,
	Paul

> participants involved in a CS that their session is being recorded.
To
>>>> siprec-aware UAs to know  whether the CS is being recorded or not?
------------------------------------------------------------------------
-------------------------------------------
> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
confidential and proprietary information of Alcatel-Lucent and/or its
affiliated entities. Access by the intended recipient only is
authorized. Any liability arising from any party acting, or refraining
from acting, on any information contained in this e-mail is hereby
excluded. If you are not the intended recipient, please notify the
sender immediately, destroy the original transmission and its
attachments and do not disclose the contents to any other person, use it
for any purpose, or store or copy the information in any medium.
Copyright in this e-mail and any attachments belongs to Alcatel-Lucent
and/or its affiliated entities.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Mar 2011 21:41:20 -0500

> probably an SRC-based solution could be more easily used to solve this

I'll try to elaborate:

I'm not informed of the specific legalities involved, but am of the 
impression that they vary widely. There are certainly contexts in which 
no audible indication need be played. (E.g. call centers, at least in 
some places.) In some cases this is dealt with by playing a general 
disclaimer at the beginning of the call, and/or having a contractual 
relationship by which this isn't required.

In such environments the SRC may not need any way of injecting an 
audible indication that recording is going on.

And there are ways an SRC could get the media for recording that don't 
provide a way to inject these tones. (E.g. a media *relay* may fork the 
media, but not be able to alter it.)

If you combine these things, you can end up with mechanisms for 
implementing the SRC function that are *incapable* of satisfying your 
proposed requirement, and yet are perfectly suitable for the intended 
recording task. I don't want to rule those out as valid implementations 
of siprec.

I'm fine with having the tone generation as an *option*, and one that 
may be absolutely required in *some* markets. If you have a business 
that requires this tone generation then you will buy a product that 
supports it.

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Thu, 3 Mar 2011 09:31:30 +0200

I agree with Paul. In the environment where SRC cannot inject any audio into the CS, best practice is to have IVR or Voice Portal to make such announcement. 

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Thursday, March 03, 2011 4:41 AM
To: Dave Smith
Cc: [email-masked]
Subject: Re: [siprec] Requirements #66 (new): Clarification of REQ-018 on indications to participants

On 3/2/2011 7:50 PM, Dave Smith wrote:
> universally accepted, and that both are required in order to be able 
> to addresss most use cases for indicating to the participants involved 
> in a CS that their session is being recorded.

> SIPREC Draft; my current thoughts are that since the SRC is handling 
> and in the path of CS UA media and is already communicating with these 
> UAs, probably an SRC-based solution could be more easily used to solve 
> this req't.

I'll try to elaborate:

I'm not informed of the specific legalities involved, but am of the impression that they vary widely. There are certainly contexts in which no audible indication need be played. (E.g. call centers, at least in some places.) In some cases this is dealt with by playing a general disclaimer at the beginning of the call, and/or having a contractual relationship by which this isn't required.

In such environments the SRC may not need any way of injecting an audible indication that recording is going on.

And there are ways an SRC could get the media for recording that don't provide a way to inject these tones. (E.g. a media *relay* may fork the media, but not be able to alter it.)

If you combine these things, you can end up with mechanisms for implementing the SRC function that are *incapable* of satisfying your proposed requirement, and yet are perfectly suitable for the intended recording task. I don't want to rule those out as valid implementations of siprec.

I'm fine with having the tone generation as an *option*, and one that may be absolutely required in *some* markets. If you have a business that requires this tone generation then you will buy a product that supports it.

	Thanks,
	Paul

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Paul Kyzivat
> have a device in place that can insert something into the media. 
> Making this a requirement on the mechanism would exclude using those 
> techniques.
>
> 	Thanks,
> 	Paul
>
>> Subject: Re: [siprec] Requirements #66 (new): Clarification of 
>> In the interests of getting the requirements document finished, I 
>> will set a short deadline for this remaining issue. If I have not 
>> heard any objections to the proposal below by 2011-03-07 I will ask 
>> the editor
> to
>>> There has been little discussion on this, apart from support from 
>>> Leon. The existing text says:
>>> Although this can be accomplished using existing SIP techniques for 
>>> playing an in-band tone, announcement or other media to 
>>> participants, the mechanism is required also to provide an 
>>> indication to recording-aware UAs for appropriate rendering at the 
>>> user interface."
>>>
>>> John (as individual)
>>>
> attachments and do not disclose the contents to any other person, use 
> it for any purpose, or store or copy the information in any medium.
> ----------------------------------------------------------------------
> ---------------------------------------------

---

From: "Dave Smith" <[email-masked]>
Date: Thu, 3 Mar 2011 00:29:07 -0800

I fully agree that an IVR solution (play an announcement) is an
acceptable method that is used today to inform a caller.  
I was introducing this req't (#1 below) in order to improve on that.  

Do we absolutely need #1 - probably not.  Do we absolutely need #2 -
probably not also.

It seems that you are indicating that at least for #1 a solution is
difficult to provide and would restrict the SRC solution significantly,
so we should not include it.  
I am wondering if that is also the case for #2.     

I don't think we need to mention any "optional" solutions in the req't.

Regards,
Dave

-----Original Message-----
From: Leon Portman [mailto:[email-masked]] 
Sent: Wednesday, March 02, 2011 11:32 PM
To: Paul Kyzivat; Dave Smith
Cc: [email-masked]
Subject: RE: [siprec] Requirements #66 (new): Clarification of REQ-018

I agree with Paul. In the environment where SRC cannot inject any audio
into the CS, best practice is to have IVR or Voice Portal to make such
announcement. 

Leon

-----Original Message-----

I'll try to elaborate:

	Thanks,
	Paul

> Behalf

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 3 Mar 2011 10:14:15 +0100

Concerning #1, I agree we need to be able to accommodate the different requirements of different regions, countries, business sectors, etc.. Sometimes this might involve playing a tone (e.g., a repeated beep) for the duration of recording, and sometimes this might involve an announcement at the beginning of the session, which will suffice whether or not recording actually takes place during the session. Basically, since not all users will use siprec-aware UAs, particularly PSTN users, the only solution is for the SRC to arrange that the appropriate tone or announcement is injected into the audio stream when required. If the SRC itself is able to do this, we don't need a SIP solution. If the SRC uses a media server to do this, existing SIP/SDP mechanisms will cater for this. I don't anticipate siprec providing new mechanisms for this. It is really just a case of not preventing the use of such mechanisms. How about the following text?

"REQ-x1 The mechanism MUST NOT prevent the application of tones or announcements during recording or at the start of a CS to support legal or policy requirements for notifying participants that the call is being recorded or may be recorded."

Concerning #2, I see this more of a courtesy thing, rather than a legal thing. Most web-based conference applications give a visual indication of whether the conference is being recorded, achieved using web technology. Where this is not available, it would be useful if siprec-aware UAs in the CS could be advised when recording is taking place so that they can give an appropriate indication to the user. I can see a number of reasons for this:
- It provides the possibility of alternative modes for hearing-impaired users.
- It gives more precise information in cases where an SRC-injected announcement is given only at the start of the call.
- It provides feedback to users who have requested that recording be started / stopped / paused / resumed.
- It gives an explicit indication to users who might not understand the meaning of an injected tone.
- It is independent of medium type (audio, video, real-time text, fax...).
- Potentially its granularity could be on a per medium basis, although I would prefer to leave that as an option for the solution, rather than making a requirement.

So how about the following text?

"REQ-x2 The mechanism MUST provide a means of indicating to recording-aware UAs whether recording is taking place, for appropriate rendering at the user interface.

John (as individual)

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dave Smith
> Sent: 03 March 2011 08:29
> To: Leon Portman; Paul Kyzivat
> Cc: [email-masked]
> Subject: Re: [siprec] Requirements #66 (new): Clarification 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> >> I also believe that the system should be able to provide a 
> "tone" to
> > CS
> >> tone to CS participants, and also the mechanism MUST 
> provide a means
> > to

---

From: Leon Portman <[email-masked]>
Date: Thu, 3 Mar 2011 17:24:22 +0200

I agree with your points. Just generic question, do we really need a requirement for mechanism not to prevent something? It can be lot of things like encryption, codec negotiation, ability to transfer call etc.

Leon

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Thursday, March 03, 2011 11:14 AM
To: Dave Smith; Leon Portman; Paul Kyzivat
Cc: [email-masked]
Subject: RE: [siprec] Requirements #66 (new): Clarification of REQ-018 on indications to participants

John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 3 Mar 2011 18:17:07 +0100

> Sent: 03 March 2011 15:24
> To: Elwell, John; Dave Smith; Paul Kyzivat
> Cc: [email-masked]
> I agree with your points. Just generic question, do we really
> need a requirement for mechanism not to prevent something? It
> can be lot of things like encryption, codec negotiation,
> ability to transfer call etc.
[JRE] It is certainly worth questioning whether we need REQ-x1 below. On the one hand, SIPREC is unlikely to specify anything that would prevent this existing capability. In fact it would be quite hard for SIPREC to specify something that would prevent the application of tones of announcement. Of course, there might be things that could be done at deployment time to prevent it (e.g., encryption), but that is not SIPREC's problem. However, I would still be inclined to keep it. In particular, the Privacy Considerations section has a statement: "Therefore this document contains requirements for being able to notify users that a call is being recorded ...". I don't think REQ-x2 alone would be sufficient to satisfy that, so if we were to remove REQ-x1 we would have to revisit the Privacy Considerations text, which I would be very reluctant to do. So I would like to keep REQ-x1 or something similar.

John (as individual)

> Concerning #1, I agree we need to be able to accommodate the
> different requirements of different regions, countries,
> business sectors, etc.. Sometimes this might involve playing
> a tone (e.g., a repeated beep) for the duration of recording,
> and sometimes this might involve an announcement at the
> beginning of the session, which will suffice whether or not
> recording actually takes place during the session. Basically,
> since not all users will use siprec-aware UAs, particularly
> PSTN users, the only solution is for the SRC to arrange that
> the appropriate tone or announcement is injected into the
> audio stream when required. If the SRC itself is able to do
> this, we don't need a SIP solution. If the SRC uses a media
> server to do this, existing SIP/SDP mechanisms will cater for
> this. I don't anticipate siprec providing new mechanisms for
> this. It is really just a case of not preventing the use of
> such mechanisms. How about the following text?
>
> "REQ-x1 The mechanism MUST NOT prevent the application of
> tones or announcements during recording or at the start of a
> CS to support legal or policy requirements for notifying
> participants that the call is being recorded or may be recorded."
>
> Concerning #2, I see this more of a courtesy thing, rather
> than a legal thing. Most web-based conference applications
> give a visual indication of whether the conference is being
> recorded, achieved using web technology. Where this is not
> available, it would be useful if siprec-aware UAs in the CS
> could be advised when recording is taking place so that they
> can give an appropriate indication to the user. I can see a
> number of reasons for this:
> - It gives more precise information in cases where an
> SRC-injected announcement is given only at the start of the call.
> - It provides feedback to users who have requested that
> recording be started / stopped / paused / resumed.
> - It gives an explicit indication to users who might not
> understand the meaning of an injected tone.
> - Potentially its granularity could be on a per medium basis,
> although I would prefer to leave that as an option for the
> solution, rather than making a requirement.
>
> "REQ-x2 The mechanism MUST provide a means of indicating to
> recording-aware UAs whether recording is taking place, for
> appropriate rendering at the user interface.
>
> John (as individual)
>

---

From: "Dave Smith" <[email-masked]>
Date: Thu, 3 Mar 2011 09:38:03 -0800

Thanks for the detailed inputs/explanations.  I agree with the
recommendations for using REQ-x1 and -x2.

Regards,
Dave

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Thursday, March 03, 2011 9:17 AM
To: Leon Portman; Dave Smith; Paul Kyzivat
Cc: [email-masked]
Subject: RE: [siprec] Requirements #66 (new): Clarification of REQ-018
onindications to participants

> ability to transfer call etc.
[JRE] It is certainly worth questioning whether we need REQ-x1 below. On
the one hand, SIPREC is unlikely to specify anything that would prevent
this existing capability. In fact it would be quite hard for SIPREC to
specify something that would prevent the application of tones of
announcement. Of course, there might be things that could be done at
deployment time to prevent it (e.g., encryption), but that is not
SIPREC's problem. However, I would still be inclined to keep it. In
particular, the Privacy Considerations section has a statement:
"Therefore this document contains requirements for being able to notify
users that a call is being recorded ...". I don't think REQ-x2 alone
would be sufficient to satisfy that, so if we were to remove REQ-x1 we
would have to revisit the Privacy Considerations text, which I would be
very reluctant to do. So I would like to keep REQ-x1 or something
similar.

John (as individual)

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 3 Mar 2011 12:04:35 -0800

Just to clarify, is the decision therefore that Req. #18 will be updated
as proposed by John? 

> > > >>> indication to recording-aware UAs for appropriate

If I am interpreting this correctly, playing of a tone or an
announcement is an option, not a required form of indication, and some
other indication may be communicated from the SRC to a recording aware
UA that results in the UA producing an indication of recording that is
possibly NOT audible, for example. The choice of the actual rendering of
this indication by the UA is left entirely to the UA. Is that correct?

Thanks,
Charles

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dave Smith
> Sent: Thursday, March 03, 2011 9:38 AM
> To: Elwell, John; Leon Portman; Paul Kyzivat (pkyzivat)
> Cc: [email-masked]
REQ-018onindications to participants
> > > >> (specifically, a distinct "beep tone" signal that is repeated
at
> > > > regular
the
> > > >>> "REQ-018 The mechanism MUST provide a means of indicating to
the
------------------------------------------------------------------------
------------------------------
> -------------
confidential and proprietary
> information of Alcatel-Lucent and/or its affiliated entities. Access
by the intended recipient only is
> authorized. Any liability arising from any party acting, or refraining
from acting, on any information
> contained in this e-mail is hereby excluded. If you are not the
intended recipient, please notify the
> sender immediately, destroy the original transmission and its
attachments and do not disclose the
> contents to any other person, use it for any purpose, or store or copy
the information in any medium.

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 4 Mar 2011 08:39:43 +0100

Charles,

The text you quote is not the latest proposal. You will see below a later proposal for two separate requirements REQ-x1 and REQ-x2 to replace REQ-018. I understand Dave was agreeing with those new requirements. I reproduce the new proposal here:

John

> From: Charles Eckel (eckelcu) [mailto:[email-masked]]
> Sent: 03 March 2011 20:05
> To: Dave Smith; Elwell, John; Leon Portman; Paul Kyzivat (pkyzivat)
> Cc: [email-masked]
> of REQ-018onindications to participants
>
> > [JRE] It is certainly worth questioning whether we need
> REQ-x1 below.
> On
> > > > Do we absolutely need #1 - probably not.  Do we
> absolutely need #2
> -
> > > > probably not also.
> > > >
> > > > >> recording device is in use); note that this is
> consistent with
> > > > > existing
> > > > >> But I do not see a reason to mention
> "announcements", or "other
> > > > media"
> > > > >> in this requirement.
> > > > >>
> [mailto:[email-masked]]
> On
> > > > > Behalf
> > > > >> Of Elwell, John
> [mailto:[email-masked]]
> > > > >>>      participants involved in a CS that their
> session is being
> > > > > recorded.
> > > > >>>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 4 Mar 2011 08:51:51 -0800

Works for me. 
Sorry I missed it in the thread, and thanks for clarifying.

Cheers,
Charles

> Sent: Thursday, March 03, 2011 11:40 PM
> To: Charles Eckel (eckelcu); Dave Smith; Leon Portman; Paul Kyzivat
(pkyzivat)
> 
> Charles,
> 
> The text you quote is not the latest proposal. You will see below a
later proposal for two separate
> requirements REQ-x1 and REQ-x2 to replace REQ-018. I understand Dave
was agreeing with those new
> requirements. I reproduce the new proposal here:
> 
> "REQ-x1 The mechanism MUST NOT prevent the application of tones or
announcements during recording or
> at the start of a CS to support legal or policy requirements for
notifying participants that the call
> is being recorded or may be recorded."
> 
recording-aware UAs whether recording is
> taking place, for appropriate rendering at the user interface.
> 
> John
> 
> 
> > > would have to revisit the Privacy Considerations text, which I
would
> > be
> > > > > It seems that you are indicating that at least for #1 a
solution
> > is
> > > > > > these functionalities are reasonable and sufficient, and
would
> > be
> > > > > I'm not informed of the specific legalities involved, but am
of
> > > > > >> support this the mechanism MUST provide a means of playing
a
> > > > > > repeatable

---

From: Alissa Cooper <[email-masked]>
Date: Sat, 5 Mar 2011 20:06:43 +0000

On Mar 4, 2011, at 7:39 AM, Elwell, John wrote:
> announcements during recording or at the start of a CS to support  
> legal or policy requirements for notifying participants that the  
> call is being recorded or may be recorded."

Why does this requirement only apply to cases where notification is  
provided because of legal or policy requirements? What if the entity  
doing the recording just thinks that notification is a Good Thing to  
Do? My suggestion:

"REQ-x1 The mechanism MUST NOT prevent the application of tones or  
announcements during recording or at the start of a CS to support  
notification to participants that the call is being recorded or may be  
recorded."

Alissa

---

From: Leon Portman <[email-masked]>
Date: Mon, 7 Mar 2011 09:41:58 +0200

+1

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alissa Cooper
Sent: Saturday, March 05, 2011 10:07 PM
To: Elwell, John
Cc: [email-masked]
Subject: Re: [siprec] Requirements #66 (new): Clarification of REQ-018onindications to participants

On Mar 4, 2011, at 7:39 AM, Elwell, John wrote:
> legal or policy requirements for notifying participants that the call

Why does this requirement only apply to cases where notification is provided because of legal or policy requirements? What if the entity doing the recording just thinks that notification is a Good Thing to Do? My suggestion:

"REQ-x1 The mechanism MUST NOT prevent the application of tones or announcements during recording or at the start of a CS to support notification to participants that the call is being recorded or may be recorded."

Alissa

> recording-aware UAs whether recording is taking place, for appropriate
> rendering at the user interface.
>
> John
>
>
>> Just to clarify, is the decision therefore that Req. #18 will be
>> updated as proposed by John?
>>
>> announcement is an option, not a required form of indication, and
>> some other indication may be communicated from the SRC to a recording
>> aware UA that results in the UA producing an indication of recording
>> that is possibly NOT audible, for example. The choice of the actual
>> rendering of this indication by the UA is left entirely to the UA. Is
>> that correct?
>>
>> Thanks,
>> Charles
>>
>>
>>>> I agree with your points. Just generic question, do we really need
>>>> a requirement for mechanism not to prevent something? It can be lot
>>>> of things like encryption, codec negotiation, ability to transfer
>>>> call etc.
>>>> different requirements of different regions, countries, business
>>>> sectors, etc.. Sometimes this might involve playing a tone (e.g., a
>>>> repeated beep) for the duration of recording, and sometimes this
>>>> might involve an announcement at the beginning of the session,
>>>> which will suffice whether or not recording actually takes place
>>>> during the session. Basically, since not all users will use
>>>> siprec-aware UAs, particularly PSTN users, the only solution is for
>>>> the SRC to arrange that the appropriate tone or announcement is
>>>> injected into the audio stream when required. If the SRC itself is
>>>> able to do this, we don't need a SIP solution. If the SRC uses a
>>>> media server to do this, existing SIP/SDP mechanisms will cater for
>>>> this. I don't anticipate siprec providing new mechanisms for this.
>>>> It is really just a case of not preventing the use of such
>>>> mechanisms. How about the following text?
>>>>
>>>> Concerning #2, I see this more of a courtesy thing, rather than a
>>>> legal thing. Most web-based conference applications give a visual
>>>> indication of whether the conference is being recorded, achieved
>>>> using web technology. Where this is not available, it would be
>>>> useful if siprec-aware UAs in the CS could be advised when
>>>> recording is taking place so that they can give an appropriate
>>>> indication to the user. I can see a number of reasons for this:
>>>> - It gives more precise information in cases where an SRC-injected
>>>> announcement is given only at the start of the call.
>>>>> difficult to provide and would restrict the SRC solution
>>>>> significantly, so we should not include it.
>>>>> I agree with Paul. In the environment where SRC cannot inject any
>>>>> audio into the CS, best practice is to have IVR or Voice Portal
>>>> to make such
>>>>> announcement.
>>>>>
>>>>> Leon
>>>>>
>>>>> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
>>>>>>  1.  playing a repeatable tone to CS participants  2.  indicate
>>>>>> to recording-aware UAs that recording is
>> currently
>>>>>> occurring
>>>>>>
>>>>> impression that they vary widely. There are certainly contexts in
>>>>> which no audible indication need be played. (E.g. call centers,
>>>> at least in
>>>>> provide a way to inject these tones. (E.g. a media *relay* may
>>>>> fork the media, but not be able to alter it.)
>>>>>
>>>>> recording task. I don't want to rule those out as valid
>>>>> implementations of siprec.
>>>>>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 7 Mar 2011 12:43:46 +0100

+1.

I am happy with Alissa's proposal for REQ-x1 and also with the previously proposed REQ-x2.

Regards
Andy

> [mailto:[email-masked]] On Behalf Of Leon Portman
> Sent: 07 March 2011 07:42
> To: Alissa Cooper; Elwell, John
> Cc: [email-masked]
> [mailto:[email-masked]] On Behalf Of Alissa Cooper
> Why does this requirement only apply to cases where
> notification is provided because of legal or policy
> requirements? What if the entity doing the recording just
> thinks that notification is a Good Thing to Do? My suggestion:
>
> CS to support notification to participants that the call is
> being recorded or may be recorded."
>
> Alissa
>
> >
> >>> would have to revisit the Privacy Considerations text,
> which I would
> >> be
> SRC-injected