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

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

> -----Original Message-----
> From: Jain, Rajnish [mailto:[e-mail]]
> Sent: Thursday, July 30, 2009 4:17 AM
> To: Doken, Serhad; Leon Portman; Alan Johnston; [e-mail]
> Subject: RE: [dispatch] Comments on draft-jain-dispatch-session-
> recording-protocol-req-00
> 
> > > 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.
> > >
> > > [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.
> 
> 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.