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