Subject: Re: [siprec] Thoughts on draft-ram-siprec-metadata-00

From: "Henry Lum" <[email-masked]>
Date: Wed, 1 Sep 2010 14:38:15 -0700

I have a few comments:

- We should mention that the model only provides a snapshot view.
Participants and media streams can change during runtime and SRS will
need to capture changes to the communication session provided by the
SRC, for example, if the call is transferred.

- I am having a bit of trouble understanding why we need to define a
recording session group. Grouping the RSes inherently means there is a
collection of CSes as well. I am hoping that we keep the grouping of
related CSes out of the current scope to keep things minimal and let the
SRS figure out related CSes using its own mechanism.

- section 4.4 - to model the pause/resume requirement, do we need some
attributes in the recorded media stream to provide the timestamps of the
pause/resume? The implementation is probably going to be using
a=inactive in the SDP, but the SRS will need to persist this piece of
information as metadata.

- section 5.2 - I am okay with having exactly one RS per CS at the note
suggests. I have commented before that there will be a need for a
decomposed model to convey metadata outside of the recording session
dialog so we are not strictly tied to a single recording session to
convey metadata to SRS (this is mentioned in section 3).

Regards,
Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Leon Portman
> Sent: Friday, August 27, 2010 12:41 PM
> To: Paul Kyzivat
> Cc: [email-masked]
> Subject: Re: [siprec] Thoughts on draft-ram-siprec-metadata-00
> 
> Yes, I agree as well regarding RS metadata. However, there are some
> exceptions for that. For example, if SRC is mixing some medias
together
> and reports the mix via RS metadata, then off course this info will be
> stored and used by SRS.
> 
> Leon
> 
> Sent from my iPad
> 
> On Aug 27, 2010, at 4:41 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> >
> >
> > Elwell, John wrote:
> >> (as chair)
> >> Thanks to the authors for posting this, following Paul's
> presentation in Maastricht and consensus in the room that people would
> like to see a separate draft on this.
> >> (as individual)
> >> This seems to be a good first pass at identifying the data objects
> involved in the subject of session recording. I am not sure that it
all
> should be considered as "metadata". In my opinion, metadata is
> information the SRS needs to accompany recorded media.
> >
> >
> >> In particular, anything to do with the Recording Session (RS) is
> just a temporary artefact of the SIPREC delivery mechanism, and
doesn't
> need to be retained as metadata. For example, whether a single RS is
> used to record one CS or several CSs is irrelevant after the event. So
> I think the Recording Session Group and Recording Session objects are
> not part of metadata.
> >
> > This is a good discussion to have.
> >
> > I don't have an opinion one way or the other on the specific piece
of
> info that John is calling out. I can imagine somebody would indeed
like
> to have that information about the recording session (for tracability
> or whatever.) Others might consider it irrelevant.
> >
> > I'm happy to go either way on that.
> >
> > The piece that I think is least likely to be needed long term, but
> which is needed by the SRS short term, is the address and port on the
> SRS at which it is receiving a particular media stream. I think it
very
> unlikely that anyone will find that important to keep in the
historical
> record. That at least establishes the point that we probably need to
> distinguish between that which is needed transiently and that which is
> needed permanently. So maybe we need a documentation convention for
> that.
> >
> > 	Thanks,
> > 	Paul
> > _______________________________________________
> > siprec mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/siprec
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

-------------------------------------------------------------------------------------------------------------------
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: Wed, 01 Sep 2010 18:23:29 -0400

Henry,

Thanks for input. Responses inline.

	Paul

> SRC, for example, if the call is transferred.

It wasn't my intent that it be a snapshot. My intent was that it capture 
any changes that occur over the duration of the RS. If you don't get 
that out of it then we need to figure out why.

> SRS figure out related CSes using its own mechanism.

I just through it in because I thought I was hearing people talk about 
cases where multiple RSs pertain to the same CS and needed to be tied 
together. I'd be happy to see it gone if it isn't needed. Even if 
*something* is needed its probably not right.

The RS by itself can be a collection of CSs. That was intentional. It 
does depend a bit on (still fuzzy) definition of CS. Certainly if you 
have a persistent recording session then you will see that. But I think 
you might also get it for a private consultation call by an agent that 
has a customer call.

> a=inactive in the SDP, but the SRS will need to persist this piece of

That *could* be handled by multiple instances of Recorded Media Stream, 
one for each active period, with none during the paused period.

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 2 Sep 2010 07:51:16 -0700

I meant the model does not only provide a snapshot view :)

Can we add the following text at the end of section 3 to clarify the
intent:

Note that the metadata model captures changes that occur over the
duration of the recording session. For example, if the call is
transferred from one participant to another, then the SRC MUST convey a
change of participant and received media stream in the communication
session. The timing of changes is not explicitly defined in the metadata
model, since the mechanism (yet to be defined) which conveys the
metadata will implicitly provide the timing of changes over the duration
of the recording session. It is up to the implementation of the SRS to
capture the actual timing of the changes.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 Sep 2010 11:53:43 -0400

Henry,

I agree with your intent, but quibble with the details.

Specifically, the Received Media Stream has a start and end time.
So a change in participants would end up being timestamped.

The model doesn't say whether the times are explicitly sent by the src 
to srs, or if the srs just captures them from the clock at the time the 
change happens. An possible alternative wording below:

session.

Some of the data in the model may not be conveyed explicitly from the 
SRC to the SRS, if it can be obtained contextually by the SRS. For 
instance, the timing of changes may not explicitly conveyed from the SRC 
to the SRC, because the mechanism (yet to be defined) which conveys the 
metadata may implicitly provide the timing. (E.g. the time a change 
occurred by be assumed to be the same as the time when notification of 
the change is received by the SRS.)

Which data is conveyed explicitly, and which is conveyed implicitly, 
will be determined when selecting a transport mechanism for the data.

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 2 Sep 2010 09:00:04 -0700

Thanks Paul. I like the revised wording.

Henry

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, September 02, 2010 11:54 AM
> To: Henry Lum
> Cc: Leon Portman; [email-masked]
> > transferred from one participant to another, then the SRC MUST
convey
> a

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 3 Sep 2010 12:57:08 +0200

Yes, this addition seems useful.

John (as individual) 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Henry Lum
> Sent: 02 September 2010 17:00
> To: Paul Kyzivat
> Cc: [email-masked]
> > > of the recording session. It is up to the implementation 
> of the SRS
> > to
> > transferred from one participant to another, then the SRC 
> MUST convey
> a
> --------------------------------------------------------------
> -----------------------------------------------------
> 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: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 3 Sep 2010 17:19:05 +0530

Thanks folks for your comments.
We will include the below text in the revised version of the draft

<snip>

</snip>

Thanks,
Ram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
Sent: Friday, September 03, 2010 4:27 PM
To: Henry Lum; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Re: [siprec] Thoughts on draft-ram-siprec-metadata-00

John (as individual)