Subject: [clue] Thoughts on relation between clue messages and SDP

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Oct 2012 18:09:18 -0400

After discussions at the interim around the call flows and signaling 
issues, and subsequent discussion, I have some revised ideas about how 
the clue messages and SDP O/A can be coordinated.

The Configure message selects capture encodings that the receiver wants 
the sender to send to it via RTP sessions RTP streams within those 
sessions that are specified in SDP.

In some cases it may be that a new Configure can reuse the RTP resources 
already present in a previously established O/A. But it is also possible 
that a new Configure will ask for capture encodings that require RTP 
resources that aren't present in the previously established O/A. In that 
case a new O/A will be needed, before or after that Configure is sent.

One of the questions that came up at the interim is whether the O/A to 
prep for a Configure should come before, or after, the Configure. An 
argument for doing the O/A *before* the Configure is that then it is 
known that the resources to support the Configure are available, and 
allows the Configure to reference elements present in the SDP. An 
argument for doing the O/A *after* the Configure is that then the 
answerer will understand *why* it is being asked to configure the SDP as 
specified, and so help it decide whether it wants to accept that.

I finally realized that the the Advertisement defines what is possible, 
and implicitly indicates what SDP will be required to support that. 
Hence, I think we can expect that an offerer can construct a new offer 
in contemplation of a Configure message it plans to send plus the last 
one it received, and in the context of the corresponding Advertisements. 
The Answerer can then evaluate that offer in the context of the same 
Advertisements. As long as the offer is consistent with current 
advertisements it should aim to construct an answer that accepts it.

With that approach, a Configure can be constructed relative to the most 
recent O/A.

During initial session setup, before the first Advertisements are 
exchanged, the offerer will have to construct the first offer without 
the context of an advertisement from the other side. It can however 
still construct the offer to be consistent with the Advertisement it 
plans to send. The Answerer can construct the answer in the context of 
the Advertisement it plans to send, constrained by what is in the offer. 
(The offer may not be sufficient for everything the answerer wishes to 
include.) Each side can then begin sending media that fits within that 
initial O/A, using a default Configure constructed locally. Concurrently 
Advertisements can be exchanged. After that Configure messages may be 
exchanged. (Or not if what is being received is satisfactory.)

It may turn out that in many cases the initial O/A is sufficient for the 
initial Configure that each side wants to send. If so then no new O/A is 
needed. Or it may turn out that it isn't. If not, then either side may 
initiate an O/A with an offer compatible with the desired Configure, I 
described above.

This also helps clarify that the Configure is both a selection from the 
advertisement and a mapping of that selection onto the SDP.

This also clarifies that the Advertisement must contain sufficient 
information to map a Configure onto the SDP needed to convey that. For 
instance, if the sender has encoders with independent IP addr/port, then 
the offer will require multiple m-lines for those, but if both the 
sender and receiver have all encoders on a single addr/port then one 
m-line may be sufficient. Since the offerer determines the set of 
m-lines in the O/A, it needs to figure this out on behalf of the answerer.

What do people think of this approach?

	Thanks,
	Paul (as individual)

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Oct 2012 09:33:34 -0400

I've been surprised that there have been no replies to this message.
Is that because it is so obvious and uncontroversial that no comment is 
needed? Or did I write it so poorly that nobody understands what I'm saying?

	Thanks,
	Paul

On 10/17/12 6:09 PM, Paul Kyzivat wrote:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Oct 2012 13:06:39 -0400

We just had a design team meeting with a very few people.
One of the things we discussed was which of the information that we need 
to transmit should be in clue messages vs. what should be in SDP.

One goal of our meeting in Atlanta will be to seek agreement on this.

It is a slightly different subject than I was trying to get at in this 
thread, but the two questions are tightly coupled.

The proposal I floated here embodies my assumption about that:

ASSUMPTION: A primary CLUE purpose is to advertise a "menu" of captures 
that *could* be sent, and to "order" from that menu (via Configure 
messages) the selection of captures that *should* be sent. All the 
information necessary to do that (descriptions of attributes of the 
available captures) is CLUE information, and belongs in the CLUE 
signaling protocol.

The SDP only needs to be sufficient to support the Configurations in 
effect. The way SDP is used with offer/answer is that each side 
specifies what it is prepared to *receive*, in contrast with the 
Advertisement which describes what can be sent.

The alternative that I think some have in mind is that SDP might carry 
much of the Advertisement. Doing so requires that SDP be able to convey 
many aspects of what can be *sent* in addition to its more common usage 
to carry what can be received. There is SDP notation to do this for some 
things, but not all things, so trying this would potentially require a 
number of SDP extensions. Also, the advertisement potentially describes 
many more alternatives than will be configured, so attempting to convey 
the advertisement in SDP is likely to explode the size of the SDP.

