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

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Nov 2011 16:48:22 -0400

This is just from me - it hasn't been reviewed by Ram and Partha.
Lets see if they agree.

	Thanks,
	Paul

On 10/31/11 7:58 AM, [email-masked] wrote:
> 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.

This is one way.
Another way is to describe it as a single stream with (A,B,C) each both 
sending and receiving it.

> 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

Why do you have the same label for all three?
Each stream that is sent to the SRS should have a different label, 
mapping to a separate m-line.

If it had been represented as a single stream, then the SRC would have 
to do the mixing, and there would be only one label.

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

Yes, it would.

	Thanks,
	Paul

> Rgds
> John Stafford | Solution Architect 1 | BT Global Services
>
> ________________________________________
> 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 ?
>
> On 10/28/11 12:10 PM, [email-masked] wrote:
>> 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. ?
>
> 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
>
>> Rgds
>> John Stafford | Solution Architect 1 | BT Global Services
>>
>> ________________________________________
>> 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 ?
>>
>> On 10/28/11 11:06 AM, [email-masked] wrote:
>>>
>>> Ram,
>>>>> I presume the participant - CS<session>    element will be replaced by
>>>>> the<    participantSessionAssoc>.
>>>>
>>>> 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.
>>>
>>> What I meant to say was:
>>> 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
>>
>>> 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
>>>
>>>> -----Original Message-----
>>>> 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,
>>>>
>>>> Please see inline for answers.
>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>> 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 ?
>>>>>
>>>>> 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>.
>>>>
>>>> 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
>>>>
>>>>>
>>>>> 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 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
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: John Elwell [mailto:[email-masked]]
>>>>>> Sent: Thursday, October 27, 2011 2:03 PM
>>>>>> To: Ram Mohan R (rmohanr); Paul Kyzivat; [email-masked]
>>>>>> Subject: Re: [siprec] Need Inputs: How to represent attributes
>>>>>> ofassociation in Metadata Model and in XML ?
>>>>>>
>>>>>> 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 ?
>>>>>>
>>>>>>
>>>>>>> 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
>>>
>>
>> _______________________________________________
>> 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
>

---

From: <[email-masked]>
Date: Wed, 2 Nov 2011 10:51:30 +0000

Paul,
I am still confused, comments inline
Rgds
John

>On Behalf Of Paul Kyzivat
>Sent: 01 November 2011 20:48
>To: [email-masked]
>> 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.
>>
>> 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.
>
>This is one way.
>Another way is to describe it as a single stream with (A,B,C)
>each both sending and receiving it.
But isn't the meta data meant to be describing the actual RTP streams?
I don't understand why this means the stream contains a mix.
Draft-ietf-siprec-metadata-05 describes a stream by "A media stream class (and its objects) has the properties of media as seen by SRC and sent to SRS",  and then goes on "The metadata model should include media streams that are not being delivered to the SRS". Which doesn't help me at all.

>
>> 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:
>Each stream that is sent to the SRS should have a different
>label, mapping to a separate m-line.
Because what is being recorded is a SRC mix of the 3 participants transmit streams into a single recorder
stream described by the one m-line

>
>If it had been represented as a single stream, then the SRC
>would have to do the mixing, and there would be only one label.
One label where ?

Can you show me how metadata and SDP should be for this example
if I don't want to describe it as a single stream with (A,B,C)
each both sending and receiving it.

>> Paul Kyzivat [[email-masked]]
>>> 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. ?
>>
>>> Paul Kyzivat [[email-masked]]
>>>> 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  ?
>>>
>>> two participants. There are two ways to represent this, and neither
>>> has the problem you describe:
>>>
>>> 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
>>>
>>>> Rgds John
>>>>
>>>>
>>>> Subject: RE: [siprec] Need Inputs: How to
>>>> IMO, send&    recv are the element which has to be pushed
>inside participant stream association element which is inline
>with the model.
>>>>
>>>> Thanks
>>>> Partha
>>>>
>[mailto:[email-masked]] On
>>>>> 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 ?
>>>>>>
>>>>> 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
>>>>>
>>>>>>
>>>>>> Rgds
>>>>>> From: [email-masked] [[email-masked]]
>On Behalf
>>>>>> Of Ram Mohan R (rmohanr) [[email-masked]]
>>>>>> the association gets deleted, the association element life ends.
>>>>>> SRC may choose to send the association element optionally or the
>>>>>> SRS can
>>>> still
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>> 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
>="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a ">
>>>>>>>>>
>="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a ">
>>>>>>>>>>
>="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a">
>>>>>>>>>>>
> </participant>
>="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a ">
>>>>>>>>>>>>