Subject: [siprec] draft-ram-siprec-metadata-format-00 for Review

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Sat, 22 Jan 2011 00:11:52 +0530

Hi all,
 
Paul, Ram and myself have posted the initial Metadata format -00 draft based on Metadata model draft(draft-ram-siprec-metadata). Metadata format introduces new SIPREC metadata specific XML document and links to SDP for media parameters. The draft provides realization of Metadata model.
 
This draft is in initial stage with lot of open item. The basic idea of posting this draft is to get the high level consensus, start the discussion on interim meeting before deep dive into individual items.
 
Thanks
Partha

________________________________

From: IETF I-D Submission Tool [mailto:[email-masked]]
Sent: Fri 1/21/2011 11:55 PM
To: Parthasarathi R (partr)
Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
Subject: New Version Notification for draft-ram-siprec-metadata-format-00 

A new version of I-D, draft-ram-siprec-metadata-format-00.txt has been successfully submitted by Parthasarathi R and posted to the IETF repository.

Filename:        draft-ram-siprec-metadata-format
Revision:        00
Title:           Session Initiation Protocol (SIP) Recording Metadata Format
Creation_date:   2011-01-21
WG ID:           Independent Submission
Number_of_pages: 14

Abstract:
Session recording is a critical requirement in many communications
environments such as call centers and financial trading.  In some of
these environments, all calls must be recorded for regulatory,
compliance, and consumer protection reasons.  Recording of a session
is typically performed by sending a copy of a media stream to a
recording device.  The requirements for which are described in
[I-D.ietf-siprec-req], the architecture for which is described in
[I-D.ietf-siprec-architecture], and the metadata model viewed by
Session Recording Server is described in [I-D.ram-siprec-metadata].
This document focuses on the Recording metadata format which
describes the communication session.

The IETF Secretariat.

---

From: Leon Portman <[email-masked]>
Date: Mon, 24 Jan 2011 12:27:06 +0200

Partha, Hi

Thank you very much for posting. Following my comments:

1.       Do we want also considering supporting light-weight formats like JSON or compressed XML?

2.       4.2.3 SRS does not have any knowledge to generate group id. And it is also supposed to be populated by the sender (SRC)

3.       4.2.11 It should be UTC time stamp, preferably with 10ms resolution

4.       I am still missing how we will report updates: like adding participants or removing media streams. We should support sending only updates tupples and also indication if they were removed
Regards

Leon

From: [email-masked] [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
Sent: Friday, January 21, 2011 8:42 PM
To: [email-masked]
Subject: [siprec] draft-ram-siprec-metadata-format-00 for Review

Hi all,

Thanks
Partha

Abstract:

The IETF Secretariat.

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 24 Jan 2011 17:59:20 +0530

Hi Leon,
 
Thanks for your comments. Please read inline.
 
Thanks
Partha

From: Leon Portman [mailto:[email-masked]] 
Sent: Monday, January 24, 2011 3:57 PM
To: Parthasarathi R (partr); [email-masked]
Subject: RE: draft-ram-siprec-metadata-format-00 for Review

Partha, Hi

1.       Do we want also considering supporting light-weight formats
like JSON or compressed XML? 

<Partha> XML is chosen for exchanging metadata as lot of other SIP
standards like XCON, PIDF uses XML for data exchange and it is widely
deployed in lot of SIP devices. XML has the advantage of better interop
as it is open standard (W3C) and already adopted.

      I'm not sure whether we prefer compressed XML as XML data is not
going to be too huge for SIPREC metadata and also XML provides more
readability. But in case you have some strong reason for exploring
compressed XML, Please let us know.

      I'm hearing about JSON for the first time :-). At the first glance
of web search on"JSON vs XML", I see the argument in the both
directions. I'll explore further in detail to understand pros & cons
between "JSON vs XML".   I'm interested in hearing from others about
their opinion on JSON </Partha>

2.       4.2.3 SRS does not have any knowledge to generate group id. And
it is also supposed to be populated by the sender (SRC) 

<Partha>  I agree with you that SRC should have knowledge about CS
grouping. I have put it as an open issue in sec 4.2.3 as SRC may not be
able to create unique group-id to SRS in case multiple SRC communicates
with SRS and all SRC may create same-id at the particular instances for
different group. Here, SRS may adds the portion of group id to create
uniqueness. In case you foresee that single SRC generates unique-id in
multiple SRC to single SRS topology, SRC will be able to generate the
key. </Partha>

3.       4.2.11 It should be UTC time stamp, preferably with 10ms
resolution 

<Partha>  xs:dateTime is used to represent timestamp which permits UTC
timestamp. </Partha>

4.       I am still missing how we will report updates: like adding
participants or removing media streams. We should support sending only
updates tupples and also indication if they were removed 

<partha> The current idea of XML schema is to pass the complete metadata
details of CS in each RS transaction. SRS will be able deduced the
change by comparing previous instance metadata with current one.  The
complete XML schema is helpful in case of transfer sort of scenario
wherein most of the details like CS, participant,stream changes but it
is sub-optimal incase of call Hold/resume.

      We (authors) discussed for passing the partial data for addition,
updating, deletion. Partial data passing for addition or updating is
straightforward whereas deletion using partial data involves lot of
complexity in the mechanism.  So, we thought of getting the feedback
before including the format in draft and it is mentioned this idea in
Sec 4.2.2 as    

            o  Open Issue: whether Partial update of Metadata XML
document is  required ?

      I'm taking your comment for adding partial update in Metadata XML
document. 

     For passing partial metadata in XML document, each element (stream,
participant, session) which has to be passed indepently has to be
represented as a separate namespace extension.

</partha>

Regards

Leon

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Parthasarathi R (partr)
Sent: Friday, January 21, 2011 8:42 PM
To: [email-masked]
Subject: [siprec] draft-ram-siprec-metadata-format-00 for Review

Hi all,

Paul, Ram and myself have posted the initial Metadata format -00 draft
based on Metadata model draft(draft-ram-siprec-metadata). Metadata
format introduces new SIPREC metadata specific XML document and links to
SDP for media parameters. The draft provides realization of Metadata
model.

This draft is in initial stage with lot of open item. The basic idea of
posting this draft is to get the high level consensus, start the
discussion on interim meeting before deep dive into individual items.

Thanks

Partha

From: IETF I-D Submission Tool [mailto:[email-masked]]
Sent: Fri 1/21/2011 11:55 PM
To: Parthasarathi R (partr)
Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
Subject: New Version Notification for
draft-ram-siprec-metadata-format-00 

A new version of I-D, draft-ram-siprec-metadata-format-00.txt has been
successfully submitted by Parthasarathi R and posted to the IETF
repository.

Filename:        draft-ram-siprec-metadata-format
Revision:        00
Title:           Session Initiation Protocol (SIP) Recording Metadata
Format
Creation_date:   2011-01-21
WG ID:           Independent Submission
Number_of_pages: 14

Abstract:

The IETF Secretariat.

---

From: "Henry Lum" <[email-masked]>
Date: Mon, 24 Jan 2011 13:32:11 -0800

Hi Partha,

This is a good start, and the main concern I have is the declarative
nature of this format. Since metadata is delivered as a stream of
events, so whenever something changes in the CS (ie. added a
participant, or participant muted audio), would the SRC report the
change by providing the entire declaration as a snapshot again? The
problem I see here is the SRS would end up with the responsibility to
figure out the changes made since the last snapshot. It's kind of like
doing a diff against the previous snapshot if the SRS needs to know what
the metadata event is about.

I am wondering if we can using something like the XCON event package
although it's expired, and this is based on RFC5261 which uses XPath to
locate and make changes to the snapshot.

Regards,

Henry

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Parthasarathi R (partr)
Sent: Friday, January 21, 2011 1:42 PM
To: [email-masked]
Subject: [siprec] draft-ram-siprec-metadata-format-00 for Review

Hi all,

Thanks

Partha

Abstract:

The IETF Secretariat.

-------------------------------------------------------------------------------------------------------------------
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: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 25 Jan 2011 11:18:26 +0530

Hi Henry,
 
Thanks for your comment. I agree with you for partial metadata exchange.
I'll update -01 version with partial notification of data.
 
Thanks
Partha

From: Henry Lum [mailto:[email-masked]] 
Sent: Tuesday, January 25, 2011 3:02 AM
To: Parthasarathi R (partr); [email-masked]
Subject: RE: [siprec] draft-ram-siprec-metadata-format-00 for Review

Hi Partha,

Regards,

Henry

Hi all,

Thanks

Partha

Abstract:

The IETF Secretariat.

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.