Subject: [siprec] Participants

From: Michael Baj <[email-masked]>
Date: Mon, 25 Jul 2011 12:37:54 +0000

Participants can only be parented to a Communication Session.  What is the purpose of the participant ID since they can not belong
to any other metadata object?  Participant IDs may differ for each CS even if it is the same endpoint (e.g. anonymous).  Is there an expectation that the SRC treat the same physical endpoint as the same participant for all CSs?  What is the criteria for defining the uniqueness of a participant?

---

From: Leon Portman <[email-masked]>
Date: Mon, 25 Jul 2011 09:33:51 -0400

I remember having some discussions about it. It will be very useful for SRS if the same participant for different CS will preserver their ID and SRS will not be required to use other participant properties (like URI) in order to map them

Leon
On Jul 25, 2011, at 8:37 AM, Michael Baj wrote:

> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Jul 2011 10:26:30 -0400

> to any other metadata object?  Participant IDs may differ for each CS even if it is the same endpoint (e.g. anonymous).  Is there an expectation that the SRC treat the same physical endpoint as the…

The same participant may participate in multiple CSs.
And that participant may participate is some but not all media streams 
of each CS.

Also, the AoR of a participant is not necessarily a unique id for a 
participant - there can be multiple devices with the same AoR that are 
participating. (E.g. you might connect to a conference focus twice - 
once with your phone for voice, and once with your pc for other media.)

The participant id gives us a way to reference a unique participant, to 
the extent that the SRC can distinguish unique participants, and at the 
same time identify a common participant when that is known to the SRC.

	Thanks,
	Paul

---

From: Michael Baj <[email-masked]>
Date: Mon, 25 Jul 2011 17:40:55 +0000

What is the intended lifetime of the participant?  Is it intended to be globally unique for the same endpoint through multiple RS taking place at different times?

e.g. participant-A is in RS-1, RS-1 terminates, RS-2 starts which also includes participant-A.  Should participant-A's ID be the same?

Or it is intended to only be unique for the duration in which the participant is active in any RS?

e.g. participant-A is in RS-1 and also in RS-2; participant-A's ID is the same.  RS-1 and RS-2 terminate.  When RS-3 starts, which also include participant-A, its ID will now be different.

Thanks,
Mike

On Jul 25, 2011, at 10:26 AM, Paul Kyzivat wrote:

> And that participant may participate is some but not all media streams of each CS.
> 
> Also, the AoR of a participant is not necessarily a unique id for a participant - there can be multiple devices with the same AoR that are participating. (E.g. you might connect to a conference focus twice - once with your phone for voice, and once with your pc for other media.)
> 
> The participant id gives us a way to reference a unique participant, to the extent that the SRC can distinguish unique participants, and at the same time identify a common participant when that is known to the SRC.
> 
> 	Thanks,
> 	Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Jul 2011 13:54:27 -0400

On 7/25/11 1:40 PM, Michael Baj wrote:
> What is the intended lifetime of the participant?
> Is it intended to be globally unique for the same endpoint through multiple RS taking place at different times?
>

We are being intentionally vague here.
IMO, the greater the scope the better.
But this depends largely on the capability of the SRC to figure it out 
and remember it.

IMO what is key is that the same participant id *not* be used unless the 
participant is really known to be the same.

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Mon, 25 Jul 2011 21:00:38 +0300

+1

Leon

Sent from my iPad

On Jul 25, 2011, at 8:54 PM, Paul Kyzivat <[email-masked]> wrote:

> But this depends largely on the capability of the SRC to figure it out and remember it.
> 
> IMO what is key is that the same participant id *not* be used unless the participant is really known to be the same.
> 
>    Thanks,
>    Paul
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 26 Jul 2011 01:06:20 +0200

This triggers a question that had not occurred to me before. 

Suppose I retain the same participant ID for a party who participants in multiple CSs and/or recordings being made over multiple RSs. Suppose the participant drops out of a first CS (but the CS perhaps continues for longer). The participant element in the XML will gain a stop time. Now the participant joins the same CS again, or a different CS. Given that we have previously given the participant a stop time, what is the meaning of restarting that participant? Perhaps the meaning of stop time is the time the participant stops participating in a given CS, rather than the time of the final death of the participant object. Likewise, when the participant rejoins the CS or a new CS, it gains a new start time, replacing the former start time. So again, what exactly are the semantics of start time for a participant?

John (as individual)

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: [email-masked]
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 25 July 2011 18:54
> To: Michael Baj
> Cc: <[email-masked]>
> Subject: Re: [siprec] Participants
> 
> > Is it intended to be globally unique for the same endpoint 
> through multiple RS taking place at different times?
> >
> > e.g. participant-A is in RS-1, RS-1 terminates, RS-2 starts 
> which also includes participant-A.  Should participant-A's ID 
> be the same?
> >
> > Or it is intended to only be unique for the duration in 
> which the participant is active in any RS?
> >
> > e.g. participant-A is in RS-1 and also in RS-2; 
> participant-A's ID is the same.  RS-1 and RS-2 terminate.  
> When RS-3 starts, which also include participant-A, its ID 
> will now be different.
> 
> >>> Participants can only be parented to a Communication 
> Session.  What is the purpose of the participant ID since 
> they can not belong
> >>> to any other metadata object?  Participant IDs may differ 
> for each CS even if it is the same endpoint (e.g. anonymous). 
>  Is there an expectation that the SRC treat the same physical 
> endpoint as the same participant for all CSs?  What is the 
> criteria for defining the uniqueness of a participant?
> >>
> >> Also, the AoR of a participant is not necessarily a unique 
> id for a participant - there can be multiple devices with the 
> same AoR that are participating. (E.g. you might connect to a 
> conference focus twice - once with your phone for voice, and 
> once with your pc for other media.)
> >>
> >> The participant id gives us a way to reference a unique 
> participant, to the extent that the SRC can distinguish 
> unique participants, and at the same time identify a common 
> participant when that is known to the SRC.
> >>
> >> 	Thanks,
> >> 	Paul
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Jul 2011 19:28:25 -0400

On 7/25/11 7:06 PM, Elwell, John wrote:
> Suppose I retain the same participant ID for a party who participants in multiple CSs and/or recordings being made over multiple RSs.
> Suppose the participant drops out of a first CS (but the CS perhaps continues for longer).
> The participant element in the XML will gain a stop time. Now the participant joins the same CS again, or a different CS.
> Given that we have previously given the participant a stop time, what is the meaning of restarting that participant?

It seems everywhere we put a stop time it causes trouble of one sort or 
another.

The "stopping" of the participation in media is signaled by removing the 
send or recv connection of the participant to the media stream.

Similarly the stopping of the participation in a CS can be determined by 
the removal of the connection of the participant to the CS.

In both cases, the "stop time" can be determined by the time the change 
was reported.

> Perhaps the meaning of stop time is the time the participant stops participating in a given CS,
> rather than the time of the final death of the participant object.

yes.
Its starting to appear problematic to attach start/stop to anything.
All that seems useful is to timestamp "associate"/"dissociate".

	Thanks,
	Paul

> Likewise, when the participant rejoins the CS or a new CS, it gains a new start time, replacing the former start time.
> So again, what exactly are the semantics of start time for a participant?
>
> John (as individual)
>
>
> John Elwell
>> Cc:<[email-masked]>

---

From: Leon Portman <[email-masked]>
Date: Tue, 26 Jul 2011 16:24:13 +0300

We have similar problem with participant capabilities. They seems to be also belonging not to participant level but on participant/CS level. So may be we should define them on this level as well.

Leon

On Jul 26, 2011, at 2:28 AM, Paul Kyzivat <[email-masked]> wrote:

> It seems everywhere we put a stop time it causes trouble of one sort or another.
> 
> The "stopping" of the participation in media is signaled by removing the send or recv connection of the participant to the media stream.
> 
> Similarly the stopping of the participation in a CS can be determined by the removal of the connection of the participant to the CS.
> 
> In both cases, the "stop time" can be determined by the time the change was reported.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Jul 2011 10:30:04 -0400

> We have similar problem with participant capabilities. They seems to be also belonging not to participant level but on participant/CS level. So may be we should define them on this level as well.

Yes. Given where we are, it seems to be a bigger change to do that, but 
it is the right thing to do.

	Thanks,
	Paul

> Leon
>
> On Jul 26, 2011, at 2:28 AM, Paul Kyzivat<[email-masked]>  wrote:
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 26 Jul 2011 20:53:13 +0530

Hi Paul / All,

Please see inline for comments

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: Monday, July 25, 2011 7:28 PM
> To: Elwell, John
> Cc: <[email-masked]>
> > Suppose I retain the same participant ID for a party who
participants
> in multiple CSs and/or recordings being made over multiple RSs.
> > The participant element in the XML will gain a stop time. Now the
> participant joins the same CS again, or a different CS.
> > Given that we have previously given the participant a stop time,
what
> is the meaning of restarting that participant?
> 

Yes. I agree with this point. We could send a partial update of XML with
no <send> or <recv> tag to indicate that a participant has stopped
sending / receiving a particular media stream identified by unique ID.

> the removal of the connection of the participant to the CS.

What you are suggesting here can be done  by sending a metadata with
participant having association to one CS at instance T0 and at instance
T1 send another metadata with the same participant having association to
another CS. 

Does this mean we don't need to explicitly indicate start/stop at all
for participant ? OR Do we still want to indicate the time in XML
(whenever possible for an SRC) ? and since these are optional
attributes, for cases where SRC cannot indicate SRS may determine by the
above logic.

> All that seems useful is to timestamp "associate"/"dissociate".

I start to  wonder if it's better to use associate/ disassociate time
rather than calling it as start/stop time as it will lead to confuse. By
having "associate/disassociate time" we can scope them to a CS.

Regards,
Ram

> 
> 	Thanks,
> 	Paul
> 
> > Likewise, when the participant rejoins the CS or a new CS, it gains
a
> new start time, replacing the former start time.
> > Registered office: Brickhill Street, Willen Lake, Milton Keynes,
MK15
> 0DJ.

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 27 Jul 2011 21:23:04 +0200

Can't a Participant be in more than one Session at the same time? According to the model, a Participant can be associated with 1 or more Sessions. According to the XML, a Participant element must have a single associated session attribute. There seems to be an inconsistency.

I think we have to go in one of two directions:

1. Say that a Participant is always associated with a single Session (this is consistent with the XML schema but out of line with the model) and therefore the Participant "dies" when the no longer participating in that Session. If a real participant is in two or more sessions, these are different Participant objects (which may or may not have sufficient information to tie them to the same real participant). This applies whether the participation is in sessions in series or in parallel (e.g., active session and held session).

2. Say that a Participant has a lifetime beyond a single session. Then a Participant object can be associated with 0 or more Session objects (this is out of line with both the model and the schema). The XML would then need to change - a Participant attribute would no longer be suitable for identifying potentially multiple Session elements, so an element with 0 or more instances would be needed.

I lean towards option 1, which I think was the conclusion that some people were coming to in earlier postings.

John (as individual)

John Elwell

> From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
> Sent: 26 July 2011 16:23
> To: Paul Kyzivat; Elwell, John
> Cc: [email-masked]
> Subject: RE: [siprec] Participants
> 
> Hi Paul / All,
> 
> > > Suppose the participant drops out of a first CS (but the 
> CS perhaps
> > continues for longer).
> > Similarly the stopping of the participation in a CS can be 
> determined
> > by
> > > Siemens Enterprise Communications Limited is a Trademark 
> Licensee of
> > Siemens AG.
> > >
> > >

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Jul 2011 18:20:04 -0400

On 7/27/11 3:23 PM, Elwell, John wrote:
> Can't a Participant be in more than one Session at the same time?

Yes, that should be allowed.

? According to the model, a Participant can be associated with 1 or more 
Sessions. According to the XML, a Participant element must have a single 
associated session attribute. There seems to be an inconsistency.

IMO that's a mistake in the schema.

> I lean towards option 1, which I think was the conclusion that some people were coming to in earlier postings.

I agree that both alternatives are possible.
I lean towards option 2.

Note that the participant, even if associated with only one session, can 
be associated with multiple media streams, or none.
I see no reason why the association with sessions should be different.
And I agree that we should then allow a participant to be in zero sessions.

Allowing a participant in multiple CS and multiple MS makes it easier 
and more certain to recognize that it is truly the *same* participant, 
rather than a different one with the same AOR. This is information that 
the SRC can know based on the signaling.

	Thanks,
	Paul

>> no<send>  or<recv>  tag to indicate that a participant has stopped

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 28 Jul 2011 12:32:49 +0530

Paul/John,

Please read inline.

Thanks
Partha 

> Sent: Thursday, July 28, 2011 3:50 AM
> To: Elwell, John
> Cc: [email-masked]

<Partha> Agreed. It may be required for some specific deployment. Same
AOR & URN UUID of participant shall be used in more than one session.
</Partha>

> ? According to the model, a Participant can be associated 
> with 1 or more Sessions. According to the XML, a Participant 
> element must have a single associated session attribute. 
> There seems to be an inconsistency.
> 
<Partha> Participant shall be associated with multiple CS as per XML
schema. The sample is given below:

Session 1 having participant 1:
        <participant
           id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"
           session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425">

Session 2 having participant 1:

        <participant
            id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"
            session="urn:uuid:cd27cfa1-2bdd-4830-a653-70374d10f103">

Please let me know the issue in this XML schema approach which allows
the participant to be included in multiple session at the same time.
This is one of the usecase of global-unique id for participant.

</Partha>         

> > 1. Say that a Participant is always associated with a 
> single Session (this is consistent with the XML schema but 
> out of line with the model) and therefore the Participant 
> "dies" when the no longer participating in that Session. If a 
> real participant is in two or more sessions, these are 
> different Participant objects (which may or may not have 
> sufficient information to tie them to the same real 
> participant). This applies whether the participation is in 
> sessions in series or in parallel (e.g., active session and 
> held session).
> >
> > 2. Say that a Participant has a lifetime beyond a single 
> session. Then a Participant object can be associated with 0 
> or more Session objects (this is out of line with both the 
> model and the schema). The XML would then need to change - a 
> Participant attribute would no longer be suitable for 
> identifying potentially multiple Session elements, so an 
> element with 0 or more instances would be needed.
> >
> > I lean towards option 1, which I think was the conclusion 
> that some people were coming to in earlier postings.

<Partha> I'm not favoring option 1 mechanism because it restricts the
participant across session to tie together. Group element helps to group
multiple session and participant global unique id helps to identify the
same participant within the single group element. In case I remember
correctly, we earlier concluded that participant has to have same id
through the single session and how its lifetime outside is based on SRC
implementation. </Partha>

> Note that the participant, even if associated with only one 
> session, can be associated with multiple media streams, or none.

<Partha> I'm missing your point here. Participant is associated with one
or more sessions but I'm not sure abt zero sessions. In case the
intention to allow the same unique-id of participant even after the
termination of the session, I'm fine with it and it is implementation
specific. </Partha>

> 
> Allowing a participant in multiple CS and multiple MS makes 
> it easier and more certain to recognize that it is truly the 
> *same* participant, rather than a different one with the same 
> AOR. This is information that the SRC can know based on the signaling.
> 

<Partha> Agreed. This is specifically required for call centre scenario
wherein multiple transfer between agents happens for the single CSG but
customer happens to be same. Here, customer participant id is same
across multiple CS within single CSG. The participant id for the next
CSG is same or different upto SRC implementation </Partha>

> Licensee of Siemens AG.
> >>> It seems everywhere we put a stop time it causes trouble 
> of one sort
> >> or
> >>> another.
> >>>
> >>> The "stopping" of the participation in media is signaled 
> by removing 
> >>> the send or recv connection of the participant to the 
> media stream.
> >>
> >> Yes. I agree with this point. We could send a partial 
> update of XML 
> >> with no<send>  or<recv>  tag to indicate that a participant has 
> >> stopped sending / receiving a particular media stream 
> identified by 
> >> unique ID.
> >>
> >>>
> >> T1 send another metadata with the same participant having 
> association 
> >> to another CS.
> >>
> >> attributes, for cases where SRC cannot indicate SRS may 
> determine by 
> >> the above logic.
> >>
> >>>
> >>>> Perhaps the meaning of stop time is the time the 
> participant stops
> >>> participating in a given CS,
> >> rather than calling it as start/stop time as it will lead 
> to confuse. 
> >> By having "associate/disassociate time" we can scope them to a CS.
> >>
> >> Regards,
> >> Ram
> >>
> >>>
> >>> 	Thanks,
> >>> 	Paul
> >>>
> >>>>> which also includes participant-A.  Should 
> participant-A's ID be 
> >>>>> the same?
> >>>>>>
> >>>>> When RS-3 starts, which also include participant-A, its ID will 
> >>>>> now be different.
> >>>>>
> >>>>> But this depends largely on the capability of the SRC 
> to figure it 
> >>>>> out and remember it.
> >>>>>
> >>>>> IMO what is key is that the same participant id *not* be used 
> >>>>> unless the participant is really known to be the same.
> >>>>>
> >>>>> 	Thanks,
> >>>>> 	Paul
> >>>>>
> >>>>> Session.  What is the purpose of the participant ID 
> since they can 
> >>>>> not belong
> >>>>> id for a participant - there can be multiple devices 
> with the same 
> >>>>> AoR that are participating. (E.g. you might connect to a 
> >>>>> conference focus twice - once with your phone for 
> voice, and once 
> >>>>> with your pc for other media.)
> >>>>>>>
> >>>>> participant, to the extent that the SRC can distinguish unique 
> >>>>> participants, and at the same time identify a common 
> participant

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 28 Jul 2011 13:02:32 +0200

Partha,

If I interpret your explanation correctly, you are saying that if a Participant object is associated with more than one Communication Session object, there are multiple instances of participant element in XML, each with the same ID but referencing different session elements? That is entirely new to me. I thought a Participant object would be represented by a single participant element only.

John (as individual)

John Elwell

> From: Parthasarathi R (partr) [mailto:[email-masked]]
> Sent: 28 July 2011 08:03

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Jul 2011 07:56:05 -0400

> If I interpret your explanation correctly, you are saying that if a Participant object is associated with more than one Communication Session object, there are multiple instances of participant ele…

I agree with John - this seems incorrect.
I think we will need a schema change to allow the participant to 
reference more than one session, and to change which ones it references 
over time.

	Thanks,
	Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 28 Jul 2011 17:55:19 +0530

John,

Please read inline.

Thanks
Partha 

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Thursday, July 28, 2011 4:33 PM
> To: Parthasarathi R (partr); Paul Kyzivat
> Cc: [email-masked]
> If I interpret your explanation correctly, you are saying 
> that if a Participant object is associated with more than one 
> Communication Session object, there are multiple instances of 
> participant element in XML, each with the same ID but 
> referencing different session elements?

<Partha> Your understanding is correct. The basic design of XML element
in metadata with its id and its parent-id is to make the hierarchical
data to flat structure which helps for partial update. Hope participant
with id & session id as an attribute will meet your requirement of
participant in multiple sessions. </Partha>

 That is entirely new 
> to me. I thought a Participant object would be represented by 
> a single participant element only.
> 
> John (as individual)
> 
> John Elwell
> with 1 or 
> > > more Sessions. According to the XML, a Participant 
> element must have 
> > > single Session (this is consistent with the XML schema but out of 
> > > line with the model) and therefore the Participant "dies" 
> when the 
> > > no longer participating in that Session. If a real 
> participant is in 
> > > two or more sessions, these are different Participant 
> objects (which 
> > > may or may not have sufficient information to tie them to 
> the same 
> > > real participant). This applies whether the participation is in 
> > > sessions in series or in parallel (e.g., active session and held 
> > > session).
> > > >
> > > session. Then a Participant object can be associated with 
> 0 or more 
> > > Session objects (this is out of line with both the model and the 
> > > schema). The XML would then need to change - a 
> Participant attribute 
> > > would no longer be suitable for identifying potentially multiple 
> > > Session elements, so an element with 0 or more instances would be 
> > > needed.
> > > >
> > participant across session to tie together. Group element helps to 
> > group multiple session and participant global unique id helps to 
> > identify the same participant within the single group 
> element. In case 
> > I remember correctly, we earlier concluded that participant has to 
> > have same id through the single session and how its 
> lifetime outside 
> > is based on SRC implementation. </Partha>
> >
> > >
> > > Note that the participant, even if associated with only 
> one session, 
> > > can be associated with multiple media streams, or none.
> > <Partha> I'm missing your point here. Participant is 
> associated with 
> > one or more sessions but I'm not sure abt zero sessions. In 
> case the 
> > > Allowing a participant in multiple CS and multiple MS makes it 
> > > easier and more certain to recognize that it is truly the
> > > *same* participant, rather than a different one with the 
> same AOR. 
> > > This is information that the SRC can know based on the
> > signaling.
> > >
> >
> > <Partha> Agreed. This is specifically required for call centre 
> > scenario wherein multiple transfer between agents happens for the 
> > single CSG but customer happens to be same. Here, customer 
> participant 
> > id is same across multiple CS within single CSG. The participant id 
> > for the next CSG is same or different upto SRC implementation 
> > </Partha>
> >
> > >     Thanks,
> > >     Paul
> > >
> > > > John (as individual)
> > > >
> > > >
> > > > John Elwell
> > > >>> In both cases, the "stop time" can be determined by 
> the time the
> > > >> change
> > > >>> was reported.
> > > >>>

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 28 Jul 2011 06:27:47 -0700

It seems to me that there are really two types of objects we are talking
about. 

1) Participant is a Person's participation of a communication session;
this is really the existing definition of a Participant that has a clear
start/stop time. Since we have trouble modelling a participant joining
multiple CS, either simultaneously and/or sequentially, it occurs to me
that we need a second object, a Person object, that refers to one or more
Participations. 

2) Person object really represents a user agent since we can also have
automata (eg. IVR) as a participant, and can potentially have a long
lifetime. We typically reference a Person object with an AOR. The
Participant can continue to have a participant ID but will refer to Person
object with the AOR.

This is just a suggestion; I think this is less confusing that using a
single type of object where we have trouble defining the lifetime of the
object.

Henry

On 11-07-28 7:56 AM, "Paul Kyzivat" <[email-masked]> wrote:

>> If I interpret your explanation correctly, you are saying that if a
>>Participant object is associated with more than one Communication
>>Session object, there are multiple instances of participant element in
>>XML, each with the same ID but referencing different session elements?
>>That is entirely new to me. I thought a Participant object would be
>>represented by a single participant element only.
>

-------------------------------------------------------------------------------------------------------------------
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: Brad Winslow <[email-masked]>
Date: Thu, 28 Jul 2011 13:29:00 +0000

Hi Folks,

I've been following the conversation on the mailing list and would like to offer this alternative for discussion.

Each CS can reference participants and and media streams by id-reference e.g.

<session id= xxx>
  <participants>			<!-- new element -->
    <id>(participant1 id)<id/>
    <id>(participant2 id)<id/>
	...
    <id>(participantN id)<id/>
  </participants>
  <streams>			<!-- new element -->
    <id>(stream1 id)</id>
	...
    <id>(streamN id)</id>
  </streams>
...
</session>

This approach eliminates the need to 'parent' the media streams and participants to a particular CS, as well as facilitating the sharing of participants and media streams between different CS without redundant specification of either.  The parent id reference is no longer needed on participants or streams and the session clearly calls out the participants and streams.  This approach is also more consistent with the participant usage of <send> and <recv> elements.

Thanks,
Brad Winslow
Acme Packet

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
Sent: Thursday, July 28, 2011 8:25 AM
To: Elwell, John; Paul Kyzivat
Cc: [email-masked]
Subject: Re: [siprec] Participants

John,

Please read inline.

Thanks
Partha 

> XML, each with the same ID but referencing different session elements?

<Partha> Your understanding is correct. The basic design of XML element in metadata with its id and its parent-id is to make the hierarchical data to flat structure which helps for partial update. Hope participant with id & session id as an attribute will meet your requirement of participant in multiple sessions. </Partha>

 That is entirely new 
> to me. I thought a Participant object would be represented by a single 
> participant element only.
> 
> John (as individual)
> 
> John Elwell
> > > >>>>> when that is known to the SRC.
> > > >>>>>>>
> > > >>>>>>>     Thanks,
> > > >>>>>>>     Paul
> > > >>>>>>>

---

From: Leon Portman <[email-masked]>
Date: Thu, 28 Jul 2011 16:32:19 +0300

I like this approach. We can also add capabilities and start stop times on this CS-> Participant relation element

Leon

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 28 Jul 2011 20:09:52 +0530

Hi Brad,

We did brainstorm about using the below format(hierarchical model) for
XML an decided that we will go for flat model ( the current proposed
metadata schema) before IETF 80 which allows us the indicate partial
updates effectively among others.

IMO it's better not to re-visit the entire thing unless we have a strong
reason ( or problem ) in the current proposed XML schema which I have
not seen so far.

Regards,
Ram

> Behalf Of Brad Winslow
> Sent: Thursday, July 28, 2011 9:29 AM
> To: [email-masked]
> I've been following the conversation on the mailing list and would
like
> to offer this alternative for discussion.
> 
> This approach eliminates the need to 'parent' the media streams and
> participants to a particular CS, as well as facilitating the sharing
of
> participants and media streams between different CS without redundant
> specification of either.  The parent id reference is no longer needed
> on participants or streams and the session clearly calls out the
> participants and streams.  This approach is also more consistent with
> the participant usage of <send> and <recv> elements.
> 
> Thanks,
> Brad Winslow
> Acme Packet
> 
> Behalf Of Parthasarathi R (partr)
MK15
> > > > And I agree that we should then allow a participant to be in
zero
> > > > sessions.
> > > > >> participant having association to one CS at instance T0 and
at
> > > > >> instance
> > > > >>>> So again, what exactly are the semantics of start time for
a
> > > > >>> participant?

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 28 Jul 2011 10:42:47 -0400

> This approach eliminates the need to 'parent' the media streams and participants to a particular CS, as well as facilitating the sharing of participants and media streams between different CS witho…

This kind of scheme makes a lot of sense to me, if for no other reason
than it makes the information model more readable as XML.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Brad Winslow <[email-masked]>
Date: Thu, 28 Jul 2011 15:21:17 +0000

Hi Ram,

Thanks for the feedback, I apologize for not being aware of the earlier discussion on the XML model.  My goal was to address the issue of 'parenting' the participants (and media streams) to multiple CSs without duplication of the participant elements.  I suspect the manipulation of the metadata and partial update may be simpler with the suggest approach.  Following the similar approach allows a continuous MS (such as MoH) to enter and exit CSs as needed.

IMO the changes suggested do not create a hierarchical model, the references between participant ids and CSs move to the CS from the participant.  The XML document retains it nearly flat format.

Regards,
Brad

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: Thursday, July 28, 2011 10:40 AM
To: Brad Winslow; [email-masked]
Cc: Joe Hildebrand (jhildebr); Peter Saint-Andre (psaintan)
Subject: RE: [siprec] Participants

Hi Brad,

We did brainstorm about using the below format(hierarchical model) for XML an decided that we will go for flat model ( the current proposed metadata schema) before IETF 80 which allows us the indicate partial updates effectively among others.

IMO it's better not to re-visit the entire thing unless we have a strong reason ( or problem ) in the current proposed XML schema which I have not seen so far.

Regards,
Ram

like
of
MK15
zero
at
a

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 28 Jul 2011 21:40:01 +0530

Hi Brad,

In your proposed schema, the participant addition requires changes in
both <session> and  <participant> element for the partial update whereas
the current model allows to add the participant without impacting
<session> element for the partial update. Please let me know any other
advantage in your proposed mechanism.

In case of readability is the focus, we need to think further because
hierarchical data is better readable than flat stuff which I proposed as
part of -00 draft of metadata format.

Thanks
Partha

> [mailto:[email-masked]] On Behalf Of Brad Winslow
> Sent: Thursday, July 28, 2011 8:51 PM
> To: [email-masked]
> Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr)
> Thanks for the feedback, I apologize for not being aware of 
> the earlier discussion on the XML model.  My goal was to 
> address the issue of 'parenting' the participants (and media 
> streams) to multiple CSs without duplication of the 
> participant elements.  I suspect the manipulation of the 
> metadata and partial update may be simpler with the suggest 
> approach.  Following the similar approach allows a continuous 
> MS (such as MoH) to enter and exit CSs as needed.
> 
> IMO the changes suggested do not create a hierarchical model, 
> the references between participant ids and CSs move to the CS 
> from the participant.  The XML document retains it nearly flat format.
> 
> Regards,
> Brad
> 
> 
> We did brainstorm about using the below format(hierarchical 
> model) for XML an decided that we will go for flat model ( 
> the current proposed metadata schema) before IETF 80 which 
> allows us the indicate partial updates effectively among others.
> 
> IMO it's better not to re-visit the entire thing unless we 
> have a strong reason ( or problem ) in the current proposed 
> XML schema which I have not seen so far.
> 
> Regards,
> Ram
> 
> that if a 
> > > Session object, there are multiple instances of 
> participant element
> > in
> > > > > >>>>>>> And that participant may participate is some 
> but not all
> > > > > >>>>> media streams of each CS.
> > > > > >>>>>>>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 28 Jul 2011 21:55:51 +0530

Adding to my previous mail, there are other partial update mechanism
explored and mentioned during IETF-80 SIPREC meeting.

1) xpath mechanism
2) REST XML mechanism

As per our analysis, the current mechanism is simplest and meet the
needs of SIPREC requirement. I'm fine with exploring further to find
still simpler mechanism exists if any.

Thanks
Partha 

> [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
> Sent: Thursday, July 28, 2011 9:40 PM
> In your proposed schema, the participant addition requires 
> changes in both <session> and  <participant> element for the 
> partial update whereas the current model allows to add the 
> participant without impacting <session> element for the 
> partial update. Please let me know any other advantage in 
> your proposed mechanism.
> 
> In case of readability is the focus, we need to think further 
> because hierarchical data is better readable than flat stuff 
> which I proposed as part of -00 draft of metadata format.
> 
> Thanks
> Partha
> 
> 
> 
> > Thanks for the feedback, I apologize for not being aware of the 
> > earlier discussion on the XML model.  My goal was to 
> address the issue 
> > of 'parenting' the participants (and media
> > streams) to multiple CSs without duplication of the participant 
> > elements.  I suspect the manipulation of the metadata and partial 
> > update may be simpler with the suggest approach.  Following the 
> > similar approach allows a continuous MS (such as MoH) to enter and 
> > exit CSs as needed.
> > 
> > IMO the changes suggested do not create a hierarchical model, the 
> > references between participant ids and CSs move to the CS from the 
> > participant.  The XML document retains it nearly flat format.
> > 
> > Regards,
> > Brad
> > 
> > 
> the current 
> > proposed metadata schema) before IETF 80 which allows us 
> the indicate 
> > partial updates effectively among others.
> > 
> > IMO it's better not to re-visit the entire thing unless we have a 
> > strong reason ( or problem ) in the current proposed XML 
> schema which 
> > I have not seen so far.
> > 
> > Regards,
> > Ram
> > 
> > > > > > single Session (this is consistent with the XML 
> schema but out
> > of
> > > > > > Session elements, so an element with 0 or more 
> instances would
> > be
> > > > > > needed.
> > > > > > >
> > > > > intention to allow the same unique-id of participant 
> even after
> > the
> > > > > id is same across multiple CS within single CSG. The 
> participant
> > id

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 28 Jul 2011 22:20:13 +0530

Hi Brad,

To clarify more, with the schema you proposed  IIUC you will still need
hierarchical model with in a CS( <session> and </session> )since all
your elements within a session are relative to that <session>. So if any
updates(add/deletion) of a participants / streams will require you to
update the session each time with the entire list  of <participants> and
<streams>( I suppose).

And as I see it does not solve the issues of a participant being
*simultaneously* involved in different sessions. In those cases the
properties of participant may be different for each session which means
we would any ways have to send multiple <participant> </participant>
with different properties in the metadata snapshot.  By having the
linkage to session outside, it will be confusing to tell which instance
belongs to which session. 

I am still trying to understand the advantages it has over the current
mechanism ( except for readability).

In case of the current proposed schema in draft, to send an update to a
participant you just need to have as follows:

<?xml version="1.0" encoding="UTF-8"?>
     <recording xmlns='urn:ietf:params:xml:ns:recording'>
   <participant
            id="urn:uuid:cd27cfa1-2bdd-4830-a653-70374d10f103"
            session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425">
            <aor>sip:[email-masked]</aor>
            <send>urn:uuid:50000c9b-9191-40a4-8231-5bcbca5e2b17</send>
            <send>urn:uuid:8b53f3de-da39-4846-93c7-ee5e5f8f6f0b</send>
            <stop-time>2010-12-16T23:41:07Z</start-time>
            <extensiondata>
               <structure>FOO!</structure>
               <whatever>bar</whatever>
           </extensiondata>
    </participant>
</recording>

If readability is the main concern then I agree that hierarchical model
is better. I would like to understand from you if there is any other
issue with proposed model in draft apart from readability.

I am open to suggestions on better encoding.

Thanks,
Ram

> Sent: Thursday, July 28, 2011 12:10 PM
> out
> > > > > > Session elements, so an element with 0 or more instances
> would
> > be
> > > > > > needed.
> > > > > > >
> > > > > intention to allow the same unique-id of participant even
after

---

From: Brad Winslow <[email-masked]>
Date: Thu, 28 Jul 2011 18:06:53 +0000

Hi Ram,

You correctly point out a partial update would be required to update several metadata items in the XML model as suggested by my changes to maintain consistency.  Leon's observation that start/stop elements could be nested under the <participants><id> tags was insightful. IIUC, the partial update could be accomplished with only the <session> element being transmitted when a participant leaves the CS (with Leon's modification).  This allows for the stop times on the participant and participant's media streams to be expressed within the <session> element. 

I understand your point about the need for multiple participant elements, since each requires a session attribute to associate the <participant> sub elements with the CS (such as stop time).

Should a participant leave a CS, I presume the partial metadata update would also include the <stream> elements and their <stop-time> sub-elements as well, or is this to be presumed when a participant 'stops'.

Thanks,
Brad

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: Thursday, July 28, 2011 12:50 PM
To: Parthasarathi R (partr); Brad Winslow; [email-masked]
Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr)
Subject: RE: [siprec] Participants

Hi Brad,

To clarify more, with the schema you proposed  IIUC you will still need hierarchical model with in a CS( <session> and </session> )since all your elements within a session are relative to that <session>. So if any
updates(add/deletion) of a participants / streams will require you to update the session each time with the entire list  of <participants> and <streams>( I suppose).

And as I see it does not solve the issues of a participant being
*simultaneously* involved in different sessions. In those cases the properties of participant may be different for each session which means we would any ways have to send multiple <participant> </participant> with different properties in the metadata snapshot.  By having the linkage to session outside, it will be confusing to tell which instance belongs to which session. 

I am still trying to understand the advantages it has over the current mechanism ( except for readability).

In case of the current proposed schema in draft, to send an update to a participant you just need to have as follows:

If readability is the main concern then I agree that hierarchical model is better. I would like to understand from you if there is any other issue with proposed model in draft apart from readability.

Thanks,
Ram

> both <session> and  <participant> element for the partial update 
> whereas the current model allows to add the participant without 
> impacting <session> element for the partial update. Please let me know 
> any other advantage in your proposed mechanism.
> 
> hierarchical data is better readable than flat stuff which I proposed 
> as part of -00 draft of metadata format.
> 
> Thanks
> Partha
> 
> 
> 
> > earlier discussion on the XML model.  My goal was to address the 
> > issue of 'parenting' the participants (and media
> > model) for XML an decided that we will go for flat model ( the 
> > current proposed metadata schema) before IETF 80 which allows us the 
> > indicate partial updates effectively among others.
> >
> > strong reason ( or problem ) in the current proposed XML schema 
> > which I have not seen so far.
> >
> > Regards,
> > Ram
> >
after
> > > > > > >>>>>>>> siprec mailing list [email-masked]

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 29 Jul 2011 00:05:24 +0530

Brad,

Please read inline

Thanks
Partha 

> From: Brad Winslow [mailto:[email-masked]] 
> Sent: Thursday, July 28, 2011 11:37 PM
> To: Ram Mohan R (rmohanr); Parthasarathi R (partr); [email-masked]
> You correctly point out a partial update would be required to 
> update several metadata items in the XML model as suggested 
> by my changes to maintain consistency.  Leon's observation 
> that start/stop elements could be nested under the 
> <participants><id> tags was insightful. IIUC, the partial 
> update could be accomplished with only the <session> element 
> being transmitted when a participant leaves the CS (with 
> Leon's modification).  This allows for the stop times on the 
> participant and participant's media streams to be expressed 
> within the <session> element. 
> 
> I understand your point about the need for multiple 
> participant elements, since each requires a session attribute 
> to associate the <participant> sub elements with the CS (such 
> as stop time).
> 
> Should a participant leave a CS, I presume the partial 
> metadata update would also include the <stream> elements and 
> their <stop-time> sub-elements as well,

<Partha> It is not required for mixed media stream. In case unmixed
streams, it is better to stop both stream & participant at the same time
</Partha>

 or is this to be 
> presumed when a participant 'stops'.
> 
> Thanks,
> Brad
> 
> 
> To clarify more, with the schema you proposed  IIUC you will 
> still need hierarchical model with in a CS( <session> and 
> </session> )since all your elements within a session are 
> relative to that <session>. So if any
> updates(add/deletion) of a participants / streams will 
> require you to update the session each time with the entire 
> list  of <participants> and <streams>( I suppose).
> 
> *simultaneously* involved in different sessions. In those 
> cases the properties of participant may be different for each 
> session which means we would any ways have to send multiple 
> <participant> </participant> with different properties in the 
> metadata snapshot.  By having the linkage to session outside, 
> it will be confusing to tell which instance belongs to which session. 
> 
> I am still trying to understand the advantages it has over 
> the current mechanism ( except for readability).
> 
> In case of the current proposed schema in draft, to send an 
> update to a participant you just need to have as follows:
> 
> If readability is the main concern then I agree that 
> hierarchical model is better. I would like to understand from 
> you if there is any other issue with proposed model in draft 
> apart from readability.
> 
> changes in 
> > > > > to me. I thought a Participant object would be 
> represented by a
> > > > single
> > > > > > the participant to be included in multiple session 
> at the same
> > > > time.
> > > > > > > I see no reason why the association with sessions 
> should be
> > > > > > different.
> > > > > > > >>> Similarly the stopping of the participation 
> in a CS can
> > be
> > > > > > > >> determined
> > > > > > > >>> by
> > > > > > > >>> Its starting to appear problematic to attach 
> start/stop
> > > > > > > to anything.
> > > > > > > >>>> Likewise, when the participant rejoins the 
> CS or a new
> > > > > > > >> CS, it gains
> > > > > > > >> a
> > > > > > > >>>>>> e.g. participant-A is in RS-1, RS-1 
> terminates, RS-2
> > > > starts
> > > > > > > >>>>>> Or it is intended to only be unique for 
> the duration
> > in
> > > > > > > >>>>>>>> to any other metadata object?  
> Participant IDs may
> > > > differ
> > > > > > > >>>>>>> Also, the AoR of a participant is not 
> necessarily a
> > > > unique

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 29 Jul 2011 14:04:39 +0200

This is an interesting suggestion, and I note the long thread of discussion that has already taken place.

The reason we ended up with the present flat structure was that people felt it would be best for partial updates. I think the main case was a large conference with many participants. With the present structure a participant can leave or join and it is only necessary to update the participant element, not the session element. So it is a trade-off between readability and efficiency. Please keep discussing this.

In particular, we should try to identify whether the issues raised at the meeting yesterday can be addressed satisfactorily using the present structure, or whether they too would be more easily addressed with the more readable structure.

John

John Elwell

> Sent: 28 July 2011 14:29
> I've been following the conversation on the mailing list and 
> would like to offer this alternative for discussion.
> 
> This approach eliminates the need to 'parent' the media 
> streams and participants to a particular CS, as well as 
> facilitating the sharing of participants and media streams 
> between different CS without redundant specification of 
> either.  The parent id reference is no longer needed on 
> participants or streams and the session clearly calls out the 
> participants and streams.  This approach is also more 
> consistent with the participant usage of <send> and <recv> elements.
> 
> Thanks,
> Brad Winslow
> Acme Packet