Subject: Re: [dispatch] Session Recording in SIP

From: "Jain, Rajnish" <[email-masked]>
Date: Mon, 6 Jul 2009 18:48:04 -0400

All: The following draft on SIP session recording requirements was submitted today:

http://www.ietf.org/internet-drafts/draft-jain-dispatch-session-recording-protocol-req-00.txt

Title:           Requirements for Session Recording Protocol (SRP)

Abstract:
Session recording is a critical requirement in many business
communications environments such as call centers and financial
trading floors.  In some of these environments, all calls must be
recorded for regulatory and compliance reasons.  In others, calls may
be recorded for quality control or business analytics.  Recording is
typically done by sending a copy of the media to the recording
devices.  This document specifies requirements for a protocol that
will manage delivery of media from an end-point that originates media
or that has access to it to a recording device.  This protocol is
being referred to as Session Recording Protocol and will most likely
be based on SIP.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Vijay Gurbani
> Sent: Monday, June 22, 2009 12:09 AM
> To: [email-masked]
> Subject: [dispatch] Summary on Session Recording in SIP
>
> All: Here is the summary of the Session Recording thread from June 9
> to June 19, 2009.  If I misrepresented anything, please let me know.
>
> There was a fair amount of discussion on where to conduct this
> work.  In the end, it was decided to continue discussions on
> dispatch, further decisions what to do -- new working group or
> put this work in an existing working group -- will be decided
> later.  Regardless of where the work is done, opinions were
> expressed that the work is important that it should commence
> in the IETF.
>
> Need to be crisp about the purpose of this work: is it that users
> record sessions to hear later, or sessions need to be recorded
> because of some business needs?  Or both?  Is SRTP covered or
> only RTP?
>
> Solutions should cover:
>   Always on recording
>   Recording on demand
>   Required recording
>   Pause and resume recording
>   Playback facilities and how they interact with recording
>   Recording formats and protocols for controlling the stored recording.
>
> A lot of discussion ensued on the specific architecture or
> architectures that would be possible.  No decision was reached on
> which specific architecture is good or bad, although various opinions
> were expressed in support for each.
>
> There are essentially four architectures to realize recording
> services: two that discuss where the media stream is forked
> out to the recorder -- at the UA or in a middlebox of some
> sort are outlined here:
>    http://www.ietf.org/mail-archive/web/dispatch/current/msg00226.html
>
> The third architecture has both UAs sending media to a
> recorder.  See:
>      http://www.ietf.org/mail-archive/web/dispatch/current/msg00236.html
>
> A fourth architecture that is a superset of the third one is at:
>      http://www.ietf.org/mail-archive/web/dispatch/current/msg00256.html
>
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
> WWW:   http://ect.bell-labs.com/who/vkg
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

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: [email-masked]
Date: Tue, 07 Jul 2009 17:50:53 +0200

Dear all,

please also have a look at the following draft, which has been  
sumbitted yesterday:

Filename:         draft-romano-dcon-recording
Revision:         00
Title:                 Session Recording for Conferences using SMIL
Creation_date:         2009-07-06
WG ID:                 Independent Submission
Number_of_pages: 24

Abstract:
This document deals with session recording, specifically for what
concerns recording of multimedia conferences, both centralized and
distributed.  Each involved media is recorded separately, and is then
properly tagged.  A SMIL [W3C.CR-SMIL3-20080115] metadata is used to
put all the separate recordings together and handle their
synchronization, as well as the possibly asynchronous opening and
closure of media within the context of a conference.  This SMIL
metadata can subsequently be used by an interested user by means of a
compliant player in order to passively receive a playout of the whole
multimedia conference session.  The motivation for this document
comes from our experience with our conferencing framework, Meetecho,
for which we implemented a recording functionality.

Cheers,

Simon

Quoting "Jain, Rajnish" <[email-masked]>:

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

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: "Doken, Serhad" <[email-masked]>
Date: Fri, 17 Jul 2009 00:56:03 -0700

I read this draft and following are my comments :

Section 3 Definitions

Perhaps Recording Server(RS) should simply be called Recorder. I see the note on the last sentence however as long as definitions refer to Client and Server, it will always imply to the reader to think that RS is the server. The statement that SRP may be SIP is an understatement since the definition for RC already referred to as a SIP UA/B2BUA.

Dynamic Recording, if the recording session is started and ended at random points on demand, its length will not be the same as actual media session.

Persistent Recording, it is not clear what is meant by "system start up". Is "system" referring to RC or RS ? 

Depending on the answer, I am curious how are these persistent recording sessions are correlated to many active media sessions and what would be mechanism to keep them alive ? What is the number of persistent recording sessions per RC/RS ? 

Perhaps implications of this should be covered somewhere else, maybe in the requirements section ?

Section 5 Requirements

REQ-006 Not a good idea to talk about the solution here and how some RC implementations handle the problem.

Perhaps REQ-010 and 011 can be combined into one by just saying "over a single or separate".

REQ-018 can be extended to say that the mechanism MUST support the ability to find out the associated recorded session(s) given that one(for instance RS) is only aware of recording session(s). I'd rather prefer this to be a separate requirement. 

I have another requirement in mind : The mechanism MUST support the ability to setup recording sessions that will record different conversation directions of the Recorded session(s) from RC(s) and they too should be correlated accordingly. For instance, while an agent is talking to a customer, there should be a way to setup two recording sessions, one carrying the media from agent towards customer and vice versa for the other. Furthermore, these recording sessions should be marked as such in SRP.

REQ-021 talks about a mode where RC just forks media to RS. However, there is value in studying transcoding, media incompatibility use cases and see if there are requirements they bring given that RS/RCs are/will most likely have different media capabilities.

If recorded session media is stopped/temporarily interrupted due to problems or features invoked on it(recording session is put on hold or started a conferencing or transfer operation), how does that affect the already setup recording session(s) ?

Nit :

Section2, sentence that starts with "that draft focuses on the mechanism to provide the SRTP...." is odd. It is clear that srtp-key draft is not for session recording, so no need to state the obvious.

Regards,
Serhad Doken

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jain, Rajnish
> Sent: Monday, July 06, 2009 3:48 PM
> To: Vijay Gurbani; [email-masked]
> Subject: Re: [dispatch] Session Recording in SIP
> 
> >    http://www.ietf.org/mail-
> archive/web/dispatch/current/msg00226.html
> >
> >      http://www.ietf.org/mail-
> archive/web/dispatch/current/msg00236.html
> >
> >      http://www.ietf.org/mail-
> archive/web/dispatch/current/msg00256.html
> >
> > - vijay
> > --
> 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: "Jain, Rajnish" <[email-masked]>
Date: Mon, 20 Jul 2009 08:50:57 -0400

Hi,

Thanks for your detailed comments. Please see inline:

> From: Doken, Serhad [mailto:[email-masked]]
> Sent: Friday, July 17, 2009 3:56 AM
> To: Jain, Rajnish; Vijay Gurbani; [email-masked]
> Subject: RE: [dispatch] Session Recording in SIP
>
> Perhaps Recording Server(RS) should simply be called Recorder. I see the
> note on the last sentence however as long as definitions refer to Client and
> Server, it will always imply to the reader to think that RS is the server.

Naming these things is always a bit tricky. If we called the RS simply the Recorder given your reasoning, then the RC should also be named differently (because the RC can act as the "server side" of the SRP signaling). The RS naming is a bit akin to the term "Media Server". If there is enough confusion on RS then, we can consider renaming it.

> The statement that SRP may be SIP is an understatement since the definition
> for RC already referred to as a SIP UA/B2BUA.

This will be clarified in subsequent revisions when we'll say that SRP is indeed SIP.

> Dynamic Recording, if the recording session is started and ended at random
> points on demand, its length will not be the same as actual media session.

Ok. We can clarify this.

> "system" referring to RC or RS ?

It meant that when both devices become functional. We can clarify this.

> Depending on the answer, I am curious how are these persistent recording
> sessions are correlated to many active media sessions and what would be
> mechanism to keep them alive ?

The data over the call metadata interface will offer the correlation. A simple way to keep SRP persistent sessions alive is through the SIP session-timers.

