コーデックの設定画面にOpusやG.711が並んでいても、その一覧だけでは通話中の方式は分かりません。実際に確認するときは、設定した候補、接続時に合意した候補、流れている音声を順に照合します。
本記事はログの読み方の入口です。製品ごとの採取操作ではなく、SIP／SDPとRTPで何を対応付けるかを説明します。図と数値は説明用で、特定サービスにそのまま投入する設定例ではありません。
1. まず、通話・区間・方向・時刻を決める
同じ電話でも、担当者端末とSBCの間、SBCと回線事業者の間では別の方式を使う場合があります。調べる通話の識別情報と時刻を決め、どの区間のどちら向きの音声かを記録してください。保留や転送の前後も区別します。
基礎的な役割は、SIP・SDP・RTPの違いで整理できます。SDPは使用条件を伝える情報、RTPは音声などのデータを運ぶ仕組みとして分けて読みます。
2. SDPの提案と応答を組にして読む
SDPのOffer／Answerは、片側の提案に相手が応答することで使用条件を調整する仕組みです。初期の提案だけで決めず、対応する応答も確認します。応答に複数の方式が残る場合があるため、「応答に記載された＝通話中に必ず使われた」とは扱いません。RFC 3264のOffer／Answerモデルを参照してください。
以下は説明用のSDPの抜粋です。接続先アドレスなどを省略しているため、完全なSDPではありません。
m=audio 41000 RTP/AVP 111 0 8
a=rtpmap:111 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000| 項目 | この例での読み方 |
|---|---|
m=audio |
音声用のメディア記述。111、0、8は方式を識別する番号 |
a=rtpmap:111 |
このメディア記述では111をOpusに対応付けている |
PCMU / PCMA |
それぞれG.711のμ-law／A-lawを示す名称 |
111が常にOpusを意味するわけではありません。動的な番号は、対象のメディア記述にある対応表で読みます。また、telephone-eventなどの番号はDTMFイベント用で、会話音声のコーデックと区別します。番号の割当はIANAのRTP Parametersでも確認できます。
Opusの48000はRTPクロックの表記であり、元音源の音声帯域を保証する値ではありません。パラメーターはRFC 7587と採用する実装の資料を照合します。
3. RTPのPayload Typeを、その区間の対応表に照合する
次に、実際のRTPストリームでPayload Type（PT）を確認します。この例の対応表を使う区間でPTが111ならOpus、0ならPCMU、8ならPCMAとして解釈します。別の区間や別の接続で使われた対応表を流用しないことが重要です。
確認結果には、送受信アドレス・ポート、ストリーム識別子、方向、時間範囲を残します。1パケットだけを見て通話全体を代表させず、音声が流れている区間を確認してください。合意した方式の範囲内での切り替えや、再交渉後の変化も見落とさないようにします。
WiresharkではRTP StreamsやRTP Stream Analysisなどが調査に使えます。詳しい操作はWireshark公式のRTPガイドを参照してください。パケットが見つからない場合は、まず採取位置やフィルターを確認します。解析ソフトで音声を再生できないことだけを根拠に、通話が無音だったとは判断できません。
4. WebRTCではストリームとcodecIdを対応付ける
ブラウザー側の統計を取得できる環境では、inbound-rtpやoutbound-rtpのcodecIdを、対応するcodec統計へ結び付けます。そこでmimeType、payloadType、clockRateなどを確認します。参照先はW3CのWebRTC統計仕様です。
受信と送信を分け、実際にパケットが増えているストリームかも確認します。実装によって取得できる項目は異なります。ブラウザー側の記録だけで、SBCから外部回線までの方式を確定できるわけではありません。
5. よくある読み違いを避ける
- 優先順位だけを見る：設定は意図を示します。接続時と通話中の記録で結果を確認します。
- 暗号化されているので何も分からないと考える：取得位置や方式によって見える情報は異なります。SRTPでは音声本体の復号と、ヘッダー等の観測を分けて考えます。
- 録音ファイルの形式を通話方式とみなす：録音の保存時に別形式へ変換される場合があります。
- 片側だけで全経路を判断する：中継装置の前後と、保留・転送後を必要に応じて照合します。
採取は管理者が認めた方法と範囲で行い、試験用の通話を使います。音声を復号・保存する必要があるかを先に決め、必要のない会話内容を調査記録に含めないようにします。
6. 結果は「区間と証拠」が分かる形で残す
例えば「10時05分の試験通話、端末→SBC区間、送信音声、PT 111、対応するSDPではOpus、転送前30秒を観測」と記録します。「Opusでした」だけより、再調査や別区間との比較がしやすくなります。
方式の確認後に途切れや遅延を調べる際は、RTP・RTCP・WebRTC統計の読み方へ進んでください。担当者側の状態を調査に生かす方法は、ResolveAXによるエージェント環境の品質分析で紹介しています。取得可能な情報は接続構成に応じて確認します。
通話経路とコーデックの調査範囲を相談する際は、対象通話、確認できる区間、採取可能な記録を共有すると、次の確認を具体化できます。
参照確認日：2026年10月5日。W3Cの参照仕様は更新されるため、利用実装の対応状況も確認してください。