Subject: [siprec] record-aware options tag

From: "Henry Lum" <[email-masked]>
Date: Mon, 4 Jul 2011 08:14:43 -0700

Following up on an issue from the interim meeting about the obligations
for recording aware UA. I think it would be sufficient to require that a
recording aware UA to indicate two things: 1) that it is recording-aware
by adding the record-aware options tag in the Supported header; 2)
provide recording indications with the a=record SDP attribute. Some
types of UA such as PSTN gateways may have local policies to provide
recording indications through other means such as inband
tones/announcements, but they are in addition to the a=record SDP
attribute.

Would such text be sufficient?

Regards,

Henry

-------------------------------------------------------------------------------------------------------------------
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: Leon Portman <[email-masked]>
Date: Mon, 4 Jul 2011 19:38:01 +0300

Do we also want to add some kind of indication if such recording aware UA introduces recording tone in the media, in order not to allow multiple media injections if more than one in the communication path?

Leon

From: [email-masked] [mailto:[email-masked]] On Behalf Of Henry Lum
Sent: Monday, July 04, 2011 6:15 PM
To: [email-masked]
Subject: [siprec] record-aware options tag

Following up on an issue from the interim meeting about the obligations for recording aware UA. I think it would be sufficient to require that a recording aware UA to indicate two things: 1) that it is recording-aware by adding the record-aware options tag in the Supported header; 2) provide recording indications with the a=record SDP attribute. Some types of UA such as PSTN gateways may have local policies to provide recording indications through other means such as inband tones/announcements, but they are in addition to the a=record SDP attribute.

Regards,
Henry

---

From: "Henry Lum" <[email-masked]>
Date: Mon, 4 Jul 2011 11:39:58 -0700

This is similar to negotiating or indicating which SRC will be recording
and the same question has been raised on the other thread about SDP
recording attributes. I think we are in agreement that it is not the
goal to indicate/negotiate multiple SRCs in the call path because this
can get quite complex...

Henry

From: Leon Portman [mailto:[email-masked]] 
Sent: July-04-11 12:38 PM
To: Henry Lum; [email-masked]
Subject: RE: record-aware options tag

Do we also want to add some kind of indication if such recording aware
UA introduces recording tone in the media, in order not to allow
multiple media injections if more than one in the communication path?

Leon

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henry Lum
Sent: Monday, July 04, 2011 6:15 PM
To: [email-masked]
Subject: [siprec] record-aware options tag

Regards,

Henry

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: "Elwell, John" <[email-masked]>
Date: Tue, 5 Jul 2011 17:01:30 +0200

My interpretation of what the meeting wanted was text along the following lines.

"A UA that has indicated recording awareness by including the record-aware option tag in a transmitted Supported header field MUST provide at its user interface an indication whether recording is on or off for a given medium based on the most recently received a=record SDP attribute for that medium."

I am not sure whether this is sufficient or whether we need to say more. For example, an automaton (such as a media server) would not have a user interface. A UA that is a conference focus might need to pass it on somehow to other participants. A UA that is a PSTN gateway would need to play a tone or announcement. Of course, a UA can avoid such an obligation by not sending this option tag in Supported, thereby relying on the SRC to do the necessary (e.g., play a tone or announcement in the case of audio).

In addition, we would need some normative statement for an SRC. Clearly it would be obliged to take action if the UA has not indicated recording awareness.

John (as individual)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Henry Lum
> Sent: 04 July 2011 16:15
> To: [email-masked]
> Following up on an issue from the interim meeting about the 
> obligations for recording aware UA. I think it would be 
> sufficient to require that a recording aware UA to indicate 
> two things: 1) that it is recording-aware by adding the 
> record-aware options tag in the Supported header; 2) provide 
> recording indications with the a=record SDP attribute. Some 
> types of UA such as PSTN gateways may have local policies to 
> provide recording indications through other means such as 
> inband tones/announcements, but they are in addition to the 
> a=record SDP attribute.
> 
>  
> 
> 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: "Henry Lum" <[email-masked]>
Date: Fri, 15 Jul 2011 08:18:42 -0700

I added some text in the latest protocol draft (05) in section 6.2 about
how to handle record awareness for automatons:

   "Some user agents that are automatons (eg.  IVR, media server, PSTN
   gateway) may not have an user interface to render recording
   indication.  When such user agent indicates recording awareness,
   these UA may render recording indication through other means, such as
   passing an inband tone on the PSTN gateway, putting the recording
   indication in a log file, or raising an application event in a
   VoiceXML dialog.  These user agents may also choose not to indicate
   recording awareness, thereby relying on whatever mechansim an SRC
   chooses to indicate recording, such as playing a tone inband"

