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

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 1 Apr 2011 06:09:03 -0700

How about:

OLD:
Metadata is the data that describes the communication session.

NEW:
Metadata is the data that describes the recording session, including the
communication sessions it is recording.

Cheers,
Charles

> -----Original Message-----
> From: Elwell, John [mailto:[email-masked]]
> Sent: Thursday, March 31, 2011 6:30 PM
> To: Charles Eckel (eckelcu); Parthasarathi R (partr); [email-masked]
> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04
> 
> 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
> 
> > -----Original Message-----
> > From: Charles Eckel (eckelcu) [mailto:[email-masked]]
> > Sent: 31 March 2011 17:11
> > To: Elwell, John; Parthasarathi R (partr); [email-masked]
> > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04
> >
> > Hi John,
> >
> > Please see inline.
> >
> > > -----Original Message-----
> > > From: Elwell, John [mailto:[email-masked]]
> > > Sent: Wednesday, March 30, 2011 11:01 AM
> > > To: Charles Eckel (eckelcu); Parthasarathi R (partr);
> > [email-masked]
> > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > 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,
> > > >
> > > > Thanks for your response. This addresses all of my concerns.
> > > > Please see
> > > > one additional clarification inline.
> > > >
> > > > > -----Original Message-----
> > > > > 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,
> > > > >
> > > > > 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
> > > > >
> > > > > 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".
> > > [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
> >
> > >
> > >
> > > > >
> > > > > 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.
> > > > >
> > > > >
> > > > > <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>
> > > >
> > > > 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
> > > >
> > > > > 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.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?
> > > > > <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
> > > > _______________________________________________
> > > > siprec mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/siprec
> > > >
> >

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Sat, 2 Apr 2011 15:10:47 +0530

Hi Charles,

Inline

> From: [email-masked] [mailto:[email-masked]] On
> Sent: Friday, April 01, 2011 6:39 PM

This  text seems to create more confusion. Please note Metadata does not
describe anything about RS. It describes only about CS.

Ram

[email-masked]

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Sun, 3 Apr 2011 22:43:23 +0530

Scott,

I am ok to make this change to the model. I would like to hear from
others if they have any issues in incorporating this change in the
model. 

The updated portion of the model will look like

  +-------------------------------+       1
  | Recording Session (RS)        |---------------+
  +-------------------------------+               |
             | 1..*             |1..*             |
             |                  |                 |
             | 0..*             |0..*             |
  +--------------+          +-----------------+   |
  |Communication |          | Communication   | 1 | 
  | Session (CS) |----------| Session (CS)    |---|
  |   Group      |0..1  1..*|                 |   | 0..* +----------+
  +--------------+          +-----------------+   |------|Extension |
       1|                     | 0..*        |1..* |      | Data     |

        |                     | 2..*        |0..* |      +----------+

    0..*|
    +---------+
    |Extension|       
    | Data    |
    +---------+

The only change in the association is :
A CS MUST be associated with zero or one CS-Group

Rest of the associations remain same. Further the association between CS
and RS remains same as what is between CS-Group and RS.

Comments ?

Regards,
Ram

> Behalf Of Scott Orton
> Sent: Friday, April 01, 2011 12:18 AM
> To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R (partr);
> [email-masked]
> 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
> Sent: Thursday, March 31, 2011 11:50 AM
> To: Scott Orton; Charles Eckel (eckelcu); Parthasarathi R (partr);
> [email-masked]
> 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]
> > 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
> >
> > [mailto:[email-masked]] On Behalf Of Elwell, John
> > Sent: Thursday, March 31, 2011 11:30 AM
[email-masked]
> > 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
> >
> > > > > > within the Recording Session", and "time a change
> > occurred by be
> > > > [JRE] I am not sure exactly what text Charles was
> > commenting on, but
> > > > > > attributes of each element. This section also
> > describes how the
> > > > > > <partha>  Please clarify whether you are interested
> > in AOR of RS
> > > or
> > > > > > (1..*) is related to CSG (0..*) and there is no need
> > of separate
> > > > > > Section 4.2.1, replace "SRC (or MAY be SRS)" with
> > "SRC or SRS".
> > > > > > 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: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sun, 3 Apr 2011 11:22:23 -0700

Hi Ram,

I agree that main point focus of the metadata is the description of the
communication sessions(s); however, the metadata model contains a
recording session element, and the recording element contains attributes
specific to the recording session. For that reason, I think it is
misleading to say the metadata describes the communication session.
Perhaps you are suggesting the recording session element should be
removed from the model, and it may be maintained in an unspecified
manner within the SRS?

Cheers,
Charles

> From: Ram Mohan R (rmohanr)
> Sent: Saturday, April 02, 2011 11:41 AM
> To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R (partr);
[email-masked]
> This  text seems to create more confusion. Please note Metadata does
not describe anything about RS.
> It describes only about CS.
> 
> Ram
> 
> >
> > Cheers,
> > Charles
> >
[email-masked]
> > > > > > > Subject: RE: [siprec] comments on
draft-ram-siprec-metadata-
> > 04

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 4 Apr 2011 09:12:23 +0530

Hi Charles,

Please see inline

> From: Charles Eckel (eckelcu)
> Sent: Sunday, April 03, 2011 11:52 PM
> To: Ram Mohan R (rmohanr); 'Elwell, John'; Parthasarathi R (partr);
> [email-masked]'
> recording session element, and the recording element contains
> attributes specific to the recording session. For that reason, I think
> it is misleading to say the metadata describes the communication
> session.

No I am not suggesting that.  I think we need slightly better wording
than that.
Metadata describes the CS but is carried in RS. Metadata has information
about CS participants, different transactions of CS(which are carried in
RS). Metadata maps  CS participants to the recorded media sent in RS.
So to summarize Metadata describes the recorded media sent in RS and its
relation to CS.

Perhaps we could retain the wordings of the Req draft ?
The requirement draft has
Metadata: Information that describes recorded media and the CS to
which they relate.

Thoughts ?

Ram

