I was thinking we needed a way to synchronize media from multiple CSs, which may be received by the SRS from one or more SRCs. Is this not a requirement? Thanks, Charles > -----Original Message----- > From: siprec-bounces@xxxxxxxx [mailto:siprec-bounces@xxxxxxxx] On Behalf Of Muthu ArulMozhi Perumal > (mperumal) > Sent: Thursday, April 14, 2011 1:42 PM > 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 forSIP-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