There is also some normative text on the obligation of an SRC if no
recording awareness has been indicated.

   "When a UA has not indicated that it is recording aware, an SRC must
   provide recording indications, where SRC is required to do so based
   on policies, through other means such as playing a tone inband."

Would the above text be sufficient?

Regards,
Henry

> From: Elwell, John [mailto:[email-masked]]
> Sent: Tuesday, July 05, 2011 11:01 AM
> "A UA that has indicated recording awareness by including the record-
> aware option tag in a transmitted Supported header field MUST provide
> at its user interface an indication whether recording is on or off for
> a given medium based on the most recently received a=record SDP
> attribute for that medium."
> 
> I am not sure whether this is sufficient or whether we need to say
> more. For example, an automaton (such as a media server) would not
have
> a user interface. A UA that is a conference focus might need to pass
it
> on somehow to other participants. A UA that is a PSTN gateway would
> need to play a tone or announcement. Of course, a UA can avoid such an
> obligation by not sending this option tag in Supported, thereby
relying
> on the SRC to do the necessary (e.g., play a tone or announcement in
> the case of audio).
> 
> In addition, we would need some normative statement for an SRC.
Clearly
> it would be obliged to take action if the UA has not indicated
> recording awareness.
> 
> John (as individual)
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Jul 2011 11:40:51 -0400

> Would the above text be sufficient?

This is tricky, because ultimately what is required is all based on 
local policy. AFAICT all this is saying is "An SRC must do what its 
local policy requires it to do".

Perhaps this could be strengthened as follows:

    "When a UA has not indicated that it is recording aware, an SRC must
    provide recording indications via the media streams, unless local
    policy specifies some other means of indication."

To a lawyer I don't think that is *any* stronger. But it *sounds* 
stronger. :-)

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Sun, 17 Jul 2011 12:57:48 +0300

The question is if the revised statement does not open a loophole for local policy "not to indicate at all". And we don't want that

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, July 15, 2011 6:41 PM
To: [email-masked]
Subject: Re: [siprec] record-aware options tag

> Would the above text be sufficient?

This is tricky, because ultimately what is required is all based on local policy. AFAICT all this is saying is "An SRC must do what its local policy requires it to do".

To a lawyer I don't think that is *any* stronger. But it *sounds* stronger. :-)

	Thanks,
	Paul
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 17 Jul 2011 13:05:26 -0400

> The question is if the revised statement does not open a loophole for local policy "not to indicate at all". And we don't want that

I think the two statements both have that possibility to the same 
degree. Is there a way to leave it to policy and not have that possibility?

And I think there are contexts in which the potential for recording is 
always known to be present and no further indication is required. For 
instance that is usually the situation with call center agent 
participants in call center calls.

Perhaps we could add something about compliance with legal requirements. 
But I'm reluctant to go that way.

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Mon, 18 Jul 2011 11:14:12 +0300

I agree, there are multiple ways to indicate recording, like announcements etc. This whole discussion is less relevant to protocols and standards and more to policies, legalities and IETF RAVEN stuff.

Leon

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Sunday, July 17, 2011 8:05 PM
To: Leon Portman
Cc: [email-masked]
Subject: Re: [siprec] record-aware options tag

On 7/17/11 5:57 AM, Leon Portman wrote:
> The question is if the revised statement does not open a loophole for 
> local policy "not to indicate at all". And we don't want that

I think the two statements both have that possibility to the same degree. Is there a way to leave it to policy and not have that possibility?

And I think there are contexts in which the potential for recording is always known to be present and no further indication is required. For instance that is usually the situation with call center agent participants in call center calls.

	Thanks,
	Paul

---

From: "Avasarala, Ranjit" <[email-masked]>
Date: Tue, 19 Jul 2011 02:06:33 +0800

Hi all
Are there any suggestions for option-tags to use for indicating that the session is to be recorded? E.g. record. 
E.g.  "Require: record" could be used to indicate that a particular session should be recorded.

Thanks

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Leon Portman
Sent: Monday, July 18, 2011 1:44 PM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [siprec] record-aware options tag

Leon

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Sunday, July 17, 2011 8:05 PM
To: Leon Portman
Cc: [email-masked]
Subject: Re: [siprec] record-aware options tag

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Jul 2011 16:30:23 -0400