> > > Metadata is the data that describes the recording session,
> including
> > > the
(and
> CS
> > > > > > > > Subject: RE: [siprec] comments on draft-ram-siprec-
> metadata-
> > > 04
> > > > > > > >
> > > > > > > > Charles,
> > > > > > > >
> occurred by

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 4 Apr 2011 09:41:51 +0200

Sure, that wording works for me. 

Thanks,
Charles

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 4 Apr 2011 13:41:35 +0530

OK.
I will update the same in the next revision.

Ram

-----Original Message-----
From: Charles Eckel (eckelcu)
Sent: Mon 4/4/2011 1:11 PM
To: Ram Mohan R (rmohanr)
Cc: Elwell, John; Parthasarathi R (partr); [email-masked]
Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04

Thanks,
Charles

---

From: Leon Portman <[email-masked]>
Date: Tue, 5 Apr 2011 17:01:09 +0300

+1

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
Sent: Monday, April 04, 2011 10:42 AM
To: Ram Mohan R (rmohanr)
Cc: [email-masked]
Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04

Thanks,
Charles

On Apr 4, 2011, at 5:42 AM, "Ram Mohan R (rmohanr)" <[email-masked]> wrote:

>> attributes specific to the recording session. For that reason, I 
>> think it is misleading to say the metadata describes the 
>> communication session.
> Metadata describes the CS but is carried in RS. Metadata has 
> information about CS participants, different transactions of CS(which 
> are carried in RS). Metadata maps  CS participants to the recorded media sent in RS.
> So to summarize Metadata describes the recorded media sent in RS and 
> its relation to CS.
> 
>>>>>> 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
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>>> 
>>>>>>>> another RS, and that is the reason I was recommending adding a 
>>>>>>>> unique ID.
>>>>>>>> This ID would

---

From: Leon Portman <[email-masked]>
Date: Tue, 5 Apr 2011 17:01:20 +0300

I am ok

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
Sent: Sunday, April 03, 2011 8:13 PM
To: Scott Orton; Elwell, John; Charles Eckel (eckelcu); Parthasarathi R (partr); [email-masked]
Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04

Scott,

I am ok to make this change to the model. I would like to hear from others if they have any issues in incorporating this change in the model. 

    0..*|
    +---------+
    |Extension|       
    | Data    |
    +---------+

Rest of the associations remain same. Further the association between CS and RS remains same as what is between CS-Group and RS.

Comments ?

Regards,
Ram

the
those
> >    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:
> >
> > recording session A one to many relationship - one communication 
> > session with multiple Recording sessions
> > The current metadata format allows all of these and I do not see 
> > what the group is adding.
> >
> > Regards,
> >     Scott
> >
[email-masked]
> > groups) that are being carried in the RS. Any ideas how better to 
> > word it?
> >
> > John
> >

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 6 Apr 2011 14:41:35 +0200

Yes, the wording from siprec-req works for me.

John

> Sent: 04 April 2011 08:42

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 6 Apr 2011 14:45:42 +0200

I am OK in principle, but I wonder whether there really needs to be a relationship between CSG and RS. Isn't that relationship an indirect relationship via CS?

John (as individual)

> From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
> Sent: 03 April 2011 18:13

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 6 Apr 2011 20:22:11 +0530

Hi John,

Yes We have an indirect relationship in the current model. However in
the current model it is REQUIRED to have a CSG as CS is connected to RS
through CSG. However not all use cases would need CSG, IOW CSG has to be
optional and there should be direct association from CS to RS even when
CSG is absent.

With the below associations we will have:
- An instance of RS can have Zero or more CSG blocks.
- An instance of RS can have Zero or more CS blocks.
- If a CSG is present it will have 1 or more CS.
- Each CS can be associated with Zero or 1 CSG.

Let me know if you have any concerns.

Regards,
Ram

> Sent: Wednesday, April 06, 2011 6:16 PM
> To: Ram Mohan R (rmohanr); Scott Orton; Charles Eckel (eckelcu);
> Parthasarathi R (partr); [email-masked]
> I am OK in principle, but I wonder whether there really needs to be a
> relationship between CSG and RS. Isn't that relationship an indirect
> relationship via CS?
> 
> John (as individual)
> 
> 
(partr);

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 6 Apr 2011 17:47:08 +0200

Ram,

I am not sure this answers my question. In the model you drew below, a CSG has both a direct relationship with an RS and an indirect relationship (via a CS). I was questioning whether we could remove the direct relationship, on the basis that the indirect relationship is sufficient.

John (as individual)

> Sent: 06 April 2011 15:52
> To: Elwell, John; Scott Orton; Charles Eckel (eckelcu); 
> > >   +--------------+          +-----------------+   
> |------|Extension
> |
> > >        1|                     | 0..*        |1..* |      | Data
> |
> > >         |                     | 2..*        |0..* |
> +----------+
> > >     0..*|
> > >     +---------+
> > >     |Extension|
> > >     | Data    |
> > >     +---------+
> > >

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 6 Apr 2011 22:18:13 +0530

Ok. I got your point. I am fine with this.  The updated portion will
look like below

                                |1..*             |
                                |                 |
                                |0..*             |

CSG can use the indirect relationship (via a CS).

Ram

> Sent: Wednesday, April 06, 2011 9:17 PM
> I am not sure this answers my question. In the model you drew below, a
> CSG has both a direct relationship with an RS and an indirect
> relationship (via a CS). I was questioning whether we could remove the
> direct relationship, on the basis that the indirect relationship is
> sufficient.
> 
> John (as individual)
> 
> 
> > > > > would just have its own ID and then a list of CS ids that
> belong
> > to
> > > > the
> > > > > group.
> > > > >
> > > > > Scott
> > > > >

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Apr 2011 15:22:52 -0400

John,

I've been thinking about how everything relates to the RS, and that 
maybe we should make some more major changes.

What I'm thinking is that none of the elements have a direct 
relationship to RS. Rather, each element is ultimately constructed as a 
time series of values delivered in updates. Its the updates that have a 
relationship to a RS - the one they are delivered in. That allows the 
possibility that not all the updates come from the same RS.

I haven't drawn a model diagram here because the concept is still fuzzy. 
Its a trial balloon - to see what others think.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 6 Apr 2011 22:10:35 +0200

Yes, that is what I meant, but I see Paul has in mind some more major changes.

John 

> Sent: 06 April 2011 17:48
> > > > >        1|                     | 0..*        |1..* |   
>    | Data
> > > > > > From: Elwell, John 
> [mailto:[email-masked]]
> draft-ram-siprec-metadata-04
> > > > > >
> > > > > > Scott,
> > > > > >

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 7 Apr 2011 16:06:54 +0530

John/Ram,

I see the issue without direct link between RS and CSG. It may be tough
to correlate CSG to RS in SRS implementation. This issue is raised by
Hadriel in terms of having single unique id for metadata format draft. I
explained his concern in "Partial updates and identifiers" mail thread.

Also another issue: SRS may be interested in knowing list of associated
RS for a given CSG. 

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat (pkyzivat)
Sent: Thursday, April 07, 2011 12:53 AM
To: [email-masked]
Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04

John,

	Thanks,
	Paul

>> To: Elwell, John; Scott Orton; Charles Eckel (eckelcu); Parthasarathi

>> R (partr); [email-masked]

>> the current model it is REQUIRED to have a CSG as CS is connected to 
>> RS through CSG. However not all use cases would need CSG, IOW CSG has

>> to be optional and there should be direct association from CS to RS 
>> even when CSG is absent.
>>

>>>> Rest of the associations remain same. Further the association 
>>>> between CS and RS remains same as what is between CS-Group and RS.
>>>>
>>>> Comments ?
>>>>
>>>> Regards,
>>>> Ram
>>>>
>>>>>>     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:
>>>>>>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 19 Apr 2011 16:01:03 +0530

Partha,
I agree with your concern here.

John,
Are you ok with retaining the below relation in the model, If yes we can
close this open item of the model

         |1..*                  |1..*             |
         |0..*                  |0..*             |

Regards,
Ram

> Sent: Thursday, April 07, 2011 4:07 PM
> To: Paul Kyzivat (pkyzivat); [email-masked]; Ram Mohan R (rmohanr);
> Elwell, John
> Hadriel in terms of having single unique id for metadata format draft.
> I explained his concern in "Partial updates and identifiers" mail
> thread.
> 
> Behalf Of Paul Kyzivat (pkyzivat)
> > I am not sure this answers my question. In the model you drew below,
> a CSG has both a direct relationship with an RS and an indirect
do
> >>>>>> The current metadata format allows all of these and I do not
see

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 19 Apr 2011 14:32:59 +0200

Ram,

I am not quite sure whether that is an issue or not. If we go for a single unique identifier, I suspect it would need to identify a CS, not an RS. In fact I was waiting to hear more from Paul on his assertion below, that perhaps none of the elements has a direct relationship with an RS. I am OK leaving the relationship in for now. It might become clearer when we resolve the question of identifiers. 

John (as individual) 

> Sent: 19 April 2011 11:31
> To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); 
> [email-masked]; Elwell, John
> > relationship to RS. Rather, each element is ultimately 
> constructed as
> a
> > time series of values delivered in updates. Its the updates 
> that have
> a
> > >> Yes We have an indirect relationship in the current 
> model. However
> > in
> > >>>>> would just have its own ID and then a list of CS ids 
> that belong
> > >> to
> > >>>> the
> > >>>>> group.
> > >>>>>
> > >>>>> Scott
> > >>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Apr 2011 09:13:03 -0400

> I am not quite sure whether that is an issue or not. If we go for a single unique identifier, I suspect it would need to identify a CS, not an RS. In fact I was waiting to hear more from Paul on hi…

I haven't worked out the details. The concept would require the 
metamodel to be modified to explicitly represent the results of updates. 
Then, each individually updatable datum in the model would be tied to 
the update that delivered it, and thus to an RS in which it was 
delivered and a timestamp for when it was delivered. Each such updatable 
datum would be represented as a time series of values.

For instance, the relationship between media streams and participants 
could be represented either as:

- each stream has a series for each participant in the stream.
   Each element in the series identifies a change in the role
   of the participant relative to that stream.

- each participant has a series for each stream in which it
   participates. Each element in the series identifies a change
   in the role of the participant relative to the stream.

In either case, each element in the series would refer to the RS over 
which it was delivered, and would have a timestamp indicating when it 
occurred.

For instance, elements in the series might indicate:
- (alice:stream-1) sending@t1, inactive@t10, sending@t20, inactive@t30
- (bob:stream-1) recving@t2, inactive@t31
- (carol:stream-1) recving@t8, inactive@t12, recving@t20, inactive@t25
- (ted:stream-1) sending@t10, inactive@t20

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 19 Apr 2011 16:33:36 +0200

I think I see where you are going. Each element in a series could potentially be delivered over a different RS. This seems to imply an RS only needs to exist momentarily. However, the RS has SDP that contains the media descriptions, and a given media description, including it's a=label attribute tying it to a Media Stream object, will need to exist continually, between the deltas. Tearing down an RS will also tear down the delivery of media for a Media Stream to the SRS. So I am not entirely sure what you have in mind.

John

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 19 April 2011 14:13
> To: Elwell, John
> Cc: Ram Mohan R (rmohanr); Parthasarathi R (partr); [email-masked]
> > I am not quite sure whether that is an issue or not. If we 
> go for a single unique identifier, I suspect it would need to 
> identify a CS, not an RS. In fact I was waiting to hear more 
> from Paul on his assertion below, that perhaps none of the 
> elements has a direct relationship with an RS. I am OK 
> leaving the relationship in for now. It might become clearer 
> when we resolve the question of identifiers.
> 
> |------|Extension |
> >>>>> the current model it is REQUIRED to have a CSG as CS is 
> connected
> >> to
> >>>>> RS through CSG. However not all use cases would need 
> CSG, IOW CSG
> >>> has

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Apr 2011 11:23:18 -0400

> I think I see where you are going. Each element in a series could potentially be delivered over a different RS. This seems to imply an RS only needs to exist momentarily. However, the RS has SDP th…

First, the idea is only half baked, so certainly feel free to take shots 
at it.

And, in case of MS, perhaps you are right that you can't reference the 
same MS from two different RS.

Or maybe you could. In principle an SRC could lose the RS dialog, 
establish a new one, and then continue talking about the same CS and MS. 
(This could happen if the SRS server crashed and a backup took over for 
it.) Its a different RTP stream on the RS, but its delivering data for 
the same CS MS.

Since in the case of a persistent RS we are prepared to have a single 
m-line in the RS represent (serially, not concurrently) different MSs, 
its clear there isn't a 1:1 relationship. So why not two different RS 
m-lines representing (serially) the same MS?

But the notion may be more important for other stuff that changes over time.

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 19 Apr 2011 21:12:19 +0530

Hi John,

Yes I agree with you on waiting till get more clarity on the identifiers
(UUID) and its need for each blocks.

I will respond with my comments on the identifiers in the other thread.
Regards,
Ram

> Sent: Tuesday, April 19, 2011 6:03 PM
> To: Ram Mohan R (rmohanr); Parthasarathi R (partr); Paul Kyzivat
> (pkyzivat); [email-masked]
> I am not quite sure whether that is an issue or not. If we go for a
> single unique identifier, I suspect it would need to identify a CS,
not
> an RS. In fact I was waiting to hear more from Paul on his assertion
> below, that perhaps none of the elements has a direct relationship
with
> an RS. I am OK leaving the relationship in for now. It might become
> clearer when we resolve the question of identifiers.
> 
> John (as individual)
> 
> > > >> RS through CSG. However not all use cases would need CSG, IOW
> CSG
> > > has
> > > >>>> others if they have any issues in incorporating this change
in
> > > >>>> between CS and RS remains same as what is between CS-Group
and
> > RS.

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 19 Apr 2011 21:20:12 +0530

John,

Even If we tear down the RS, we can still have the same MS block in the
model ( and in format identified by its unique identifier).
Of course the properties of the MS will be different at different
instances. In the first instance it will have the label attribute to RS1
SDP.
In the second instance it can have label attribute pointing to RS2 SDP.
This is just my thought and we should think through different scenarios
to see if this can work

Regards,
Ram

> From: Paul Kyzivat (pkyzivat)
> Sent: Tuesday, April 19, 2011 8:53 PM
> To: Elwell, John
> > I think I see where you are going. Each element in a series could
> potentially be delivered over a different RS. This seems to imply an
RS
> only needs to exist momentarily. However, the RS has SDP that contains
> the media descriptions, and a given media description, including it's
> a=label attribute tying it to a Media Stream object, will need to
exist
> continually, between the deltas. Tearing down an RS will also tear
down
> the delivery of media for a Media Stream to the SRS. So I am not
> entirely sure what you have in mind.
> 
> >>>>> I see the issue without direct link between RS and CSG. It may
be
> >>>> tough
> >>>>> I haven't drawn a model diagram here because the concept is
still
> >>>>> fuzzy.
> >>>>>>>>>> Rather than the CS pointing to the CS Group, I would like
to
> >>>>>>>> suggest

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 20 Apr 2011 12:59:28 +0200

