[dispatch] Comments on draft-rehor-dispatch-session-recording-req-00

["Hutton, Andrew" <[e-mail]>]

Some comments on the session recording requirements draft draft-rehor-dispatch-session-recording-req-00

1. The introduction states that the "recording sessions can be of any kind such as voice, video and instant messaging". I think it would be sensible to restrict the scope to RTP based media (I.e. voice and video) and possibly move out the instant messaging recording as a separate work item if needed.

2. The introduction contains a statement regarding "draft-wing-sipping-srtp-key". This draft describes a mechanism for disclosing SRTP session keys to intermediaries which is not relevant to this work because the scope of the new work relates to the case when an endpoint forks media to the recorder and therefore uses separate SRTP keys.

3. I think the last sentence of the introduction (I.e. "There are already IETF working groups ....") should be removed as it relates to IETF process and is not relevant for the draft.

4. Section 3. The definition of a "Recording Client" states that the RC "is a SIP User Agent (UA) or a "Back-to-Back-User-Agent (B2BUA) that acts as the source of the recorded media". I think we should remove the B2BUA reference as it is not relevant what is important is simply that the RC is a SIP UA that acts as the source of the media.

5. Section 4, Use case 6. Typo "agents and agents and..".

6. Section 5. I don't see the need for Figure 2 as it really seems to be logically the same as Figure 1. The recording control and media both have to originate from the recording client and therefore in Figure 2 it is the combination of the B2BUA and the A/S (Probably also a B2BUA) which make up the RC.

7. Section 5. Figure 3 needs to show the location of the RC.

8. Section 5. Figure 4. I find it difficult to see how the "Recording Control" and the "Recorded Media" can be split in this way as they both need to be handled by the RC. Since the diagram shows SIP as the protocol between UA-C and the A/S then I assume that this SIP interface would need to be enhanced with something to provide the recording control which does not seem to make sense.

9. Section 5. Figure 4. Also needs to show the location of the RC.

10. Section 6 Req-021. This does not look like a requirement to me but some kind of implementation limitation and may not even be possible as I don't see how SRTP could be made to work in this way. The definition of the RC states that it is the source of the media which seems incompatible with this requirement.

11. Section 6 Req-030. This does not sound like an SRP requirement.

Regards
Andy


Andrew Hutton

Office of the CTO.
Siemens Enterprise Communications.