I am fine with separated REQ-022 and REQ-xxx. Though the solution for REQ-022 and REQ-xxx could be based on the wallclock time, having an explicit REQ-023 looks fine from a requirements perspective. Muthu |-----Original Message----- |From: Elwell, John [mailto:john.elwell@xxxxxxxxxxxxxxxxxxxxxx] |Sent: Thursday, April 21, 2011 9:15 PM |To: Leon Portman; Parthasarathi R (partr); Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); |ietf@xxxxxxxx |Cc: siprec@xxxxxxxx |Subject: RE: [siprec] Last Call:<draft-ietf-siprec-req-09.txt>(UseCasesandRequirements forSIP-based |MediaRecording (SIPREC)) toInformational RFC | |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