Subject: RE: [siprec] Last Call: <draft-ietf-siprec-req-09.txt> (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 14 Apr 2011 12:03:31 +0530

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.

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: [email-masked] [mailto:[email-masked]] On
Behalf Of The IESG
|Sent: Wednesday, April 06, 2011 6:20 PM
|To: IETF-Announce
|Cc: [email-masked]
|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
[email-masked] mailing lists by 2011-04-20. Exceptionally, comments may
be
|sent to [email-masked] 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
[email-masked]
|https://www.ietf.org/mailman/listinfo/siprec

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Apr 2011 12:54:23 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Muthu ArulMozhi 
> Perumal (mperumal)
> Sent: 14 April 2011 07:34
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [siprec] Last Call: 
> <draft-ietf-siprec-req-09.txt> (Use Cases andRequirements for 
> SIP-based Media Recording (SIPREC)) toInformational RFC
> 
[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

> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: Leon Portman <[email-masked]>
Date: Thu, 14 Apr 2011 15:18:36 +0300

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: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Thursday, April 14, 2011 1:54 PM
To: Muthu ArulMozhi Perumal (mperumal); [email-masked]
Cc: [email-masked]
Subject: Re: [siprec] Last Call: <draft-ietf-siprec-req-09.txt> (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC

> [mailto:[email-masked]] On Behalf Of Muthu ArulMozhi Perumal 
> (mperumal)
> 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.

John

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Apr 2011 14:57:30 +0200

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)

> From: Leon Portman [mailto:[email-masked]] 
> Sent: 14 April 2011 13:19
> To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); [email-masked]
> Cc: [email-masked]
> Subject: RE: [siprec] Last Call: 
> 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.
> 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
> 
> [mailto:[email-masked]] On Behalf Of Elwell, John
> [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

---

From: Leon Portman <[email-masked]>
Date: Thu, 14 Apr 2011 19:27:10 +0300

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:[email-masked]] 
Sent: Thursday, April 14, 2011 3:58 PM
To: Leon Portman; Muthu ArulMozhi Perumal (mperumal); [email-masked]
Cc: [email-masked]
Subject: RE: [siprec] Last Call: <draft-ietf-siprec-req-09.txt> (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC

John (as individual)

> 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.
> 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
> 
> **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.

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 15 Apr 2011 02:11:38 +0530

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

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 15 Apr 2011 08:22:48 +0200

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) 

> From: Muthu ArulMozhi Perumal (mperumal) [mailto:[email-masked]] 
> Sent: 14 April 2011 21:42
> To: Ram Mohan R (rmohanr); Leon Portman; Elwell, John; [email-masked]
> Cc: [email-masked]
> <draft-ietf-siprec-req-09.txt>(Use Cases andRequirements for 
> SIP-based MediaRecording (SIPREC)) toInformational RFC
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 14 Apr 2011 22:12:39 +0530

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

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Leon Portman
> Sent: Thursday, April 14, 2011 9:57 PM
> 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
> 
> 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)
> 
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 14 Apr 2011 16:29:18 -0700

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

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Muthu ArulMozhi Perumal
> (mperumal)
> Sent: Thursday, April 14, 2011 1:42 PM
> Subject: Re: [siprec] Last Call:<draft-ietf-siprec-req-09.txt>(Use
Cases andRequirements forSIP-based
> MediaRecording (SIPREC)) toInformational RFC
>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 15 Apr 2011 10:55:30 +0530

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: [email-masked] [mailto:[email-masked]] 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; [email-masked]
Cc: [email-masked]
Subject: Re: [siprec] LastCall:<draft-ietf-siprec-req-09.txt>(Use Cases
andRequirements forSIP-basedMediaRecording (SIPREC)) toInformational RFC

Thanks,
Charles

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 15 Apr 2011 07:55:26 -0700

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

> 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; [email-masked]
> Cc: [email-masked]
> 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?
> 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.
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.
> 
Behalf Of Charles Eckel (eckelcu)
> To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon
Portman; Elwell, John;
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [siprec] LastCall:<draft-ietf-siprec-req-09.txt>(Use
Cases andRequirements forSIP-
> basedMediaRecording (SIPREC)) toInformational RFC
> 
which may be received by the
> SRS from one or more SRCs. Is this not a requirement?
> 
> Thanks,
> Charles
>

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 21 Apr 2011 17:14:43 +0530

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

---

From: Leon Portman <[email-masked]>
Date: Thu, 21 Apr 2011 16:54:03 +0300

I agree, we should have dedicated wall clock requirement

Leon

-----Original Message-----
From: Parthasarathi R (partr) [mailto:[email-masked]] 
Sent: Thursday, April 21, 2011 4:51 PM
To: Muthu ArulMozhi Perumal (mperumal); Elwell, John; Ram Mohan R (rmohanr); Leon Portman; [email-masked]
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of Muthu ArulMozhi Perumal (mperumal)
Sent: Thursday, April 21, 2011 5:15 PM
To: Elwell, John; Ram Mohan R (rmohanr); Leon Portman; [email-masked]
Cc: [email-masked]
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

|> 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 --

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 21 Apr 2011 19:20:57 +0530

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Muthu ArulMozhi Perumal (mperumal)
Sent: Thursday, April 21, 2011 5:15 PM
To: Elwell, John; Ram Mohan R (rmohanr); Leon Portman; [email-masked]
Cc: [email-masked]
Subject: Re: [siprec] Last Call:<draft-ietf-siprec-req-09.txt>(Use
CasesandRequirements forSIP-based MediaRecording (SIPREC))
toInformational RFC

+1

Muthu

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 21 Apr 2011 17:44:46 +0200

I like the separated REQ-022 and REQ-xxx. In accordance with previous discussions, I think we need REQ-023 too.

John (as individual)

> Sent: 21 April 2011 14:54
> To: Parthasarathi R (partr); Muthu ArulMozhi Perumal 
> (mperumal); Elwell, John; Ram Mohan R (rmohanr); [email-masked]
> Cc: [email-masked]
> Subject: RE: [siprec] Last 
> Call:<draft-ietf-siprec-req-09.txt>(Use CasesandRequirements 
> forSIP-based MediaRecording (SIPREC)) toInformational RFC
> 
> To: Muthu ArulMozhi Perumal (mperumal); Elwell, John; Ram 
> Mohan R (rmohanr); Leon Portman; [email-masked]
> Cc: [email-masked]
> 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.
> 
> 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 
> 
> REQ-022 The mechanism MUST provide means for facilitating the 
> following either at storage or at playback:

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 21 Apr 2011 21:27:42 +0530

I am fine with separated REQ-022 and REQ-xxx. Though the solution for
REQ-022 and REQ-xxx could be based on the wallclock time, having an
explicit REQ-023 looks fine from a requirements perspective.

Muthu

|-----Original Message-----
|From: Elwell, John [mailto:[email-masked]]
|Sent: Thursday, April 21, 2011 9:15 PM
|To: Leon Portman; Parthasarathi R (partr); Muthu ArulMozhi Perumal
(mperumal); Ram Mohan R (rmohanr);
[email-masked]
|Cc: [email-masked]
|Subject: RE: [siprec] Last
Call:<draft-ietf-siprec-req-09.txt>(UseCasesandRequirements forSIP-based
|MediaRecording (SIPREC)) toInformational RFC
|
|I like the separated REQ-022 and REQ-xxx. In accordance with previous
discussions, I think we need
|REQ-023 too.
|
|John (as individual)
|
|> -----Original Message-----
|> From: Leon Portman [mailto:[email-masked]]
|> Sent: 21 April 2011 14:54
|> To: Parthasarathi R (partr); Muthu ArulMozhi Perumal
|> (mperumal); Elwell, John; Ram Mohan R (rmohanr); [email-masked]
|> Cc: [email-masked]
|> Subject: RE: [siprec] Last
|> Call:<draft-ietf-siprec-req-09.txt>(Use CasesandRequirements
|> forSIP-based MediaRecording (SIPREC)) toInformational RFC
|>
|> I agree, we should have dedicated wall clock requirement
|>
|> Leon
|>
|> -----Original Message-----
|> From: Parthasarathi R (partr) [mailto:[email-masked]]
|> Sent: Thursday, April 21, 2011 4:51 PM
|> To: Muthu ArulMozhi Perumal (mperumal); Elwell, John; Ram
|> Mohan R (rmohanr); Leon Portman; [email-masked]
|> Cc: [email-masked]
|> 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: [email-masked]
|> [mailto:[email-masked]] On Behalf Of Muthu ArulMozhi
|> Perumal (mperumal)
|> Sent: Thursday, April 21, 2011 5:15 PM
|> To: Elwell, John; Ram Mohan R (rmohanr); Leon Portman; [email-masked]
|> Cc: [email-masked]
|> 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:[email-masked]]
|> |Sent: Friday, April 15, 2011 11:53 AM
|> |To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon
|> Portman; [email-masked]
|> |Cc: [email-masked]
|> |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:[email-masked]]
|> |> Sent: 14 April 2011 21:42
|> |> To: Ram Mohan R (rmohanr); Leon Portman; Elwell, John;
|> [email-masked]
|> |> Cc: [email-masked]
|> |> 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);
|> |> [email-masked]
|> |> |Cc: [email-masked]
|> |> |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: [email-masked]
|> [mailto:[email-masked]] On
|> |> |> Behalf Of Leon Portman
|> |> |> Sent: Thursday, April 14, 2011 9:57 PM
|> |> |> To: Elwell, John; Muthu ArulMozhi Perumal (mperumal);
|> [email-masked]
|> |> |> Cc: [email-masked]
|> |> |> 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:[email-masked]]
|> |> |> Sent: Thursday, April 14, 2011 3:58 PM
|> |> |> To: Leon Portman; Muthu ArulMozhi Perumal (mperumal);
|> [email-masked]
|> |> |> Cc: [email-masked]
|> |> |> 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:[email-masked]]
|> |> |> > Sent: 14 April 2011 13:19
|> |> |> > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal);
|> |> [email-masked]
|> |> |> > Cc: [email-masked]
|> |> |> > 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: [email-masked]
|> |> |> > [mailto:[email-masked]] On Behalf Of Elwell, John
|> |> |> > Sent: Thursday, April 14, 2011 1:54 PM
|> |> |> > To: Muthu ArulMozhi Perumal (mperumal); [email-masked]
|> |> |> > Cc: [email-masked]
|> |> |> > 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: [email-masked]
|> |> |> > > [mailto:[email-masked]] On Behalf Of Muthu
|> |> |> > ArulMozhi Perumal
|> |> |> > > (mperumal)
|> |> |> > > Sent: 14 April 2011 07:34
|> |> |> > > To: [email-masked]
|> |> |> > > Cc: [email-masked]
|> |> |> > > 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: [email-masked]
|> [mailto:[email-masked]]
|> |> On
|> |> |> > > Behalf Of The IESG
|> |> |> > > |Sent: Wednesday, April 06, 2011 6:20 PM
|> |> |> > > |To: IETF-Announce
|> |> |> > > |Cc: [email-masked]
|> |> |> > > |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
|> |> |> > > [email-masked] mailing lists by 2011-04-20. Exceptionally,
|> |> |> > > comments may
|> |> |> > > be
|> |> |> > > |sent to [email-masked] 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
|> |> |> > > [email-masked]
|> |> |> > > |https://www.ietf.org/mailman/listinfo/siprec
|> |> |> > > _______________________________________________
|> |> |> > > siprec mailing list
|> |> |> > > [email-masked]
|> |> |> > > https://www.ietf.org/mailman/listinfo/siprec
|> |> |> > >
|> |> |> > _______________________________________________
|> |> |> > siprec mailing list
|> |> |> > [email-masked]
|> |> |> > https://www.ietf.org/mailman/listinfo/siprec
|> |> |> >
|> |> |> _______________________________________________
|> |> |> siprec mailing list
|> |> |> [email-masked]
|> |> |> https://www.ietf.org/mailman/listinfo/siprec
|> |>
|> _______________________________________________
|> siprec mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/siprec
|>