Subject: [siprec] mechansim for requesting no-record for recording aware UA

From: "Henry Lum" <[email-masked]>
Date: Mon, 31 Jan 2011 14:16:34 -0800

This is one of the issues from the interim call.

In order for a recording-aware UA to request that a call not to be
recorded, there are 3 proposed mechanisms. I want to get feedback on
which mechanism is most appropriate to meet REQ-017 and REQ-018:

1)      Use caller preference to request that a call not to be recorded

For example,

Reject-Contact: *;sip.recorded 

For a UA to request that a call not to be recorded. When the call is
being recorded, use the feature tag sip.recorded to indicate that the
call is being recorded. The mechanism is optional so this preference may
not be honored all the time. Also, the mechanism in Reject-Contact would
prevent the call from connecting there are no contacts that would not
record the call.

2)      Specify a new SIP header to indicate recording preference

Define a new option tag called no-record and use a new SIP header to
indicate recording preference in a new SIP header.

For example,

Record-Preference: record / no-record-reject / no-record-accept

record means that the caller is requesting the call to be recorded

no-record-reject means that the caller does not wish to connect the call
if the call must be recorded.

no-record-accept means that the caller does not wish to be recorded but
may establish the call is recording is enabled.

When the call is recorded, use the feature tag sip.recorded to indicate
that the call is being recorded.

3)      Define a new SDP attribute to request for either a session or
media stream not to be recorded. 

This one is suggested during the interim call and allows the caller to
indicate recording preference using a session-level or media-level
attribute. We can define two attributes:

a=recordpref:[preference]

preference = "record" / "no-record-reject" / "no-record-accept"

The meaning of the preferences are the same as 2) above.

a=record:[state]

state = "active"  / "inactive"

The first attribute is used by the user agent who wishes to indicate the
preference for recording the session. The second attribute is used to
indicate whether recording is actually active or inactive. This
mechanism also allows a user agent is allowed to send a reINVITE in the
middle of the call to change the recording preference. 

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: Paul Kyzivat <[email-masked]>
Date: Mon, 31 Jan 2011 21:21:23 -0500

Just to be clear, this is discussing how this request is indicated in 
the *CS*, right?

I *think* I prefer option 3 (in SDP) for the flexibility it gives and 
because fundamentally this is about media. However that probably won't 
say anything about whether *metadata* about the call is recorded. Do we 
care about that?

	Thanks,
	Paul

On 1/31/2011 5:16 PM, Henry Lum wrote:
> 1)Use caller preference to request that a call not to be recorded
>
> For example,
>
> 2)Specify a new SIP header to indicate recording preference
>
> 3)Define a new SDP attribute to request for either a session or media
> stream not to be recorded.
>
> preference = “record” / “no-record-reject” / “no-record-accept”
>
> state = “active” / “inactive”
>
> 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.
>
>
>
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 1 Feb 2011 08:28:51 +0100

1. One thing we need to clarify is which entity has the final say on whether recording will take place - the SRC or the SRS. In the SRC case, if no-record is requested, the SRC would not offer the session or medium to the SRS. In the SRS case, the SRC would pass the no-record request to the SRS, which would respond according to its policy. Although superficially this does not impact the choice of mechanism on the CS, the time taken to consult the SRS might possibly have some influence. For example, it might not be possible to signal the outcome in the response to the CS request that asked for no-record (c.f., discussions taking place in SIPCORE on whether, for a no-INVITE transaction, you can expect to dereference the location URL before sending the SIP response). This might be an issue for some of the proposed mechanisms for no-record.

2. Either UA in the call might request no-record, and at any stage in the call, so we cannot assume the request will be in in the initial INVITE request. If the callee UA wants to request no-record, it could do it in response to the initial INVITE request, or in a separate request. If it is in a response, we would need to use another request, in the reverse direction, to signal the outcome. Mechanisms such as caller preferences and the Require header field would not work for a response. Asking for no-record in a mid-dialog request might also have issues - I am not sure how caller preferences would apply, and use of the Require header field would perhaps not have the desired outcome. Finally, whatever mechanism we choose must be usable in 3PCC situations.

3. Do we need a mechanism whereby the CS is automatically cleared if no-record cannot be granted, or is it sufficient just to indicate this to the user concerned and leave the user to take action? Certainly if we decide that no-record can be on a per-medium basis, automatically clearing the call seems unreasonable.

John (as individual)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 01 February 2011 02:21
> To: [email-masked]
> Subject: Re: [siprec] mechansim for requesting no-record for 
> recording aware UA
>