Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-05.txt

From: <[email-masked]>
Date: Tue, 1 Nov 2011 08:21:33 +0000

Ram

The only issue I can see is that the voice recorder companies will not be able to do call reconstruction as there will be parts of the call where they have no RS that has an activestream and so will not be informed about these parts of a CS.

I agree that in terms of recording this info is not needed as there is no recording associated with it. However any voice recorder that was hoping to use the meta data to provide call records will now not be abl eto do so.

Since we are developing th eswitch side of this we are OK with it I just wanted to confirm th eVoice Recorder companies are also happy

Finlay

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Ram Mohan R (rmohanr) [[email-masked]]
Sent: 01 November 2011 06:49
To: Stafford,J,John,JRJ3X C; [email-masked]
Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-05.txt

Hi John S

Please see inline

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, October 31, 2011 9:59 PM
> To: Ram Mohan R (rmohanr); [email-masked]
> Subject: RE: [siprec] I-D Action: draft-ietf-siprec-metadata-05.txt
>
> Ram,
>
> If CS has associate/dissaociated instead of begin/end times, then
there
> won't be any way of signalling that a CS has ended, only that it is no
> longer being recorded.
>
> Especially as Charles says it was going to be allowed to have a CS
with
> zero participants.
>
> Maybe CS needs BOTH associate/dissassociate and begin/end times ?

The associate-time here indicates the time a CS was associated with a
RS. IOW it is the time the recording of CS is started in that RS.
Disassociate time indicate the time the recording of CS was stopped from
that RS.  The reason why this attribute was added is to address cases
where only parts of CS is recorded(e.g. you record the first few mins of
a CS, then stop the recording, then re-start recording of the same CS
after some time). In such cases indicating begin/end of CS is not
correct as CS has not ended, but RS has ended.  So the WG decided it's
better to have associate/disassociate time and have its scope to a RS so
that a CS may have multiple associate/disassociate times if need be. For
simple cases where the entire CS is recorded, the associate/disassociate
times may be mapped to the CS begin/end times assuming recording is
started the same moment CS is setup.

 I agree that with this approach, we are not indicating explicitly
indicating when the CS has actually started/ended.
>From the past discussions, there was no much interest in keeping both of
this information. If you think there are enough use-cases where
indicating both these will be helpful please bring them, we can discuss
further and add begin/end times after getting consensus from WG.

Regards,
Ram

>
> Rgds
> John Stafford | Solution Architect 1 | BT Global Services | Tel:+44
> (0)1932 773504   | E: [email-masked]  |
> www.bt.com/globalservices
> ________________________________________
> From: Ram Mohan R (rmohanr) [[email-masked]]
> Sent: 31 October 2011 15:46
> To: Stafford,J,John,JRJ3X C; [email-masked]
> Subject: RE: [siprec] I-D Action: draft-ietf-siprec-metadata-05.txt
>
> John,
>
> This needs to be changed to associate/disassociate time to be in
> consistent with model. We will take care in the next revision.
>
> Ram
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of [email-masked]
> > Sent: Monday, October 31, 2011 8:09 PM
> > To: [email-masked]
> > Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-05.txt
> >
> > Partha
> >
> > sections 6.3, 7.1,and  8 show CS as having Associate Time and
> > Dissassociate Time,
> > but  examples in section 13 show CS having start-time and end-time.
> >
> >
> > Rgds
> > John Stafford | Solution Architect 1 | BT Global Services
> >
> > ________________________________________
> > From: [email-masked] [[email-masked]] On Behalf Of
> > [email-masked] [[email-masked]]
> > Sent: 31 October 2011 13:36
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-05.txt
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories. This draft is a work item of the SIP Recording Working
> > Group of the IETF.
> >
> >         Title           : Session Initiation Protocol (SIP)
Recording
> > Metadata
> >         Author(s)       : Ram Mohan Ravindranath
> >                           Parthasarathi Ravindran
> >                           Paul Kyzivat
> >         Filename        : draft-ietf-siprec-metadata-05.txt
> >         Pages           : 45
> >         Date            : 2011-10-31
> >
> >    Session recording is a critical requirement in many
communications
> >    environments such as call centers and financial trading.  In some
> of
> >    these environments, all calls must be recorded for regulatory,
> >    compliance, and consumer protection reasons.  Recording of a
> session
> >    is typically performed by sending a copy of a media stream to a
> >    recording device.  This document describes the metadata model as
> >    viewed by Session Recording Server(SRS) and the Recording
metadata
> >    format.
> >
> >
> > A URL for this Internet-Draft is:
> >
http://www.ietf.org/internet-drafts/draft-ietf-siprec-metadata-05.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > This Internet-Draft can be retrieved at:
> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-metadata-05.txt
> > _______________________________________________
> > siprec mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/siprec
> > _______________________________________________
> > siprec mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/siprec
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: Ravindran Parthasarathi <[email-masked]>
Date: Tue, 1 Nov 2011 19:26:27 +0000

Hi Finlay,

AFAIK, we haven't heard any objection for the current proposal from Voice 
Recorder implementers. 

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of [email-masked]
>Sent: Tuesday, November 01, 2011 1:52 PM
>To: [email-masked]; [email-masked]; [email-masked]
>The only issue I can see is that the voice recorder companies will not
>be able to do call reconstruction as there will be parts of the call
>where they have no RS that has an activestream and so will not be
>informed about these parts of a CS.
>
>I agree that in terms of recording this info is not needed as there is
>no recording associated with it. However any voice recorder that was
>hoping to use the meta data to provide call records will now not be abl
>eto do so.
>
>Since we are developing th eswitch side of this we are OK with it I just
>wanted to confirm th eVoice Recorder companies are also happy
>
>Finlay
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Nov 2011 12:01:52 -0400

Finlay,

IIUC you are concerned about recording the actual start and stop times 
of call signaling, regardless of whether the media is recorded or not. 
Is that right? But it isn't entirely straightforward to determine when a 
call starts and ends. We have abstracted CS, so that it isn't identical 
to SIP Dialog - it might be a conference, or more complex things.

We do have the associate/dissociate of participants to CS - which is 
distinct from association/dissociate from media streams. So for 
practical purposes, you can assume a CS to start when a participant is 
first associated with it, and to end when the last participant is 
dissociated from it. This is so even if none of the media is ever recorded.

So what is missing?

	Thanks,
	Paul