Subject: Re: [AVT] SST switched multipoint conferences

From: "Ingemar Johansson S" <[email-masked]>
Date: Wed, 16 Dec 2009 16:27:50 +0100

Hi

I have not had the cycles necessary to follow this thread nor to update
the image attribute draft. Looking that latest version of the image
attribute draft.
http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-image-attributes/
What is neded in addition to what is already specified in the draft to
support the video switching scenario?. 
As things are specified in the draft today, the offerer can specify a
number of resolutions (with a given preference) for the send and receive
directions and the answerer can reply corresponding prefered resolutions
for the send and receive directions.

Regards
Ingemar

> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 15 Dec 2009 17:04:39 +0200
> From: Roni Even <[email-masked]>
> Subject: Re: [AVT] SST switched multipoint	conferences
> 	indraft-ietf-avt-rtp-svc-20
> To: "'Stuart Taylor (sttaylor)'" <[email-masked]>, [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi Stuart,
> 
> I am not sure why you need multi[le levels, the level 
> parameter provides a maximum and not a specific configuration.
> 
> I am also not sure how you define a common mode that dictates 
> to the endpoint what they are supposed to send.
> 
>  
> 
> I prefer using something like image attribute which is a 
> general parameter and not a codec specific one to request a 
> mode from a sender.
> 
> Roni Even
> 
>  
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stuart Taylor (sttaylor)
> Sent: Tuesday, December 15, 2009 4:14 PM
> To: Roni Even; [email-masked]
> Subject: Re: [AVT] SST switched multipoint conferences 
> indraft-ietf-avt-rtp-svc-20
> 
>  
> 
> [My last response is stuck in moderation. this time I'll let 
> it wait so hopefully the document will go through eventually.]
> 
>  
> 
> Elaborating on my last response. my intent was to try and 
> stay within the syntax framework defined in the current 
> draft.  However, my usage of sprop-operation-point-info to 
> negotiate receiving operation points creates a conflict with 
> the original definition: a switching conference bridge can 
> only send what it receives, so if it receives something 
> different than it declared in sprop-operation-point-info then 
> what it sends won't conform to that declaration. 
> 
>  
> 
> To be clear, I do not want to generate a re-INVITE with each 
> video switch.
> Rather, new parameters need to be sent in band at each 
> switch.  Note that "sprop" parameters generally aren't very 
> useful in a switched-media multipoint conference for this reason.
> 
>  
> 
> If I was to start from scratch, I would prefer to declare 
> multi-operation-point receiving capabilities rather than 
> sending capabilities.  For instance, we could extend the 
> profile-level-id to explicitly declare multiple levels.  It 
> could be extended with the attributes in the current 
> sprop-operation-point-info, or just use the imageattr 
> parameter from the mmusic draft.  An advantage to this 
> approach is that each side can initiate the SDP negotiation, 
> whereas in my proposal only the conference bridge can 
> initiate the negotiation.
> 
>  
> 
> Stuart Taylor
> 
>  
> 
>  
> 
> From: Stuart Taylor (sttaylor)
> Sent: Monday, December 14, 2009 6:18 PM
> To: 'Roni Even'; [email-masked]
> Subject: RE: [AVT] SST switched multipoint conferences 
> indraft-ietf-avt-rtp-svc-20
> 
>  
> 
> My original use case description was dropped from the AVT 
> submission because it's too big (although the authors of the 
> SVC draft received it directly).
> Attached is that document, which hopefully makes the 
> expectations more clear.
> 
>  
> 
> Specifically in answer to your question, in the expected 
> usage the first requested operation point will be compatible 
> with all the endpoints, although in many cases it would 
> suboptimal.  Additional operation points, typically with 
> higher layer identifiers, would provide a better experience 
> for the more capable endpoints.
> 
>  
> 
> Stuart Taylor
> 
>  
> 
>  
> 
> From: Roni Even [mailto:[email-masked]]
> Sent: Monday, December 14, 2009 5:40 PM
> To: Stuart Taylor (sttaylor); [email-masked]
> Subject: RE: [AVT] SST switched multipoint conferences 
> indraft-ietf-avt-rtp-svc-20
> 
>  
> 
> Hi,
> 
> I looked at the example and I am not sure how it works for a 
> conferencing bridge. If the bridge wants to offer two 
> operation points but the end point only send one how can he 
> offer the other endpoints two operation points. The general 
> question is  how the bridge can offer  a common mode to the 
> endpoints or does he need to make a new offer whenever a 
> video switch occurs.
> 
> Roni Even
> 
>  
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stuart Taylor (sttaylor)
> Sent: Thursday, December 03, 2009 7:32 PM
> To: [email-masked]
> Subject: [AVT] SST switched multipoint conferences in 
> draft-ietf-avt-rtp-svc-20
> 
>  
> 
> [resending with reduced payload size]
> 
>  
> 
> For your consideration, attached is language to amend 
> draft-ietf-avt-svc for improved negotiation of switched 
> multi-point conferences in a single-stream transmission 
> context.  This adds a parameter "recv-operation-points" 
> which, in an offer, requests receipt of multiple operation points.
> 
>  
> 
> Summary:  this relates to a concern previously raised by 
> Charles Eckel.
> While it is true that sprop-operation-point-info can be used 
> to declare a layering scheme, we do not see how a conference 
> bridge making that declaration is obligating an answering 
> endpoint to abide by it when sending.
> This proposal attempts to establish the symmetry required for 
> a successful multipoint conference.
> 
>  
> 
> Stuart Taylor
> 
> Technical Leader,
> 
> Cisco Systems
> 
> [email-masked]
> 
>  
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://www.ietf.org/mail-archive/web/avt/attachments/20091215
/10c14c7a/attachment.htm>
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 15 Dec 2009 09:29:19 -0600
> From: "Stuart Taylor (sttaylor)" <[email-masked]>
> Subject: Re: [AVT] SST switched multipoint
> 	conferencesindraft-ietf-avt-rtp-svc-20
> To: "Roni Even" <[email-masked]>, <[email-masked]>
> Message-ID:
> 	<[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
> 
> Roni,
> 
>  
> 
> For instance, suppose you have a mix of QCIF, CIF and 4CIF 
> endpoints in a conference.  The conference bridge needs to be 
> able to tell all the endpoints to generate at least a QCIF 
> layer, which is universally compatible within this context, 
> though suboptimal for most.  If an endpoint is capable, then 
> it should also generate the CIF and 4CIF enhancement layers, 
> for a better experience on the higher resolution endpoints.
> 
>  
> 
> Alternately, you might have a mix of CIF and 4CIF, with some 
> of the CIF endpoints being AVC instead of SVC.  In that case 
> you don't want any endpoints generating QCIF base layers, so 
> you would declare the lowest and required operation point as 
> CIF.  Yes, an endpoint can still legally generate QCIF in 
> that case, but I would hope they will not.
> 
>  
> 
> Under our proposal, the conference bridge declares multiple 
> operation points using sprop-operation-point-info, then 
> requests receipt of those operation points, with the first 
> (QCIF in the first example, CIF in the
> second) being required.  An alternative method would be for 
> the conference bridge to declare multiple levels using an 
> extension of profile-level-id, with the lowest putting a cap 
> on the base layer and the others being a guide for useful 
> combinations of enhancement layers.
> 
>  
> 
> Stuart Taylor
> 
>  
> 
>  
> 
>  
> 
> From: Roni Even [mailto:[email-masked]]
> Sent: Tuesday, December 15, 2009 10:05 AM
> To: Stuart Taylor (sttaylor); [email-masked]
> Subject: RE: [AVT] SST switched multipoint 
> conferencesindraft-ietf-avt-rtp-svc-20
> 
>  
> 
> Hi Stuart,
> 
> I am not sure why you need multi[le levels, the level 
> parameter provides a maximum and not a specific configuration.
> 
> I am also not sure how you define a common mode that dictates 
> to the endpoint what they are supposed to send.
> 
>  
> 
> I prefer using something like image attribute which is a 
> general parameter and not a codec specific one to request a 
> mode from a sender.
> 
> Roni Even
> 
>  
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stuart Taylor (sttaylor)
> Sent: Tuesday, December 15, 2009 4:14 PM
> To: Roni Even; [email-masked]
> Subject: Re: [AVT] SST switched multipoint conferences 
> indraft-ietf-avt-rtp-svc-20
> 
>  
> 
> [My last response is stuck in moderation... this time I'll 
> let it wait so hopefully the document will go through eventually.]
> 
>  
> 
> Elaborating on my last response... my intent was to try and 
> stay within the syntax framework defined in the current 
> draft.  However, my usage of sprop-operation-point-info to 
> negotiate receiving operation points creates a conflict with 
> the original definition: a switching conference bridge can 
> only send what it receives, so if it receives something 
> different than it declared in sprop-operation-point-info then 
> what it sends won't conform to that declaration. 
> 
>  
> 
> To be clear, I do not want to generate a re-INVITE with each 
> video switch.  Rather, new parameters need to be sent in band 
> at each switch.
> Note that "sprop" parameters generally aren't very useful in 
> a switched-media multipoint conference for this reason.
> 
>  
> 
> If I was to start from scratch, I would prefer to declare 
> multi-operation-point receiving capabilities rather than 
> sending capabilities.  For instance, we could extend the 
> profile-level-id to explicitly declare multiple levels.  It 
> could be extended with the attributes in the current 
> sprop-operation-point-info, or just use the imageattr 
> parameter from the mmusic draft.  An advantage to this 
> approach is that each side can initiate the SDP negotiation, 
> whereas in my proposal only the conference bridge can 
> initiate the negotiation.
> 
>  
> 
> Stuart Taylor
> 
>  
> 
>  
> 
> From: Stuart Taylor (sttaylor)
> Sent: Monday, December 14, 2009 6:18 PM
> To: 'Roni Even'; [email-masked]
> Subject: RE: [AVT] SST switched multipoint conferences 
> indraft-ietf-avt-rtp-svc-20
> 
>  
> 
> My original use case description was dropped from the AVT 
> submission because it's too big (although the authors of the 
> SVC draft received it directly).  Attached is that document, 
> which hopefully makes the expectations more clear.
> 
>  
> 
> Specifically in answer to your question, in the expected 
> usage the first requested operation point will be compatible 
> with all the endpoints, although in many cases it would 
> suboptimal.  Additional operation points, typically with 
> higher layer identifiers, would provide a better experience 
> for the more capable endpoints.
> 
>  
> 
> Stuart Taylor
> 
>  
> 
>  
> 
> From: Roni Even [mailto:[email-masked]]
> Sent: Monday, December 14, 2009 5:40 PM
> To: Stuart Taylor (sttaylor); [email-masked]
> Subject: RE: [AVT] SST switched multipoint conferences 
> indraft-ietf-avt-rtp-svc-20
> 
>  
> 
> Hi,
> 
> I looked at the example and I am not sure how it works for a 
> conferencing bridge. If the bridge wants to offer two 
> operation points but the end point only send one how can he 
> offer the other endpoints two operation points. The general 
> question is  how the bridge can offer  a common mode to the 
> endpoints or does he need to make a new offer whenever a 
> video switch occurs.
> 
> Roni Even
> 
>  
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stuart Taylor (sttaylor)
> Sent: Thursday, December 03, 2009 7:32 PM
> To: [email-masked]
> Subject: [AVT] SST switched multipoint conferences in 
> draft-ietf-avt-rtp-svc-20
> 
>  
> 
> [resending with reduced payload size]
> 
>  
> 
> For your consideration, attached is language to amend 
> draft-ietf-avt-svc for improved negotiation of switched 
> multi-point conferences in a single-stream transmission 
> context.  This adds a parameter "recv-operation-points" 
> which, in an offer, requests receipt of multiple operation points.
> 
>  
> 
> Summary:  this relates to a concern previously raised by 
> Charles Eckel.
> While it is true that sprop-operation-point-info can be used 
> to declare a layering scheme, we do not see how a conference 
> bridge making that declaration is obligating an answering 
> endpoint to abide by it when sending.  This proposal attempts 
> to establish the symmetry required for a successful 
> multipoint conference.
> 
>  
> 
> Stuart Taylor
> 
> Technical Leader,
> 
> Cisco Systems
> 
> [email-masked]
> 
>  
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://www.ietf.org/mail-archive/web/avt/attachments/20091215
/04834c13/attachment.htm>
> 
> ------------------------------
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
> 
> 
> End of avt Digest, Vol 68, Issue 39
> ***********************************
>

---

From: "Stuart Taylor (sttaylor)" <[email-masked]>
Date: Wed, 16 Dec 2009 12:32:42 -0600

The mmusic draft is useful for indicating multiple resolutions.
However, I believe the intent there is to give the sender a choice of
multiple encodings without implying that multiple receivers are
involved.  By itself the imageattr attribute is inadequate for this
application because:
1.  There is no indication that multiple simultaneous encodings are
desired.
2.  The resolution by itself is only a partial description of receiver
capabilities.  In particular, the maximum frame rate and bandwidth (and
macroblocks per second) are not indicated.

Stuart

-----Original Message-----
From: Ingemar Johansson S [mailto:[email-masked]] 
Sent: Wednesday, December 16, 2009 10:28 AM
To: [email-masked]
Cc: Stuart Taylor (sttaylor); [email-masked]
Subject: Re: [AVT] SST switched multipoint conferences

Hi

Regards
Ingemar

---

From: Ye-Kui Wang <[email-masked]>
Date: Fri, 18 Dec 2009 14:59:41 +0200

Hi Stuart, 

We have studied and discussed your inputs among us authors of the draft, and
here are our comments. Our comments are directly responding to your minimum
requirements. This way, all your proposed text changes are hopefully
covered. 

1. The declared operation points are explicitly required to conform to
a single consistent layering scheme with an unambiguous hierarchy.  This is
implied by the current draft but not actually stated.

[Authors] We think that this is clear in the current draft. Once an SDP
includes sprop-operation-point-info, the layer structure is clearly
indicated
without ambiguity. However, we can certainly improve the clarity if you
point out the specific places where it is required. 

2. By answering an SVC offer containing sprop-operation-point-info, the
answerer is agreeing to the declared operation points (up to the layer-id
specified in the answer) for both receiving and sending.  The answerer's
encoder must produce a stream that is compatible with, but not necessarily
identical to, the negotiated operation points. 

[Authors]: We think that this is also clear. If the direction attribute is
sendrecv or not present, then what is said in the SDP applies to both
sending and receiving. If direction attribute of sendonly is present, what
is said in the SDP applies to only sending. If direction attribute of
recvonly is present, what is said in the SDP applies to only receiving. 

We propose that either the sprop-operation-point-info is always used
symmetrically or that the offer should indicate whether symmetry is required
through a new attribute.

[Authors]: We don't understand the logic between this proposal and the above
requirement. Could you please clarify if the direction attribute is not
sufficient.

3. We suggest the following syntax for an indication that
sprop-operation-point-info should be interpreted symmetrically:
recv-operation-points=<comma separated list of layer id numbers>.  This
allows the offering endpoint to indicate the properties of important layer
combinations, presumably matching the capabilities of various represented
endpoints.  The identified layers correspond to identifiers in the
sprop-operation-point-info declared in the same offer, ordered by priority.

[Authors]: Once the answerer chooses one operation point, the server will
send all the lower layers required for presenting the opeation point. In
addition, layer IDs themselves are naturally in priority order. These are
clear from the definitions of "layer", "operation points" etc. from section
3. Therefore, we don't see the need of this proposed change. 

4. When sprop-operation-point-info declares an operation point with
layer-id=1, this is describing the SVC base layer.  In the multipoint use
case described here we should expect the conference bridge to always declare
this layer, but there may be other use cases where this is not true.  If
declared, all parties must produce a stream that can be shaped down an AVC
stream which is consistent with this base layer definition.  The
profile-level-id is interpreted as in RFC-3984bis.  For AVC
interoperability, parameters of this layer other than the profile-level-id
are to be taken as strong hints rather than mandates.

[Authors]: A conforming SVC bitstream must contain an AVC base layer. It is
not possible to have a conforming SVC bitstream without an AVC base layer.
The profile-level-id is specified in this SVC draft. Of course, the
semantics for the AVC base layer are the same as that descirbed in 3984bis.
Therefore, we don't see the need of a change to address this requirement.

5. The answering endpoint is not required to exactly match the layering
scheme used by the offering endpoint.  A stream is compatible with the
negotiated operation points if one of the following is true:
a. It contains only a base layer that is compliant with the
profile-level-id defined in the operation point identified as layer-id #1.
Compliance is defined as in RFC-3984, implying that the encoder may produce
at a lower level than indicated by the profile-level-id.

[Authors]: Encoders are always allowed to output a bitstream that is
actually of a lower level than the one declared. We don't see the need for a

change herein.

b. It contains a base layer that is complaint with the declared base
layer in all particulars, optionally plus enhancement layers.  The aggregate
of all layers should match at least one of the negotiated operation points
by having the same frame dimensions, frame rate and maximum bit rate less
than or equal to that operation point, and consistent with to the
profile-level-id.

[Authors]: When the chosen operation point includes more than the base
layer, the
bitstream of the chosen operation point must certainly match what is chosen.
And again, encoders are always allowed to output a bitstream that is
actually of a lower level than the one declared. Therefore, we think that
this
requirement is already met by the current draft. 

Best Regards,
Authors of the SVC draft

> Sent: Wednesday, December 16, 2009 8:33 PM
> To: Ingemar Johansson S; [email-masked]
> Cc: [email-masked]
> However, I believe the intent there is to give the sender a 
> choice of multiple encodings without implying that multiple 
> receivers are involved.  By itself the imageattr attribute is 
> inadequate for this application because:
> 1.  There is no indication that multiple simultaneous 
> encodings are desired.
> 2.  The resolution by itself is only a partial description of 
> receiver capabilities.  In particular, the maximum frame rate 
> and bandwidth (and macroblocks per second) are not indicated.
> 
> Stuart
> 
> 
> I have not had the cycles necessary to follow this thread nor 
> to update the image attribute draft. Looking that latest 
> version of the image attribute draft.
> What is neded in addition to what is already specified in the 
> draft to support the video switching scenario?. 
> As things are specified in the draft today, the offerer can 
> specify a number of resolutions (with a given preference) for 
> the send and receive directions and the answerer can reply 
> corresponding prefered resolutions for the send and receive 
> directions.
> 
> Regards
> Ingemar
> 
> 
> > 
> > I am not sure why you need multi[le levels, the level parameter 
> > provides a maximum and not a specific configuration.
> > 
> > I am also not sure how you define a common mode that 
> dictates to the 
> > endpoint what they are supposed to send.
> > 
> >  
> > 
> > I prefer using something like image attribute which is a general 
> > parameter and not a codec specific one to request a mode from a 
> > sender.
> > 
> > Roni Even
> > 
> >  
> > 
> > [My last response is stuck in moderation. this time I'll 
> let it wait 
> > so hopefully the document will go through eventually.]
> > 
> >  
> > 
> stay within 
> > the syntax framework defined in the current draft.  
> However, my usage 
> > of sprop-operation-point-info to negotiate receiving 
> operation points 
> > creates a conflict with the original definition: a switching 
> > conference bridge can only send what it receives, so if it receives 
> > something different than it declared in sprop-operation-point-info 
> > then what it sends won't conform to that declaration.
> > 
> >  
> >

---

From: "Stuart Taylor (sttaylor)" <[email-masked]>
Date: Tue, 22 Dec 2009 08:40:26 -0600

Authors,

Thank you for your consideration.  Your response indicates that you
intended to create a framework for the type of negotiation we need.
However, the current draft fails to state some important assumptions,
which permits multiple interpretations.

If I understand your answers correctly, you assume that when an offerer
declares sprop-operation-point-info it is declaring not only what it
wants to send, but also what it wants to receive. This goes a long way
to satisfying our requirements, but I do not see where this assumption
is stated in the draft.  The concept of layering plan symmetry, where
both endpoints send using the same layering structure, is not discussed.

Based on that assumption, I have some questions:

Question 1:
If an answerer uses profile-level-id instead of scalable-layer-id, is it
still obligated to use the offered layering plan when sending?

Question 2:
Is either endpoint allowed to change its sending layering plan to be
inconsistent with the declared sprop parameters without a re-INVITE?

Question 3:
If an answer contains sprop-operation-point-info, is it allowed to be
inconsistent with the offered sprop-operation-point-info?  If yes, does
that mean asymmetric layering plans are supported under the draft?

Question 4:
We are confused the sentence, "A receiver MAY indicate its choice of the
highest layer it wants to send and/or receive using the optional media
type parameter scalable-layer-id."  Note that the sentence should start
with "An answerer" instead of "A receiver", since both endpoints can be
receivers and only the answerer can use scalable-layer-id (right?), but
that's not the problem.  Which of the following interpretations are
true?

A)  The answerer will receive all the layers with a lower layer_id
value, even if there is no dependency between the selected layer and the
lower-numbered layer.

B)  The answerer will receive all the layers that are required to
compose the selected operation point, implying that layers independent
of the selected operation point (even with a lower layer_id) will not be
sent.

C)  The answerer will receive all the layers that are required to
compose the selected operation point and all the operation points that
precede the selected operation point in the sprop-operation-point-info
(regardless of layer_id value).  If this is the answer, what does it
mean if only sprop-scalablity-info, and not sprop-operation-point-info,
is declared?

Note that the layering plan is not unidimensional: temporal layers to
construct CIFp30 may precede layers to construct 4CIFp15. An endpoint
may not want to receive 30 fps layers after selecting 4CIFp15.  However,
a conference bridge will want to receive all the layers required to
construct both.

Question 5:
How would level-asymmetry-allowed be applied when
sprop-operation-point-info and scalable-layer-id are employed?  I would
like it to permit the sprop-operation-point-info to declare layers that
exceed the default profile-level-id, implying they may be sent but
cannot be received.  Similarly, the scalable-layer-id answer should not
limit the layers (within the plan) that the answerer can send.
 
Best regards,
Stuart Taylor

-----Original Message-----
From: Ye-Kui Wang [mailto:[email-masked]] 
Sent: Friday, December 18, 2009 8:00 AM
To: Stuart Taylor (sttaylor); 'Ingemar Johansson S'; [email-masked]
Cc: [email-masked]; 'Stephan Wenger'; 'Thomas Schierl'; 'Alex
Eleftheriadis'

Hi Stuart, 

We have studied and discussed your inputs among us authors of the draft,
and
here are our comments. Our comments are directly responding to your
minimum
requirements. This way, all your proposed text changes are hopefully
covered. 

1. The declared operation points are explicitly required to conform to
a single consistent layering scheme with an unambiguous hierarchy.  This
is
implied by the current draft but not actually stated.

2. By answering an SVC offer containing sprop-operation-point-info, the
answerer is agreeing to the declared operation points (up to the
layer-id
specified in the answer) for both receiving and sending.  The answerer's
encoder must produce a stream that is compatible with, but not
necessarily
identical to, the negotiated operation points. 

[Authors]: We think that this is also clear. If the direction attribute
is
sendrecv or not present, then what is said in the SDP applies to both
sending and receiving. If direction attribute of sendonly is present,
what
is said in the SDP applies to only sending. If direction attribute of
recvonly is present, what is said in the SDP applies to only receiving. 

We propose that either the sprop-operation-point-info is always used
symmetrically or that the offer should indicate whether symmetry is
required
through a new attribute.

[Authors]: We don't understand the logic between this proposal and the
above
requirement. Could you please clarify if the direction attribute is not
sufficient.

3. We suggest the following syntax for an indication that
sprop-operation-point-info should be interpreted symmetrically:
recv-operation-points=<comma separated list of layer id numbers>.  This
allows the offering endpoint to indicate the properties of important
layer
combinations, presumably matching the capabilities of various
represented
endpoints.  The identified layers correspond to identifiers in the
sprop-operation-point-info declared in the same offer, ordered by
priority.

[Authors]: Once the answerer chooses one operation point, the server
will
send all the lower layers required for presenting the operation point.
In
addition, layer IDs themselves are naturally in priority order. These
are
clear from the definitions of "layer", "operation points" etc. from
section
3. Therefore, we don't see the need of this proposed change. 

