5つのチーム、音声ネットワークをテストする5つの異なる理由。

十数社のピアリングパートナー経由でトラフィックを運んでいます。そのうちの1社は自社側に問題はないと主張し、お客様は逆の声を寄せています。通話の相手側の半分は、どちらにも見えません。

CDRだけの事後デバッグでは、codecの再ネゴシエーション、トランスコーディングによるアーティファクト、本物のpacket lossを切り分けられません。手作業でpcapを取得する頃には、たいてい状況は解消しています。

1. 01すべてのピアリングルートに対して、お客様のネットワーク上のエージェントノードから、スケジュール済みのキャンペーンを継続的に実行します。
2. 02各通話を、応答、PDD、双方向に音声が流れたかどうかで判定します。コード別の判定ポリシーにより、ビジートーンのテストでの486は成功、404は失敗として扱えます。
3. 03ルートが劣化したときは、失敗した通話そのもののSIP ladderとパケットキャプチャがすでに手元にあります。

新しいSBC、新しいキャリア、またはUCaaSへの切り替えです。設定は正しく見え、手動のテスト通話もいくつか成功しています。

手動のテストは、1台のハンドセットからの正常系しか確認しません。オファーに含まれる2番目のcodec、保留時のre-INVITE、新しいSBCが要求するようになったPRACK、2通話ではなく200同時通話になったときの挙動は確認できません。

1. 01Test Consoleから機能確認の通話を発信し、SIP ladder全体を確認できます。認証チャレンジやre-INVITEを含め、すべてのトランザクションがタイミング付きで表示されます。
2. 02拠点が実際に到達する同時接続数で負荷テストを実行し、1秒あたりの通話数を段階的に増やします。限界点は推測せず、実際に観察できます。
3. 03切り替え期間中もスケジュール済みのキャンペーンを実行し続けることで、リグレッションが起きればすぐに気づけます。

PBX、SBC、ゲートウェイ、ソフトフォンを開発しています。リリースのたびに、お客様がすでに利用しているcodec、トランスポート、call flowで動作し続ける必要があります。

手作業のリグレッションや、1人のエンジニアしか理解していないスクリプトでは、誰かが覚えていたフローしかカバーできません。TLS上の2番目のcodecや、不正な形式のヘッダーへの応答は、テストされないまま残りがちです。

1. 01通話テストを、codecとトランスポートのマトリクスを持つYAMLスイートとして記述し、製品と並べてバージョン管理します。
2. 02ビルドのたびにCIからスイートを実行し、ユニットテストと同じように、JUnitの結果でリリースの可否を判定します。
3. 03異常系にはSignalling Labを使います。手書きで意図的に不正な形式にしたSIPを送り、新しいビルドがどう応答するかを確認します。

発信通話の音声品質は、日中のほとんどの時間は問題ありません。苦情は午後に集中し、誰も再現できません。

trunkが稼働しているかどうかだけを見るモニタリングでは、断続的な劣化は見えません。通話が200 OKで完了しても、使い物にならないことがあります。バースト状に到着するjitter、片方向のみの音声、狭帯域のcodecへのフォールバックなどです。

1. 01重要なルートに対して、スケジュールに沿って24時間、合成通話を実行します。応答だけでなく、双方向の音声とネゴシエートされたcodecも毎回確認します。
2. 02苦情があるルートに集中しているときは、そのルートで音声品質テストを実行します。既知の音声を送信し、届いた音声と比較するため、パケット統計が正常に見えても劣化を検出できます。
3. 03jitterヒストグラムとフレーム単位のドリルダウンを使い、バースト性のロスと継続的な劣化を見分けます。

複数のクライアントの音声を管理しています。どのクライアントもネットワークが正常かどうかを知りたがり、求める形式はそれぞれ異なります。

レポートは別々のツールから手作業でまとめられるため時間がかかり、せいぜい月次になります。月次のレポートは、クライアントがすでに経験した問題の要約にすぎません。

1. 01クライアントごとに独立したテナントとして分離し、専用のアカウント、エージェントノード、チームを持たせます。
2. 02通話記録、SLAの結果、load testingの実行結果からレポートを一度作成すれば、スケジュールに従って自動で送信されます。
3. 03クライアントが自社のツールで利用したい場合はAPIですべてを操作でき、CIを使うクライアント向けにはJUnit形式で出力できます。

スケジュール済みのテストが夜間に失敗しました。当番のエンジニアの手元には通話記録、レスポンスコード、そして待っているお客様がいます。SIP ladder、SDP、メディアの結果を読む時間はありません。

レスポンスコードが示すのは原因ではなく症状です。同じ488でも、codecの不一致、相手側が拒否したSRTPオファー、SBCのポリシーのいずれもあり得て、証拠は複数の画面に分散しています。

1. 01通話記録で「AIに質問」を押すか、通話が失敗した理由をアシスタントに尋ねます。
2. 02アシスタントは、VoiceLab自身の記録から通話、そのSIP ladder、メディアの結果を読み取り、その通話の文脈でレスポンスを説明します。
3. 03すべての主張には、Observed、Likely、Unknownのいずれかが付きます。データが示す事実と、アシスタントの推測が区別されます。
4. 04関係する2つのアカウントの比較や、SLAインシデントを前週の同じ時間帯と比べた調査も依頼できます。

新しいtrunkにも、他と同じ確認が必要です。アカウントを登録し、指定のcodecで番号に発信し、音声を確認し、それを毎晩繰り返します。

これらはそれぞれ、複数のページにまたがる十数項目のフォームです。codec名や番号を打ち間違えると、実行が失敗し、わかりにくい結果が返ります。

1. 01次のように説明します。「6001から6002へPCMAで発信し、音声を確認」。
2. 02アシスタントは正確な番号でアカウントを特定し、テストの案を作成して、APIが適用するのと同じルールで検証します。
3. 03送信または変更される内容そのものである提案を確認し、「Confirm」を押します。それまで何も実行されません。
4. 04結果は他のテストと同様に通話記録に表示され、アシスタントが結果を説明します。