Subject: [siprec] Partial updates and identifiers

From: "Elwell, John" <[email-masked]>
Date: Wed, 6 Apr 2011 16:24:28 +0200

Much of the discussion on draft-ram-metadata-format in Prague concerned the mechanism for performing partial updates and the use of identifiers. The draft permits partial updates by allowing individual objects (e.g., CS, participant, media stream) to be sent with updated content, without having to send again other objects that have not changed. So, for example, in a large conference, it would be possible to add or modify an individual participant object without having to send all the other participant objects again. I do not recall any opposition to this basic principle.

However, to achieve this, every object requires an identifier, and it was asserted that these identifiers need to be globally unique for all time. Although this might be efficient for updating an individual object, when sending many objects (e.g., at the start of a CS or when refreshing the entire metadata), this can make the metadata very bulky. It depends, of course, on the format of the identifiers, and it was stated that there could be alternatives to UUID. Nevertheless, some people had concerns. These concerns also extended to the impact on the database where metadata is stored, since it might not be feasible to convert to a database-friendly mechanism for linking objects together.

One alternative proposal during the meeting was to have a single unique identifier at the top level (for the RS) and use local identifiers for other objects. Thus when updating a single object, it would be necessary to include the top level identifier as well as one or more local identifiers. However, there were also concerns this might not fulfil actual or perceived future requirements.

Please continue discussion on this.

John (as chair)

---

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

John,

For the moment we have proposed that the ids be conveyed in the form of 
URIs that are globally unique, and specifically that they be UUID URNs. 
There is no dependency on the particular form of the URI, but specifying 
they must be UUID URNs makes it possible to perform some internal 
optimizations for storage.

The UUID URN is a pretty inefficient encoding. A UUID can be expressed 
in 32 bits, so we could consider retaining UUIDs but alter the encoding 
if its really an issue. However I am far from convinced that the size of 
the IDs is going to be a major issue in the overall size of messages, so 
I think its probably premature to worry about it.

Because the ids can be expressed in 32 bits, the SRC and SRS can store 
them internally that way, thus reducing the runtime cost of maintaining 
the data.

The use of unique ids is a significant part of the overall approach to 
formatting updates. If somebody has a different concept in mind it could 
be useful to have an alternative proposal for the format. If we had two 
worked out approaches we could compare the tradeoffs in each.

	Thanks,
	Paul

On 4/6/2011 10:24 AM, Elwell, John wrote:
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

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

John,

Sorry for the lengthy mail but it contains lot of analysis and reasoning
for this id approach. 

Adding to Paul's point, I wish to give more background and reason for
these globally unique id. Initially I had the impression that the single
unique id (RS dialog-id) in the recording (session level) and some
relevant natural id for the rest of the element will serve the purpose.
There are usecases where this assumption fails. Even I have thought of
using "xml:id" instead of URN UUID to avoid long string but xml:id may
not end up with unique value always. Our analysis for URN UUID for each
level is as follows and please provide your input in case id shall be
tweaked:

1) Recording block: The reason for globally unique id is that multiple
SRC with same id to single SRS. 

Topology:

SRC1         SRC2
 |            |
 |            ----(RS1-ID1)-----SRS1
 |
  ---(RS2-ID1)------------------SRS1

In the above topology, it is possible for ID1 is generated by both SRC1
and SRC2 at the same time. 

2) group (CSG) block: Grouping mechanism (Hadriel session-id, Paul Jones
Session-UUID) is outside the scope of SIPREC. URN UUID abstracts the
exact mechanism to SRS and provides the information only about the group
of CS from SRC perspective. It possible that group may span across
multiple RS and It is up to SRS to group and view as single recording.
Here, the single level id in the top will fail. The counter argument is
to force the single RS having complete CSG but it*may not* be possible
in SRC implementation. Here, xml:id will not serve the purpose

3) session (CS) block: At the immediate look, session falls exactly
under recording block. Use case 3 of draft-ietf-siprec-req-09
illustrates where CS span across multiple RS. This requirement calls for
unique id in session by which these session shall be viewed as single CS
even though there is no group exists among them. IMO, in case session
should not have globally unique id, then it is preferred to remove
usecase 3 in the requirement.

4) participant block: It needs some id which may be AOR but AOR is not
unique. IMO, xml:id may serve the purpose with session unique id. The
trick exists for participant who are not associated with CS. We shall
discuss and fine tune if required.

5) stream block: Label attribute shall be used as unique value but RFC
4574 does not mandate label attribute has to be unique across the dialog
or CS and so, it may possible to change within RS and no normative
statement to stop this implementation. IMO, xml:id may serve the purpose
with session unique id. Here as well, We shall discuss and fine tune if
required.

6) extensiondata block: This is tracked in the separate mail thread
whether unique id is required or not. Let us close this as part of that
mail thread.

Including explicitly Hadriel, Peter, Joe in this mail thread as they
have different view on this ID mechanism. 

I had offline discussion with Hadriel in Prague after SIPREC meeting and
my understanding of his major concern is that how SRS will be able to
design the database in case partial update does not have recording (top)
id information. I'll put more thought processing to close Hadriel
concern of how top id has to be tracked in case partial update by which
SRS implementation will be simplified in terms of aggregation
maintenance.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat (pkyzivat)
Sent: Thursday, April 07, 2011 12:33 AM
To: [email-masked]
Subject: Re: [siprec] Partial updates and identifiers

John,

	Thanks,
	Paul

On 4/6/2011 10:24 AM, Elwell, John wrote:
> Much of the discussion on draft-ram-metadata-format in Prague
concerned the mechanism for performing partial updates and the use of
identifiers. The draft permits partial updates by allowing individual
objects (e.g., CS, participant, media stream) to be sent with updated
content, without having to send again other objects that have not
changed. So, for example, in a large conference, it would be possible to
add or modify an individual participant object without having to send
all the other participant objects again. I do not recall any opposition
to this basic principle.
>
> However, to achieve this, every object requires an identifier, and it
was asserted that these identifiers need to be globally unique for all
time. Although this might be efficient for updating an individual
object, when sending many objects (e.g., at the start of a CS or when
refreshing the entire metadata), this can make the metadata very bulky.
It depends, of course, on the format of the identifiers, and it was
stated that there could be alternatives to UUID. Nevertheless, some
people had concerns. These concerns also extended to the impact on the
database where metadata is stored, since it might not be feasible to
convert to a database-friendly mechanism for linking objects together.
>
> One alternative proposal during the meeting was to have a single
unique identifier at the top level (for the RS) and use local
identifiers for other objects. Thus when updating a single object, it
would be necessary to include the top level identifier as well as one or
more local identifiers. However, there were also concerns this might not
fulfil actual or perceived future requirements.

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 8 Apr 2011 18:05:30 +0200

Focusing just on participant and stream for the time being, do these need to be unique across multiple CSs or not?

John 

> From: Parthasarathi R (partr) [mailto:[email-masked]] 
> Sent: 07 April 2011 10:51
> To: Paul Kyzivat (pkyzivat); [email-masked]; Elwell, John
> Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe 
> Hildebrand (jhildebr)
> Subject: RE: [siprec] Partial updates and identifiers
> 
> John,
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 11 Apr 2011 13:04:33 +0530

John,

As I mentioned below, stream block will be unique within CS, (not
required to be unique across multiple CS) and so, xml:id or enhancing
the normative statement of RFC 4574 label attribute to be unique within
CS will serve the purpose. I'm fine with any of the above mentioned id.
Please note that RFC 4574 "label" attribute is the nature data for RS
dialog.

In case participant within CS, xml:id will serve the purpose but we need
to get more clarity about participants who are not part of CS but within
RS. Because CS may span across different RS how about the participant
who are not part of CS? Ex: One of the user in the conference acts as
SRC, fetch participant info using conferene package and new RS is
created during initial conference creation and hold&resume of a user
within CS.

Thanks
Partha

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Friday, April 08, 2011 9:36 PM
To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); [email-masked]
Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand
(jhildebr)

Focusing just on participant and stream for the time being, do these
need to be unique across multiple CSs or not?

John 

> Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand 
> (jhildebr)
> Sorry for the lengthy mail but it contains lot of analysis and 
> reasoning for this id approach.
> 
> these globally unique id. Initially I had the impression that the 
> single unique id (RS dialog-id) in the recording (session level) and 
> some relevant natural id for the rest of the element will serve the 
> purpose.

> not end up with unique value always. Our analysis for URN UUID for 
> each level is as follows and please provide your input in case id 
> shall be
> tweaked:
> 

> In the above topology, it is possible for ID1 is generated by both 
> SRC1 and SRC2 at the same time.
> 
> exact mechanism to SRS and provides the information only about the 
> group of CS from SRC perspective. It possible that group may span 
> across multiple RS and It is up to SRS to group and view as single 
> recording.
> Here, the single level id in the top will fail. The counter argument 
> is to force the single RS having complete CSG but it*may not* be 
> possible in SRC implementation. Here, xml:id will not serve the 
> purpose
> 
> illustrates where CS span across multiple RS. This requirement calls 
> for unique id in session by which these session shall be viewed as 
> single CS even though there is no group exists among them. IMO, in 
> case session should not have globally unique id, then it is preferred 
> to remove usecase 3 in the requirement.
> 

> 4574 does not mandate label attribute has to be unique across the 
> dialog or CS and so, it may possible to change within RS and no 
> normative statement to stop this implementation. IMO, xml:id may serve

> the purpose with session unique id. Here as well, We shall discuss and

> fine tune if required.
> whether unique id is required or not. Let us close this as part of 
> that mail thread.
> 
> I had offline discussion with Hadriel in Prague after SIPREC meeting 
> and my understanding of his major concern is that how SRS will be able

> to design the database in case partial update does not have recording 
> (top) id information. I'll put more thought processing to close 
> Hadriel concern of how top id has to be tracked in case partial update

> by which SRS implementation will be simplified in terms of aggregation

> [mailto:[email-masked]] On Behalf Of Paul Kyzivat (pkyzivat)
> For the moment we have proposed that the ids be conveyed in the form 
> of URIs that are globally unique, and specifically that they be UUID 
> URNs.
> There is no dependency on the particular form of the URI, but 
> specifying they must be UUID URNs makes it possible to perform some 
> internal optimizations for storage.
> 

> in 32 bits, so we could consider retaining UUIDs but alter the 
> encoding if its really an issue. However I am far from convinced that 
> the size of the IDs is going to be a major issue in the overall size 
> of messages, so I think its probably premature to worry about it.
> 

> them internally that way, thus reducing the runtime cost of 
> maintaining the data.
> 

> formatting updates. If somebody has a different concept in mind it 
> could be useful to have an alternative proposal for the format. If we 
> had two worked out approaches we could compare the tradeoffs in each.
> 
> 	Thanks,
> 	Paul
> 
> changed. So, for example, in a large conference, it would be possible 
> to add or modify an individual participant object without having to 
> send all the other participant objects again. I do not recall any 
> opposition to this basic principle.
> >

> would be necessary to include the top level identifier as well as one 
> or more local identifiers. However, there were also concerns this 
> might not fulfil actual or perceived future requirements.
> >

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 11 Apr 2011 10:40:53 +0200

> Sent: 11 April 2011 08:35
> To: Elwell, John; Paul Kyzivat (pkyzivat); [email-masked]
> RS. 
[JRE] If I understand the figure in section 3 of metadata-04 correctly, a Participant can have a relationship with a CS, but no direct relationship with an RS. So a participant that does not have a relationship with a CS is left completely unattached, unless it has a relationship with a Media Stream (which always has a relationship with a CS). So to summarize:
- a Participant can have a direct relationship with a CS; or
- a Participant can have an indirect relationship with a CS (via a Media Stream);
- a Participant can have no relationship with a CS, and therefore no relationship with an RS.
Do we really need this last case?

> Because CS may span across different RS how about the participant
> who are not part of CS?
[JRE] I don't understand the words "Because CS may span across different RS", because in the rest of the sentence you are talking about a Participant that is not part of a CS.

> Ex: One of the user in the conference acts as
[JRE] I am not sure what you are trying to say here. I would consider a user whose identity is obtained via a conference event package as being part of the CS. That user is sending/receiving Media Streams that are part of a CS, or if it isn't sending/receiving Media Streams, what is the relevance of that Participant? Why would we create a new RS for such a participant? 

John (as individual)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 11 Apr 2011 14:59:29 +0530

John,

Please read inline.

Thanks
Partha 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Monday, April 11, 2011 2:11 PM
To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); [email-masked]
Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand
(jhildebr)

> the normative statement of RFC 4574 label attribute to be unique 
> within CS will serve the purpose. I'm fine with any of the above 
> mentioned id.
> In case participant within CS, xml:id will serve the purpose but we 
> need to get more clarity about participants who are not part of CS but

> within RS.
[JRE] If I understand the figure in section 3 of metadata-04 correctly,
a Participant can have a relationship with a CS, but no direct
relationship with an RS.

<Partha> Sorry, I mixed up my statement with the latest update of making
CSG optional. As per Sec 3 of metadata-04, participant has direct
relationship with CSG in case CS is left completely unattached. In case
CSG is optional, then participant will have direct relationship with RS
in case there is no relationship between CS and participant. </Partha> 

 So a participant that does not have a relationship with a CS is left
completely unattached, unless it has a relationship with a Media Stream
(which always has a relationship with a CS). So to summarize:
- a Participant can have a direct relationship with a CS; or
- a Participant can have an indirect relationship with a CS (via a Media
Stream);
<Partha> agreed </Partha>
- a Participant can have no relationship with a CS, and therefore no
relationship with an RS.
Do we really need this last case?

<Partha> I'm happy if the last case is not required because it simplify
the solution and there is no need of unique id for participant. But SRS
implementers may prefer to have relationship with participant and RS. I
wish more opinion before taking decision whether to remove the last case
</Partha>

> Because CS may span across different RS how about the participant who 
> are not part of CS?
[JRE] I don't understand the words "Because CS may span across different
RS", because in the rest of the sentence you are talking about a
Participant that is not part of a CS.

> Ex: One of the user in the conference acts as SRC, fetch participant 
> info using conferene package and new RS is created during initial 
> conference creation and hold&resume of a user within CS.
[JRE] I am not sure what you are trying to say here. I would consider a
user whose identity is obtained via a conference event package as being
part of the CS.

<Partha> I'm trying to give the example where participant is not
associated with CS directly but related to CSG (/RS). This scenario was
considered as a blocking in -03 version of metadata. I'm not arguing to
have this scenario but it is major concern for few folks.

CS is between focus and UA, UA acts as SRC, UA receives the participant
info via conference event package but those participants are not related
in CS directly (and only focus is related) but they contributed for the
mixed stream. </Partha>

 That user is sending/receiving Media Streams that are part of a CS, or
if it isn't sending/receiving Media Streams, what is the relevance of
that Participant?

<Partha> Mixed media stream from focus to UA belongs to the Conference
event package participants. There participant are not directly involved
as part of CS. </Partha> 
 Why would we create a new RS for such a participant? 
<Partha> RS is not created for participant. Multiple RS shall be created
the same CS during the different time frame as shown below

           <-------------------CS1------------->
             <---RS1-->  <---RS2------> 

CS1 is between UA (SRC) and focus whereas RS1, RS2 is between UA (SRC)
and SRS. Here tangling (conference event package) participant has to be
grouped together in RS1, RS2 by some means through given metadata. The
question whether this corner has to be solved ? </Partha>

John (as individual)

---

From: Leon Portman <[email-masked]>
Date: Mon, 11 Apr 2011 16:45:29 +0300

Hello

As I  have mentioned in another thread, we also have a use case of persistent recording of specific participant (between login/logout events for example),  where participant will not have media, CS or CSG and will be connected directly to RS.

We will have m-lines with label in RS SDP and SRC will update SRS with metadata with CS and media streams that point to these labels per CS.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
Sent: Monday, April 11, 2011 12:29 PM
To: Elwell, John; Paul Kyzivat (pkyzivat); [email-masked]
Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); Hadriel Kaplan
Subject: Re: [siprec] Partial updates and identifiers

John,

Please read inline.

Thanks
Partha 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: Monday, April 11, 2011 2:11 PM
To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); [email-masked]
Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand
(jhildebr)

> within RS.
[JRE] If I understand the figure in section 3 of metadata-04 correctly, a Participant can have a relationship with a CS, but no direct relationship with an RS.

<Partha> Sorry, I mixed up my statement with the latest update of making CSG optional. As per Sec 3 of metadata-04, participant has direct relationship with CSG in case CS is left completely unattached. In case CSG is optional, then participant will have direct relationship with RS in case there is no relationship between CS and participant. </Partha> 

 So a participant that does not have a relationship with a CS is left completely unattached, unless it has a relationship with a Media Stream (which always has a relationship with a CS). So to summarize:
- a Participant can have a direct relationship with a CS; or
- a Participant can have an indirect relationship with a CS (via a Media Stream); <Partha> agreed </Partha>
- a Participant can have no relationship with a CS, and therefore no relationship with an RS.
Do we really need this last case?

<Partha> I'm happy if the last case is not required because it simplify the solution and there is no need of unique id for participant. But SRS implementers may prefer to have relationship with participant and RS. I wish more opinion before taking decision whether to remove the last case </Partha>

> conference creation and hold&resume of a user within CS.
[JRE] I am not sure what you are trying to say here. I would consider a user whose identity is obtained via a conference event package as being part of the CS.

<Partha> I'm trying to give the example where participant is not associated with CS directly but related to CSG (/RS). This scenario was considered as a blocking in -03 version of metadata. I'm not arguing to have this scenario but it is major concern for few folks.

CS is between focus and UA, UA acts as SRC, UA receives the participant info via conference event package but those participants are not related in CS directly (and only focus is related) but they contributed for the mixed stream. </Partha>

 That user is sending/receiving Media Streams that are part of a CS, or if it isn't sending/receiving Media Streams, what is the relevance of that Participant?

<Partha> Mixed media stream from focus to UA belongs to the Conference event package participants. There participant are not directly involved as part of CS. </Partha>  Why would we create a new RS for such a participant? 
<Partha> RS is not created for participant. Multiple RS shall be created the same CS during the different time frame as shown below

CS1 is between UA (SRC) and focus whereas RS1, RS2 is between UA (SRC) and SRS. Here tangling (conference event package) participant has to be grouped together in RS1, RS2 by some means through given metadata. The question whether this corner has to be solved ? </Partha>

John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 11 Apr 2011 18:45:30 +0200

Partha,

Thanks for reminding me - I now recall the discussion some weeks/months ago about the participants obtained from the conference event package. I was never particularly comfortable with the fact these were not considered part of the CS. While that might be correct if we consider the CS to be the SIP dialog between the SRC and the conference focus, taking a broader view of CS those participants behind the focus could be considered part of the CS. I don't particularly want to open up the old discussion if people are happy with what we have, but something doesn't seem quite right to me.

For example, if these "participants" are not considered part of the CS, and if we don't have specific information about their involvement in media streams, do they really merit being considered Participant objects?

In other words, two possible approaches are:

1) The CS extends only as far as the focus / mixer. The focus/mixer is a "Participant" and the users behind the focus are not separate Participants but are just additional data associated with the focus/mixer Participant. The only Media Streams we are concerned with are between the mixer and the SRC.

2) The CS extends beyond the focus/mixer to users learned via the conference event package, each of those users is a separate Participant object, and we are concerned with Media Stream objects that those participants send and receive. I am not sure how feasible this approach is, because I am not sure that the SRC can obtain enough information about media streams at users behind the focus/mixer.

It seems the present solution is somewhere between the two, which is why I am uncomfortable.

Regards,

John (as individual)

> Sent: 11 April 2011 10:29
> > > 2) group (CSG) block: Grouping mechanism (Hadriel
> session-id, Paul
> > > Jones

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 11 Apr 2011 18:45:40 +0200

Yes, I can see the case for an RS without a CS, but I think any participant object should be associated with a CS (so when there is no CS there is no participant). So even for the persistent recording case, we can keep the RS alive, but why do we need to keep a participant object alive?

John (as individual)

> From: Leon Portman [mailto:[email-masked]]
> Sent: 11 April 2011 14:45
> To: Parthasarathi R (partr); Elwell, John; Paul Kyzivat
> (pkyzivat); [email-masked]
> As I  have mentioned in another thread, we also have a use
> case of persistent recording of specific participant (between
> login/logout events for example),  where participant will not
> have media, CS or CSG and will be connected directly to RS.
>
> We will have m-lines with label in RS SDP and SRC will update
> SRS with metadata with CS and media streams that point to
> these labels per CS.
>
> Leon
>
> [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
> [JRE] If I understand the figure in section 3 of metadata-04
> correctly, a Participant can have a relationship with a CS,
> but no direct relationship with an RS.
>
> <Partha> Sorry, I mixed up my statement with the latest
> update of making CSG optional. As per Sec 3 of metadata-04,
> participant has direct relationship with CSG in case CS is
> left completely unattached. In case CSG is optional, then
> participant will have direct relationship with RS in case
> there is no relationship between CS and participant. </Partha>
>
>  So a participant that does not have a relationship with a CS
> is left completely unattached, unless it has a relationship
> with a Media Stream (which always has a relationship with a
> CS). So to summarize:
> - a Participant can have an indirect relationship with a CS
> (via a Media Stream); <Partha> agreed </Partha>
> <Partha> I'm happy if the last case is not required because
> it simplify the solution and there is no need of unique id
> for participant. But SRS implementers may prefer to have
> relationship with participant and RS. I wish more opinion
> before taking decision whether to remove the last case </Partha>
>
> [JRE] I don't understand the words "Because CS may span
> across different RS", because in the rest of the sentence you
> are talking about a Participant that is not part of a CS.
>
> [JRE] I am not sure what you are trying to say here. I would
> consider a user whose identity is obtained via a conference
> event package as being part of the CS.
>
> <Partha> I'm trying to give the example where participant is
> not associated with CS directly but related to CSG (/RS).
> This scenario was considered as a blocking in -03 version of
> metadata. I'm not arguing to have this scenario but it is
> major concern for few folks.
>
> CS is between focus and UA, UA acts as SRC, UA receives the
> participant info via conference event package but those
> participants are not related in CS directly (and only focus
> is related) but they contributed for the mixed stream. </Partha>
>
>  That user is sending/receiving Media Streams that are part
> of a CS, or if it isn't sending/receiving Media Streams, what
> is the relevance of that Participant?
>
> <Partha> Mixed media stream from focus to UA belongs to the
> Conference event package participants. There participant are
> not directly involved as part of CS. </Partha>  Why would we
> create a new RS for such a participant?
> <Partha> RS is not created for participant. Multiple RS shall
> be created the same CS during the different time frame as shown below
>
> CS1 is between UA (SRC) and focus whereas RS1, RS2 is between
> UA (SRC) and SRS. Here tangling (conference event package)
> participant has to be grouped together in RS1, RS2 by some
> means through given metadata. The question whether this
> corner has to be solved ? </Partha>
>
> John (as individual)
>
>
>
> >
> > Thanks
> > Partha
> >

---

From: "Henry Lum" <[email-masked]>
Date: Mon, 11 Apr 2011 13:32:10 -0700

I am having trouble understanding why we would have a participant with
no association to a CS. I get the impression that we call the
terminology a participant because it is a participant of a CS. For the
use case of agent login/logout, would this belong to extension data of a
recording session rather than modeling it as a participant with/without
a CS since there is no call anyways?

Henry

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Elwell, John
> Sent: Monday, April 11, 2011 12:46 PM
> To: Leon Portman; Parthasarathi R (partr); Paul Kyzivat (pkyzivat);
> [email-masked]
> Cc: Peter Saint-Andre (psaintan); Hadriel Kaplan; Joe
> Hildebrand(jhildebr)
> Yes, I can see the case for an RS without a CS, but I think any
> participant object should be associated with a CS (so when there is no
> CS there is no participant). So even for the persistent recording
case,
> we can keep the RS alive, but why do we need to keep a participant
> object alive?
> 
> John (as individual)
> 

-------------------------------------------------------------------------------------------------------------------
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: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 11 Apr 2011 15:52:45 -0700

Hi John,

I have attached the last e-mail I have from the thread in which I first
raised this issue. Unfortunately, I do not have the e-mail with the
ultimate agreement, but maybe someone else does or this will help prompt
some memories.

Cheers,
Charles

Behalf Of Elwell, John
> Sent: Monday, April 11, 2011 9:46 AM
> Thanks for reminding me - I now recall the discussion some
weeks/months ago about the participants
> obtained from the conference event package. I was never particularly
comfortable with the fact these
> were not considered part of the CS. While that might be correct if we
consider the CS to be the SIP
> dialog between the SRC and the conference focus, taking a broader view
of CS those participants behind
> the focus could be considered part of the CS. I don't particularly
want to open up the old discussion
> if people are happy with what we have, but something doesn't seem
quite right to me.
> 
> For example, if these "participants" are not considered part of the
CS, and if we don't have specific
> information about their involvement in media streams, do they really
merit being considered
> Participant objects?
> 1) The CS extends only as far as the focus / mixer. The focus/mixer is
a "Participant" and the users
> behind the focus are not separate Participants but are just additional
data associated with the
> focus/mixer Participant. The only Media Streams we are concerned with
are between the mixer and the
> SRC.
> 
> 2) The CS extends beyond the focus/mixer to users learned via the
conference event package, each of
> those users is a separate Participant object, and we are concerned
with Media Stream objects that
> those participants send and receive. I am not sure how feasible this
approach is, because I am not
> sure that the SRC can obtain enough information about media streams at
users behind the focus/mixer.
> > correctly,
> > update of making
> > (via a Media
> > it simplify
> > across different
> > consider a
> > participant
> > of a CS, or
Conference
> > be created

Subject: RE: [siprec] metadata model for participant that is not part of CS
From: "Charles Eckel (eckelcu)" <[email-masked]>
To: "Ram Mohan R (rmohanr)" <[email-masked]>, "Elwell, John" <[email-masked]>, <[email-masked]>
Date: Thu, 27 Jan 2011 11:07:46 -0700

Hi Ram,

If all CS participants are required to support the conference event
package and provide sufficient info about each non-CS participant in
order to be allowed to bring them in, then I am ok with it. My concern
is that the SRS will not be able to get sufficient info about non-CS
participant in all cases. In such cases, it seems to me the media
streams should be associated with the CS participant responsible for the
non-CS participant, rather than allowing media from incompletely
described non-CS participants to exist on its own.
You mention the case of the conference focus, in which everything may be
fine, but there are other cases, as mentioned by Jon, for which this may
not be the case.

Cheers,
Charles

> From: Ram Mohan R (rmohanr)
> Sent: Thursday, January 27, 2011 4:35 AM
> To: Elwell, John; Charles Eckel (eckelcu); [email-masked]
> Subject: RE: [siprec] metadata model for participant that is not part
of CS
> 
> Hi Charles/John,
> 
> In the current model, a media stream is always associated with at
least one participant. Here is the
> snippet of the associations between CS and Participant and Participant
and Media Streams taken from
> the draft
> https://datatracker.ietf.org/doc/draft-ram-siprec-metadata
> 
> Section 4.3.2 has the associations between CS and Participant
> Section 4.4.2 has the associations between media stream and
participant
> 
> The current model allows participants who are not part of CS to be
part of the model.
> A example of such a case is:
> - participants in a premixed media stream.  The SRC may have knowledge
of such Participants, yet not
> have any signaling relationship with them.  This might arise if one
participant in CS is a conf focus.
> 
> In those case, if the metadata for non-CS participants is incomplete,
the SRC can use other mechanisms
> like subscribing to conference event package to retrieve the
information about non-CS participants.
> 
> To summarize the model allows representing of non-CS participants who
contribute media to CS.
> 
> Charles,
> The use case section is at the end of this document
> https://datatracker.ietf.org/doc/draft-ram-siprec-metadata
> 
> Please note the case where Focus is acting as SRC is simpler as all
participants of conference which
> are connected to focus will in turn become participants of CS too.
> 
> Thanks,
> Ram
> 
> > Sent: Thursday, January 27, 2011 1:09 PM
> > To: Charles Eckel (eckelcu); [email-masked]
> > Subject: Re: [siprec] metadata model for participant that is not
part
> > of CS
> >
> > I am starting to see Charles's point. For a participant behind a
> > bridge, you don't really know what media he is contributing or what
> > media he is receiving. All you know for certain is that the bridge
is a
> > participant. Perhaps we could assign multiple user identities to a
> > bridge participant, thereby reflecting users behind the bridge that
may
> > or may not be contributing to the media the bridge sends and may or
may
> > not be recipients of media the bridge receives.
> >
> > Note that the model when the SRC is at the bridge, rather than
outside
> > the bridge, is quite different. Also the model where the bridge is
> > switching, rather than mixing, might be different.
> >
> > John (as individual)
> >
> > > [mailto:[email-masked]] On Behalf Of Charles Eckel
(eckelcu)
> > > Sent: 26 January 2011 18:56
> > > To: [email-masked]
> > > Subject: [siprec] metadata model for participant that is not
> > > part of CS
> > >
> > > This is to follow up on some questions I raised regarding the
> > metadata
> > > model during the interim meeting Tuesday.
> > > My initial concern was that I thought we were allowing media
> > > streams to
> > > be defined without any participant. I now understand that is not
the
> > > case; rather, a media stream is always associated with at least
one
> > > participant, but that participant need not necessary be
> > > associated with
> > > the CS.
> > > Now I have some concern about participants that are not part
> > > of the CS.
> > > My concern is that the level of metadata we have for such
> > participants
> > > will be inconsistent at best. If the metadata for a non-CS
> > participant
> > > is incomplete, what do we plan to do?
> > > Also, I believe there was reference to a document that contains
the
> > > model and some use cases. Which document is that?
> > >
> > > Thanks,
> > > Charles

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 12 Apr 2011 08:43:20 +0200

I think the attached message was the last in that thread. So I don't really think we had closure.

John

> From: Charles Eckel (eckelcu) [mailto:[email-masked]]
> Sent: 11 April 2011 23:53
> To: Elwell, John; Parthasarathi R (partr); Paul Kyzivat
> Hildebrand
> > > > > refreshing the entire metadata), this can make the
> metadata very
> > > > > bulky.

Subject: RE: [siprec] metadata model for participant that is not part of CS
From: "Charles Eckel (eckelcu)" <[email-masked]>
To: "Elwell, John" <[email-masked]>, Leon Portman <[email-masked]>, "Paul Kyzivat (pkyzivat)" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 14 Feb 2011 20:25:44 +0100

I am ok with this best effort handling as in reality that is always the
case anyway. If we show two use cases, one with highly functionality and
cooperative participants and another with lower functioning
participants, and illustrate the resulting meta data population, I think
that will address my concerns.
For example:

1) Participant A within a CS conferences in another party that is not a
part of the CS via internal 3rd party conference feature. Participant A
does not provide any SIP signaling regarding this toward the SRS. What
is the resulting metadata?

2) MCU is used to host a multiparty conference that is part of a CS.
What is the resulting metadata at the SRS if the MCU supports the
conferencing package? How do things look if it does not.

Perhaps (1) is just a special case of (2), but I think going through the
metadata example will help determine that.

Cheers,
Charles

Behalf Of Elwell, John
> Sent: Sunday, February 13, 2011 11:36 PM
> To: Leon Portman; Paul Kyzivat (pkyzivat); [email-masked]
> Subject: Re: [siprec] metadata model for participant that is not part
of CS
>
> Or we could have values "unknown" for certain things.
>
> John (as individual)
>
>
> > Sent: 13 February 2011 22:40
> > To: Elwell, John; Paul Kyzivat; [email-masked]
> > Hello,
> > I agree with Paul statement that SRC should provide best
> > effort to report complete metadata as possible. And we should
> > model it as complete as possible as well.
> > In cases where information is not complete or cannot be
> > guaranteed to be correct, we should allow SRC to indicate it:
> > maybe  we should add a parameter called: "Metadata Certainty"?
> >
> > Leon
> >
> >
> > [mailto:[email-masked]] On Behalf Of Elwell, John
> > Sent: Friday, February 11, 2011 4:29 PM
> > To: Paul Kyzivat; [email-masked]
> > Subject: Re: [siprec] metadata model for participant that is
> > not part of CS
> >
> > I realise I was directly addressed earlier in this thread and
> > I didn't reply (it was left sitting in my inbox).
> >
> > I don't have anything further to add - I see both sides of
> > the argument. Paul/Ram are looking for sufficient
> > expressiveness to cover a wide range of situations, even
> > though in many cases information available will be limited.
> > Charles is concerned, I think, with it being misleading in
> > some cases where limited information is available. So perhaps
> > we need other opinions in order to close on this one.
> >
> > John
> >
> > > [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> > > Sent: 27 January 2011 18:58
> > > To: [email-masked]
> > > Subject: Re: [siprec] metadata model for participant that
> > is not part
> > > of CS
> > >
> > > Charles,
> > >
> > > I don't think we will be able (or should try) to design
> > this so that
> > > everything the SRC specifies is guaranteed to be as complete as
you
> > > wish it to be. At the end of the day, the SRC will have to
> > do what it
> > > can, and some will be better at it than others. If the SRC you
have
> > > chosen isn't supplying the information it could have and
> > wish it had,
> > > then you can complain and request upgrades, or you can choose a
> > > different product.
> > >
> > > As long as we have sufficient expressiveness to describe
> > things as you
> > > wish for any given case then I think we are good. Lets
> > ensure we can
> > > at least do that.
> > >
> > > BTW, this is exactly the sort of discussion I have been hoping we
> > > would have over the model. I expected it would happen quite
> > some time
> > > ago. But better now than never.
> > >
> > >   Thanks,
> > >   Paul
> > >
> > > On 1/27/2011 1:07 PM, Charles Eckel (eckelcu) wrote:
> > > > Hi Ram,
> > > >
> > [mailto:[email-masked]] On
> > > >>> Behalf Of Elwell, John
> > > >>>> Subject: [siprec] metadata model for participant that
> > is not part
> > > >>>> of CS
> > > >>>>
> > > >>>> streams to be defined without any participant. I now
> > understand
> > > >>>> that is not
> > > > the
> > > >>>> associated with the CS.
> > > >>>> Now I have some concern about participants that are
> > not part of
> > > >>>> the CS.

---

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

Renaming the mail thread to discussion to this specific issue -
"Metadata for participants not part of CS" which we have been discussing
from several weeks.

Please continue the other issues in original thread and lets use this
thread to close this issue. I would request people to give inputs for
this issue on this thread and take it to a conclusion.

We(Authors of Metadata model) included participants that are not part of
CS to imply:
- Participants that does NOT contribute to signaling in CS but
contributes to media 
The intent is to give more flexibility in the metamodel to represent
these types of participants.

Following are some of use case where this can happen-

Use-Case 1: A conference where one of the participants is a SRC. In
these case the Focus which talks to this SRC becomes part of CS
contributing signaling as well as media. However the media includes
media from other participants that are not part of CS. Please note SRC
has to subscribe to conf event packet to get this information (which may
not be always feasible).

Use-Case 2: one UA in CS works in 3pcc mode to acquire an MoH media
stream,  this might be reflected as unique source for media stream
without   having a reported signaling relationship to it. E.g is given
here by Henry Lum
http://www.ietf.org/mail-archive/web/siprec/current/msg01372.html

In some sense these participants are *still* part of CS as they
contribute to CS media.

There are three approaches I can see-
Don't model the participants that does not contribute signaling in CS
and only contribute Media
Model these participants as not part of CS in the model but associated
with Media Stream block ( current approach)
Model these participants to be associated with CS but have the
association labeled as "indirect participant" 

Let me know your thoughts.

Thanks,
Ram

> Sent: Tuesday, April 12, 2011 12:13 PM
> To: Charles Eckel (eckelcu); Parthasarathi R (partr); Paul Kyzivat
> Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr)
> > To: Elwell, John; Parthasarathi R (partr); Paul Kyzivat (pkyzivat);
> > [email-masked]
> > I have attached the last e-mail I have from the thread in which I
> > first raised this issue. Unfortunately, I do not have the e-mail
with
> > the ultimate agreement, but maybe someone else does or this will
help
> > prompt some memories.
> > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr);
> Hadriel
> > Kaplan
> > > It seems the present solution is somewhere between the two, which
> is
> > why I am uncomfortable.
> > >
> > > Regards,
> > >
> > > John (as individual)
> > >
> > >
> > > > > In case participant within CS, xml:id will serve the purpose
> but
> > we
> > > > correctly, a Participant can have a relationship with a CS, but
> no
> > > > direct relationship with an RS.
> > > >
> > > > <Partha> Sorry, I mixed up my statement with the latest update
of
> > > > making CSG optional. As per Sec 3 of metadata-04, participant
has
> > > > direct relationship with CSG in case CS is left completely
> > > > unattached. In case CSG is optional, then participant will have
> > > > direct relationship with RS in case there is no relationship
> > > > between CS and participant.
> > > > </Partha>
> > > >
> > > > completely unattached, unless it has a relationship with a Media
> > > > Stream (which always has a relationship with a CS). So to
> > > > summarize:
> > > > - a Participant can have an indirect relationship with a CS (via
> a
> > > > Media Stream); <Partha> agreed </Partha>
> > > > <Partha> I'm happy if the last case is not required because it
> > > > simplify the solution and there is no need of unique id for
> > > > participant. But SRS implementers may prefer to have
relationship
> > > > with participant and RS. I wish more opinion before taking
> > > > decision whether to remove the last case </Partha>
> > > >
> > > > [JRE] I don't understand the words "Because CS may span across
> > > > different RS", because in the rest of the sentence you are
> talking
> > > > about a Participant that is not part of a CS.
> > > >
event
> > > > package as being part of the CS.
> > > >
> > > > associated with CS directly but related to CSG (/RS). This
> > > > scenario was considered as a blocking in -03 version of
metadata.
> > > > I'm not arguing to have this scenario but it is major concern
for
> > > > few folks.
> > > > participants are not related in CS directly (and only focus is
> > > > related) but they contributed for the mixed stream. </Partha>
> > > >
> > > >  That user is sending/receiving Media Streams that are part of a
> > > > CS, or if it isn't sending/receiving Media Streams, what is the
> > > > relevance
> > of
> > > > that Participant?
> > > >
> > > > event package participants. There participant are not directly
> > > > involved as part of CS. </Partha>  Why would we create a new RS
> > > > for such a participant?
> > > > <Partha> RS is not created for participant. Multiple RS shall be
> > > > created the same CS during the different time frame as shown
> below
> > > >
> > > > and SRS. Here tangling (conference event package) participant
has
> > > > to be grouped together in RS1, RS2 by some means through given
> > > > metadata.
> > The
> > > > > > these globally unique id. Initially I had the impression
that
> > > > > > each level is as follows and please provide your input in
> case
> > id
> > > > > > shall be
> > > > > > tweaked:
> > > > > >
> > > > > > In the above topology, it is possible for ID1 is generated
by
> > both
> > > > > > 4574 does not mandate label attribute has to be unique
across
> > > > > (pkyzivat)
> > > > > > of messages, so I think its probably premature to worry
about
> > it.
> > > > > > content, without having to send again other objects that
have
> > not
> > > > > > send all the other participant objects again. I do not
recall
> > any

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 19 Apr 2011 12:19:33 +0530

Hi all,

As per the progress in another mail thread
(http://www.ietf.org/mail-archive/web/siprec/current/msg01864.html),
there is no known usecase wherein participant involved in RS but not
involved in CS directly. IOW, participant is always within CS. This
change in metadata model makes us to re-look whether participant shall
be unique id within CS (something like xml:id) rather than globally
unique id.

The open question is whether participant in multiple CS within single RS
should have same id or not. Example: Alice acts as SRC and the scenario
is as follows:

1) Alice establish CS1 with Bob, RS is established between Alice & SRS,
CS1 details with Alice & Bob as participant is passed
2) Bob transfer the session to Carol 
3) New CS2 is established between Alice & Carol, RS is updated with new
CS2 info having Alice & Carol as participants 

The open question are

1) At step 3, whether Alice MUST have the same unique id as in step 1 or
it is not mandatory? 

2) If required to be unique across RS, whether xml:id serve the purpose?

Thanks
Partha 

-----Original Message-----
From: Charles Eckel (eckelcu) 
Sent: Tuesday, April 12, 2011 4:23 AM
To: Elwell, John; Parthasarathi R (partr); Paul Kyzivat (pkyzivat);
[email-masked]
Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); Hadriel
Kaplan
Subject: RE: [siprec] Partial updates and identifiers

Hi John,

Cheers,
Charles

> weeks/months ago about the participants obtained from the conference 
> event package. I was never particularly comfortable with the fact 
> these were not considered part of the CS. While that might be correct 
> if we consider the CS to be the SIP dialog between the SRC and the 
> conference focus, taking a broader view of CS those participants
behind the focus could be considered part of the CS. I don't
particularly want to open up the old discussion if people are happy with
what we have, but something doesn't seem quite right to me.
> CS, and if we don't have specific information about their involvement 
> in media streams, do they really merit being considered Participant
objects?

> a "Participant" and the users behind the focus are not separate 
> Participants but are just additional data associated with the 
are between the mixer and the SRC.
> conference event package, each of those users is a separate 
> Participant object, and we are concerned with Media Stream objects 
> that those participants send and receive. I am not sure how feasible
this approach is, because I am not sure that the SRC can obtain enough
information about media streams at users behind the focus/mixer.
> > > In case participant within CS, xml:id will serve the purpose but 
> > > we need to get more clarity about participants who are not
> > part of CS but
> >
> > > within RS.
> > correctly, a Participant can have a relationship with a CS, but no 
> > <Partha> Sorry, I mixed up my statement with the latest update of 
> > making CSG optional. As per Sec 3 of metadata-04, participant has 
> > direct relationship with RS in case there is no relationship between

> > CS and participant.
> > </Partha>
> >
> >  So a participant that does not have a relationship with a CS is 
> > left completely unattached, unless it has a relationship with a 
> > Media Stream (which always has a relationship with a CS). So to 
> > summarize:

> > participant. But SRS implementers may prefer to have relationship 
> > with participant and RS. I wish more opinion before taking decision 
> > whether to remove the last case </Partha>
> >
> > different RS", because in the rest of the sentence you are talking 
> > consider a user whose identity is obtained via a conference event 
> > associated with CS directly but related to CSG (/RS). This scenario 
> > was considered as a blocking in -03 version of metadata. I'm not 
> > arguing to have this scenario but it is major concern for few folks.
> >
> > participant info via conference event package but those participants

> > are not related in CS directly (and only focus is related) but they 
> > contributed for the mixed stream. </Partha>
> >
> >  That user is sending/receiving Media Streams that are part of a CS,

> > or if it isn't sending/receiving Media Streams, what is the 
> > relevance of that Participant?
> >
> > Conference event package participants. There participant are not 
> > directly involved as part of CS. </Partha>  Why would we create a 
> > new RS for such a participant?
> > created the same CS during the different time frame as shown below
> >
> > CS1 is between UA (SRC) and focus whereas RS1, RS2 is between UA 
> > (SRC) and SRS. Here tangling (conference event package) participant 
> > has to be grouped together in RS1, RS2 by some means through given 
> > metadata. The question whether this corner has to be solved ? 
> > </Partha>
> >
> > John (as individual)
> >
> >
> >
> > >
> > > Thanks
> > > Partha
> > >
> > > > these globally unique id. Initially I had the impression that 
> > > > the single unique id (RS dialog-id) in the recording (session
> > > level) and
> > > > each level is as follows and please provide your input in case 
> > > > id shall be
> > > > tweaked:
> > > >
> > > > group of CS from SRC perspective. It possible that group may 
> > > > span across multiple RS and It is up to SRS to group and view
> > as single
> > > > recording.

> > > > 4574 does not mandate label attribute has to be unique across 
> > > > the dialog or CS and so, it may possible to change within RS and

> > > > no normative statement to stop this implementation. IMO,
> > > xml:id may serve
> > >
> > > > content, without having to send again other objects that have 
> > > > not changed. So, for example, in a large conference, it would
> > > be possible
> > > > send all the other participant objects again. I do not recall 
> > > > any opposition to this basic principle.
> > > > >
> > > > time. Although this might be efficient for updating an 
> > > > individual object, when sending many objects (e.g., at the start

> > > > of a
> > > CS or when
> > > > refreshing the entire metadata), this can make the metadata very

> > > > or more local identifiers. However, there were also concerns 
> > > > this might not fulfil actual or perceived future requirements.
> > > > >

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Apr 2011 08:36:57 -0400

On 4/19/2011 2:49 AM, Parthasarathi R (partr) wrote:
> 1) Alice establish CS1 with Bob, RS is established between Alice&  SRS,
> CS1 details with Alice&  Bob as participant is passed
> 3) New CS2 is established between Alice&  Carol, RS is updated with new
> CS2 info having Alice&  Carol as participants
>
> The open question are
>

IMO it is at least *preferred* that there be a single Participant 
entity, with one id, for Alice in both CS.

But I don't think we need mandate that - we can leave it as "quality of 
implementation". While it might be nice to mandate it, I think it would 
send us down a rat hole trying to figure out how to specify those cases 
where it must be the same and those where it need not be.

	Thanks,
	Paul

>>> - a Participant can have an indirect relationship with a CS (via a
>>> Media Stream);<Partha>  agreed</Partha>
>>> whether to remove the last case</Partha>
>>>
>>> contributed for the mixed stream.</Partha>
>>>
>>> directly involved as part of CS.</Partha>   Why would we create a

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 19 Apr 2011 14:24:27 -0700

Hi Partha,

I think that participants need to be unique within the recording
session, even if they span multiple CSs. I do not see a need to make
them unique across recording sessions. It would be nice, but I think
that is out of scope for SIPREC.

Cheers,
Charles

> From: Parthasarathi R (partr)
> Sent: Monday, April 18, 2011 11:50 PM
> To: Charles Eckel (eckelcu); 'Elwell, John'; Paul Kyzivat (pkyzivat);
[email-masked]'
> Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); 'Hadriel
Kaplan'
> As per the progress in another mail thread (http://www.ietf.org/mail-
> archive/web/siprec/current/msg01864.html), there is no known usecase
wherein participant involved in
> RS but not involved in CS directly. IOW, participant is always within
CS. This change in metadata
> model makes us to re-look whether participant shall be unique id
within CS (something like xml:id)
> rather than globally unique id.
> 
> The open question is whether participant in multiple CS within single
RS should have same id or not.
> Example: Alice acts as SRC and the scenario is as follows:
> 
> 1) Alice establish CS1 with Bob, RS is established between Alice &
SRS, CS1 details with Alice & Bob
> as participant is passed
> 3) New CS2 is established between Alice & Carol, RS is updated with
new CS2 info having Alice & Carol
> as participants
> 
> The open question are
> 
> 1) At step 3, whether Alice MUST have the same unique id as in step 1
or it is not mandatory?
[email-masked]
Kaplan
> I have attached the last e-mail I have from the thread in which I
first raised this issue.
> Unfortunately, I do not have the e-mail with the ultimate agreement,
but maybe someone else does or
> this will help prompt some memories.
> 
> Cheers,
> Charles
> 
behind the focus could be
> considered part of the CS. I don't particularly want to open up the
old discussion if people are happy
> with what we have, but something doesn't seem quite right to me.
> >
objects?
> > focus/mixer Participant. The only Media Streams we are concerned
with are between the mixer and the
> > that those participants send and receive. I am not sure how feasible
this approach is, because I am
> not sure that the SRC can obtain enough information about media
streams at users behind the
> focus/mixer.
between
> > > with participant and RS. I wish more opinion before taking
decision
> > > associated with CS directly but related to CSG (/RS). This
scenario
participants
> > >  That user is sending/receiving Media Streams that are part of a
CS,
Hildebrand