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

From: Alan Johnston <[email-masked]>
Date: Fri, 24 Jul 2009 13:28:58 -0500

Here are my comments on this draft.

Overall, I think this draft is an excellent start at the requirements 
for this important topic.  I look forward to future discussions of 
charter text so we can get started on the work.

Section 2:

"  Another, related IETF draft is draft-wing-sipping-srtp-key
   [I-D.wing-sipping-srtp-key], which describes an approach for
   providing SRTP session keys to a recorder-type server.  That draft
   focuses on the mechanism to provide the SRTP session key, rather than
   the mechanism to invoke and sustain recording sessions themselves."

draft-wing-sipping-srtp-key actually has a lot of discussion, including 
call flows showing how recording sessions can be established.  Also, 
this document has four recording modes discussed, which I think should 
be discussed in this document.  Two are mentioned without really 
explaining them, and two others are implied by various requirements.

Section 3:

" Recording Session: The session created between an RC and RS for the
   purpose of recording a Recorded Session.  The Recorded Session may
   itself be based on SIP, but it is a separate session from the
   Recording Session.

   Recorded Session: A session created between a UAC and UAS that is
   recorded by the RC and RS systems."

These two terms only differ by their tense, yet I think one refers to a 
signaling session and the other refers to a media session.  If so, 
better terms and definitions are needed.  If not, we need a term for the 
actual recorded media.  Also, there are (at least) two sessions here - 
the one between the UAs and the Recording Session - in a few places I 
suspect the two are being confused. 

"  Dynamic Recording: Dynamic recording is a mode of recording where the
   recording sessions are established on an as needed basis.  The length
   of these sessions is typically same as the length of the actual media
   sessions.

   Persistent Recording: Persistent recording is a mode of recording
   where the recording sessions are established at system start-up and
   kept-alive from that point on.  The length of these sessions is
   independent from the length of the actual recorded media sessions.
   Persistent recording sessions avoid issues such as media clipping
   that can occur due to delays in recording session establishment."

These terms need more explanation as I can think of multiple things they 
might mean.  For example, when you say "session" do you mean a signaling 
session or media session?  When you talk about avoiding media clipping, 
do you mean that media is always sent by the RC to the RS regardless of 
whether there is any media? 

Figures could use Figure numbers and labels.  Also, it would be worth 
showing which is the RC and which is the RS in them.

Section 5

"   o REQ-001 The mechanism MUST support the ability to perform
   persistent (always-on) or dynamic (on-demand) Recording Sessions."

I'm not sure that the Persistent and Dynamic Recording as defined above 
correspond to the Always On and On Demand modes defined in 
http://tools.ietf.org/html/draft-wing-sipping-srtp-key-04#section-4.

"   o REQ-002 The mechanism MUST support the ability to perform
   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."

Without fully understanding Persistent Recording, I can't evaluate this 
requirement. 

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

I'm not clear what mixed media means here - does it mean a mix of media 
types - synchronized audio and video from the same session, or do you 
mean multiple media streams from different sessions?  The note seems to 
indicate that this relates only to a conference call where multiple 
sources (SSRCs) have been combined into a single RTP session.

"   o REQ-013 The mechanism MUST support the ability to inject tones into
   the Recorded Session either from the RS or from the RC."

Recorded Session seems to be defined as the media between the RC and 
RS.  Is that where the injected tones should be?  Or should then be 
mixed in the media between the two UAs?

"   o REQ-021 The mechanism MUST support the ability for the RC to only
   perform media replication to the RS, without needing to decode or mix
   audio/video/etc., and without needing to be an RTP agent.  This will
   allow the RC to replicate media at layers below RTP.  Clearly, such
   an RC mode would not be able to provide transcoding, or media
   injection from the RS back into the Recorded Session."

Does this mean that you think that RTP is unsuitable for transporting 
media between the RS and RC?  Clearly it isn't for IM, but I would think 
that many of the functions of RTP are needed for audio and video media.  
To understand this requirement will take more discussion.

Thanks,
Alan

---

From: Leon Portman <[email-masked]>
Date: Sun, 26 Jul 2009 05:10:08 +0300

Alan, Hi

Thanks for the comments.

Please see below my answers

Regards

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan Johnston
Sent: Friday, July 24, 2009 9:29 PM
To: [email-masked]
Subject: [dispatch] Comments on draft-jain-dispatch-session-recording-protocol-req-00

Section 2:

[LeonP] Yes, for the protocol draft, we will need to combine all of the approaches and make sure that we covered all use cases

Section 3:

[LeonP] Actually Recording Session relates to both SIP and Media that is forked to the recording server and Recorded Session is actually the original conversation between two UAs. These two are exactly the two sessions that you are describing.

[LeonP] Yes, by session we mean both legs: signaling and media. And in Persistent Recording mode, the Recording SIP session supposed to stay connected even there is not actual connected sessions for the specific recorded UA. 

Section 5

[LeonP] It is different in the way that the Recording Session is established only once during initialization (or login events) and then only media is forwarded per each call in order to minimize the clipping.

 [LeonP] It is specific trading floor environment requirements where multiple handset and speakers for specific turrets will be mixed on the turret level for recording by one recording channel.

Recorded Session seems to be defined as the media between the RC and 
RS.  Is that where the injected tones should be?  Or should then be 
mixed in the media between the two UAs?
[LeonP] we have multiple options here. Preferable solution that one of the UAs will inject them (triggered by policy or parameters in SRP), but there are also configuration where RS will be required to create them and send back to RC (like talking clock for example)

[LeonP] Actually it was Hadriel requirement. I believe it only means that RC does not required to implement RTP stack, it can just fork RTP packets on the network level (by hardware)

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

---

From: Alan Johnston <[email-masked]>
Date: Mon, 27 Jul 2009 03:07:44 -0500

Leon,

Thanks for your replies - see a few comments below.

Thanks,
Alan

> [LeonP] Actually Recording Session relates to both SIP and Media that is forked to the recording server and Recorded Session is actually the original conversation between two UAs. These two are exa…
OK - I didn't get that from the definitions, so you probably want to 
reword these and maybe reference a figure. 

> [LeonP] Yes, by session we mean both legs: signaling and media. And in Persistent Recording mode, the Recording SIP session supposed to stay connected even there is not actual connected sessions fo…

OK, you need to reword these definitions to this is very clear.

> [LeonP] It is different in the way that the Recording Session is established only once during initialization (or login events) and then only media is forwarded per each call in order to minimize th…

That's what I thought you meant, and this is different from the 
definitions in my draft.  We should try to get these definitions sorted 
out this week.

>  [LeonP] It is specific trading floor environment requirements where multiple handset and speakers for specific turrets will be mixed on the turret level for recording by one recording channel.

OK - since this mixing is done by the endpoint (turret), this is an 
example of  where the UA is acting as the RC, right?  This use case 
should be described in the document.

> [LeonP] we have multiple options here. Preferable solution that one of the UAs will inject them (triggered by policy or parameters in SRP), but there are also configuration where RS will be require…

So, we are talking about the RS sending media to the RC which must be 
inserted into the media session between the two UAs?  This use case 
needs to be discussed elsewhere outside of this requirement.

> [LeonP] Actually it was Hadriel requirement. I believe it only means that RC does not required to implement RTP stack, it can just fork RTP packets on the network level (by hardware)

Yes, I think I get that when I reread the requirement.  This is a very 
important requirement that has a huge impact on the scalability of the 
system.

---

From: Roni Even <[email-masked]>
Date: Mon, 27 Jul 2009 17:58:26 +0300

Hi,
I am not sure how REQ-021 will work if you want to address packet loss and
control using RTCP. I suggest you look at the Topologies RFC 5117 for
directions
Roni Even
> > [LeonP] Actually it was Hadriel requirement. I believe it only means
> that RC does not required to implement RTP stack, it can just fork RTP
> packets on the network level (by hardware)
> >
>

---

From: "Labarbera, Chris " <[email-masked]>
Date: Mon, 27 Jul 2009 10:10:20 -0500

We need to look at this in the big picture. If you want to address packet loss and control using RTCP, you will most likely use the services of a session border controller to act as the B2BUA and leverage the services of the SBC to manage RTCP and MOS scores for the media. The whole context of the dispatch recording method is to provide a forking point at a large ingress point such as a SBC. In this model, a SBC can deliver 15,000 SIP sessions to a series of enterprise PBX/ACD systems and the dispatch method can be used to selectively fork media to a voice recorder at great scale and capacity. The overall goal of this model is to provide an effective and scalable solution for recording in high availability (transparently) without putting any additional demand on the PBX systems downstream from the recorder.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Monday, July 27, 2009 10:58 AM
To: 'Alan Johnston'; 'Leon Portman'
Cc: [email-masked]
Subject: Re: [dispatch] Comments on draft-jain-dispatch-session-recording-protocol-req-00

Hi,

---

From: "Doken, Serhad" <[email-masked]>
Date: Tue, 28 Jul 2009 00:47:04 -0700

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Leon Portman
> Sent: Saturday, July 25, 2009 7:10 PM
> To: Alan Johnston; [email-masked]
> [LeonP] Yes, for the protocol draft, we will need to combine all of the
> approaches and make sure that we covered all use cases
> 
> Section 3:
> 
> [LeonP] Actually Recording Session relates to both SIP and Media that
> is forked to the recording server and Recorded Session is actually the
> original conversation between two UAs. These two are exactly the two
> sessions that you are describing.
> 
> [LeonP] Yes, by session we mean both legs: signaling and media. And in
> Persistent Recording mode, the Recording SIP session supposed to stay
> connected even there is not actual connected sessions for the specific
> recorded UA.
> 
> [LeonP] It is different in the way that the Recording Session is
> established only once during initialization (or login events) and then
> only media is forwarded per each call in order to minimize the
> clipping.

