Subject: [clue] the action items i took from the meeting

From: "Roni Even" <[email-masked]>
Date: Tue, 21 Aug 2012 18:16:24 +0200

Hi,

This are the points I took from the meeting

1.       We can use RTP header extensions but will need to update the header
extension RFC about not ignoring header extensions.

2.       Discussion on how to support simulcast in CLUE.  Roni proposes to
use the SDP support and will write a document about it

3.       Is a new offer answer required for a new advertisement or
configuration. Roni to address.

4.       Discussion about selecting encoding for a media capture. Is the
encoding only for defining physical limitation or do we use them also for
selecting for example a specific encoding in a simulcast for a media
capture. General question is if  in a configuration you select a media
capture only or also a specific type of content and how you advertise it
(clarify the framework?)

I hope these are what we discussed

Roni

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Aug 2012 17:31:43 +0200

Hi,

Regarding 2), note that there is a draft about simulcast and SDP:

http://tools.ietf.org/id/draft-westerlund-avtcore-rtp-simulcast-01.txt

Regards,

Christer

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Roni Even [[email-masked]]
Sent: Tuesday, August 21, 2012 7:16 PM
To: [email-masked]
Subject: [clue] the action items i took from the meeting

Hi,

1.       We can use RTP header extensions but will need to update the header extension RFC about not ignoring header extensions.

2.       Discussion on how to support simulcast in CLUE.  Roni proposes to use the SDP support and will write a document about it

3.       Is a new offer answer required for a new advertisement or configuration. Roni to address.

4.       Discussion about selecting encoding for a media capture. Is the encoding only for defining physical limitation or do we use them also for selecting for example a specific encoding in a simulcast for a media capture. General question is if  in a configuration you select a media capture only or also a specific type of content and how you advertise it (clarify the framework?)

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Aug 2012 14:12:50 -0400

Thanks Roni. I was making notes but got pulled away to something else 
before I could finish. So I'll add to yours.

On 8/21/12 12:16 PM, Roni Even wrote:
> 1.We can use RTP header extensions but will need to update the header

Explanation for *why*: Jonathan spoke with Colin about it. Colin thought 
that such a change would not affect any existing deployments.

(But note that this is all opinion. When we actually move to do this we 
might get surprised, so probably better to get on with it asap. And its 
my understanding that this is a separate issue from defining the 
specific new header extension we need.)

> 2.Discussion on how to support simulcast in CLUE.  Roni proposes to use
> the SDP support and will write a document about it
>
> 3.Is a new offer answer required for a new advertisement or

An example we discussed was a session that had no presentation and wants 
to add one. If the presentation stream will be multiplexed on an 
existing media session (m-line) and will use an existing payload type 
for that m-line, then an O/A probably won’t be needed. If it needs to be 
sent using a new payload type, then a new O/A would be required before 
the advertisement can be sent.

We didn't discuss a case where an O/A is required before sending a new 
configuration message - if such a case is possible.

> 4.Discussion about selecting encoding for a media capture. Is the
> encoding only for defining physical limitation or do we use them also
> for selecting for example a specific encoding in a simulcast for a media

My impression of the discussion of this was broader. What I understood 
(from the documents and the discussion today) is that the configuration 
selects a number of *things* (for which we currently have no name) to be 
received. Each of those things is a combination of one of the advertised 
captures and one of the advertised encodings. Its a simulcast if the 
same capture is selected multiple times - each in association with a 
different encoding. There seemed to be widespread agreement about this.

** Roni took an action item to request specific clarifications in
    the framework to ensure all readers get the same understanding.

This then means that the RTP header extension isn't conveying a 
capture-id. Rather it is identifying one (or more) of these combinations 
of capture with encoding.

If this is right, then we are lacking terminology for talking about this 
combination. So we need an addition to the framework to cover that too.

> I hope these are what we discussed

We also discussed *briefly* discussed my two questions:

- can CLUE *work* without a dynamic mapping of RTP stream to
   capture+encoding pair? (Hence the requirement for an RTP extension.)

- if so, how severe are the negative consequences of doing so?

What I got from the discussion was that we probably *could*, but only by 
restricting the topologies we support. And that would violate our 
requirements. (We didn't discuss which ones. But by my reading there is 
one: "REQMT-13: The solution MUST support both transcoding and switching 
approaches to providing multipoint conferences."

	Thanks,
	Paul

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 21 Aug 2012 21:11:39 +0100

On 21 Aug 2012, at 19:12, Paul Kyzivat wrote:
> Thanks Roni. I was making notes but got pulled away to something else before I could finish. So I'll add to yours.
> 
> Explanation for *why*: Jonathan spoke with Colin about it. Colin thought that such a change would not affect any existing deployments.

Not sure I remember a conversation like that...

> (But note that this is all opinion. When we actually move to do this we might get surprised, so probably better to get on with it asap. And its my understanding that this is a separate issue from defining the specific new header extension we need.)

Right. RFC 5285 states that "header extensions using this specification MUST only be used for data that can safely be ignored by the recipient without affecting interoperability". If CLUE wants to use an RTP header extension, it either needs to fit with those restrictions, or revise RFC 5285 to allow whatever new uses are required. I'd expect that any update to RFC 5285 would start by documenting the effects of relaxing the usage restrictions, and seeing what breaks, so it can discuss the compatibility concerns.

> An example we discussed was a session that had no presentation and wants to add one. If the presentation stream will be multiplexed on an existing media session (m-line) and will use an existing payload type for that m-line, then an O/A probably won’t be needed. If it needs to be sent using a new payload type, then a new O/A would be required before the advertisement can be sent.
> 
> We didn't discuss a case where an O/A is required before sending a new configuration message - if such a case is possible.
> 
> My impression of the discussion of this was broader. What I understood (from the documents and the discussion today) is that the configuration selects a number of *things* (for which we currently have no name) to be received. Each of those things is a combination of one of the advertised captures and one of the advertised encodings. Its a simulcast if the same capture is selected multiple times - each in association with a different encoding. There seemed to be widespread agreement about this.
> 
> This then means that the RTP header extension isn't conveying a capture-id. Rather it is identifying one (or more) of these combinations of capture with encoding.
> 
> If this is right, then we are lacking terminology for talking about this combination. So we need an addition to the framework to cover that too.
> 
> What I got from the discussion was that we probably *could*, but only by restricting the topologies we support. And that would violate our requirements. (We didn't discuss which ones. But by my reading there is one: "REQMT-13: The solution MUST support both transcoding and switching approaches to providing multipoint conferences."
> 
> 	Thanks,
> 	Paul
> 
> 
>> Roni
>> 
>> 
>> 

-- 
Colin Perkins
http://csperkins.org/

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Aug 2012 17:03:33 -0400

> Not sure I remember a conversation like that...

That's the trouble with heresay - especially if I might have noted it 
down wrong.

> Right. RFC 5285 states that "header extensions using this specification MUST only be used for data that can safely be ignored by the recipient without affecting interoperability". If CLUE wants to…

I know you can accurately predict the future, but what do you think the 
chances are of getting something like that approved, and how long it 
might take? (And feel free to factor in whether you would be supporting 
or opposing it.)

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Wed, 22 Aug 2012 00:13:48 +0200

Hi Paul,
In number 4 this is not my action item.
The current framework does not mention this usage for encoding groups and
Paul Wity should point where it does.
I still think that we amp a capture ID. There may be more than one SSRC
mapped to the same capture id 

I was making a general comment on the readability of the encoding group
support in the framework

Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
Sent: 21 August, 2012 8:13 PM
To: [email-masked]
Subject: [clue] Notes and action items from 21-aug-2012 design team meeting

Thanks Roni. I was making notes but got pulled away to something else before
I could finish. So I'll add to yours.

> for selecting for example a specific encoding in a simulcast for a 
> media capture. General question is if in a configuration you select a 
> media capture only or also a specific type of content and how you 
> advertise it (clarify the framework?)

My impression of the discussion of this was broader. What I understood (from
the documents and the discussion today) is that the configuration selects a
number of *things* (for which we currently have no name) to be received.
Each of those things is a combination of one of the advertised captures and
one of the advertised encodings. Its a simulcast if the same capture is
selected multiple times - each in association with a different encoding.
There seemed to be widespread agreement about this.

This then means that the RTP header extension isn't conveying a capture-id.
Rather it is identifying one (or more) of these combinations of capture with
encoding.

	Thanks,
	Paul

---

From: Colin Perkins <[email-masked]>
Date: Tue, 21 Aug 2012 22:20:04 +0100

>> On 21 Aug 2012, at 19:12, Paul Kyzivat wrote:
...
> I know you can accurately predict the future, but what do you think the chances are of getting something like that approved, and how long it might take? (And feel free to factor in whether you would be supporting or opposing it.)

The text about this in RFCs 3550 and 5285 is there for a reason. If you can explain why that reason is no longer a concern, and show that there are no significant backwards compatibility issues, then I'd expect this could move fairly quickly. If there's no convincing reason why this is acceptable now but wasn't when the standards were written, then it may take longer. It's difficult to be more precise without having seen a draft...

-- 
Colin Perkins
http://csperkins.org/

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Aug 2012 18:03:05 -0400

> In number 4 this is not my action item.

Well, I *tried* to give it to you. :-)

> Paul Wity should point where it does.

I'm not sure, but I *think* you are alone in not getting this 
understanding. Maybe its implicit rather than explicit. But I was 
thinking if you are the one who didn't get it you would best be able to 
say why.

But maybe not. If its implicit then maybe someone who does infer it 
needs to spell out what led to that inference.

> mapped to the same capture id

If the configure message simply specified which captures it wanted, 
without saying which encoding to use, then how is the decision about 
encoding made? Does the sender choose? If the sender chooses, then what 
is the point of putting encodings into the advertisement?

And, if the recipient wants multiple encodings of the same capture, how 
would it request that?

	Thanks,
	Paul

---

From: John Leslie <[email-masked]>
Date: Tue, 21 Aug 2012 18:06:58 -0400

Paul Kyzivat <[email-masked]> wrote:
>> Right. RFC 5285 states that "header extensions using this specification 
>> MUST only be used for data that can safely be ignored by the recipient 
>> without affecting interoperability". If CLUE wants to use an RTP header 
>> extension, it either needs to fit with those restrictions, or revise RFC 
>> 5285 to allow whatever new uses are required. I'd expect that any update 
>> to RFC 5285 would start by documenting the effects of relaxing the usage 
>> restrictions, and seeing what breaks, so it can discuss the compatibility 
>> concerns.
> 
> ... what do you think the chances are of getting something like that
> approved, and how long it might take?

   There are _so_ many things I don't understand here that a wiser man
would certainly keep quiet...

   Nonetheless, this piece of 5285 strikes me as awfully fundamental to
it: 5285 does _not_ "update" 3550: thus usage of it must not invalidate
other possible interpretations of 3550. We have no basis for expecting
receivers of RTP packets to pay any attention to 5285: thus IMHO it
MUST be valid for them to ignore 5285 header extensions.

   I'd like somebody to explain why we want anything to do with 5285.
It would seem to make more sense for us to define a different interpretation
of a 3550 header extension. But I don't even understand why we want to
use an RTP header "extension" at all. :^(

   (It _might_ turn out that I'm not the only confused WG participant.)

--
John Leslie <[email-masked]>

---

From: "Roni Even" <[email-masked]>
Date: Wed, 22 Aug 2012 08:13:11 +0200

Paul,
I can see that it is feasible to define individual encodes this way. The
issue is that the use case for the encodes as stated in the framework is to
address physical constrains, when supporting multiple simultaneous streams.
If the idea was to use it for simulcast, it should state it.  It was never
mentioned that the purpose is to support simulcast or any image control
functionality. If you want to use it to specify the image size by the
consumer it misses parameters currently available in the SDP image attribute
Roni

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 22 August, 2012 12:03 AM
To: Roni Even
Cc: [email-masked]
Subject: Re: [clue] Notes and action items from 21-aug-2012 design team
meeting

> The current framework does not mention this usage for encoding groups 
> and Paul Wity should point where it does.

I'm not sure, but I *think* you are alone in not getting this understanding.
Maybe its implicit rather than explicit. But I was thinking if you are the
one who didn't get it you would best be able to say why.

But maybe not. If its implicit then maybe someone who does infer it needs to
spell out what led to that inference.

> I still think that we amp a capture ID. There may be more than one 
> SSRC mapped to the same capture id

If the configure message simply specified which captures it wanted, without
saying which encoding to use, then how is the decision about encoding made?
Does the sender choose? If the sender chooses, then what is the point of
putting encodings into the advertisement?

	Thanks,
	Paul

> I was making a general comment on the readability of the encoding 
> group support in the framework
>
>
>
> Roni
>
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Paul Kyzivat
> (from the documents and the discussion today) is that the 
> configuration selects a number of *things* (for which we currently have no
name) to be received.
> Each of those things is a combination of one of the advertised 
different encoding.
> This then means that the RTP header extension isn't conveying a
capture-id.
> Rather it is identifying one (or more) of these combinations of 
> capture with encoding.
>
> If this is right, then we are lacking terminology for talking about 
> this combination. So we need an addition to the framework to cover that
too.
> What I got from the discussion was that we probably *could*, but only 
> by restricting the topologies we support. And that would violate our 
> one: "REQMT-13: The solution MUST support both transcoding and 
> switching approaches to providing multipoint conferences."
>
> 	Thanks,
> 	Paul
>
>
>> Roni
>>
>>
>>

---

From: Andy Pepperell <[email-masked]>
Date: Wed, 22 Aug 2012 08:25:55 +0100

Hi Roni

> I was making a general comment on the readability of the encoding group
I think it was me that made the rash promise to ensure that the framework
was clear on this point :)

>From what I remember in the meeting what we said needing clarification was
being able to instantiate a single capture into multiple encodings - to
address this first, the framework talks about this in section 8, for
instance:
*Every media capture is associated with an encoding group, which is used to
instantiate that media capture into one or more encoded streams.*
and:
*If there are multiple individual encodings in the group, then a single
media capture can be encoded into multiple different streams at the same
time...*
and from section 9:
*For each media capture the consumer wants to receive, it configures one or
more of the encodings in that capture's encoding group*

>[Roni]

I'm not sure how to answer this one, except perhaps asking you to make a
more specific comment on the readability of the encoding group support in
the framework... :)

>Is the encoding only for defining physical limitation or do we use them
also for selecting for example a specific encoding in a simulcast for a
media
capture.

To attempt an answer on this one, yes, it's true that one usage of the
encoding group system was to ensure that today's Telepresence endpoint
devices which are typically formed of 2, 3, or 4 distinct regular endpoints
with some additional control logic were well represented - specifically the
likely constraint that only, say, the DSP resource on the device connected
to the leftmost camera would be able to produce encodings of that camera's
media capture. However, it would be wrong to say that the encoding group
system is "only for defining physical limitation" as that's only one use,
and we didn't want to be too prescriptive - a single-box software MCU might
sensibly separate out its main and presentation encodings with separate
encoding groups, or use this scheme to capture nuances of switched vs
transcoded.

>General question is if in a configuration you select a media capture only
or also a specific type of content and how you advertise it (clarify the
framework?)

The configuration (consumer stream choice) mechanism is intended to allow
the consumer to select both the set of capture encodings it wishes the
provider to send to it, plus characteristics of those encodings such as
maximum bandwidth / resolution etc. (all of which would be subject to SIP
call level overall restrictions as conveyed by SDP, which would also define
payload types etc. as now).

>  (clarify the framework?)
I think it's a fair comment on the framework that, as compared to the level
of detail and number of example cases relating to provider advertisements
and encoding groups then the configuration / consumer stream choice side of
things is perhaps under-represented in the document. This may be something
worth addressing - additionally, the messaging / data model document will
by necessity contain full details of all of these aspects.

Regards,

Andy

---

From: Andy Pepperell <[email-masked]>
Date: Wed, 22 Aug 2012 08:48:07 +0100

On Wed, Aug 22, 2012 at 7:13 AM, Roni Even <[email-masked]> wrote:

> If the idea was to use it for simulcast, it should state it.

In a sense the framework was written to explain the general-purpose
mechanisms available without being too prescriptive about their uses - the
idea of the abstract media captures, provider advertisement and the ways in
which a consumer could use this information does talk in more than one
place about instantiating multiple encodings of the same media capture -
our view (which could obviously be revised based on feedback!) was that
this was sufficient and didn't need labelling as "simulcast", which might
mean different things to different people...

Your comment seems to be tying together encoding groups (one use of which
is to express physical constraints) and simulcast, whereas in fact these
are in a sense orthogonal aspects of the framework - specifically, a system
with no constraints requiring it to express its encoding capabilities in
more than one encoding group might still be perfectly happy to provide
multiple versions of all of its media captures. A system capable of
producing only one encoding of a media capture would need to ensure that
capture was associated with an encoding group comprising just one potential
encoding - it would depend on the nature of the provider-side equipment
whether a "physical" or other type of constraint was imposing that
restriction, so we didn't feel it useful to dictate that in the framework
document.

>  It was never

I think we've already had a long thread on the topic of whether such
parameters transported via SDP works well within CLUE... I don't think it
does - e.g. considering the case where a consumer is receiving multiple
active speakers and composing them itself into a layout then it needs to
tell the provider the display size characteristics of those speakers'
streams, and, moreover, tell the provider new values when it decides to use
a different layout (at which point it would seem wrong to force a new
Offer/Answer). Similarly, a provider might want to tell its associated CLUE
consumer(s) about a 4:3 / 16:9 aspect ratio change in a presentation video
channel without a new Offer/Answer.

Regards,

Andy

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Aug 2012 08:55:16 -0400

> consumer it misses parameters currently available in the SDP image attribute

Thanks Roni. I'm not trying to *sell* anything here. I just want 
everybody to have a common understanding of what we are doing.

It's quite possible that my "shared understanding" comes from listening 
to people talk rather than to what is written. But we need to be 
agreeing on what is written.

The next question then could be whether its important for the 
advertisement to be able to express an ability to simulcast a capture, 
and if so, for the receiver to be able to select more than one of the 
simulcast variants of that capture.

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Thu, 23 Aug 2012 15:45:15 +0200

Hi Andy,

I am looking at the simulcast support and what is not clear to me is in
which topologies you see simulcast.

I can understand a point to point where there is an offer and the receiver
selects which stream it wants. (resolution, frame rate, bit rate and codec
(useful for audio), but this is regular offer answer.

The other topology is RTP mixer where the mixer may receives all simulcast
streams from the sender and send each user a stream according to the
receiver capability. 

Are there other use cases and what topology do you assume?

Roni

From: Andy Pepperell [mailto:[email-masked]] 
Sent: 22 August, 2012 9:26 AM
To: Roni Even
Cc: Paul Kyzivat; [email-masked]
Subject: Re: [clue] Notes and action items from 21-aug-2012 design team
meeting

Hi Roni

Hi Paul,

Every media capture is associated with an encoding group, which is used to
instantiate that media capture into one or more encoded streams.

and:

If there are multiple individual encodings in the group, then a single media
capture can be encoded into multiple different streams at the same time...

and from section 9:

For each media capture the consumer wants to receive, it configures one or
more of the encodings in that capture's encoding group

support in the framework

capture. 

I think it's a fair comment on the framework that, as compared to the level
of detail and number of example cases relating to provider advertisements
and encoding groups then the configuration / consumer stream choice side of
things is perhaps under-represented in the document. This may be something
worth addressing - additionally, the messaging / data model document will by
necessity contain full details of all of these aspects.

Regards,

Andy

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Thu, 23 Aug 2012 15:34:13 +0000

I think the RTP translator topology must be added, where a switching MCU keeps the SSRC from the originating media provider and rewrites the RTCP.

My assumption is that the MCU does an aggregation based on the various consumer requests and do a configuration towards each provider of media.

Cheers

-Espen

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: 23. august 2012 15:45
To: 'Andy Pepperell'
Cc: [email-masked]
Subject: Re: [clue] Notes and action items from 21-aug-2012 design team meeting

Hi Andy,
I am looking at the simulcast support and what is not clear to me is in which topologies you see simulcast.
I can understand a point to point where there is an offer and the receiver selects which stream it wants. (resolution, frame rate, bit rate and codec (useful for audio), but this is regular offer answer.
The other topology is RTP mixer where the mixer may receives all simulcast streams from the sender and send each user a stream according to the receiver capability.

From: Andy Pepperell [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: 22 August, 2012 9:26 AM
To: Roni Even
Cc: Paul Kyzivat; [email-masked]<mailto:[email-masked]>
Subject: Re: [clue] Notes and action items from 21-aug-2012 design team meeting

Hi Roni
On Tue, Aug 21, 2012 at 11:13 PM, Roni Even <[email-masked]<mailto:[email-masked]>> wrote:
Hi Paul,
The current framework does not mention this usage for encoding groups and

I think it was me that made the rash promise to ensure that the framework was clear on this point :)

>From what I remember in the meeting what we said needing clarification was being able to instantiate a single capture into multiple encodings - to address this first, the framework talks about this in section 8, for instance:
Every media capture is associated with an encoding group, which is used to instantiate that media capture into one or more encoded streams.
and:
If there are multiple individual encodings in the group, then a single media capture can be encoded into multiple different streams at the same time...
and from section 9:
For each media capture the consumer wants to receive, it configures one or more of the encodings in that capture's encoding group

>[Roni]
>I was making a general comment on the readability of the encoding group support in the framework

I'm not sure how to answer this one, except perhaps asking you to make a more specific comment on the readability of the encoding group support in the framework... :)

>Is the encoding only for defining physical limitation or do we use them also for selecting for example a specific encoding in a simulcast for a media
capture.

To attempt an answer on this one, yes, it's true that one usage of the encoding group system was to ensure that today's Telepresence endpoint devices which are typically formed of 2, 3, or 4 distinct regular endpoints with some additional control logic were well represented - specifically the likely constraint that only, say, the DSP resource on the device connected to the leftmost camera would be able to produce encodings of that camera's media capture. However, it would be wrong to say that the encoding group system is "only for defining physical limitation" as that's only one use, and we didn't want to be too prescriptive - a single-box software MCU might sensibly separate out its main and presentation encodings with separate encoding groups, or use this scheme to capture nuances of switched vs transcoded.

>General question is if in a configuration you select a media capture only or also a specific type of content and how you advertise it (clarify the framework?)

The configuration (consumer stream choice) mechanism is intended to allow the consumer to select both the set of capture encodings it wishes the provider to send to it, plus characteristics of those encodings such as maximum bandwidth / resolution etc. (all of which would be subject to SIP call level overall restrictions as conveyed by SDP, which would also define payload types etc. as now).

>  (clarify the framework?)
I think it's a fair comment on the framework that, as compared to the level of detail and number of example cases relating to provider advertisements and encoding groups then the configuration / consumer stream choice side of things is perhaps under-represented in the document. This may be something worth addressing - additionally, the messaging / data model document will by necessity contain full details of all of these aspects.

Regards,

Andy

---

From: "Roni Even" <[email-masked]>
Date: Thu, 23 Aug 2012 21:53:43 +0200

Hi Eapen,

I think that there may be a problem with a translator for the multicast
since if the translator will forward only part of the multicast streams it
will receive RTCP RR only for this art and may think that the other were
lost

Roni 

From: Espen Berger (espeberg) [mailto:[email-masked]] 
Sent: 23 August, 2012 5:34 PM
To: Roni Even; 'Andy Pepperell'
Cc: [email-masked]
Subject: RE: [clue] Notes and action items from 21-aug-2012 design team
meeting

I think the RTP translator topology must be added, where a switching MCU
keeps the SSRC from the originating media provider and rewrites the RTCP. 

My assumption is that the MCU does an aggregation based on the various
consumer requests and do a configuration towards each provider of media. 

Cheers 

-Espen 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni
Even
Sent: 23. august 2012 15:45
To: 'Andy Pepperell'
Cc: [email-masked]
Subject: Re: [clue] Notes and action items from 21-aug-2012 design team
meeting

Hi Andy,

Roni

Hi Roni

Hi Paul,

and:

and from section 9:

support in the framework

capture. 

Regards,

Andy

---

From: "Roni Even" <[email-masked]>
Date: Thu, 23 Aug 2012 23:43:59 +0200

Hi Espen,

Please look at
http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-01

Roni

Cheers 

-Espen 

Hi Andy,

Roni

Hi Roni

Hi Paul,

and:

and from section 9:

support in the framework

capture. 

Regards,

Andy

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Fri, 24 Aug 2012 08:15:18 +0000

Hi Roni

The reference to RTP translator topology was incorrect, I was thinking about the 'Selective Forwarding Switch' topology that Magnus presented during the June interim meeting. The presentation has addition topologies that are not yet in the RFC5115 RTP topology document, so hopefully someone will update it.

Regarding you comment on RTCP RR; A selective forwarding switch can keep track of streams sent and received for each RTP session and rewrite all RTCP SR/RR to make sure that RTCP information is correct for each RTP session. The topology will result in source disappearing and reappearing again based on the MCU policies, which must be understood and handled in terms of the various RTP mechanisms.

Cheers

-Espen
 [rtp-topology] - http://www.ietf.org/proceedings/interim/2012/06/07/clue/slides/slides-interim-2012-clue-2-6.pdf

From: Roni Even [mailto:[email-masked]]
Sent: 23. august 2012 23:44
To: Espen Berger (espeberg); 'Andy Pepperell'
Cc: [email-masked]
Subject: RE: [clue] Notes and action items from 21-aug-2012 design team meeting

Hi Espen,
Please look at http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-01
Roni

From: Espen Berger (espeberg) [mailto:[email-masked]]
Sent: 23 August, 2012 5:34 PM
To: Roni Even; 'Andy Pepperell'
Cc: [email-masked]
Subject: RE: [clue] Notes and action items from 21-aug-2012 design team meeting

Cheers

-Espen

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Roni Even
Sent: 23. august 2012 15:45
To: 'Andy Pepperell'
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [clue] Notes and action items from 21-aug-2012 design team meeting

Hi Andy,

Hi Roni

capture.

Regards,

Andy

---

From: "Roni Even" <[email-masked]>
Date: Fri, 24 Aug 2012 15:03:06 +0200

Espen,

This is still a mixer, it terminates RTCP even though it is one SSRC space.
At the Interim meeting this topology was not part of the supported
topologies for CLUE based on the issue mentioned with it and because it is
not supported by RTP. We agreed on media switching mixer and source
projection mixer.

My understanding is that the in CLUE the MCU will create and offer with the
relevant streams also for simulcast.

I am also not sure why the consumer need to define the mapping since the
advertisement knows what it offers.

I think that we will continue the discussion until we see the call flow SDP,
RTCP feedback and CLUE since we probably see different models.

I will try to work on my view of the call flow.

Roni

From: Espen Berger (espeberg) [mailto:[email-masked]] 
Sent: 24 August, 2012 10:15 AM
To: Roni Even; 'Andy Pepperell'
Cc: [email-masked]
Subject: RE: [clue] Notes and action items from 21-aug-2012 design team
meeting

Hi Roni

The reference to RTP translator topology was incorrect, I was thinking about
the 'Selective Forwarding Switch' topology that Magnus presented during the
June interim meeting. The presentation has addition topologies that are not
yet in the RFC5115 RTP topology document, so hopefully someone will update
it. 

Regarding you comment on RTCP RR; A selective forwarding switch can keep
track of streams sent and received for each RTP session and rewrite all RTCP
SR/RR to make sure that RTCP information is correct for each RTP session.
The topology will result in source disappearing and reappearing again based
on the MCU policies, which must be understood and handled in terms of the
various RTP mechanisms.  

Cheers 

-Espen 

 [rtp-topology] -
http://www.ietf.org/proceedings/interim/2012/06/07/clue/slides/slides-interi
m-2012-clue-2-6.pdf

Hi Espen,

Please look at

Roni

Cheers 

-Espen 

Hi Andy,

Roni

Hi Roni

Hi Paul,

and:

and from section 9:

support in the framework

capture. 

Regards,

Andy

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Fri, 24 Aug 2012 14:17:25 +0000

As long as we support at least one topology that allow for keeping the SSRC through the MCU.

-Espen

From: Roni Even [mailto:[email-masked]]
Sent: 24. august 2012 15:03
To: Espen Berger (espeberg); 'Andy Pepperell'
Cc: [email-masked]
Subject: RE: [clue] Notes and action items from 21-aug-2012 design team meeting

Espen,
This is still a mixer, it terminates RTCP even though it is one SSRC space. At the Interim meeting this topology was not part of the supported topologies for CLUE based on the issue mentioned with it and because it is not supported by RTP. We agreed on media switching mixer and source projection mixer.
My understanding is that the in CLUE the MCU will create and offer with the relevant streams also for simulcast.

I am also not sure why the consumer need to define the mapping since the advertisement knows what it offers.
I think that we will continue the discussion until we see the call flow SDP, RTCP feedback and CLUE since we probably see different models.
I will try to work on my view of the call flow.
Roni

From: Espen Berger (espeberg) [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>

Hi Roni

Cheers

-Espen

From: Roni Even [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>

Hi Espen,

From: Espen Berger (espeberg) [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>

Cheers

-Espen

Hi Andy,

Hi Roni

capture.

Regards,

Andy

---

From: Mary Barnes <[email-masked]>
Date: Fri, 24 Aug 2012 09:41:22 -0500

Roni included the topologies that we agreed at the interim (from Magnus'
presentation) in the rtp-mapping draft:
http://datatracker.ietf.org/doc/draft-even-clue-rtp-mapping/?include_text=1

It would be really good if people could review those and suggest
changes/additions based upon what's already written down.  We really need
this well documented (based on WG consensus) for our CLUE deliverables.

On that topic, it would be good to take a step back and look at the RTP
requirements that are in the rtp-usage draft:
http://www.ietf.org/id/draft-lennox-clue-rtp-usage-04.txt (Section 9 in
particular).
As we also should have that clearly documented and agreed by the WG.

Mary.

On Fri, Aug 24, 2012 at 9:17 AM, Espen Berger (espeberg) <[email-masked]
> wrote:

>  As long as we support at least one topology that allow for keeping the
> SSRC through the MCU. ****
>
> ** **
>
> -Espen ****
>
> ** **
>
> ** **
>
> *From:* Roni Even [mailto:[email-masked]]
> *Sent:* 24. august 2012 15:03
>
> *To:* Espen Berger (espeberg); 'Andy Pepperell'
> *Cc:* [email-masked]
> *Subject:* RE: [clue] Notes and action items from 21-aug-2012 design team
> meeting****
>
>  ** **
>
> Espen,****
>
> This is still a mixer, it terminates RTCP even though it is one SSRC
> space. At the Interim meeting this topology was not part of the supported
> projection mixer.****
> My understanding is that the in CLUE the MCU will create and offer with
> the relevant streams also for simulcast.****
>
> ** **
>
> advertisement knows what it offers.****
>
> I think that we will continue the discussion until we see the call flow
> SDP, RTCP feedback and CLUE since we probably see different models.****
>
> I will try to work on my view of the call flow.****
>
> Roni****
>
> ** **
>
> *From:* Espen Berger (espeberg) [mailto:[email-masked]]
> *Sent:* 24 August, 2012 10:15 AM
> *To:* Roni Even; 'Andy Pepperell'
> *Cc:* [email-masked]
> *Subject:* RE: [clue] Notes and action items from 21-aug-2012 design team
> meeting****
>
> ** **
>
> Hi Roni****
>
> ** **
>
> The reference to RTP translator topology was incorrect, I was thinking
> about the ‘Selective Forwarding Switch’ topology that Magnus presented
> during the June interim meeting. The presentation has addition topologies
> that are not yet in the RFC5115 RTP topology document, so hopefully someone
> will update it. ****
>
> ** **
>
> track of streams sent and received for each RTP session and rewrite all
> RTCP SR/RR to make sure that RTCP information is correct for each RTP
> session. The topology will result in source disappearing and reappearing
> again based on the MCU policies, which must be understood and handled in
> terms of the various RTP mechanisms.  ****
>
> ** **
>
> Cheers ****
>
> ** **
>
> -Espen ****
>
>  [rtp-topology] -
> http://www.ietf.org/proceedings/interim/2012/06/07/clue/slides/slides-interim-2012-clue-2-6.pdf
> ****
>
> ** **
>
> ** **
>
> *From:* Roni Even [mailto:[email-masked]]
> *Sent:* 23. august 2012 23:44
> *To:* Espen Berger (espeberg); 'Andy Pepperell'
> *Cc:* [email-masked]
> *Subject:* RE: [clue] Notes and action items from 21-aug-2012 design team
> meeting****
>
> ** **
>
> Hi Espen,****
>
> Please look at
> http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-01****
>
> Roni****
>
> ** **
>
> *From:* Espen Berger (espeberg) [mailto:[email-masked]]
> *Sent:* 23 August, 2012 5:34 PM
> *To:* Roni Even; 'Andy Pepperell'
> *Cc:* [email-masked]
> *Subject:* RE: [clue] Notes and action items from 21-aug-2012 design team
> meeting****
>
> ** **
>
> ****
> ** **
> consumer requests and do a configuration towards each provider of media. *
> ***
>
> ** **
>
> Cheers ****
>
> ** **
>
> -Espen ****
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Roni Even
> *Sent:* 23. august 2012 15:45
> *To:* 'Andy Pepperell'
> *Cc:* [email-masked]
> *Subject:* Re: [clue] Notes and action items from 21-aug-2012 design team
> meeting****
>
> ** **
>
> Hi Andy,****
>
> which topologies you see simulcast.****
>
> (useful for audio), but this is regular offer answer.****
>
> receiver capability. ****
>
> ** **
>
> Are there other use cases and what topology do you assume?****
>
> Roni****
>
> ** **
>
> ** **
>
> *From:* Andy Pepperell [mailto:[email-masked]]
> *Sent:* 22 August, 2012 9:26 AM
> *To:* Roni Even
> *Cc:* Paul Kyzivat; [email-masked]
> *Subject:* Re: [clue] Notes and action items from 21-aug-2012 design team
> meeting****
>
> ** **
>
> Hi Roni****
>
> On Tue, Aug 21, 2012 at 11:13 PM, Roni Even <[email-masked]>
> wrote:****
>
> Hi Paul,
> The current framework does not mention this usage for encoding groups and*
> ***
>
>  ****
>
> support in the framework****
>
>   ****
>
> was clear on this point :)****
>
> ** **
>
> instance:****
> *Every media capture is associated with an encoding group, which is used
> to instantiate that media capture into one or more encoded streams.*****
>
> and:****
>
> time...*****
> and from section 9:****
> *For each media capture the consumer wants to receive, it configures one
> or more of the encodings in that capture's encoding group*****
>
> ** **
>
> >[Roni]****
>
> group support in the framework****
>
> ** **
>
> the framework... :)****
> ** **
> media****
> capture. ****
> ** **
> transcoded.****
> ** **
> framework?)****
> ** **
> payload types etc. as now).****
>
> ** **
>
> >  (clarify the framework?)****
>
> I think it's a fair comment on the framework that, as compared to the
> level of detail and number of example cases relating to provider
> advertisements and encoding groups then the configuration / consumer stream
> choice side of things is perhaps under-represented in the document. This
> may be something worth addressing - additionally, the messaging / data
> model document will by necessity contain full details of all of these
> aspects.****
>
> ** **
>
> Regards,****
>
> ** **
>
> Andy****
>
> ** **
>