Subject: Re: [siprec] RS to CS relationship as an attribute inRecording block

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 2 May 2011 06:33:46 -0700

Hi John,

Having a recording exist outside of the RS provides, among other things,
a way for a SRC to establish a new RS to continue a recording in the
event something goes wrong with initial RS. It also facilitates having
multiple SRCs participate in the same recording, which we agreed was out
of scope, but is at least possible if a recording exists outside of an
RS.
I suppose the argument could be made this is not really necessary.
Rather, one could, outside of the scope of SIPREC, decide to associate
multiple RSs in various ways, including stitching them together for the
purpose of failover or distributed recordings. Is that what you have in
mind?

Cheers,
Charles

> -----Original Message-----
> From: Elwell, John [mailto:[email-masked]]
> Sent: Saturday, April 30, 2011 3:12 AM
> To: Paul Kyzivat (pkyzivat); Charles Eckel (eckelcu)
> Cc: Parthasarathi R (partr); [email-masked]
> Subject: RE: [siprec] RS to CS relationship as an attribute
inRecording block
> 
> I am confused, because this thread has suddenly started to talk about
a "recording", whereas metadata-
> 00 has an object called "Recording Session", which seems to imply it
has a 1:1 relationship with the
> SIP dialog for the RS. If people have a notion of a recording object
that does not have a 1:1
> relationship with an RS, and therefore a single SIP dialog, I would
suggest they articulate why this
> would be needed, with a view to getting it into the metadata model.
> 
> John
> 
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:[email-masked]]
> > Sent: 30 April 2011 01:38
> > To: Charles Eckel (eckelcu)
> > Cc: Parthasarathi R (partr); Elwell, John; [email-masked]
> > Subject: Re: [siprec] RS to CS relationship as an attribute
> > inRecording block
> >
> >
> >
> > On 4/29/2011 11:47 AM, Charles Eckel (eckelcu) wrote:
> > > Hi Partha,
> > >
> > > Use of the RS dialog-id seems ok to me. However, if I
> > understood John's
> > > point, he was suggesting a unique id within the metadata to
> > identify the
> > > RS is not required. This is different than requiring a unique ID
to
> > > identify the recording. I think the unique ID for the
> > recording should
> > > not be required to be the RS dialog-id. Doing so would
> > preclude things
> > > such as having the SRC re-establish a new RS the SRS for
> > the purpose of
> > > continuing a recording.
> >
> > Yes, I agree.
> >
> > A "recording" is really just all the data and metadata
> > accumulated about
> > a CS or CSG. That data has been received through one *or
> > more* RSs. Each
> > RS has some metadata of its own (such as who the SRC was.)
> >
> > To track that, when the SRS receives message from the SRC, it should
> > associate each independent hunk of metadata in that message with its
> > info about the RS.
> >
> > Then for example, the elements in the time series of updates
> > to each CS,
> > MS, etc. will each link to the RS that delivered it.
> >
> > An SRS that wanted to be lazy might not bother to keep all that.
> >
> > 	Thanks,
> > 	Paul
> >
> > > Regarding use of the Date header, one problem is that Date
> > is optional,
> > > so you would need SIPREC to make it mandatory for SRC and
> > SRS, else they
> > > may not include it.
> >
> > True. I guess we could either make its use mandatory with siprec, or
> > else convey the data separately in the metadata.
> >
> > 	Thanks,
> > 	Paul
> >
> > > Cheers,
> > > Charles
> > >
> > >> -----Original Message-----
> > >> From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of Parthasarathi R (partr)
> > >> Sent: Thursday, April 28, 2011 11:24 PM
> > >> To: Paul Kyzivat (pkyzivat); Elwell, John
> > >> Cc: [email-masked]
> > >> Subject: Re: [siprec] RS to CS relationship as an attribute
> > > inRecording block
> > >>
> > >> John,
> > >>
> > >> Please clarify whether you propose to use RS dialog id as
> > "recording"
> > >> element unique id for the session. I had the same impression and
> > >> mentioned at
> > >>
http://www.ietf.org/mail-archive/web/siprec/current/msg01751.html.
> > > From
> > >> the metadata XML format perspective, "recording" element unique
id
> > > will
> > >> be defined by its application which is nothing but SIP (RS
> > dialog-id).
> > >> "recording" Unique-id is created after the dialog is
> > established with
> > >> SRS for "to-tag" portion of dialog-id. Even in case multiple SRC
to
> > >> single SRS, RS dialog-id is unique.
> > >> "recording" element does not require any id in Metadata XML
because
> > > only
> > >> one instance of "recording" element per RS.
> > >>
> > >> In the same line, Please let me know your opinion of "recording"
> > > element
> > >> start/stop time which shall be derived from "Date" header
> > in INVITE&
> > >> BYE of RS SIP dialog.  The intention is to use some of the
metadata
> > >> information from RS dialog rather than duplicating in XML.
> > >>
> > >> Having said that, I understand Paul point of view for
> > having URN UUID
> > >> within XML scope. There is no dependency on current URN
> > UUID from SRS
> > >> side.
> > >>
> > >> Thanks
> > >> Partha
> > >>
> > >> -----Original Message-----
> > >> From: [email-masked] [mailto:[email-masked]] On
> > > Behalf
> > >> Of Paul Kyzivat (pkyzivat)
> > >> Sent: Wednesday, April 27, 2011 7:28 PM
> > >> To: Elwell, John
> > >> Cc: [email-masked]
> > >> Subject: Re: [siprec] RS to CS relationship as an attribute
> > > inRecording
> > >> block
> > >>
> > >>
> > >>
> > >> On 4/27/2011 4:00 AM, Elwell, John wrote:
> > >>> I agree with Paul.
> > >>>
> > >>> Also, it is not at all clear to me why we need any unique
> > >> identification for the RS - doesn't the SIP dialog
> > identifier achieve
> > >> this? The RS is only a vehicle for delivering one or more
> > recordings
> > >> (media and metadata) to the SRS, and once the delivered
> > information is
> > >> stored for future playback, the delivery mechanism, i.e., the RS
> > >> identity, is no longer relevant.
> > >>
> > >> I don't think we *need* explicit metadata for the RS.
> > >> But I think the SRS will want to keep track of where it got the
> > > various
> > >> pieces of data and metadata it receives and records. It
> > could capture
> > >> basic info from the SIP dialog for that purpose. But it might be
> > > useful
> > >> for the SRC to be able to transmit additional data about itself
and
> > > its
> > >> reason for establishing the RS. Perhaps that is all
> > "extension data",
> > >> but I think its useful to have some mechanism in place to
> > transmit it.
> > >>
> > >> 	Thanks,
> > >> 	Paul
> > >>
> > >>> However, I have a feeling we have been round this loop before,
so
> > >> apologies if we came to a resolution.
> > >>>
> > >>> John (as individual)
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: [email-masked]
> > >>>> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> > >>>> Sent: 25 April 2011 15:57
> > >>>> To: [email-masked]
> > >>>> Subject: Re: [siprec] RS to CS relationship as an attribute in
> > >>>> Recording block
> > >>>>
> > >>>> Given all the combinations you cite, I'm inclined to
> > simply plan to
> > >>>> accommodate many RS to many CS in all cases.
> > >>>>
> > >>>> Having to specify which type is to be used when
> > establishing the RS
> > >>>> seems like a problem waiting to happen. I think the SRC won't
> > > always
> > >>>> know, or worse - it will think it knows but turn out to be
wrong.
> > >>>>
> > >>>> 	Thanks,
> > >>>> 	Paul
> > >>>>
> > >>>> On 4/25/2011 10:35 AM, Parthasarathi R (partr) wrote:
> > >>>>> Hi all,
> > >>>>> The context for this attribute is whether globally unique
> > >>>> id is required
> > >>>>> in each metadata block or whether it is required only in some
of
> > > the
> > >>
> > >>>>> block only. One of the compelling reason for globally
> > unique id is
> > >>>>> because of the complex relationship between RS and CS
> > which is not
> > >>>>> currently passed from SRC to SRS. I'm trying to find
> > >>>> whether passing the
> > >>>>> information will reduce the complexity of globally unique
> > >>>> id in some blocks.
> > >>>>> In case RS to CS relationship between SRC&   SRS, there is a
> > >>>> possibility
> > >>>>> of three types and they are as follows:
> > >>>>> 1) One RS to one CS: Simple mechanism and every CS is
> > >>>> directly mapped to
> > >>>>> RS. Here, RS needs to be global unique id whereas those block
is
> > > not
> > >>
> > >>>>> required to be global.
> > >>>>> 2) One RS to many CS:
> > >>>>> Usecases are as follows:
> > >>>>> a) Persistent recording
> > >>>>> b) Recording with single CSG
> > >>>>> Here as well, RS needs to be global unique id whereas those
> > >>>> block is not
> > >>>>> required to be global.
> > >>>>> 3) Many RS to one CS:
> > >>>>> Use case are as follows:
> > >>>>> a) start/stop recording session during single CS.
> > >>>>> Here. RS needs global unique id as well as CS needs global
> > >>>> unique id.
> > >>>>> Please note that this mechanism will not co-exist with
> > >>>> above two mechanism.
> > >>>>> The attribute name is recording_type wherein the value of
> > >>>> the attributes
> > >>>>> will be
> > >>>>> a) one_rs_one_cs
> > >>>>> b) one_rs_many_cs
> > >>>>> c) many_rs_one_cs
> > >>>>> By knowing this attribute, SRS will be able to manage
> > >>>> unique-id and its
> > >>>>> scope as SRS aware of SRC mechanism. Say in case of
> > >>>> one_rs_many_cs SRC,
> > >>>>> media stream (MS) will never exceed RS wherein in case of
> > >>>>> many_rs_one_cs, MS will never exceed CS and in both scenario,
MS
> > > is
> > >>>>> local to RS or CS. Please let me know whether it is worth
> > >>>> to add this
> > >>>>> attribute in Metadata model.
> > >>>>> Thanks
> > >>>>> Partha
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> 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: Tue, 3 May 2011 18:38:43 +0200

I saw a "recording" as being as being a recording of a CS. So yes, a recording can exist outside of an RS, and might even span multiple RSs, but doesn't the CS object cover this?

John 

> From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
> Sent: 02 May 2011 14:34
> To: Elwell, John; Paul Kyzivat (pkyzivat)
> [mailto:[email-masked]] On
> [mailto:[email-masked]] On
> > > > Behalf

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 3 May 2011 09:56:09 -0700

I do not think the CS is sufficient. For example, how do you know if I
want another recording of the same CS, or a single recording?

Cheers,
Charles

> Sent: Tuesday, May 03, 2011 9:39 AM
> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat)
inRecording block
> 
> I saw a "recording" as being as being a recording of a CS. So yes, a
recording can exist outside of an
> RS, and might even span multiple RSs, but doesn't the CS object cover
this?

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 3 May 2011 21:54:45 +0200

Why would I want two recordings of the same CS at the same SRS?

John

> Sent: 03 May 2011 17:56
> > > of scope, but is at least possible if a recording exists
> outside of
> an
> > > RS.
> > > > 00 has an object called "Recording Session", which
> seems to imply
> it
> > > > > > RS is not required. This is different than
> requiring a unique
> ID
> > > to
> > > > > >>>>> In case RS to CS relationship between SRC&
> SRS, there is
> a
> > > > > >>>> possibility

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 3 May 2011 13:25:25 -0700

Because one is mine and the other is yours and you want to record yours
in one format and in combination with other CSs, and I want mine in
another format and with other CSs.
For example you want yours recorded a single mixed audio and composited
video stream, and I want all separate streams.

Cheers,
Charles

> Sent: Tuesday, May 03, 2011 12:55 PM
inRecording block
> > > > > > >> But I think the SRS will want to keep track of where it
got

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 3 May 2011 22:33:10 +0200

In that case, I would assert that we need a "Recording" object in the metadata model, not a "Recording Session" object.

John

> Sent: 03 May 2011 21:25
> > > I do not think the CS is sufficient. For example, how do
> you know if
> I
> > > > I saw a "recording" as being as being a recording of a
> CS. So yes,
> a
> > > > > event something goes wrong with initial RS. It also
> facilitates
> > > having
> > > > > > From: Elwell, John
> [mailto:[email-masked]]
> > > > > > SIP dialog for the RS. If people have a notion of a
> recording
> > > object
> > > > > that does not have a 1:1
> > > > > > relationship with an RS, and therefore a single SIP
> dialog, I
> > > would
> > > > > > > >> the metadata XML format perspective,
> "recording" element
> > > unique
> > > > > id
> > > > > > > > will
> > > > > > > >> for the SRC to be able to transmit additional
> data about
> > > itself
> > > > > and
> > > > > > > > its
> > > > > > > >>>> seems like a problem waiting to happen. I
> think the SRC
> > > won't
> > > > > > > > always
> > > > > > > >>>>> Here as well, RS needs to be global unique
> id whereas
> > > those
> > > > > > > >>>> block is not
> > > > > > > >>>>> required to be global.
> > > > > > > >>>>> 3) Many RS to one CS:
> > > > > > > >>>>> Use case are as follows:

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 3 May 2011 14:29:47 -0700

Works for me.

> Sent: Tuesday, May 03, 2011 1:33 PM
inRecording block
> 
> In that case, I would assert that we need a "Recording" object in the
metadata model, not a "Recording
> Session" object.
> > > > > > > would be needed, with a view to getting it into the
metadata
> > > > model.
> > > > > > > > > point, he was suggesting a unique id within the
metadata
> > > > > > > > True. I guess we could either make its use mandatory
with
> > > > > > siprec, or
> > > > > > > > >> be defined by its application which is nothing but
SIP
> > (RS
> > > > > > > > >> "recording" element does not require any id in
Metadata
> > XML
> > > > > > > > >> BYE of RS SIP dialog.  The intention is to use some
of
> > > > > > > > >>> However, I have a feeling we have been round this
loop
> > > > before,
> > > > > > > > >>>>> many_rs_one_cs, MS will never exceed CS and in
both
> > > > > > scenario,

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 4 May 2011 06:14:19 +0530

All the folks in the mail thread indicates that SIPREC solution will be
designed in a generic fashion of "Many RS to Many CS" relationship in
SRS by default. Even current metadata format draft(-01) is written with
the same assumption.

In case anybody have disagreement with this approach, Please speak for
it.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Leon Portman
Sent: Wednesday, April 27, 2011 6:20 PM
To: Elwell, John; Paul Kyzivat (pkyzivat); [email-masked]
Subject: Re: [siprec] RS to CS relationship as an attributein Recording
block

I agree with Paul and John. Lets handle the complex case. And I also
agree that RS identity is not important. We have agreed that post CS
updating of metadata is out of scope

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
Sent: Wednesday, April 27, 2011 11:00 AM
To: Paul Kyzivat; [email-masked]
Subject: Re: [siprec] RS to CS relationship as an attribute in Recording
block

I agree with Paul.

Also, it is not at all clear to me why we need any unique identification
for the RS - doesn't the SIP dialog identifier achieve this? The RS is
only a vehicle for delivering one or more recordings (media and
metadata) to the SRS, and once the delivered information is stored for
future playback, the delivery mechanism, i.e., the RS identity, is no
longer relevant.

However, I have a feeling we have been round this loop before, so
apologies if we came to a resolution.

John (as individual)  

> Given all the combinations you cite, I'm inclined to simply plan to 
> Having to specify which type is to be used when establishing the RS 
> seems like a problem waiting to happen. I think the SRC won't always 
> know, or worse - it will think it knows but turn out to be wrong.
> 
> 	Thanks,
> 	Paul
> 
> > in each metadata block or whether it is required only in some of the

> > block only. One of the compelling reason for globally unique id is 
> > because of the complex relationship between RS and CS which is not 
> > In case RS to CS relationship between SRC & SRS, there is a
> possibility
> > RS. Here, RS needs to be global unique id whereas those block is not

> > many_rs_one_cs, MS will never exceed CS and in both scenario, MS is

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 May 2011 21:21:55 -0400

Of course this could be accomplished simply by dumb luck:

If you and I have separate SRCs and are asking for separate recordings 
of the "same" CS, it will only be recognized as the same CS if the two 
SRCs coordinate among themselves to use the same UUID for it. If they 
don't (likely in this case) the SRS with thing it is two CSs and so you 
get two recodings.

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 4 May 2011 11:05:28 +0530

I think this is something we discussed earlier w.r.t model also to
accommodate  "Many RS to many CS"
http://www.ietf.org/mail-archive/web/siprec/current/msg01746.html

The associations with that change in model can allow:
A CS to be associated with multiple RS [ to take care of use case 3
mentioned by Partha way below in this mail thread] 
A RS to have Zero or more CSs [ to support use case 1 and 2]

In any case I will add this item to model slide and we can discuss
during the Interim meeting on May 9th to close it.

Regards,
Ram

> Sent: Wednesday, May 04, 2011 6:14 AM
> To: Leon Portman; Elwell, John; Paul Kyzivat (pkyzivat);
> [email-masked]
> Recording
> identification

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 4 May 2011 17:20:55 +0530

I agree with Paul here. 
The below use-case that Charles mentions is a good example of two SRCs
recording the same CS simultaneously via different RS.
In these cases these are two Recording Sessions each recording the same
CS and the current model is sufficient for the same.

John,

so I don't see a need to change "Recording Session" to "Recording"
object in the model. Or are you talking here about grouping of
recordings ?

As Paul mentioned it will only be recognized as the same CS only if the
two SRCs coordinate among themselves to use the same UUID for it.
Otherwise we will get two recordings.

Ram

> Behalf Of Paul Kyzivat (pkyzivat)
> Sent: Wednesday, May 04, 2011 6:52 AM
> To: Elwell, John
> Cc: [email-masked]
inRecording
> metadata model, not a "Recording Session" object.
> >
> > John
> >

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 4 May 2011 15:40:08 +0200

Ram,

If we don't think a Recording object is needed for the case that Charles describes, fine. But I would also argue that we don't need a Recording Session object.

John (as individual)

> From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
> Sent: 04 May 2011 12:51

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 5 May 2011 15:57:39 -0700

The other use case is different RS for the same recording. That is where
I think recording object comes in handy.

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
> Sent: Wednesday, May 04, 2011 6:40 AM
> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
> Cc: [email-masked]
inRecording block
> 
> Ram,
> 
> If we don't think a Recording object is needed for the case that
Charles describes, fine. But I would
> also argue that we don't need a Recording Session object.
> 
> John (as individual)
> 
> > > don't (likely in this case) the SRS with thing it is two CSs and
so
> > you
> > > > In that case, I would assert that we need a "Recording" object
in
> > > >>>>>> Rather, one could, outside of the scope of SIPREC, decide
to
> > > >>>> associate
metadata

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 6 May 2011 07:20:12 +0530

Charles,

Different RS for same recording looks like "recording group"
requirement. There was "recording group" metadata block in the initial
metadata draft and it was removed as there was no known usecase. I'm
reading your usecase which may call for optional "recording group" block
in metadata model.   

I'll provide some hypothetical scenario: SRC has RS1 with mixed stream,
RS2 with unmixed stream for CS1. SRS has to aware that RS1 and RS2
belongs to same recording. This shall be achieved by "recording group"
metadata block which will extend for your scenario which is outside the
scope of SIPREC. Let us discuss in the meeting whether "recording group"
is required.

John,

Recording Session object has two attributes namely

1) Recording Requestor (SRC/SRS) - This may be required in SRS in terms
of metadata model but which shall be derived from the information
whether RS INVITE is received in SRS or INVITE sent out by SRS.

2) Recording type (Persistent/selective) - This attribute will become
irrelevant in case SRS is designed with the principle of "Many RS to
Many CS" as mentioned below in this mail thread.

Based on the current attributes, metadata format will have no standard
XML element. Please let me know whether your argue is same or not.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Charles Eckel (eckelcu)
Sent: Friday, May 06, 2011 4:28 AM
To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Re: [siprec] RS to CS relationship as an attribute inRecording
block

Cheers,
Charles

Behalf Of Elwell, John
inRecording block
> > In these cases these are two Recording Sessions each recording the 
> > same CS and the current model is sufficient for the same.
> >
> > John,
> >
> > As Paul mentioned it will only be recognized as the same CS only if 
> > the two SRCs coordinate among themselves to use the same UUID for 
> > it.
so
in
> > > >> Because one is mine and the other is yours and you want to 
> > > >> record yours in one format and in combination with other CSs, 
> > > >> and I
> > want mine in
> > > >> For example you want yours recorded a single mixed audio and 
> > > >> composited video stream, and I want all separate streams.
> > > >>
> > > >> Cheers,
> > > >> Charles
> > > >>

> > > >>>>>> inRecording block
> > > >>>>>>
> > > >>>>>> Hi John,
> > > >>>>>>
> > > >>>>>> Having a recording exist outside of the RS provides, among 
> > > >>>>>> other things, a way for a SRC to establish a new RS to 
> > > >>>>>> continue a
> > > >>>> recording in the
> > > >>>>>> multiple SRCs participate in the same recording, which we 
> > > >>>>>> agreed was out of scope, but is at least possible if a 
> > > >>>>>> recording exists
> > > >>>> outside of
> > > >>>> an
> > > >>>>>> RS.
to
> > > >>>> associate
> > > >>>>>> multiple RSs in various ways, including stitching them 
> > > >>>>>> together for the purpose of failover or distributed 
> > > >>>>>> recordings. Is that what you have in mind?
> > > >>>>>>
> > > >>>>>> Cheers,
> > > >>>>>> Charles
> > > >>>>>>
metadata
> > > >>>>>>>> accumulated about a CS or CSG. That data has been 
> > > >>>>>>>> received through one *or
> > > >>>>>>>> more* RSs. Each
> > > >>>>>>>>>>>>> b) Recording with single CSG Here as well, RS needs 
> > > >>>>>>>>>>>>> to be global unique
> > > >> id whereas
> > > >>>> those
> > > >>>>>>>>>>>> block is not
> > > >>>>>>>>>>>>> required to be global.
> > > >>>>>>>>>>>>> 3) Many RS to one CS:
> > > >>>>>>>>>>>>> Use case are as follows:

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 6 May 2011 09:34:19 +0200

