Subject: Re: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call

From: "Henry Lum" <[email-masked]>
Date: Wed, 27 Apr 2011 13:15:53 -0700

I am trying to see if we can more explicit about relating wall clock
time with recording controls such as pause/resume:

REQ-024: The mechanism MUST provide means to relate recording and
recording controls such as start/stop/pause/resume to the wall clock
time.

Henry

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Leon Portman
Sent: April-27-11 9:30 AM
To: [email-masked]; Ken Rehor (krehor)([email-masked]); Elwell, John
Subject: [siprec] Summary of the changes of draft-ietf-siprec-req-10 -
last call

Hello

Please see below summary of the changes for  updated version of the
requirements document.

Main changes:

1.       Updated REQ-022, 023, 024 (all other numbers are ++, original
22 and 23 removed), thanks to Muthu and John for the text

a.       REQ-022: The mechanism MUST provide means for facilitating
synchronization of the recorded media streams and metadata.

b.      REQ-023: The mechanism MUST provide means for facilitating
synchronization among the recorded media streams.

c.       REQ-024: The mechanism MUST provide means for relating
recordings to wall clock time.

2. Use Case 8 - nit pick, thanks to Muthu (me -> may be)

a."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) may be deployed."

                3. Proposed additional paragraph in the security section
from the security review (not in the text yet, pending WG approval):

"Integrity and correctness of the recorded sessions is not ensured by
cryptographic means to ensure that the CS has not been tampered with.
This would have to be done by organizational and technical controls that
prevent tampering with CS participants and SRC."

Regards

Leon

					
-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

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

OK for me.

John

________________________________
From: Henry Lum [mailto:[email-masked]]
Sent: 27 April 2011 21:16
To: Leon Portman; [email-masked]; [email-masked]; Elwell, John
Subject: RE: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call

I am trying to see if we can more explicit about relating wall clock time with recording controls such as pause/resume:

REQ-024: The mechanism MUST provide means to relate recording and recording controls such as start/stop/pause/resume to the wall clock time.

Henry

From: [email-masked] [mailto:[email-masked]] On Behalf Of Leon Portman
Sent: April-27-11 9:30 AM
To: [email-masked]; Ken Rehor (krehor)([email-masked]); Elwell, John
Subject: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call

Hello

Please see below summary of the changes for  updated version of the requirements document.

Main changes:

1.       Updated REQ-022, 023, 024 (all other numbers are ++, original 22 and 23 removed), thanks to Muthu and John for the text

a.       REQ-022: The mechanism MUST provide means for facilitating synchronization of the recorded media streams and metadata.

b.      REQ-023: The mechanism MUST provide means for facilitating synchronization among the recorded media streams.

c.       REQ-024: The mechanism MUST provide means for relating recordings to wall clock time.

a."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) may be deployed."

                3. Proposed additional paragraph in the security section from the security review (not in the text yet, pending WG approval):

"Integrity and correctness of the recorded sessions is not ensured by cryptographic means to ensure that the CS has not been tampered with. This would have to be done by organizational and technical controls that prevent tampering with CS participants and SRC."

Regards

Leon

---

From: Leon Portman <[email-masked]>
Date: Thu, 28 Apr 2011 09:58:37 +0300

+1

Leon

From: Elwell, John [mailto:[email-masked]]
Sent: Thursday, April 28, 2011 9:24 AM
To: Henry Lum; Leon Portman; [email-masked]; [email-masked]
Subject: RE: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call

OK for me.

John

Henry

Hello

Main changes:

Regards

Leon

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 28 Apr 2011 12:36:21 +0530

I'm also fine with Henry proposed requirement. 
 
I'm curious to know from SIPREC solution point of view whether REQ-024
requirement calls for Network Time protocol (NTP) or similar protocol
mechanism between SRC and SRS.
 
Thanks
Partha

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
Sent: Thursday, April 28, 2011 11:54 AM
To: Henry Lum; Leon Portman; [email-masked]; Ken Rehor (krehor)
Subject: Re: [siprec] Summary of the changes of draft-ietf-siprec-req-10
- last call

OK for me.
 
John

	From: Henry Lum [mailto:[email-masked]] 
	Sent: 27 April 2011 21:16
	To: Leon Portman; [email-masked]; [email-masked]; Elwell,
John
	Subject: RE: [siprec] Summary of the changes of
