7. SIP Messages

7 SIP Messages

SIP はテキストベースのプロトコルであり, UTF-8 文字セット (RFC 2279 [7]) を使用します.

SIP メッセージは, クライアントからサーバへの要求, またはサーバからクライアントへの応答のいずれかです.

要求 (セクション 7.1) と応答 (セクション 7.2) の両方のメッセージは, 文字セットと構文の詳細が異なりますが, RFC 2822 [3] の基本形式を使用します (たとえば, SIP は RFC 2822 のヘッダフィールドとして有効ではないヘッダフィールドを許可します). 両方のタイプのメッセージは, 開始行, 1 つ以上のヘッダフィールド, ヘッダフィールドの終わりを示す空行, および任意のメッセージボディから構成されます.

     generic-message  =  start-line
                         *message-header
                         CRLF
                         [ message-body ]
     start-line       =  Request-Line / Status-Line

開始行, 各メッセージヘッダ行, および空行は, キャリッジリターンラインフィードシーケンス (CRLF) で終端されなければなりません (MUST). メッセージボディが存在しない場合でも, 空行が存在しなければならないことに注意してください.

上記の文字セットの違いを除き, SIP のメッセージおよびヘッダフィールドの構文の多くは HTTP/1.1 と同一です. ここで構文とセマンティクスを繰り返す代わりに, [HX.Y] を使用して現在の HTTP/1.1 仕様 (RFC 2616 [8]) のセクション X.Y を参照します.

ただし, SIP は HTTP の拡張ではありません.

7.1 Requests

SIP 要求は, 開始行として Request-Line を持つことで区別されます. Request-Line は, メソッド名, Request-URI, および単一のスペース (SP) 文字で区切られたプロトコルバージョンを含みます.

Request-Line は CRLF で終わります. 行末の CRLF シーケンス以外に CR や LF は許可されません. いずれの要素内にも線形空白 (LWS) は許可されません.

     Request-Line  =  Method SP Request-URI SP SIP-Version CRLF

  Method: 本仕様は 6 つのメソッドを定義します. 連絡先情報を登録するための REGISTER, セッションを設定するための INVITE, ACK, CANCEL, セッションを終了するための BYE, およびサーバの能力を問い合わせるための OPTIONS です. 標準化トラック RFC に記載された SIP 拡張は, 追加のメソッドを定義する可能性があります.

  Request-URI: Request-URI は, セクション 19.1 で説明された SIP または SIPS URI, または一般 URI (RFC 2396 [5]) です. これは, この要求が宛てられているユーザまたはサービスを示します. Request-URI には, エスケープされていないスペースや制御文字を含んではならず (MUST NOT), "\"<>\"" で囲んではなりません (MUST NOT).

       SIP 要素は, "sip", "sips" 以外のスキームを持つ Request-URI をサポートしてもよい (MAY) です (たとえば, RFC 2806 [9] の "tel" URI スキーム). SIP 要素は, 独自の手段を使用して非 SIP URI を変換し, その結果 SIP URI, SIPS URI, またはその他のスキームを生成してもよい (MAY) です.

  SIP-Version: 要求メッセージと応答メッセージの両方に, 使用されている SIP のバージョンが含まれ, バージョンの順序付け, 準拠要件, およびバージョン番号のアップグレードに関して [H3.1] (HTTP を SIP に, HTTP/1.1 を SIP/2.0 に置き換えたもの) に従います. 本仕様に準拠するため, SIP メッセージを送信するアプリケーションは, "SIP/2.0" の SIP-Version を含めなければなりません (MUST). SIP-Version 文字列は大文字小文字を区別しませんが, 実装は大文字で送信しなければなりません (MUST).

       HTTP/1.1 とは異なり, SIP はバージョン番号をリテラル文字列として扱います. 実際には, これに違いは生じないはずです.

7.2 Responses

SIP 応答は, 開始行として Status-Line を持つことで要求から区別されます. Status-Line は, プロトコルバージョンに続いて, 数値の Status-Code とそれに関連付けられたテキスト句から構成され, 各要素は単一の SP 文字で区切られます.

最後の CRLF シーケンス以外に CR や LF は許可されません.

  Status-Line  =  SIP-Version SP Status-Code SP Reason-Phrase CRLF

Status-Code は, 要求の理解と満足の試みの結果を示す 3 桁の整数の結果コードです. Reason-Phrase は, Status-Code の短いテキスト説明を与えることを意図しています. Status-Code は自動機械のために意図されており, Reason-Phrase は人間のユーザのために意図されています. クライアントは, Reason-Phrase を検査または表示する必要はありません.

本仕様は理由句に対する特定の表現を提案していますが, 実装は要求の Accept-Language ヘッダフィールドで示された言語など, 他のテキストを選択してもよい (MAY) です.

Status-Code の最初の数字は, 応答のクラスを定義します. 下 2 桁は分類上の役割を持ちません. このため, ステータスコードが 100 から 199 の間の応答は "1xx 応答" と呼ばれ, 200 から 299 の間の応答は "2xx 応答" と呼ばれ, 以下同様です. SIP/2.0 では, 最初の数字に 6 つの値が許可されています.

  1xx: Provisional (暫定的) — 要求を受信し, 処理を継続中.

  2xx: Success (成功) — 動作は正常に受信, 理解, および受け入れられた.

  3xx: Redirection (リダイレクション) — 要求を完了するためにさらに処理が必要.

  4xx: Client Error (クライアントエラー) — 要求に不正な構文があるか, このサーバでは実行できない.

  5xx: Server Error (サーバエラー) — サーバは一見有効な要求を実行できなかった.

  6xx: Global Failure (グローバル失敗) — いかなるサーバでも要求を実行できない.

セクション 21 は, これらのクラスを定義し, 個々のコードを説明します.

7.3 Header Fields

SIP ヘッダフィールドは, 構文およびセマンティクスの両面で HTTP ヘッダフィールドと類似しています. 特に, SIP ヘッダフィールドは, message-header の構文および複数行にわたるヘッダフィールド拡張の規則に関する [H4.2] の定義に従います. ただし, 後者は HTTP では暗黙の空白と折り返しで指定されています. 本仕様は RFC 2234 [10] に準拠し, 明示的な空白と折り返しのみを文法の不可欠な一部として使用します.

[H4.2] はまた, 値がカンマ区切りリストである同じフィールド名の複数のヘッダフィールドを 1 つのヘッダフィールドに結合できることも指定しています. これは SIP にも当てはまりますが, 文法が異なるため特定の規則は異なります. 具体的には, 文法が次の形式である任意の SIP ヘッダは,

  header  =  "header-name" HCOLON header-value *(COMMA header-value)

同じ名前のヘッダフィールドをカンマ区切りリストに結合することを許可します. Contact ヘッダフィールドは, ヘッダフィールド値が "*" でない限り, カンマ区切りリストを許可します.

7.3.1 Header Field Format

ヘッダフィールドは, RFC 2822 [3] のセクション 2.2 で与えられたものと同じ一般的なヘッダ形式に従います. 各ヘッダフィールドは, フィールド名, その後にコロン (":"), およびフィールド値から構成されます.

  field-name: field-value

セクション 25 で指定された message-header の正式な文法は, コロンの両側に任意の量の空白を許可します. ただし, 実装はフィールド名とコロンの間にスペースを避け, コロンとフィールド値の間に単一のスペース (SP) を使用すべきです (SHOULD).

  Subject:            lunch
  Subject      :      lunch
  Subject            :lunch
  Subject: lunch

したがって, 上記はすべて有効かつ等価ですが, 最後が推奨される形式です.

