Subject: [clue] Comment on rendering slides

From: "Elwell, John" <[email-masked]>
Date: Tue, 26 Jul 2011 14:32:53 +0200

Based on this morning's discussion, I have a problem with the proposal on the last slide:

"REQ-x:	It MUST be possible for a client to indicate, per media stream, supported rendering type(s).
REQ-y:	It MUST be possible to inform a client, per media stream, the rendering type(s) applied to the stream.  "

I believe this is a more asymmetric problem, and perhaps needs to be expressed in terms of:
"REQ-x:	It MUST be possible for a client to indicate, per media stream, rendering type(s) it is able to transmit.
 
REQ-y:	It MUST be possible to inform a client, per media stream, the rendering type(s) that can be received." 

(where the media types to be received would be selected from those able to be transmitted by the peer)

Notwithstanding, of course, that we need to explore more use cases to see whether this really fits.

John

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: [email-masked]
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 26 Jul 2011 07:51:30 -0700

I would prefer to continue to use the existing SDP mechanism to describe
what an endpoint is capable of receiving. I think the existing framework
draft provides a mechanism for a sender to indicate what it can send,
and for a receiver to select which of those it wants to receive.
As for asymmetry, I read the framework as allowing each side to act as a
sender and a receiver, facilitating asymmetry. If others think this is
not the case, then I agree with John that we need to clarify that.

What I think is missing is:
- a mechanism for a receiver to indicate a preference for, or a request
for, a specific rendering, or layout, or format (i.e. not just that I
want one H.264 video stream and one G.722 audio stream, but what I want
each of those to contain). 

The main benefit of doing this is that it might allow a sender to tailor
its description of what it can send to include options that the receiver
requested, as opposed to the sender trying to list every single possible
combination it can imagine. 
There are many ways to do this, and I do not want to get into the
details here, but if we agree that we need a mechanism for a receiver to
advertise its preference or request something specific from the sender
along these line, then I think we can cover Christer's rendering use
cases as well as some of the use cases I mentioned previously regarding
composition. If we list out the use cases, we can make sure this
mechanism is sufficient to address all of them.

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
> Sent: Tuesday, July 26, 2011 8:33 AM
> To: [email-masked]
> Subject: [clue] Comment on rendering slides
> 
> "REQ-x:	It MUST be possible for a client to indicate, per media
stream, supported rendering
> type(s).
> REQ-y:	It MUST be possible to inform a client, per media
stream, the rendering type(s) applied to
> the stream.  "
> "REQ-x:	It MUST be possible for a client to indicate, per media
stream, rendering type(s) it is
> able to transmit.
> 
> REQ-y:	It MUST be possible to inform a client, per media
stream, the rendering type(s) that can
> be received."
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 26 Jul 2011 17:23:55 +0200

Yes, I think the framework does provide for asymmetry, so perhaps the need to refine these requirements is moot. As to whether the current framework is mappable onto offer-answer, I am not sure. Probably by using >1 offer-answer cycles it could be done.

The question of whether we need to start with the receiver saying what it can receive (and the sender choosing what to select what to send on that basis) or start with the sender saying what it can send (and the receiver choosing what it wants to receive from that list) is a valid question and I am not sure I understand what the right answer is. For example, a receiver with a large screen perhaps has unlimited capabilities as to what it can display on that screen, so negotiation really needs to start with the sender saying what it can send and the receiver making a selection. On the other hand, a receiver with a single speaker might want to start by saying it can receive a single audio stream, and the sender selects the most appropriate stream to send out of those it is able to capture. Perhaps the framework has the necessary flexibility - I am not sure.

John 

> From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
> Sent: 26 July 2011 15:52
> To: Elwell, John; [email-masked]
> Subject: RE: [clue] Comment on rendering slides
> 
> > Based on this morning's discussion, I have a problem with 
> the proposal
> on the last slide:
> > 
> > Notwithstanding, of course, that we need to explore more 
> use cases to
> see whether this really fits.
> > 
> > John
> > 
> > John Elwell
> > Registered office: Brickhill Street, Willen Lake, Milton 
> Keynes, MK15
> 0DJ.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Jul 2011 11:35:19 -0400

(as individual)

I largely agree with Charles.

ISTM that what this is developing into is a more extensive negotiation 
than is possible with one round of o/a exchange.