I guess the point I am trying to make is that the RS has to be persistent so that you can continually deliver media streams to the SRS. Agreed it can break, and have to be re-established, but under normal operation it would be persistent for the duration of the CS being recorded (or longer in the case of "persistent recording"). So when a metadata update includes a Media Stream, the metadata is essentially tied to that RS until a further metadata update occurs removing that Media Stream or until the RS ceases to exist, whichever is sooner.

John (as individual)

> Sent: 19 April 2011 16:50
> To: Paul Kyzivat (pkyzivat); Elwell, John
> Cc: Parthasarathi R (partr); [email-masked]
> > But the notion may be more important for other stuff that
> changes over
> > time.
> >
> >     Thanks,
> >     Paul
> >
> > > John
> > >
> > >
> > >> Then, each individually updatable datum in the model
> would be tied
> > to
> > >> which it was delivered, and would have a timestamp
> indicating when
> > it
> > >> occurred.
> > >>
> > >>>>>>>>>      |   Group      |0..1  1..*|
> |   | 0..*
> > >>>>>>> +----------+
> > >>>>>>>>>> Some folks wanted to be able to group related
> CSs together
> > >>>>>>>>> (e.g., a CS

---

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

John,

I agree with you that normal cases RS will remain at least for the
duration of CS. However it is common to have use cases where recording
is done for first few mins of a CS and then stopped, re-started at a
later point (e.g Recording of a company meeting where you may want to
record only portions of meeting). 

In any case, the point I like to high light here is, MS block could be
common across RS and even across CS[ due to consult transfer e.t.c].
These use cases indicate the need to have a unique ID for MS block
(similar to the UUID that we have defined in format) as we cannot depend
on neither CS ID or RS ID.

Let me know your comments on this.

Regards,
Ram
> Sent: Wednesday, April 20, 2011 4:29 PM
> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
> I guess the point I am trying to make is that the RS has to be
> persistent so that you can continually deliver media streams to the
> SRS. Agreed it can break, and have to be re-established, but under
> normal operation it would be persistent for the duration of the CS
> being recorded (or longer in the case of "persistent recording"). So
> when a metadata update includes a Media Stream, the metadata is
> essentially tied to that RS until a further metadata update occurs
> removing that Media Stream or until the RS ceases to exist, whichever
> is sooner.
> 
> John (as individual)
> 
> > > establish a new one, and then continue talking about the same CS
> and
> > > MS.
> > > (This could happen if the SRS server crashed and a backup took
over
> > for
> > > >> In either case, each element in the series would refer to the
RS
> > > over
> > > >>>>> From: [email-masked] [mailto:siprec-
> [email-masked]]
> > On
> > > >>>>>>>> relationship between CSG and RS. Isn't that relationship
> an
> > > >>>>> indirect
> > > >>>>>>>> relationship via CS?
> > > >>>>>>>>
> > > >>>>>>>> John (as individual)
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>> I am ok to make this change to the model. I would like
to
> > > >>>>>>> hear from
> > > >>>>>>>>>>> A one to one relationship - one communication session
> to
> > > one
> > > >>>>>>>>>>> The current metadata format allows all of these and I
> do
> > > not
> > > >>>> see

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 20 Apr 2011 16:48:54 +0200

> Sent: 20 April 2011 14:52
> To: Elwell, John; Paul Kyzivat (pkyzivat)
[JRE] I am having a hard time understanding the concept of a single Media Stream that survives across multiple CSs. For example, in the case of transfer, I would have thought new Media Streams would be created.

John

> > > > potentially be delivered over a different RS. This
> seems to imply
> > an
> > > RS
> > > > First, the idea is only half baked, so certainly feel
> free to take
> > > > shots
> > > > at it.
> > > >
> > > > >>>> Are you ok with retaining the below relation in
> the model, If
> > > > >>>> yes we can
> > > > >>>>> to correlate CSG to RS in SRS implementation.
> This issue is
> > > > >>>> raised by
> > > > >>>>> I explained his concern in "Partial updates and
> identifiers"
> > > mail
> > > > >>>>> thread.
> > > > >>>>>
> > > > >>>>> Also another issue: SRS may be interested in
> knowing list of
> > > > >>>> associated
> > > > >>>>> RS for a given CSG.
> > > > >>>>>
> > > > >>>>> Thanks
> > > > >>>>> Partha
> > > > >>>>>
> > > > >>>>> Subject: Re: [siprec] comments on
> > > > >>>>> relationship (via a CS). I was questioning
> whether we could
> > > > >>>> remove the
> > > > >>>>>>>>> To: Scott Orton; Elwell, John; Charles Eckel
> (eckelcu);
> > > > >>>>>>>>>>       In that case I would like to see the
> CS group be
> > > > >>>>>>> made optional.
> > > > >>>>>>>>>> that the CS point to the RS and have the CS
> group stand
> > > > >>>>>>>>> alone where it
> > > > >>>>>>>>>> To: Scott Orton; Charles Eckel (eckelcu);
> Parthasarathi
> > > > >>>>>>> R (partr);
> > > > >>>>>>>>>> [email-masked]
> > > > >>>>>>>>>>> session to the SRS. Looking at the
> requirements I see
> 3
> > > > >>>>>>>>>>>                               - one
> Recording session
> > > > >>>> made up of

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 20 Apr 2011 22:37:46 +0530

Hi John,

Please see inline [RAM]

> Sent: Wednesday, April 20, 2011 8:19 PM
> [JRE] I am having a hard time understanding the concept of a single
> Media Stream that survives across multiple CSs. For example, in the
> case of transfer, I would have thought new Media Streams would be
> created.

[RAM]
Here is my thoughts. 
1) There can be multiple RS per CS 
RS1 --- CS1--MS1
RS2----CS1--MS1
Examples are partial recording of CS (like recording parts of meeting,
redundant recording where there are multiple SRCs recording the same CS)

2) There can be same Media Stream across multiple CS. 
RS1--- CS1--- MS1
RS2--CS2--MS1
Examples are Multicast MoH played to multiple end points who are
potentially part of disjoint CSs where each CS is recorded as part of
separate RS.

Of course the above is arguable where the stream is same or different.
My view is since the UA (that supplies the Multicast MoH) and its media
are same across all CS, I think it can be represented as same MS block.

However it is still possible to treat each as separate stream in the
model, in which case the information that it is the same MS played by a
UA to different CS will be lost. I don't know if there is an interest to
capture this level of detail and if it is of any use to SRS.

Regards,
Ram

> > > > > >> metamodel to be modified to explicitly represent the
results
> > > > > >> of updates.
> > > > > >>>>     |   Group      |0..1  1..*|                 |   |
0..*
> > > > > >>>>> To: Paul Kyzivat (pkyzivat); [email-masked]; Ram Mohan
R
> > > > > >> (rmohanr);
> > > > > >>>>> I see the issue without direct link between RS and CSG.
> It
> > > may
> > > > be
> > > > > >>>> tough
> > > > > >>>>> relationship to a RS - the one they are delivered in.
> That
> > > > > >>>> allows the
> > > > > >>>>>> I am not sure this answers my question. In the model
you
> > > > > >>>> drew below,
> > > > > >>>>>>>> I am OK in principle, but I wonder whether there
> really
> > > > > >>>>>>> needs to be a
> [mailto:[email-masked]]
> > > > > >>>>>>>>>      | Recording Session (RS)
|---------------
> +
> > > > > >>>>>>>>>                 | 1..*             |1..*
> > > > > >>>>>>>>>                 | 0..*             |0..*
> > > > > >>>>>>>>>      | Session (CS) |----------| Session (CS)
|---
> > > > > >>>>>>>>>           1|                     | 0..*        |1..*
> > > > > >>>>>>>>>            |                     | 2..*        |0..*
> > > > > >>>>>>>>> between CS and RS remains same as what is between
CS-
> > > Group
> > > > > >>>>>>>>>> Rather than the CS pointing to the CS Group, I
would
> > > like
> > > > > >>>>>>>>>> customer being transferred to a second agent). I
> will
> > > > > >>>>>>> leave it to
> > > > > >>>>>>>>> those
> > > > > >>>>>>>>>> folks to add to this.
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> John (chair hat on)
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>>       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

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 21 Apr 2011 08:31:05 +0200

> Sent: 20 April 2011 18:08
> > > In any case, the point I like to high light here is, MS 
> block could
> > be
[JRE] Agreed. In this case MS1 is local to CS1.

> are same across all CS, I think it can be represented as same 
[JRE] I would argue these are different MSs. I agree that a medium such as music on hold might be sent, in synch, to multiple participants in multiple CSs. In that particular situation there might be some efficiency saving by calling it the same MS. However, I would suggest (although this is not my field of expertise) it would make life a lot harder for the SRS and its database. I would have expected to want to record a complete CS (all its participants and media streams)  as a complete recording, which could be deleted, copied, and so on without having to go looking for other objects that complete that recording and are shared with other recordings. For example, if you delete a recording, you would want to delete all its MSs, but not those used by other recordings, although you would need a garbage collection mechanism to delete an MS recording when it is no longer used by any CS recordings. Rather ugly. Making a MS local to a CS would simplify all this.

> capture this level of detail and if it is of any use to SRS.
[JRE] I assume what you are saying here is not that information will be lost, but that you will be unable to tell, without doing a comparison, whether two different MSs played to participants in two different CSs are identical or not for the particular time span that is common. I don't see where such a requirement would come from.

John (as individual)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 21 Apr 2011 18:54:39 +0530

John,

I could think of one usecase wherein MS is outside CS but within single
RS.  The usecase is multiple CS within single RS and MS. The usecase is
as follows:

B2BUA acts as SRC. A, B, C are participants within single B2BUA. A
creates single RS for a CSG.

1) A calls B through B2BUA. B2BUA creates RS towards SRS with CSG1, CS1,
MS1 (A's media stream), MS2 (B's media stream), Participant1 as A &
Participant2 as B.
2) B connects with C through B2BUA
3) B transfer the call of A & B to C using REFER, B2BUA converts REFER
to RE-INVITE towards A & C and A & C are connected. B2BUA updates RS
with CS2, Participant1 as A & participant2 as C, MS1(A's media stream),
MS2(C's media stream). There is no update on RS1, CSG1, MS1, MS2. MS2
will become MS2 with the new association and in terms of format, it will
associate with <send> tag.

In the above scenario, MS have life outside CS but it is within RS. The
unique id shall be within RS scope as mentioned in IETF-80 meeting. But
in another situation, MS is outside the scope of RS but within CS and
the usecase is Multiple RS for single CS, details are as follows:

A, B are pariticipants. A acts as SRC which tear down RS whenever hold
happens & creates new RS when resume happens.

1) A calls B. A creates RS1 towards SRS with CS1, MS1 (A's media
stream), MS2 (B's Media stream),Participant1 as A & Participant2 as B.
2) A put B on hold. A tear down RS1.
3) A resume B. A creates RS2 towards SRS with CS1, MS1 (A's media
stream), MS2 (B's Media stream),Participant1 as A & Participant2 as B

Here MS1 & MS2 needs to be same across RS to group media streams
correctly. Please let me know your opinion here.

Having said that MS have life outside a particular CS, I create separate
thread within unique how it shall be handled. 

Thanks
Partha

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Thursday, April 21, 2011 12:01 PM
To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
Cc: Parthasarathi R (partr); [email-masked]
Subject: Does MS have life outside a particular CS? (was RE: [siprec]
comments on draft-ram-siprec-metadata-04)

> > > (similar to the UUID that we have defined in format) as we cannot 
> > > depend on neither CS ID or RS ID.

> My view is since the UA (that supplies the Multicast MoH) and its 
> media are same across all CS, I think it can be represented as same MS

> block.
[JRE] I would argue these are different MSs. I agree that a medium such
as music on hold might be sent, in synch, to multiple participants in
multiple CSs. In that particular situation there might be some
efficiency saving by calling it the same MS. However, I would suggest
(although this is not my field of expertise) it would make life a lot
harder for the SRS and its database. I would have expected to want to
record a complete CS (all its participants and media streams)  as a
complete recording, which could be deleted, copied, and so on without
having to go looking for other objects that complete that recording and
are shared with other recordings. For example, if you delete a
recording, you would want to delete all its MSs, but not those used by
other recordings, although you would need a garbage collection mechanism
to delete an MS recording when it is no longer used by any CS
recordings. Rather ugly. Making a MS local to a CS would simplify all
this.

> model, in which case the information that it is the same MS played by 
> a UA to different CS will be lost. I don't know if there is an 
> interest to capture this level of detail and if it is of any use to 
> SRS.
[JRE] I assume what you are saying here is not that information will be
lost, but that you will be unable to tell, without doing a comparison,
whether two different MSs played to participants in two different CSs
are identical or not for the particular time span that is common. I
don't see where such a requirement would come from.

John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 21 Apr 2011 17:42:01 +0200

Partha, 

> From: Parthasarathi R (partr) [mailto:[email-masked]] 
> Sent: 21 April 2011 14:25
> To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
> Cc: [email-masked]
> Subject: RE: Does MS have life outside a particular CS? (was 
> RE: [siprec] comments on draft-ram-siprec-metadata-04)
> 
> John,
> 
[JRE] Why two media streams? Why not a single MS, with both A and B sending and receiving that MS?

> MS2(C's media stream).
[JRE] I would have expected, from my understanding of the metadata model, that the CS2 would have a new MS, with both A and B sending and receiving that new MS.

> There is no update on RS1, CSG1, MS1, MS2. MS2
> In the above scenario, MS have life outside CS but it is 
> within RS. 
[JRE] I can see how it COULD work like that, but it is not intuitive. To me, a new CS means the existing media stream stops and a new media stream is created.

> The
[JRE] Again, I would model this as a single MS, to which both A and B contribute.

> correctly. Please let me know your opinion here.
[JRE] Although I disagree that we have two Media Streams here, I do agree that the single Media Stream could be considered to survive the hold/resume, and hence survive from RS1 to RS2. But the MS is within the context of the same CS (CS1), and therefore this is outside the scope of this particular thread, which is asking whether an MS can have a life outside a particular CS. In this case the MS continues to be associated with the CS, so I don't have a problem with that.

So you have failed to convince me that an MS needs to have a life outside a CS.

John (as individual)

> > > > later point (e.g Recording of a company meeting where 
> you may want
> > to
> > redundant recording where there are multiple SRCs recording 
> the same 
> > CS)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 21 Apr 2011 21:50:03 +0530

John,

Please read inline.

Thanks
Partha 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Thursday, April 21, 2011 9:12 PM
To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul Kyzivat
(pkyzivat)
Cc: [email-masked]
Subject: RE: Does MS have life outside a particular CS? (was RE:
[siprec] comments on draft-ram-siprec-metadata-04)

Partha, 

> I could think of one usecase wherein MS is outside CS but within 
> single RS.  The usecase is multiple CS within single RS and MS. The 
> usecase is as follows:
> 
[JRE] Why two media streams? Why not a single MS, with both A and B
sending and receiving that MS?
<Partha> The media streams are un-mixed, MS1 points to RTP from A
through label attribute in MS1 SDP, MS2 points to RTP from B through
label attribute in MS2 SDP </Partha>

> with CS2, Participant1 as A & participant2 as C, MS1(A's media 
> stream), MS2(C's media stream).
[JRE] I would have expected, from my understanding of the metadata
model, that the CS2 would have a new MS, with both A and B sending and
receiving that new MS.

<Partha> It is not mandatory because participant information will be
updated and pointing to the same m-line in RS with same label attribute.
>From SRS perspective, the same media stream with the update in the
participant name only. Say MS2 is stored as one record with B as
participant for T0 to T1 timelines and C as participant from T1 to T2.
</Partha>

> There is no update on RS1, CSG1, MS1, MS2. MS2 will become MS2 with 
> the new association and in terms of format, it will associate with 
> <send> tag.
> 
> In the above scenario, MS have life outside CS but it is within RS.
[JRE] I can see how it COULD work like that, but it is not intuitive. 

<Partha> In SIPREC solution, UPDATE message with CS2(session element) ,
participant "C" element are received in SRS. This partial update of
UPDATE helps to make this scenario work. There is no change in term
stream element or RS SDP </Partha>

To me, a new CS means the existing media stream stops and a new media
stream is created.

<Partha> I'm interested knowing whether you propose that MS MUST stop in
case CS ends and the above scenario is outside the scope of SIPREC?
</Partha>

> The
> unique id shall be within RS scope as mentioned in IETF-80 meeting. 
> But in another situation, MS is outside the scope of RS but within CS 
> and the usecase is Multiple RS for single CS, details are as follows:
> 

> stream), MS2 (B's Media stream),Participant1 as A & Participant2 as B.
[JRE] Again, I would model this as a single MS, to which both A and B
contribute.
<Partha> Again, unmixed stream from A and B </Partha>
> correctly. Please let me know your opinion here.

[JRE] Although I disagree that we have two Media Streams here, I do
agree that the single Media Stream could be considered to survive the
hold/resume, and hence survive from RS1 to RS2. But the MS is within the
context of the same CS (CS1), and therefore this is outside the scope of
this particular thread, which is asking whether an MS can have a life
outside a particular CS. In this case the MS continues to be associated
with the CS, so I don't have a problem with that.

<Partha> I have 2nd example to illustrate MS have life outside RS.
</Partha>

So you have failed to convince me that an MS needs to have a life
outside a CS.

<Partha> In case the above scenario-1 way of recording is outside the
scope of SIPREC, I agree with you that MS does not have life outside a
particular CS </Partha> 

John (as individual)

> 
> Having said that MS have life outside a particular CS, I create 
> separate thread within unique how it shall be handled.
> 
> Thanks
> Partha
> 
> [JRE] I would argue these are different MSs. I agree that a medium 
> such as music on hold might be sent, in synch, to multiple 
> participants in multiple CSs. In that particular situation there might

> be some efficiency saving by calling it the same MS. However, I would 
> suggest (although this is not my field of expertise) it would make 
> life a lot harder for the SRS and its database. I would have expected 
> to want to record a complete CS (all its participants and media 
> streams)  as a complete recording, which could be deleted, copied, and

> so on without having to go looking for other objects that complete 
> that recording and are shared with other recordings. For example, if 
> you delete a recording, you would want to delete all its MSs, but not 
> those used by other recordings, although you would need a garbage 
> collection mechanism to delete an MS recording when it is no longer 
> used by any CS recordings. Rather ugly. Making a MS local to a CS 
> would simplify all this.
> 
> > 
> > 
> [JRE] I assume what you are saying here is not that information will 
> be lost, but that you will be unable to tell, without doing a 
> comparison, whether two different MSs played to participants in two 
> different CSs are identical or not for the particular time span that 
> is common. I don't see where such a requirement would come from.
> 
> John (as individual)
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 21 Apr 2011 22:18:14 +0200

> Sent: 21 April 2011 17:20
[JRE] Reading the metadata model again, I think it does seem to imply two Media Stream objects if the two directions for a 2-party call are sent unmixed (as two m-lines in the RS SDP), so I will concede that we have two Media Stream objects here. I had been thinking of a slightly different model, where there is one Media Stream, but associations between the Media Stream and Participants pointed to different m-lines in the RS SDP.

> participant for T0 to T1 timelines and C as participant from T1 to T2.
[JRE] Or alternatively it could be modelled that when a new CS starts there is a new Media Stream object, still pointing to the same m-line in the RS SDP. This would avoid the need for a Media Stream object to survive beyond the lifetime of a CS, and therefore allow local identification. While there is no CS in progress, the m-line would be disabled (port 0) and would not be referenced by any Media Stream.

> scope of SIPREC, I agree with you that MS does not have life outside a
[JRE] I assume you are talking about the call transfer case. I am not saying that use case is outside the scope of SIPREC. I am just saying that it can be modelled a different way, which may be advantageous in terms of the number of globally unique identifiers needed.

John (as individual)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 27 Apr 2011 12:00:28 +0530

John,

My intention is show the complexity in the metadata model in the current
form. Global unique id solves the issue but let us explore for better
optimized solution with more local unique id if any exists.

I have created another mail thread for adding the recording type
attribute which helps in most of the metadata blocks to have local
unique id rather than global unique id. Let us see how others visualize
that attribute. 

IMO, it may better to have globally unique id with the current metadata
model attributes. We may be able to add the normative statement that
"Media stream (MS) MUST be terminated when CS is terminated" in the
metadata but in reality, MS is within the scope of RS which is forced to
delete for no reason. These sort will be restrictive for few SRC
implementation. For eg: RS may created MS with RSVP which may not prefer
to terminate the resource during RS mid-session changes like CS changes
even though intermediate time with no media but the above normative
statement forces to break those SRC implementation.

Please read inline for more comments.

Thanks
Partha 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Friday, April 22, 2011 1:48 AM
To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul Kyzivat
(pkyzivat)
Cc: [email-masked]

> label attribute in MS2 SDP </Partha>
[JRE] Reading the metadata model again, I think it does seem to imply
two Media Stream objects if the two directions for a 2-party call are
sent unmixed (as two m-lines in the RS SDP), so I will concede that we
have two Media Stream objects here. I had been thinking of a slightly
different model, where there is one Media Stream, but associations
between the Media Stream and Participants pointed to different m-lines
in the RS SDP.

> participant for T0 to T1 timelines and C as participant from T1 to T2.
[JRE] Or alternatively it could be modelled that when a new CS starts
there is a new Media Stream object, still pointing to the same m-line in
the RS SDP.

<Partha> The purpose of unique-id will go for toss here. The same media
stream (MS) has unique id "id1" initially and later it will have "id2"
which will not be good for replay. Of course, MS life is always within
RS in this scenario but not within CS. So, Unique Id within RS will
serve the purpose </Partha>

 This would avoid the need for a Media Stream object to survive beyond
the lifetime of a CS, and therefore allow local identification. While
there is no CS in progress, the m-line would be disabled (port 0) and
would not be referenced by any Media Stream.

<Partha> RS m-line is not required to 0 because it shall change into
"a=inactive" as well. There is no change in the resource reservation in
both SRC and SRS </Partha>

> <Partha> I'm interested knowing whether you propose that MS MUST stop 
> in case CS ends and the above scenario is outside the scope of SIPREC?
> </Partha>
> 
> > The
> hold/resume, and hence survive from RS1 to RS2. But the MS is within 
> the context of the same CS (CS1), and therefore this is outside the 
> scope of this particular thread, which is asking whether an MS can 
> have a life outside a particular CS. In this case the MS continues to 
> be associated with the CS, so I don't have a problem with that.
> 

> particular CS </Partha>
[JRE] I assume you are talking about the call transfer case. I am not
saying that use case is outside the scope of SIPREC. I am just saying
that it can be modelled a different way, which may be advantageous in
terms of the number of globally unique identifiers needed.

John (as individual)

---

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

Partha,

You wrote:
"<Partha> The purpose of unique-id will go for toss here. The same media
stream (MS) has unique id "id1" initially and later it will have "id2"
which will not be good for replay. Of course, MS life is always within
RS in this scenario but not within CS. So, Unique Id within RS will
serve the purpose </Partha>"

As far as the recording, and therefore the playback, are concerned, these really are two media streams, belonging to two separate CSs. The fact that they happened to be delivered using the same m-line on the same RS is really irrelevant to what gets recorded and played back.

John (as individual)

> Sent: 27 April 2011 07:30
> > > 1) A calls B through B2BUA. B2BUA creates RS towards SRS
> with CSG1,
> > > CS1,

---

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

There seems to be some confusion in this discussion about what a MS is.

On one hand there is an m-line in the SDP of the RS, and a corresponding 
RTP stream.

On another hand there is an m-line in a CS and a corresponding RTP stream.

And then there is an MS described in the metadata conveyed over the RS.

And for both of the above, a single m-line might correspond to different 
RTP streams over time, due to renegotiating the address and/or port of 
the recipient, or by a different sender sending to the same port.

There is a mapping between one or more RTP streams in the CS (or 
multiple CSs?) and one or more RTP streams in the RS. The metadata 
hopefully describes that mapping.

But perhaps we don't have full agreement on what sorts of mappings are 
possible. Some that I think we allow are:
- one CS RTP stream to one RS RTP stream.
- multiple concurrent CS RTP streams mixed to one
   RS RTP stream
- multiple CS RTP streams sequentially mapped to the same
   RS RTP stream
...

Presumably the RTP streams associated with the RS end when the RS ends.
That does not necessarily mean that the media stream of a CS also ends 
at that time. It could be picked up again in a different RS by the same 
or different SRC.

	Thanks,
	Paul

On 4/27/2011 2:30 AM, Parthasarathi R (partr) wrote:
>>> MS1 (A's media stream), MS2 (B's media stream), Participant1 as A&
>>> Participant2 as B.
>> label attribute in MS2 SDP</Partha>
>>> 3) B transfer the call of A&  B to C using REFER, B2BUA
>> converts REFER
>>
>>> to RE-INVITE towards A&  C and A&  C are connected. B2BUA
>> updates RS
>>> with CS2, Participant1 as A&  participant2 as C, MS1(A's media
> serve the purpose</Partha>
>
> both SRC and SRS</Partha>
>
>>
>> stream element or RS SDP</Partha>
>>
>>> happens&  creates new RS when resume happens.
>>>
>>> stream), MS2 (B's Media stream),Participant1 as A&
>> Participant2 as B.
>> <Partha>  Again, unmixed stream from A and B</Partha>
>>> stream), MS2 (B's Media stream),Participant1 as A&
>> Participant2 as B
>>>
>>> Here MS1&  MS2 needs to be same across RS to group media streams
>> particular CS</Partha>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 27 Apr 2011 11:17:46 -0700

That helps clarify it for me. Thanks Paul.

Cheers,
Charles

> Sent: Wednesday, April 27, 2011 6:52 AM
> To: Parthasarathi R (partr)
> Cc: [email-masked]
> Subject: Re: [siprec] Does MS have life outside a particular CS? (was
RE: comments on draft-ram-
> siprec-metadata-04)
> >>> 1) A calls B through B2BUA. B2BUA creates RS towards SRS with
CSG1,

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 27 Apr 2011 14:01:37 -0700

> That does not necessarily mean that the media stream of a CS also ends
at
> that time. It could be picked up again in a different RS by the same
or
> different SRC.

IIUC, a single CS is only mapped to a single SRC. If we have a media
stream of a CS picked by another SRC, then it should be a different CS
but can be related to the same CS group.

Henry

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Paul Kyzivat
> Sent: April-27-11 9:52 AM
RE:
> On one hand there is an m-line in the SDP of the RS, and a
corresponding RTP
> stream.
> And for both of the above, a single m-line might correspond to
different RTP
> streams over time, due to renegotiating the address and/or port of the
> recipient, or by a different sender sending to the same port.
> 
multiple
> CSs?) and one or more RTP streams in the RS. The metadata hopefully
> describes that mapping.
> 
at
> that time. It could be picked up again in a different RS by the same
or
> different SRC.
> > My intention is show the complexity in the metadata model in the
> > current form. Global unique id solves the issue but let us explore
for
> > better optimized solution with more local unique id if any exists.
> >
> > unique id rather than global unique id. Let us see how others
> > visualize that attribute.
> >
> > IMO, it may better to have globally unique id with the current
> > metadata model attributes. We may be able to add the normative
> > statement that "Media stream (MS) MUST be terminated when CS is
> > terminated" in the metadata but in reality, MS is within the scope
of
> > RS which is forced to delete for no reason. These sort will be
> > restrictive for few SRC implementation. For eg: RS may created MS
with
> > RSVP which may not prefer to terminate the resource during RS
> > mid-session changes like CS changes even though intermediate time
with
> > no media but the above normative statement forces to break those SRC
> implementation.
> >
CSG1,
> > there is a new Media Stream object, still pointing to the same
m-line
> > in the RS SDP.
> >
> > <Partha>  The purpose of unique-id will go for toss here. The same
> > media stream (MS) has unique id "id1" initially and later it will
have "id2"
> >   This would avoid the need for a Media Stream object to survive
> > beyond the lifetime of a CS, and therefore allow local
identification.
> > While there is no CS in progress, the m-line would be disabled (port
> > 0) and would not be referenced by any Media Stream.
> >
> > "a=inactive" as well. There is no change in the resource reservation
> > in both SRC and SRS</Partha>
> >
> >>
> >> <Partha>  I'm interested knowing whether you propose that MS MUST
> >> stop in case CS ends and the above scenario is outside the scope of
> SIPREC?
> >> </Partha>
> >>
> >>> The
> >> <Partha>  In case the above scenario-1 way of recording is outside
> >> the scope of SIPREC, I agree with you that MS does not have life
> >> outside a
> >
> >> particular CS</Partha>

-------------------------------------------------------------------------------------------------------------------
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, 27 Apr 2011 18:55:31 -0400

> but can be related to the same CS group.

Two things:

It could be the same SRC but two different RSs. (Perhaps it drops the RS 
during a long pause, or because the SRS crashed and restarted and the 
SRC had to reconnect.)

If there are two different SRCs, and they happen to know it is the same 
CS (I'm not proposing *how* they know), it would be better to refer to 
the same CS.

I'm not saying we should require SRCs to do such things - only that a 
design that permits this is better than one that does not.

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 28 Apr 2011 08:19:03 -0700

I agree it would be out of scope for two different SRCs to refer to the
same CS. The metadata model currently does not seem to prevent such
scenario, as long as there is a way to identify the same CS across
different SRC. The CS Identifier currently states that it is a unique
identifier, and I don't think we should mandate that to be globally
unique across multiple SRCs like the CSG identifier.

Regards,
Henry

> Sent: Wednesday, April 27, 2011 6:56 PM
> To: Henry Lum
> RE: comments on draft-ram-siprec-metadata-04)
> 
> 
> 
> >>> sent unmixed (as two m-lines in the RS SDP), so I will concede
that
> > we
> >>>> model, that the CS2 would have a new MS, with both A and B
sending
> >>>> and
> >>>
> >>>> receiving that new MS.
> >>>>
> >>>> <Partha>   It is not mandatory because participant information
> will
> > be
> >>>> participant for T0 to T1 timelines and C as participant from T1
to
> > T2.
> >>>> [JRE] Again, I would model this as a single MS, to which both A
> and
> > B
> >>>> contribute.
> >>>> have a life outside a particular CS. In this case the MS
continues
> >>>>> is common. I don't see where such a requirement would come from.
---------------------------------------------------------------------
> ----------------------------------------------
> > 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: Thu, 28 Apr 2011 11:42:37 -0400

> unique across multiple SRCs like the CSG identifier.

Once you decide to have a "unique" id assigned by the SRC, its very 
little harder to make it globally unique rather than simply unique to an 
RS or an SRC. And there is very little benefit to the SRS to narrowing 
the scope either.

We only get to make this decision once. Its really hard to retrofit 
later to extend the scope. IMO all of the IDs should be globally unique. 
That gives us a lot more flexibility in how this evolves in the future.

How we convey the id (as a URL, or something else) is another matter, 
and much less of a big deal. If the concern is how many bytes it 
consumes in the message then we can work on that.

In any case, while proposed mechanisms must satisfy the requirements, 
AFAIK there is no reason that a proposed mechanism cannot go beyond the 
stated requirements. If there are multiple proposed mechanisms, and one 
has ids more global than another, then people can decide which they like 
better. But the choice is only among what is proposed. So if there are 
two philosophies in this regard, then maybe there had better be two 
proposed mechanisms.

Or, I guess someone could propose a new requirement: "Unique IDs in the 
mechanism MUST NOT be globally scoped - they MUST be locally scoped to 
an RS and duplicated across RSs". (I won't support that one.)

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Thu, 28 Apr 2011 18:57:47 +0300

I agree that we should have all IDs to be globally unique.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Thursday, April 28, 2011 6:43 PM
To: Henry Lum
Cc: [email-masked]
Subject: Re: [siprec] Does MS have life outside a particular CS? (was RE: comments on draft-ram-siprec-metadata-04)

On 4/28/2011 11:19 AM, Henry Lum wrote:
> I agree it would be out of scope for two different SRCs to refer to
> the same CS. The metadata model currently does not seem to prevent
> such scenario, as long as there is a way to identify the same CS
> across different SRC. The CS Identifier currently states that it is a
> unique identifier, and I don't think we should mandate that to be
> globally unique across multiple SRCs like the CSG identifier.

Once you decide to have a "unique" id assigned by the SRC, its very little harder to make it globally unique rather than simply unique to an RS or an SRC. And there is very little benefit to the SRS to narrowing the scope either.

We only get to make this decision once. Its really hard to retrofit later to extend the scope. IMO all of the IDs should be globally unique.
That gives us a lot more flexibility in how this evolves in the future.

How we convey the id (as a URL, or something else) is another matter, and much less of a big deal. If the concern is how many bytes it consumes in the message then we can work on that.

In any case, while proposed mechanisms must satisfy the requirements, AFAIK there is no reason that a proposed mechanism cannot go beyond the stated requirements. If there are multiple proposed mechanisms, and one has ids more global than another, then people can decide which they like better. But the choice is only among what is proposed. So if there are two philosophies in this regard, then maybe there had better be two proposed mechanisms.

Or, I guess someone could propose a new requirement: "Unique IDs in the mechanism MUST NOT be globally scoped - they MUST be locally scoped to an RS and duplicated across RSs". (I won't support that one.)

        Thanks,
        Paul

>> It could be the same SRC but two different RSs. (Perhaps it drops the
>> RS during a long pause, or because the SRS crashed and restarted and
>> the SRC had to reconnect.)
>>
>> CS (I'm not proposing *how* they know), it would be better to refer
>> to the same CS.
>>
>> 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.
>>>
>>>
>
>
> ----------------------------------------------------------------------
> ---------------------------------------------