Subject: [AVT] SST switched multipoint conferences in draft-ietf-avt-rtp-svc-20

From: "Stuart Taylor (sttaylor)" <[email-masked]>
Date: Thu, 3 Dec 2009 11:32:06 -0600

[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]

---

From: Roni Even <[email-masked]>
Date: Tue, 15 Dec 2009 00:40:00 +0200

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

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]

---

From: "Stuart Taylor (sttaylor)" <[email-masked]>
Date: Tue, 15 Dec 2009 08:14:06 -0600

[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

Stuart Taylor

Technical Leader,

Cisco Systems

[email-masked]

---

From: "Stuart Taylor (sttaylor)" <[email-masked]>
Date: Mon, 14 Dec 2009 17:18:01 -0600

Stuart Taylor

Hi,

Roni Even

Stuart Taylor

Technical Leader,

Cisco Systems

[email-masked]

---

From: Roni Even <[email-masked]>
Date: Tue, 15 Dec 2009 17:04:39 +0200

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

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

Hi,

Roni Even

Stuart Taylor

Technical Leader,

Cisco Systems

[email-masked]

---

From: "Stuart Taylor (sttaylor)" <[email-masked]>
Date: Tue, 15 Dec 2009 09:29:19 -0600

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 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

Stuart Taylor

Stuart Taylor

Hi,

Roni Even

Stuart Taylor

Technical Leader,

Cisco Systems

[email-masked]