「どれくらい難しいの？」ってストローマンが言った。2026年になっても、テレカンファレンスはまだこんなにひどい状態だ。何十億ドルも儲けられるのに、Zoomはせいぜい普通だし、Microsoftの何とかみたいにひどいこともある。テレカンファレンスが手探りの混乱じゃないところを見たことがないよ。

QUICも標準だよ。

ブログの著者が自分のことを説明し始めたのに気づいたかもしれないね。「6年前にTwitchでWebRTC SFUを書いたんだ。最初はOpenAIと同じくPion（Go）を使ってたけど、ベンチマークで遅すぎるってわかったからフォークしたんだ。結局、すべてのプロトコルを再実装しちゃったよ、もちろんね！1年前にはDiscordでRustでWebRTC SFUを書き直した。やっぱりそうなるよね！トレンドに気づいてるかも。面白い事実：WebRTCは2000年代初頭からの約45のRFCで構成されてるんだ。そして、技術的にはドラフトのままの事実上の標準もある（例：TWCC、REMB）。すべてを実装しなきゃいけないときは、全然面白くない事実だよ。私を認定WebRTCエキスパートだと思ってもらっていいよ。だから、二度とWebRTCを使いたくないんだ。彼らは「普通のやり方」を試して十分すぎるほどやったと思うけど、どう思う？」

Microsoft Graph APIを使ってメールとやり取りしようとしたことある？

どのプラットフォームをターゲットにしてて、そんなに苦労したの？フラストレーションがあったのは残念だね。教育やライブラリが増えて、少しずつ良くなってるといいな。Codexとかが今はすごく簡単にそれを処理できるのも驚きだよね。

この理由でLiveKitが好きだし、彼らのCEOもクールだよ。

そうだね。遅延を軽減するための追加の設定があるかもしれないけど、クライアントはSTT -> プロンプト -> TTSの遅延に対処したくないみたい。会話が「リアル」に感じられれば、たまに品質の問題があっても我慢するみたいだね。

リアルタイムが欲しいってこと？OpenAIのユースケースはリアルタイムを必要としないってことじゃない？OpenAIが応答するとき、ユーザーが聞く必要がある前にほとんどの音声が準備されてる。リアルタイムより早く音声を生成するから、リアルタイムプロトコルは合わないよね。

こんにちは、著者です。私のコメントの返信があまり面白くないことをお詫びします。すべての低遅延アプリケーションは、品質と遅延のトレードオフを決めなきゃいけないんです。混雑がキューイング（＝遅延）を引き起こし、それを避けるためには何かをスキップする必要がある（品質を下げる）。WebRTCの遅延と品質の調整は固定されてる。遅延を最小限に抑えるのは得意だけど、柔軟性が欠けてるんだ。それでも（使おうと）WebRTCを使うのは、あなたが示唆したように、ブラウザのサポートがそれを唯一の選択肢の一つにしてるから。もちろん、今まではね！WebTransportを使えば、一般的なプロトコルを通じてWebRTCのような動作を実現できる。ストリームをドロップ/リセットするまでの待機時間を自分で決められるんだ。ブログで言いたかったのは、ユーザーはしばしばストリーミングを求めるけど、ドロップは望んでいないってこと。もちろん、WebRTCなしで音声の入出力をストリーミングすることはできる。アプリケーションは、音声パケットが永遠に失われるタイミングを決めるべきだと思う…それは50msなのか500msなのか5000msなのか？私の主張は、音声AIは50msの選択肢を選ぶべきじゃないってこと。

ジェミニってWebSocketだと思う？重いカスタムアプリケーションで独自のメディア処理をしようとすると、同じような経験をするよ。AudioContextや再開の問題にぶつかるし…その辺のコーナーケースを扱うのが本当に面倒なんだ :(

…でもユーザーとしては、遅い/高価なプロンプトが正確になるために、200ms余分に待つ方がいい。これにはめっちゃ反対。会話モードがあると、ほぼ普通の会話ができるから、ゲームチェンジャーだと思う。もしレイテンシーを50-100ms短縮できたら嬉しいし、200ms増えたら使わなくなるかも。深いリサーチが必要な時はテキストを使って、プロンプトを慎重に作成するけど、外出中はスタートレックのコンピュータと会話したいんだよね。面白いことに、別のテック企業で関連するプロジェクトに関わっていて、この意見を言ったら、たくさんの反対があったのが明らかだった。会話の流暢さが一番重要な機能だと思うのに、まだ驚いてる。

リアルタイムよりも早く送信したくないよ。ユーザーがモデルを中断したら、3分の音声を送信しても10秒しか再生されないって、無駄な帯域を使っただけだよ。1秒ずつ送信すれば十分。20msや10分を一度に送る理由なんてない。どちらもバカげてる。

こんにちは、ショーンさん。1. ユーザーはもちろんレイテンシーを下げたいけど、LLMが「聞き間違える」回数も減らしたいんだよね。レイテンシーと品質のトレードオフについてA/Bテストをするのは素晴らしいけど、WebRTCだとその調整が難しいんだ。2. TTSの専門家じゃないけど、結果を少しずつ出すメリットって何？シリコンは時間の数字がどれだけ早く増えるかなんて気にしないでしょ？3. そうだね、クライアントがIPが変わったことに気づいてICE再交渉ができることもある。でも、たいていは気づかないし、サーバーが変化を検出するのに頼ることが多いけど、LBの設定だとそれができないんだ。大したことじゃないけど、すでにいろいろと面倒なことをしなきゃいけないのが残念。4. そのドラフトは7 RTTになるってこと？また、いくつかはパイプライン化できるから、実際の数はもう少し低いけど。実際の問題は、P2Pを使う場合に二重のTLSハンドシェイクを引き起こす必須のシグナリングサーバーだよ。5. もちろんWebRTCは新しい開発者には簡単だけど、それが大企業のOpenAIにとっては問題を引き起こすこともある。RTP over QUICをいじってみるべきだと思うし、手伝いたいよ。コードサイズが心配なら、ブラウザ（そしていつかOS）がQUICライブラリを提供してくれるし、MoQに近いものに切り替えれば、QUICがフラグメンテーションや再送、輻輳制御を処理してくれる。アプリケーションは意外と小さくなるよ。RoQ/MoQの主な欠点は、QUICが輻輳制御されているためGCCを実装できないこと。今のところブラウザから送信する際はcubic/BBRに縛られてる。

クライアントに複雑さを押し付けることになるよ。WebRTCのシンプルさ（createOffer -> setRemoteDescription）が、人々が簡単にオンボードできる理由なんだ。WebRTCは複雑で、ライブラリであっても（すでに使っているブラウザに組み込まれているライブラリであっても）。クライアント/サーバーの音声インタラクションでは、わざわざ使う理由が見当たらない。別の方法で音声サンプルを送信した方がいいし、再生のためにジッターバッファのロジックを借りるのもありだよ。今の仕事は音声とビデオ会議、1対1の通話に関わっていて、WebRTCは本当に複雑なんだ。すぐに製品を立ち上げられたけど、無茶なことをすると修正が大変だし、クライアントのためにフォークしてもね。TURNについては大きな愚痴が書けるよ。[1] TURNは、クライアントがアロケーションをリクエストするときに、一時的なポートではなく、ランデブーIDを割り当てるべきだと思う。その後、ピアはサービスポートでTURNサーバーに接続し、ランデブーIDへの接続をリクエストする。クライアントがピアアドレスを知って許可を追加する必要がなくなる。エンドツーエンドの中継接続に到達するための通信が少なくて済むんだ。高度なクラスターは、IDに情報をエンコードして、クライアントとピアがそれぞれ近くのTURNサーバーに連絡できるようにし、サーバーが接続を調整できるようにする。あまり高度でないクラスターは、IDとともにTURNサーバーのIPとサービスポートを共有する必要がある。

「著者は絶対に正しい。リアルタイムプロトコルは必要ない。すべてのデータを取得することがもっと重要だ。ユーザーは500msを超えない限り遅延に気づかないだろう」ってのは、私の経験とは違うな。音声で1日6000件の会話を運用していて、WebRTC + カスケーディング（STT/LLM/TTS）アーキテクチャを使ってる。もしかしたらコメントを誤解したかもしれないけど、その500msは今の最先端の音声実装のフロアみたいなもので、運が良ければ、無駄を省いて、推測デコーディングや推論などの高価なことをやってる。LLMのパスだけで450msかかる。商業用の音声AIでは、1msがすごく重要なんだ。そこに200msや300msを追加したら、会話が本当に劣化する。私たちはビジネスをサポートするために多くの音声関連のことをやっていて、主に技術に詳しくないユーザーを相手にしてる。昨年の試みでは、ターンからターンのレイテンシーが1200ms-1500msくらいで、ユーザーの混乱や中断、会話の放棄、全体的に非常に不快な体験を引き起こした。今はツールの使用に応じてターンからターンで約700msになっていて、まあまあの体験に近づいてきてる。実際の人とのインタラクションに匹敵するくらい。さらに100msを削減するためにかなりのコストをかけてる。推測的なLLMパスや推測的なツール実行（ユーザーが話している間にいくつかのLLM推論を行うけど、非冪等のツール呼び出しを実行する前に、そのLLMパスが使えるかどうか、ユーザーが文の最後に重要なことを言っていないかを確認する）を使って、100-200msを削減しようとしてる。500msが無関係だと言う人は、他のユースケースを説明してるんだと思う。私の音声AIの経験では、問題は時々のWebRTCパケットのドロップじゃない。実際の難しい問題は、強い背景ノイズ、エコー、そしてもちろんアクセントなんだ。WebRTCはその洗練されたAEC実装のおかげで、少なくともエコーの問題にはかなり役立ってる。OpenAIのスケールで実装するのが大変なのはわかるけど、ハイパースケールアプリケーション以外には、たくさんの良い解決策や商業プロバイダー（例えば、Dailyなど）があって、問題にならない。解決すべき本当の問題はまだ他にある。でも、500msを私のレイテンシーバジェットに追加したら、私のアプリケーションは終わりだよ。

クラウドサービスと話すときはNATトラバーサルはいらないよ。