draft-ietf-siprec-req-10 - last call

	I am trying to see if we can more explicit about relating wall
clock time with recording controls such as pause/resume:

	REQ-024: The mechanism MUST provide means to relate recording
and recording controls such as start/stop/pause/resume to the wall clock
time.

	Henry

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Leon Portman
	Sent: April-27-11 9:30 AM
	To: [email-masked]; Ken Rehor (krehor)([email-masked]);
Elwell, John
	Subject: [siprec] Summary of the changes of
draft-ietf-siprec-req-10 - last call

	Hello

	Please see below summary of the changes for  updated version of
the requirements document.

	Main changes:

	1.       Updated REQ-022, 023, 024 (all other numbers are ++,
original 22 and 23 removed), thanks to Muthu and John for the text

	a.       REQ-022: The mechanism MUST provide means for
facilitating synchronization of the recorded media streams and metadata.

	b.      REQ-023: The mechanism MUST provide means for
facilitating synchronization among the recorded media streams.

	a."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) may be deployed."

	                3. Proposed additional paragraph in the security
section from the security review (not in the text yet, pending WG
approval):

	"Integrity and correctness of the recorded sessions is not
ensured by cryptographic means to ensure that the CS has not been
tampered with. This would have to be done by organizational and
technical controls that prevent tampering with CS participants and SRC."

	Regards

	Leon

	 

	CONFIDENTIALITY NOTICE: This e-mail and any files attached may
contain confidential and proprietary information of Alcatel-Lucent
and/or its affiliated entities. Access by the intended recipient only is
authorized. Any liability arising from any party acting, or refraining
from acting, on any information contained in this e-mail is hereby
excluded. If you are not the intended recipient, please notify the
sender immediately, destroy the original transmission and its
attachments and do not disclose the contents to any other person, use it
for any purpose, or store or copy the information in any medium.
Copyright in this e-mail and any attachments belongs to Alcatel-Lucent
and/or its affiliated entities.

---

From: Leon Portman <[email-masked]>
Date: Thu, 28 Apr 2011 10:43:04 +0300

My opinion that we should not require or relay on NTP. It will also not help us will network latency or in delays with sending and processing metadata and rtp packets. This is why we should explicitly send wall clock between SRC and SRS. And SRC should be "the master" clock. SRS time is not important.

Regards

Leon

From: Parthasarathi R (partr) [mailto:[email-masked]]
Sent: Thursday, April 28, 2011 10:06 AM
To: Elwell, John; Henry Lum; Leon Portman; [email-masked]; Ken Rehor (krehor)
Subject: RE: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call

I'm curious to know from SIPREC solution point of view whether REQ-024 requirement calls for Network Time protocol (NTP) or similar protocol mechanism between SRC and SRS.

Thanks
Partha

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Thursday, April 28, 2011 11:54 AM
To: Henry Lum; Leon Portman; [email-masked]; Ken Rehor (krehor)
Subject: Re: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call
OK for me.

John

Henry

Hello

Main changes:

Regards

Leon

---

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

Looks Ok for me.

Regards,

Ram

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henry Lum
Sent: Thursday, April 28, 2011 1:46 AM
To: Leon Portman; [email-masked]; Ken Rehor (krehor); Elwell, John
Subject: Re: [siprec] Summary of the changes of draft-ietf-siprec-req-10
-last call

Henry

Hello

Main changes:

Regards

Leon

 

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
confidential and proprietary information of Alcatel-Lucent and/or its
affiliated entities. Access by the intended recipient only is
authorized. Any liability arising from any party acting, or refraining
from acting, on any information contained in this e-mail is hereby
excluded. If you are not the intended recipient, please notify the
sender immediately, destroy the original transmission and its
attachments and do not disclose the contents to any other person, use it
for any purpose, or store or copy the information in any medium.
Copyright in this e-mail and any attachments belongs to Alcatel-Lucent
and/or its affiliated entities.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Apr 2011 08:49:42 -0400

On 4/28/2011 3:43 AM, Leon Portman wrote:
> My opinion that we should not require or relay on NTP. It will also not
> help us will network latency or in delays with sending and processing
> metadata and rtp packets. This is why we should explicitly send wall
> clock between SRC and SRS. And SRC should be "the master" clock. SRS
> time is not important.

I'm ok with that. But it doesn't address coordination of the metadata 
timing with the media timing.