I see the "Always On" Recording as a separate third mode of Recording where for a particular one or set of devices(possibly set via provisioning), all calls are recorded from start to end(by setting up recording sessions) and no persistent recording sessions are kept for them.

>  [LeonP] It is specific trading floor environment requirements where
> multiple handset and speakers for specific turrets will be mixed on the
> turret level for recording by one recording channel.
> 
> 
> [LeonP] we have multiple options here. Preferable solution that one of
> the UAs will inject them (triggered by policy or parameters in SRP),
> but there are also configuration where RS will be required to create
> them and send back to RC (like talking clock for example)
> 

Most such middlebox media forkers will have RTP stack implemented anyway. Though packet replication can be done at a lower layer, it'd probably still need the smarts to know the replicated packet is actually a RTP packet to determine which packet to replicate.

---

From: "Jain, Rajnish" <[email-masked]>
Date: Thu, 30 Jul 2009 07:17:14 -0400

> I see the "Always On" Recording as a separate third mode of Recording where
> for a particular one or set of devices(possibly set via provisioning), all
> calls are recorded from start to end(by setting up recording sessions) and
> no persistent recording sessions are kept for them.

I guess this is semantics, but wouldn't that still be "On Demand"? In your scenario, it just so happens that the RC/RS have been configured to record all calls for a given end-point, but the recording sessions are still established on a per call basis.

Thanks,
Raj

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: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Thu, 30 Jul 2009 10:35:47 -0400

Pl. see inline ... 

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Jain, Rajnish
>Sent: Thursday, July 30, 2009 4:47 PM
>To: Doken, Serhad; Leon Portman; Alan Johnston; [email-masked]
>Subject: Re: [dispatch]Comments on 
>draft-jain-dispatch-session-recording-protocol-req-00
>
>>
>> I see the "Always On" Recording as a separate third mode of 
>Recording 
>> where for a particular one or set of devices(possibly set via 
>> provisioning), all calls are recorded from start to end(by 
>setting up 
>> recording sessions) and no persistent recording sessions are 
>kept for them.
>
>I guess this is semantics, but wouldn't that still be "On 
>Demand"? In your scenario, it just so happens that the RC/RS 
>have been configured to record all calls for a given 
>end-point, but the recording sessions are still established on 
>a per call basis.

This is similar to a recording anchor where during recording either RC
or RS is designated as the recording anchor. For example in a call
center, the external caller is the recording anchor and recording
continues even when call is transferred to another agent, call is put on
hold or another agent is conferenced, the recording from the caller
device does not stop. The recording anchor also provides the metadata to
the RS to keep track of different service interactions.

Thanks

---

From: "Jain, Rajnish" <[email-masked]>
Date: Thu, 30 Jul 2009 11:00:06 -0400

Hi Sanjay,

Pls. see inline:

> From: Sanjay Sinha (sanjsinh) [mailto:[email-masked]]
> Sent: Thursday, July 30, 2009 10:36 AM

> the RS to keep track of different service interactions.

That's a good use case. One way to look at this is that the RC is anchored on the end-point that represents the external caller. This is also known as line-side recording. Another way to look at this is that the RCs are anchored on the agent UAs and the metadata is used to correlate and construct the overall call. This is also known as station-side recording.

I'd imagine that this use case (regardless of where the RC is anchored) could still be addressed through either On-Demand or Always-on recording modes. I don't see this as a separate recording mode, unless I'm missing something.

Thanks,
Raj

---

From: "Doken, Serhad" <[email-masked]>
Date: Fri, 31 Jul 2009 00:54:30 -0700

> From: Jain, Rajnish [mailto:[email-masked]]
> Sent: Thursday, July 30, 2009 4:17 AM
> Subject: RE: [dispatch] Comments on draft-jain-dispatch-session-
> recording-protocol-req-00
> 
> I guess this is semantics, but wouldn't that still be "On Demand"? In
> your scenario, it just so happens that the RC/RS have been configured
> to record all calls for a given end-point, but the recording sessions
> are still established on a per call basis.

The nuance I was thinking in my scenario is RC or RS avoids the need notify the other via signaling to kick off the recording session which I consider this notification process as on demand. So, yes in the end, I agree it is mostly semantics.

> 
> Thanks,
> Raj
> 
> 
> 
> 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.