> E.g.  "Require: record" could be used to indicate that a particular session should be recorded.

That is a whole different thing!

Option tags aren't really suitable for that, for a number of reasons:
- Require:foo is to fail unless the UAS *supports* foo, but has no
   implication that foo be used. So in this case it could ensure that the
   UAS was *capable* of recording, but not that it *is* recording.

- This doesn't say anything about *what* is recorded, where it is
   recorded, how one might access the recording, etc.

ISTM that requesting a recording is a complex process, something on the 
order of configuring a conference focus. Among other things, just 
ensuring that there in an SRC on the path to the callee may not be 
trivial. If we want to do that then I think it is a separate deliverable.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 19 Jul 2011 10:49:12 +0200

Ranjit,

Past discussions seem to have led to the following consensus:
- We will not specify a means for a UA in a CS to "require" that the CS be recorded.
- We will specify means for a UA in a CS to express a preference whether or not to record, but this will not be binding on any SRC.
- This preference will be expressed on a per medium level, and therefore in SDP (as currently proposed in the draft).

It would be good to avoid opening up this issue again unless you have new technical arguments.

Thanks,

John (as chair)

> [mailto:[email-masked]] On Behalf Of Avasarala, Ranjit
> Sent: 18 July 2011 19:07
> To: Leon Portman; Paul Kyzivat
> Cc: [email-masked]
> Are there any suggestions for option-tags to use for 
> indicating that the session is to be recorded? E.g. record. 
> [mailto:[email-masked]] On Behalf Of Leon Portman
> I agree, there are multiple ways to indicate recording, like 
> announcements etc. This whole discussion is less relevant to 
> protocols and standards and more to policies, legalities and 
> IETF RAVEN stuff.
> 
> Leon
> 
> I think the two statements both have that possibility to the 
> same degree. Is there a way to leave it to policy and not 
> have that possibility?
> 
> And I think there are contexts in which the potential for 
> recording is always known to be present and no further 
> indication is required. For instance that is usually the 
> situation with call center agent participants in call center calls.
> 
> > This is tricky, because ultimately what is required is all 
> based on local policy. AFAICT all this is saying is "An SRC 
> must do what its local policy requires it to do".
> >

---

From: "Avasarala, Ranjit" <[email-masked]>
Date: Tue, 19 Jul 2011 18:45:55 +0800

Hi John

So how do I indicate to the SRS that a particular session has to recorded at the beginning of the session? Also say I want to begin recording at some point in the session or end it at some point in between, how do I do this?
I feel putting all info in INVITE alone is not useful!

Regards
Ranjit

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Tuesday, July 19, 2011 2:19 PM
To: Avasarala, Ranjit; Leon Portman; Paul Kyzivat
Cc: [email-masked]
Subject: RE: [siprec] record-aware options tag

Ranjit,

Thanks,

John (as chair)

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Jul 2011 09:02:45 -0400

A UA that is determined to have a session recorded can act as an SRC.
In that case it needs no protocol mechanisms to cause that to happen.

But if a UA is determined to require that some other entity be involved 
in the call as an SRC, then I think something considerably beyond what 
we have been addressing is required.

For instance, suppose the UAC makes its request, and gets a successful 
response, but the response is from the UAS that happens to have SRC 
capabilities. The result may be a recording, but one that is 
inaccessible to the UAC. Presumably that wouldn't meet your expectations.

Perhaps the UAC could accomplish its goals by ensuring that the call is 
routed through a particular SRC it knows will meet its needs. If it does 
that it may not need any additional protocol to initiate the recording - 
it would be implied by the SRC being in the call path.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 19 Jul 2011 15:31:01 +0200

Ranjit,

You ask how to indicate to the SRS that a particular session has to be recorded. Did you really mean SRS? If so, that is achieved using the SIPREC protocol and the transfer of metadata, including updates to metadata during the session (e.g., any pausing and resuming of streams).

John 

> From: Avasarala, Ranjit [mailto:[email-masked]] 
> Sent: 19 July 2011 11:46
> To: Elwell, John; Leon Portman; Paul Kyzivat
> Cc: [email-masked]
> So how do I indicate to the SRS that a particular session has 
> to recorded at the beginning of the session? Also say I want 
> to begin recording at some point in the session or end it at 
> some point in between, how do I do this?
> - We will specify means for a UA in a CS to express a 
> preference whether or not to record, but this will not be 
> binding on any SRC.
> - This preference will be expressed on a per medium level, 
> and therefore in SDP (as currently proposed in the draft).
>