Subject: [siprec] Comments on recording notification and audio injection

From: Gabor Moczar <[email-masked]>
Date: Wed, 24 Mar 2010 13:09:54 +0100

I would like to share some comments I have about the REQ-024 and the
proposed audio injection functionality.
Before doing it, let me provide you some background information about the
key drivers behind this function.
Notifying the end users of a call that the session in which they
are participating is being recorded is mandatory by the law in
most countries. It varies country by country or state by state (in the USA),
but in most cases the system has to announce (or one the call participant),
that the call is being recorded. In addition to the voice announcement, some
regulations also require to play a so called recording tone during the call.
This "beep" tone is played periodically to all parties in the call,
indicating that call recording is turned on. The frequency and the period
may change country by country (
http://www.itu.int/ITU-T/inr/forms/files/tones-0203.pdf).
According to my past experience, meeting regulatory requirements regarding
announcements and tones was always a big headache. None of the telephony
platforms, I am familiar with, is able to fully support all types of
scenarios:
S1: play recording announcement at the beginning of an inbound call before
the call is being connected to called party (in most cases the call is
simple routed through an IVR)
S2: play recording announcement at the beginning of an outbound
call automatically (I have never seen this scenario working, because playing
the announcement before the called party picks up is something achievable,
but no one wants start a conversation by listening to an automatic prompt if
she/he is the called party)
S3: play recording announcement when the party in control actually starts
the recording or pauses or restarts it during a single call (only conference
based recorders are able to support this requirement currently)
S4: visually notify the parties in a video call/conference (all previous
scenarios apply)
S5: providing recording tone or continuous visual sign during the recording
(all previous scenarios apply)

Based on the above items, it would be great if the telephony platform
vendors would implement this functionality in the endpoints (as indicated in
the requirements draft). In my opinion, the endpoint is the only place,
where all types of scenarios can be supported in the most efficient way.
I can also imagine a system, where all configuration options regarding this
functionality resides on the telephony platform, since the RC is always
aware of the current state of the recording session (even in the case
of persistent recording the telephony system knows that it is turned on or
off when a given call starts).

Some hints for Nathan's and Deepanshu's comments:
>2. Regarding REQ-024, it would be nice to be able to specify which specific
leg of the communications has media injection.  For example, only the
external caller should hear recorded >messages or beep tones.  It would be
nice to be able to play a message at the start of the session even if the
session is not being initially recorded (in case recording starts
mid-session)
 >>Sorry for the clarification: but, do you mean to indicate to the end user
that the session they are going to participate in MAY BE recorded in future?
Yes. It is a very common use case. On demand recording in most systems
allows the users to record the entire call even if the user is decided to
record it in the middle of the call (or even after the call is finished). In
this case the announcement looks like "The call may be recorded ..." in the
beginning of the call.

Regards,
Gabor

---

From: Deepanshu Gautam <[email-masked]>
Date: Thu, 25 Mar 2010 11:38:42 +0800

I DO NOT HAVE any problems, what so ever, with the existence of this
requirement. I can understand very well that this is something which SIPREC
must work on.
 
What i have concern/problem for is:
 
A message in the beginning of the call saying "The call may be recorded
...". As an end user i want to know *FOR SURE* whether you are going to
record (in between or at the end) my call not, so that i can decided whether
to continue with the call or not (i may have some privacy concerns which i
don't want to take risk for, in case you want to record).
 
>It is a very common use case. On demand recording in most systems allows
the users to record the entire call even if the user is decided to record it
in the middle of the call (or even after >the call is finished).
 
I'm not very sure about it being *very* common. It may suffer from some user
privacy concerns (as mentioned above in round bracket). 
In the case of on-demand recording, i would rather prefer a message saying
"A recording request is being made...." in the middle of the call (when RS
or RC actually initiate the recording). In this case the call will be
recorded from the specific point (when it is requested) onward, not the
entier call (also, this is my understanding of the related description in
the draft, unless it is changed/modified).
 
Regards
Deepanshu

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Gabor Moczar
Sent: 2010年3月24日 20:10
To: [email-masked]
Subject: [siprec] Comments on recording notification and audio injection

I would like to share some comments I have about the REQ-024 and the
proposed audio injection functionality.
Before doing it, let me provide you some background information about the
key drivers behind this function.
Notifying the end users of a call that the session in which they are
participating is being recorded is mandatory by the law in most countries.
It varies country by country or state by state (in the USA), but in most
cases the system has to announce (or one the call participant), that the
call is being recorded. In addition to the voice announcement, some
regulations also require to play a so called recording tone during the call.
This "beep" tone is played periodically to all parties in the call,
indicating that call recording is turned on. The frequency and the period
may change country by country
(http://www.itu.int/ITU-T/inr/forms/files/tones-0203.pdf).
According to my past experience, meeting regulatory requirements regarding
announcements and tones was always a big headache. None of the telephony
platforms, I am familiar with, is able to fully support all types of
scenarios:
S1: play recording announcement at the beginning of an inbound call before
the call is being connected to called party (in most cases the call is
simple routed through an IVR)
S2: play recording announcement at the beginning of an outbound call
automatically (I have never seen this scenario working, because playing the
announcement before the called party picks up is something achievable, but
no one wants start a conversation by listening to an automatic prompt if
she/he is the called party)
S3: play recording announcement when the party in control actually starts
the recording or pauses or restarts it during a single call (only conference
based recorders are able to support this requirement currently)
S4: visually notify the parties in a video call/conference (all previous
scenarios apply)
S5: providing recording tone or continuous visual sign during the recording
(all previous scenarios apply)

Based on the above items, it would be great if the telephony platform
vendors would implement this functionality in the endpoints (as indicated in
the requirements draft). In my opinion, the endpoint is the only place,
where all types of scenarios can be supported in the most efficient way. 
I can also imagine a system, where all configuration options regarding this
functionality resides on the telephony platform, since the RC is always
aware of the current state of the recording session (even in the case of
persistent recording the telephony system knows that it is turned on or off
when a given call starts). 

Regards,
Gabor

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 25 Mar 2010 00:23:14 -0400

Well if it says “your call may be recorded”, it means exactly that: it may be.  So if you have privacy concerns, assume that it will and hang up.  What’s the problem?

-hadriel

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Deepanshu Gautam
Sent: Wednesday, March 24, 2010 11:39 PM
To: 'Gabor Moczar'; [email-masked]
Subject: Re: [siprec] Comments on recording notification and audio injection

I DO NOT HAVE any problems, what so ever, with the existence of this requirement. I can understand very well that this is something which SIPREC must work on.

A message in the beginning of the call saying "The call may be recorded ...". As an end user i want to know *FOR SURE* whether you are going to record (in between or at the end) my call not, so that i can decided whether to continue with the call or not (i may have some privacy concerns which i don't want to take risk for, in case you want to record).

>It is a very common use case. On demand recording in most systems allows the users to record the entire call even if the user is decided to record it in the middle of the call (or even after >the call is finished).

I'm not very sure about it being *very* common. It may suffer from some user privacy concerns (as mentioned above in round bracket).
In the case of on-demand recording, i would rather prefer a message saying "A recording request is being made...." in the middle of the call (when RS or RC actually initiate the recording). In this case the call will be recorded from the specific point (when it is requested) onward, not the entier call (also, this is my understanding of the related description in the draft, unless it is changed/modified).

Regards
Deepanshu

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gabor Moczar
Sent: 2010年3月24日 20:10
To: [email-masked]
Subject: [siprec] Comments on recording notification and audio injection
I would like to share some comments I have about the REQ-024 and the proposed audio injection functionality.
Before doing it, let me provide you some background information about the key drivers behind this function.
Notifying the end users of a call that the session in which they are participating is being recorded is mandatory by the law in most countries. It varies country by country or state by state (in the USA), but in most cases the system has to announce (or one the call participant), that the call is being recorded. In addition to the voice announcement, some regulations also require to play a so called recording tone during the call. This "beep" tone is played periodically to all parties in the call, indicating that call recording is turned on. The frequency and the period may change country by country (http://www.itu.int/ITU-T/inr/forms/files/tones-0203.pdf).
According to my past experience, meeting regulatory requirements regarding announcements and tones was always a big headache. None of the telephony platforms, I am familiar with, is able to fully support all types of scenarios:
S1: play recording announcement at the beginning of an inbound call before the call is being connected to called party (in most cases the call is simple routed through an IVR)
S2: play recording announcement at the beginning of an outbound call automatically (I have never seen this scenario working, because playing the announcement before the called party picks up is something achievable, but no one wants start a conversation by listening to an automatic prompt if she/he is the called party)
S3: play recording announcement when the party in control actually starts the recording or pauses or restarts it during a single call (only conference based recorders are able to support this requirement currently)
S4: visually notify the parties in a video call/conference (all previous scenarios apply)
S5: providing recording tone or continuous visual sign during the recording (all previous scenarios apply)

Based on the above items, it would be great if the telephony platform vendors would implement this functionality in the endpoints (as indicated in the requirements draft). In my opinion, the endpoint is the only place, where all types of scenarios can be supported in the most efficient way.
I can also imagine a system, where all configuration options regarding this functionality resides on the telephony platform, since the RC is always aware of the current state of the recording session (even in the case of persistent recording the telephony system knows that it is turned on or off when a given call starts).

Some hints for Nathan's and Deepanshu's comments:
>2. Regarding REQ-024, it would be nice to be able to specify which specific leg of the communications has media injection.  For example, only the external caller should hear recorded >messages or beep tones.  It would be nice to be able to play a message at the start of the session even if the session is not being initially recorded (in case recording starts mid-session)
 >>Sorry for the clarification: but, do you mean to indicate to the end user that the session they are going to participate in MAY BE recorded in future?
Yes. It is a very common use case. On demand recording in most systems allows the users to record the entire call even if the user is decided to record it in the middle of the call (or even after the call is finished). In this case the announcement looks like "The call may be recorded ..." in the beginning of the call.

Regards,
Gabor

---

From: Deepanshu Gautam <[email-masked]>
Date: Thu, 25 Mar 2010 15:33:54 +0800

The problem is:

The call may be equally important to me, so i need to know exactly WHEN/IF
the recording is to be started, and then i'll hang-up.

Note: we are talking about mid-session (on-demand) recording.

Regards
Deepanshu

  _____

From: Hadriel Kaplan [mailto:[email-masked]]
Sent: 2010年3月25日 12:23
To: Deepanshu Gautam; 'Gabor Moczar'; [email-masked]
Subject: RE: [siprec] Comments on recording notification and audio injection

Well if it says “your call may be recorded”, it means exactly that: it may
be.  So if you have privacy concerns, assume that it will and hang up.
What’s the problem?

-hadriel

  _____

Deepanshu Gautam

Regards

Deepanshu

  _____

Regards,

Gabor

---

From: Nathan Kryger <[email-masked]>
Date: Thu, 25 Mar 2010 08:40:21 -0700 (PDT)

I can honestly appreciate your concern here but realistically, the owner of the recording equipment is only likely to turn on notification in cases where it is required by law.  The end user is not always going to have the ability to choose if they want the call recorded or not and they are not always going to know.  Since different countries/states/localities have different laws regarding this, we should make sure that whatever we come up with has the ability to meet as many of those requirements as possible and then stop at that.

Nathan

________________________________
From: Deepanshu Gautam <[email-masked]>
To: Gabor Moczar <[email-masked]>; [email-masked]
Sent: Wed, March 24, 2010 8:38:42 PM
Subject: Re: [siprec] Comments on recording notification and audio injection

I 
DO NOT HAVE any problems, what so ever, with the existence of this 
requirement. I can understand very well that this is something which SIPREC must 
work on.

A 
message in the beginning of the call saying "The call may be recorded ...". As 
an end user i want to know *FOR SURE* whether you are going to record (in 
between or at the end) my call not, so that i can decided whether to 
continue with the call or not (i may have some privacy concerns which i don't 
want to take risk for, in case you want to record).
 
>It is a very common use case. On demand recording in most systems 
allows the users to record the entire call even if the user is decided to record 
it in the middle of the call (or even after >the call is 
finished).
 
I'm not very sure about it being *very* common. It may suffer from some user 
privacy concerns (as mentioned above in round bracket). 
In the case of on-demand recording, i would rather prefer a message 
saying "A recording request is being made...." in the middle of the call (when 
RS or RC actually initiate the recording). In this case the call will be 
recorded from the specific point (when it is requested) onward, not the 
entier call (also, this is my understanding of the related description in the 
draft, unless it is changed/modified).
 
Regards
Deepanshu

________________________________
 From: [email-masked] 
[mailto:[email-masked]] On Behalf Of Gabor 
Moczar
Sent: 2010年3月24日 20:10
To: [email-masked]
Subject: [siprec] Comments on recording notification 
and audio injection

I would like to share some comments I have about the REQ-024 and the 
proposed audio injection functionality.
Before doing it, let me provide you some background information about the 
key drivers behind this function.
Notifying the end users of a call that the session in which they 
are participating is being recorded is mandatory by the law in 
most countries. It varies country by country or state by state 
(in the USA), but in most cases the system has to announce (or one the call 
participant), that the call is being recorded. In addition to the voice 
announcement, some regulations also require to play a so called recording tone 
during the call. This "beep" tone is played periodically to all parties in the 
call, indicating that call recording is turned on. The frequency and the period 
may change country by country (http://www.itu.int/ITU-T/inr/forms/files/tones-0203.pdf).
According to my past experience, meeting regulatory requirements regarding 
announcements and tones was always a big headache. None of the telephony 
platforms, I am familiar with, is able to fully support all types of 
scenarios:
S1: play recording announcement at the beginning of an inbound call before 
the call is being connected to called party (in most cases the call is simple 
routed through an IVR)
S2: play recording announcement at the beginning of an outbound 
call automatically (I have never seen this scenario working, because 
playing the announcement before the called party picks up is something 
achievable, but no one wants start a conversation by listening to an automatic 
prompt if she/he is the called party)
S3: play recording announcement when the party in control actually starts 
the recording or pauses or restarts it during a single call (only conference 
based recorders are able to support this requirement currently)
S4: visually notify the parties in a video call/conference (all previous 
scenarios apply)
S5: providing recording tone or continuous visual sign during the 
recording (all previous scenarios apply)

Based on the above items, it would be great if the telephony platform 
vendors would implement this functionality in the endpoints (as indicated in the 
requirements draft). In my opinion, the endpoint is the only place, where all 
types of scenarios can be supported in the most efficient 
way. 
I can also imagine a system, where all configuration options regarding this 
functionality resides on the telephony platform, since the RC is always aware of 
the current state of the recording session (even in the case 
of persistent recording the telephony system knows that it is turned 
on or off when a given call starts). 

Some hints for Nathan's and Deepanshu's comments:
>2. 
Regarding REQ-024, it would be nice to be able to specify which specific leg of 
the communications has media injection.  For example, only the external 
caller should hear recorded >messages or beep tones.  It would be nice 
to be able to play a message at the start of the session even if the session is 
not being initially recorded (in case recording starts 
mid-session)
 >>Sorry for the clarification: but, do you mean to 
indicate to the end user that the session they are going to participate in 
MAY BE recorded in future?
Yes. 
It is a very common use case. On demand recording in most systems allows the 
users to record the entire call even if the user is decided to record it in the 
middle of the call (or even after the call is finished). In this case the 
announcement looks like "The call may be recorded ..." in the beginning of the 
call. 

Regards,
Gabor

---

From: Deepanshu Gautam <[email-masked]>
Date: Fri, 26 Mar 2010 16:10:33 +0800

Sorry can't stop my fingures going towards the keyboard :-)
 
The current requirement uses "MUST". So, i guess user WILL BE informed in
case a recording is initiated, unless it is changed or some additions are
made.
 
Anyway, lets discuss this when we'll have a specific proposal to change the
draft.
 
Regards
Deepanshu
 
 From: Nathan Kryger [mailto:[email-masked]] 
Sent: 2010年3月25日 23:40
To: Deepanshu Gautam; Gabor Moczar; [email-masked]
Subject: Re: [siprec] Comments on recording notification and audio injection

I can honestly appreciate your concern here but realistically, the owner of
the recording equipment is only likely to turn on notification in cases
where it is required by law.  The end user is not always going to have the
ability to choose if they want the call recorded or not and they are not
always going to know.  Since different countries/states/localities have
different laws regarding this, we should make sure that whatever we come up
with has the ability to meet as many of those requirements as possible and
then stop at that.

Nathan

  _____  

 

 
 
Regards
Deepanshu

  _____  

Regards,
Gabor

---

From: Nathan Kryger <[email-masked]>
Date: Fri, 26 Mar 2010 13:39:41 -0700 (PDT)

I see what you mean.  I'm not sure if the MUST in this case means that the RS/RC must always inject media to indicate recording or that it MUST have mechanism in place that can be configured to do that.  I feel that if it is the former, it would limit adoption of this because many potential users of this such as contact centers already have other ways such as IVR's to notify people of recording and there are some localities that do not have notification requirements at all.  Perhaps one of the original authors can comment on this.

Nathan

________________________________
From: Deepanshu Gautam <[email-masked]>
To: Nathan Kryger <[email-masked]>; Gabor Moczar <[email-masked]>; [email-masked]
Sent: Fri, March 26, 2010 1:10:33 AM
Subject: RE: [siprec] Comments on recording notification and audio injection

Sorry can't stop my fingures going towards the keyboard 
:-)
 
The current requirement uses "MUST". So, i guess user WILL 
BE informed in case a recording is initiated, unless it is changed or some 
additions are made.
 
Anyway, lets discuss this when we'll have a specific 
proposal to change the draft.
 
Regards
Deepanshu
 
 From: Nathan Kryger 
[mailto:[email-masked]] 
Sent: 2010年3月25日 23:40
To: Deepanshu Gautam; Gabor Moczar; [email-masked]
Subject: Re: [siprec] 
Comments on recording notification and audio 
injection

I can honestly appreciate your concern here but realistically, the owner of 
the recording equipment is only likely to turn on notification in cases where it 
is required by law.  The end user is not always going to have the ability 
to choose if they want the call recorded or not and they are not always going to 
know.  Since different countries/states/localities have different laws 
regarding this, we should make sure that whatever we come up with has the 
ability to meet as many of those requirements as possible and then stop at 
that.

Nathan

________________________________
 From: Deepanshu Gautam 
<[email-masked]>
To: Gabor Moczar <[email-masked]>; 
[email-masked]
Sent: Wed, 
March 24, 2010 8:38:42 PM
Subject: Re: [siprec] Comments on recording 
notification and audio injection

I 

A 

 
Regards
Deepanshu

Regards,
Gabor

---

From: Anish Mehra <[email-masked]>
Date: Fri, 26 Mar 2010 17:10:48 -0400

Couple of comments/questions –

1.      Sorry to go back to couple of posts but I am actually wondering why these policy/compliance related announcements (media injection) are even in scope. As pointed by Nathan, media injection is a common function in contact centers performed by other components in the call flow – IVRs, Switch prompts. Why should that even be a function of recording device? Yes there are privacy concerns in some countries but a more common scenario is “Stop Recording On Demand” where you can always assume a call to be recorded (with an up-front announcement from a device)  but the caller should be able to request to stop the recording mid-stream if desired. I feel that limiting the scope to recording and recording only will keep it simple –“separation-of- concerns”

2.      There could also be a need to add business data to a recording – during or after the call. This business data could come from variety of sources including other systems like CRM applications. Does the “Metadata” as described in requirements cover for such a scenario?

Thanks,
Anish

From: [email-masked] [mailto:[email-masked]] On Behalf Of Nathan Kryger
Sent: Friday, March 26, 2010 4:40 PM
To: Deepanshu Gautam; Gabor Moczar; [email-masked]
Subject: Re: [siprec] Comments on recording notification and audio injection

Nathan

The current requirement uses "MUST". So, i guess user WILL BE informed in case a recording is initiated, unless it is changed or some additions are made.

Anyway, lets discuss this when we'll have a specific proposal to change the draft.

Regards
Deepanshu

Nathan

Regards
Deepanshu

Regards,
Gabor

________________________________
NOTICE: The information contained in this electronic mail transmission is intended by Convergys Corporation for the use of the named individual or entity to which it is directed and may contain information that is privileged or otherwise confidential. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or by telephone (collect), so that the sender's address records can be corrected.

---

From: Gabor Moczar <[email-masked]>
Date: Mon, 29 Mar 2010 11:48:43 +0200

I think there is a misunderstanding. The REQ-024 refers to the RC (Recording
Client), which is the "endpoint" being recorded. I don't think that the RS
(Recording Server) should do any media injection (that would be a potential
security problem). In my earlier post, I tried to describe the gap between
the requirements of the customers and the available functions of telephony
systems. This gap can be easily overcome with enabling recording
announcement and tone generation at the recorded endpoints. And since the
upcoming SIPREC standard has a "leg" in the endpoints (RC), it
sounds fairly logical to me to include announcement and tone generation
requirements there too.

Regards,
Gabor

On Fri, Mar 26, 2010 at 11:10 PM, Anish Mehra <[email-masked]>wrote:

>  Couple of comments/questions -
>
>
>
> 1.      Sorry to go back to couple of posts but I am actually wondering
> why these policy/compliance related announcements (media injection) are even
> in scope. As pointed by Nathan, media injection is a common function in
> contact centers performed by other components in the call flow - IVRs,
> Switch prompts. Why should that even be a function of recording device? Yes
> there are privacy concerns in some countries but a more common scenario is
> “Stop Recording On Demand” where you can always assume a call to be recorded
> (with an up-front announcement from a device)  but the caller should be able
> to request to stop the recording mid-stream if desired. I feel that limiting
> the scope to recording and recording only will keep it simple
> -“separation-of- concerns”
>
> 2.      There could also be a need to add business data to a recording -
> during or after the call. This business data could come from variety of
> sources including other systems like CRM applications. Does the “Metadata”
> as described in requirements cover for such a scenario?
>
>
>
> Thanks,
>
> Anish
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Nathan Kryger
> *Sent:* Friday, March 26, 2010 4:40 PM
>
> *To:* Deepanshu Gautam; Gabor Moczar; [email-masked]
> *Subject:* Re: [siprec] Comments on recording notification and audio
> injection
>
>
>
> I see what you mean.  I'm not sure if the MUST in this case means that the
> RS/RC must always inject media to indicate recording or that it MUST have
> mechanism in place that can be configured to do that.  I feel that if it is
> the former, it would limit adoption of this because many potential users of
> this such as contact centers already have other ways such as IVR's to notify
> people of recording and there are some localities that do not have
> notification requirements at all.  Perhaps one of the original authors can
> comment on this.
>
>
>
> Nathan
>
>
>  ------------------------------
>
> *From:* Deepanshu Gautam <[email-masked]>
> *To:* Nathan Kryger <[email-masked]>; Gabor Moczar <[email-masked]>;
> [email-masked]
> *Sent:* Fri, March 26, 2010 1:10:33 AM
> *Subject:* RE: [siprec] Comments on recording notification and audio
> injection
>
>  *From:* Nathan Kryger [mailto:[email-masked]]
> *Sent:* 2010年3月25日 23:40
> *To:* Deepanshu Gautam; Gabor Moczar; [email-masked]
> *Subject:* Re: [siprec] Comments on recording notification and audio
> injection
>
>   ------------------------------
>
> *From:* Deepanshu Gautam <[email-masked]>
> *To:* Gabor Moczar <[email-masked]>; [email-masked]
> *Sent:* Wed, March 24, 2010 8:38:42 PM
> *Subject:* Re: [siprec] Comments on recording notification and audio
> injection
>
> I'm not very sure about it being *very* common. It may suffer from some
> user privacy concerns (as mentioned above in round bracket).
>
>  ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Gabor Moczar
> *Sent:* 2010年3月24日 20:10
> *To:* [email-masked]
> *Subject:* [siprec] Comments on recording notification and audio injection
>
> >2. Regarding REQ-024, it would be nice to be able to specify which
> specific leg of the communications has media injection.  For example, only
> the external caller should hear recorded >messages or beep tones.  It would
> be nice to be able to play a message at the start of the session even if the
>  >>Sorry for the clarification: but, do you mean to indicate to the end
> user that the session they are going to participate in MAY BE recorded in
> future?
>
> ------------------------------
> NOTICE: The information contained in this electronic mail transmission is
> intended by Convergys Corporation for the use of the named individual or
> entity to which it is directed and may contain information that is
> privileged or otherwise confidential. If you have received this electronic
> mail transmission in error, please delete it from your system without
> copying or forwarding it, and notify the sender of the error by reply email
> or by telephone (collect), so that the sender's address records can be
> corrected.
>