Re: [dispatch] Session recording in SIP

["Doken, Serhad" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of James M. Polk
> Sent: Wednesday, June 10, 2009 3:00 PM
> To: Roni Even; 'Alan Johnston'; 'Romascanu, Dan (Dan)'
> Cc: 'Leon Portman'; [e-mail]; 'Jain, Rajnish'; 'Hadriel
> Kaplan'
> Subject: Re: [dispatch] Session recording in SIP
> 
> Hey
> 
> I agree with Roni about this probably being best suited for XCON,
> after all, any point to point recording is likely (merely) adding a
> 3rd party (the recorder) to the session.
> 
> This brings up probably the most glaring whole (in my mind) that is
> not mentioned below - the ability to have a recorder without at least
> one side knowing it's there.  Not every time, and in fact probably
> most times, you don't want the other person knowing you are recording
> them. It's likely more of a case of not explicitly asking the called
> party "can I record this conversation", it just happens.

As someone who have implemented SIP based recording which has been shipping for several years, this thread caught my eye though I haven't read the whole lively set of e-mails yet. 

In most enterprise contact center environments(say 1-800-2CALLME), caller(let's call him customer) will get an announcement of some sort like "This call may/will be monitored/recorded for quality purposes" at the beginning of the call. For limited cases, customer has a chance to accept/reject that or if refuses he/she can hang up. Called party(Agent) as an employee is almost always aware that call may be recorded since contact center businesses collect quality and business analytic data based on those recordings. Moreover, in some deployments, periodic recording tones are played towards customer and agent phones to alert/remind them that call is being recorded. It could be the case that sometimes all calls are recorded or sometimes calls to a particular set of agent phones are recorded.

On the other hand, a supervisor monitoring a conversation between a customer and agent may decide to record that conversation, at any random point, simply triggering it via a CTI application that is running on his desktop for the whole call duration or may wish to stop that recording at any random point.

Serhad

> 
> James
> 
> At 11:18 AM 6/10/2009, Roni Even wrote:
> >Hi,
> >I agree that this is an important work but I am not sure about a WG.
> This
> >may be done in XCON and AVT.
> >Note that the recording is not only for point to point call but at
> least for
> >three parties like in call center scenarios
> >
> >I also did not notice any mention of the playback part but it should
> also be
> >addressed
> >
> >Roni Even
> >
> >-----Original Message-----
> >From: [e-mail] [mailto:[e-mail]] On
> Behalf
> >Of Alan Johnston
> >Sent: Wednesday, June 10, 2009 4:42 PM
> >To: Romascanu, Dan (Dan)
> >Cc: Leon Portman; [e-mail]; Jain, Rajnish; Hadriel Kaplan
> >Subject: Re: [dispatch] Session recording in SIP
> >
> >This is important work to be done in RAI.  Key management for secure
> >recording is an important component that needs to be addressed.
> >
> >draft-wing-sipping-srtp-key-04 addresses many of these topics.
> >
> >Thanks,
> >Alan
> >
> >
> >Romascanu, Dan (Dan) wrote:
> > > I believe that this is an important application, and I support
> doing
> > > work in this direction.
> > >
> > > Three comments on the preliminary words:
> > >
> > > 1. The requirement is for both signaling and media recording,
> right?
> > > Probably good to say it.
> > > 2. Security and regulations on how the information is accessed and
> > > protected are of high importance. They would probably be reflected
> in
> > > the requirements, but explicit wording in the future charter can
> help.
> > > 3. I suggest that we look at the IPFIX protocol as a possible
> technology
> > > to re-use
> > >
> > > Dan
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: [e-mail]
> > >> [mailto:[e-mail]] On Behalf Of Vijay K. Gurbani
> > >> Sent: Wednesday, June 10, 2009 12:02 AM
> > >> To: [e-mail]
> > >> Cc: Leon Portman; Jain,Rajnish; Hadriel Kaplan
> > >> Subject: [dispatch] Session recording in SIP
> > >>
> > >> Hi: I realize that the deadline for charter proposals was
> > >> yesterday, but I hope that it is not too late to submit one more.
> > >>
> > >> A few interested people (Hadriel Kaplan, Dan Wing, Rajnish
> > >> Jain, Leon Portman, Andrew Hutton and I) have been interested
> > >> in RTP session recording in SIP.  The requirement draft will
> > >> be released shortly.
> > >>
> > >> We would like to request agenda time in dispatch to propose
> > >> the formation of a new working group to define protocol
> > >> extensions and an architecture for RTP recording.
> > >>
> > >> Session recording in SIP
> > >> Mailing Lists: TBD
> > >> Chairs: TBD
> > >> Area Directorate: Real Time Applications (RAI)
> > >>
> > >> Purpose:
> > >>
> > >> Session recording is a critical operational requirement in
> > >> many businesses, especially where voice is used as a medium
> > >> for commerce and customer support. A prime example where
> > >> voice is used for trade is the financial industry. The call
> > >> recording requirements in this industry are quite stringent.
> > >> The recorded calls are used for dispute resolution and
> > >> regulatory compliance. Other businesses such as customer
> > >> support call centers typically employ call recording for
> > >> quality control or business analytics.
> > >>
> > >> Depending on the country and its regulatory requirements,
> > >> financial trading floors typically must record all calls. The
> > >> recorded media content must be an exact copy of the actual
> > >> conversation (i.e.
> > >> clipping and loss of media are unacceptable).  Some
> > >> deployments and regulations require that calls be aborted or
> > >> rejected if the recording device is unavailable.
> > >>
> > >> This group will specify requirements for a SIP based protocol
> > >> interface between a communications system and a recorder. The
> > >> Communications System is responsible for establishing media
> > >> sessions where the actual business is conducted. The Recorder
> > >> is the sink of the recorded media.
> > >>
> > >> The recorded sessions can be of any kind such as voice, video
> > >> and instant messaging. A recorded session is typically
> > >> comprised of actual media content and the call metadata. The
> > >> call metadata allows recording archives to be searched and
> > >> filtered at a later time.
> > >> The conveyance of call metadata from the communications
> > >> system to the recorder is outside the scope of this document.
> > >>
> > >> This group will only looks into active recording, where the
> > >> recorded system purposefully streams media to a recording
> > >> device. Passive recording, where a recording device detects
> > >> media directly from the network, is outside the scope of this
> > >> document. In addition, lawful intercept is outside the scope
> > >> of the group.
> > >>
> > >> Proposed deliverables:
> > >>
> > >> 1) Requirements document;
> > >> 2) Solutions document, including reference architecture.
> > >>
> > >> Thanks,
> > >>
> > >> - 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}
> > >> Web:   http://ect.bell-labs.com/who/vkg/
> > >> _______________________________________________
> > >> dispatch mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/dispatch
> > >>
> > >>
> > > _______________________________________________
> > > dispatch mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dispatch
> > >
> > >
> >
> >_______________________________________________
> >dispatch mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/dispatch
> >
> >_______________________________________________
> >dispatch mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/dispatch
> 
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch