New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

Comments

Projects
None yet
2 participants
@robin-raymond
Copy link
Contributor

robin-raymond commented Sep 18, 2015

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

This comment has been minimized.

Copy link
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 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

@aboba aboba closed this Oct 6, 2015

Jxck added a commit to Jxck/ortc that referenced this issue Oct 15, 2015

- 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment