Subject: [clue] Notes from design team meeting re: signaling open issues

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 16 Sep 2014 06:45:39 -0700

Here are my notes from the design team meeting.

CLUE signaling design team meeting
Sep 16, 2014
Rob Hansen, Mary Barnes, Paul Kyzivat, Mark Duckworth, Christian Groves, Roberta Presta, Roni Even, Jonathan Lennox
Rob discussed issues
*         Fallback to non-CLUE - when does it happen?
o    signalling document has a proposal that defines when this happens, but there are other ideas
o    Rob's idea (in the signaling doc) is to use the same criteria to enable CLUE as to disable it
o    If data channel connection is lost, probably don't want that to mean the call is not CLUE enabled any more
o    The group agrees with Rob's proposal
*         Fallback to non-CLUE - what does it mean?
o    When fallback to non CLUE-enabled occurs, then CLUE-controlled media stops.
o    some other details about handling data channel and CLUE protocol should be defined
o    Should close the CLUE channel.  Can keep SCTP open if it is used for other things.
*         When making an SDP offer, if the offerer wants to enable CLUE then SDP should indicate this.  Even if previous O/A exchanges have not enabled CLUE.  This is consistent with an offerer always including video if it wants to add video to an audio call.
*         Security issues
o    Mary made suggestions
o    This doc shouldn't have a heavy security section.  Using existing protocols.
o    Jonathan suggested mention case of SDP and SCTP going to different addresses, one is attacker one is victim?
o    Mary plans to get a security review done during WGLC

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Sep 2014 10:24:45 -0400

Thanks Mark.

In addition, There was discussion of defining a new state for when the 
clue channel itself has been established. One term suggested was "CLUE 
Active". I think there was support for this. (Another suggestion was 
"CLUE Awesome", but I don't think it was serious.)

> Here are my notes from the design team meeting.

[snip]

> oJonathan suggested mention case of SDP and SCTP going to different
> addresses, one is attacker one is victim?

He was referring specifically to
http://tools.ietf.org/html/rfc5245#section-18.5.1

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Wed, 17 Sep 2014 11:37:56 +1000

I just want to make sure I understand what was being proposed for 
fallback of CLUE media streams. I'm going to try to avoid the use of 
"CLUE enabled" and "CLUE capable" and focus on the SDP and what it means.

Consider the following SDP where a CLUE controlled video stream has been 
configured, established and everything is awesome :-).

       a=group:CLUE 1 2
       m=application 6100 SCTP/DTLS 6100
       a=sctpmap:1 webrtc-datachannel
       a=mid:1
       ...
       m=video 6004 RTP/AVP 96
       a=rtpmap:96 H264/90000
       a=fmtp:96 profile-level-id=42e016
       a=sendonly
       a=mid:2
       a=label:enc1

Case 1) The SDP is updated to remove mid:2 effectively removing the 
video stream from CLUE control. However a=sendonly remains, i.e.
       a=group:CLUE 1
       m=application 6100 SCTP/DTLS 6100
       a=sctpmap:1 webrtc-datachannel
       a=mid:1
       ...
       m=video 6004 RTP/AVP 96
       a=rtpmap:96 H264/90000
       a=fmtp:96 profile-level-id=42e016
       a=sendonly

My assumption is that video continues to flow because the media stream 
is no longer under CLUE control (thus rules regarding configuring don't 
apply) and the sending direction is still send only. However as its not 
part of a CLUE group anymore any previously Advertised CLUEinfo 
regarding the video stream is no longer valid.

Case 2) The SDP is updated to remove mid:2 effectively removing the 
video stream from CLUE control the endpoint wants to stop the stream. My 
assumption is that to stop sending the video media stream either the 
port has to be changed to zero or a=inactive is set. Any CLUE info 
regarding the stream is discarded.

Case 3) The SDP is updated to remove mid:1 effectively closing the CLUE 
channel. However the video stream remain in the CLUE group, e.g.
       a=group:CLUE 2
       m=application 6100 SCTP/DTLS 6100
       a=sctpmap:1 webrtc-datachannel
       ...
       m=video 6004 RTP/AVP 96
       a=rtpmap:96 H264/90000
       a=fmtp:96 profile-level-id=42e016
       a=sendonly
       a=mid:2
       a=label:enc1
My assumption is that the video stream continues unchanged and as its 
still in a CLUE group any advertised CLUEinfo is still valid for the stream.

Case 4) To remove the CLUE protocol and media channels the CLUE group 
should be removed and the media line zeroed/made inactive, e.g.
       m=application 6100 SCTP/DTLS 6100
       a=sctpmap:1 webrtc-datachannel
       ...
       m=video 0 RTP/AVP 96

Rob is that what you were proposing?

Regards, Christian

On 16/09/2014 11:45 PM, Duckworth, Mark wrote:
> Rob Hansen, Mary Barnes, Paul Kyzivat, Mark Duckworth, Christian 
> Groves, Roberta Presta, Roni Even, Jonathan Lennox
>
> Rob discussed issues
>
> ·Fallback to non-CLUE - when does it happen?
>
> osignalling document has a proposal that defines when this happens, 
> but there are other ideas
>
> oRob's idea (in the signaling doc) is to use the same criteria to 
> enable CLUE as to disable it
>
> oIf data channel connection is lost, probably don't want that to mean 
> the call is not CLUE enabled any more
>
> oThe group agrees with Rob's proposal
>
> ·Fallback to non-CLUE - what does it mean?
>
> oWhen fallback to non CLUE-enabled occurs, then CLUE-controlled media 
> stops.
>
> osome other details about handling data channel and CLUE protocol 
> should be defined
>
> oShould close the CLUE channel.  Can keep SCTP open if it is used for 
> other things.
>
> ·When making an SDP offer, if the offerer wants to enable CLUE then 
> SDP should indicate this.  Even if previous O/A exchanges have not 
> enabled CLUE.  This is consistent with an offerer always including 
> video if it wants to add video to an audio call.
>
> ·Security issues
>
> oMary made suggestions
>
> oThis doc shouldn't have a heavy security section.  Using existing 
> protocols.
>
> oMary plans to get a security review done during WGLC
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Robert Hansen <[email-masked]>
Date: Wed, 17 Sep 2014 10:07:42 +0100

1) Yes
2) Yes
3) No. At present, the proposal is that by removing the SCTP association 
from the CLUE group the call is no longer CLUE-enabled. However, because 
the CLUE group is still present and still contains the video that video 
is still CLUE-controlled and hence can't be sent under these conditions.
4) Yes

Rob

On 17/09/14 02:37, Christian Groves wrote:
> Consider the following SDP where a CLUE controlled video stream has 
> been configured, established and everything is awesome :-).
>
>       a=group:CLUE 1 2
> is no longer under CLUE control (thus rules regarding configuring 
> don't apply) and the sending direction is still send only. However as 
> its not part of a CLUE group anymore any previously Advertised 
> CLUEinfo regarding the video stream is no longer valid.
>
> video stream from CLUE control the endpoint wants to stop the stream. 
> My assumption is that to stop sending the video media stream either 
> the port has to be changed to zero or a=inactive is set. Any CLUE info 
> Case 3) The SDP is updated to remove mid:1 effectively closing the 
> CLUE channel. However the video stream remain in the CLUE group, e.g.
>       a=group:CLUE 2

---

From: Christian Groves <[email-masked]>
Date: Fri, 19 Sep 2014 10:10:27 +1000

Hello Rob,

With respect to 3), I guess there's two points at which the video could 
stop. Actual closure of the CLUE SCTP streams through the data channel 
reset procedure, or once the updated SDP is received. I guess the actual 
trigger is the closure of the CLUE stream rather than the reception of 
the SDP.

Christian

On 17/09/2014 7:07 PM, Robert Hansen wrote:
> 1) Yes
> 2) Yes
> 3) No. At present, the proposal is that by removing the SCTP 
> association from the CLUE group the call is no longer CLUE-enabled. 
> However, because the CLUE group is still present and still contains 
> the video that video is still CLUE-controlled and hence can't be sent 
> under these conditions.
> 4) Yes
>
> Rob
>
>> My assumption is that video continues to flow because the media 
>> stream is no longer under CLUE control (thus rules regarding 
>> configuring don't apply) and the sending direction is still send 
>> only. However as its not part of a CLUE group anymore any previously 
>> Advertised CLUEinfo regarding the video stream is no longer valid.
>>
>> the port has to be changed to zero or a=inactive is set. Any CLUE 
>> info regarding the stream is discarded.
>>
>>> oIf data channel connection is lost, probably don't want that to 
>>> mean the call is not CLUE enabled any more
>>>
>>> oWhen fallback to non CLUE-enabled occurs, then CLUE-controlled 
>>> media stops.
>>>
>>> oShould close the CLUE channel.  Can keep SCTP open if it is used 
>>> for other things.
>>>

---

From: Robert Hansen <[email-masked]>
Date: Fri, 19 Sep 2014 16:23:07 +0100

I would say that the answer is whichever happens first.

Rob

On 19/09/14 01:10, Christian Groves wrote:
> Hello Rob,
>
> With respect to 3), I guess there's two points at which the video 
> could stop. Actual closure of the CLUE SCTP streams through the data 
> channel reset procedure, or once the updated SDP is received. I guess 
> the actual trigger is the closure of the CLUE stream rather than the 
> reception of the SDP.
>
> Christian
>
>>> video stream from CLUE control the endpoint wants to stop the 
>>> stream. My assumption is that to stop sending the video media stream 
>>> either the port has to be changed to zero or a=inactive is set. Any 
>>> CLUE info regarding the stream is discarded.
>>>
>>> My assumption is that the video stream continues unchanged and as 
>>> its still in a CLUE group any advertised CLUEinfo is still valid for 
>>> the stream.
>>>
>>> Case 4) To remove the CLUE protocol and media channels the CLUE 
>>> group should be removed and the media line zeroed/made inactive, e.g.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Sep 2014 12:54:59 -0400

> I would say that the answer is whichever happens first.

I'm question that. Can you tell an intentional closure of the stream 
from a reset due to an error of some sort? And even an intentional 
closure might be in preparation for an O/A to change the SCTP address.

I think it isn't until you get a new O/A that you know what is intended. 
Until then, ISTM it is better to leave the media running in accord with 
the last configurations.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Mon, 22 Sep 2014 10:43:44 +1000

I tend to agree with Paul, from a media flow perspective. I guess that 
means the criteria for establishing a media flow is different from 
removing a media flow.

Regards, Christian

On 20/09/2014 2:54 AM, Paul Kyzivat wrote:
> I think it isn't until you get a new O/A that you know what is 
> intended. Until then, ISTM it is better to leave the media running in 
> accord with the last configurations.
>
>     Thanks,
>     Paul
>
>> Rob
>>