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

[Christer Holmberg <[e-mail]>]

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.

Regards,

Christer
Sent from Windows Mail