What is the number of persistent recording
> sessions per RC/RS ?

That's an implementation-dependent choice.

> implementations handle the problem.

That note is only informative text. I guess we can take it out.

> Perhaps REQ-010 and 011 can be combined into one by just saying "over a

Fine. Will change this.

> REQ-018 can be extended to say that the mechanism MUST support the ability
> to find out the associated recorded session(s) given that one(for instance
> RS) is only aware of recording session(s). I'd rather prefer this to be a
> separate requirement.

The RS is aware of the recorded session metadata. REQ-018 is a bit broad in the sense that it talks about correlation in either direction (i.e. from recorded sessions to recording sessions and vice-versa). I think your comment is about splitting the two directions, right?

> I have another requirement in mind : The mechanism MUST support the ability
> to setup recording sessions that will record different conversation
> directions of the Recorded session(s) from RC(s) and they too should be
> correlated accordingly. For instance, while an agent is talking to a
> customer, there should be a way to setup two recording sessions, one
> carrying the media from agent towards customer and vice versa for the other.
> Furthermore, these recording sessions should be marked as such in SRP.

Yes, this is needed. This requirement was actually in there and somehow got removed in one of the edits. We'll add this.

> REQ-021 talks about a mode where RC just forks media to RS. However, there
> is value in studying transcoding, media incompatibility use cases and see if
> there are requirements they bring given that RS/RCs are/will most likely
> have different media capabilities.

REQ-021 is primarily about a middle-box type of RC that forks the media. The RC vendors in this case want their boxes to be optimal and scalable by doing as little media processing as possible. REQ-021 isn't precluding the use cases that you mentioned, but I think it'll make sense to address such use cases in this document.

> If recorded session media is stopped/temporarily interrupted due to problems
> or features invoked on it(recording session is put on hold or started a
> conferencing or transfer operation), how does that affect the already setup
> recording session(s) ?

I think that'll largely depend on the RC/RS implementations and the nature of the SRP sessions. For instance, if the recording sessions are persistent and the RC puts recorded session media on hold, then it RC MAY reINVITE the RS and put the recording session media on hold or it MAY just temporarily stop sending such media (silence suppression) to the RS.

> Nit :
>
> Section2, sentence that starts with "that draft focuses on the mechanism to
> provide the SRTP...." is odd. It is clear that srtp-key draft is not for
> session recording, so no need to state the obvious.

Ok. We can change some wording here.

Thanks,
Raj

---

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

> From: Jain, Rajnish [mailto:[email-masked]]
> Sent: Monday, July 20, 2009 5:51 AM
> To: Doken, Serhad; Vijay Gurbani; [email-masked]
> Naming these things is always a bit tricky. If we called the RS simply
> the Recorder given your reasoning, then the RC should also be named
> differently (because the RC can act as the "server side" of the SRP
> signaling). The RS naming is a bit akin to the term "Media Server". If
> there is enough confusion on RS then, we can consider renaming it.

Indeed, I think RC could be renamed as well since it is not a pure client and can be a server at times. Using, Recording Client and Recording Server at section 1 before their definitions are given in Section 2 adds to the confusion. I would offer something like Recorder and (Recorded Media) Forker which is self explanatory.

> > Persistent Recording, it is not clear what is meant by "system start
> up". Is
> > "system" referring to RC or RS ?
> 

It'll probably need more than functional, at a minimum registered/can make-receive calls/process media.

> The data over the call metadata interface will offer the correlation. A
> simple way to keep SRP persistent sessions alive is through the SIP
> session-timers.
> 

Obviously, however as I referred to in my subsequent question below, this may have implications scaling up. If I have a device with high number of simultaneous calls capability, media forker almost needs to keep that many persistent recording sessions and refresh them all the time by session timers. A bunch of race conditions may occur and it may be a drain of resources on the device that is doing the media forking especially when there is no actual session. Moreover, there will be certain assumptions made for such persistent recording sessions such as the codec used for the media session etc.
 
