telcoladder

TelcoLadder

決定論的な5G／4G／IMSシグナリングアナライザーおよびコールフロー相関ツールです。 tshark の上位レイヤーとして、相関分析と根本原因の特定を行います。すべてのインターフェースを通じて1人の加入者を追跡し、検証済みの原因テーブルに基づいてあらゆる障害を説明します。生成された情報は一切ありません。

コアネットワークのSREおよびR&D、RAN／コアネットワークの相互運用性テスト、ベンダーや通信事業者での三次トラブルシューティングを対象としています。シグナリングを読み解くことを生業としている方を想定しています。

pip install telcoladder
telcoladder check                             # verifies tshark and its dissectors
telcoladder summarize failed_attach.pcapng    # one page of facts, every failure cited

得られるもの

1回の解析から2種類の出力が得られます。チケットに貼り付けられるMermaid図：

sequenceDiagram
    autonumber
    participant gNB
    participant AMF
    Note over gNB,AMF: SUPI 001011234567895
    gNB->>AMF: #35;7 InitialUEMessage ▸ Registration request
    AMF->>gNB: #35;8 DownlinkNASTransport ▸ Authentication request
    rect rgb(255, 226, 226)
    gNB->>AMF: #35;9 UplinkNASTransport ▸ Authentication failure
    Note over AMF: Synch failure (#35;21) — 3GPP TS 24.501 §9.11.3.2
    end
    rect rgb(255, 226, 226)
    AMF->>gNB: #35;10 DownlinkNASTransport ▸ Registration reject
    Note over gNB: Protocol error, unspecified (#35;111) — 3GPP TS 24.501 §9.11.3.2
    end

これは説明用の図ではなく、tests/fixtures/ki-mismatch の実際の出力です。ローカルのOpen5GSテストベッドでキャプチャした、誤ったキーが設定されたUEのものです。予想されるMAC障害ではありません。Kが一致しないUEは、ネットワークが再同期に利用できないAUTSを計算するため、#21 の後に単独の #111 が発生します。原因テーブルにそのように記載されているのは、もっともらしく聞こえるからではなく、実際に検証したからです。

同じキャプチャをブラウザーでも確認できます。実際の tshark 表示フィルターを使ったパケット一覧、フレームごとのデコードツリーとバイト列、各失敗イベントの開始側と原因を示すラダー、そしてすべてのセルに元のフレームを記載したPDUセッションごとのマトリックスが表示されます。

対応する内容

世代	プロトコル	原因の説明
5Gコア	NGAP、NAS-5GS、HTTP/2 SBI、PFCP、GTP-U	206
4G／EPC	S1AP、NAS-EPS、GTPv2-C（S11、S5/S8、N26）、SGsAP（SGs）	236
IMS	SIP（通話、KPI）、Diameter、H.248/MEGACO	333

すべての原因コードは人手で検証したテーブルを使って照合され、該当する仕様、その平易な説明、そして現場で実際に発生させる根本原因が示されます。合計775件あり、名称はすべて tshark から一字一句そのまま取得し、テストで再確認しています。何も生成されません。テーブルにない原因は未登録として報告され、条項番号は人が書き起こした場合にのみ表示されます。すべてのネットワーク機能はIPアドレスではなく名前で表示され、その名前の根拠はホバーすると確認できます。

課題と、その解決方法

現状	TelcoLadder の導入後
1人の加入者を追跡するために、ウィンドウ間で UE ID を手作業でコピーする	1人の加入者の全履歴を1つのフローに集約します。SUPI、5G-S-TMSI、NGAP および S1AP の UE ID、TEID、Call-ID を網羅し、再利用されたキーは再利用されたものとして扱います
N2 と SBI が別々のキャプチャに記録され、対応付けられない	N2、SBI、N4 を1つのタイムラインに統合します。N4 は、UPF が割り当て、NGAP が中継した GTP-U トンネルエンドポイントを介して関連付けます
N26 ハンドオーバーが NGAP、N26、S11、S1AP に分散している	4つすべてにまたがる1つのセグメントとして表示します。MME が Create Session Response から HandoverRequest にコピーする S1-U SGW F-TEID を介して関連付けます
原因コードだけが表示され、仕様書を調べる必要がある	仕様名、平易な説明、フィールドレベルの根本原因とともに、775件の原因を表示します。条項は人が確認した箇所に限られます
コンテキストが解放されると、RAN とコアがお互いに責任を押し付ける	すべての UE コンテキスト解放に、RAN が要求したか、コアが指示したかを明示します。これは意見ではなく、通信上の事実です
手掛かりが見えないまま、プロシージャが停止する	NAS タイマーのデフォルト値（T3560、T3460 …）と一致する場合は、そのギャップを特定します。また、TAC、セル、DNN、コア要素ごとに失敗を集計します
VoLTE の Gm シグナリングが IPsec ESP の中に隠れている	NULL 暗号化 ESP を検出してデコードし、その中の SIP と SDP を加入者のラダーに関連付けます。実際に暗号化されている ESP は引き続き読み取れず、推測せずに件数を記録します
AS や、課金 ID を維持する SBC などの B2BUA が Call-ID を変更するため、1つの通話が無関係なダイアログとして表示される	課金 ID（ICID）が共通し、時間が重なるレッグを、エンドツーエンドで1つの通話として扱います。H.248、HSS、課金、ENUM は、その通話との関連を示す証拠がある場合にのみ紐付けます
顧客のキャプチャは決して建物の外に持ち出せない	お使いのマシン上で実行するコマンドです。127.0.0.1 以外ではネットワークリスナーを起動せず、テレメトリ、クラウド、モデルも使用しません

クイックスタート：5つの方法

Python がインストールされていない Windows の場合は？ pip は使わず、 4. Windows、インストール不要 に進んでください。必要なのは Wireshark だけです。

# 1. CLI — one page of deterministic facts, Markdown or JSON
telcoladder summarize capture.pcapng
telcoladder analyze capture.pcapng -o flow.mmd      # Mermaid, byte-for-byte reproducible

# 2. Browser — drop a capture, or paste a path for anything large
telcoladder serve                                   # http://127.0.0.1:3005

# 3. AI agent — the same facts as MCP tools over stdio
claude mcp add telcoladder -- telcoladder mcp

4. Windows、インストール不要。 タグ付けされたソースから CI でビルドした、ポータブル zip 形式のスタンドアロン実行ファイルです。インストールもレジストリキーの書き込みもありません。必要なのは、マシンに Wireshark 4.0 以降がインストールされていることだけです。

1. ダウンロードして解凍します。 Releases ページから TelcoLadder-Windows-x64.zip（約 10 MB）を入手します。
2. check-environment.cmd をダブルクリックします。 Wireshark のデフォルトのインストール先である Program Files 配下、または TELCOLADDER_TSHARK の指定先から tshark.exe を見つけ、ディセクタを確認します。
3. そのフォルダーから実行します。

   telcoladder.exe summarize capture.pcapng
   telcoladder.exe serve
   

   serve は http://127.0.0.1:3005 で待ち受けます。ブラウザーで開き、キャプチャ（最大 1 GB）をドロップするか、それより大きなファイルのパスを貼り付けてください。

5. キャプチャをほかの人に渡します。 telcoladder anonymize in.pcap out.pcap は、加入者 ID、アドレス、ホスト名、PLMN、セル識別子を、同じ長さのキー付き仮名に書き換えます。TBCD、ASCII、JSON、HPACK-Huffman も同様です。すべてのチェックサムを再計算した後、出力を再読み込みし、元の値が残っていれば保持を拒否します。出力は同じパイプラインを通り、同じプロシージャ、ロール、失敗が得られます。異なるのは名前だけです。キャプチャ間で同じキーを使うと、同じ仮名が使われます。キーは一度だけ表示され、ファイルには書き込まれません。圧縮された HTTP/2 ボディはその場で書き換えられないため、--blank-opaque-bodies を指定しない限り拒否されます。

pip を使う場合は Python 3.11 以降と tshark（Wireshark 4.0 以降）が必要です。macOS と Windows のインストーラーは、どちらも tshark を PATH に追加しません。TelcoLadder は標準のインストールディレクトリを検索して見つけるか、TELCOLADDER_TSHARK の指定を使用します。venv を使った Windows の手順はユーザーガイドに記載されています。

デコーダーにはない、5つの機能

インターフェースをまたいだ相関付け。 サブスクライバーは、適切なスコープを持つ識別キーの集合です。NGAP と S1AP の UE ID はそれぞれ1つのアソシエーション内でのみ一意であり、TEID と TMSI は再割り当てされるためエピソードとして扱われます。また、GTP-U トンネルエンドポイントは、NGAP、PFCP、GTP-U、そして今回新たに S1AP でも共有される1つの定義です。誤ったキーによる障害では、同じフローに2人分の情報が含まれていても、ラダー図は正常に描画されます。そのため、この問題を確実に引き起こすよう作成したキャプチャを使って、キーの構成をテストしています。

検証済みの原因775件。 tshark -G values の名前を、すべての CI プラットフォームで実行されるテストで再確認しています。2つの Diameter 番号空間は分けて扱い、NGAP と S1AP の原因グループは、メッセージが選択したグループ内で検索します。人が記述した順序シーケンスのルールも照合して、該当フレームとともに報告します。#21 の後に #111 が続く場合はシーケンスの問題ではなく、キーの不一致です。

障害の起点の特定。 UEContextReleaseRequest を送信するのは常に RAN であり、Release Command を送信するのは常にコアです。どちらが開始したかは、ラダー図、手順リスト、xDR に示されます。理由は引き続き原因テーブルから取得し、別の判定文字列は設けていません。

タイマーとの照合と影響範囲。 応答のないネットワークリクエストの後、タイマーのデフォルト値が経過してから Release または Reject が続いた場合、そのタイマーと「整合している」と報告します。キャプチャから分かるのはタイミングであり、AMF の状態ではないため、タイムアウトが確定したとは決して報告しません。複数のサブスクライバーがいる場合、障害は TAC、セル、DNN、コア側の要素ごとに集計します。不明な位置情報は除外せず、null の行として表示します。

設計上、エアギャップ環境に対応。 serve は 127.0.0.1 にバインドし、Host ヘッダーを検証します。MCP サーバーは stdio 専用です。ブラウザーバンドルはパッケージに同梱され、ネットワークから何も読み込みません。テレメトリーもモデルもありません。ツールが読み取れなかった情報、すなわち暗号化された NAS、ECIES で保護された SUCI、SBI 上の TLS、どのディセクターも解析できなかったフレームは、結論を出す前に数を集計して明示します。

テスト用キャプチャからの3つのシナリオ

以下はそれぞれ tests/fixtures/ にあるフィクスチャで、自分で実行できます。

1. 一見するとキーの不一致には見えないケース — ki-mismatch。同期失敗（#21）の後に、単独のプロトコルエラー（#111）が続きます。原因テーブルのシーケンスルールは真の原因を示し、SQN のリセットでは解決しないことも説明します。telcoladder summarize tests/fixtures/ki-mismatch/capture.pcap
2. 応答のなかった Authentication リクエストから6.000秒後にコンテキストが解放されるケース — 5gc-context-release。解放はコアが順序を決定したものとしてマークされ、時間差は T3560 のデフォルト値と整合していると報告されます。同じファイル内の2人目のサブスクライバーは、無線リンクの喪失後に gNB の要求によって解放され、そのようにマークされます。
3. ターゲット eNB が拒否する 5GS → EPS ハンドオーバー — n26-handover。1つのラダー図に5つの要素が表示されます。障害はワイヤ上に3回現れます（S1AP HandoverFailure、N26 Forward Relocation Response、NGAP HandoverPreparationFailure）。仕様名を示し、存在しない条項を作り出すことなく、S1AP テーブルに基づいて1回だけ説明します。

現在の機能

• tshark を使って、1 つの pcap / pcapng から 3 世代すべてを読み取ります。
• ネットワーク機能を特定し、証拠が曖昧な場合は推測せずに IP アドレスを表示します。リレー（5G SCP、Diameter DRA、SIP プロキシなど）は独自の役割を維持し、その背後にあるサービスの功績として扱われることはありません。
• 前述のスコープに従って、識別子やプロトコルをまたいで 1 人の加入者を関連付けます。SBI が TLS で保護され、SUCI が ECIES で保護された本番トレースでも、N2 側では UE ごとに独立したフローが形成されます。読み取れなかった内容は件数を集計して報告し、黙って破棄することはありません。
• 加入者のトラフィックをシナリオ（登録、アタッチ、PDU セッション、サービス要求（UE 起動またはネットワーク起動）、専用ベアラーの確立、変更と解放、登録解除、ハンドオーバー（キャンセルされたものも含みます。これは失敗ではありません）、アイドルモビリティ、IMS 登録と通話）に分割します。各シナリオには結果、原因、最初の失敗、継続時間を記録し、該当する場合は開始側、照合されたタイマー、またはハンドオーバーの準備時間と実行時間も記録します。軸となるのは加入者が行っていたことです。どのプロトコルが運んだかではありません。アタッチ内の S6a のやり取りはそのアタッチの一部であり、シナリオを終了させるコンテキスト解放はそのシナリオの一部です（開始側と原因もシナリオに引き継がれ、xDR には独立した行として解放も記載されます）。また、HSS の「unknown user」という応答は、そのアタッチの失敗です。どのシナリオにも属さない Diameter のやり取りは、それ自体が HSS 起動のやり取りとして扱われます。S6a/Gx は 4G に、Cx/Sh は IMS に分類され、その分類は Application-Id によって決まります。
• DRA 経由で Diameter（S6a/S6d、Cx/Dx、Sh、Rx、Gx、SWx、S6b）を読み取ります。役割は、誰がどのコマンドを開始したかに基づいて判定します。リレーの両側で観測された要求は 2 つのホップを持つ 1 つのトランザクションとして表示し、中継された失敗は 1 回だけ集計します。
• SIP 通話をプロシージャーとして扱い、呼び出し音が鳴るまでの時間、応答までの時間、通話時間、誰がどのような理由で切断したかを記録します。話中または着信拒否の場合、着信側は失敗ではなく ended-by-user として扱います。この分類はコードではなく、原因テーブルで定義されています。
• プロシージャー記録（--xdr）と、フィールドが固定された JSON サマリーをエクスポートします。どちらもバイト単位で再現可能なため、jq を使って「このバッチ全体の失敗率はどのくらいか」と調べられます。
• 英語または繁体字中国語（--lang zh_TW、またはブラウザー内の切り替え）で出力します。システムのロケールは意図的に使用しません。同じコマンドは 2 台のマシンで同じ文言を出力する必要があります。出力はチケットに貼り付けて使われるためです。
• 標準以外のポートは明示的に指定する必要があります。TCP 接続の確立後にキャプチャを開始した場合、tshark が検出できる HTTP/2 プリアンブルはありません。アダプターで一般的なケースを宣言し、残りは --decode-as で対応します。

大きなキャプチャでは、描画する前に対象を絞り込みます。

telcoladder analyze big.pcapng --subscriber 001011234567895
telcoladder analyze big.pcapng --since 120 --until 180
telcoladder analyze big.pcapng --filter 'ngap || s1ap'      # any tshark display filter

絞り込みで到達できなかったものはすべて明示的に一覧表示し、黙って破棄することはありません。ディセクションは約 0.19 秒/MB で実行され、処理時間はデータ量に比例します（あるマシンでは 145 MB、78 万フレームのファイルを 28 秒で処理）。tshark の出力はストリーミングされるため、メモリー使用量はファイルサイズではなく、保持されたメッセージ数に応じて変化します。

先行するプロジェクトと、それでもこれが存在する理由

以下のツールは先に登場しており、試す価値があります。TelcoLadder はこれらに取って代わろうとしているわけではありません。

プロジェクト	機能	それでも TelcoLadder が存在する理由
telekom/5g-trace-visualizer	pcap → 5GC の SVG シーケンス図（HTTP/2、NAS、PFCP）。Deutsche Telekom 製、Apache-2.0。	2023 年 8 月以降、メンテナンスされていません。PlantUML 出力には plantuml.jar が必要です。k8s デプロイメント向けの広範な設定項目を備え、Jupyter ノートブックから実行します。
irontec/sngrep	優れた、現在も活発にメンテナンスされている ncurses ベースの SIP フロービューアーです。	ターミナル専用かつ SIP 専用です。出力をドキュメントに貼り付けることはできず、5G には対応していません。
sipcapture/homer	サーバー、エージェント、データベース、ウェブ UI を備えたフル機能のキャプチャプラットフォームです。	デプロイして運用するインフラです。TelcoLadder は単一のファイルに対して実行するコマンドです。
dgudtsov/pcap2uml	SIP／Diameter／MAP／CAMEL にまたがる IMS のコールフローを PlantUML に変換します。	発想としては最も近いものです。5G（NGAP／NAS-5GS）には対応せず、出力は PlantUML です。
agranig/pcap2mermaid	Perl で SIP を Mermaid に変換します。	2019 年 1 月に 2 日間コミットがあった後、更新はありません。こうしたツールが求められていることは示されましたが、引き継ぐ人はいませんでした。

これらのどれも単独では実現していないのは、5G と 4G と IMS を相関付けた 1 つの図にまとめ、Mermaid を出力し、何が問題だったかを検証済みの説明とともに示すことです。

正直な制限事項

• SBI は SCP を使用する Open5GS の 1 つのデプロイメントに対してのみ検証済みであり、null スキームの SUCI とクリアテキストの h2c に限られます。本番環境の SBI は通常 TLS を使用します。そのようなフレームはポートごとに 不可視 としてカウントされます。tshark の設定はそのまま渡されるため（--tshark-pref tls.keylog_file:…）、Wireshark と同様にキー ログを指定できますが、ここには TLS フィクスチャがなく、その経路はテストでカバーされていません。いずれの場合も N2 には影響しません。
• 3gpp-Sbi-Target-apiRoot を送信しない完全に透過的な SCPはエンドポイントと区別できず、ラベルのない IP にフォールバックします。これは正しい失敗方向であり、実際に残っている課題です。
• Diameter は 7 つのインターフェースをカバーし、ロールと厳選された原因（S6a/S6d、Cx/Dx、Sh、Rx、Gx、SWx、S6b）を示します。残りは（Rf を含め）デコードされ、ロールの推定は行わずに Application-Id を表示します。Diameter のフィクスチャはすべて RFC 6733 に基づいて作成されており、キャプチャしたものではありません。TCP のみで、SCTP はなく、タイミングは仮のものです。
• 4 つの動作ルールには、裏付けとなるキャプチャがありません。 MME 間の S10 ハンドオーバー、Xn/X2 のパス切り替え、CS フォールバック、通話中の Cx 認証遅延は、メッセージ名に基づいて記述され、合成テストでのみカバーされています。実際のキャプチャでどのように見えるかは測定されていません。障害の前に示されるシーケンスは、1 つのセグメント内のメッセージ順序であり、因果関係が立証されているわけではありません。
• SIP だけではコアプロキシの名前は特定できません。 UE と P-CSCF は Gm 自体から特定します。具体的には、セキュリティ合意ヘッダー、または複数のピアとの IPsec アソシエーションを保持するアドレスを用い、それらがない場合は加入者 ID を含む Contact にフォールバックします。I-CSCF、S-CSCF、AS の名前が特定されるのは、同じキャプチャ内に Cx または Sh の通信がある場合のみです。ラベル付けされる SIP の参照点は Gm のみです。ここではそれらを検証したキャプチャがないため、Mw と ISC はラベル付けされません。H.248 には中立的な MGC / MGW ロールを割り当て、参照点は付与しません。プロトコルだけでは Iq、Mn、Mp のどれかを判断できないためです。
• 通話と番号は、証拠がある場合にのみ関連付けられます。 B2BUA のレッグを 1 つの通話としてまとめるのは、課金 ID（ICID）を共有し、時間が重複する場合のみです。ICID を置き換える B2BUA または SBC があると、行は分かれたままになります。番号は国際形式の場合にのみ HSS、課金、ENUM の記録と関連付けられます。現地形式の番号に推測した国番号が補完されることはありません。VoLTE、VoNR、VoWiFi が表示されるのは、P-Access-Network-Info で宣言されている場合のみです。そのヘッダーがない場合、アクセスは「未宣言」として報告されます。
• 原因テーブル 21 個のうち、仕様条項を引用しているのは 9 個のみです。 残りの 12 個は仕様を示すだけで、そこで止まります。誤った条項を示すより、条項を記載しないほうが適切です。
• 4G、IMS、ハンドオーバーのフィクスチャは、tshark をオラクルとしてバイト単位で作成されています。 プロトコルについては正確ですが、実際のデプロイメントについては何も示しません。各 scenario.md には、そのフィクスチャで立証できない事項が記載されています。UE の無線機能は解析されません。NR および LTE の RRC コンテナは解析に時間がかかるため抽出時にスキップされますが、フレームごとのデコードツリーでは引き続き参照できます。
• Security Mode Command 以降の NAS は暗号化されており、内容は不可視ですが、パケットは NGAP のキャリアとして表示されます。Gm 上の IPsec ESP も同様です。読み取られるのは NULL 暗号化された ESP のみで、暗号化された ESP は読み取り不可としてカウントされます。GTP-U は加入者を関連付けますが、スループットや損失の KPI は含まれません。RTP アダプターはありません。ISUP と CAMEL は識別されますが、読み取られません。
• SBI メッセージが引用するトンネルを介した関連付けは推定です。 方向と時間枠に基づいて関連付け、リリースをまたぐことはなく、1 つのフローに 2 つの SUPI を割り当てる場合も関連付けません。サマリーにはその件数が含まれます。残るケースとして、転送された古い引用がトンネルのリリース後に到着し、UPF がその同じ TEID を 10 s 以内に、フローに SUPI が表示されない UE に再利用した場合でも、関連付けられる可能性があります。単一のキャプチャポイントでは、その順序はプロトコルに違反します。
• 非常に大きなフローでは Mermaid が遅くなります。 --max-messages を使用してください。切り詰めが行われた場合は、必ず図の中に明記されます。
• anonymize が不在を証明できるのは、tshark が特定できるものに限られます。 一度もデコードされなかった ID はそのまま残ります。TLS ペイロードは不透明です。gzip 本文と DATA フレームをまたいで再構成される本文は推測せず、処理を拒否します。IPv6 のテキスト形式とバイナリ形式、および TAC のテキスト形式とバイナリ形式は、それぞれ独立して仮名化されます。レポートにはこれらすべてが記載されます。

検証方法

3 つのメッセージが欠けたフローも正しいフローとまったく同じように見えるため、テストスイートでは独自の解析結果だけを検証するのではなく、独立したオラクルとして tshark と照合します。メッセージ数、手順名とメッセージ名、すべての原因テーブル、誤ったマージを誘発する目的で作成されたフィクスチャの識別キーを照合します。新しいテストはミューテーションテストで確認します。意図的にコードを壊し、テストが失敗することを確認します。プッシュごとに、Linux では tshark 4.2 を使用して Python 3.11、3.12、3.13 で、macOS と Windows では tshark 4.6 を使用して、全テストスイートを実行します。ページ上部のバッジはリアルタイムで更新されます。バッジの対象外となる項目は、.github/workflows/ci.yml の冒頭に記載されています。

エアギャップ設計

このツールから外部へのネットワーク経路はありません。解析はファイルを読み込む子 tshark プロセスで実行されます。serve はループバックアドレスのみにバインドし、それ以外の Host ヘッダーを拒否します。MCP トランスポートは stdio です。ブラウザーバンドルはコードとともにパッケージ化され、外部リソースを参照しません。ホームへの通信は行わず、パイプラインのどの部分にもモデルは関与しません。アップロードされたキャプチャは、解放されるかアイドル状態の期限が切れるまで、システムの一時ディレクトリにモード 0600 で保存されます。大きなファイルの場合はパスを貼り付けるだけで、ファイルは一切コピーされません。

詳細情報

エンジン（ストリーミングアーキテクチャと測定済みスループット、識別モデルとキーの再利用、原因ライブラリとそのオラクル規律、N26 のステッチング、リリースの帰属、タイマー）については、docs/deep-dive.md に記載されています。実際のキャプチャを扱うための運用ガイドは docs/user-guide.md、プロトコル追加時の仕様は docs/plugin-contract.md、ツールを使用するエージェント向けの仕様は AGENTS.md をご覧ください。

コントリビューションと問題の報告

CONTRIBUTING.md は簡潔です。そこに記載された内容の中でも、とりわけ重要なルールが 2 つあります。実際の加入者や顧客のデータは、どこにも持ち込まないこと、そして仕様の各条項はすべて人間が検証し、自動生成しないことです。

脆弱性を見つけましたか？ 公開のイシューではなく、SECURITY.md をご覧ください。

ライセンス

PolyForm Noncommercial License 1.0.0。LICENSE をご覧ください。

個人利用、非営利利用、教育目的の研究であれば無料で利用できます。商用展開、商用配布、または営利目的の製品への組み込みには、別途商用ライセンスが必要です。タイトルを「Commercial licence」とした GitHub イシューを作成するか、リポジトリを通じてメンテナーに連絡してください。定型フォームではなく、条件についての返信が届きます。

Release 0.1.0 は Apache-2.0 のもとで公開されており、引き続きその条件で利用できます。サードパーティの素材には、それぞれのライセンスが適用されます。ブラウザーバンドルの依存関係（MIT/ISC、NOTICE に記載）と http2-multistream フィクスチャ（Apache-2.0、Deutsche Telekom）が該当します。