WebRTC DataChannelのストリーム数上限 (2)

はじめに

こんにちは。鈴木です。

リアルタイムコミュニケーション（RTC）仕様の標準化と，キャリア網機能を提供するAPIの標準化を担当し，技術調査・仕様提案を行っています。

前回の記事では，WebRTC関連実験のひとつとして，Chromeにおいて WebRTC DataChannelで何本のストリームが確立できるのかを調査しました。

Chrome 152において，WebRTC DataChannelで利用できるストリームIDの上限が緩和されていることを確認できたため，最新状況をご紹介します。

実験条件

環境

環境	version
Windows 11	25H2 (26200.9168)
Chrome	152.0.7977.82

実験方法

前回の記事と同様に，1つのブラウザタブ内で2つのRTCPeerConnectionを作成し，ローカルでSDP交換を行うことでWebRTCセッションを確立します。確立したセッション上でDataChannelを順次作成し，エラーが発生するまでのストリームIDと作成本数を記録します。

DataChannelの作成にはRTCPeerConnection.createDataChannel()を使用します。テストではnegotiated: trueを指定し，明示的に引数でストリームIDを指定するモードで実験しました。negotiated: false(デフォルト)の場合，"IETF RFC 8832: WebRTC Data Channel Establishment Protocol"¹ の規定により，ストリームIDはDTLSクライアント側が偶数，DTLSサーバ側が奇数から自動採番されます。このため，一方のエンドポイントから作成できるDataChannelの本数は，後述の実験結果の半分程度となります。

実験結果

Chromeでnegotiated: trueモードを使い，ストリームIDを0から順に増やしながらDataChannelを作成した結果を以下に示します。

成功した最大ID	作成できた本数	maxChannels	発生したエラー
65534	65535	65535	TypeError

ストリームID=0～65534の65535本のDataChannelを同時に作成できました。ストリームID=65535を指定した時点でTypeErrorが発生しました。

またストリームIDを65000から増やした場合は，ストリームID=65000～65534の535本のDataChannelを作成した時点で頭打ちとなりました。

このことから，DataChannelの作成可否を左右するのは確立済みの本数ではなく，指定するストリームIDの値が0～65534の範囲に収まるかどうかであるとわかります。結果として，同時に確立できるDataChannelは最大65535本となります。

前回の記事ではストリームIDの上限が1023でしたが，65534に緩和されたことになります。

上限超過時に発生するエラーの種類も変更されています。前回の記事で上限超過時に発生したエラーはOperationErrorでしたが，今回はTypeErrorに変わっています。この違いについては後述します。

動作変更が反映されたバージョン

Chromiumの api/sctp_transport_interface.h で指定されていた kMaxSctpStreams = 1024 の制限は，Chromium 149（2026-06-02にStable版として公開）に対応する libwebrtc において kMaxSctpStreams = 65535 に変更されています。

このことから，実験で確認された挙動の変更は Chrome 149 から反映されているものと想定されます。

IETF仕様との整合性

SCTP仕様を定める "IETF RFC 9260: Stream Control Transmission Protocol"² の Section 5.1.1 では，エンドポイントが送信したいストリームの最大数と，受け入れ可能なストリームの最大数を，(SCTPアソシエーション確立時の)INIT/INIT ACKチャンクで宣言することとしています。

In the INIT and INIT ACK chunks, the sender of the chunk MUST indicate the number of outbound streams (OS) it wishes to have in the association, as well as the maximum inbound streams (MIS) it will accept from the other endpoint.

同じく Section 5.1.1 では，利用可能なストリームIDの範囲について，最小は0，最大は自らの送信ストリームの最大数 (local OS: Local Outbound Streams) と，相手が受信可能なストリームの最大数 (remote MIS: Remote Maximum Inbound Streams) の小さい方の値 - 1 としています。

After the association is initialized, the valid outbound stream identifier range for either endpoint MUST be 0 to min(local OS, remote MIS) - 1.

また Section 3.3.2 および 3.3.3 で示されるように，INIT/INIT ACKチャンク中で宣言されるOSやMISは，16bit固定長の符号なし整数とされ，最大値は65535となります。

Number of Outbound Streams (OS): 16 bits (unsigned integer)
Defines the number of outbound streams the sender of this INIT chunk wishes to create in this association.
(中略)
Number of Inbound Streams (MIS): 16 bits (unsigned integer)
Defines the maximum number of streams the sender of this INIT chunk allows the peer end to create in this association.

以上から，SCTP仕様において，あるエンドポイントAの宣言するOSと，対向エンドポイントBの宣言するMISが，ともに仕様上の最大値である65535の場合，エンドポイントAの利用できるストリームIDは 0～65534 (= 65535 - 1) となります。

同様にエンドポイントBが宣言するOS，エンドポイントAが宣言するMISが，ともに65535であれば，エンドポイントBの利用できるストリームIDも 0～65534 となります。

なおSCTPをWebRTC DataChannelで利用する際の規定として，"IETF RFC 8831: WebRTC Data Channels"³ の Section 6.2 では，SCTP確立時のストリーム数ネゴシエーションにおいて（OS,MISともに）最大数の65535を指定するべきとしています。

The number of streams negotiated during SCTP association setup SHOULD be 65535, which is the maximum number of streams that can be negotiated during the association setup.

上記と実験結果を照らし合わせると，Chromeでは実装特有の制限を廃止し，（少なくともChrome同士の直接接続では）SCTPプロトコルで定める最大の範囲でストリームIDを利用できるようになったことがわかります。

エラー種別の変化について

前回のOperationErrorは，libwebrtc内部のストリームID上限チェック（kMaxSctpSid = 1023の超過）でDataChannel作成が失敗し，ChromiumがそれをOperationErrorとして通知したものです。

一方，W3C WebRTC: Real-Time Communication in Browsers のcreateDataChannel()の規定では，IDが65535の場合にTypeErrorを投げることとしており，Chromiumはこのチェックをlibwebrtcを呼び出す前に行っています。

If [[DataChannelId]] is equal to 65535, which is greater than the maximum allowed ID of 65534 but still qualifies as an unsigned short, throw a TypeError.

従来はlibwebrtc側の1024本制限が先に作用していたため，このチェックに到達することはありませんでした。libwebrtcの制限がSCTP仕様上の最大値まで緩和されたことで，W3C仕様が定めるSCTP由来の上限（ストリームID 65534）に基づくTypeErrorが観測されるようになったものです。

まとめ

本記事では，ChromeでWebRTC DataChannelに利用できるストリームIDの上限が緩和され，結果として同時に確立できるDataChannel数が増えたことをご紹介しました。

本チームでは引き続きWebRTCを含むRTC関連技術の動向を紹介してまいります。

---