Re: [clue] IETF#89: CLUE Data Channel - Next Step

[Paul Kyzivat <[e-mail]>]

Comment at end

On 3/5/14 8:38 PM, Christer Holmberg wrote:
> Hi data channel lovers,
>
> Today we agreed to adopt DECP for the CLUE Data Channel (CDC).
>
> (Note that we did NOT prevent usage of draft-eyzak, if the mechanism
> gets done in MMUSIC).
>
> (We also agreed that there needs to be A way to identity that a call can
> use CLUE, but that is NOT the topic of this e-mail - please start a
> separate thread if you want to discuss that).
>
> As time has been allocated for the CDC also on Friday, I intend to use
> that time to discuss the issue regarding who is responsible for sending
> DATA_CHANNEL_OPEN.
>
>
> First we need to decide if we want to specify who is responsible, or
> whether we’ll specify procedures when both endpoints send DCO.
>
> My suggestion is that we do specify that one of the endpoints is
> responsible.
>
> Second, if we agree to the suggestion above, we need to decide which
> endpoint is responsible for sending DCO. Alternatives are e.g. offerer,
> answerer, DTLS client and DTLS server. Note that this is separate from
> which endpoint establishes the SCTP association, and how the DTLS roles
> are determined - those procedures are defined in the sctp-sdp draft.
>
> Also, we do need to describe what happens if both endpoint still sends
> DCO. It would be considered an error case, and we could e.g. say that
> the endpoint responsible for sending DCO would have to reset the
> stream/channel created by the other endpoint.

Some (maybe all) of these algorithms for determining which end does the 
open may be difficult for applications to apply. In particular I'm 
thinking about an RTCWEB browser app. It *may* have access to info about 
whether it is the "even" or "odd" end, but maybe not.

It could figure that out by doing an experiment - opening a channel and 
then discovering its stream id. But that is silly.

I doubt it will have access to whether it is DTLS client or server. It 
*might* be able to determine if it is offerer or answerer (of the first 
O/A in which the SCTP m-line appears. But this also seems tricky to 
figure out. (It will likely have to scan every SDP sent or received, 
looking for the SCTP m-line.)

Another alternative I'll try again is for each end to send an open *if* 
it wants to be an advertiser. Then it will use that channel to send 
advertisements and receive configurations. In the normal case, each will 
then receive an open. It would use that channel to receive 
advertisements and send configure messages.

Or, we could just let each side send an open. If one side receives and 
open before sending one, then it won't send its own - both will use that 
one. If an endpoint receives an open after sending its own, it will ack 
that. At that point it has two CLUE channels. Both sides agree that if 
they have two clue channels, then they only use the one with the smaller 
stream ID, and send a reset on the one with the larger stream id. This 
does mean that any messages sent on the stream that is reset will be 
ignored. (That can happen if messages are sent immediately after the 
open, before the ack is received.)

Either of these symmetric ones are easy to implement in any environment.

	Thanks,
	Paul