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

From: "Elwell, John" <[email-masked]>
Date: Thu, 25 Aug 2011 16:55:05 +0200

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

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.

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.

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

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?

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.

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.

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

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

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

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

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?

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.

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

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.