Subject: [clue] comment on coclusion 7 of the iterim meeting report

From: "Roni Even" <[email-masked]>
Date: Tue, 9 Oct 2012 09:03:34 +0200

Hi

7) Empty Advertisement:  Is this allowed and what does it mean? 

Conclusion: Yes. It means you have nothing you are willing to send. May also
still want media in other direction. 

I think that the correct sentence is "It means you have nothing you are
willing to advertise". The SDP is still there and you can still send media
based on the SDP. 

BTW: conclusion 9 has some weird characters.

Roni

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Oct 2012 11:54:49 -0400

Roni,

On 10/9/12 3:03 AM, Roni Even wrote:
> Conclusion: Yes. It means you have nothing you are willing to send. May
> also still want media in other direction.
>
> I think that the correct sentence is “It means you have nothing you are
> willing to advertise”. The SDP is still there and you can still send
> media based on the SDP.

Hmm. I think what you say requires some discussion.

When a clue endpoint connects with another endpoint that doesn't support 
clue it is clear that one should decide what to do based on the SDP in a 
normal non-clue way.

But when both ends support clue and exchange advertisements it isn't 
clear to me what should be done about stuff described in SDP that isn't 
negotiated via the advertisements.

ISTM that there are different possible philosophies here, that we 
haven't discussed, or even realized need to be discussed. Off the top of 
my head:

1) we could consider that advertisements and configurations provide the 
high level view of the session, while the SDP provides a lower level 
mechanism to support that and fill in details. There is a clear mapping 
from elements in the configurations to elements in the SDP. The meaning 
of the SDP for proper rendering can't be discerned from the SDP alone - 
the advertisement and configuration are required to understand it. Any 
"extra" SDP that isn't referenced from the advertisements and 
configurations then probably doesn't apply to the telepresence session. 
It may be ignored, or else may relate to some other "application" 
sharing the same session.

2) we could consider that the negotiated SDP in the session is the 
primary representation of the telepresence session. In principle this 
could be sufficient without exchange of any advertisements and 
configurations. Advertisements and configurations are exchanged to 
*supplement* this - provide extra hints about what to do when the SDP 
itself isn't sufficient, and also to provide hints about what SDP would 
be fruitful to negotiate. Any SDP that isn't referenced by 
advertisements and configurations should be taken at face value and 
fitted into the telepresence session using local algorithms.

Frankly I had been thinking that (1) was the intended way. It wasn't 
until your message that I realized there might be another view.

It seems to me that this needs careful consideration.

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Tue, 9 Oct 2012 18:49:11 +0200

Paul,
I think that the change I proposed is in-line with conclusion 9, where the
media started based on the first offer answer and the advertisement may be
done later.
 This is also the call flow in
http://tools.ietf.org/html/draft-romanow-clue-call-flow-02 .
Roni
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
Sent: 09 October, 2012 5:55 PM
To: [email-masked]
Subject: Re: [clue] comment on conclusion 7 of the interim meeting report

Roni,

On 10/9/12 3:03 AM, Roni Even wrote:
> Conclusion: Yes. It means you have nothing you are willing to send. 
> May also still want media in other direction.
>
> I think that the correct sentence is "It means you have nothing you 
> are willing to advertise". The SDP is still there and you can still 
> send media based on the SDP.

But when both ends support clue and exchange advertisements it isn't clear
to me what should be done about stuff described in SDP that isn't negotiated
via the advertisements.

ISTM that there are different possible philosophies here, that we haven't
discussed, or even realized need to be discussed. Off the top of my head:

1) we could consider that advertisements and configurations provide the high
level view of the session, while the SDP provides a lower level mechanism to
support that and fill in details. There is a clear mapping from elements in
the configurations to elements in the SDP. The meaning of the SDP for proper
rendering can't be discerned from the SDP alone - the advertisement and
configuration are required to understand it. Any "extra" SDP that isn't
referenced from the advertisements and configurations then probably doesn't
apply to the telepresence session. 
It may be ignored, or else may relate to some other "application" 
sharing the same session.

2) we could consider that the negotiated SDP in the session is the primary
representation of the telepresence session. In principle this could be
sufficient without exchange of any advertisements and configurations.
Advertisements and configurations are exchanged to
*supplement* this - provide extra hints about what to do when the SDP itself
isn't sufficient, and also to provide hints about what SDP would be fruitful
to negotiate. Any SDP that isn't referenced by advertisements and
configurations should be taken at face value and fitted into the
telepresence session using local algorithms.

Frankly I had been thinking that (1) was the intended way. It wasn't until
your message that I realized there might be another view.

	Thanks,
	Paul

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Oct 2012 14:26:16 -0400

> http://tools.ietf.org/html/draft-romanow-clue-call-flow-02 .

I think there is a difference (at least there could be) between the 
defaults that apply before the first exchange of advertisements, and 
what happens later.

We discussed the possibility that there could be a well defined 
"default" advertisement that is assumed until an actual advertisement is 
received. (Though I don't think we reached any conclusion.)

What we didn't discuss what what that default might be, or whether it 
would be "fixed" or "derived" from the SDP.

We *did* discuss the possibility that if there was an explicit way to 
say you wanted the default advertisement then you might be able to 
revert to the default advertisement at a later point in the session, and 
that that could be useful.

Perhaps you are suggesting that the "empty" advertisement means the same 
as the "default" advertisement - to do whatever is implied by the SDP. 
That is *possible*, but it doesn't seem like the obvious choice to me.

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Tue, 9 Oct 2012 20:59:27 +0200

Paul,
Here is a scenario  two endpoints A and B support CLUE. Let's say that A is
a one camera system with two monitors that support also H.239 like
presentation. So it sends an offer with CLUE channel and the SDP will
include the people video stream and the support for BFCP and the content.
B responds with similar SDP and the CLUE channel is opened, now B sends an
advertisement with one video media capture and also a second capture scene
indicating it can send a presentation. So this looks like two similar
systems. Now what is the reason for A to send an advertisement, for
all-purpose he can close the clue channel and continue as non-clue call. The
reason to open the CLUE  channel is because the systems do not know when
starting the call what is in the other side before opening a CLUE channel.

I am not sure what a default advertisement is?  
I am not sure that there is a requirement to have advertisements in both
directions. 
 Also According to SIP, media can flow when a receive port is available in
the O/A and I do not think we intend to change the semantic of SIP and this
is also what the call flow document described.

Practically, it make sense to send media ASAP (at least audio and probably
video) in order to provide a better user experience (once connected you
expect to be able to speak and hear the other side.

BTW: I think that having max-ssrc for SSRC multiplexing can help both side
to see that there is no need for CLUE here.

Roni

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 09 October, 2012 8:26 PM
To: Roni Even
Cc: [email-masked]
Subject: Re: [clue] comment on conclusion 7 of the interim meeting report

On 10/9/12 12:49 PM, Roni Even wrote:
> Paul,
> I think that the change I proposed is in-line with conclusion 9, where 
> the media started based on the first offer answer and the 
> advertisement may be done later.

I think there is a difference (at least there could be) between the defaults
that apply before the first exchange of advertisements, and what happens
later.

We discussed the possibility that there could be a well defined "default"
advertisement that is assumed until an actual advertisement is received.
(Though I don't think we reached any conclusion.)

What we didn't discuss what what that default might be, or whether it would
be "fixed" or "derived" from the SDP.

We *did* discuss the possibility that if there was an explicit way to say
you wanted the default advertisement then you might be able to revert to the
default advertisement at a later point in the session, and that that could
be useful.

Perhaps you are suggesting that the "empty" advertisement means the same as
the "default" advertisement - to do whatever is implied by the SDP. 
That is *possible*, but it doesn't seem like the obvious choice to me.

	Thanks,
	Paul

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Paul Kyzivat
> When a clue endpoint connects with another endpoint that doesn't 
> support clue it is clear that one should decide what to do based on 
> the SDP in a normal non-clue way.
>
> clear to me what should be done about stuff described in SDP that 
> isn't negotiated via the advertisements.
>
my head:
>
> 1) we could consider that advertisements and configurations provide 
> the high level view of the session, while the SDP provides a lower 
> level mechanism to support that and fill in details. There is a clear 
> mapping from elements in the configurations to elements in the SDP. 
> The meaning of the SDP for proper rendering can't be discerned from 
> the SDP alone - the advertisement and configuration are required to 
> understand it. Any "extra" SDP that isn't referenced from the 
> advertisements and configurations then probably doesn't apply to the
telepresence session.
> could be sufficient without exchange of any advertisements and
configurations.
> itself isn't sufficient, and also to provide hints about what SDP 
> would be fruitful to negotiate. Any SDP that isn't referenced by

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Oct 2012 16:13:00 -0400

> systems. Now what is the reason for A to send an advertisement,  for

OK. That is plausible. System A can decide that the default handling 
will be sufficient, so that it need not send an advertisement. But it 
should still send a config for the advertisement from B.

> starting the call what is in the other side before opening a CLUE channel.

But advertisements can change mid-call. If the clue channel is closed 
then that won't be possible.

> I am not sure what a default advertisement is?

I'm not sure either. We would have to decide how to infer one, and how 
that relates to the SDP that is negotiated. We need to decide what one 
does based on the initial SDP in the absence of any advertisement.

> I am not sure that there is a requirement to have advertisements in both

Maybe not. But if we can count of them it can ease the initial call 
setup, possibly eliminating an O/A exchange. (Though we haven't decided 
if we care about that.)

> is also what the call flow document described.

Media can flow. There is no promise about what happens to it. It may all 
be ignored. The advertisement and config give context to decide how to 
do something useful with it.

> expect to be able to speak and hear the other side.

Certainly it makes sense to send *something*. But it might not be what 
you ultimately want. It might just be a single video stream with a slide 
announcing the session, and a single audio stream with background music. 
It might be nothing else gets sent until after an advertisement is sent 
and a config received.

The important thing here is that we are clear enough about expectations 
that things will interoperate properly.

> to see that there is no need for CLUE here.

I now remember that there was some discussion in SJ that we provide some 
indication in SDP of those m-lines that are in use by CLUE. Then *other* 
m-lines could be treated via other mechanisms.

Perhaps there is more that we can do with SDP so that some subset of 
clue can be accomplished without need of clue messaging. But we need to 
decide if we want to go that way. AFAIK it hasn't been considered.

ISTM the minimum is that prior to advertisement/config exchange the 
media is handled as if this was not a clue session. After the 
advertisement/config exchange the media would then be processed 
according to what is written in the clue specs. But I assume there are 
other ways to define this.

I hope some other people will give opinions here so that this isn't just 
a dialog. I don't have strong opinions about what the right way is here 
- just that so far we haven't decided and we need to.

	Thanks,
	Paul