音声技術の基礎｜第5回
SIPは通話セッションの開始・変更・終了を制御し、RTPは音声などのメディアを伝送します。SDPは、IPアドレス・ポート・コーデックなどの条件を記述する形式で、SIPなどを通じて交換されます。接続手続きが成功しても、音声の到達や再生、品質まで保証されたことにはなりません。
「呼び出しはできるのに、相手の声が聞こえない」。IP電話では、接続の手続きと音声の伝送が別の仕組みで動くため、このような症状が起こります。本記事ではSIP・SDP・RTPの役割を分け、どこから調査すればよいかを説明します。
SIPとRTP、SDPの違いを比較
| 項目 | 主な役割 | 調査で見るもの |
|---|---|---|
| SIP | セッションの開始・変更・終了を制御 | 要求・応答、Call-ID、接続や転送の経過 |
| SDP | 交換するメディア条件を記述 | 宛先IP・ポート、コーデック、送受信方向 |
| RTP | 音声などのリアルタイムデータを伝送 | 実際の宛先、方向、Payload Type、受信状況 |
1. SIPは通話を開始・変更・終了する
SIP（Session Initiation Protocol）は、通信セッションを開始し、変更し、終了するためのプロトコルです。代表的な通話ではINVITEで開始を要求し、応答を経て接続を成立させ、BYEで終了します。
SIPの成功応答は、音声が相手のスピーカーまで届いたことを証明するものではありません。接続手続きの成功率と、双方向の音声品質は別々の試験項目です。保留や転送で通話条件が更新された場合も同様です。
2. SDPはメディアの条件を記述する
SDP（Session Description Protocol）は、音声などの通信条件を記述する形式です。IPアドレス、ポート、コーデックの候補、送受信の方向などを表します。SIPのメッセージ内で運ばれることがありますが、SDPそのものが音声を配送するわけではありません。
提案したコーデックと相手が受け入れたコーデックを確認し、実際の通信と一致するかを調べます。候補一覧の先頭にある方式を、そのまま採用済みと判断しないでください。
3. RTPは音声データを運ぶ
RTPは音声などのリアルタイムデータを扱います。SIPの経路とRTPの経路は一致するとは限りません。SIPサーバーが通話の手続きを仲介し、音声は別のメディア中継装置を経由する構成もあります。
そのため、SIPが通ったという理由でRTPの通信許可や配送経路も正しいとみなすことはできません。ファイアウォール、NAT、SBCの設定を調べるときは、両方の経路を図に描きます。
4. 単純化した接続例を読む
- 端末AがINVITEを送り、音声条件を提案する。
- 相手側の応答で通話とメディアの条件が確定する。
- ACKで接続手続きを進め、合意した条件で音声を送受信する。
- BYEとその応答で通話を終了する。
これは基本形を理解するための例です。実際には接続完了前に案内音が流れる早期メディア、認証、複数の中継装置、途中の条件変更などがあります。すべての通話が図の順序・経路になるわけではありません。
5. 症状に応じて最初の観測点を選ぶ
| 症状 | 最初に確認する情報 |
|---|---|
| 発信できない | SIP応答、認証、宛先、タイムアウト |
| つながるが無音 | SDP、双方向RTP、端末の入出力 |
| 片方向だけ聞こえない | 聞こえない方向の送信・到着・復号 |
| 転送後に無音 | 変更後のSDPと音声経路 |
この表は調査の出発点です。例えば無音でも、マイクのミュートや出力先の誤設定が原因の場合があります。ネットワークに限定せず、端末で実際に音声が入力・再生されているかも確認します。
聞こえない方向から調べる手順は、片通話・無音をNATとSDPから切り分けるで説明しています。
SIPは正常なのに音声が聞こえないのはなぜ？
SIPの成功は呼制御の結果であり、RTPが相手に届き、復号・再生できることの証明ではありません。聞こえない方向を決め、次の順に同じ通話の情報を照合します。
- SDP：接続時と保留・転送後の宛先、ポート、方向を比較する。コーデックはSDPとRTPから実使用方式を確認する手順で照合する。
- RTP：送信側から出ているか、受信側へ届くかを確認する。SBCが中継する構成では両側の区間を分ける。
- NAT・FW・SBC：到達していない区間で、アドレス変換、通信許可、メディア中継を確認する。
- 届いている音声：パケット損失の連続性とジッター・再生待ち時間を確認し、ミュート・入出力機器・復号も調べる。
- 復旧後の評価：双方向の会話を確かめ、必要に応じてMOS・PESQ・POLQAによる音声品質評価へ進む。
途切れが混雑時だけに起こる場合は、DSCPとQoSの設定・キュー制御の確認も同じ時間帯の記録で照合します。RTP自体にも配送や品質の保証はありません。
6. 調査記録には通話と音声の両方を残す
SIPのCall-ID、発着信時刻、経由装置、音声ストリームの方向を対応づけます。B2BUAとして動く装置などでは区間ごとにCall-IDが変わることがあるため、装置側の相関情報も利用します。時刻だけに頼らず、同じ通話のどの区間かを特定できる記録にします。
接続試験の完了条件は、呼が成立することに加え、双方が発話を聞き取れ、必要な保留・転送後も会話できることまで含めて決めてください。
更改前後の確認範囲を決める際は、SBC更改時の接続・負荷試験の確認項目も参考になります。
よくある質問
SDPは音声を送るプロトコルですか？
SDPは音声などのメディア条件を記述する形式です。SIPなどで運ばれ、提案・応答の枠組みで条件を交換します。音声データの伝送を担うRTPとは役割が異なります。
SIPとRTPは同じ経路を通りますか？
必ずしも同じ経路を通りません。呼制御の中継先とメディアの中継先が異なる構成があるため、接続の記録と音声ストリームの記録を別々に取り、同じ通話へ対応付けます。
エージェント側のブラウザー・端末・ネットワーク情報から原因候補を絞る場合は、ResolveAXによる通話品質とエージェント環境の分析をご確認ください。SIP・SBC・NAT側の記録も必要に応じて照合し、製品で観測できる範囲と未確認の区間を分けます。
参考規格・資料
片通話や転送後の無音を検証するときは、SIP・SDP・RTPの記録と構成図をそろえると、確認すべき区間を整理できます。音声そのものの比較にはSoftware AGDによる音声品質評価を参照し、CCアーキテクトへSIP・VoIP・SBCを含む接続と音声品質の検証を相談するからご相談ください。