All DCEP messages MUST
be sent using ordered delivery and reliable transmission. They MUST
be sent on the same outgoing stream as the user messages belonging to the corresponding data channel. Multiplexing and demultiplexing is done by using the SCTP PPID. Therefore, a DCEP message MUST
be sent with the assigned PPID for the Data Channel Establishment Protocol (see Section 8.1
). Other messages MUST NOT
be sent using this PPID.
The peer that initiates opening a data channel selects a stream identifier for which the corresponding incoming and outgoing streams are unused. If the side is acting as the DTLS client, it MUST
choose an even stream identifier; if the side is acting as the DTLS server, it MUST
choose an odd one. The initiating peer fills in the parameters of the DATA_CHANNEL_OPEN message and sends it on the chosen stream.
If a DATA_CHANNEL_OPEN message is received on an unused stream, the stream identifier corresponds to the role of the peer, and all parameters in the DATA_CHANNEL_OPEN message are valid, then a corresponding DATA_CHANNEL_ACK message is sent on the stream with the same stream identifier as the one the DATA_CHANNEL_OPEN message was received on.
If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions above, the receiver MUST
close the corresponding data channel using the procedure described in [RFC 8831
] and MUST NOT
send a DATA_CHANNEL_ACK message in response to the received message. This might occur if, for example, a DATA_CHANNEL_OPEN message is received on an already used stream, there are problems with parameters within the DATA_CHANNEL_OPEN message, the odd/even rule is violated, or the DATA_CHANNEL_OPEN message itself is not well formed. Therefore, receiving an SCTP stream-reset request for a stream on which no DATA_CHANNEL_ACK message has been received indicates to the sender of the corresponding DATA_CHANNEL_OPEN message the failure of the data channel setup procedure. After also successfully resetting the corresponding outgoing stream, which concludes the data channel closing initiated by the peer, a new DATA_CHANNEL_OPEN message can be sent on the stream.
After the DATA_CHANNEL_OPEN message has been sent, the sender of that message MAY
start sending messages containing user data without waiting for the reception of the corresponding DATA_CHANNEL_ACK message. However, before the DATA_CHANNEL_ACK message or any other message has been received on a data channel, all other messages containing user data and belonging to this data channel MUST
be sent ordered, no matter whether the data channel is ordered or not. After the DATA_CHANNEL_ACK or any other message has been received on the data channel, messages containing user data MUST
be sent ordered on ordered data channels and MUST
be sent unordered on unordered data channels. Therefore, receiving a message containing user data on an unused stream indicates an error. In that case, the corresponding data channel MUST
be closed, as described in [RFC 8831