モチベーション
Amazon Connectを用いて電話をかけた時に、音質が悪いという問題が発生しました。 「音質の悪さ」にも色々とありますが、発言がプツプツと切れるイメージ。この問題を調査する過程で色々と調べ物があったので、そのメモを残しておきます。
調査・可視化
音質が悪いと一言で言っても、色々な要因が考えられます。AWSのドキュメント上でも、いくつかの観点が公開されています。例えば、Amazon Connectを利用する部屋、ヘッドセット、PC、OSやブラウザの設定などです。
一方で、音質悪化の要因がクライアント側にあるとも限りません。ネットワーク等に原因がある場合もあるため、いくつかのテストや解析用ツールも公開されています。
Amazon Connect Endpoint Test Utilityはレイテンシーやプロトコル疎通を確認するためのツールで、CCP Log ParserはCCPのログを解析するためのツールです。
このCCP Log Parserでは、Jitter Buffer & RTTやskewを可視化できます。でも、それぞれは何を指すのでしょうか。
Jitter Buffer & RTTの正体
ここでいうJitter Buffer & RTTとは何なのでしょうか。 Amazon Connectのマニュアルでは、次のようにしか説明されていません。
The Jitter Buffer & RTT graph. Round trip time (RTT) values above 300 will affect the call experience. Report these to your IT support team.
Improve call quality on agent workstations in Amazon Connect contact centers
この詳細を掘り下げる上では、Amazon Connectの技術的詳細を掘り下げる必要があります。
WebRTCとRTP/RTCP
Amazon Connectでは、ウェブブラウザを通じて高品質かつセキュアな音声通信を実現するためにWebRTCを用いています。
WebRTCはさまざまなプロトコルの集合体で、WebRTCを構成するプロトコルの1つがRTPです。RTPは、データを転送する(S)RTPと、その制御プロトコルとして機能するRTCPの2つから成立します。
The Real-time Transport Protocol (RTP) [RFC3550] is REQUIRED to be implemented as the media transport protocol for WebRTC. RTP itself comprises two parts: the RTP data transfer protocol and the RTP Control Protocol (RTCP). RTCP is a fundamental and integral part of RTP and MUST be implemented and used in all WebRTC endpoints.
このうちのRTCPでは、受信レポートブロックと呼ばれる受信品質に関する情報を伝達でき、例えばパケットの欠落、転送遅延に関する情報が含まれます。 今回のJitter Buffer & RTTの値は、このRTCPの受信レポートブロックから取得されているものと考えられます。
RFC 3550のRTP: A Transport Protocol for Real-Time Applicationsに定義のある「RR: Receiver Report RTCP Packet」を見れば良さそう。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | PT=RR=201 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_1 (SSRC of first source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_2 (SSRC of second source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 : ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jitter
ここでいうJitterは、次の式で定義される値であり、一言で言えばパケットの転送時間がどれだけ揺らぐかを示します。過度な変動を抑えるために累積的に更新される値になっています。
$$ \begin{align} J(i) &= J(i-1) + \frac{\left| D(i-1, i) - J(i-1) \right|}{16} \newline D(i,j) &= (R{j} - R{i}) - (S{j} - S{i}) \newline &= (R{j} - S{j}) - (R{i} - S{i}) \end{align} $$
- $J(i)$は$i$番目のパケットが到着した時点でのジッタの推定値
- $J(i-1)$は前回のパケット到着時のジッタ推定値
- $D(i,j)$は$j$番目のパケットと$i$番目のパケットの相対的な到着時間差
- $R_{j}$は$j$番目のパケットの到着時刻
- $S_{j}$は$j$番目のパケットの送信時刻
この値が大きいということは、パケットの伝送時間が大きく揺らいでいるということを示し、ネットワークの一時的な輻輳が疑われます。
RTT
RTCPは、RTTの計測方法もプロトコルに含んでいます。
パケットの中に含まれるlast SR (LSR)とdelay since last SR (DLSR)を使ってRTTが計算できるようになっています。
- LSR: 送信者が最後に送信したSender Report (SR) パケットのNTPタイムスタンプの中間32ビット
- DSLR: 受信者が最後にSRを受信してから、現在のReceiver Report (RR) を送信するまでの経過時間
RTTは、現在時刻からLSRとDLSRを引くことで求まります。
skew
Skewに関してはGitHubのCCP Log Parserに次のような記載があり、Amazon Connectとエージェント（Amazon Connectを使う側の端末）間の時刻差のようです。
Skew is the difference between the client-side (agent's workstation) local timestamp and server-side (Amazon Connect service) timestamp in milliseconds.
これを裏付けるドキュメントは私の知る限り公開されていないのですが、 一番確からしい情報はamazon-connect-streamsのソースでしょう。
Agent側は、随時Amazon Connectとの送受信を行なっており、個々のレスポンスの一部を「Snapshot」として記録しています。そのレスポンス中のタイムスタンプをエージェント側のローカルタイムスタンプと比較して、時刻同期のズレを検出しているようです。
