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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf