Subject: [siprec] comments on draft-ram-siprec-metadata-04

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sat, 26 Mar 2011 12:04:42 -0700

I gave the draft and read and have the following comments.

Section 3. Think the metadata describes the recording session, not the
communication session. Replace "metamodel" with "metadata model", and
"MAY be conveyed in Recording Session" with "MAY be conveyed within the
Recording Session", and "time a change occurred by be assumed" with
"time a change occurred may be assumed".

Section 4, suggest rewording as, "The section describes each element of
the metadata model, and the attributes of each element. This section
also describes how the different elements are associated."

Section 4.1, RecordingRequestorID is not really an ID, it is more of a
type. I think RecordingRequestor is more appropriate. That said, I think
you also need a unique ID for the Recording Session, right?

Section 4.2.1, replace "SRC (or MAY be SRS)" with "SRC or SRS".

Section 4.3.2, why does a CS need two participants or more? What about
studio mode recording?

Section 4.4.1, what is participant type and what is its use, or why
needed?

Section 4.5, I think Media Stream requires a unique ID attribute as
well. Is the "Media Stream Reference" the SDP label attribute?

Thanks,
Charles

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 29 Mar 2011 14:00:30 +0530

Charles,

Thanks for review the document. Please read inline.

Thanks
Partha 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Charles Eckel (eckelcu)
Sent: Sunday, March 27, 2011 12:35 AM
To: [email-masked]
Subject: [siprec] comments on draft-ram-siprec-metadata-04

Section 4.1, RecordingRequestorID is not really an ID, it is more of a
type. I think RecordingRequestor is more appropriate.

<Partha>Agreed. We will update in the next revision </partha>

 That said, I think you also need a unique ID for the Recording Session,
right?
<partha>  Please clarify whether you are interested in AOR of RS or just
ID. In the model, Recording (1..*) is related to CSG (0..*) and there is
no need of separate attribute for unique id. In the metadata format, URN
UUID in CSG (group) & recording exist which helps to visualize the
association </partha>

Section 4.2.1, replace "SRC (or MAY be SRS)" with "SRC or SRS".
<Partha>Agreed. We will update in the next revision </partha>

Section 4.4.1, what is participant type and what is its use, or why
needed?
<partha> This attribute has to be removed as per the last interim
meeting. We will update in the next revision. </partha>

Section 4.5, I think Media Stream requires a unique ID attribute as
well. 
<partha> As mentioned above in the model draft, the association between
CS and participant is shown. In terms of format draft, it is represented
by URN UUID </partha>
Is the "Media Stream Reference" the SDP label attribute?
<partha> Your understanding is correct </partha>

Thanks,
Charles

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

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 29 Mar 2011 07:37:55 -0700

Hi Partha,

Thanks for your response. This addresses all of my concerns. Please see
one additional clarification inline. 

> From: Parthasarathi R (partr)
> Sent: Tuesday, March 29, 2011 10:31 AM
> To: Charles Eckel (eckelcu); [email-masked]
> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04
> 
> Charles,
> 
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Charles Eckel (eckelcu)
> Section 3. Think the metadata describes the recording session, not the
communication session. Replace
> "metamodel" with "metadata model", and "MAY be conveyed in Recording
Session" with "MAY be conveyed
> within the Recording Session", and "time a change occurred by be
assumed" with "time a change occurred
> may be assumed".
> 
> Section 4, suggest rewording as, "The section describes each element
of the metadata model, and the
> attributes of each element. This section also describes how the
different elements are associated."
> Section 4.1, RecordingRequestorID is not really an ID, it is more of a
type. I think
> RecordingRequestor is more appropriate.
> 
> 
>  That said, I think you also need a unique ID for the Recording
Session, right?
> <partha>  Please clarify whether you are interested in AOR of RS or
just ID. In the model, Recording
> (1..*) is related to CSG (0..*) and there is no need of separate
attribute for unique id. In the
> metadata format, URN UUID in CSG (group) & recording exist which helps
to visualize the association
> </partha>

I am assuming there is a need to distinguish one RS from another RS, and
that is the reason I was recommending adding a unique ID. This ID would
not be the RS AOR as that may not be unique.

Cheers,
Charles

studio mode recording?
needed?
> <partha> This attribute has to be removed as per the last interim
meeting. We will update in the next
> revision. </partha>
well.
> <partha> As mentioned above in the model draft, the association
between CS and participant is shown.
> In terms of format draft, it is represented by URN UUID </partha>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 30 Mar 2011 11:00:38 +0200

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
> Sent: 29 March 2011 15:38
> To: Parthasarathi R (partr); [email-masked]
> Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04
> 
> Hi Partha,
> 
[JRE] I am not sure exactly what text Charles was commenting on, but in my opinion metadata describes a CS (and how media streams in the RS relate to that CS), rather than describing the RS.

John (as individual)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 30 Mar 2011 16:50:27 +0530

Charles,

Please read inline

Thanks
Partha 

-----Original Message-----
From: Charles Eckel (eckelcu) 
Sent: Tuesday, March 29, 2011 8:08 PM
To: Parthasarathi R (partr); [email-masked]'
Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04

Hi Partha,

> "MAY be conveyed in Recording Session" with "MAY be conveyed within 
> the Recording Session", and "time a change occurred by be assumed"
with "time a change occurred may be assumed".
> of the metadata model, and the attributes of each element. This
section also describes how the different elements are associated."

Session, right?
> attribute for unique id. In the metadata format, URN UUID in CSG 
> (group) & recording exist which helps to visualize the association 
> </partha>

I am assuming there is a need to distinguish one RS from another RS, and
that is the reason I was recommending adding a unique ID. 

<Partha> The next revision will be updated with "unique ID" attribute in
the recording session block.

In the metadata format, each recording element is uniquely identified by
having URN UUID recording attribute. </Partha> 

This ID would not be the RS AOR as that may not be unique.

Cheers,
Charles

studio mode recording?
needed?
well.
> In terms of format draft, it is represented by URN UUID </partha> Is 
> the "Media Stream Reference" the SDP label attribute?

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 31 Mar 2011 09:10:30 -0700

Hi John,

Please see inline.

> From: Elwell, John [mailto:[email-masked]]
> Sent: Wednesday, March 30, 2011 11:01 AM
> To: Charles Eckel (eckelcu); Parthasarathi R (partr); [email-masked]
> [JRE] I am not sure exactly what text Charles was commenting on, but
in my opinion metadata describes
> a CS (and how media streams in the RS relate to that CS), rather than
describing the RS.
> John (as individual)

The metadata model is anchored by an element for the RS. This recording
session contains 0 or more CS group each with 1 or more CS. This is what
led to my comment that the metadata model describes an RS rather than a
CS.

Cheers,
Charles

> > This ID would

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 31 Mar 2011 18:29:39 +0200

Charles,

OK, I see how you got there, but really it describes the CSs (and CS groups) that are being carried in the RS. Any ideas how better to word it?

John 

> From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
> Sent: 31 March 2011 17:11
> To: Elwell, John; Parthasarathi R (partr); [email-masked]

---

From: Scott Orton <[email-masked]>
Date: Thu, 31 Mar 2011 09:43:15 -0700

John, Charles, Partha,
   I have a question. What is the purpose of the CS Group? I do not see it adding anything to the metadata. To me it seems that the whole purpose of the metadata is to describe the recording session to the SRS. Looking at the requirements I see 3 relationships that the spec is attempting to describe: 

A one to one relationship - one communication session to one recording session
A one to many relationship - one communication session with multiple Recording sessions
                           - one Recording session made up of multiple communications sessions

The current metadata format allows all of these and I do not see what the group is adding.

Regards,
    Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Thursday, March 31, 2011 11:30 AM
To: Charles Eckel (eckelcu); Parthasarathi R (partr); [email-masked]
Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04

Charles,

John

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 31 Mar 2011 18:49:59 +0200

Scott,

Some folks wanted to be able to group related CSs together (e.g., a CS between a customer and an agent and a second CS resulting from the customer being transferred to a second agent). I will leave it to those folks to add to this.

John (chair hat on)

> From: Scott Orton [mailto:[email-masked]] 
> Sent: 31 March 2011 17:43
> To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R 
> (partr); [email-masked]
>    I have a question. What is the purpose of the CS Group? I 
> do not see it adding anything to the metadata. To me it seems 
> that the whole purpose of the metadata is to describe the 
> recording session to the SRS. Looking at the requirements I 
> see 3 relationships that the spec is attempting to describe: 
> 
> [mailto:[email-masked]] On Behalf Of Elwell, John
> OK, I see how you got there, but really it describes the CSs 
> (and CS groups) that are being carried in the RS. Any ideas 
> how better to word it?
> 
> John 
> 
> > > > > <partha>  Please clarify whether you are interested 
> in AOR of RS
> > or
> > > > > Section 4.4.1, what is participant type and what is 
> its use, or
> > why
> > > > needed?
> > > > > Section 4.5, I think Media Stream requires a unique 
> ID attribute
> > as
> > > > well.

---

From: Scott Orton <[email-masked]>
Date: Thu, 31 Mar 2011 11:47:59 -0700

John,
    Thanks for the information.

   In that case I would like to see the CS group be made optional. Rather than the CS pointing to the CS Group, I would like to suggest that the CS point to the RS and have the CS group stand alone where it would just have its own ID and then a list of CS ids that belong to the group.

Scott

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Thursday, March 31, 2011 11:50 AM
To: Scott Orton; Charles Eckel (eckelcu); Parthasarathi R (partr); [email-masked]
Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04

Scott,

John (chair hat on)