DataChannel / implementation IETF conflict even / odd port problem #242

Closed
robin-raymond opened this Issue Sep 18, 2015 · 1 comment

Projects

None yet

2 participants

@robin-raymond
Contributor

DataChannel can be constructed and wired before Dtls/Ice is started and DTLS role is determined.

But in section 4 of data protocol doc https://www.ietf.org/id/draft-ietf-rtcweb-data-protocol-09.txt

It says:

To avoid collisions where both sides try to open a Data Channel with
   the same Stream Identifiers, each side MUST use Streams with either
   even or odd Stream Identifiers when sending a DATA_CHANNEL_OPEN
   message.  When using SCTP over DTLS
   [I-D.ietf-tsvwg-sctp-dtls-encaps], the method used to determine which
   side uses odd or even is based on the underlying DTLS connection
   role: the side acting as the DTLS client MUST use Streams with even
   Stream Identifiers, the side acting as the DTLS server MUST use
   Streams with odd Stream Identifiers.

The trouble is that DataChannel could be fully constructed with params.id before this odd/even rule could potentially be enforced. Thus we might need to fire "DataChannel.onerror" if we wish to enforce this IETF rule. Plus we may have to throw an exception on construction if we are able to determine the params are invalid upon construction due to the established DTLS client/server role.

@aboba
Contributor
aboba commented Sep 29, 2015

Here is a proposal:

In Section 11.2, add the following sentence:

"If parameters is invalid, throw an InvalidParameters exception."

In Section 11.3.1, the explanation of onerror should read as follows:

onerror of type EventHandler,
This event handler, of event handler type error, must be supported by all objects implementing the RTCDataChannel interface. One reason an error event can be fired is if the value of parameters passed in the constructor is subsequently determined to be invalid. This can happen if parameters.negotiated is set to false and then a call to RTCDtlsTransport.start() causes the DTLS role to be set to a value inconsistent with the value of parameters.id, as noted in [DATA-PROT] Section 4.

@robin-raymond robin-raymond pushed a commit that referenced this issue Oct 6, 2015
Robin Raymond - Clarified behavior of RTCDataChannel.send(), as noted in:
#240

- Fixed typos in Example 11, as noted in:
#241
#248

- Added text relating to RTCDataChannel exceptions and errors, as noted in:
#242

- Reconciliation of RTCRtpEncodingParameters dictionary with WebRTC 1.0, as noted in:
#249
e395344
@aboba aboba closed this Oct 6, 2015
@Jxck Jxck added a commit to Jxck/ortc that referenced this issue Oct 15, 2015
@Jxck Robin Raymond + Jxck - Clarified behavior of RTCDataChannel.send(), as noted in:
w3c#240

- Fixed typos in Example 11, as noted in:
w3c#241
w3c#248

- Added text relating to RTCDataChannel exceptions and errors, as noted in:
w3c#242

- Reconciliation of RTCRtpEncodingParameters dictionary with WebRTC 1.0, as noted in:
w3c#249
5be6f84
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment