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@xxxxxxxxxxxxxxxxxxxxxx] Sent: Thursday, April 14, 2011 3:58 PM To: Leon Portman; Muthu ArulMozhi Perumal (mperumal); ietf@xxxxxxxx Cc: siprec@xxxxxxxx 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@xxxxxxxx] > Sent: 14 April 2011 13:19 > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@xxxxxxxx > Cc: siprec@xxxxxxxx > 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@xxxxxxxx > [mailto:siprec-bounces@xxxxxxxx] On Behalf Of Elwell, John > Sent: Thursday, April 14, 2011 1:54 PM > To: Muthu ArulMozhi Perumal (mperumal); ietf@xxxxxxxx > Cc: siprec@xxxxxxxx > 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@xxxxxxxx > > [mailto:siprec-bounces@xxxxxxxx] On Behalf Of Muthu > ArulMozhi Perumal > > (mperumal) > > Sent: 14 April 2011 07:34 > > To: ietf@xxxxxxxx > > Cc: siprec@xxxxxxxx > > 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@xxxxxxxx [mailto:siprec-bounces@xxxxxxxx] On > > Behalf Of The IESG > > |Sent: Wednesday, April 06, 2011 6:20 PM > > |To: IETF-Announce > > |Cc: siprec@xxxxxxxx > > |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@xxxxxxxx mailing lists by 2011-04-20. Exceptionally, > > comments may > > be > > |sent to iesg@xxxxxxxx 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@xxxxxxxx > > |https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > > siprec mailing list > > siprec@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > siprec mailing list > siprec@xxxxxxxx > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf