RE: [siprec] Last Call:<draft-ietf-siprec-req-09.txt>(Use CasesandRequirements forSIP-based MediaRecording (SIPREC)) toInformational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I agree, we should have dedicated wall clock requirement

Leon

-----Original Message-----
From: Parthasarathi R (partr) [mailto:partr@xxxxxxxxx] 
Sent: Thursday, April 21, 2011 4:51 PM
To: Muthu ArulMozhi Perumal (mperumal); Elwell, John; Ram Mohan R (rmohanr); Leon Portman; ietf@xxxxxxxx
Cc: siprec@xxxxxxxx
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@xxxxxxxx [mailto:siprec-bounces@xxxxxxxx] 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@xxxxxxxx
Cc: siprec@xxxxxxxx
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.elwell@xxxxxxxxxxxxxxxxxxxxxx]
|Sent: Friday, April 15, 2011 11:53 AM
|To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon
Portman; ietf@xxxxxxxx
|Cc: siprec@xxxxxxxx
|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@xxxxxxxxx]
|> Sent: 14 April 2011 21:42
|> 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 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@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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]