Subject: [siprec] Minor comments on siprec-req-04

From: "Elwell, John" <[email-masked]>
Date: Tue, 2 Nov 2010 17:44:09 +0100

I think the editor can take care of most of these when he produces req-05. If anyone thinks otherwise, please shout.

1. Section 2:
"It should be noted that the requirements for the
   protocol between a Session Recording Server and Session Recording
   Client have very similar requirements (such as codec and transport
   negotiation, encryption key interchange, firewall traversal) as
   compared to regular SIP media sessions.  The choice of SIP for
   session recording provides reuse of an existing protocol."
This seems to imply that SIP is fine as is, which suggests we have no work to do in SIPREC! Unfortunately, that is not the case, so I would recommend rewording. Also some editorial improvements, such as eliminating "requirements ... have very similar requirements":

"It should be noted that the requirements for the protocol between a Session Recording Client and a Session Recording Server are very similar to those for regular SIP sessions (such as codec and transport negotiation, encryption key interchange, firewall traversal).  Therefore by choosing SIP as the basis for session recording, maximum reuse is made of an existing protocol."

2. Section 2:
"An archived session recording is typically comprised of the
   Communication Session media content and the Communication Session
   Metadata."
Since we refer to these simply as "media" and "metadata" later, add these in parentheses. Also editorial correction:
"An archived session recording typically comprises the
   Communication Session media content (media) and the Communication Session
   Metadata (metadata)."

3. Section 2:
"The Communication Session
   Metadata needs to be conveyed from the Session Recording Client to
   the Session Recording Server."
So too does the media! I suggest we say (using the shortened terms from the previous comment):
"The metadata, as well as the media, needs to be conveyed from the Session Recording Client to the Session Recording Server."

4. Section 3, definition of SRS:
"a specialized media server or collector
   that acts as the sink of the recorded media"
I think we should mention metadata too. I know it is mentioned in the last sentence of the paragraph, but see my later comment. So change to:
"a specialized media server or collector
   that acts as the sink of the recorded media and metadata"

5. Section 3, definition of SRS:
"An SRS is a logical
   function that typically archives media for extended durations of time
   and provides interfaces for search and retrieval of the archived
   media"
I don't really think the provision of interfaces for search and retrieval are part of the SRS, which is a logical component just for recording purposes. In addition I think we need to mention metadata. I think we can reword this as:
"An SRS is a logical function that archives media and metadata for an extended period, so that the media and metadata can subsequently be searched and retrieved."

6. Section 3, definition of SRS:
"An SRS is typically also the sink of the recorded session metadata."
When would it NOT be the sink of metadata? Or put it another way, if metadata is sent elsewhere, isn't it outside the scope of SIPREC? Delete this sentence (my proposals above cover metadata sufficiently, in my opinion).

7. Section 3, definition of SRC:
"A Session Recording Client (SRC) is a
   SIP User Agent (UA) that acts as the source of the recorded media"
Add "and metadata".

8. Section 5, definition of SRS:
"The SRC itself or
   another entity working on its behalf (such as a SIP Application
   Server) may act as the source of the recording metadata."
Since earlier in the definition we have talked about an SRC including an AS, I don't think we need to make provision for an AS to be a separate entity from the SRC for the purpose of supplying metadata. Or put it another way, if the SRS receives metadata from a source other than the SRC, that would be outside the scope of SIPREC. I would suggest deleting this sentence. The addition proposed by the previous comment should be sufficient to cover metadata.

9. Section 5, definition of SIPREC:
"SIPREC: The set of SIP extensions that supports recording of
   Communication Sessions."
SIPREC is the name of the WG, which will not last indefinitely. Although the WG will generate extensions to SIP and/or SDP, it is not clear that those extensions will collectively be called SIPREC. I think we can remove this definition from the requirements document. The only place it is used is in REQ-029, which I think is a candidate for removal anyway (covered by more specific security requirements).

10. Section 3:
"Pause and Resume during a Communication Session: "
Delete. The definitions of Pause and Resume that follow are sufficient (although subject to a separate tracker issue).

11. Section 4, use case 4:
Change "independent from" to "independent of"

12. Section 4, use case 4:
"CS details
   and CS metadata will still be signaled, and can be correlated to the
   recorded media"
What are "CS details", as opposed to "metadata". Suggest we change:
"CS details and metadata" to just "Metadata".

13. Section 4, use case 4:
"There will still need to be a means of correlating
   the recorded media connection/packets to the Communication Session."
Isn't this what metadata is for, and hence isn't this covered by the previous sentence? I would suggest deleting this sentence.

14. Section 4, use case 5:
"An example of a real-time controls is Pause/Resume"
Change to:
"An example of a real-time control is Pause/Resume"

15. Section 4, use case 6:
"DTMF or ASR"
Expand ASR, since this is the first (only) use.

16. Section 4, use case 6:
"applications
   may need to be recorded "
Change to:
"sessions
   may need to be recorded "

17: Section 4, use case 7:
"Mobile phones of knowledge workers when they conduct work related
   (and legally required recording) calls."
Change to:
"Mobile phones of knowledge workers when they conduct work-related calls for which recording is legally required."

18. Section 4, use case 11:
"In trading floors environments, in order to save resources, it may be
   preferable to mix multiple concurrent calls (Communication Sessions)
   on different handsets/speakers on the same turret into single
   recording session."
I am not sure what gains you get by merging into a single RS unless you also mix media streams of the same type into a single stream. Perhaps we can say:
"In trading floors environments, in order to save resources, it may be
   preferable to mix media streams from multiple concurrent calls (Communication Sessions)
   on different handsets/speakers on the same turret into single
   recording session media stream."

19. REQ-012 and REQ-012bis:
In each of these we mention "audio streams", but in the second sentence of the note to REQ-012 we talk about "media streams". For consistency we should use "media streams" throughout these two requirements.

20. Note to REQ-012:
"The RS MAY be informed about
   the composition of the mixed streams through session metadata."
First, we should not use RFC 2119 language in a note. Second, any normative statements we make should be on the mechanism that SIPREC will define, not on any architectural component. Thirdly, it is hard to imagine what is meant by informing the RS (recording session). We could say:
"The metadata should provide information on the composition of the mixed media stream."

21. REQ-029 has been superseded by REQ-040 onwards and can be deleted.

22. REQ-030 and REQ-032 are nothing to do with security and should be moved from under the "SECURITY" sub-heading (already commented by somebody else).

23. "REQ-030 The mechanism MUST provide a means for the Recording
   Session identifier so that the Recording Session itself is labeled as
   a SIP session that is established for the purpose of recording."
This doesn't parse. Perhaps it should say:
"REQ-030 The mechanism MUST provide a means for the Recording
   Session to be identified as established for the purpose of recording."

24. "REQ-040 The mechanism SHALL provide means for an SRS to SRC on RS
   initiation"
Change "for an SRS to SRC" to "for an SRS to authenticate an SRC".

25. Section 6:
"Both the signaling and media
   for the SIPREC needs the ability to be authenticated and protected
   from eavesdropping and non-repudiation"
Change "SIPREC" to "RS".

John (as individual)