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(_dot_)elwell(_at_)siemens-enterprise(_dot_)com]
|Sent: Thursday, April 21, 2011 9:15 PM
|To: Leon Portman; Parthasarathi R (partr); Muthu ArulMozhi Perumal
(mperumal); Ram Mohan R (rmohanr);
|ietf(_at_)ietf(_dot_)org
|Cc: siprec(_at_)ietf(_dot_)org
|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(_dot_)Portman(_at_)nice(_dot_)com]
|> Sent: 21 April 2011 14:54
|> To: Parthasarathi R (partr); Muthu ArulMozhi Perumal
|> (mperumal); Elwell, John; Ram Mohan R (rmohanr); 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
|>
|> I agree, we should have dedicated wall clock requirement
|>
|> Leon
|>
|> -----Original Message-----
|> From: Parthasarathi R (partr) [mailto:partr(_at_)cisco(_dot_)com]
|> Sent: Thursday, April 21, 2011 4:51 PM
|> To: Muthu ArulMozhi Perumal (mperumal); 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
|>
|> 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