VoLTEで通話はつながるのに音声が聞こえない：SIP・SDP・RTPの確認手順

通話が接続済みと表示されても、相手に音声が届いているとは限りません。通話の設定、合意したメディア条件、実際のパケット転送を分けて確認します。今回は、この三つを結び付けて無音の原因を切り分ける考え方を紹介します。

1．まず、どの要求に対する200 OKなのかを確認する

SIPはセッションの確立・変更・終了を制御するシグナリングプロトコルです。REGISTERに対する200 OKと、INVITEに対する200 OKは意味が異なります。対象のCall-IDとCSeqを確認し、INVITEの成功応答とACKを同じ通話の流れで照合します。これは通話設定の証拠であり、音声が実際に届いた証拠ではありません。

2．SDPを「音声の受信先と条件」として読む

現在有効なOffer/Answerから、オーディオの受信アドレス、ポート、コーデック、方向を比較します。UPDATEやre-INVITEで条件が変わっている場合、最初のSDPだけでは判断できません。

• c=：接続アドレス。同じメディアにメディアレベルのc=があれば、セッションレベルの値より優先します。

• m=audio：オーディオのポート、トランスポート、メディア形式。

• a=rtpmap：RTP Payload Typeとコーデック・クロックレートの対応。

• a=fmtp：コーデック固有の形式パラメーター。名前が一致していても、詳細条件を合わせて確認します。

• a=sendrecvなど：合意した送受信方向。sendrecvだけで実際のパケット転送を確認したことにはなりません。

3．例：受信先の向きを取り違えない

この例では、AとBがSDPに記載した受信アドレス・ポートは次のとおりです。

• 端末AがSDPに記載した受信先：192.0.2.10:40000

• 相手BがSDPに記載した受信先：198.51.100.20:50000

この例では、Aから送る音声はBの50000番ポートへ、Bから送る音声はAの40000番ポートへ向かうかを確認します。Aの受信ポートを、Aが送信するときの宛先ポートとして読まないことがポイントです。
Aで取得したキャプチャにA→Bのパケットだけがあり、B→Aが見つからない場合、確認できた事実は「Aの観測点で逆方向のパケットが見つからなかった」までです。Bが送っていないのか、途中で失われたのか、キャプチャから漏れたのかは、別の観測点との比較が必要です。この結果だけでコーデックや無線網を原因と断定しません。

4．RTPが見えても、実際の音声まで確認する

実際のアドレス・ポート・Payload Typeを合意した条件と照合し、問題が起きた時間帯の両方向の流れを確認します。両方向にパケットがあっても、音声内容、デコード、ミュート設定、端末の音声出力に問題が残ることがあります。RTP・RTCPの統計は、利用者が実際に聞いた音声と合わせて解釈します。
実際のVoLTEでは、IMSプロファイル、SBCによるメディア中継、SRTP、Bearer・QoSの設定も考慮します。直接通信を想定した上の例を、そのまますべてのネットワークに当てはめないようにします。

技術面接では、確認の順序を説明する

「INVITEの成功応答とACKを対応付けて通話設定を確認します。次に、現在有効なSDPのOffer/Answerから受信アドレス・ポート・コーデック・方向を整理します。同じ通話・時間帯の実メディアを両方向で比較し、パケット転送と音声のデコード・再生を分けて調べます。」
原因を先に決めるのではなく、観測した事実と、次に必要な証拠を分けることが重要です。

日本語講座で学習を続ける

私のUdemy日本語講座「VoLTE/IMSと5G/LTE Throughput」では、SIP・SDP・RTP、Bearer、コーデック、通話手順をメッセージ例で結び付けて解説しています。講座ページでカリキュラムとプレビューをご確認いただけます。
Kihong Kim｜モバイル通信・問題解決シリーズ 01
技術資料：RFC 3261：SIP・RFC 8866：SDP・RFC 3264：Offer/Answer・RFC 3550：RTP/RTCP