> 
> > Perhaps implications of this should be covered somewhere else, maybe
> in the
> > requirements section ?
> >
> > Section 5 Requirements
> >
> > REQ-006 Not a good idea to talk about the solution here and how some
> RC
> > implementations handle the problem.
> 
> > Perhaps REQ-010 and 011 can be combined into one by just saying "over
> a
> > single or separate".
> 
> Fine. Will change this.
> 
> The RS is aware of the recorded session metadata. REQ-018 is a bit
> broad in the sense that it talks about correlation in either direction
> (i.e. from recorded sessions to recording sessions and vice-versa). I
> think your comment is about splitting the two directions, right?

Yes

> Yes, this is needed. This requirement was actually in there and somehow
> got removed in one of the edits. We'll add this.
> 
> REQ-021 is primarily about a middle-box type of RC that forks the
> media. The RC vendors in this case want their boxes to be optimal and
> scalable by doing as little media processing as possible. REQ-021 isn't
> precluding the use cases that you mentioned, but I think it'll make
> sense to address such use cases in this document.
> 
> I think that'll largely depend on the RC/RS implementations and the
> nature of the SRP sessions. For instance, if the recording sessions are
> persistent and the RC puts recorded session media on hold, then it RC
> MAY reINVITE the RS and put the recording session media on hold or it
> MAY just temporarily stop sending such media (silence suppression) to
> the RS.

In that case, the recorded session and the persistent recording sessions need to be synchronized back during resume which may bring the media clipping problem that persistent recording attempted to solve in the first case.

Regards,
Serhad Doken

---

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

Hi Serhad,

Comments inline:

> Indeed, I think RC could be renamed as well since it is not a pure client
> and can be a server at times. Using, Recording Client and Recording Server
> at section 1 before their definitions are given in Section 2 adds to the
> confusion. I would offer something like Recorder and (Recorded Media) Forker
> which is self explanatory.

The RC/RS naming is intended to be _logical_ as opposed to the client server roles in an INVITE transaction. I'll try to gather design team's input on this.

> Obviously, however as I referred to in my subsequent question below, this
> may have implications scaling up. If I have a device with high number of
> simultaneous calls capability, media forker almost needs to keep that many
> persistent recording sessions and refresh them all the time by session
> timers. A bunch of race conditions may occur and it may be a drain of
> resources on the device that is doing the media forking especially when
> there is no actual session. Moreover, there will be certain assumptions made
> for such persistent recording sessions such as the codec used for the media
> session etc.

These appear to be implementation issues. The SRP mechanism must allow for scalable implementations, but I don't think we can state that RC and RS must support 'n' number of session.

> In that case, the recorded session and the persistent recording sessions
> need to be synchronized back during resume which may bring the media
> clipping problem that persistent recording attempted to solve in the first
> case.

Persistent recording sessions will likely not use re-INVITEs for recording session on recorded session hold/resume. They'll simply pause/resume recording session RTP. The metadata events will slightly lag behind this RTP activity, but there will be timestamps in those events to achieve synchronization.

Thanks,
Raj

---

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

Hi Rajnish,

> Sent: Thursday, July 30, 2009 3:58 AM
> The RC/RS naming is intended to be _logical_ as opposed to the client
> server roles in an INVITE transaction. I'll try to gather design team's
> input on this.
> 
> These appear to be implementation issues. The SRP mechanism must allow
> for scalable implementations, but I don't think we can state that RC
> and RS must support 'n' number of session.
> 

It could be more than implementation issues especially for the enviroments where the media forker (RC) is limited in its capabilities such as memory, power, bandwidth. For such cases it is preferable that the Recorder(RS) sets up the persistent recording sessions.

> 
> > > > If recorded session media is stopped/temporarily interrupted due
> to
> > > problems
> > > > or features invoked on it(recording session is put on hold or
> started
> > > a
> > > > conferencing or transfer operation), how does that affect the
> already
> > > setup
> > > > recording session(s) ?
> > >
> Persistent recording sessions will likely not use re-INVITEs for
> recording session on recorded session hold/resume. They'll simply
> pause/resume recording session RTP. The metadata events will slightly
> lag behind this RTP activity, but there will be timestamps in those
> events to achieve synchronization.

That is interesting. Since we are requirement phase, I will hold off my thoughts till the solution draft.

Thanks,
Serhad Doken