RE: [siprec] LastCall:<draft-ietf-siprec-req-09.txt>(UseCases andRequirementsforSIP-basedMediaRecording (SIPREC)) toInformational RFC

["Parthasarathi R (partr)" <[e-mail]>]

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