Subject: [siprec] Need Inputs: How to represent attributes of association in metadata Model and in XML ?

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 12 Oct 2011 11:18:09 +0530

(Sorry for lengthy e-mail)

Hi All,

In the last interim we discussed 4 approaches for representing
attributes of association in XML.

Here are some pros/cons for each of them:
Approach 1: 
----------
Represent the association attribute as a property within one of the
associated elements. Example given at
http://www.ietf.org/mail-archive/web/siprec/current/msg02709.html Does
not need another XML element and represents the association attributes
as capability of one of the association element. 
e.g.
<participant
           id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"
           session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> 
                 <aor>sip:[email-masked]</aor>
                 <associate-time>2010-12-16T23:41:07Z</associate-time>
                 <capabilities> TBD</capabilties>
                 <participantStreamAssoc  
                  stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a
">
                   <associate-time>2010-12-16T23:41:07Z</associate-time>
                   <csrc>contributing SSRC-1</csrc>   
                 </participantStreamAssoc>
 </participant>
In the above example the participant contributes a single streams. For
each stream the association attribute (participant-stream) is shown with
the stream ID nested in. 

Approach 2:
----------- 
In this approach we have a new XML element for every association class.
This xml element will NOT have a unique ID instead it references the ID
of associated elements (shown below). With this approach it is easy to
update as the association class is a separate XML element and not
property.
e.g.
<participantSessionAssoc 
 participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"  
 session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425">
  <associate-time>2010-12-16T23:41:07Z</associate-time>
  <capabilities> TBD</capabilties>
</participantSessionAssoc>

<participantStreamAssoc  
 participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"
 stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a ">
    <associate-time>2010-12-16T23:41:07Z</associate-time>
    <csrc>contributing SSRC-1</csrc>   
</participantStreamAssoc>

Approach 3 and 4 are in the below e-mail from John.
Approach 3 defines a new Unique ID for every association XML elment.
Also it creates alias for the other IDs. In the discussions in interim
there was no strong support for this approach.

Approach 4 is same as approach 1 where in the association element is
encapsulated in one of  the XML elements (to which it is associated). In
addition to that it also has reference to the elements (alias of IDs) to
which the association belongs.

I prefer approach 2 as it is has a separate XML element to represent the
association class. The only difference of this XML element from others
is this does not need a unique ID. Instead it references the IDs of the
elements to which the association belongs.
Since association class is a special class meant to associate multiple
classes, I see it ok to have a representation as in approach 2 where in
the identifier is the concatenation of the classes to which the
association belongs to.

Please provide your comments on this and also suggest any other
approaches to represent association classes in XML.

Regards,
Ram

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ram Mohan R (rmohanr)
> Sent: Friday, September 23, 2011 1:32 PM
> To: Elwell, John; [email-masked]
> Subject: Re: [siprec] #72: How to represent attributes of
> associationinmetadata Model and in XML ?
> 
> John,
> 
> Lets discuss these two approaches along with the other two in today's
> meeting. I have added these to the slides.
> 
> Regards,
> Ram
> 
> > -----Original Message-----
> > From: Elwell, John [mailto:[email-masked]]
> > Sent: Friday, September 23, 2011 1:01 PM
> > To: Ram Mohan R (rmohanr); siprec issue tracker
> > Cc: [email-masked]
> > Subject: RE: [siprec] #72: How to represent attributes of
association
> > inmetadata Model and in XML ?
> >
> > Ram,
> >
> > I don't like having to use the combination of participant unique ID
> and
> > session unique ID for uniquely identifying a <participant/> element
> as
> > proposed in approach 1, and therefore of the two approaches here I
> > prefer approach 2.
> >
> > Unfortunately approach 2 gets extremely verbose, particularly if we
> > apply the same approach to associations between stream and
> participant.
> > Consider a 20 party conference with 2 streams, audio and video (not
> an
> > extreme example, but good enough to illustrate my point). Each
> > participant is sending and receiving both streams. This means 80
> > associations between participant and stream. Each association
element
> > has its own unique ID, plus IDs referencing a <participant/> element
> > and a <stream/> element. A total of 240 unique IDs on the wire just
> to
> > represent these associations. Taking the example unique ID below
with
> > 45 characters, this is 10800 characters for the IDs alone. I am not
> > sure whether this is a problem of not.
> >
> > A couple of alternative approaches:
> >
> > Approach 3: Define local IDs as aliases for globally unique IDs.
This
> > approach reduces the number of unique IDs on the wire per
association
> > from 3 to 1, replacing them with local IDs. Of course, the local IDs
> > have to be defined. This might marginally penalize the VERY simple
> > cases, but saves significantly for more complex situations.
> > e.g.:
> > <session
> > 	id="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"
> > 	local="123">
> > ...
> > </session>
> >
> > <participant
> > 	id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"
> > 	local="234">
> > ...
> > </participant>
> >
> > <participantSessionAssoc
> > 	id="urn:uuid:acdf43ee-1441-478d-4eca-4d4f555a896d"
> > 	participant="234"
> > 	session="123">
> > ...
> > </participantSessionAssoc
> >
> >
> > Approach 4: Encapsulate associations within one of the object
> elements
> > concerned, e.g., encapsulate sequence of participants in the
> <session/>
> > element. This approach reduces the number of unique IDs on the wire
> per
> > association from 3 to 1.
> > e.g.:
> > <session
> > 	id="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425">
> > ....
> >   <sessionParticipant
> > 	participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3">
> >     ....
> >   </sessionParticipant>
> > </session>
> >
> > <participant
> > 	id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3">
> > ...
> > </participant>
> >
> > Or alternatively:
> > <session
> > 	id="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425">
> > ....
> >   <participants>
> >     <sessionParticipant
> > 	  participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3">
> >       ....
> >     </sessionParticipant>
> >   </participants>
> > </session>
> >
> > <participant
> > 	id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3">
> > ...
> > </participant>
> >
> > A further remark on approach 4. This means that you can't send a
> > partial update conveying only an association - you have to send the
> > whole element in which the association is embedded. So in the
example
> > above, if a participant drops out of a session you would have to
send
> > the whole <session/> element. So this might be a reason for
embedding
> > the associations in a <participant/> element instead, if we consider
> a
> > given participant is unlikely to be in more than a handful of
> sessions.
> >
> > John (as individual)
> >
> > > -----Original Message-----
> > > From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
> > > Sent: 22 September 2011 17:57
> > > To: Elwell, John; siprec issue tracker
> > > Cc: [email-masked]
> > > Subject: RE: [siprec] #72: How to represent attributes of
> > > association inmetadata Model and in XML ?
> > >
> > > Hi John,
> > >
> > > Please see inline.
> > >
> > > > -----Original Message-----
> > > > From: Elwell, John [mailto:[email-masked]]
> > > > Sent: Thursday, September 22, 2011 8:47 PM
> > > > To: Ram Mohan R (rmohanr); siprec issue tracker
> > > > Cc: [email-masked]
> > > > Subject: RE: [siprec] #72: How to represent attributes of
> > > association
> > > > inmetadata Model and in XML ?
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked]
> > > > > [mailto:[email-masked]] On Behalf Of Ram Mohan R
> > > (rmohanr)
> > > > > Sent: 22 September 2011 11:11
> > > > > To: siprec issue tracker
> > > > > Cc: [email-masked]
> > > > > Subject: Re: [siprec] #72: How to represent attributes of
> > > > > association in metadata Model and in XML ?
> > > > >
> > > > > I have not seen any inputs on this so far. In the last
> > > > > discussion we had on Monday we discussed to ways to represent
> > > > > attributes of association. Can folks look at these and
> > > > > provide inputs and also other ways to represent attributes of
> > > > > association ?
> > > > >
> > > > > Use-case:
> > > > > ---------
> > > > > A participant who is simultaneously in multiple sessions
> > > > > having different capabilities(this attribute is an attribute
> > > > > of association).
> > > > >
> > > > > Approach 1:
> > > > > -----------
> > > > > Session 1 having participant 1:
> > > > >         <participant
> > > > >            id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"
> > > > >
> > > session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425">
> > > > >                  <aor>sip:[email-masked]</aor>
> > > > >
> <associate-time>2010-12-16T23:41:07Z</associate-
> > > > time>
> > > > >                  <capabilities> TBD</capabilties>
> > > > >          </participant>
> > > > > Session 2 having the same participant 1:
> > > > >
> > > > >         <participant
> > > > >             id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"
> > > > >
> > > session="urn:uuid:cd27cfa1-2bdd-4830-a653-70374d10f103">
> > > > >                  <aor>sip:[email-masked]</aor>
> > > > >
> <associate-time>2010-12-16T23:41:07Z</associate-
> > > > time>
> > > > >                  <capabilities> TBD</capabilties>
> > > > >          </participant>
> > > > >
> > > > > Here the session ID is different and it's the same
> > > > > participant ID across both sessions.
> > > > >
> > > > > In this approach all the association attributes are encoded
> > > > > within the <participant> element as the participant already
> > > > > has session ID of the session to which it is associated.
> > > > >
> > > > > Pros: This is simple as we are just adding capabilities to
> > > > > the existing participant element and hence it does not
> > > > > require any additional ID.
> > > > [JRE] If I understand the proposal correctly there is a possible
> > > > problem. The example shows two <participant/> elements with the
> > same
> > > > unique ID. If the SRC sends a partial update that contains a
> > > > <participant/> element, the SRS can't use its unique ID alone to
> > > > identify the particular element that has changed. The SRS has to
> > use
> > > > the combination of the element's unique ID and the
> > > referenced session
> > > > unique ID. I am not sure this is a problem, but it is certainly
a
> > > > change from what we have discussed in the past, and it
> > > means rules for
> > > > matching become more complex. To some extent it defeats the
> > > purpose of
> > > > having a unique ID for a participant.
> > >
> > > True. I agree with your point. The last time this proposal was
made
> > by
> > > Partha, I remember there was a feedback on the similar lines.
> > > This issue
> > > is going to be present for any attribute of participant not just
> > > association attribute whenever a participant is simultaneously
> > present
> > > in multiple sessions.
> > >
> > > As you mentioned below the combination of participant ID and
> > > session ID
> > > (association) can serve as unique ID in cases where a participant
> is
> > > simultaneously in multiple sessions.
> > >
> > > Ram
> > >
> > > >
> > > > Let's try another case. The SRC sends a partial update with a
> > > > <participant/> element whose referenced session is
> > > different from that
> > > > of any existing <participant/> element with that same
> > > unique ID. Does
> > > > this mean the SRS has to add a new <participant/> element to its
> > > model?
> > > > Again this seems to be contrary to my earlier understanding that
> > you
> > > > only add something if you receive something with a new unique
ID.
> > > >
> > > > I believe up till now a complete XML document would never have
> two
> > > > elements with the same unique ID. This principle (if that
> > > was people's
> > > > understanding) now seems to be destroyed.
> > > >
> > > > Basically the combination of <participant/> unique ID and
> > <session/>
> > > > unique ID becomes the unique ID for the association - not
> > > necessarily
> > > > wrong, but I do wonder whether having a unique ID for a
> participant
> > > > element is rather pointless when it alone is not usable as
unique
> > > > identification for an element.
> > > >
> > > > John (as individual)
> > > >
> > >
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: Leon Portman <[email-masked]>
Date: Wed, 12 Oct 2011 09:25:15 +0200

Ram Hi

I am ok with approaches 1 and  however I do prefer approach one because it will be easier for SRS to get decode - association is inside relevant element. And it is more readable.
Approach 2 will work as well, however it is important that if there will be a change in association then to send to SRS not only updated association element but also related elements: for example if stream was associated to participant and session, send also participant and session latest state.

Regards

Leon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
Sent: Wednesday, October 12, 2011 7:48 AM
To: [email-masked]
Subject: [siprec] Need Inputs: How to represent attributes of association in metadata Model and in XML ?

Hi All,

In the last interim we discussed 4 approaches for representing attributes of association in XML.

Represent the association attribute as a property within one of the associated elements. Example given at http://www.ietf.org/mail-archive/web/siprec/current/msg02709.html Does not need another XML element and represents the association attributes as capability of one of the association element. 
                 </participantStreamAssoc>  </participant> In the above example the participant contributes a single streams. For each stream the association attribute (participant-stream) is shown with the stream ID nested in. 

Approach 2:
-----------
This xml element will NOT have a unique ID instead it references the ID of associated elements (shown below). With this approach it is easy to update as the association class is a separate XML element and not property.

<participantStreamAssoc

Approach 3 and 4 are in the below e-mail from John.
Approach 3 defines a new Unique ID for every association XML elment.
Also it creates alias for the other IDs. In the discussions in interim there was no strong support for this approach.

Approach 4 is same as approach 1 where in the association element is encapsulated in one of  the XML elements (to which it is associated). In addition to that it also has reference to the elements (alias of IDs) to which the association belongs.

I prefer approach 2 as it is has a separate XML element to represent the association class. The only difference of this XML element from others is this does not need a unique ID. Instead it references the IDs of the elements to which the association belongs.
Since association class is a special class meant to associate multiple classes, I see it ok to have a representation as in approach 2 where in the identifier is the concatenation of the classes to which the association belongs to.

Please provide your comments on this and also suggest any other approaches to represent association classes in XML.

Regards,
Ram

association
element
with
This
association
example
send
embedding
> > > > > attributes of association. Can folks look at these and provide 
> > > > > inputs and also other ways to represent attributes of 
> > > > > association ?
> > > > >
> > > > > Use-case:
> > > > > ---------
> > > > > Here the session ID is different and it's the same participant 
> > > > > ID across both sessions.
> > > > >
> > > > > Pros: This is simple as we are just adding capabilities to the 
> > > > > existing participant element and hence it does not require any 
> > > > > additional ID.
a
made
ID.
unique

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 12 Oct 2011 14:21:57 +0530

Leon,
Thanks for your response. One of the adv with approach 2 is we can
indicate only changes in the association without the need to indicating
the elements ( of association). IOW for the below example, if there is a
change in participant-stream association I can simply send the following
in partial update:

<participantStreamAssoc 
 stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a">
     <disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantStreamAssoc>

Do you see a need to always indicate the related elements too ? In which
case I see approach 1 as more suitable.

Thanks,
Ram

> From: Leon Portman [mailto:[email-masked]]
> Sent: Wednesday, October 12, 2011 12:55 PM
> To: Ram Mohan R (rmohanr); [email-masked]
> Cc: Ofir Roth
> Subject: RE: Need Inputs: How to represent attributes of association
> I am ok with approaches 1 and  however I do prefer approach one
because
> it will be easier for SRS to get decode - association is inside
> relevant element. And it is more readable.
> Approach 2 will work as well, however it is important that if there
> will be a change in association then to send to SRS not only updated
> association element but also related elements: for example if stream
> was associated to participant and session, send also participant and
> session latest state.
> 
> Regards
> 
> Leon
> 
> 
> Subject: [siprec] Need Inputs: How to represent attributes of
> associated elements. Example given at http://www.ietf.org/mail-
> archive/web/siprec/current/msg02709.html Does not need another XML
> element and represents the association attributes as capability of one
> of the association element.
> e.g.
> <participant
>                  </participantStreamAssoc>  </participant> In the
above
> example the participant contributes a single streams. For each stream
> the association attribute (participant-stream) is shown with the
stream
> ID nested in.
> encapsulated in one of  the XML elements (to which it is associated).
> In addition to that it also has reference to the elements (alias of
> IDs) to which the association belongs.
> 
> I prefer approach 2 as it is has a separate XML element to represent
> the association class. The only difference of this XML element from
> others is this does not need a unique ID. Instead it references the
IDs
> of the elements to which the association belongs.

---

From: Leon Portman <[email-masked]>
Date: Wed, 12 Oct 2011 10:54:20 +0200

We do prefer to receive related elements as well, it makes implementation much easier.
 At least we should get relevant IDs.  For example below, SRC should also send ParticipantId

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: Wednesday, October 12, 2011 10:52 AM
To: Leon Portman; [email-masked]
Cc: Ofir Roth
Subject: RE: Need Inputs: How to represent attributes of association in Metadata Model and in XML ?

Leon,
Thanks for your response. One of the adv with approach 2 is we can indicate only changes in the association without the need to indicating the elements ( of association). IOW for the below example, if there is a change in participant-stream association I can simply send the following in partial update:

<participantStreamAssoc

Do you see a need to always indicate the related elements too ? In which case I see approach 1 as more suitable.

Thanks,
Ram

because
above
stream
IDs

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 12 Oct 2011 14:26:54 +0530

My bad(typo) while sending the example. The correct partial update I
intended to send  is: 

<participantStreamAssoc

This is inline with approach 2 where in each association XML element
will have the IDs of the related associated elements.

Ram

> Sent: Wednesday, October 12, 2011 2:24 PM
in
> Metadata Model and in XML ?
> 
in
> Metadata Model and in XML ?
> 
> Leon,
> the elements ( of association). IOW for the below example, if there is
> a change in participant-stream association I can simply send the
> following in partial update:
> 
> 
> <participantStreamAssoc
> Do you see a need to always indicate the related elements too ? In
> which case I see approach 1 as more suitable.
> 
> Thanks,
> Ram
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Oct 2011 13:17:36 -0400

I like approach 2, as Ram has shown it. It deals with the problems John 
raised with the others.

I didn't follow John's arithmetic on this one, using his 20 party 
conference example. As I count that, there are 21 participants when you 
include the focus. Each of the 20 has two stream/participant 
associations with the focus, for a total of 40. (The association is 
bidirectional. I can only get to 80 by assuming we had to represent an 
association in each direction.) And each has two ids, each of which is 
also the id of a stream or participant. So there are really only 23 
distinct ids that need to be assigned for this. (One for each of the 21 
participants, and one for each of the two streams.)

The 40 associations, each carrying two ids, is still kind of a lot if 
its sent all at once. But when starting up a conference they will 
probably be added gradually as each participant joins. Same at the end 
if they drop off individually. But it could be a bunch together if the 
conference is forcibly dropped by the focus. But it does minimize what 
is sent when things happen incrementally.

There may be some optimizations that can be done - e.g. a sort of 
"wildcard" for one of the the two ids in the association class. E.g.

<participantStreamAssoc
   participant="*"

(I'm not advocating that particular syntax. Its just something to make 
the point.)

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 14 Oct 2011 09:29:12 +0530

Thanks Paul for your comments. I also prefer approach 2 as mentioned
below in this thread.
I will wait to hear for comments/opinion from others.

Ram

> Behalf Of Paul Kyzivat
> Sent: Thursday, October 13, 2011 10:48 PM
> To: [email-masked]
> Subject: Re: [siprec] Need Inputs: How to represent attributes of
> association in Metadata Model and in XML ?
> 
> >>   At least we should get relevant IDs.  For example below, SRC
> should
> >> also send ParticipantId
> >>
> >>> This xml element will NOT have a unique ID instead it references
> the
> >> ID
> >>> of associated elements (shown below). With this approach it is
easy
> >>> classes, I see it ok to have a representation as in approach 2
> where
> >> in

---

From: Brad Winslow <[email-masked]>
Date: Fri, 14 Oct 2011 13:49:14 +0000

Hi Folks,

I believe the association elements complicate the metadata model.  It seems to me, unless I'm being naïve, that the SRC would introduce the participant and the steam elements into the CS at the same time.  The association mechanism as described doesn't seem to support the notion of side conversations, as the <send/> and <recv/> elements are capable of doing.  If the <send/> and <recv/> elements remain in the metadata, I'm not sure what benefit the association elements provide.

Thanks,
Brad

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
Sent: Thursday, October 13, 2011 11:59 PM
To: Paul Kyzivat; [email-masked]
Subject: Re: [siprec] Need Inputs: How to represent attributes of association in Metadata Model and in XML ?

Thanks Paul for your comments. I also prefer approach 2 as mentioned below in this thread.
I will wait to hear for comments/opinion from others.

Ram

easy
> >>>    <capabilities>  TBD</capabilties> </participantSessionAssoc>
> >>>
> >>> <participantStreamAssoc
> >>>      <csrc>contributing SSRC-1</csrc> </participantStreamAssoc>
> >>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Oct 2011 12:21:44 -0400

> Approach 2 will work as well, however it is important that if there will be a change in association then to send to SRS not only updated association element but also related elements: for example i…

The intent is to send changed elements, including sufficient information 
to understand which element it is, and thus how it relates to previously 
sent and unchanged elements. At the same time the goal is to avoid 
transmitting unchanged elements.

So current proposal is that "regular" elements have one ID that 
identifies them. So that has to be sent when sending an update to that 
element.

Association Classes aren't identified by a single ID. Rather they are 
identified by the IDs of the two things they associate. Thus when 
updating them those two IDs need to be transmitted. (Doing it this way 
is a choice - there are other ways, but this so far seems a reasonable way.)

Are you asking that additional redundant info be supplied when sending 
an update to an association class?

	Thanks,
	Paul

>>> session unique ID for uniquely identifying a<participant/>  element
>> as
>>> has its own unique ID, plus IDs referencing a<participant/>  element
>>> and a<stream/>  element. A total of 240 unique IDs on the wire just
>> to
>>> the whole<session/>  element. So this might be a reason for
> embedding
>>> the associations in a<participant/>  element instead, if we consider
>> a
>>>>>> within the<participant>  element as the participant already
>>>>> problem. The example shows two<participant/>  elements with the
>>> same
>>>>> of any existing<participant/>  element with that same
>>>> unique ID. Does
>>>>> this mean the SRS has to add a new<participant/>  element to its
>>>> model?
>>>>> Basically the combination of<participant/>  unique ID and
>>> <session/>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 17 Oct 2011 15:23:42 +0530

Hi Brad,

If I understand your question correct you are asking why association class is needed right ?

We had several discussions before  and in IETF81 meeting we reached to a consensus that certain attributes in the current model (e.g. attributes of participant like callee capabilities, stream attributes like association/disassociation time, csrc) which are attributes of association and NOT attributes of the element. 
See minutes - http://www.ietf.org/mail-archive/web/siprec/current/msg02511.html
More at http://www.ietf.org/mail-archive/web/siprec/current/msg02692.html

Hence we introduced association class and this mail is discussing the possible representations in XML for the same.

Some use-cases are:
In case of mixed stream we can have multiple participants contributing to the stream and a participant may be contributing to multiple streams also. In these cases the attributes that link participant to stream like time, csrc are association attributes
Capabilities of participant are again attributes of association of participant to a session as a participant may have different capabilities (e.g. a participant may be a end point in session 1 and then focus in session 2).

Now regarding the representation for association class, we seem to be narrowing down is approach 2 

If you have other ways to represent association class in the metadata XML document, Please suggest.

Thanks,
Ram

> Behalf Of Brad Winslow
> Sent: Friday, October 14, 2011 7:19 PM
> To: [email-masked]
> Subject: Re: [siprec] Need Inputs: How to represent attributesof
> I believe the association elements complicate the metadata model.  It
> seems to me, unless I'm being naïve, that the SRC would introduce the
> participant and the steam elements into the CS at the same time.  The
> association mechanism as described doesn't seem to support the notion
> of side conversations, as the <send/> and <recv/> elements are capable
> of doing.  If the <send/> and <recv/> elements remain in the metadata,
> I'm not sure what benefit the association elements provide.
> 
> Thanks,
> Brad
> 
> > >> the elements ( of association). IOW for the below example, if
> there
> > is
> > >>> element and represents the association attributes as capability
> of
> > >> one

---

From: "John Elwell" <[email-masked]>
Date: Thu, 27 Oct 2011 09:33:26 +0100

Approach 2 seems reasonable. Could we say that an association is implicitly 
deleted (gains a dissociate time) as soon as one of the associated elements 
is deleted (gains a dissociate time)? This would reduce the on-the wire 
document size for both partial and full metadata in some circumstances 
(e.g., conference termination by the focus).

John

----- Original Message ----- 
From: "Ram Mohan R (rmohanr)" <[email-masked]>
To: "Paul Kyzivat" <[email-masked]>; <[email-masked]>
Sent: Friday, October 14, 2011 4:59 AM
Subject: Re: [siprec] Need Inputs: How to represent attributes ofassociation 
in Metadata Model and in XML ?

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Oct 2011 12:47:03 -0400

On 10/27/11 4:33 AM, John Elwell wrote:
> Approach 2 seems reasonable. Could we say that an association is
> implicitly deleted (gains a dissociate time) as soon as one of the
> associated elements is deleted (gains a dissociate time)? This would
> reduce the on-the wire document size for both partial and full metadata
> in some circumstances (e.g., conference termination by the focus).

I *think* that would be reasonable.
It would be good to have someone that is actively working on an 
implementation comment on it.

	Thanks,
	Paul

> John
>
>
> ----- Original Message ----- From: "Ram Mohan R (rmohanr)"
> <[email-masked]>
> Subject: Re: [siprec] Need Inputs: How to represent attributes
> ofassociation in Metadata Model and in XML ?
>
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 27 Oct 2011 22:38:22 +0530

Hi John,

Thanks for your comment on this. Yes several of us seem to be inclined
towards approach 2.  I like your point that once one of the elements in
the association gets deleted, the association element life ends. SRC may
choose to send the association element optionally or the SRS can still
learn that as the way you mentioned. 

We ( authors of metadata draft ) discussed internally on this open item
and see some issues with adopting approach 2 as is with the current
model /schema. I will start a separate mail thread for the issue as this
thread is already too long.

Thanks,
Ram

> From: John Elwell [mailto:[email-masked]]
> Sent: Thursday, October 27, 2011 2:03 PM
> To: Ram Mohan R (rmohanr); Paul Kyzivat; [email-masked]
> implicitly
> >> distinct ids that need to be assigned for this. (One for each of
the
> > 21
> >> > My bad(typo) while sending the example. The correct partial
update
> I
> >> >>> was associated to participant and session, send also
participant
> >> >>>                   </participantStreamAssoc>   </participant>
In
> >> >>> In this approach we have a new XML element for every
association
> >> >> class.
> >> >>> Approach 4 is same as approach 1 where in the association
> element
> >> is
> >> >>> In addition to that it also has reference to the elements
(alias

---

From: <[email-masked]>
Date: Thu, 27 Oct 2011 18:44:53 +0100

I am not clear on the effect on the other XMl elements.

I presume the participant - CS  <session> element will be replaced by the< participantSessionAssoc>.

I also presume <send> and <recv>  will no longer be needed, and that the  <participantStream Assoc> will include an attribute to say send or recv ?

Is that correct ?

I hope the rule will remain that,  in the abscence of any recv elements by default a stream is assumed to be recieved by all participants.

Rgds
John Stafford | Solution Architect 1 | BT Global Services 

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Ram Mohan R (rmohanr) [[email-masked]]
Sent: 27 October 2011 18:08
To: John Elwell; Paul Kyzivat; [email-masked]
Subject: Re: [siprec] Need Inputs: How to represent attributes ofassociation    in Metadata Model and in XML ?

Hi John,

Thanks,
Ram

the
update
participant
In
association
(alias

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 28 Oct 2011 19:04:23 +0530

Hello John S,

Please see inline for answers.

> Behalf Of [email-masked]
> Sent: Thursday, October 27, 2011 11:15 PM
> To: [email-masked]
> Subject: Re: [siprec] Need Inputs: How to represent
> attributesofassociation in Metadata Model and in XML ?
> 

No. <session> will continue to remain. We are talking about association
attributes of participant-session.
The other attributes of <participant> and <session> which are not
association attributes will continue to be the respective elements.

> 
> I also presume <send> and <recv>  will no longer be needed, and that
> the  <participantStream Assoc> will include an attribute to say send
or
> recv ?

This is a good suggestion. I have not given a thought on this so far. In
principle this should be fine as once the association of a participant
to a stream ends it stops sending/receiving the same. We need to think
through different use-cases to see if its fine to have <send>, <recv>
inside association element itself. By having send, recv inside the
association we can avoid one XML element as they can be attribute.

> 
> Is that correct ?
> 
> I hope the rule will remain that,  in the abscence of any recv
elements
> by default a stream is assumed to be recieved by all participants.

No, in the last IETF we agreed it's better to always explicity indicate
recv. We will continue to stick to that as I see no reason to change.

Regards,
Ram

> From: [email-masked] [[email-masked]] On Behalf Of
> Ram Mohan R (rmohanr) [[email-masked]]
> > >> I like approach 2, as Ram has shown it. It deals with the
problems
> > >> conference example. As I count that, there are 21 participants
> when
> > > you
> > >> bidirectional. I can only get to 80 by assuming we had to
> represent
> > an
> > >> association in each direction.) And each has two ids, each of
> which
> > is
> > >> The 40 associations, each carrying two ids, is still kind of a
lot
> > if
> > >> probably be added gradually as each participant joins. Same at
the
> > end
> > >> if they drop off individually. But it could be a bunch together
if
> > >> >> Do you see a need to always indicate the related elements too
?
> > >> >>> From: [email-masked]
[mailto:[email-masked]]
> > On
> > >> >>> Represent the association attribute as a property within one
> of
> > > the
> http://www.ietf.org/mail-
> > >> >>> archive/web/siprec/current/msg02709.html Does not need
another
> > XML
> > >> >>> example the participant contributes a single streams. For
each
> > >> >>> Also it creates alias for the other IDs. In the discussions
in
> > >> >> interim
> > >> >>> the association class. The only difference of this XML
element
> > > from
> > >> >>> others is this does not need a unique ID. Instead it
> references
> > > the
> > >> >> IDs

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Fri, 28 Oct 2011 19:12:38 +0530

Hi,

IMO, send & recv are the element which has to be pushed inside
participant stream association element which is inline with the model.

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On
Behalf
>Of Ram Mohan R (rmohanr)
>Sent: Friday, October 28, 2011 7:04 PM
>To: [email-masked]; [email-masked]
>Subject: Re: [siprec] Need Inputs: How to
>representattributesofassociation in Metadata Model and in XML ?
>
>Hello John S,
>
of
>> > >> conference is forcibly dropped by the focus. But it does
minimize
>> > what
>> > >> (I'm not advocating that particular syntax. Its just something
to
>> > make
>> > >> >> Thanks for your response. One of the adv with approach 2 is
we
>> > can
>> > >> >>> Approach 2 will work as well, however it is important that
if
>> > >> >>> association element but also related elements: for example
if
>> > >> >>>                   <capabilities>  TBD</capabilties>
="urn:uuid:f3373a7b-4958-4e55-8820-
>> > >> >>> d03a191fb76a
>> > >> >>> update as the association class is a separate XML element
and
>> > not
>> > >> >>> Since association class is a special class meant to
associate
>> > >> >> multiple

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Oct 2011 10:19:40 -0400

Yes, this seems the right thing to do.

	Thanks,
	Paul

On 10/28/11 9:42 AM, Ravindran Parthasarathi wrote:
> Hi,
>
> IMO, send&  recv are the element which has to be pushed inside
>>> I presume the participant - CS<session>  element will be replaced by
>>> the<  participantSessionAssoc>.
>>
>> No.<session>  will continue to remain. We are talking about association
>> The other attributes of<participant>  and<session>  which are not
>>> I also presume<send>  and<recv>   will no longer be needed, and that
>>> the<participantStream Assoc>  will include an attribute to say send
>> or
>>> recv ?
>>
>> through different use-cases to see if its fine to have<send>,<recv>
>>>> From: "Ram Mohan R (rmohanr)"<[email-masked]>
>>>> To: "Paul Kyzivat"<[email-masked]>;<[email-masked]>

---

From: <[email-masked]>
Date: Fri, 28 Oct 2011 16:06:19 +0100

Ram,
>association attributes will continue to be the respective elements.

What I meant to say was:
I presume the participant's session attribute will be replaced by the <participantSessionAssoc>.
Is that correct ?

RE use of <recv>, this means for a large conference each participant update will be very large as it needs to include recv's for every other participants send  ?

Rgds John

-----Original Message-----
From: Ravindran Parthasarathi [mailto:[email-masked]]
Sent: 28 October 2011 14:43
To: Ram Mohan R (rmohanr); Stafford,J,John,JRJ3X C; [email-masked]
Subject: RE: [siprec] Need Inputs: How to representattributesofassociation in Metadata Model and in XML ?

Hi,

IMO, send & recv are the element which has to be pushed inside participant stream association element which is inline with the model.

Thanks
Partha

Behalf
>> the association gets deleted, the association element life ends. SRC
>> may choose to send the association element optionally or the SRS can
still
>> model /schema. I will start a separate mail thread for the issue as
>> this thread is already too long.
>>
>> Thanks,
>> Ram
>>
>>
>> > associated elements is deleted (gains a dissociate time)? This
>> > would reduce the on-the
>> wire
of
minimize
to
we
if
if
and
associate

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Oct 2011 12:05:29 -0400

On 10/28/11 11:06 AM, [email-masked] wrote:
> I presume the participant's session attribute will be replaced by the<participantSessionAssoc>.
> Is that correct ?

Yup, that's the idea.

> RE use of<recv>, this means for a large conference each participant update will be very large as it needs to include recv's for every other participants send  ?

The association is between each participant and a stream, not between 
two participants. There are two ways to represent this, and neither has 
the problem you describe:

- one stream for the conference.
   Each participant both sends and receives it.

- one stream for each participant in the conference.
   The focus is represented as a participant.
   Each real participant sends and receives its own stream.
   The focus sends and receives all the streams.

I guess the situation you describe would occur if there was a full-mesh 
of streams between participants. But afaik nobody does that. And if they 
did it would be hard to get an SRC in the middle.

	Thanks,
	Paul

> IMO, send&  recv are the element which has to be pushed inside participant stream association element which is inline with the model.
>
> Thanks
> Partha
>

---

From: <[email-masked]>
Date: Fri, 28 Oct 2011 17:10:13 +0100

Paul,

OK, I understand, but how does the recorder know that the stream sent by the focus is a mixed conference stream , ie contains all of the streams received by the focus. ?

Rgds

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: 28 October 2011 17:05
To: [email-masked]
Subject: Re: [siprec] Need Inputs: How to representattributesofassociation in Metadata Model and in XML ?

Yup, that's the idea.

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Oct 2011 13:29:37 -0400

> OK, I understand, but how does the recorder know that the stream sent by the focus is a mixed conference stream , ie contains all of the streams received by the focus. ?

I don't think I understand the question.
The SRS should just believe what it is told:
the stream it receives contains a mix of all the participants reported 
as sending to it.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Mon, 31 Oct 2011 11:58:19 +0000

Paul,
RE use of recv with conferences,

thanks for your response, I think I am ok with this now, I got myself all confused last week, your response made me stop and think.

Here is my understanding,  please point if I am still wrong:

The <stream> elements in metadata describe the RTP streams that flow as part of the call,
so for a 3 party conference (A,B,C) with a separate media server conference focus, there are 6 streams.

The recorder stream is sent from the conference focus,  assume this this has  a=label:1234 in its SDP.

So in the metadata, the streams would be labelled to indicate that the the transmit streams from the 3 participants are mixed into the recorder stream, as follows:
A->focus  stream    <label>1234</label>
focus->A  stream
B->focus  stream    <label>1234</label>
focus->B  stream
C->focus  stream   <label>1234</label>
focus->C stream

I think the metadata draft would benefit from having a conference example.

Rgds

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: 28 October 2011 18:29
To: [email-masked]
Subject: Re: [siprec] Need Inputs: How to representattributesofassociation in Metadata Model and in XML ?

        Thanks,
        Paul