ヘッダフィールドは, 各追加行の先頭に少なくとも 1 つの SP または水平タブ (HT) を付けることで, 複数行にわたって拡張できます. 改行と次の行の先頭の空白は, 単一の SP 文字として扱われます. したがって, 以下は等価です.

  Subject: I know you're there, pick up the phone and talk to me!
  Subject: I know you're there,
           pick up the phone
           and talk to me!

異なるフィールド名を持つヘッダフィールドの相対順序は重要ではありません. ただし, プロキシ処理に必要なヘッダフィールド (Via, Route, Record-Route, Proxy-Require, Max-Forwards, Proxy-Authorization など) は, 迅速な解析を容易にするために, メッセージの上部に配置することが推奨されます (RECOMMENDED). 同じフィールド名を持つヘッダフィールド行の相対順序は重要です. そのヘッダフィールドの完全なフィールド値がカンマ区切りリストとして定義されている場合にのみ (つまり, セクション 7.3 の文法に従う場合), 同じフィールド名を持つ複数のヘッダフィールド行がメッセージ内に存在してもよい (MAY) です. 後続の各フィールド値を最初のものにカンマで区切って付加することによって, メッセージのセマンティクスを変更することなく, 複数のヘッダフィールド行を 1 つの "field-name: field-value" ペアに結合できる必要があります (MUST). この規則の例外は, WWW-Authenticate, Authorization, Proxy-Authenticate, および Proxy-Authorization ヘッダフィールドです. これらの名前を持つ複数のヘッダフィールド行はメッセージ内に存在してもよい (MAY) ですが, その文法はセクション 7.3 の一般的な形式に従わないため, 単一のヘッダフィールド行に結合してはなりません (MUST NOT).

実装は, 1 行あたり単一値の形式またはカンマ区切り値の形式の任意の組み合わせで, 同じ名前を持つ複数のヘッダフィールド行を処理できなければなりません (MUST).

以下のヘッダフィールド行のグループは, すべて有効かつ等価です.

  Route: `&lt;sip:[email protected]>`
  Subject: Lunch
  Route: `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`

  Route: `&lt;sip:[email protected]>`, `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`
  Subject: Lunch

  Subject: Lunch
  Route: `&lt;sip:[email protected]>`, `&lt;sip:[email protected]>`,
         `&lt;sip:[email protected]>`

以下の各ブロックは有効ですが, 互いに等価ではありません.

  Route: `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`

  Route: `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`

  Route: `&lt;sip:[email protected]>`,`&lt;sip:[email protected]>`,
         `&lt;sip:[email protected]>`

ヘッダフィールド値の形式は, ヘッダフィールド名ごとに定義されます. それは常に, TEXT-UTF8 オクテットの不透明なシーケンス, または空白, トークン, 区切り文字, および引用文字列の組み合わせのいずれかです. 多くの既存のヘッダフィールドは, 値の後に, セミコロンで区切られたパラメータ名, パラメータ値のペアの並びが続く一般的な形式に従います.

     field-name: field-value *(;parameter-name=parameter-value)

任意の数のパラメータペアをヘッダフィールド値に付加できる場合でも, 特定のパラメータ名が複数回現れてはならない (MUST NOT) ことに注意してください.

ヘッダフィールドを比較するとき, フィールド名は常に大文字小文字を区別しません. 特定のヘッダフィールドの定義で別途指定されない限り, フィールド値, パラメータ名, およびパラメータ値は大文字小文字を区別しません. トークンは常に大文字小文字を区別しません. 別途指定されない限り, 引用文字列として表現される値は大文字小文字を区別します. たとえば,

  Contact: `&lt;sip:[email protected]>`;expires=3600

は, 次と等価です.

  CONTACT: `&lt;sip:[email protected]>`;ExPiReS=3600

および

  Content-Disposition: session;handling=optional

は, 次と等価です.

  content-disposition: Session;HANDLING=OPTIONAL

以下の 2 つのヘッダフィールドは等価ではありません.

  Warning: 370 devnull "Choose a bigger pipe"
  Warning: 370 devnull "CHOOSE A BIGGER PIPE"

