【要約】通話路を覗いて呼を推測してはいけない ― Amazon Connect+KVSでシグナリングを引く [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が、KVSのストリーム出現をトリガーに呼を検知しようとした際、通信制御の欠如により以下の問題に直面した。通信路（ベアラ）の監視のみでは、制御信号（シグナリング）が取得できないためである。
- ・通話の冒頭音声が欠落する。
- ・発信者番号などの呼情報が取得できない。
- ・複数呼の同時発生時に、音声と呼の紐付けが困難になる。
// Approach
開発者は、制御信号と通話路を分離する古典的な設計思想をクラウド上で再現した。Amazon ConnectのコールフローからLambdaを起動し、制御情報を明示的に受け取る構成とした。
- ・コールフローからLambdaを起動し、呼の同定情報を取得する。
- ・Lambdaが取得した情報をSQSへ送信する。
- ・消費サービスはSQSをロングポーリングし、制御信号に基づきKVSから音声を吸い上げる。
// Result
この設計変更により、システムは実運用に耐えうる堅牢性を獲得した。制御信号に基づき、メディアストリームを正確にハンドリングできるようになった。
- ・呼とストリームの正確な紐付けが可能になった。
- ・StartFragmentNumberの利用により、通話の先頭から音声を取得できた。
- ・発信者番号の表示や、複数呼の独立した並行処理を実現した。
Senior Engineer Insight
> クラウド環境でも通信工学の基本原則が重要であることを示す好例だ。KVSのポーリングによる「当たり」ではなく、LambdaとSQSを用いたイベント駆動型のシグナリング設計は、スケーラビリティと信頼性の両面で極めて合理的である。また、OpenAIのVADを活用して無音検出の責務をAPI側に委ねる判断も、実装の複雑性を下げる優れた選択だ。実戦投入時には、コールフローにおける無音ループの設計ミスなど、メディア経路の物理的な挙動にも細心の注意を払うべきである。