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

From: "Henry Lum" <[email-masked]>
Date: Sat, 30 Jan 2010 20:10:51 -0800

Hi Ken,

I have a bunch of questions and comments on the requirements for SRP
requirements.

-          Section 3 - Recording Client - If the SRP requirement does
not mandate to use SIP as the actual recording protocol, why does the
recording client have to be a SIP user agent or B2BUA?

-          Section 3 - Recorded session - Is a recorded session has to
be a SIP session?

-          Section 3 - Persistent Recording - does recorded session
exist in this context since it seems like the recording session is
persistent from the endpoint perspective.

-          Section 4 - use case 5 - if the recording can include
recording for an IVR application (ie. VoiceXML application), does that
mean the call metadata must include application contexts as well?

-          Section 4, use case 7 - the first sentence has a strange word
"&mdash". This use case somehow implies certain architectural design for
a PBX with regards to media forking. Is that necessary from a
requirement perspective?

-          Section 4, use case 8 - shall we use a more general
terminology such as multi-party call? Depending on the situation, the
supervisor may be conferenced with the agent and customer so the
recording session needs to define how a multi-party session should be
recorded.

-          Section 4, use case 11, does a recorder "must" support some
sort of media processing such as real-time analytics? This is more of a
business application on the recording server side, which is independent
of the session recording protocol itself.

-          Section 6:

o   REQ-001 - what does full-time Recording session mean?

o   REQ-003 - it's unclear what is the target of the recording session
here since this not directly related to a single recorded session
(perhaps many)

o   REQ-006 - I mentioned above that IVR sessions may contain additional
IVR application metadata; should this requirement clarify that the
mechanism should include application metadata?

o   REQ-007 - this wording of the requirement to me is pointing towards
a specific implementation of high-availability or fault-tolerance of a
recording session.

o   REQ-009 - the wording here is a bit unclear here. Do you mean the
recorded session represents a multi-party session where there are
multiple media streams from multiple recorded sessions, and the media
streams may be mixed by a conference mixer?

o   REQ-013 - this is only one way of notifying the customer that the
call is being recorded but there are others. I think this requires a bit
more explanation of why this is needed. To me this looks like a
duplicate of REQ-022

o   REQ-015 - what does non-repudiation mean in this context? Isn't this
the same as REQ-017?

o   REQ-021 - what happens with SRTP if recording client simply forks
the media? The recording server would not be able to decrypt the media
unless it gets the private keys from the recorded session.

o   REQ-028 - the wording redirected looks out of context here; the
requirement only applies when recording client initiates a recording
session to an available recorder server?

o   REQ-029/030 - They look very generic and I don't think these should
be requirements for SRP, but rather a product requirement on how OA&M
works for the recording client/server.

Thanks

Henry

-------------------------------------------------------------------------------------------------------------------
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: Leon Portman <[email-masked]>
Date: Sun, 31 Jan 2010 13:02:40 +0200

Hi, Henry.

I will try to answer some of the questions. Please see below.

Leon

From: [email-masked] [mailto:[email-masked]] On Behalf Of Henry Lum
Sent: Sunday, January 31, 2010 6:11 AM
To: [email-masked]
Cc: Dave Smith; [email-masked]
Subject: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00

Hi Ken,

I have a bunch of questions and comments on the requirements for SRP requirements.

-          Section 3 - Recording Client - If the SRP requirement does not mandate to use SIP as the actual recording protocol, why does the recording client have to be a SIP user agent or B2BUA?
[LeonP] Actually there is a difference between Recorded session (the actual call to be recorded) that can be not SIP based and Recording Session (part of SRP) that is used for triggering recording and it is SIP based. So both RC and RS are SIP UA.

-          Section 3 - Recorded session - Is a recorded session has to be a SIP session?
[LeonP] No, my comment above

-          Section 3 - Persistent Recording - does recorded session exist in this context since it seems like the recording session is persistent from the endpoint perspective.
[LeonP] No, recorded session are not required to be existing during initiation of persistent session. Persistent recording session can be initiated on agent logon for example.

-          Section 4 - use case 5 - if the recording can include recording for an IVR application (ie. VoiceXML application), does that mean the call metadata must include application contexts as well?
[LeonP] Yes, like specific script or input results

-          Section 4, use case 7 - the first sentence has a strange word "&mdash". This use case somehow implies certain architectural design for a PBX with regards to media forking. Is that necessary from a requirement perspective?
[LeonP] XML convert mistake. We don't want assume any specific configurations.

-          Section 4, use case 8 - shall we use a more general terminology such as multi-party call? Depending on the situation, the supervisor may be conferenced with the agent and customer so the recording session needs to define how a multi-party session should be recorded.
[LeonP] Yes, probably we want to use more generic term then Complex Call

-          Section 4, use case 11, does a recorder "must" support some sort of media processing such as real-time analytics? This is more of a business application on the recording server side, which is independent of the session recording protocol itself.
[LeonP] The main point there was that Recording Protocol must support real time streaming for real time analytics

-          Section 6:

[LeonP] Record all calls

o   REQ-003 - it's unclear what is the target of the recording session here since this not directly related to a single recorded session (perhaps many)
[LeonP] To minimize media clipping associated with recording initiation

o   REQ-006 - I mentioned above that IVR sessions may contain additional IVR application metadata; should this requirement clarify that the mechanism should include application metadata?
[LeonP] Yes, we should

o   REQ-007 - this wording of the requirement to me is pointing towards a specific implementation of high-availability or fault-tolerance of a recording session.

o   REQ-009 - the wording here is a bit unclear here. Do you mean the recorded session represents a multi-party session where there are multiple media streams from multiple recorded sessions, and the media streams may be mixed by a conference mixer?
[LeonP]  It is more for trading floor environments where multiple concurrent calls on the same device (turret) recorded together. It is not related to summation for conference participants at the same call.

o   REQ-013 - this is only one way of notifying the customer that the call is being recorded but there are others. I think this requires a bit more explanation of why this is needed. To me this looks like a duplicate of REQ-022

o   REQ-015 - what does non-repudiation mean in this context? Isn't this the same as REQ-017?
[LeonP] REQ-015 talk regarding media and REQ-017 regarding SRP SIP Session

o   REQ-021 - what happens with SRTP if recording client simply forks the media? The recording server would not be able to decrypt the media unless it gets the private keys from the recorded session.
[LeonP] It is out of scope of this document.

o   REQ-028 - the wording redirected looks out of context here; the requirement only applies when recording client initiates a recording session to an available recorder server?
[LeonP] We want to support both directions

o   REQ-029/030 - They look very generic and I don't think these should be requirements for SRP, but rather a product requirement on how OA&M works for the recording client/server.

Thanks
Henry