Conceivably this could be done using multiple o/a exchanges, but that 
may not be the best way.

It seems to me that when a box advertises what it can provide, it 
probably doesn't want to be required to have all of those already 
available. IOW, the advertisement is like a menu from which the 
recipient can order, rather than a buffet from which the recipient can 
take things. (An SDP offer is a buffet.) The sender can then defer 
cooking the item until it knows it has an order.

The other issue is whether the sender can realistically enumerate the 
entire menu. Perhaps there are too many variations possible. In that 
case the "customer" may want to request something that is not on the 
menu. Maybe that then gets added to the menu, and maybe not.

Whether we need to go that way may depend on the mechanism used to 
deliver the advertisement/menu. If its done via SDP then the size of the 
menu is probably quite limited. If it is done some other way, then maybe 
not.

	Thanks,
	Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 26 Jul 2011 14:43:25 -0700

I think we are really talking about draft-romanow-clue-framework-00 and not the rendering slides, but I left the subject line the same :)

Yes, the framework allows both sides of an exchange to act as both a Media Provider (sender) and a Media Consumer (receiver), with a separate dialog for each direction, so the resulting media flows can be asymmetric.

As for the receiver indicating preferences up front, yes, it is partly there in the document, that is what the "hints" mentioned in section 7 are for.  The concept is there, but exactly what to do with it is not yet fleshed out.

And for the receiver indicating what it wants the streams to contain, that is partly there too if the sender advertises choices that have different attributes.  So for example a receiver could choose between a "composed" video stream and a "switched" video stream.  Exactly how the composition and switching is done is not specified in the framework.  If there is a need to exchange this information, perhaps it could be added, but I don't think the use case document has any cases yet where this would be required, and I didn't see it in the requirements document either.

The use case document also mentions ability to choose media from a specific source, for example I might want to always see a particular person in the conference even though that person rarely speaks.  This type of source selection is not yet covered in the framework.  For other types of source selection, I think we need more use cases to inform requirements.

I'm not sure either if this framework can or should be mapped on to SDP offer/answer.  That needs further discussion.

Mark Duckworth

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: Tuesday, July 26, 2011 11:35 AM
> To: [email-masked]
> Subject: Re: [clue] Comment on rendering slides
> 
> (as individual)
> 
> >> Based on this morning's discussion, I have a problem with the
> proposal
> > on the last slide:
> >>
> >> Notwithstanding, of course, that we need to explore more use cases
> to
> >> Registered office: Brickhill Street, Willen Lake, Milton Keynes,
> MK15
> > 0DJ.

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Wed, 27 Jul 2011 05:12:47 -0700

Just to add a bit to Mark's response.

I agree that it's not clear whether the framework should/could be mapped
to offer/answer. It seems like a good idea to develop this solution in
somewhat discrete stages, first specifying what we want to do, and then
considering the best (or possible) mechanisms, such as SDP.

As for the receiver starting the dialogue with the provider by telling
it information about itself to inform the advertisements sent by the
sender, the framework specifies this as optional. 

The current draft of the framework is specifically aimed at just the
basic ideas and deliberately leaves details for the next version, even
though they are of course crucial. It seems best if we could agree on
basic design decisions, and then fill them out- rather than presenting
everything at once - it seemed like we might get bogged down in details
and not focus on the basic ideas.

Allyn

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Duckworth, Mark
> Sent: Tuesday, July 26, 2011 2:43 PM
> To: [email-masked]
> I think we are really talking about draft-romanow-clue-framework-00
and
> not the rendering slides, but I left the subject line the same :)
> 
> Yes, the framework allows both sides of an exchange to act as both a
> Media Provider (sender) and a Media Consumer (receiver), with a
> separate dialog for each direction, so the resulting media flows can
be
> asymmetric.
> 
> As for the receiver indicating preferences up front, yes, it is partly
> there in the document, that is what the "hints" mentioned in section 7
> are for.  The concept is there, but exactly what to do with it is not
> yet fleshed out.
> 
> And for the receiver indicating what it wants the streams to contain,
> that is partly there too if the sender advertises choices that have
> different attributes.  So for example a receiver could choose between
a
> "composed" video stream and a "switched" video stream.  Exactly how
the
> composition and switching is done is not specified in the framework.
> If there is a need to exchange this information, perhaps it could be
> added, but I don't think the use case document has any cases yet where
> this would be required, and I didn't see it in the requirements
> document either.
> 
> The use case document also mentions ability to choose media from a
> specific source, for example I might want to always see a particular
> person in the conference even though that person rarely speaks.  This
> type of source selection is not yet covered in the framework.  For
> other types of source selection, I think we need more use cases to
> inform requirements.
> 
> I'm not sure either if this framework can or should be mapped on to
SDP
> offer/answer.  That needs further discussion.
> 
> Mark Duckworth
> 
> 
> Of
> > > As for asymmetry, I read the framework as allowing each side to
act
> > as a
> > > sender and a receiver, facilitating asymmetry. If others think
this
> > is
> > > for, a specific rendering, or layout, or format (i.e. not just
that
> I
> > > details here, but if we agree that we need a mechanism for a
> receiver
> > to
> > >> I believe this is a more asymmetric problem, and perhaps needs to
> be
> > > expressed in terms of:
> > >> (where the media types to be received would be selected from
those
> > > able to be transmitted by the peer)
> > >>
> > >> Siemens Enterprise Communications Limited is a Trademark Licensee
> of
> > > Siemens AG.
> > >>
> > >>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Jul 2011 09:25:34 -0400

> Yes, the framework allows both sides of an exchange to act as both a Media Provider (sender) and a Media Consumer (receiver), with a separate dialog for each direction, so the resulting media flows…

We aren't really discussing mechanism in detail yet, so this is probably 
premature. But do you *really* mean a separate *dialog* in each 
direction??? That seems very weird. I can understand how there might be 
a separate m-line for each direction, which allows the properties to 
differ radically.

> As for the receiver indicating preferences up front, yes, it is partly there in the document, that is what the "hints" mentioned in section 7 are for.  The concept is there, but exactly what to do…

OK. That wasn't entirely obvious, though that is what I had inferred.

> I'm not sure either if this framework can or should be mapped on to SDP offer/answer.  That needs further discussion.

I am in agreement with John here.

With o/a, one side or the other is "first". For both sides to indicate a 
preference, then receive an advertisement, then make a selection, two or 
even three o/a cycles may be needed. But that is doable.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Jul 2011 23:12:03 +0200

Hi,

Based on the very good discussions and feedback on tuesday morning, I am updating the slides, so that they talk about saying what one can send, and saying what one can receive.

Whether we eventually will use SDP for this I think is outside the scope as far as the requirements are concerned. Therefor, in order to avoid confusion, I have removed all text talking about "offer" and "answer".

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Elwell, John [[email-masked]]
Sent: Tuesday, July 26, 2011 6:23 PM
To: Charles Eckel (eckelcu); [email-masked]
Subject: Re: [clue] Comment on rendering slides

John

> receiver to

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Jul 2011 23:16:14 +0200

Hi,

>"REQ-x: It MUST be possible for a client to indicate, per media stream, rendering type(s) it is able to >transmit.
>
>REQ-y:  It MUST be possible to inform a client, per media stream, the rendering type(s) that can be >received."
>

Yes. And, it must also be indicated which types have actually been selected.

That can be done e.g. by the sender first "advertising" what it is able to send, and the receiver then "selects" what it wants to receive.

Regards,

Christer

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 27 Jul 2011 20:36:14 -0700

Paul,

Maybe separate *dialog* is the wrong word.  What I mean is a device that is both a Media Consumer and Provider will send/receive messages communicating information about what it will send and what it will receive, and those two sets of information are independent of each other.  But I guess you can call it a single dialog.

Mark

> Sent: Wednesday, July 27, 2011 9:26 AM
> To: [email-masked]
> and not the rendering slides, but I left the subject line the same :)
> >
> separate dialog for each direction, so the resulting media flows can be
> asymmetric.
> 
> > As for the receiver indicating preferences up front, yes, it is
> partly there in the document, that is what the "hints" mentioned in
> section 7 are for.  The concept is there, but exactly what to do with
> it is not yet fleshed out.
> 
> different attributes.  So for example a receiver could choose between a
> "composed" video stream and a "switched" video stream.  Exactly how the
> SDP offer/answer.  That needs further discussion.
>