I suppose the most common case of multiple CS from a single SRC is a
conference focus acting as SRC. In this case, the SRC could help
synchronization of the individual CSs as part of sending to RS. Perhaps
it is not required to do so, but it should if it can.
For the case of multiple SRCs which you say is out of scope, I do not
see anything in the requirements that says otherwise, but it was always
my assumption that you could have multiple SRCs. For example, a point to
point call and each sends its stream to RS. I will reread the
requirements more closely.
Cheers,
Charles
-----Original Message-----
From: Parthasarathi R (partr)
Sent: Thursday, April 14, 2011 10:26 PM
To: Charles Eckel (eckelcu); Muthu ArulMozhi Perumal (mperumal); Ram
Mohan R (rmohanr); Leon Portman;
Elwell, John; ietf(_at_)ietf(_dot_)org
Cc: siprec(_at_)ietf(_dot_)org
Subject: RE: [siprec] LastCall:<draft-ietf-siprec-req-09.txt>(UseCases
andRequirementsforSIP-
basedMediaRecording (SIPREC)) toInformational RFC
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: siprec-bounces(_at_)ietf(_dot_)org
[mailto:siprec-bounces(_at_)ietf(_dot_)org] 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;
ietf(_at_)ietf(_dot_)org
Cc: siprec(_at_)ietf(_dot_)org
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: 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
_______________________________________________
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