PLEASE, think about this, comment on the list prior to the meeting, and 
be prepared to discuss it at the meeting. It is really hard to make more 
progress without an agreement on this point.

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Mon, 29 Oct 2012 19:34:23 +0200

Paul,
Your assumption about SDP attributes being receive value is not precise. I
can agree that for part of the SSP attributes that have similar CLUE
attributes mostly the encoding ones that this is true. For the rest this is
not correct.
Example "content" or ""ssrc" SDP attributes which are sender ones.

As for what is in CLUE , my major issue is with the encoding groups which I
do not see the value of. The data model has a group assigned to a media
capture and not individual encodes. I also do not see how you will have
different individual encodes for media captures based on the current
definition of a capture scene.
There was some mention of simulcast which cannot be described with the
current encoding structure while we show in RTP mapping how it is done in
SDP

Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
Sent: 29 October, 2012 7:07 PM
To: [email-masked]
Subject: Re: [clue] Thoughts on relation between clue messages and SDP

We just had a design team meeting with a very few people.
One of the things we discussed was which of the information that we need to
transmit should be in clue messages vs. what should be in SDP.

ASSUMPTION: A primary CLUE purpose is to advertise a "menu" of captures that
*could* be sent, and to "order" from that menu (via Configure
messages) the selection of captures that *should* be sent. All the
information necessary to do that (descriptions of attributes of the
available captures) is CLUE information, and belongs in the CLUE signaling
protocol.

The SDP only needs to be sufficient to support the Configurations in effect.
The way SDP is used with offer/answer is that each side specifies what it is
prepared to *receive*, in contrast with the Advertisement which describes
what can be sent.

The alternative that I think some have in mind is that SDP might carry much
of the Advertisement. Doing so requires that SDP be able to convey many
aspects of what can be *sent* in addition to its more common usage to carry
what can be received. There is SDP notation to do this for some things, but
not all things, so trying this would potentially require a number of SDP
extensions. Also, the advertisement potentially describes many more
alternatives than will be configured, so attempting to convey the
advertisement in SDP is likely to explode the size of the SDP.

PLEASE, think about this, comment on the list prior to the meeting, and be
prepared to discuss it at the meeting. It is really hard to make more
progress without an agreement on this point.

	Thanks,
	Paul

On 10/22/12 9:33 AM, Paul Kyzivat wrote:
> Is that because it is so obvious and uncontroversial that no comment 
> is needed? Or did I write it so poorly that nobody understands what 
> I'm saying?
>
>      Thanks,
>      Paul
>
>> issues, and subsequent discussion, I have some revised ideas about 
>> how the clue messages and SDP O/A can be coordinated.
>>
>> The Configure message selects capture encodings that the receiver 
>> wants the sender to send to it via RTP sessions RTP streams within 
>> those sessions that are specified in SDP.
>>
>> In some cases it may be that a new Configure can reuse the RTP 
>> resources already present in a previously established O/A. But it is 
>> also possible that a new Configure will ask for capture encodings 
>> that require RTP resources that aren't present in the previously 
>> established O/A. In that case a new O/A will be needed, before or after
that Configure is sent.
>>
>> One of the questions that came up at the interim is whether the O/A 
>> to prep for a Configure should come before, or after, the Configure. 
>> An argument for doing the O/A *before* the Configure is that then it 
>> is known that the resources to support the Configure are available, 
>> and allows the Configure to reference elements present in the SDP. An 
>> answerer will understand *why* it is being asked to configure the SDP 
>> as specified, and so help it decide whether it wants to accept that.
>>
>> I finally realized that the the Advertisement defines what is 
>> possible, and implicitly indicates what SDP will be required to support
that.
>> Hence, I think we can expect that an offerer can construct a new 
>> offer in contemplation of a Configure message it plans to send plus 
>> the last one it received, and in the context of the corresponding
Advertisements.
>> With that approach, a Configure can be constructed relative to the 
>> most recent O/A.
>>
>> plans to send. The Answerer can construct the answer in the context 
>> of the Advertisement it plans to send, constrained by what is in the
offer.
>> include.) Each side can then begin sending media that fits within 
>> that initial O/A, using a default Configure constructed locally. 
>> Concurrently Advertisements can be exchanged. After that Configure 
>> messages may be exchanged. (Or not if what is being received is 
>> satisfactory.)
>>
>> It may turn out that in many cases the initial O/A is sufficient for 
>> the initial Configure that each side wants to send. If so then no new 
>> O/A is needed. Or it may turn out that it isn't. If not, then either 
>> side may initiate an O/A with an offer compatible with the desired 
>> Configure, I described above.
>>
>> This also helps clarify that the Configure is both a selection from 
>> the advertisement and a mapping of that selection onto the SDP.
>>
>> information to map a Configure onto the SDP needed to convey that. 
>> For instance, if the sender has encoders with independent IP 
>> addr/port, then the offer will require multiple m-lines for those, 
>> but if both the sender and receiver have all encoders on a single 
>> addr/port then one m-line may be sufficient. Since the offerer 
>> determines the set of m-lines in the O/A, it needs to figure this out 
>> on behalf of the answerer.
>>

