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 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf