Subject: [siprec] comments on draft-ietf-siprec-protocol-06

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 19 Jul 2012 22:43:27 +0000

I have one major comment and one minor comment on the draft. I'll start with the major comment.

Section 6.1 and section 6.2 discuss the use for the +sip.src/+sip.srs feature tag and siprec option tag by a SRC/SRS to start an RS. The section clearly and correctly states that both the feature tag and the option tag must be present.
However, the sections also describe the usage of the +sip.src/+sip.srs feature tags in REGISTSER messages. The usage of +sip.src/+sip.srs feature tag without the siprec options tag in other requests, such as INVITE, is not covered. The meaning of these feature tags to UAs in not addressed.
I suggest to change section 6 from "Initiating a Recording" to  "SIP Handling". This is more in line with the approach take in sections 7 and 8, which are titled "SDP Handling" and "RTP  Handling". Within section 6 was can have:
	6.1 Procedures at  the SRC  
	6.2 Procedures at the SRS
	6.3 Procedures at Recording-aware UAs

To the existing section 7, we can add:
	Section 7.3 Procedures at Recording-Aware UAs.
The material currently in section 11 gets relocated into section 6 and 7 accordingly.
In addition to simply reorganizing, we also clarify what it means for a UA to receive to INVITE or 200 OK from an SRC that includes +sip.src. I take this to mean that the thing the UA is talking to is able to act as a SIPREC SRC, even though it may not be recording currently. This may be useful in some scenarios, such as for an MCU to know that one of the participants in the conference is a recorder. Consequently the UA or MCU may want to indicate a recording preference, and/or pay attention to any SDP record attributes. Whether or not the UA/MCU can influence the operation of the SRC remains a policy decision of the SRC, as currently described in the draft.

My minor/editorial comment is in regard to section 5.3. This section provides good introductory information; however, the first paragraph does not read well in my opinion. I think it would benefit from separating the record and recordpref attributes discussion a bit. Proposed text is as follows:

"The SRC is responsible for providing recording indications to the participants in the CS. The SRC does so using the SIPREC defined SDP attribute a=record. This attribute is used as a declaration by the SRC to indicate whether recording of the CS is taking place . The SRC may use other recording indication mechanisms as well; however, such mechanisms are outside the scope of SIPREC.
Recording-aware UAs can indicate a recording preference in the CS using the SIPREC defined SDP attribute a=recordpref. The recording preference attribute is a declaration by the recording-aware UA of its recording preference. The SRC is not obligated to honor a recording preference provided by a UA, as it is merely an indication of a preference, not a direct command or request to start or stop recording."

Cheers,
Charles

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 26 Jul 2012 08:51:23 -0700

Hi Charles,

Please see inline.

Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of
> Charles Eckel (eckelcu)
> Sent: July-19-12 6:43 PM
> To: [email-masked]
> Subject: [siprec] comments on draft-ietf-siprec-protocol-06
> 
> I have one major comment and one minor comment on the draft. I'll
start with
> the major comment.
> 
> Section 6.1 and section 6.2 discuss the use for the +sip.src/+sip.srs
feature
> tag and siprec option tag by a SRC/SRS to start an RS. The section
clearly and
> correctly states that both the feature tag and the option tag must be
present.
> However, the sections also describe the usage of the +sip.src/+sip.srs
feature
> tags in REGISTSER messages. The usage of +sip.src/+sip.srs feature tag
without
> the siprec options tag in other requests, such as INVITE, is not
covered. The
> meaning of these feature tags to UAs in not addressed.

[Henry] The intention to require both option tag and feature tag is to
first identify that a session is a recording session with the option
tag, and then identify the party (SRC/SRS) with the feature tag. Without
the option tag, a session should not be considered a recording session;
how the UA treats a party in a normal SIP session with a src/srs feature
tag should be up to the UA. For example, the SRC may tell the
participant that it is an SRC and the participant may choose to do
nothing with this or include the recording preference to indicate the
wish to record. You are right that it is not quite clear what this means
and it's not covered in both section 6 and 11.

> I suggest to change section 6 from "Initiating a Recording" to  "SIP
> Handling". This is more in line with the approach take in sections 7
and 8,
> which are titled "SDP Handling" and "RTP  Handling". Within section 6
was can
> have:
> The material currently in section 11 gets relocated into section 6 and
7
> accordingly.

[Henry] The original thought is to organize recording indication and
preference as a separate section to explain how this is used between
record-aware UA and SRC, and not mix this with the recording session.
Now that the introductory text on how recording preference is used is
moved to section 5.3, it is possible re-align the major headings as SIP,
SDP, RTP/RTCP handling, Metadata. Let's see what others think about
reorganization.

> In addition to simply reorganizing, we also clarify what it means for
a UA to
> receive to INVITE or 200 OK from an SRC that includes +sip.src. I take
this to
> mean that the thing the UA is talking to is able to act as a SIPREC
SRC, even
> though it may not be recording currently. This may be useful in some
> scenarios, such as for an MCU to know that one of the participants in
the
> conference is a recorder. Consequently the UA or MCU may want to
indicate a
> recording preference, and/or pay attention to any SDP record
attributes.

[Henry] As long as the MCU indicates recording-aware support in the
initial INVITE request/response, then the MCU should be able to find out
which participant is an SRC and provide the recording preference later
in the call. This needs to be clarified as you suggested in the first
comment.
 
> Whether or not the UA/MCU can influence the operation of the SRC
remains a
> policy decision of the SRC, as currently described in the draft.
> 
> My minor/editorial comment is in regard to section 5.3. This section
provides
> good introductory information; however, the first paragraph does not
read well
> in my opinion. I think it would benefit from separating the record and
> recordpref attributes discussion a bit. Proposed text is as follows:
> 
[Henry] Thanks, this reads much better.

> "The SRC is responsible for providing recording indications to the
> participants in the CS. The SRC does so using the SIPREC defined SDP
attribute
> a=record. This attribute is used as a declaration by the SRC to
indicate
> whether recording of the CS is taking place . The SRC may use other
recording
> indication mechanisms as well; however, such mechanisms are outside
the scope
> of SIPREC.
> Recording-aware UAs can indicate a recording preference in the CS
using the
> SIPREC defined SDP attribute a=recordpref. The recording preference
attribute
> is a declaration by the recording-aware UA of its recording
preference. The
> SRC is not obligated to honor a recording preference provided by a UA,
as it
> is merely an indication of a preference, not a direct command or
request to
> start or stop recording."
> 
> Cheers,
> Charles
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jul 2012 12:39:46 -0400

> and it's not covered in both section 6 and 11.

I take slight issue with the above.

The option tag cannot indicate that the session *is* a recording 
session. All an option tag can do is indicate *support* for features.
So for instance I *could* send you an INVITE with Require:siprec and yet 
have it be a regular call. But it would fail unless you are *capable* of 
a recording session.

The definitive signaling that this *is* an RS should be the metadata.

I (reluctantly) have agreed that we can get away with interpreting the 
presence of the +sip.src or +sip.srs tag as meaning that end intends to 
act in that role, rather than simply being *capable* of doing so. We 
have some precedent for such usage, such as with isFocus.

	Thanks,
	Paul