4. When sprop-operation-point-info declares an operation point with
layer-id=1, this is describing the SVC base layer.  In the multipoint
use
case described here we should expect the conference bridge to always
declare
this layer, but there may be other use cases where this is not true.  If
declared, all parties must produce a stream that can be shaped down an
AVC
stream which is consistent with this base layer definition.  The
profile-level-id is interpreted as in RFC-3984bis.  For AVC
interoperability, parameters of this layer other than the
profile-level-id
are to be taken as strong hints rather than mandates.

[Authors]: A conforming SVC bitstream must contain an AVC base layer. It
is
not possible to have a conforming SVC bitstream without an AVC base
layer.
The profile-level-id is specified in this SVC draft. Of course, the
semantics for the AVC base layer are the same as that described in
3984bis.
Therefore, we don't see the need of a change to address this
requirement.

5. The answering endpoint is not required to exactly match the layering
scheme used by the offering endpoint.  A stream is compatible with the
negotiated operation points if one of the following is true:
a. It contains only a base layer that is compliant with the
profile-level-id defined in the operation point identified as layer-id
#1.
Compliance is defined as in RFC-3984, implying that the encoder may
produce
at a lower level than indicated by the profile-level-id.

[Authors]: Encoders are always allowed to output a bitstream that is
actually of a lower level than the one declared. We don't see the need
for a

change herein.

b. It contains a base layer that is complaint with the declared base
layer in all particulars, optionally plus enhancement layers.  The
aggregate
of all layers should match at least one of the negotiated operation
points
by having the same frame dimensions, frame rate and maximum bit rate
less
than or equal to that operation point, and consistent with to the
profile-level-id.

[Authors]: When the chosen operation point includes more than the base
layer, the
bitstream of the chosen operation point must certainly match what is
chosen.
And again, encoders are always allowed to output a bitstream that is
actually of a lower level than the one declared. Therefore, we think
that
this
requirement is already met by the current draft. 

Best Regards,
Authors of the SVC draft