It may not need to be normative but *somewhere* I would like to see a 
description of a plausible algorithm for aligning the media to the SRC 
wall clock time. (I'm just looking for an existence proof that there is 
sufficient information to do the job.) Perhaps it is as simple as:

- the SRS tags received media packets with the time of reception
   using its own clock
- when the SRS receives metadata, it uses the SRC time from the message
   to compute a delta between SRS time and SRC time
- the SRS then uses that delta to adjust the timestamps for the
   referenced media

(The above is at least incomplete - it raises a number of issues.)

	Thanks,
	Paul

> Regards
>
> Leon
>
> *From:*Parthasarathi R (partr) [mailto:[email-masked]]
> *Sent:* Thursday, April 28, 2011 10:06 AM
> *To:* Elwell, John; Henry Lum; Leon Portman; [email-masked]; Ken Rehor
> (krehor)
> *Subject:* RE: [siprec] Summary of the changes of
> ------------------------------------------------------------------------
>
> *From:[email-masked] [mailto:[email-masked]] *On
> Behalf Of *Elwell, John
> *Sent:* Thursday, April 28, 2011 11:54 AM
> *To:* Henry Lum; Leon Portman; [email-masked]; Ken Rehor (krehor)
> *Subject:* Re: [siprec] Summary of the changes of
>     ------------------------------------------------------------------------
>
>     *From:*Henry Lum [mailto:[email-masked]]
>     *Sent:* 27 April 2011 21:16
>     *To:* Leon Portman; [email-masked]; [email-masked]; Elwell, John
>     *Subject:* RE: [siprec] Summary of the changes of
>     *From:[email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Leon Portman
>     *Sent:* April-27-11 9:30 AM
>     *To:* [email-masked]; Ken Rehor (krehor)([email-masked]); Elwell,
>     John
>     *Subject:* [siprec] Summary of the changes of
>     1.Updated REQ-022, 023, 024 (all other numbers are ++, original 22
>     and 23 removed), thanks to Muthu and John for the text
>
>     a.REQ-022: The mechanism MUST provide means for facilitating
>     b.REQ-023: The mechanism MUST provide means for facilitating
>     c.REQ-024: The mechanism MUST provide means for relating recordings
>     to wall clock time.
>
>     2. Use Case 8 – nit pick, thanks to Muthu (me -> may be)
>
>     a."In cases where calls inside or between branches must be recorded,
>     a centralized recording system in data centers together with
>     3. Proposed additional paragraph in the security section from the
>     security review (not in the text yet, pending WG approval):
>
>     "Integrity and correctness of the recorded sessions is not ensured
>     by cryptographic means to ensure that the CS has not been tampered
>     with. This would have to be done by organizational and technical
>     controls that prevent tampering with CS participants and SRC."
>
>     Regards
>
>     Leon
>
>
>     and/or its affiliated entities. Access by the intended recipient
>     only is authorized. Any liability arising from any party acting, or
>     refraining from acting, on any information contained in this e-mail
>     is hereby excluded. If you are not the intended recipient, please
>     notify the sender immediately, destroy the original transmission and
>     its attachments and do not disclose the contents to any other
>     person, use it for any purpose, or store or copy the information in
>     any medium. Copyright in this e-mail and any attachments belongs to
>     Alcatel-Lucent and/or its affiliated entities.
>
>
>
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: Leon Portman <[email-masked]>
Date: Thu, 28 Apr 2011 15:57:08 +0300

Paul Hi

Yes, it can be used like that except that time difference information probably will be used during the playback - to align played media with metadata events.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Thursday, April 28, 2011 3:50 PM
To: [email-masked]
Subject: Re: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call

On 4/28/2011 3:43 AM, Leon Portman wrote:
> My opinion that we should not require or relay on NTP. It will also 
> not help us will network latency or in delays with sending and 
> processing metadata and rtp packets. This is why we should explicitly 
> send wall clock between SRC and SRS. And SRC should be "the master" 
> clock. SRS time is not important.

I'm ok with that. But it doesn't address coordination of the metadata timing with the media timing.

It may not need to be normative but *somewhere* I would like to see a description of a plausible algorithm for aligning the media to the SRC wall clock time. (I'm just looking for an existence proof that there is sufficient information to do the job.) Perhaps it is as simple as:

	Thanks,
	Paul