Subject: [clue] Does CLUE data channel failure implicitly trigger fallback to legacy mode?

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 Sep 2013 17:57:21 +0000

Hi,

In CLUE we have been talking about two modes: "legacy mode" and "CLUE mode".

Without going into the details in this thread, "legacy mode" basically means communication between a CLUE entity and a non-CLUE entity (read: an entity that does not support the CLUE protocol).

In "CLUE mode", there is a data channel established for the exchange of CLUE protocol messages.

One of the question has been whether a loss of that data channel means an automatic fallback to "legacy mode", or whether a fallback requires an explicit Offer, where the data channel is disabled etc.

My opinion is that fallback to legacy DOES require an explicit Offer, e.g. for the following reasons:

1) Make sure that all parties are aware of the fallback.

2) There might be dedicated m=audio/video lines for legacy mode, and during clue mode they might be disabled. An Offer is needed in order to enable them.

3) Similar to 2), there are a number of dedicated m=audio/video lines for clue mode, and when there is a fallback to legacy mode they need to be disabled (keeping them enabled might keep unecessary resources locked, and may also affect charging, etc).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Sep 2013 14:36:52 -0400

Hi Christer,

Thanks for taking this up. One request for you:

> In CLUE we have been talking about two modes: "legacy mode" and "CLUE mode".

IMO (and Mary's) we need a new name to replace "legacy" mode.
"Legacy" has the wrong connotation - of just old stuff that we are 
trying to get away from. That isn't what we mean here. Rather we mean 
something like "non-clue mode", but that it too cumbersome. I could live 
with "clueless mode", though it sounds a bit like a joke.

> Without going into the details in this thread, "legacy mode" basically
> means communication between a CLUE entity and a non-CLUE entity (read:
> an entity that does not support the CLUE protocol).
>
> One of the question has been whether a loss of that data channel means
> an automatic fallback to "legacy mode", or whether a fallback requires
> an explicit Offer, where the data channel is disabled etc.
>
> 2) There might be dedicated m=audio/video lines for legacy mode, and
> during clue mode they might be disabled. An Offer is needed in order to
> enable them.
>
> 3) Similar to 2), there are a number of dedicated m=audio/video lines
> for clue mode, and when there is a fallback to legacy mode they need to
> be disabled (keeping them enabled might keep unecessary resources
> locked, and may also affect charging, etc).

I agree with all the above.

It has been proposed by some that it might be desirable to close the 
clue channel yet remain in CLUE mode. At least in principle this could 
work. The last negotiated advertisement and configuration would remain 
in effect. I guess this would save *some* (small) amount of resources in 
cases where no changes in clue configuration are anticipated.

If we did support this, then we would require an even more overt way to 
indicate the transition to legacy mode.

Personally I don't find this compelling. I'm satisfied with absence or 
explicit closing of the clue channel as the indicator for legacy mode. 
But I think we need to get consensus on this.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 Sep 2013 06:42:47 +0000

Hi,

On 9/24/13 1:57 PM, Christer Holmberg wrote:
> "Legacy" has the wrong connotation - of just old stuff that we are trying to get away from. That isn't what we mean here. Rather we 
> mean something like "non-clue mode", but that it too cumbersome. I could live with "clueless mode", though it sounds a bit like a joke.

Another term that have been used is "single-stream mode". Not sure that is very good either, though, because in the example I intend to present next week there are actually 4 streams in the non-clue mode :)

>> during clue mode they might be disabled. An Offer is needed in order 
>> to enable them.
>>
>> for clue mode, and when there is a fallback to legacy mode they need 
>> to be disabled (keeping them enabled might keep unecessary resources 
> It has been proposed by some that it might be desirable to close the clue channel yet remain in CLUE mode. 
>
> At least in principle this could work. The last negotiated advertisement and configuration would remain in effect. I guess 
> this would save *some* (small) amount of resources in cases where no changes in clue configuration are anticipated.
>
> If we did support this, then we would require an even more overt way to indicate the transition to legacy mode.
>
> Personally I don't find this compelling. I'm satisfied with absence or explicit closing of the clue channel as the indicator for legacy mode. 

There may be a number of reason (some of which end users don't have any control over) why a the clue channel goes down, so my opinion is still that explicit closing (read: SDP Offer) is needed.

Having said that, if the clue channel does go down, we probably need some text on how to re-establish it.

Regards,

Christer

---

From: Christian Groves <[email-masked]>
Date: Wed, 25 Sep 2013 20:54:50 +1000

Hello,

Please see my comments below.

Christian

> Another term that have been used is "single-stream mode". Not sure that is very good either, though, because in the example I intend to present next week there are actually 4 streams in the non-clu…
[CNG] In Q.5/16 in the requirements document we have a legacy use case 
as well as requirements for interworking to legacy devices. I think the 
term is fine. We could always add a definition somewhere if its unclear.
> Having said that, if the clue channel does go down, we probably need some text on how to re-establish it.
[CNG] I think Paul is referring to me when he says "some". This was in 
the context of what does it actually mean to the media if the CLUE data 
channel is closed? If the CLUE data channel is closed it doesn't 
automatically mean that the media is removed or that the encoding of the 
media changes. The media is only removed or changed via SDP. So you can 
remove the CLUE data channel but the media established as a result of a 
CLUE exchange remains. What do we assume about the metadata (i.e. CLUE 
attributes) regarding those streams? i.e. is the spatial information 
valid or no longer valid, etc?

Does the removal or the CLUE data channel only give a legacy state? or 
is the legacy mode reverting back to media that would have been 
established in the absence of CLUE support?

For me legacy would be the later.

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 Sep 2013 11:46:18 +0000

Hi,

>>> trying to get away from. That isn't what we mean here. Rather we mean something like "non-clue mode", but that it too cumbersome. I could live with "clueless mode", though it sounds a bit like a joke.
>> Another term that have been used is "single-stream mode". Not sure 
>> that is very good either, though, because in the example I intend to 
>> present next week there are actually 4 streams in the non-clue mode :)
> [CNG] In Q.5/16 in the requirements document we have a legacy use case as well as requirements for interworking to legacy devices. I think the term is fine. We could always add a definition somewhere if its unclear.

Does Q.5/16 have a definition that we could use?

>>>> Without going into the details in this thread, "legacy mode" 
>>>> basically means communication between a CLUE entity and a non-CLUE entity (read:
>>>> One of the question has been whether a loss of that data channel 
>>>> means an automatic fallback to "legacy mode", or whether a fallback 
>>>> requires an explicit Offer, where the data channel is disabled etc.
>>>>
>>>> 3) Similar to 2), there are a number of dedicated m=audio/video 
>>>> lines for clue mode, and when there is a fallback to legacy mode 
>>>> they need to be disabled (keeping them enabled might keep unecessary 
>>>> resources locked, and may also affect charging, etc).
>>> At least in principle this could work. The last negotiated 
>>> advertisement and configuration would remain in effect. I guess this would save *some* (small) amount of resources in cases where no changes in clue configuration are anticipated.
>>>
> [CNG] I think Paul is referring to me when he says "some". This was in the context of what does it actually mean to the media if the 
> CLUE data channel is closed? If the CLUE data channel is closed it doesn't automatically mean that the media is removed or that the encoding 
> of the media changes. The media is only removed or changed via SDP. So you can remove the CLUE data channel but the media established as a 
> result of a CLUE exchange remains. What do we assume about the metadata (i.e. CLUE attributes) regarding those streams? i.e. is the spatial 
> information valid or no longer valid, etc?

My idea is that, in legacy mode, we only have a single audio stream, two video streams (of which one is for presentation/screen sharing), so there is no need for spatial information. 

If you want to exchange spatial information - you use CLUE. 

> Does the removal or the CLUE data channel only give a legacy state? or is the legacy mode reverting back to media that would have been established in the absence of CLUE support?

In my opinion, there is no "that would have been established". In the reverting-back-to-legacy SDP Offer, you need to explicitly negotiate the media you are going to use, the same way you do when you send the initial Offer for the session.

Regards,

Christer

---

From: Christian Groves <[email-masked]>
Date: Wed, 25 Sep 2013 23:39:17 +1000

Hello Christer,

Please see below.

Christian

> Does Q.5/16 have a definition that we could use?

[CNG] Here's the description of the legacy use case from F.TPS-Req:

This use case describes a case where a legacy videoconferencing endpoint 
(or other heterogeneous device such as voice only endpoint) is involved 
in the telepresence session. The legacy endpoint does not understand 
additions related to telepresence functionality and interworking is 
required to communicate between the telepresence and legacy endpoints. 
Figure 8 illustrates the use case.
This use case may also utilise other legacy equipment such as a legacy 
H.323 MCU in order to participate in a conference.

> If you want to exchange spatial information - you use CLUE.
[CNG] I agree that if you want spatial information you use CLUE. I think 
there's a difference in thinking of what legacy means. You seem to 
assign a particular mode or configuration of streams. For me legacy is 
with respect of the absence of CLUE rather than a particular media 
configuration. An endpoint could have 5 video streams and still be 
legacy if it doesn't understand CLUE.

> In my opinion, there is no "that would have been established". In the reverting-back-to-legacy SDP Offer, you need to explicitly negotiate the media you are going to use, the same way you do when y…
[CNG] Your definition of legacy above would fit my "that would have been 
established" description. If the endpoint didn't have CLUE it would have 
only used one audio and two video streams in the initial offer.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Sep 2013 16:37:49 +0000

Hi,

> legacy if it doesn't understand CLUE.

Sure, I don't think we want to forbid that.

The whole idea of defining how the initial Offer looks like, is to make sure people know what they at least have to support in order to communicate with a CLUE entity. But, in addition to that, you can of course negotiate as many streams as you want.

Regards,

Christer