---

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 29 Oct 2012 18:40:28 +0100

Hi Paul,

> ASSUMPTION: A primary CLUE purpose is to advertise a "menu" of captures that *could* be sent, and to "order" from that menu (via Configure messages) the selection of captures that *should* be sent. All the information necessary to do that (descriptions of attributes of the available captures) is CLUE information, and belongs in the CLUE signaling protocol.
> 
> The SDP only needs to be sufficient to support the Configurations in effect. The way SDP is used with offer/answer is that each side specifies what it is prepared to *receive*, in contrast with the Advertisement which describes what can be sent.

A big +1 from my side to both the assumption and its corollary about SDP utilization in CLUE.

Simon

> 
> The alternative that I think some have in mind is that SDP might carry much of the Advertisement. Doing so requires that SDP be able to convey many aspects of what can be *sent* in addition to its more common usage to carry what can be received. There is SDP notation to do this for some things, but not all things, so trying this would potentially require a number of SDP extensions. Also, the advertisement potentially describes many more alternatives than will be configured, so attempting to convey the advertisement in SDP is likely to explode the size of the SDP.
> 
> PLEASE, think about this, comment on the list prior to the meeting, and be prepared to discuss it at the meeting. It is really hard to make more progress without an agreement on this point.
> 
> 	Thanks,
> 	Paul
> 

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

		    <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Oct 2012 14:44:53 -0400

> Example "content" or ""ssrc" SDP attributes which are sender ones.

Yes, I realize it's not entirely true. But it is true enough to be an issue.

> definition of a capture scene.

I'm sure others know much better than I what is realistic with 
implementations, now and planned. But I understand this conceptually. 
Certainly if an MCU is involved, and has transcoding and scaling 
capabilities, then it might be able to offer a menu of alternative 
encodings for a particular capture. And I don't see how you would offer 
this menu of encodings in SDP. If it was done via a separate line for 
each possible capture-encoding, then it will require 
(number-of-captures)*(number of encodings) lines, which could get ugly.

I'm willing to be convinced otherwise, but it still seems to me that the 
set of encodings makes more sense as part of the clue "menu" than as 
part of the sip session.

> current encoding structure while we show in RTP mapping how it is done in

The way I have been thinking about it, simulcast would only be 
represented in the SDP if the selected Configuration actually selects 
multiple encodings of the same capture.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Tue, 30 Oct 2012 12:42:37 +1100

Hello Paul,

I agree with the assumption. I think that the advertisement should 
contain all the information needed to describe capture so that the 
receiver can make an educated decision on which capture/s to chose.

Regards, Christian

On 30/10/2012 4:06 AM, Paul Kyzivat wrote:
> One of the things we discussed was which of the information that we 
> need to transmit should be in clue messages vs. what should be in SDP.
>
> ASSUMPTION: A primary CLUE purpose is to advertise a "menu" of 
> captures that *could* be sent, and to "order" from that menu (via 
> Configure messages) the selection of captures that *should* be sent. 
> All the information necessary to do that (descriptions of attributes 
> of the available captures) is CLUE information, and belongs in the 
> CLUE signaling protocol.
>
> much of the Advertisement. Doing so requires that SDP be able to 
> convey many aspects of what can be *sent* in addition to its more 
> common usage to carry what can be received. There is SDP notation to 
> do this for some things, but not all things, so trying this would 
> potentially require a number of SDP extensions. Also, the 
> advertisement potentially describes many more alternatives than will 
> be configured, so attempting to convey the advertisement in SDP is 
> likely to explode the size of the SDP.
>
> PLEASE, think about this, comment on the list prior to the meeting, 
> and be prepared to discuss it at the meeting. It is really hard to 
> make more progress without an agreement on this point.
>
>     Thanks,
>     Paul
>
>>> resources
>>> the