W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > June 2017

Re: [webrtc-pc] Should even/odd id validation be enforced in createDataChannel when negotiated is true?

From: Soares Chen via GitHub <sysbot+gh@w3.org>
Date: Thu, 22 Jun 2017 03:58:08 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-310268938-1498103887-sysbot+gh@w3.org>
> My assumption was that this "MUST" only applies to generated IDs, not IDs selected by the application. If the application is selecting IDs itself, it seems like it would be the application's responsibility to avoid collisions.

It seems that your assumption only applies when `negotiated` is false. Section 6.5 of draft-ietf-rtcweb-data-channel-13 states that:

> When one side wants to open a channel using out-of-band negotiation, it picks a stream.  Unless otherwise defined or negotiated, the streams are picked based on the DTLS role (the client picks even stream identifiers, the server odd stream identifiers).  However, the application is responsible for avoiding collisions with existing streams.

My understanding is the the requirement in draft-ietf-rtcweb-data-protocol is enforced on the `DATA_CHANNEL_OPEN` message sent, regardless of how the message was generated. So unless the API call doesn't result in sending `DATA_CHANNEL_OPEN` message, i.e. when `negotiated` is false, the user agent must ensure the protocol is followed.

Section 6 of draft-ietf-rtcweb-data-protocol also states that:

> If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions above, for instance ..., the odd/even rule is violated ..., the receiver MUST close the corresponding Data Channel using the procedure described in [I-D.ietf-rtcweb-data-channel] and MUST NOT send a DATA_CHANNEL_ACK message in response to the received message.

So perhaps the behavior of the current spec is that if an odd/even-violated ID is provided, the data channel should never be established and error event is eventually fired. This could be pretty confusing to unfamiliar users.

But I don't really follow the motivation behind allowing custom ID to be set for all cases. It makes sense to provide ID when `negotiated` is false, but when `negotiated` is true, it doesn't really make sense for applications to be exposed to this kind of low level details.

GitHub Notification of comment by soareschen
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1413#issuecomment-310268938 using your GitHub account
Received on Thursday, 22 June 2017 03:58:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:21:40 UTC