RE: [siprec] Last Call: <draft-ietf-siprec-req-09.txt> (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC

I am not sure that having wall clock only for CS start is enough, especially for partial metadata update. I will prefer to have on media level

Leon

-----Original Message-----
From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] 
Sent: Thursday, April 14, 2011 3:58 PM
To: Leon Portman; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org
Cc: siprec@ietf.org
Subject: RE: [siprec] Last Call: <draft-ietf-siprec-req-09.txt> (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC

Understood, but if we have wall clock time for the start of a CS, wouldn't that be sufficient? The new requirement would cover synchronization of all media start/stops relative to that time.

John (as individual)

> -----Original Message-----
> From: Leon Portman [mailto:Leon.Portman@nice.com]
> Sent: 14 April 2011 13:19
> To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org
> Cc: siprec@ietf.org
> Subject: RE: [siprec] Last Call: 
> <draft-ietf-siprec-req-09.txt> (Use Cases andRequirements for 
> SIP-based Media Recording (SIPREC)) toInformational RFC
> 
> Actually REQ-022 and REQ-023 describing not only requirement to 
> synchronize between different media streams but more importantly 
> ability to relate them to real world (wall) clock. It is not only 
> important to playback them correctly but also to know when it was 
> said.
> One example is continue trading after closing hour (even for one 
> second is not allowed)
> 
> And if these media are synchronized to wall clock then they are also 
> synchronized between them thus I am not sure if we need this 
> additional requirement.
> 
> Thanks
> 
> Leon
> 
> -----Original Message-----
> From: siprec-bounces@ietf.org
> [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John
> Sent: Thursday, April 14, 2011 1:54 PM
> To: Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org
> Cc: siprec@ietf.org
> Subject: Re: [siprec] Last Call: 
> <draft-ietf-siprec-req-09.txt> (Use Cases andRequirements for 
> SIP-based Media Recording (SIPREC)) toInformational RFC
> 
> 
>  
> 
> > -----Original Message-----
> > From: siprec-bounces@ietf.org
> > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu
> ArulMozhi Perumal
> > (mperumal)
> > Sent: 14 April 2011 07:34
> > To: ietf@ietf.org
> > Cc: siprec@ietf.org
> > Subject: Re: [siprec] Last Call: 
> > <draft-ietf-siprec-req-09.txt> (Use Cases andRequirements for 
> > SIP-based Media Recording (SIPREC)) toInformational RFC
> > 
> > I've one major comment. It draft discusses synchronization
> between the
> > recorded media streams and synchronized playback, which
> seem important
> > for certain applications:
> > 
> > <snip>
> > Some applications require the recording of more than one
> media stream,
> > possibly of different types. Media are synchronized, either
> at storage
> > or at playback.
> > </snip>
> > 
> > However, in the requirements section it doesn't seem REQ-022 and
> > REQ-023 are all that are need and sufficient to achieve this with 
> > needed precision. So, I would suggest adding another requirement as
> > follows:
> > The mechanism MUST provide means for facilitating
> synchronization of
> > the recorded media streams and metadata either at storage or at 
> > playback.
> > This includes, but not limited to, the information needed as per
> > REQ-022 and REQ-023.
> [JRE] This seems a reasonable addition. I wonder if the new 
> requirement (first sentence only) is sufficient as a
> **replacement** for REQ-022 and REQ-023. On reading REQ-022 and 
> REQ-023 again, it is not so clear what their purpose was, and they 
> seem to be more like a solution than a requirement.
> One purpose would certainly be that covered by Muthu's new 
> requirement. Was there any other purpose?
> 
> John
> 
> > 
> > A nitpick:
> > Use Case 8
> > In cases where calls inside or between branches must be recorded, a 
> > centralized recording system in data centers together with
> telephony
> > infrastructure (e.g. PBX) me deployed.
> > 
> > s/me/may be
> > 
> > Muthu
> > 
> > |-----Original Message-----
> > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On
> > Behalf Of The IESG
> > |Sent: Wednesday, April 06, 2011 6:20 PM
> > |To: IETF-Announce
> > |Cc: siprec@ietf.org
> > |Subject: [siprec] Last Call: <draft-ietf-siprec-req-09.txt>
> > (Use Cases
> > andRequirements for SIP-based
> > |Media Recording (SIPREC)) toInformational RFC
> > |
> > |
> > |The IESG has received a request from the SIP Recording WG
> (siprec) to
> > |consider the following document:
> > |- 'Use Cases and Requirements for SIP-based Media
> Recording (SIPREC)'
> > |  <draft-ietf-siprec-req-09.txt> as an Informational RFC
> > |
> > |The IESG plans to make a decision in the next few weeks,
> and solicits
> > |final comments on this action. Please send substantive
> > comments to the
> > |ietf@ietf.org mailing lists by 2011-04-20. Exceptionally,
> > comments may
> > be
> > |sent to iesg@ietf.org instead. In either case, please retain the 
> > |beginning of the Subject line to allow automated sorting.
> > |
> > |The file can be obtained via
> > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/
> > |
> > |IESG discussion can be tracked via
> > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/
> > |
> > |
> > |
> > |No IPR declarations have been submitted directly on this I-D.
> > |_______________________________________________
> > |siprec mailing list
> > |siprec@ietf.org
> > |https://www.ietf.org/mailman/listinfo/siprec
> > _______________________________________________
> > siprec mailing list
> > siprec@ietf.org
> > https://www.ietf.org/mailman/listinfo/siprec
> > 
> _______________________________________________
> siprec mailing list
> siprec@ietf.org
> https://www.ietf.org/mailman/listinfo/siprec
> 