7.3.2 Header Field Classification

一部のヘッダフィールドは, 要求または応答のいずれかでのみ意味を持ちます. これらはそれぞれ, 要求ヘッダフィールドおよび応答ヘッダフィールドと呼ばれます. ヘッダフィールドがそのカテゴリに一致しないメッセージに現れた場合 (たとえば応答内の要求ヘッダフィールド), それは無視されなければなりません (MUST). セクション 20 は, 各ヘッダフィールドの分類を定義します.

7.3.3 Compact Form

SIP は, 一般的なヘッダフィールド名を省略形で表現する機構を提供します. これは, メッセージがそれを運ぶために利用可能なトランスポート上で大きすぎて運べなくなる場合 (たとえば UDP を使用する場合, 最大伝送単位 (MTU) を超える場合) に有用な場合があります. これらの省略形はセクション 20 で定義されています. 省略形は, メッセージのセマンティクスを変更することなく, いつでもヘッダフィールド名の長い形式と置換されてもよい (MAY) です. ヘッダフィールド名は, 同じメッセージ内で長い形式と短い形式の両方で現れてもよい (MAY) です. 実装は, 各ヘッダ名の長い形式と短い形式の両方を受け入れなければなりません (MUST).

7.4 Bodies

この仕様の拡張で定義された新しい要求を含め, 要求は, 別途注記がない限り, メッセージボディを含んでいてもよい (MAY) です. ボディの解釈は, 要求メソッドに依存します.

応答メッセージの場合, 要求メソッドと応答ステータスコードが, メッセージボディの種類と解釈を決定します. すべての応答はボディを含んでいてもよい (MAY) です.

7.4.1 Message Body Type

メッセージボディのインターネットメディアタイプは, Content-Type ヘッダフィールドによって与えられなければなりません (MUST). ボディが圧縮などのエンコーディングを受けている場合, それは Content-Encoding ヘッダフィールドによって示されなければなりません (MUST). そうでない場合, Content-Encoding は省略されなければなりません (MUST). 該当する場合, メッセージボディの文字セットは, Content-Type ヘッダフィールド値の一部として示されます.

RFC 2046 [11] で定義された "multipart" MIME タイプは, メッセージのボディ内で使用されてもよい (MAY) です. マルチパートメッセージボディを含む要求を送信する実装は, リモート実装がマルチパートを含まない Accept ヘッダフィールドを通じてこれを要求した場合, セッション記述を非マルチパートメッセージボディとして送信しなければなりません (MUST).

SIP メッセージは, バイナリボディまたはボディパートを含んでいてもよい (MAY) です. 送信者が明示的な charset パラメータを提供しない場合, "text" タイプのメディアサブタイプは, デフォルトの charset 値として "UTF-8" を持つように定義されています.

7.4.2 Message Body Length

ボディの長さ (バイト数) は, Content-Length ヘッダフィールドによって提供されます. セクション 20.14 は, このヘッダフィールドの必要な内容を詳細に説明します.

HTTP/1.1 の "chunked" 転送エンコーディングは, SIP には使用してはならない (MUST NOT) ことに注意してください. (注意: chunked エンコーディングは, メッセージのボディを一連のチャンクとして転送するために変更し, 各チャンクには独自のサイズ指示子があります. )

7.5 Framing SIP Messages

HTTP とは異なり, SIP 実装は UDP またはその他の信頼性のないデータグラムプロトコルを使用できます. そのような各データグラムは, 1 つの要求または応答を運びます. 信頼性のないトランスポートの使用上の制約については, セクション 18 を参照してください.

ストリーム指向トランスポート上で SIP メッセージを処理する実装は, 開始行の前に現れる CRLF を無視しなければなりません (MUST) [H4.1].

  各 SIP メッセージの末尾をストリーム内で見つけるために, Content-Length ヘッダフィールド値が使用されます. これは, SIP メッセージがストリーム指向トランスポート上で送信されるときは常に存在します.