I like the separated REQ-022 and REQ-xxx. In accordance with previous discussions, I think we need REQ-023 too. John (as individual) > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@xxxxxxxx] > Sent: 21 April 2011 14:54 > To: Parthasarathi R (partr); Muthu ArulMozhi Perumal > (mperumal); Elwell, John; Ram Mohan R (rmohanr); ietf@xxxxxxxx > Cc: siprec@xxxxxxxx > Subject: RE: [siprec] Last > Call:<draft-ietf-siprec-req-09.txt>(Use CasesandRequirements > forSIP-based MediaRecording (SIPREC)) toInformational RFC > > I agree, we should have dedicated wall clock requirement > > Leon > > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@xxxxxxxxx] > Sent: Thursday, April 21, 2011 4:51 PM > To: Muthu ArulMozhi Perumal (mperumal); Elwell, John; Ram > Mohan R (rmohanr); Leon Portman; ietf@xxxxxxxx > Cc: siprec@xxxxxxxx > Subject: RE: [siprec] Last > Call:<draft-ietf-siprec-req-09.txt>(Use CasesandRequirements > forSIP-based MediaRecording (SIPREC)) toInformational RFC > > Muthu/John, > > I will prefer to have "a" and "b" as separate requirement as > "a" is related to RTP & its model, needs more discussion > whereas "b" will be related to SIPREC metadata model which > will be addressed by the current mechanism of start/stop time > of media stream block. > > REQ-022: The mechanism MUST provide means for facilitating > synchronization of the recorded media streams and metadata. > > REQ-xxx: The mechanism MUST provide means for facilitating > synchronization among the recorded media streams > > Apart from this, I'm interested to know whether John's > Req-023 requirement in the below mail will be solved by the > current proposed REQ-xxx. > > Thanks > Partha > > -----Original Message----- > From: siprec-bounces@xxxxxxxx > [mailto:siprec-bounces@xxxxxxxx] On Behalf Of Muthu ArulMozhi > Perumal (mperumal) > Sent: Thursday, April 21, 2011 5:15 PM > To: Elwell, John; Ram Mohan R (rmohanr); Leon Portman; ietf@xxxxxxxx > Cc: siprec@xxxxxxxx > Subject: Re: [siprec] Last Call:<draft-ietf-siprec-req-09.txt>(Use > CasesandRequirements forSIP-based MediaRecording (SIPREC)) > toInformational RFC > > +1 > > I would suggest a small change to REQ-022 that John has > drafted below to make it more explicit: > > REQ-022 The mechanism MUST provide means for facilitating the > following either at storage or at playback: > a. Synchronization among the recorded media streams and b. > Synchronization of the recorded media streams and metadata. > > Muthu > > |-----Original Message----- > |From: Elwell, John [mailto:john.elwell@xxxxxxxxxxxxxxxxxxxxxx] > |Sent: Friday, April 15, 2011 11:53 AM > |To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon > Portman; ietf@xxxxxxxx > |Cc: siprec@xxxxxxxx > |Subject: RE: [siprec] Last Call: <draft-ietf-siprec-req-09.txt>(Use > CasesandRequirements for SIP-based > |MediaRecording (SIPREC)) toInformational RFC > | > |So perhaps if we replace REQ-022 and REQ-023 with the > requirement that > Muthu has proposed and one > |further requirement, e.g.: > | > |"REQ-022 The mechanism MUST provide means for facilitating > synchronization of the > |recorded media streams and metadata either at storage or at playback. > | > |REQ-023 The mechanism MUST provide means for relating recordings to > wall clock time." > | > |John (as individual) > | > |> -----Original Message----- > |> From: Muthu ArulMozhi Perumal (mperumal) > [mailto:mperumal@xxxxxxxxx] > |> Sent: 14 April 2011 21:42 > |> To: Ram Mohan R (rmohanr); Leon Portman; Elwell, John; > ietf@xxxxxxxx > |> Cc: siprec@xxxxxxxx > |> Subject: RE: [siprec] Last Call: > |> <draft-ietf-siprec-req-09.txt>(Use Cases andRequirements for > |> SIP-based MediaRecording (SIPREC)) toInformational RFC > |> > |> I agree with John that these seem more like part of a > solution rather > > |> than actual requirements. In addition, sending the > wallclock time at > |> media start/end alone may not suffice for achieving inter-media > |> synchronization and playback, instead we may need to send the > |> wallclock time periodically, like RTCP. For e.g, if there > is a codec > |> renegotiation in CS the RTP timestamp can restart from a random > |> value. If silence suppression is enabled there would be > gaps in the > |> RTP timestamp. > |> > |> These are things that need to be discussed as part of the > solution -- > > |> the requirement itself should be generic enough, like what I > |> described. > |> REQ-022 and REQ-023 we have doesn't seem to clearly indicate the > |> purpose. > |> > |> Muthu > |> > |> |-----Original Message----- > |> |From: Ram Mohan R (rmohanr) > |> |Sent: Thursday, April 14, 2011 10:13 PM > |> |To: Leon Portman; 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 MediaRecording (SIPREC)) toInformational RFC > |> | > |> |We already have attributes Start-Time / End-time in Media Stream > |> block. This is for the same purpose > |> |to indicate the wall clock time for start/end of media. > |> | > |> |Ram > |> | > |> |> -----Original Message----- > |> |> From: siprec-bounces@xxxxxxxx > [mailto:siprec-bounces@xxxxxxxx] On > |> |> Behalf Of Leon Portman > |> |> Sent: Thursday, April 14, 2011 9:57 PM > |> |> 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 MediaRecording (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@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 > |> |> > > |> |> _______________________________________________ > |> |> 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