Subject: Re: [siprec] Partial updates and identifiers

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 4 May 2011 10:15:57 +0530

Hi Charles,

In case participants id has to be unique for single RS with multiple CS
as you mentioned below mail and also, participant id has to be unique
within single CS which span across multiple RS (start & stop of
recording within CS scenario), then participant unique id needs to be
global (URN UUID) rather than local id like xml:id. Please let me know
in case you have any other opinion on the same.

Thanks
Partha

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

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

> -----Original Message-----
> 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'
> Subject: RE: [siprec] Partial updates and identifiers
> 
> 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,
> 
> 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
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Elwell, John
> > Sent: Monday, April 11, 2011 9:46 AM
> > To: 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
> >
> > 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)
> >
> >
> > > -----Original Message-----
> > > From: Parthasarathi R (partr) [mailto:[email-masked]]
> > > Sent: 11 April 2011 10:29
> > > To: Elwell, John; Paul Kyzivat (pkyzivat); [email-masked]
> > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand
> > > (jhildebr)
> > > 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)
> > > Subject: RE: [siprec] Partial updates and identifiers
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Parthasarathi R (partr) [mailto:[email-masked]]
> > > > Sent: 11 April 2011 08:35
> > > > To: Elwell, John; Paul Kyzivat (pkyzivat); [email-masked]
> > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand
> > > > (jhildebr)
> > > > Subject: RE: [siprec] Partial updates and identifiers
> > > >
> > > > 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.
> > > [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)
> > >
> > >
> > >
> > > >
> > > > 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)
> > > > Subject: RE: [siprec] Partial updates and identifiers
> > > >
> > > > Focusing just on participant and stream for the time being,
> > > do these
> > > > need to be unique across multiple CSs or not?
> > > >
> > > > John
> > > >
> > > > > -----Original Message-----
> > > > > 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,
> > > > >
> > > > > 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,
> > > > >
> > > > > 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:
> > > > > > 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)
> > > > > > _______________________________________________
> > > > > > siprec mailing list
> > > > > > [email-masked]
> > > > > > https://www.ietf.org/mailman/listinfo/siprec
> > > > > >
> > > > > _______________________________________________
> > > > > siprec mailing list
> > > > > [email-masked]
> > > > > https://www.ietf.org/mailman/listinfo/siprec
> > > > >
> > > >
> > >
> > _______________________________________________
> > siprec mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/siprec

---

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

I follow the logic, but let me run through a simple use case. 

0) I am on a call that is part of a recording. Initially, this is
through CS1 which results in RS1, which is part of recording X. My
unique participant ID is p0.

I drop off and call back in. I need to be brought back into the same
recording X. Possible scenarios are:

1) I call back into CS1, and am added into recording X through RS1. My
unique participant ID is p1?
2) I call into CS2, and am added to recording X through RS1. My unique
participant ID is p2?
3) I call into CS2, and am added to recording X through RS2. My unique
participant ID is p3?

If the SRS is able to make use of some other metadata to realize that
p0=p1=p2=p3, great, if not, they look like different participants.

Cheers,
Charles

> Sent: Tuesday, May 03, 2011 9:46 PM
[email-masked]'
Kaplan'
> In case participants id has to be unique for single RS with multiple
CS as you mentioned below mail
> and also, participant id has to be unique within single CS which span
across multiple RS (start & stop
> of recording within CS scenario), then participant unique id needs to
be global (URN UUID) rather than
> local id like xml:id. Please let me know in case you have any other
opinion on the same.
[email-masked]'
Kaplan'
> 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
> > To: Charles Eckel (eckelcu); 'Elwell, John'; Paul Kyzivat
(pkyzivat); [email-masked]'
> > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr);
'Hadriel Kaplan'
> > 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.
> > 1) At step 3, whether Alice MUST have the same unique id as in step
1 or it is not mandatory?
purpose?
first raised this issue.
> > > involvement in media streams, do they really merit being
considered Participant objects?
> > > It seems the present solution is somewhere between the two, which
is why I am uncomfortable.
Hildebrand
> > > > I'm not arguing to have this scenario but it is major concern
for few folks.
> > > > through given metadata. The question whether this corner has to
be solved ?
Hildebrand
> > > > > > of messages, so I think its probably premature to worry
about it.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 May 2011 17:46:44 -0400

> unique participant ID is p1?

Maybe. It depends on whether the SRC recognizes you as the same 
participant and remembers that it had assigned p1 to you.
If not, then you will presumably appear as a new participant.

> 2) I call into CS2, and am added to recording X through RS1. My unique

Pretty much the same answer as above.

Its also up to the SRC to decide if this is part of CS1 or CS2.

> 3) I call into CS2, and am added to recording X through RS2. My unique

Pretty much the same again. If it is the same SRC, and has some history 
to figure out what is going on, it can continue to use p1.

If it is a different SRC, then its more of a challenge. There would have 
to be some sharing of info between the two for the new SRC to recover 
the old p1. More likely you will get a new p3.

> p0=p1=p2=p3, great, if not, they look like different participants.

Yes, if the p(i) are different the SRS could still attempt correlation, 
but its outside our current scope.

	Thanks,
	Paul

> across multiple RS (start&  stop
>>> 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
>>>
> Hadriel
>>>>> Media Stream);<Partha>  agreed</Partha>
>>>>> decision whether to remove the last case</Partha>
>>>>>
>>>>> related) but they contributed for the mixed stream.</Partha>
>>>>>
>>>>> directly involved as part of CS.</Partha>   Why would we create
> a

---

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

When is a participant the same participant and when is it different? I call into a conference from my desk phone. I later drop out and then call in again to the same conference from my cell phone. The conference is being recorded. In this case it is unlikely that the SRC will have any information to correlate the new caller with the caller who dropped out, unless they happen to share the same SIP AOR.

I think it is fine for participants to be assigned new IDs each time they join a call or participate in different calls / different recordings. If other attributes of the Participant object can be used to correlate two different Participant IDs (e.g., the same SIP AoR), this can be made use of. Otherwise they are treated as different participants, even though it might be the same person.

John (as individual)

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 05 May 2011 22:47
> To: Charles Eckel (eckelcu)
> Cc: Parthasarathi R (partr); Elwell, John; [email-masked];
> Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr);
> Hadriel Kaplan

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 May 2011 08:10:38 -0400

John,

I think we are in agreement. My point was that some SRCs may be smarter 
about this than others. If they are able to figure out when to reuse the 
same participant id, then that is great, but not required.

(Of course they must not reuse the same participant id *by accident*.)

	Thanks,
	Paul

---

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

The reason I brought this up was in response to Partha's assertion that
participant IDs need to be globally unique rather than unique within a
given CS, RS, or recording. The point I was trying to make was that an
SRS might actually want a way to correlate participants, either by
participant ID or some other metadata or some mechanism outside the
scope of SIPREC. While this is still possible with globally unique
participant IDs, it is made more difficult. So in this case, mandating
that participant IDs be globally unique make things more
complex/difficult. Why are globally unique participant IDs across all
CSs and RSs required? That is what I am trying to understand.
They is some cost associated with this, and I want to make sure the cost
is warranted.

Cheers,
Charles

> From: Paul Kyzivat (pkyzivat)
> Sent: Friday, May 06, 2011 5:11 AM
> To: Elwell, John
> Cc: Charles Eckel (eckelcu); Parthasarathi R (partr); [email-masked];
Peter Saint-Andre (psaintan);
> Joe Hildebrand (jhildebr); Hadriel Kaplan
> > When is a participant the same participant and when is it different?
I call into a conference from
> my desk phone. I later drop out and then call in again to the same
conference from my cell phone. The
> conference is being recorded. In this case it is unlikely that the SRC
will have any information to
> correlate the new caller with the caller who dropped out, unless they
happen to share the same SIP
> AOR.
> >
> > I think it is fine for participants to be assigned new IDs each time
they join a call or participate
> in different calls / different recordings. If other attributes of the
Participant object can be used
> to correlate two different Participant IDs (e.g., the same SIP AoR),
this can be made use of.
> Otherwise they are treated as different participants, even though it
might be the same person.
Hildebrand
Hildebrand
> >>>>>>> correctly, a Participant can have a relationship with a CS,
but
> >>> no
> >>>>>>> <Partha>   Sorry, I mixed up my statement with the latest
update
> >>> of
> >>>>>>> - a Participant can have an indirect relationship with a CS
(via
> >>>>>>>> From: Elwell, John
[mailto:[email-masked]]

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 May 2011 17:36:47 -0400

Charles,

On 5/6/2011 1:04 PM, Charles Eckel (eckelcu) wrote:
> participant IDs, it is made more difficult.

???

How? Having globally unique ones makes it *possible* for more than one 
src to reference the same one. If the SRS wants to correlate ones that 
are different, how does this make it more difficult?

> So in this case, mandating

As noted above, being globally unique means that two different SRCs that 
find a way of discovering each others ids MAY then reference/reuse them.

If the ids are instead *locally* unique to an SRC, then the SRS still 
has to make them globally unique if it stores in common the data from 
multiple SRCs. (It can do that by prefixing the src-local id with a uid 
for the SRC.) But that has its own problems.

In that environment if src1 knows and wants to reference an id generated 
by src2, it can't do so unless there is a way for src1 to include an id 
like src2:id. And if we allow that we are back to globally unique ids - 
just of a different format. Or else you just can't cross reference at all.

Another issue with this is that if the ids are not globally unique, then 
*exactly* what is the scope in which they *are* unique. For the SRS to 
understand them properly that must be nailed down. Once you get beyond a 
single RS session, there starts to be uncertainty whether two RSs 
involved the same SRC or different ones. Of course we could solve that 
by requiring the SRC to provide a globally unique id for itself, and 
other ids that are unique within the scope of that one. But that is 
again just a different way of encoding globally unique ids.

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 6 May 2011 15:56:44 -0700

If the participant generates its own ID instead, it could represent
itself the same for all instances that it wants correlated. This could
be a To/From URI, or a P-Asserted-Identity URI. It will not work in all
cases, but it could in some. If I understand your point correctly, an
SRC/SRS could still use some metadata to achieve this same thing, and
having globally unique participant IDs enables having other mechanisms,
outside the scope of SIPREC, that do not rely on endpoints to represent
themselves in a consistent fashion. Do I have it straight now?

Thanks,
Charles

> Sent: Friday, May 06, 2011 2:37 PM
> Cc: Elwell, John; Parthasarathi R (partr); [email-masked]; Peter
Saint-Andre (psaintan); Joe
> Hildebrand (jhildebr); Hadriel Kaplan
> >> about this than others. If they are able to figure out when to
reuse
> > the
> >>>>>>> I have attached the last e-mail I have from the thread in
which
> > I
[mailto:[email-masked]]
> > On
> >>>>>>>> For example, if these "participants" are not considered part
of
> >>>>> the
> >>>>>>>>>> (not required to be unique across multiple CS) and so,
xml:id
> >>>>> or
> >>>>>>>>>> In case participant within CS, xml:id will serve the
purpose
> >>>>>>>>> making CSG optional. As per Sec 3 of metadata-04,
participant
> >>>>> has
> >>>>>>>>> left completely unattached, unless it has a relationship
with
> >>>>>>>>> <Partha>    I'm happy if the last case is not required
because
> > it
> >>>>>>>>>> initial conference creation and hold&resume of a user
within
> >>>>> CS.
> >>>>>>>>> CS1 is between UA (SRC) and focus whereas RS1, RS2 is
between
> > UA

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 May 2011 19:48:04 -0400

On 5/6/2011 6:56 PM, Charles Eckel (eckelcu) wrote:
> be a To/From URI, or a P-Asserted-Identity URI.

There would have to be agreement on what it is that identifies the scope 
of uniqueness.

And IIUC, you are saying two or more SRCs might choose to operate within 
the same identity scope by providing the same "SRC identity". That 
probably means it couldn't be to/from/paid, because that would limit 
those who could be in the same group. So lets assume for a moment that 
it is some other, globally unique id that is provided by the SRC to the 
SRS, and which the SRS would then have to couple with the other ids to 
make them unique in its db.

So what you have arrived at is a globally unique id. All you have done 
is changed the wire encoding.

If, in any given RS, the SRC is limited to referencing ids within the 
one SRC-id it has provided for that RS, then you have partitioned the 
SRS db into subdomains based on the SRC-id, without any possibility of 
an SRC reaching across the domain boundaries.

You could fix that by allowing the src to explicitly provide a different 
src-id with a specific id-reference, perhaps as an optional field. But 
at that point you again actually have globally unique ids, with perhaps 
a coding efficiency. (Or maybe not - it might be worse.)

> It will not work in all

I don't quite understand what you are saying.

> themselves in a consistent fashion. Do I have it straight now?

There are a lot of things that we care about in siprec that are out of 
scope. For instance querying the data we are writing. (A write-only db 
isn't really very interesting.)

IMO this is a decision where if we limit this now it will be hard to fix 
in the future. We don't need to be designing the mechanism for sharing 
these ids in order to imagine that somebody will want to.

	Thanks,
	Paul