Subject: [siprec] FW: I-D Action:draft-johnston-siprec-cc-rec-00.txt

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 6 Jul 2010 09:07:05 +0200

FYI

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 03 July 2010 15:45
To: [email-masked]
Subject: I-D Action:draft-johnston-siprec-cc-rec-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : SIP Call Control - Recording Extensions
	Author(s)       : A. Johnston, A. Hutton
	Filename        : draft-johnston-siprec-cc-rec-00.txt
	Pages           : 7
	Date            : 2010-07-03

This document defines SIP extensions for session recording to meet
the requirements in the "Requirements for SIP-based Media Recording
(SIPREC)" document.  In particular, mechanisms to allow SIP elements
to distinguish between the Recording Session and the Communication
Session.  Also a mechanism for a UA to learn that the communication
session is being recorded is proposed.  The Metadata about the
session is not covered by this document.  SIP feature tags 'srs',
'src', and 'recorded' are defined to identify the Session Recording
Server, Session Recording Client, and the presence of recording in
the communication session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-johnston-siprec-cc-rec-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1qb2huc3Rvbi1zaXByZWMtY2MtcmVjLTAwLnR4dA0K

---

From: Leon Portman <[email-masked]>
Date: Tue, 6 Jul 2010 12:51:57 +0300

Hello,

My comments for the draft.

Section 4.3. My interpretation of REQ-023 "The mechanism MUST support a means for a SIP UA to request
that a session is not recorded" was that recording is should not to be allowed and however it is presented in section 4.3 that call will be disconnected if recording is initiated. So I think that adding "norecord" tag is mandatory for not initiating recording without blocking the call after the fact.
Actually do we want add additional requirement into the requirement draft that will require support for this flow as well (dropping the call)?

Additional comment: do we also want to define a tag "required recording" in the original CS that will trigger recording request between SRC and SRS?

Leon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hutton, Andrew
Sent: Tuesday, July 06, 2010 10:07 AM
To: [email-masked]
Subject: [siprec] FW: I-D Action:draft-johnston-siprec-cc-rec-00.txt

FYI

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 03 July 2010 15:45
To: [email-masked]
Subject: I-D Action:draft-johnston-siprec-cc-rec-00.txt 

This document defines SIP extensions for session recording to meet the requirements in the "Requirements for SIP-based Media Recording (SIPREC)" document.  In particular, mechanisms to allow SIP elements to distinguish between the Recording Session and the Communication Session.  Also a mechanism for a UA to learn that the communication session is being recorded is proposed.  The Metadata about the session is not covered by this document.  SIP feature tags 'srs', 'src', and 'recorded' are defined to identify the Session Recording Server, Session Recording Client, and the presence of recording in the communication session.

Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 7 Jul 2010 09:40:25 -0700

A few comments:

- I think the document should organize the feature tags by the types of
sessions (Recording or Communication sessions). For example, group src
and srs for Recording Sessions, and group recorded/norecord feature tags
for Communication Sessions.
- Should we also define a tag to request (but not require) recording?
Doing so means that we also need to provide a mechanism to tell the UA
that the recording has not been started but the CS is still established.

Regards,
Henry

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Leon Portman
> Sent: Tuesday, July 06, 2010 5:52 AM
> To: Hutton, Andrew; [email-masked]
> Subject: Re: [siprec] FW: I-D Action:draft-johnston-siprec-cc-rec-
> 00.txt
> 
> Hello,
> 
> Section 4.3. My interpretation of REQ-023 "The mechanism MUST support
a
> means for a SIP UA to request
> that a session is not recorded" was that recording is should not to be
> allowed and however it is presented in section 4.3 that call will be
> disconnected if recording is initiated. So I think that adding
> "norecord" tag is mandatory for not initiating recording without
> blocking the call after the fact.
> Actually do we want add additional requirement into the requirement
> draft that will require support for this flow as well (dropping the
> call)?
> 
> Additional comment: do we also want to define a tag "required
> recording" in the original CS that will trigger recording request
> between SRC and SRS?
> 
> Leon
> 
> From: [email-masked] [mailto:i-d-announce-
> [email-masked]] On Behalf Of [email-masked]
> Sent: 03 July 2010 15:45
> This document defines SIP extensions for session recording to meet the
> requirements in the "Requirements for SIP-based Media Recording
to
> distinguish between the Recording Session and the Communication
> session is being recorded is proposed.  The Metadata about the session
> is not covered by this document.  SIP feature tags 'srs', 'src', and
> 'recorded' are defined to identify the Session Recording Server,
> Session Recording Client, and the presence of recording in the
> communication session.
> 
> _______________________________________________
> 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, 07 Jul 2010 15:13:43 -0400

> for Communication Sessions.

I'm still mulling over whether I like using feature tags for this vs. 
something else. I think feature tag is right for the SRS, though maybe 
not this tag. Its possible that actor=msg-taker would be sufficient 
here, perhaps in conjunction with an Accept of some format used to 
encode the metadata. (Or an Info-Package for same purpose.)

I'm not yet convinced its necessary for the SRC to be identified. AFAIK 
the worst that can happen is that it won't deliver any metadata. The SRS 
could eventually drop any caller that does that. If it is needed, 
another value for Actor might be appropriate, rather than a new tag.

The use of a feature tag for 'recorded' is bothering me more.
Feature tags in this sort of use are attached to Contact URIs, and 
should be viewed as describing the features of the thing designated by 
that URI. In the case where one of the UAs in the CS is the SRC, then I 
think this would be ok.

But when the SRC is in the call as a B2BUA it gets questionable. If the 
B2BUA uses its own URI as contact when establishing the CS then its 
technically ok. If it acts more like a proxy - passing through the 
Contact from the other end and just record-routing to stay in the call - 
then it is certainly wrong for it to add this feature tag to the contact 
URI.

Even when the B2BUA uses its own contact, it should probably be copying 
the feature tags of the far end onto its own contact address. Adding 
this new tag then muddies the waters about what is going on.

Perhaps Call-Info would be a more suitable place to carry info about the 
recording of the call. Or potentially it could be flagged in the SDP, 
where it could be indicated on a per-media-stream basis. (Though I don't 
know how useful that would be.)

> - Should we also define a tag to request (but not require) recording?

What is the use case for that?
(I can see one for *requiring* recording.)

	Thanks,
	Paul

>> Behalf Of Hutton, Andrew