Subject: Re: [siprec] Need Inputs: How to represent attributesof association in Metadata Model and in XML ?

From: Brad Winslow <[email-masked]>
Date: Tue, 18 Oct 2011 20:25:16 +0000

Hi Ram,

Thank you for the information, I must admit I have been away from the SIPREC mailing list for a while, my apologies to all.

In the protocol specification the <participant> element has two attributes "id" and "session".  This element represents the relationship between the participant and the session, hence the "id" and "session" attributes.  The nested <send> and <recv> elements might be reformatted as;

<send stream="urn:uuid:aeeab19b-9d7a-4d40-6dfa-42ce65d5794b">
	<associate-time>2011-10-18T14:59:53</associate-time>
	 <csrc>Contributing CSRC</csrc>
	<capabilities> etc.. </capabilities>
	<xs:any> extension data </xs:any>
</send>

Where the "stream" attribute would reference the stream element in the CS (since the <stream> has attributes of "id' and "session" as well).
The association of this participant to the stream can be nested in the <send> and <recv> elements as above.  Since participants are added to the metadata with the required "session" attribute, I'm not sure I understand the necessity of the <participantSessionAssoc> element.  One would assume if the participant "id" attribute is identical across sessions, the participant is the same, although I don't recall if this is formally declared in the protocol draft.
The <stream> element maps the XML metadata to the SDP media line, the <send> and <recv> elements associate a participant with a stream, it seems to be the logical place for the additional feature attributes.

Presuming the SRS would use XPath or XQuery parsing, nesting the associate-time, csrc, etc. attributes in the <send> (and <recv>) elements may simplify the logic.  By not introducing new elements in the metadata, we might be able to reduce the message bloat.

Thanks,
Brad

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: Monday, October 17, 2011 5:54 AM
To: Brad Winslow; [email-masked]
Subject: RE: [siprec] Need Inputs: How to represent attributesof association in Metadata Model and in XML ?

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Brad Winslow
> Sent: Friday, October 14, 2011 7:19 PM
> To: [email-masked]
> Subject: Re: [siprec] Need Inputs: How to represent attributesof 
> association in Metadata Model and in XML ?
> 
> 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
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > 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 ?
> >
> > 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="*"
> >    stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a ">
> >       <disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
> > </participantStreamAssoc>
> >
> > (I'm not advocating that particular syntax. Its just something to
> make
> > the point.)
> >
> > 	Thanks,
> > 	Paul
> >
> >
> > On 10/12/11 4:56 AM, Ram Mohan R (rmohanr) wrote:
> > > My bad(typo) while sending the example. The correct partial update
> I
> > > intended to send  is:
> > >
> > > <participantStreamAssoc
> > >    participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"
> > >    stream ="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a ">
> > >       <disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
> > > </participantStreamAssoc>
> > >
> > > This is inline with approach 2 where in each association XML
> element
> > > will have the IDs of the related associated elements.
> > >
> > > Ram
> > >
> > >> -----Original Message-----
> > >> From: Leon Portman [mailto:[email-masked]]
> > >> Sent: Wednesday, October 12, 2011 2:24 PM
> > >> To: Ram Mohan R (rmohanr); [email-masked]
> > >> Cc: Ofir Roth
> > >> Subject: RE: Need Inputs: How to represent attributes of
> association
> > > in
> > >> Metadata Model and in XML ?
> > >>
> > >> 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
> > >>   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
> > >>
> > >>> -----Original Message-----
> > >>> 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
> > >>> inmetadata Model and in XML ?
> > >>>
> > >>> 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 ?
> > >>>
> > >>> (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
> > >>>
> > > _______________________________________________
> > > siprec mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/siprec
> > >
> >
> > _______________________________________________
> > siprec mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/siprec
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec