Subject: [clue] CLUE Data Channel: Things to think about for London

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Feb 2014 11:03:05 +0000

Hi,

London is coming up, and there are some things I'd like us to focus on when it comes to the CLUE data channel.

First, as I have not seen any suggestions to do otherwise, for the moment I am making the following working assumptions:

-          We will use the WebRTC data channel as base for the CLUE data channel (how much we will eventually document in CLUE, or whether we can simply reference the RTCWEB specs, is to be seen).

-          We will AT LEAST use the mechanism defined in the SCTP-SDP draft to negotiate the SCTP/DTLS association used for the data channel.

We can always change these assumptions later. But, if someone thinks we should not even make those working assumptions at this point: please speak up now :)

Now, what I would like to get consensus on (or, at least focus the discussions on) in London, and what I therefor ask people to focus on for now, is:

-          Whether we are going to use the DCP. There has been good discussions on the RTCWEB list, addressing many of the concerns that at least I had raised;

-          IF we will use the DCP, what (if any) CLUE specific procedures do we need to specify in order to avoid glare (read: both endpoints establishing separate channels).

-          Whether we are going to use Richard's draft.

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 12 Feb 2014 19:33:31 +0000

Hi Christer,

-          Whether we are going to use Richard's draft.
[Raju] DCP allows user to send data over data channel immediately after "data channel open" request is sent without waiting for "ack". Do we need such capability for CLUE? Per my understanding we don't need it. Per "6.  Example: A call between two CLUE-capable endpoints" of http://www.ietf.org/id/draft-kyzivat-clue-signaling-06.txt the CLUE control messages can only be sent after SDP offer/answer is complete. So, using DCP may actually cause issues wrt user trying to send CLU control msgs before SDP offer/answer is completed.
In fact, using external negotiation avoids one RTT delay (which happens after SDP O/A is complete) associated to DCP and avoids "glare" situations.

Also, SCTP/DTLS media info for CLUE is signalled via SDP O/A anyway along with other audio, video media. So, using the same SDP O/A sequence for external negotiation makes sense and fits well within this framework.

Therefore, I suggest using external data channel negotiation (Richard's draft) for CLUE data channel.
Btw, we will be adding more clear procedure to Richard's draft about when an application can use externally negotiated data channel. This will be in the draft that will be proposed to MMUSIC at London.

-Raju

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Feb 2014 15:09:04 -0500

On 2/12/14 2:33 PM, Makaraju, Maridi Raju (Raju) wrote:
> Hi Christer,
>
> Now, what I would like to get consensus on (or, at least focus the
> discussions on) in London, and what I therefor ask people to focus on
> for now, is:
>
> -Whether we are going to use the DCP. There has been good discussions on
> the RTCWEB list, addressing many of the concerns that at least I had raised;
>
> -IF we will use the DCP, what (if any) CLUE specific procedures do we
> need to specify in order to avoid glare (read: both endpoints
> establishing separate channels).
>
> -Whether we are going to use Richard’s draft.
>
> */[Raju] /*DCP allows user to send data over data channel immediately
> after “data channel open” request is sent without waiting for “ack”. Do
> we need such capability for CLUE? Per my understanding we don’t need it.
> Per “6.  Example: A call between two CLUE-capable endpoints” of
> http://www.ietf.org/id/draft-kyzivat-clue-signaling-06.txt the CLUE
> control messages can only be sent after SDP offer/answer is complete.
> So, using DCP may actually cause issues wrt user trying to send CLU
> control msgs before SDP offer/answer is completed.

I believe the O/A must be completed before it is possible to establish 
the DTLS foundation for the SCTP association. And you can't send data 
until that happens. (With webrtc, it think you may be able to request 
that the channel be opened and send data, but it will be buffered until 
the SCTP association is up.)

> In fact, using external negotiation avoids one RTT delay (which happens
> after SDP O/A is complete) associated to DCP and avoids “glare” situations.
>
> Also, SCTP/DTLS media info for CLUE is signalled via SDP O/A anyway
> along with other audio, video media. So, using the same SDP O/A sequence
> for external negotiation makes sense and fits well within this framework.

Yes, it "fits".

OTOH, it will be more complex for an RTCWEB client to deal with.
DCP would be more natural for that.

> Therefore, I suggest using external data channel negotiation (Richard’s
> draft) for CLUE data channel.

> Btw, we will be adding more clear procedure to Richard’s draft about
> when an application can use externally negotiated data channel. This
> will be in the draft that will be proposed to MMUSIC at London.

Raju - I understand Richard has left A-L. I heard that Keith would be 
taking over the authoring of Richard's draft. Are you also involved with 
that?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Feb 2014 15:16:09 -0500

On 2/12/14 6:03 AM, Christer Holmberg wrote:
> Hi,
>
> London is coming up, and there are some things I’d like us to focus on
> when it comes to the CLUE data channel.
>
> First, as I have not seen any suggestions to do otherwise, for the
> moment I am making the following working assumptions:
>
> -We will use the WebRTC data channel as base for the CLUE data channel
> (how much we will eventually document in CLUE, or whether we can simply
> reference the RTCWEB specs, is to be seen).
>
> -We will AT LEAST use the mechanism defined in the SCTP-SDP draft to
> negotiate the SCTP/DTLS association used for the data channel.
>
> We can always change these assumptions later. But, if someone thinks we
> should not even make those working assumptions at this point: please
> speak up now J
>

You already had a suggestion for how to handle that over on the rtcweb list.

Another possibility -

Once again consider using two channels. E.g.,

Each endpoint that wants to be an advertiser opens a channel and then 
sends the first advertisement. The other end (as consumer) sends 
Configure on this channel. Assuming both ends want to be advertisers we 
end up with two channels. If one end doesn't want to be an advertiser it 
just doesn't open a channel. If the consumer doesn't want to configure 
anything, it immediately closes the channel the other end opened.

This has a certain elegant simplicity to it.

	Thanks,
	Paul

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 12 Feb 2014 21:36:13 +0000

Hi Paul,

>the SCTP association is up.)
[Raju] Yes. But that's the case with initial SDP offer/answer. But a 
sub-sequent offer/answer can use an already established SCTP/DTLS 
association to open a new data channel even before the offer/answer 
completes. With external negotiation, to send data, the offerer has to wait 
until answer arrives; while answerer can send data soon after sending
SDP answer. That means, the offerer should be prepared to receive data
before SDP answer arrives (early media).

> > after SDP O/A is complete) associated to DCP and avoids "glare"
> situations.
> >

[Raju] Agree.

> taking over the authoring of Richard's draft. Are you also involved with

[Raju] Yes. Keith and I will be taking over. Keith will be present at the London's meeting.

Thanks
raju