(answering only the part addressed to me - see below)

> From: Parthasarathi R (partr) [mailto:[email-masked]]
> Sent: 06 May 2011 02:50
> To: Charles Eckel (eckelcu); Elwell, John; Ram Mohan R
> (rmohanr); Paul Kyzivat (pkyzivat)
> Cc: [email-masked]
[JRE] My reasoning for suggesting the RS object class is not needed is because an RS is only a means to an end. It is only a vehicle for delivering metadata and media to the SRS for recording. How that data got delivered to the SRS is irrelevant for the purposes of storing the data, searching the data and retrieving the data. So I don't think we need to model an RS object class in our metadata model and we don't need to define a format for such an object in our metadata format.

Concerning the attributes that currently are part of an RS object:
- Recording Requester (SRC/SRS). The SRS already knows this, so does not need to be receive this information again as part of transmitted metadata.
- Recording Type (Persistent/Selective). First, we are defining a generic mechanism, whereby an RS can support 1 or more CSs and a CS can be recorded by one or more RSs. Based on this generic mechanism, an SRC can alter the relationship between CS and RS at will, and there are probably far more than two ways it can do that - trying to pigeon hole things into persistent and selective is too inflexible.
Secondly, the SRS can see what is happening from other information in the metadata. For the particular case where an RS is retained over a number of CSs in sequence, perhaps with gaps between them, it can deduce (if it really wants to) from metadata updates that this is a persistent case. We don't need to repeat that information (and introduce the possibility of conflicting information).

John (as individual)

> [mailto:[email-masked]] On Behalf
> > > > >>>>>>> I am confused, because this thread has suddenly
> started to
> > > > >>>>>> talk about
> > > > >>>>>>>>> point, he was suggesting a unique id within
> the metadata
> > > > >> to
> > > > >>>>>>>> identify the
> > > > >>>>>>>> True. I guess we could either make its use
> mandatory with
> > > > >>>>>> siprec, or
> > > > >>>>>>>>>> be defined by its application which is
> nothing but SIP
> > > > >> (RS
> > > > >>>>>>>> dialog-id).
> > > > >>>>>>>>>> "recording" element does not require any id
> in Metadata
> > > > >> XML
> > > > >>>>>> because
> > > > >>>>>>>>> only
> > > > >>>>>>>>>> BYE of RS SIP dialog.  The intention is to
> use some of
> > > > >> the
> > > > >>>>>> metadata
> > > > >>>>>>>>>>> However, I have a feeling we have been
> round this loop
> > > > >>>> before,
> > > > >>>>>> so
> > > > >>>>>>>>>>>>> many_rs_one_cs, MS will never exceed CS
> and in both
> > > > >>>>>> scenario,
> > > > >>>>>> MS
> > > > >>>>>>>>> is

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 6 May 2011 15:37:05 +0530

John,

Please read inline

Thanks
Partha 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Friday, May 06, 2011 1:04 PM
To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R
(rmohanr); Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] RS to CS relationship as an attribute inRecording
block

> To: Charles Eckel (eckelcu); Elwell, John; Ram Mohan R (rmohanr); Paul

> Kyzivat (pkyzivat)

> reading your usecase which may call for optional "recording group" 
> block in metadata model.
>
> metadata block which will extend for your scenario which is outside 
> the scope of SIPREC. Let us discuss in the meeting whether "recording 
> group"
> is required.
>
> John,
>
> 1) Recording Requestor (SRC/SRS) - This may be required in SRS in 
> terms of metadata model but which shall be derived from the 
> information whether RS INVITE is received in SRS or INVITE sent out by

> SRS.

> XML element. Please let me know whether your argue is same or not.
[JRE] My reasoning for suggesting the RS object class is not needed is
because an RS is only a means to an end. It is only a vehicle for
delivering metadata and media to the SRS for recording. How that data
got delivered to the SRS is irrelevant for the purposes of storing the
data, searching the data and retrieving the data. 

<Partha> It might. Keeping metadata information of whether recording
initiated by SRS or SRC may be crucial information in some recording
deployment. But I agree with you that there is no known agreed upon
element within recording element of metadata format. Let us discuss in
detail during the meeting and close this open end </Partha> 

So I don't think we need to model an RS object class in our metadata
model and we don't need to define a format for such an object in our
metadata format.

Concerning the attributes that currently are part of an RS object:
- Recording Requester (SRC/SRS). The SRS already knows this, so does not
need to be receive this information again as part of transmitted
metadata.

<Partha> As I mentioned earlier, metadata model is designed from SRS
point of view wherein the initiator of RS may be required in SRS for
further processing. Let us discuss and close it in the meeting <Partha>

- Recording Type (Persistent/Selective). First, we are defining a
generic mechanism, whereby an RS can support 1 or more CSs and a CS can
be recorded by one or more RSs. Based on this generic mechanism, an SRC
can alter the relationship between CS and RS at will, and there are
probably far more than two ways it can do that - trying to pigeon hole
things into persistent and selective is too inflexible.
Secondly, the SRS can see what is happening from other information in
the metadata. For the particular case where an RS is retained over a
number of CSs in sequence, perhaps with gaps between them, it can deduce
(if it really wants to) from metadata updates that this is a persistent
case. We don't need to repeat that information (and introduce the
possibility of conflicting information).

<Partha> Agreed. Let us remove this attribute until otherwise somebody
has disagreement </Partha>

John (as individual)

> [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
> > > > >>>>>>>>>>>>> siprec mailing list [email-masked] 
> > > > >>>>>>>>>>>> siprec mailing list [email-masked]

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 6 May 2011 10:19:32 -0700

Hi Partha,

I am responding to the first part of the e-mail as John and yourself
have already continued the second part in another thread.
A recording group would work for me as well. My goal is to have some way
for an SRC to tell the SRS this RS for meant to be part of something
that already exists, perhaps on this same SRS. We can call it a
recording group, and recording object, and recording ID, or whatever we
want. The idea is that when a recording starts, a recording ID is
generated, either by the SRC, or by the SRS if none is provided by the
SRC. This recording ID could be used to tie other RSs to the same
recording.
I agree this could be achieved by a mechanism outside of SIPREC, but I
think it might be helpful to build it into SIPREC was it seems like a
pretty useful and basic feature to me. 

Cheers,
Charles

> From: Parthasarathi R (partr)
> Sent: Thursday, May 05, 2011 6:50 PM
Kyzivat (pkyzivat)
inRecording block
> Different RS for same recording looks like "recording group"
requirement. There was "recording group"
> metadata block in the initial metadata draft and it was removed as
there was no known usecase. I'm
block in metadata model.
> 
> I'll provide some hypothetical scenario: SRC has RS1 with mixed
stream, RS2 with unmixed stream for
> CS1. SRS has to aware that RS1 and RS2 belongs to same recording. This
shall be achieved by "recording
> group" metadata block which will extend for your scenario which is
outside the scope of SIPREC. Let us
> discuss in the meeting whether "recording group" is required.
> 
> John,
> 
terms of metadata model but which
> shall be derived from the information whether RS INVITE is received in
SRS or INVITE sent out by SRS.
> 2) Recording type (Persistent/selective) - This attribute will become
irrelevant in case SRS is
> designed with the principle of "Many RS to Many CS" as mentioned below
in this mail thread.
> Based on the current attributes, metadata format will have no standard
XML element. Please let me know
> whether your argue is same or not.
> 
> Thanks
> Partha
> 
Behalf Of Charles Eckel (eckelcu)
inRecording block
> 
> The other use case is different RS for the same recording. That is
where I think recording object
> comes in handy.
> > > > >>>>>>> I am confused, because this thread has suddenly started
to
metadata
with
SIP
Metadata
of
loop
both

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 6 May 2011 23:58:59 +0530

Hi Charles,

I agree with you for having "optional" recording group metadata block
which relates to "recording session". Let us have closure in meeting for
the addition of this new "optional" block.

As recording group is decided by SRC, I prefer the unique id generation
by SRC which is inline with the current metadata format. Please note
that multiple SRC creating recording group is outside the scope of
SIRPEC.

Thanks
Partha

-----Original Message-----
From: Charles Eckel (eckelcu) 
Sent: Friday, May 06, 2011 10:50 PM
To: Parthasarathi R (partr); 'Elwell, John'; Ram Mohan R (rmohanr); Paul
Kyzivat (pkyzivat)
Cc: [email-masked]'

Hi Partha,

Cheers,
Charles

> there was no known usecase. I'm reading your usecase which may call
for optional "recording group" block in metadata model.
> stream, RS2 with unmixed stream for CS1. SRS has to aware that RS1 and

> RS2 belongs to same recording. This shall be achieved by "recording 
outside the scope of SIPREC. Let us discuss in the meeting whether
"recording group" is required.

> where I think recording object comes in handy.
> 
> Cheers,
> Charles
> 

> > > As Paul mentioned it will only be recognized as the same CS only 
> > > if the two SRCs coordinate among themselves to use the same UUID 
> > > for it.
> > > > From: [email-masked] [mailto:[email-masked]] 
> > > > On Behalf Of Paul Kyzivat (pkyzivat)

> > > > >>>>>> Subject: RE: [siprec] RS to CS relationship as an 
> > > > >>>>>> attribute inRecording block
> > > > >>>>>>
> > > > >>>>>> Hi John,
> > > > >>>>>>
> > > > >>>>>> Having a recording exist outside of the RS provides, 
> > > > >>>>>> among other things, a way for a SRC to establish a new RS

> > > > >>>>>> to continue a

> > > > >>>>>>>>>>>>> b) Recording with single CSG Here as well, RS 
> > > > >>>>>>>>>>>>> needs to be global unique
> > > > >> id whereas
> > > > >>>> those
> > > > >>>>>>>>>>>> block is not
> > > > >>>>>>>>>>>>> required to be global.
> > > > >>>>>>>>>>>>> 3) Many RS to one CS:
> > > > >>>>>>>>>>>>> Use case are as follows: