Subject: Re: [siprec] Comments on draft-ietf-siprec-protocol-00

From: "Henry Lum" <[email-masked]>
Date: Tue, 6 Sep 2011 10:07:02 -0700

Hi John, 

Thanks for the thorough review. Please see inline.

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
Sent: Thursday, August 25, 2011 10:55 AM
To: [email-masked]
Subject: [siprec] Comments on draft-ietf-siprec-protocol-00

I have read -00 and I believe it needs some refactoring to change from a
proposal to a specification - it is in limbo between the two at present.
Particular comments are as follows:

1. The Abstract should say something about the protocol being based on
SIP/SDP/RTP. On the other hand, I see no need to  introduce terms like
SRC and SRS in the Abstract. Something like:
"This document specifies the use of the Session Initiation Protocol
(SIP), the Session Description Protocol (SDP) and the Real Time Protocol
(RTP) for delivering real-time media and metadata from a communication
session to a recording device."

[hlum] Okay I will fix this.

2. The Introduction needs structuring better. I think it needs to cover
the following points (in sequence):
- State what we are trying to achieve (i.e., delivering real-time media
and metadata from a CS to a recording device.
- State that we are using SIP/SDP/RTP for this purpose.
- State that SIP is used to establish an RS between an SRC on the path
of the CS to an SRS at the recording device, in accordance with the
architecture in [arch].
- State that SIP is also used to deliver metadata, as specified in
[metadata] to the SRS.
- State that the protocol satisfies the requirements in RFC6341.
- I am not a big fan of having a statement about the structure of the
document, since it in some respects duplicates the table of contents,
but I guess it does no harm.

[hlum] Okay I will reword to clarify the above points.

Ensure that acronyms are expanded on first use. 

3. I suspect the Scope section (3) requires more work. For example:
- Make it clear that record-aware UAs are UAs participating in the CS.
- Recording policies not only determine which CSs are to be recorded,
but also whether parts of a CS are to be recorded.
- Delivering on-real-time media is out of scope.
- Policies governing how CS users are made aware of recording are out of
scope.
- Acquiring >>additional<< metadata through non-SIP means - I think we
are only talking about additional metadata, not a replacement for the
metadata delivered over SIP.

[hlum] Okay.

4. Section 4.1 needs a little attention to avoid confusing SRC
functionality and B2BUA or UA functionality. For example:
"When the SRC is deployed as a B2BUA, the SRC can route call requests
from UA(A) to UA(B)".
I would contend that the B2BUA routes call requests from A to B. The SRC
is merely an add-on that does the recording bit.
Also it says:
"the SRC may bridge the media between UA(A) and UA(B)."
I would suggest expressing it as "the SRC can cause the B2BUA to bridge
the media..."

[hlum] The wording in this section does seem to mix the usage of an SRC
and a B2BUA. The main goal here is to explain how to deliver the
recorded media from the SRC to the SRS without specifying where the call
is routed through. I will clarify the wording here.

5. Section 4.2 describes the use of REFER to a conference focus to get
it to establish an RS. How does the conference focus know, on receipt of
the REFER request, that the resulting INVITE request is for the purpose
of recording? In addition, I see no mention of REFER in the rest of the
document, so is this section really relevant? I agree an SRC could be
located at a conference focus, but establishment of RSs can be left as
local policy for the SRC (or the SRS, in the case of SRS-initiated).
This is effectively the case for the B2BUA case, so why not for the
conference focus case?

[hlum] This subsection is indeed the same case as 4.1, it's just one of
the cases to initiate recording through the use of a REFER, and we are
not introducing new handling with REFER anyways (other than explaining
the srs feature tag). Instead of using an additional section to describe
this, perhaps I will expand on 4.1 to explain ways recordings can be
intiaited.

6. Section 4.3 is a little bit back-to-front, in the sense that it
starts off by talking about exceptions (metadata information that is
delivered by SDP rather than in metadata XML) - it would be better to
describe the XML delivery mechanism first, and then point out that
certain metadata is not included in XML since it is present in SDP. But
be careful not to duplicate material that is in the metadata draft -
maybe we don't even need to mention the exception in the protocol
document.

Also I think we should be clearer about the conditions when a snapshot
request is appropriate, as discussed recently.

[hlum] Okay.

6. Section 5 has the title "SIP Extensions for Recording Session", but
the first part (prior to 5.1) does not really talk about extensions but
talks about how to implement existing SIP capabilities. For example, the
paragraph about the From header field. Not sure whether the "must" here
is meant to be a "MUST". What about PAI? 

The paragraph about pre-allocating a recorded media stream (i.e., an RS
media stream) has implications beyond just SIP, e.g., on keeping it
alive until needed, on what to do when one CS finishes. Also it should
perhaps not just talk about a single media stream, but one per medium
for which there is an anticipated need for recording and for which
clipping would be a problem. I think a lot more needs to be said, but it
doesn't really fit under "SIP Extensions".

The last paragraph talks about recorded media streams from multiple CSs,
but not about multiple recorded media streams from a single CS.

Informational material can probably go in section 4, but we need to
think about how to organize the normative stuff, given that it can
impact SIP, SDP and RTP. Also, I would like to see any normative
procedures sub-divided unto procedures at an SRC and procedures at an
SRS.

[hlum] I agree that with the amount of extensions required for the RS,
it would be useful to reorganize the normative sections into procedures
at SRC and SRS. We could have the following subsections for the
procedures:
- Initiating a recording session - this includes the use of feature tag,
option tag, content disposition and content for metadata, and labels for
recorded media streams
- Updating metadata
- Snapshot request
- Handling media stream updates (both RS and CS media stream updates)

I think we need to be careful with our terminology to do with media
streams - whether we are talking about a CS media stream, an RS media
stream, or a metadata media stream object (which, according to recent
discussions, is constrained to be neither just a CS media stream nor
just an RS media stream).

7. Section 5.1.1. The middle paragraph is background to why we have made
a decision - this shouldn't remain in the final deliverable. In both
5.1.1 and 5.1.2 we are missing normative procedures for the SRC and SRS,
e.g., I think there need to be MUSTs concerning inclusion of the
relevant tag in one's Contact header fields, and possibly MUSTs
concerning receipt of the other one in received Contact header fields.

8. Section 5.3 "SDP handling" does not seem to fit in section 5 "SIP
Extensions for Recording Session".

The section contains a number of lower case musts, shoulds and mays, and
I think some of these should be normative, others not. We must be
careful not to make normative statements that repeat normative
statements in other specifications (e.g., RFC 3264, 4566), or worse
still contradict existing normative provisions. On the other hand we
might need normative statements that go beyond what are in existing
RFCs, i.e., closing options. Also there is some use of present tense,
e.g."To remove a recorded media stream from the recording session, send
a
   reINVITE and set the port to zero in the m= line."

[hlum] I was reminded about repeating normative statements in other
specifications and it does not belong to a SIP extension section.
Perhaps restructuring the procedures at SRC and SRS may clarify the SDP
usage.

Again terminology around media streams needs to be considered very
carefully,  Also the description around the use of labels needs some
careful attention to wording. For example:
"Note that a participant may have
   multiple streams (audio and video) and each stream is labeled
   separately."
This could be interpreted that streams are specific to particular
participants, but generally CS streams relate to a CS and any number of
participants in the CS can contribute to or receive a given stream.

9. Section 5.5:
"The label attribute contains a reference to the rest of the
   metadata information."
Not exactly. A label attribute within an RS SDP media description is a
means by which a media stream element in metadata XML can reference that
media description and hence identify the RS media stream used for
conveying that media stream to the SRS.
(But you can see here how we have a problem with media stream
terminology).

[hlum] To clarify - the label attribute provides a name to the RS media
stream. The metadata XML can reference that label to identify the RS
media stream.

"For all basic metadata information such as communication session,
   participants and call identifiers, they can be included in the
   initial INVITE request sent by the SRC."
This is incorrect for persistent recording or for any other situation
where a single RS is used to record multiple CSs where not all CSs
and/or not all participants exist at the time the RS is established.

"Metadata can be included as
   content in the INVITE or UPDATE request."
Which particular UPDATE request is this?

"A new "disposition-type" of
   Content-Disposition is defined for this purpose and the value is
   "recording-session"."
This content disposition value is not just defined for this purpose (the
initial INVITE, which is the subject of this paragraph). It is also to
be used in re-INVITEs, later, i.e., it is applicable to any message in
which metadata is to be conveyed. Also why do we mention the
content-disposition value without mentioning the content-type value?

[hlum] application/rs-metadata is defined but I guess it's only
mentioned in an example. I will clarify.

"Since there can only be a
   single INVITE or UPDATE transaction happening at a time within a SIP
   dialog, using sequence number CSeq in the dialog can be a reliable
   way for the SRS to identify the receipt of the next metadata update."
Because of the existence of B2BUAs on the RS signalling path, I doubt we
can claim that Cseq is reliable.

[hlum] Since we agreed that metadata XML will include a sequence number,
I don't think we need to make this claim (or false claim) anymore.

The last paragraph talks about metadata snapshots, yet we have not yet
introduced the concept of partial versus full metadata.

10. Section 5.6.
I rather doubt the need for such complexity in the body of a snapshot
request. In particular, I find the use of the term "header" confusing
when talking about a body part of a SIP message (particular as a Reason
header field exists in SIP as well). Where is the ABNF for
"extension-header" defined?

[hlum] We could opt for a SIP header instead of a body, but in both
cases we still require additional processing for SRC and SRS to look for
the existence of such header or content so I don't think a body
necessarily adds complexity. I should correct the wording of header to
avoid confusion with a SIP header and correct the ABNF.

11. Section 5.7.
I think this needs to mention keep-alives. It also needs to make it
clear that pausing could be because of pausing a recording during a CS
or pausing because a CS has finished, or a particular CS media stream
has finished. Or at least that is my assumption.

[hlum] I am not sure which keep-alive you are talking about, is this for
maintaining NAT bindings or just general RTP/RTCP keep alive? 

Do we need to mention disabling media when finished with? For example,
as the number of active RS media streams grows with more parallel CSs
and media, and then shrinks as these terminate, do we necessarily need
to change them all to inactive and keep the streams alive, thereby
wasting resources such as NAT ports, SRS ports, TURN servers, etc.?

[hlum] Yes we should, I am thinking of mentioning this for the
persistent recording use case which is the most likely use case to
disable a media stream when there are no calls to be recorded while
keeping the RS around.

Concerning the last paragraph about mute, if all participants
contributing to a media stream have invoked mute, is this not good
reason to change the RS media stream to inactive? In any case, do we
need to say something about keep-alive in this situation?

12. Section 6 "Extensions for Recording-Aware User Agents" - I would
like to see normative procedures sub-divided into procedures at an SRC
and procedures at a recording-aware UA.

In 6.1.1:
" 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"
I think it also needs to be stated that the fact that a UA claims to be
recording aware does not necessarily obviate the need for providing
indications of recording through other means, particularly where a
particular message needs to be conveyed. A recording-aware UA can,
however, supplement any other indication, e.g, by tailoring to the needs
of the user.

13. I suspect there is more we will want to say on security, and
probably privacy too, but I haven't given it much thought. Perhaps a
reference to the considerations in RFC 6341 might be a start.

John (as individual)

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: [email-masked]
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15
0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of
Siemens AG.
_______________________________________________
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: Tue, 6 Sep 2011 21:14:21 +0200

Henry,

> avoid confusion with a SIP header and correct the ABNF.
[JRE] I think the WG agreed use of a body part, but I believe it can be kept very simple.

> maintaining NAT bindings or just general RTP/RTCP keep alive? 
[JRE] Essentially for maintaining NAT bindings / firewall pin-holes for RTP/RTCP.

John

John Elwell

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.