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

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 8 Dec 2009 17:19:16 +0100

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.

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 8 Dec 2009 15:39:15 -0500

Hi all,

For (1):

How about restricting it to the media described in the sdp between the parties for the session to be recorded (assuming call setup in SIP) or the equivalent for non-SIP?

What I have in mind is a video conference with collab content in a second video stream and a tcp session for BFCP. In this case it might be desirable to record some of the BFCP information to indicate which collab content is on the second video stream. In general the BFCP is listed as an m-line in the sdp.

Also:
Is it worth stating as a requirement that the streams in each direction be sent separately to the recording device (or is this implied?). Some recording devices check for times when both parties are talking - since in a call center scenario such recordings may be discussions worth listening to...

Peter Musgrave

On 2009-12-08, at 11:19 AM, Hutton, Andrew wrote:

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Jain, Rajnish" <[email-masked]>
Date: Wed, 9 Dec 2009 10:19:47 -0500

Also:

Peter Musgrave

This is implied in REQ-010. I think we can add a clarifying note that indicates that the recording media streams may carry the Rx and Tx of recorded media stream separately.

   o REQ-010 The mechanism MUST support the ability to deliver multiple
   media streams for a given Recorded Session over separate Recording
   Sessions to the RS.

Thanks,
Raj Jain

Regards
Andy

Andrew Hutton
Office of the CTO.

DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 10 Dec 2009 10:01:12 +0100

Yes I agree this should be clarified and it should be clear that both modes are allowed (i.e. tx/rx mixed or seperated).

Regards
Andy

-----Original Message-----
From: Jain, Rajnish [mailto:[email-masked]] 
Sent: 09 December 2009 15:20
To: Peter Musgrave; Hutton, Andrew
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00

Also:

Peter Musgrave

Thanks,
Raj Jain

Regards
Andy

Andrew Hutton
Office of the CTO.

---

From: <[email-masked]>
Date: Thu, 10 Dec 2009 21:23:00 -0000

Have you also considered the scenario of persistent calls (nailed up PWs) in which the calls are constantly recorded.  Currently in our world we mix a number of speakers - terminated on the same endpoint device - into a single recording channel to cut down the required bandwidth.

-----Original Message-----
From: [email-masked] on behalf of Hutton, Andrew
Sent: Thu 12/10/2009 9:01 AM
To: Jain, Rajnish; Peter Musgrave
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00

Regards
Andy

-----Original Message-----
From: Jain, Rajnish [mailto:[email-masked]] 
Sent: 09 December 2009 15:20
To: Peter Musgrave; Hutton, Andrew
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00

Also:

Peter Musgrave

Thanks,
Raj Jain

Regards
Andy

Andrew Hutton
Office of the CTO.

---

From: "Jain, Rajnish" <[email-masked]>
Date: Thu, 10 Dec 2009 18:12:53 -0500

> Have you also considered the scenario of persistent calls (nailed up PWs) in
> which the calls are constantly recorded.  Currently in our world we mix a
> number of speakers - terminated on the same endpoint device - into a single
> recording channel to cut down the required bandwidth.

Yes. This is captured in requirements REQ-03 and REQ-09.

   o REQ-003 The mechanism MUST support persistent Recording Sessions,
   such that the connection and attributes of media in the Recording
   Session are not dynamically signaled for each Recorded Session before
   it can be recorded.  Call details and metadata will still be
   signaled, but can be post- correlated to the recorded media.  There
   will still need to be a means of correlating the recorded media
   connection/packets to the Recorded Session, however this may be on a
   permanent filter-type basis, such as based on a SIP AoR of an agent
   that is always recorded, or based on identifiers in the recorded
   media itself.

   o REQ-009 The mechanism MUST support the ability to deliver mixed
   media streams to the RS.  The RS MAY be informed about the
   composition of the mixed streams through session metadata.

   Note: A mixed media stream is where several recorded sessions are
   carried in a single recording session.  A mixed media stream is
   typically produced by a mixer function.

> Yes I agree this should be clarified and it should be clear that both modes
> are allowed (i.e. tx/rx mixed or seperated).
>
> Regards
> Andy
>
>
> Is it worth stating as a requirement that the streams in each direction be
> sent separately to the recording device (or is this implied?). Some
> recording devices check for times when both parties are talking - since in a
> call center scenario such recordings may be discussions worth listening
> to...
>
> Peter Musgrave
>
>
> This is implied in REQ-010. I think we can add a clarifying note that
> indicates that the recording media streams may carry the Rx and Tx of
> recorded media stream separately.
>
> 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.
>
>
> Regards
> Andy
>
> Andrew Hutton
> Office of the CTO.
> DISCLAIMER: This e-mail may contain information that is confidential,
> privileged or otherwise protected from disclosure. If you are not an
> intended recipient of this e-mail, do not duplicate or redistribute it by
> any means. Please delete it and any attachments and notify the sender that
> you have received it in error. Unintended recipients are prohibited from
> taking action on the basis of information in this e-mail.E-mail messages may
> contain computer viruses or other defects, may not be accurately replicated
> on other systems, or may be intercepted, deleted or interfered with without
> the knowledge of the sender or the intended recipient. If you are not
> comfortable with the risks associated with e-mail messages, you may decide
> not to use e-mail to communicate with IPC. IPC reserves the right, to the
> extent and under circumstances permitted by applicable law, to retain,
> monitor and intercept e-mail messages to and from its systems.