ietf
[Top] [All Lists]

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

2011-04-15 09:56:18
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(_at_)ietf(_dot_)org 
[mailto:siprec-bounces(_at_)ietf(_dot_)org] 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(_at_)ietf(_dot_)org
Cc: siprec(_at_)ietf(_dot_)org
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(_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

<Prev in Thread] Current Thread [Next in Thread>