Subject: [siprec] RS to CS relationship as an attribute in Recording block

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 25 Apr 2011 20:05:04 +0530

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Apr 2011 10:57:11 -0400

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:
> information will reduce the complexity of globally unique id in some blocks.
> Please note that this mechanism will not co-exist with above two mechanism.
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 27 Apr 2011 10:00:05 +0200

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)  

> -----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
>

---

From: Leon Portman <[email-masked]>
Date: Wed, 27 Apr 2011 15:50:25 +0300

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.

John (as individual)  

> Subject: Re: [siprec] RS to CS relationship as an attribute in 
> Recording block
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Apr 2011 09:57:46 -0400

> 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…

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

>>> In case RS to CS relationship between SRC&  SRS, there is a
>> possibility

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 29 Apr 2011 11:54:00 +0530

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.

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 29 Apr 2011 08:47:43 -0700

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. 
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.

Cheers,
Charles

> 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]
inRecording block
> Subject: Re: [siprec] RS to CS relationship as an attribute
inRecording

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Apr 2011 20:37:54 -0400

> such as having the SRC re-establish a new RS the SRS for the purpose of

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

> so you would need SIPREC to make it mandatory for SRC and SRS, else they

True. I guess we could either make its use mandatory with siprec, or 
else convey the data separately in the metadata.

	Thanks,
	Paul

>> start/stop time which shall be derived from "Date" header in INVITE&
> Behalf

---

From: "Elwell, John" <[email-masked]>
Date: Sat, 30 Apr 2011 12:11:55 +0200

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

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 30 April 2011 01:38
> To: Charles Eckel (eckelcu)
> Cc: Parthasarathi R (partr); Elwell, John; [email-masked]