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(_at_)ietf(_dot_)org
[mailto:siprec-bounces(_at_)ietf(_dot_)org] 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(_at_)ietf(_dot_)org
Cc: siprec(_at_)ietf(_dot_)org
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(_dot_)elwell(_at_)siemens-enterprise(_dot_)com]
|Sent: Friday, April 15, 2011 11:53 AM
|To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon
Portman; ietf(_at_)ietf(_dot_)org
|Cc: siprec(_at_)ietf(_dot_)org
|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(_at_)cisco(_dot_)com]
|> Sent: 14 April 2011 21:42
|> To: Ram Mohan R (rmohanr); Leon Portman; Elwell, John;
ietf(_at_)ietf(_dot_)org
|> Cc: siprec(_at_)ietf(_dot_)org
|> 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(_at_)ietf(_dot_)org
|> |Cc: siprec(_at_)ietf(_dot_)org
|> |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(_at_)ietf(_dot_)org
[mailto:siprec-bounces(_at_)ietf(_dot_)org] On
|> |> Behalf Of Leon Portman
|> |> Sent: Thursday, April 14, 2011 9:57 PM
|> |> To: Elwell, John; Muthu ArulMozhi Perumal (mperumal);
ietf(_at_)ietf(_dot_)org
|> |> Cc: siprec(_at_)ietf(_dot_)org
|> |> 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(_dot_)elwell(_at_)siemens-enterprise(_dot_)com]
|> |> Sent: Thursday, April 14, 2011 3:58 PM
|> |> To: Leon Portman; Muthu ArulMozhi Perumal (mperumal);
ietf(_at_)ietf(_dot_)org
|> |> Cc: siprec(_at_)ietf(_dot_)org
|> |> 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(_dot_)Portman(_at_)nice(_dot_)com]
|> |> > Sent: 14 April 2011 13:19
|> |> > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal);
|> ietf(_at_)ietf(_dot_)org
|> |> > Cc: siprec(_at_)ietf(_dot_)org
|> |> > 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(_at_)ietf(_dot_)org
|> |> > [mailto:siprec-bounces(_at_)ietf(_dot_)org] On Behalf Of Elwell, John
|> |> > Sent: Thursday, April 14, 2011 1:54 PM
|> |> > To: Muthu ArulMozhi Perumal (mperumal); ietf(_at_)ietf(_dot_)org
|> |> > Cc: siprec(_at_)ietf(_dot_)org
|> |> > 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(_at_)ietf(_dot_)org
|> |> > > [mailto:siprec-bounces(_at_)ietf(_dot_)org] On Behalf Of Muthu
|> |> > ArulMozhi Perumal
|> |> > > (mperumal)
|> |> > > Sent: 14 April 2011 07:34
|> |> > > To: ietf(_at_)ietf(_dot_)org
|> |> > > Cc: siprec(_at_)ietf(_dot_)org
|> |> > > 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(_at_)ietf(_dot_)org
[mailto:siprec-bounces(_at_)ietf(_dot_)org]
|> On
|> |> > > Behalf Of The IESG
|> |> > > |Sent: Wednesday, April 06, 2011 6:20 PM
|> |> > > |To: IETF-Announce
|> |> > > |Cc: siprec(_at_)ietf(_dot_)org
|> |> > > |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(_at_)ietf(_dot_)org mailing lists by 2011-04-20. Exceptionally,
|> |> > > comments may
|> |> > > be
|> |> > > |sent to iesg(_at_)ietf(_dot_)org 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(_at_)ietf(_dot_)org
|> |> > > |https://www.ietf.org/mailman/listinfo/siprec
|> |> > > _______________________________________________
|> |> > > siprec mailing list
|> |> > > siprec(_at_)ietf(_dot_)org
|> |> > > https://www.ietf.org/mailman/listinfo/siprec
|> |> > >
|> |> > _______________________________________________
|> |> > siprec mailing list
|> |> > siprec(_at_)ietf(_dot_)org
|> |> > https://www.ietf.org/mailman/listinfo/siprec
|> |> >
|> |> _______________________________________________
|> |> siprec mailing list
|> |> siprec(_at_)ietf(_dot_)org
|> |> https://www.ietf.org/mailman/listinfo/siprec
|>
_______________________________________________
siprec mailing list
siprec(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/siprec
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf