voice_app_traffic_dived

1月末に急にユーザーが増えた、すごく会話がやりやすい通話アプリについて、通信の内容を観察する会をした。
協力していただいた10人ぐらいの皆様、ありがとうございました。

知りたいことは、良い感じの会話を実現するボイスチャットの部分についてのみで、
オーディエンス向けの送信は、遅延を大きくしてスケールさせる、インターネットラジオと同じことをやっているだけのようなので、観察を省略した。
オーディエンス向けにミキシングするサーバーが設置されていて、そこからラジオに流し込むのだろうと推測。


観察会でわかったことの概要は、以下の通り

- 送受信する相手のIPアドレスは1個と、サブでもう1個だけ。P2Pではなくスター型である。東京にあるデータセンターとだけ通信している。 
- UDPのみが使われる。ポート番号は一定していない。
- 部屋に誰もいなくても、自分の声は、約 5.5KBytes/secでサーバに送信される。
- サーバーでミキシングはやっていない。人数が増えたら、受信量が比例して増える。
- 同時に声を送信できるのは、ひとつの部屋に4人まで。5人以上で自分の名前を連呼して確認した。
- 自分の声を送信してるときは、自分のアイコンのまわりに輪っかが表示される。(輪っかは4個まで)
- 4人分の声を受信しているときは、声を送信しない。
- 4人が発話してるときでも、モデレーターの声が優先されることはない。　
- かといって速いもの勝ちでもない。多分、声の大きさか何かで優先順位が決まる。
- iPhoneのNetwork Conditionerを使って、Very Bad Networkを選択すると、通信品質の警告が表示される。　また、声がぶちぶち切れるようになり、同じ音を繰り返し再生する補間がはたらいた。
- Network Conditioner　で受信帯域を 100Kbps, パケットロス率を30% に設定した状態で会話をしていたら、接続が切れた。(Very Badは 1Mbps, 10%)
- 「交互に数を数えるテスト」で測定した結果、Network COnditionerなしだと1秒以下、Very Bad Networkだと往復に6~7秒かかった。ジッタバッファの長さは、動的に調整される。
- 往復に6~7秒かかる状態でも、削除される声はなかった。声は、届くまで再送され続けることがわかった。実際、再送していると見られる送信量の増大が観測された。
- パケットのフォーマットは、DTLS、WebRTC、QUIC　のいずれでもなさそうである。とりあえず冒頭の2バイトは長さフィールドとわかった。連番のフィールドもある。とても単純でマルチプレイゲームのパケットみたい。
- パケットの中身とサイズからすると、24KHz input, Opusの20ミリ秒delayでビットレートは32Kbps、モノラルに違いない!

1人しかいない部屋で何か声を送ると、5.5Kbpsぐらい送信される(緑)。受信はほとんど増えない

話している人数が増えると、通信量(受信量)が増える。　サーバーでミキシングし、ストリームを1個にしている、ということはないだろう

通信品質を人工的に悪くする(30%ロス)と、送信量も受信量も増えた。だいたい2倍以内ぐらい。　再送をして確実に届けようとしていることがわかる。

東京データセンターが選択される基準はなんだろう?

音声エンコーダーは何が使われているだろう?

言い始めと言い終わりが、Zoomほどは切れないのが、なぜなぜ

パケットが秒間だいたい50個なので、Opusのデフォルトの最小遅延22.5ms　の設定じゃないかな。。