SDP
音声や映像の通信について、メディアの種類、接続先、ポート番号、使用形式などを表す記述形式。通信条件を伝えるものであり、音声そのものを配送する仕組みではない。
イマシルちゃんの解説
音声通話や動画配信を始めるには、何をどこへ送り、どんな形式で扱うかを相手へ伝える必要があるんだ。
SDPは、こうした通信条件を文字で書き表すための記述形式だよ。
たとえば音声を送るのか映像を送るのか、受信先はどこか、どのコーデックを使うかを記すの。コーデックは、音声や映像をデータに変えたり元に戻したりする方式だよ。
共通の書き方があるから、別々の機器でも通信の準備に必要な情報を読み取れるんだ。
ただし、SDP自身がその情報を相手へ届けたり、音声を運んだりするわけではなく、その仕事は別の通信の仕組みが担うよ。
この解説はわかりやすかったですか?
より深い解説
記述と転送を分ける
SDPの基本仕様はRFC 8866であり、RFC 4566を置き換えた。名称にProtocolを含むが、中心となるのはセッション情報のテキスト形式である。自身の転送手順は定めず、SIPやRTSPなどで運ぶ。
主な行の役割
各行は種類を表す文字と「=」、値から成る。全体に共通する情報と、個々のメディアに対応する情報を区別する。
| 行 | 表すもの |
|---|---|
| v= | 記述形式の版 |
| o= | 作成元、セッション識別子、版情報など |
| s= | セッション名 |
| c= | 接続先のアドレスなど |
| t= | セッションの有効時間 |
| m= | メディア、受信ポート、転送プロトコル、形式 |
| a= | 方向や符号化方式などの属性 |
記述を読む例
次は一つの音声受信先を示す独自の例である。実際の使用では、機器やアプリケーションに必要な条件を追加する。
v=0
o=- 12345 1 IN IP4 192.0.2.40
s=Training call
c=IN IP4 192.0.2.40
t=0 0
m=audio 42000 RTP/AVP 0
a=sendrecv
この例では、audioは音声を表し、受信ポートは42,000である。末尾の属性は送受信の両方を行う意図を示す。記述されたアドレスへ、ネットワーク上で到達できることまでは保証しない。
条件を合意する手順
RFC 3264のオファー・アンサーモデルでは、一方が対応できる条件を提示し、相手が利用可能な条件を答える。この枠組みでSDPを用いるが、記述形式だけで交渉手順のすべてが成立するわけではない。
たとえば双方が使えるコーデックの共通部分を選ぶ。形式が一致しても、NATやファイアウォールが通信を妨げればメディアは届かない。接続先情報の交換と、実際の到達性を分けて点検する。
関連プロトコルとの比較
通話開始の要求と、音声を含むパケットでは、使用する通信相手や経路が異なる場合もある。呼制御が成功したことだけを根拠に、音声の経路も正常と判断しない。
実際の試験ではここに出る!全2問
ネットワークスペシャリスト
- 午前Ⅱ
テクニカルエンジニア(ネットワーク)
- 午前