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やファイアウォールが通信を妨げればメディアは届かない。接続先情報の交換と、実際の到達性を分けて点検する。
関連プロトコルとの比較
通話開始の要求と、音声を含むパケットでは、使用する通信相手や経路が異なる場合もある。呼制御が成功したことだけを根拠に、音声の経路も正常と判断しない。