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

From: "Henry Lum" <[email-masked]>
Date: Tue, 1 Feb 2011 07:47:53 -0800

Inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Elwell, John
> Sent: Tuesday, February 01, 2011 2:29 AM
> To: Paul Kyzivat; [email-masked]
> Subject: Re: [siprec] mechansim for requesting no-record for recording
> aware UA
> 
> 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.

[[hlum]] I think the request to honor no-record in CS and recording
policy should be decoupled; if the SRC needs to defer the decision for
handling no-record to the SRS, then we need to come up with a mechanism
to tie the establishment of a CS with an RS. This looks to me more of an
implementation decision to tie them together.

> 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.

[[hlum]] I am hoping that this mechanism don't need to deal with timing
issues between CS/RS because it needs to defer a recording decision to
the SRS. I see this as an implementation issue.
> 
> 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.
> 
[[hlum]] Yes, caller preferences and Require header needs to be in the
initial INVITE so you are right they won't work. 

> 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? 

[[hlum]] It should be desirable to allow both mechanisms. In any case,
if an endpoint does not understand the no-record preference and tries to
record, the caller would need to clear the CS manually anyways when the
caller receive indication (probably audio indication) that the call is
being recorded. 

> Certainly if
> we decide that no-record can be on a per-medium basis, automatically
> clearing the call seems unreasonable.

[[hlum]] The endpoint can reject the media stream if the endpoint does
not wish the clear the call.
> 
> 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
> >
> > 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:
> > > 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.
> > >
> > >
> > >
> > > _______________________________________________
> > > siprec mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/siprec
> > _______________________________________________
> > siprec mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/siprec
> >
> _______________________________________________
> 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: "Elwell, John" <[email-masked]>
Date: Wed, 2 Feb 2011 09:39:45 +0100

> From: Henry Lum [mailto:[email-masked]] 
> Sent: 01 February 2011 15:48
> To: Elwell, John; Paul Kyzivat; [email-masked]
> Subject: RE: [siprec] mechansim for requesting no-record for 
> recording aware UA
> 
> Inline.
> 
[JRE] So let us imagine the SRC sends a no-record indication to the SRS. At some stage there will need to be an indication on the CS as to whether the call is being recorded or not. The issue is whether that indication needs to be in response to the request conveying the no-record request, or whether it can be deferred for a later request.

John (as individual)

> --------------------------------------------------------------
> -----------------------------------------------------
> 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 
> 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 Feb 2011 09:08:05 -0500

> [JRE] So let us imagine the SRC sends a no-record indication to the SRS. At some stage there will need to be an indication on the CS as to whether the call is being recorded or not. The issue is wh…

ISTM that the caller will initially be informed (or already know) that 
the call is being recorded. He will then post a request that it *not* be 
recorded, but should continue to assume it is being recorded until 
receiving some positive confirmation that it is not. That confirmation 
may come immediately, later, or never.

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 2 Feb 2011 06:34:12 -0800

Yes, I think the confirmation or indication of recording is independent
of the no-record preference. Of course, unless the caller specifically
requests that the call to be rejected if no-record cannot be honoured
but then this type of request needs to be made when the call is placed.

Henry

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: February-02-11 9:08 AM
> To: Elwell, John
> Cc: Henry Lum; [email-masked]
> > [JRE] So let us imagine the SRC sends a no-record indication to the
SRS. At
> some stage there will need to be an indication on the CS as to whether
the
> call is being recorded or not. The issue is whether that indication
needs to be
> in response to the request conveying the no-record request, or whether
it
> can be deferred for a later request.
> 
the call is
> being recorded. He will then post a request that it *not* be recorded,
but
> should continue to assume it is being recorded until receiving some
positive
> confirmation that it is not. That confirmation may come immediately,
later, or
> never.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Feb 2011 11:47:37 -0500

> but then this type of request needs to be made when the call is placed.

I think the best we could do for *that* is to reject the call if there 
will be an RS. But even then, who is responsible for honoring that request?

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 2 Feb 2011 18:18:44 +0100

Paul,

That would be fine with me - I just wanted to make sure we understood the implications.

John (as individual)

> Sent: 02 February 2011 14:08
> To: Elwell, John
> > [JRE] So let us imagine the SRC sends a no-record 
> indication to the SRS. At some stage there will need to be an 
> indication on the CS as to whether the call is being recorded 
> or not. The issue is whether that indication needs to be in 
> response to the request conveying the no-record request, or 
> whether it can be deferred for a later request.
>

---

From: "Dave Smith" <[email-masked]>
Date: Wed, 2 Feb 2011 11:20:30 -0800

Can we rely on the implementation associated with REQ-018 to address
that confirmation?

o REQ-018 The mechanism MUST provide a means of indicating to the
   participants involved in a CS that their session is being recorded.

Regards,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Wednesday, February 02, 2011 6:08 AM
To: Elwell, John
Cc: [email-masked]; Henry Lum
Subject: Re: [siprec] mechansim for requesting no-record for recording
aware UA

> [JRE] So let us imagine the SRC sends a no-record indication to the
SRS. At some stage there will need to be an indication on the CS as to
whether the call is being recorded or not. The issue is whether that
indication needs to be in response to the request conveying the
no-record request, or whether it can be deferred for a later request.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Feb 2011 16:16:22 -0500

>     participants involved in a CS that their session is being recorded.

That doesn't currently require a mechanism to indicate that you are 
*not* being recorded.

The indication that you are being recorded might be a one-time thing 
rather than a continuous thing. In that case its absence doesn't mean 
you are not being recorded.

	Thanks,
	Paul