I suppose the most common case of multiple CS from a single SRC is a conference focus acting as SRC. In this case, the SRC could help synchronization of the individual CSs as part of sending to RS. Perhaps it is not required to do so, but it should if it can. For the case of multiple SRCs which you say is out of scope, I do not see anything in the requirements that says otherwise, but it was always my assumption that you could have multiple SRCs. For example, a point to point call and each sends its stream to RS. I will reread the requirements more closely. Cheers, Charles > -----Original Message----- > From: Parthasarathi R (partr) > Sent: Thursday, April 14, 2011 10:26 PM > To: Charles Eckel (eckelcu); Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon Portman; > Elwell, John; ietf@xxxxxxxx > Cc: siprec@xxxxxxxx > Subject: RE: [siprec] LastCall:<draft-ietf-siprec-req-09.txt>(UseCases andRequirementsforSIP- > basedMediaRecording (SIPREC)) toInformational RFC > > Charles, > > synchronize multiple CS from multiple SRCs to single SRS is outside the scope of SIPREC. I'm not very > clear about the requirement of media synchronization for multiple CS from single SRC because each CS > have its own media stream, is there any need to synchronize between multiple CS? > > Muthu, > > I'm seeing two requirement here: > > 1) Timestamp synchronization between metadata and media stream. > > This is possible to be achieved by current metadata media stream start& stop time wherein media packet > shall be stored or played back with the reference to start time of media stream block. Say Media > stream start time as T0 and end time as T1, the first media packet is received at T0+ t[i] wherein > t[i] is the time interval between T0 and first media packet. Here T0+t[i] is always less than T1. > Playback shall use T0 as the reference value. Here there is no need of extra time reference required. > > 2) Timestamp synchronization between multiple media stream (audio + video) > > New requirement is to synchronize between media stream and there is need to identify the detailed > requirement. Infact, I'm still not very much clear which may be due to my lack of specific details > about audio+Video recording. > > Please correct in case I'm missing something. > > Thanks > Partha > > -----Original Message----- > From: siprec-bounces@xxxxxxxx [mailto:siprec-bounces@xxxxxxxx] On Behalf Of Charles Eckel (eckelcu) > Sent: Friday, April 15, 2011 4:59 AM > To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon Portman; Elwell, John; > ietf@xxxxxxxx > Cc: siprec@xxxxxxxx > Subject: Re: [siprec] LastCall:<draft-ietf-siprec-req-09.txt>(Use Cases andRequirements forSIP- > basedMediaRecording (SIPREC)) toInformational RFC > > 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 > _______________________________________________ > siprec mailing list > siprec@xxxxxxxx > https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf