Network Working Group J. Rosenberg Request for Comments: 3261 dynamicsoft Obsoletes: 2543 H. Schulzrinne Category: Standards Track Columbia U. G. Camarillo Ericsson A. Johnston WorldCom J. Peterson Neustar R. Sparks dynamicsoft M. Handley ICIR E. Schooler AT&T June 2002 SIP(セッション開始プロトコル) SIP: Session Initiation Protocol 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準 トラックプロトコルを規定するものであり、改善のための議論や提案を 依頼するものである。標準化の段階や、プロトコルの位置付けについては、 最新版の"Internet Official Protocol Standards" (STD 1)を参照されたい。 この文書の配布は無制限である。 著作権表記 Copyright (C) The Internet Society (2002). All Rights Reserved. 概要 この文書では、単数あるいは複数の相手とのセッションを生成、変更、切断 するためのアプリケーション層制御(シグナリング)プロトコルである、セッ ション開始プロトコル(SIP)について述べる。ここでいうセッションとは、イ ンターネット通話、マルチメディア配信、マルチメディアカンファレンスを 含んだものである。 セッションを生成するために使われるSIP招待(invitation)は、参加者が互換 メディアタイプをマッチさせるための、セッション記述を伝える。ユーザー の現在地へリクエストをルートする役に立ち、サービスに対してユーザーを 認証および認可し、プロバイダの呼ルートポリシーを実装し、かつ、ユー ザーに機能を提供する、プロキシサーバーと呼ばれるエレメントをSIPは使用 する。プロキシサーバーが使用するユーザーの現在地をユーザーがアップロー ドすることを認める登録機能も、SIPは提供する。SIPは異なる様々なトラン スポートプロトコル上で動作する。 Rosenberg, et. al. Standards Track [Page 1] RFC 3261 SIP: Session Initiation Protocol June 2002 Table of Contents 1 はじめに ............................................ 8 2 SIP機能概要 ......................................... 9 3 述語規則 ............................................ 10 4 操作概要 ............................................ 10 5 プロトコルの構造 .................................... 18 6 定義 ................................................ 20 7 SIPメッセージ ....................................... 26 7.1 リクエスト .......................................... 27 7.2 応答 ................................................ 28 7.3 ヘッダーフィールド .................................. 29 7.3.1 ヘッダーフィールドの書式 ............................ 30 7.3.2 ヘッダーフィールドの分類 ............................ 32 7.3.3 短縮形 .............................................. 32 7.4 ボディ .............................................. 33 7.4.1 メッセージボディのタイプ ............................ 33 7.4.2 メッセージボディの長さ .............................. 33 7.5 SIPメッセージのフレーム化 ........................... 34 8 ユーザーエージェントの一般的な動作 .................. 34 8.1 UACの動作 ........................................... 35 8.1.1 リクエストの生成 .................................... 35 8.1.1.1 Request-URI ......................................... 35 8.1.1.2 To .................................................. 36 8.1.1.3 From ................................................ 37 8.1.1.4 Call-ID ............................................. 37 8.1.1.5 CSeq ................................................ 38 8.1.1.6 Max-Forwards ........................................ 38 8.1.1.7 Via ................................................. 39 8.1.1.8 Contact ............................................. 40 8.1.1.9 Supported と Require ................................ 40 8.1.1.10 付加的なメッセージコンポーネント .................... 41 8.1.2 リクエストの送信 .................................... 41 8.1.3 応答の処理 .......................................... 42 8.1.3.1 トランザクションレイヤーのエラー .................... 42 8.1.3.2 認識できない応答 .................................... 42 8.1.3.3 複数のVia ........................................... 43 8.1.3.4 3xx応答の処理 ....................................... 43 8.1.3.5 4xx応答の処理 ....................................... 45 8.2 UASの動作 ........................................... 46 8.2.1 メソッド検査 ........................................ 46 8.2.2 ヘッダー検査 ........................................ 46 8.2.2.1 ToとRequest-URI ..................................... 46 8.2.2.2 マージされたリクエスト .............................. 47 8.2.2.3 Require ............................................. 47 8.2.3 コンテンツの処理 .................................... 48 8.2.4 拡張の適用 .......................................... 49 8.2.5 リクエストの処理 .................................... 49 Rosenberg, et. al. Standards Track [Page 2] RFC 3261 SIP: Session Initiation Protocol June 2002 8.2.6 応答の生成 .......................................... 49 8.2.6.1 暫定応答の送信 ...................................... 49 8.2.6.2 ヘッダーとタグ ...................................... 50 8.2.7 ステートレスUASの動作 ............................... 50 8.3 リダイレクトサーバー ................................ 51 9 リクエストのキャンセル .............................. 53 9.1 クライアントの動作 .................................. 53 9.2 サーバーの動作 ...................................... 55 10 登録 ................................................ 56 10.1 概要 ................................................ 56 10.2 REGISTERリクエストの構築 ............................ 57 10.2.1 バインディングの追加 ................................ 59 10.2.1.1 Contactアドレスの有効期限間隔の設定 ................. 60 10.2.1.2 Contactアドレス間のプリファレンス ................... 61 10.2.2 バインディングの削除 ................................ 61 10.2.3 バインディングの取得 ................................ 61 10.2.4 バインディングのリフレッシュ ........................ 61 10.2.5 内部クロックの設定 .................................. 62 10.2.6 登録サーバーの発見 .................................. 62 10.2.7 リクエストの送信 .................................... 62 10.2.8 エラー応答 .......................................... 63 10.3 REGISTERリクエスト処理 .............................. 63 11 能力の問い合わせ .................................... 66 11.1 OPTIONSリクエストの構築 ............................. 67 11.2 OPTIONSリクエストの処理 ............................. 68 12 ダイアログ .......................................... 69 12.1 ダイアログの生成 .................................... 70 12.1.1 UASの動作 ........................................... 70 12.1.2 UACの動作 ........................................... 71 12.2 ダイアログ内のリクエスト ............................ 72 12.2.1 UACの動作 ........................................... 73 12.2.1.1 リクエストの生成 .................................... 73 12.2.1.2 応答の処理 .......................................... 75 12.2.2 UASの動作 ........................................... 76 12.3 ダイアログの終了 .................................... 77 13 セッションの開始 .................................... 77 13.1 概要 ................................................ 77 13.2 UACの処理 ........................................... 78 13.2.1 最初のINVITEの生成 .................................. 78 13.2.2 INVITEに対する応答の処理 ............................ 81 13.2.2.1 1xx応答 ............................................. 81 13.2.2.2 3xx応答 ............................................. 81 13.2.2.3 4xx、5xx、および6xx応答 ............................. 81 13.2.2.4 2xx応答 ............................................. 82 13.3 UASの処理 ........................................... 83 13.3.1 INVITEの処理 ........................................ 83 13.3.1.1 進捗状態 ............................................ 84 13.3.1.2 INVITEがリダイレクトされる .......................... 84 Rosenberg, et. al. Standards Track [Page 3] RFC 3261 SIP: Session Initiation Protocol June 2002 13.3.1.3 INVITEが拒否される .................................. 85 13.3.1.4 INVITEが受け入れられる .............................. 85 14 既存セッションの変更 ................................ 86 14.1 UACの動作 ........................................... 86 14.2 UASの動作 ........................................... 88 15 セッションの終了 .................................... 89 15.1 BYEリクエストによるセッションの終了 ................. 90 15.1.1 UACの動作 ........................................... 90 15.1.2 UASの動作 ........................................... 91 16 プロキシの動作 ...................................... 91 16.1 概要 ................................................ 91 16.2 ステートフルプロキシ ................................ 92 16.3 リクエストの有効性検証 .............................. 94 16.4 ルート情報の前処理 .................................. 96 16.5 リクエストのターゲットの決定 ........................ 97 16.6 リクエストの転送(forward) ........................... 99 16.7 応答の処理 .......................................... 107 16.8 タイマーCの処理 ..................................... 114 16.9 トランスポートエラーの操作 .......................... 115 16.10 CANCELの処理 ........................................ 115 16.11 ステートレスプロキシ ................................ 116 16.12 プロキシのルート処理のまとめ ........................ 118 16.12.1 例 .................................................. 118 16.12.1.1 基本的なSIP台形 ..................................... 118 16.12.1.2 ストリクトルーティングを行うプロキシのトラバース .... 120 16.12.1.3 Record-Routeヘッダーフィールド値の書き換え .......... 121 17 トランザクション .................................... 122 17.1 クライアントトランザクション ........................ 124 17.1.1 INVITEクライアントトランザクション .................. 125 17.1.1.1 INVITEトランザクションの概要 ........................ 125 17.1.1.2 形式的な説明 ........................................ 125 17.1.1.3 ACKリクエストの構築 ................................. 129 17.1.2 非INVITEクライアントトランザクション ................ 130 17.1.2.1 非INVITEトランザクションの概要 ...................... 130 17.1.2.2 形式的な説明 ........................................ 131 17.1.3 応答をクライアントトランザクションにマッチングする .. 132 17.1.4 トランスポートエラーの操作 .......................... 133 17.2 サーバートランザクション ............................ 134 17.2.1 INVITEサーバートランザクション ...................... 134 17.2.2 非INVITEサーバートランザクション .................... 137 17.2.3 リクエストをサーバートランザクションにマッチングする 138 17.2.4 トランスポートエラーの操作 .......................... 141 18 トランスポート ...................................... 141 18.1 クライアント ........................................ 142 18.1.1 リクエストの送信 .................................... 142 18.1.2 応答の受信 .......................................... 144 18.2 サーバー ............................................ 145 18.2.1 リクエストの受信 .................................... 145 Rosenberg, et. al. Standards Track [Page 4] RFC 3261 SIP: Session Initiation Protocol June 2002 18.2.2 応答の送信 .......................................... 146 18.3 フレーム化 .......................................... 147 18.4 エラー操作 .......................................... 147 19 コモンメッセージコンポーネント ...................... 147 19.1 SIP URIとSIPS URI ................................... 148 19.1.1 SIP URIコンポーネントとSIPS URIコンポーネント ....... 148 19.1.2 文字エスケープ要求事項 .............................. 152 19.1.3 SIP URIとSIPS URIの例 ............................... 153 19.1.4 URIの比較 ........................................... 153 19.1.5 URIからリクエストを作る ............................. 156 19.1.6 SIP URIとtel URLを関係付ける ........................ 157 19.2 オプションタグ ...................................... 158 19.3 タグ ................................................ 159 20 ヘッダーフィールド .................................. 159 20.1 Accept .............................................. 161 20.2 Accept-Encoding ..................................... 163 20.3 Accept-Language ..................................... 164 20.4 Alert-Info .......................................... 164 20.5 Allow ............................................... 165 20.6 Authentication-Info ................................. 165 20.7 Authorization ....................................... 165 20.8 Call-ID ............................................. 166 20.9 Call-Info ........................................... 166 20.10 Contact ............................................. 167 20.11 Content-Disposition ................................. 168 20.12 Content-Encoding .................................... 169 20.13 Content-Language .................................... 169 20.14 Content-Length ...................................... 169 20.15 Content-Type ........................................ 170 20.16 CSeq ................................................ 170 20.17 Date ................................................ 170 20.18 Error-Info .......................................... 171 20.19 Expires ............................................. 171 20.20 From ................................................ 172 20.21 In-Reply-To ......................................... 172 20.22 Max-Forwards ........................................ 173 20.23 Min-Expires ......................................... 173 20.24 MIME-Version ........................................ 173 20.25 Organization ........................................ 174 20.26 Priority ............................................ 174 20.27 Proxy-Authenticate .................................. 174 20.28 Proxy-Authorization ................................. 175 20.29 Proxy-Require ....................................... 175 20.30 Record-Route ........................................ 175 20.31 Reply-To ............................................ 176 20.32 Require ............................................. 176 20.33 Retry-After ......................................... 176 20.34 Route ............................................... 177 Rosenberg, et. al. Standards Track [Page 5] RFC 3261 SIP: Session Initiation Protocol June 2002 20.35 Server .............................................. 177 20.36 Subject ............................................. 177 20.37 Supported ........................................... 178 20.38 Timestamp ........................................... 178 20.39 To .................................................. 178 20.40 Unsupported ......................................... 179 20.41 User-Agent .......................................... 179 20.42 Via ................................................. 179 20.43 Warning ............................................. 180 20.44 WWW-Authenticate .................................... 182 21 応答コード .......................................... 182 21.1 暫定応答 1xx ........................................ 182 21.1.1 100 Trying (試行中) ................................. 183 21.1.2 180 Ringing (呼び出し中) ............................ 183 21.1.3 181 Call Is Being Forwarded (呼が転送されている) .... 183 21.1.4 182 Queued (キューに入れられた) ..................... 183 21.1.5 183 Session Progress (セッションの進捗状況) ......... 183 21.2 成功応答 2xx ........................................ 183 21.2.1 200 OK .............................................. 183 21.3 リダイレクト応答 3xx ................................ 184 21.3.1 300 Multiple Choices (複数の選択肢がある) ........... 184 21.3.2 301 Moved Permanently (恒久的に移動した) ............ 184 21.3.3 302 Moved Temporarily (一時的に移動した) ............ 184 21.3.4 305 Use Proxy (プロキシを使用せよ) .................. 185 21.3.5 380 Alternative Service (代替サービス) .............. 185 21.4 リクエスト失敗応答 4xx .............................. 185 21.4.1 400 Bad Request (不正なリクエスト) .................. 185 21.4.2 401 Unauthorized (認可されていない) ................. 185 21.4.3 402 Payment Required (料金支払いが必要) ............. 186 21.4.4 403 Forbidden (禁止) ................................ 186 21.4.5 404 Not Found (見つからない) ........................ 186 21.4.6 405 Method Not Allowed (メソッドが許可されていない) . 186 21.4.7 406 Not Acceptable (受け入れできない) ............... 186 21.4.8 407 Proxy Authentication Required (プロキシ認証が必要) 186 21.4.9 408 Request Timeout (リクエストがタイムアウトした) .. 186 21.4.10 410 Gone (リソースがもう存在しない) ................. 187 21.4.11 413 Request Entity Too Large (リクエストのエンティティ が大きすぎる) ................................... 187 21.4.12 414 Request-URI Too Long (Request-URIが長すぎる) .... 187 21.4.13 415 Unsupported Media Type (サポートされていないメディ アタイプ) ....................................... 187 21.4.14 416 Unsupported URI Scheme (サポートされていないURIス キーム) ......................................... 187 21.4.15 420 Bad Extension (不正な拡張) ...................... 187 21.4.16 421 Extension Required (拡張が必要) ................. 188 21.4.17 423 Interval Too Brief (間隔が短すぎる) ............. 188 21.4.18 480 Temporarily Unavailable (一時的に利用不可) ...... 188 21.4.19 481 Call/Transaction Does Not Exist (呼またはトランザ クションが存在しない) ........................... 188 21.4.20 482 Loop Detected (ループが検知された) .............. 188 21.4.21 483 Too Many Hops (ホップが多すぎる) ................ 189 21.4.22 484 Address Incomplete (アドレスが不完全) ........... 189 Rosenberg, et. al. Standards Track [Page 6] RFC 3261 SIP: Session Initiation Protocol June 2002 21.4.23 485 Ambiguous (不明瞭) .............................. 189 21.4.24 486 Busy Here (ここはビジー) ........................ 189 21.4.25 487 Request Terminated (リクエストが終了させられた) . 190 21.4.26 488 Not Acceptable Here (ここでは受け入れ不能) ...... 190 21.4.27 491 Request Pending (リクエストペンディング) ........ 190 21.4.28 493 Undecipherable (解読不能) ....................... 190 21.5 サーバーでの失敗応答 5xx ............................ 190 21.5.1 500 Server Internal Error (サーバー内部エラー) ...... 190 21.5.2 501 Not Implemented (実装されていない) .............. 191 21.5.3 502 Bad Gateway (不正なゲートウェイ) ................ 191 21.5.4 503 Service Unavailable (サービスを利用できない) .... 191 21.5.5 504 Server Time-out (サーバータイムアウト) .......... 191 21.5.6 505 Version Not Supported (サポートされていないバー ジョン) ........................................... 192 21.5.7 513 Message Too Large (メッセージが大きすぎる) ...... 192 21.6 グローバル失敗応答 6xx .............................. 192 21.6.1 600 Busy Everywhere (どの場所もビジー) .............. 192 21.6.2 603 Decline (辞退) .................................. 192 21.6.3 604 Does Not Exist Anywhere (どこにも存在しない) .... 192 21.6.4 606 Not Acceptable (受け入れ不能) ................... 192 22 HTTP認証の使用法 .................................... 193 22.1 フレームワーク ...................................... 193 22.2 ユーザー・ユーザー間認証 ............................ 195 22.3 プロキシ・ユーザー間認証 ............................ 197 22.4 ダイジェスト認証スキーム ............................ 199 23 S/MIME .............................................. 201 23.1 S/MIMEの証明書 ...................................... 201 23.2 S/MIMEの鍵交換 ...................................... 202 23.3 MIMEボディの安全確保 ................................ 205 23.4 S/MIMEを使用したSIPヘッダーのプライバシーと完全性: SIPトンネリング ..................................... 207 23.4.1 SIPヘッダーの完全性と機密性の特性 ................... 207 23.4.1.1 完全性 .............................................. 207 23.4.1.2 機密性 .............................................. 208 23.4.2 トンネリングの完全性と認証 .......................... 209 23.4.3 トンネリング暗号化 .................................. 211 24 例 .................................................. 213 24.1 登録 ................................................ 213 24.2 セッションセットアップ .............................. 214 25 SIPプロトコルのための拡張BNF ........................ 219 25.1 基本ルール .......................................... 219 26 セキュリティの考慮: スレットモデルとセキュリティ利用 の推奨 .............................................. 232 26.1 攻撃とスレットモデル ................................ 233 26.1.1 登録の乗っ取り ...................................... 233 26.1.2 サーバーになりすます ................................ 234 26.1.3 メッセージボディの改竄 .............................. 235 26.1.4 セッションの破壊 .................................... 235 Rosenberg, et. al. Standards Track [Page 7] RFC 3261 SIP: Session Initiation Protocol June 2002 26.1.5 サービス拒否および増幅 .............................. 236 26.2 セキュリティの仕組み ................................ 237 26.2.1 トランスポートレイヤーとネットワークレイヤーのセキュ リティ .............................................. 238 26.2.2 SIPS URIスキーム .................................... 239 26.2.3 HTTP認証 ............................................ 240 26.2.4 S/MIME .............................................. 240 26.3 セキュリティの仕組みの実装 .......................... 241 26.3.1 SIPの実装者に対する要求事項 ......................... 241 26.3.2 セキュリティソリューション .......................... 242 26.3.2.1 登録 ................................................ 242 26.3.2.2 ドメイン間リクエスト ................................ 243 26.3.2.3 ピアツーピアのリクエスト ............................ 245 26.3.2.4 DoS防御 ............................................. 246 26.4 制限事項 ............................................ 247 26.4.1 HTTPダイジェスト認証 ................................ 247 26.4.2 S/MIME .............................................. 248 26.4.3 TLS ................................................. 249 26.4.4 SIPS URI ............................................ 249 26.5 プライバシー ........................................ 251 27 IANA条項 ............................................ 252 27.1 オプションタグ ...................................... 252 27.2 警告コード(Warn-Code) ............................... 252 27.3 ヘッダーフィールド名 ................................ 253 27.4 メソッドと応答コード ................................ 253 27.5 「message/sip」MIMEタイプ .......................... 254 27.6 新規Content-Dispositionパラメータの登録 ............. 255 28 RFC2543からの変更点 ................................. 255 28.1 重要な機能変更 ...................................... 255 28.2 軽微な機能変更 ...................................... 260 29 規範的な参考文献 .................................... 261 30 有益な参考文献 ...................................... 262 A タイマー値の表 ...................................... 265 謝辞 ................................................ 266 著者の連絡先 ........................................ 267 完全な著作権表記 .................................... 269 1 はじめに セッションの生成と管理を必要とする、多くのインターネットのアプリケー ションがある。ここで、セッションとは、関係する相手どうしでのデータ交 換とみなされる。これらのアプリケーションの実装は、参加者の行動によっ て複雑化する。つまり、ユーザーはエンドポイント間で移動するかもしれない、 ユーザーを複数の名前でアドレス指定できるかもしれない、そして、ユーザー はさまざまな異なるメディアで、ときには同時に通信するかもしれない。 音声やビデオあるいはテキストメッセージといった、さまざまな形式のリア ルタイムなマルチメディアセッションデータを伝える、多くのプロトコルが立 案されている。Session Initiation Protocol(SIP)は、インターネットの Rosenberg, et. al. Standards Track [Page 8] RFC 3261 SIP: Session Initiation Protocol June 2002 エンドポイント(ユーザーエージェントと呼ばれる)がお互いを発見し、 共有を望むセッションの特性に合意することを可能にすることで、これらの プロトコルと協調して動作する。セッションの参加者と見込まれるものの 場所を特定するため、および他の機能のために、SIPは、ユーザーエー ジェントが登録リクエストやセッションへの招待およびその他のリクエスト を送ることができる、ネットワークホスト(プロキシサーバーと呼ばれる)の インフラを生成することを可能にする。SIPは、下位のトランスポートプロ トコルから独立し、確立されるセッションのタイプに依存せずに動作する、 セッションを生成・修正・終了するためのしなやかで多目的なツールである。 2 SIP機能概要 SIPは、インターネット通話のようなマルチメディアセッション(カンファレ ンス)を確立・修正・終了できるアプリケーション層制御プロトコルである。 SIPは既存の、マルチキャストカンファレンスのようなセッションに参加者を 招待することもできる。メディアを既存のセッションに追加(および既存のセッ ションから削除)することができる。SIPは、パーソナルモビリティ(参考文 献[27])(ユーザーはネットワーク上の場所に関係なく、外部から見える単一 の識別子を保持することができる)をサポートするネームマッピングとリダイ レクションサービスを透過的にサポートする。 SIPは、マルチメディアコミュニケーションの確立と終了に関する5つの側面 をサポートする。 ユーザー位置(user location): コミュニケーションに使用されるエ ンドシステムの決定。 ユーザー有効性(user availability): 着呼側パーティーのコミュニ ケーションに参加する意思の決定。 ユーザー能力(user capabilities): 使用されるメディアとメディア パラメータの決定。 セッションセットアップ(session setup): 「呼び出し」。発呼側パー ティーと着呼側パーティー双方でのセッションパラメータの決定。 セッション管理(session management): セッションの転送・終了、セッ ションパラメータの修正、サービスの起動を含む。 SIPは垂直的に統合されたコミュニケーションシステムではない。SIPはむし ろ、完全なマルチメディアアーキテクチャを築き上げるために他の IETFの プロトコルとともに使用することができるコンポーネントである。通常、こ れらのアーキテクチャは次のようなプロトコルを含む。リアルタイムデー タのトランスポートとQoSフィードバックを提供するリアルタイムトランスポー トプロトコル(RTP)(RFC1889 参考文献[28])、ストリーミングメディアの配送を 制御するためのリアルタイムストリーミングプロトコル(RTSP)(RFC2326 Rosenberg, et. al. Standards Track [Page 9] RFC 3261 SIP: Session Initiation Protocol June 2002 参考文献[29])、公衆交換電話網(PSTN)へのゲートウェイを制御するゲートウェ イ制御プロトコル(MEGACO)(RFC3015 参考文献[30])、およびマルチメディ アセッションを記述するためのセッション記述プロトコル(SDP)(RFC2327 参 考文献[1])。そのため、ユーザーに完全なサービスを提供するために、SIPは 他のプロトコルと共に使用されるべきである。しかしながら、SIPの基本機能 と操作は、これらのプロトコルのいずれにも依存しない。 SIPはサービスを提供しない。むしろSIPは、別のサービスを実装するために 使用されるプリミティブを提供する。例えば、SIPはユーザーの場所を特定 し、その現在地に不透明オブジェクト(opaque object)を配送できる。例えば、 もしこのプリミティブがSDPで書かれたセッション記述を配送するために 使用されると、エンドポイント間でセッションのパラメータを合意できる。 もし同じプリミティブが、セッション記述と同様に発呼側の写真を配送する ために使用される場合、「caller ID」サービスが容易に実装できる。この例 が示すように、ひとつのプリミティブは一般的にいくつもの異なるサービス を提供するために使用される。 SIPはフロアコントロールや投票(voting)のようなカンファレンス制御サービ スを提供せず、カンファレンスがどのように管理されるか規定しない。SIPは、 他のカンファレンス制御プロトコルを使用するセッションを開始するために 使用することができる。SIPメッセージとそれが確立するセッションはまった く別のネットワークに渡すことができるので、SIPはいかなる種類のネットワー クリソース確保能力も提供できないし、提供しない。 提供されるサービスの性質は、セキュリティを特に重要にする。このためSIP は、DoS攻撃防御、認証(ユーザー・トゥ・ユーザーおよびプロキシ・トゥ・ ユーザーの両方)、完全性防御、および暗号化とプライバシーサービスを含む、 セキュリティサービス一式を提供する。 SIPはIPv4およびIPv6の両方とともに動作する。 3 述語規則 このドキュメントでは、次のキーワードはBCP 14、RFC2119(参考文献[2])に 記述されているとおりに解釈され、SIPに準拠した実装のための要求レベル を示す。 「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、 「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、 「MAY」、および「OPTIONAL」 4 操作概要 このセクションでは、簡単な例を用いてSIPの基本操作を紹介する。このセク ションは本質的にチュートリアルであって、規範となる記述は含まない。 Rosenberg, et. al. Standards Track [Page 10] RFC 3261 SIP: Session Initiation Protocol June 2002 最初の例ではSIPの基本機能(エンドポイントの位置特定、通信の要望の発信、 セッションを確立するためのセッションパラメータのネゴシエーション、お よび確立されたセッションの解除)を示す。 図1は2人のユーザー(AliceとBob)のあいだのSIPメッセージ交換の典型的な例 を示している。(各メッセージは、文章中での参照用として「"F"+番号」とし てラベル付けしてある)。この例では、インターネット上でBobのSIPフォンと 通話するために、Aliceは 彼女のPC上でSIPアプリケーション(ソフトフォン) を使用する。図1には、セッションの確立を容易にするために AliceとBobに 成り代わって動作する、2台のSIPプロキシサーバーも示されている。この典 型的な配置は、図1の点線の図形で示されるように、「SIP台形(trapezoid)」 と呼ばれることが多い。 AliceはBobのSIPアイデンティティ(SIP URIと呼ばれるURIの一種)を使用して 「通話する」。SIP URIについてはセクション19.1で定義されている。それは E-mailアドレスと似た形式であり、通常、ユーザー名とホスト名を含む。この 例では、sip:bob@biloxi.comである。ここで、biloxi.comはBobのSIPサービス プロバイダのドメインである。Aliceはsip:alice@atlanta.com というSIP URI を持っている。Aliceはおそらく、BobのSIP URIをキーボードから打ち込むか、 ハイパーリンクあるいはアドレス帳のエントリをクリックしただろう。SIPは また、SIPS URIと呼ばれるセキュアなURIも提供する。例えば、 sips:bob@biloxi.comである。SIPS URIにかけられた通話は、発呼側から着呼側 のドメインまで、すべてのSIPメッセージを伝えるためにセキュアな暗号化され たトランスポート(すなわちTLS)が使用されることを保証する。そこから、リク エストは着呼側のドメインのポリシーに依存するセキュリティの仕組みを使用 して、安全に着呼側まで送られる。 SIPはHTTPライクなリクエスト/応答のトランザクションモデルに基づいてい る。各トランザクションは、サーバー上である特定のメソッドまたは関数を 呼び出すリクエストと、少なくとも一つの応答からなる。この例では、Alice のソフトフォンがBobのSIP URIに宛ててINVITEリクエストを送ることでトラ ンザクションが始まる。INVITEは、リクエスト送る側(Alice)がサーバー(Bob) にとってほしい動作を指定する、SIPメソッドの一例である。INVITEリクエス トは多くのヘッダーフィールドを含む。ヘッダーフィールドは、メッセージ についての追加情報を提供する、名前付けされた属性である。INVITE中に存 在するヘッダーフィールドは、呼のための一意な識別子、デスティネーショ ンアドレス、Aliceのアドレス、およびAliceがBobと確立したいセッションの タイプについての情報を含む。INVITE(図1のメッセージF1)は次のような形で ある。 Rosenberg, et. al. Standards Track [Page 11] RFC 3261 SIP: Session Initiation Protocol June 2002 atlanta.com . . . biloxi.com . プロキシ プロキシ . . . アリスの . . . . . . . . . . . . . . . . . . . . ボブの ソフトフォン SIPフォン | | | | | INVITE F1 | | | |--------------->| INVITE F2 | | | 100 Trying F3 |--------------->| INVITE F4 | |<---------------| 100 Trying F5 |--------------->| | |<-------------- | 180 Ringing F6 | | | 180 Ringing F7 |<---------------| | 180 Ringing F8 |<---------------| 200 OK F9 | |<---------------| 200 OK F10 |<---------------| | 200 OK F11 |<---------------| | |<---------------| | | | ACK F12 | |------------------------------------------------->| | Media Session | |<================================================>| | BYE F13 | |<-------------------------------------------------| | 200 OK F14 | |------------------------------------------------->| | | 図1: SIPのセッションセットアップ例(SIP台形あり) INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 142 (AliceのSDPは示されていない) テキスト形式でエンコードされたメッセージの最初の行はメソッド名(INVITE) を含む。それに続く行はヘッダーフィールドのリストである。この例では必 要とされる最小限のフィールドのセットを含む。ヘッダーについて以下に簡単 に述べる。 Rosenberg, et. al. Standards Track [Page 12] RFC 3261 SIP: Session Initiation Protocol June 2002 Viaは、Aliceがこのリクエストに対する応答の受信を望むアドレス(pc33.atl anta.com)を含む。また、このトランザクションを識別するbranchパラメータ も含む。 Toは、リクエストがもともと差し向けられた先の、表示名(Bob)とSIP URIま たはSIPS URI(sip:bob@biloxi.com)を含む。表示名についてはRFC2822(参考 文献[3])で述べられている。 Fromもリクエストの発信元の表示名(Alice)とSIP URIまたはSIPS URI(sip: alice@atlanta.com)を含む。このヘッダーフィールドは、ソフトフォンがURI に追加した乱数文字列(1928301774)を含むtagパラメータも持つ。これは識別 の目的で使用される。 Call-IDは、乱数文字列とソフトフォンのホスト名またはIPアドレスを組み合 わせて生成された、この呼のグローバルに一意な識別子を含む。To tag、From tag、およびCall-IDの組み合わせは、AliceとBobのあいだのピアツーピアの SIPリレーションシップを完全に定義し、ダイアログと呼ばれる。 CSeq(Command Sequence)は、整数値とメソッド名を含む。CSeq番号は新しい リクエストごとにインクリメントされる。CSeq番号はトラディショナルな連 続した番号である。 Contactは、Aliceにコンタクトするためのダイレクトルートを表す、通常は 完全修飾ドメイン名(FQDN)におけるユーザー名からなるSIP URIまたはSIPS URI を含む。FQDNが望ましいとはいえ、多くのエンドシステムはドメイン名を登 録していないので、IPアドレスが許可されている。Viaヘッダーフィールドが 応答をどこに送るかを他のエレメントに伝えるのに対して、Contactヘッダー フィールドは、今後のリクエストをどこに送るかを他のエレメントに伝える。 Max-Forwardsは、リクエストがデスティネーションに向かう過程でとること ができるホップ数を制限するための役に立つ。Max-Forwardsは、各ホップご とに1ずつデクリメントされる整数からなる。 Content-Typeは、メッセージボディ(例では示されていない)の説明を含む。 Content-Lengthは、メッセージボディのオクテット(byte)カウントを含む。 SIPヘッダーフィールドの完全なセットはセクション20で定義されている。 セッションの詳細、例えばメディアのタイプ、コーデック、サンプリング レートは、SIPを使用して記述されない。むしろ、SIPメッセージのボディが、 他のプロトコルの書式でエンコードされたセッションの記述を含む。そのよう な書式の一つがセッション記述プロトコル(SDP)(RFC2327 参考文献[1])であ る。このSDPメッセージ(例には示されていない)は、E-mailメッセージで Rosenberg, et. al. Standards Track [Page 13] RFC 3261 SIP: Session Initiation Protocol June 2002 ドキュメントのアタッチメントが運ばれるように、あるいはHTTPメッセージ でWebページが運ばれるように、SIPメッセージによって運ばれる。 ソフトフォンはBobの場所、あるいはbiloxi.comドメインのSIPサーバーの場 所を知らないので、Aliceのドメイン(atlanta.com)のSIPサーバーにINVITEを 送る。atlanta.comのSIPサーバーのアドレスは、例えば、Aliceのソフトフォ ンに設定されているかもしれないし、あるいはDHCPによって発見されるも しれない。 atlanta.comのSIPサーバーは、プロキシサーバーとして知られるタイプのSIP サーバーである。プロキシサーバーはリクエストを送った者の代わりにSIPリ クエストを受信し、それを転送(forward)する。[訳注:以降、transferと区 別し、「転送(forward)」、「転送(transfer)」と併記。]この例では、プロキ シサーバーが INVITEリクエストを受信し、Aliceのソフトフォンに100(Trying) 応答を送り返す。100(Trying)応答は、INVITEが受信され、プロキシがAliceの ソフトフォンに成り代わって、デスティネーションにINVITEをルートすること を試みていることを示す。SIPでの応答は、数値3桁のコードとそれに続く説明 フレーズを用いる。この応答は、INVITEと同じTo、From、Call-ID、CSeq、およ びbranchパラメータを持ったViaを含む。これは、Aliceのソフトフォンが、 送信したINVITEにこの応答を関係付けることを可能にする。atlanta.comのプ ロキシサーバーは、biloxi.comドメインのSIPサーバーを見つけるために、お そらく特定のタイプのDNS(Domain Name Service)ルックアップを実行して、 biloxi.comのプロキシサーバーの場所を特定する。これについては参考文献 [4]で述べられている。結果として、それはbiloxi.comのプロキシサーバーの IPアドレスを取得し、INVITEリクエストをそこに転送(forward)(またはプロ キシ)する。リクエストを転送(forward)する前に、atlanta.comのプロキシサー バーはそれ自身のアドレスを含む付加的なViaヘッダーフィールド値を追加す る(INVITE は最初のViaにAliceのアドレスをすでに含んでいる)。biloxi.comの プロキシサーバーはINVITEを受信し、それがINVITEを受信しリクエストを処理 していることを示すために、atlanta.comのプロキシサーバーに100(Trying)応 答で応答する。プロキシサーバーは、Bobの現在のIPアドレスを含む一般的に ロケーションサービスと呼ばれるデータベースに問い合わせる。(このデータ ベースをどのようにして存在させることができるか、次のセクションでわかる だろう。)biloxi.comのプロキシサーバーは、それ自身のアドレスを含むもう一 つのViaヘッダーフィールド値をINVITEに追加し、それをBobのSIPフォンにプロ キシする。 BobのSIPフォンはINVITEを受信すると、BobがAliceからかかってきた通話を 受けるかどうか決定できるように、その通話をBobに知らせる。つまり、Bob の電話が鳴る。BobのSIPフォンは、2つのプロキシを逆向きにルートされて返 される、180(Ringing)応答でこのことを示す。各プロキシは、応答をどこに 送るか決定するためにViaヘッダーフィールドを使用し、先頭から自分自身の アドレスを取り除く。結果として、最初のINVITEをルートするためにはDNSと ロケーションサービスのルックアップが必要とされたが、180(Ringing)応答 はルックアップやプロキシで保持されているステートを使用せずに発呼側に 返すことができる。このことはまた、INVITEを見る各プロキシは、そのINVITE Rosenberg, et. al. Standards Track [Page 14] RFC 3261 SIP: Session Initiation Protocol June 2002 へのすべての応答をも見ることになるという望ましい特性も持つ。 Aliceのソフトフォンが180(Ringing)応答を受信すると、それは、おそらく呼 び出し音あるいはAliceの画面上にメッセージを表示して、この情報をAlice に渡す。 この例では、Bobは通話を受けることにする。彼がハンドセットを取ると、彼 のSIPフォンは、通話が受けられたことを示すために200(OK)応答を送信する。 200(OK)は、BobがAliceと確立することを望むセッションのタイプのSDPメディ ア記述を持つメッセージボディを含む。結果として、2フェーズのSDPメッセー ジ交換があることになる。Aliceが一つをBobに送り、Bobは一つをAliceに送り 返す。この2フェーズの交換は、基本的なネゴシエーション能力を提供 する。そしてこれは、SDP交換の単純なオファー/アンサーモデルに基づいて いる。もしBobが通話を受けたくなかったり、他の通話でビジーだった場合、 200(OK)のかわりにエラー応答が返され、メディアセッションが確立されない 結果になっただろう。SIP応答コードの完全なリストはセクション21にある。 Bobが送るときの200(OK)(図1のメッセージF9)は以下のようである。 SIP/2.0 200 OK Via: SIP/2.0/UDP server10.biloxi.com ;branch=z9hG4bKnashds8;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com ;branch=z9hG4bK776asdhds ;received=192.0.2.1 To: Bob ;tag=a6c85cf From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 131 (BobのSDPは示されていない) 応答の最初の行は応答コード(200)と理由フレーズ(OK)を含む。残りの行は ヘッダーフィールドを含む。Via、To、From、Call-ID、およびCSeqヘッダー フィールドはINVITEリクエストからコピーされた。(3つのViaヘッダーフィー ルド値がある。AliceのSIPフォンが追加したもの、atlanta.comのプロキシが 追加したもの、biloxy.comのプロキシが追加したものである。)BobのSIPフォ ンがToヘッダーフィールドにtagパラメータを追加した。このtagは両方のエ ンドポイントによってダイアログに組み込まれ、この呼の今後のすべてのリ Rosenberg, et. al. Standards Track [Page 15] RFC 3261 SIP: Session Initiation Protocol June 2002 クエストと応答に含められる。Contactヘッダーフィールドは、BobのSIPフォ ンで彼にダイレクトに到達できるURIを含む。Content-TypeとContent-Length は、BobのSDPメディア情報を含む(ここでは示されていない)メッセージボディ について言及している。 この例で示されたDNSとロケーションサービスのルックアップに加えて、プロ キシサーバーは、リクエストをどこに送るか決定するために柔軟な「ルーティ ングの決定」を下せる。例えば、もしBobのSIPフォンが486(Busy Here) 応答を返した場合、biloxi.comのプロキシサーバーはINVITEをBobのボイスメー ルサーバーにプロキシすることもできる。プロキシサーバーは同時に多くの場 所にINVITEを送ることもできる。このタイプのパラレルサーチはフォークとし て知られている。 この場合、200(OK)は2つのプロキシを通してルートバックされ、Aliceのソフ トフォンによって受信される。それから、呼び出し音を止め、通話が受けら れたことを示す。最後に、最終応答(200(OK))の受信をコンファームするため に、Aliceのソフトフォンは確認メッセージ(ACK)をBobのSIPフォンに送る。 この例では、ACKは2つのプロキシをバイパスしてAliceのソフトフォンからBob のSIPフォンに直接送られる。これは、INVITE/200(OK)の交換を通して、2つ のエンドポイントが、最初のINVITEが送られたときには知らなかったお互い のアドレスをContactヘッダーフィールドから知ったために起こる。2つのプ ロキシが実行したルックアップはもはや必要ではないので、プロキシはコー ルフローから抜ける。これで、SIPセッションを確立するために使用された INVITE/200/ACKの3ウェイハンドシェイクが完了する。セッションセットアッ プについての全詳細はセクション13で述べる。 AliceとBobのメディアセッションが開始され、彼らは、SDPの交換で合意した 書式を使用してメディアパケットを送る。一般に、エンドツーエン ドのメディアパケットはSIPのシグナリングメッセージとは別の経路を取る。 セッション中に、AliceまたはBobのいずれかがメディアセッションの特性 (characteristics)の変更を決定できる。これは新しいメディア記述を含む re-INVITEを送ることで達成できる。このre-INVITEは、それが新たなセッショ ンを確立するのではなく既存のセッションを修正するためのものであるこ とを相手が理解するように、既存のダイアログを参照する。相手はその変更 を受け入れるために200(OK)を送る。リクエストを送った側はその200(OK)に 対してACKで応答する。相手が変更を受け入れない場合、488(Not Acceptable Here)のようなエラー応答が送信される。これもACKを受信する。しかしながら、 re-INVITEの失敗は既存の呼を失敗させる原因にならない - 既にネゴシエー トされた特性(characteristics)を用いてセッションは継続する。セッション 修正についての全詳細はセクション14で述べる。 Rosenberg, et. al. Standards Track [Page 16] RFC 3261 SIP: Session Initiation Protocol June 2002 呼の終了時に、Bobが先に切断(ハングアップ)し、BYEメッセージを生成する。 このBYEは、再びプロキシをバイパスして、Aliceのソフトフォンにダイレクト にルートされる。AliceはBYEの受信を200(OK)応答でコンファームする。これ はセッションとBYEトランザクションを終了する。ACKは送られない - ACKは、 INVITEリクエストに対する応答への応答としてのみ送信される。この、INVITE の特別な操作の理由については後ほど議論するが、SIPの信頼性の仕組み、呼 び出し中の電話が受けられるまでに取ることができる時間長さ、およびフォー クに関連している。この理由により、SIPにおけるリクエスト操作は、INVITE または非INVITE(INVITE以外のすべてのメソッド)のいずれかに分類されること が多い。セッション終了についての全詳細はセクション15で述べる。 セクション24.2では図1の例で示されたメッセージがすべて記載されている。 ある場合には、セッションが継続しているあいだ中、2つのエンドポイント間 のすべてのメッセージングを見ることは、SIPのシグナリングパスの中にある プロキシにとって有用かもしれない。例えば、biloxi.comのプロキシサー バーが最初のINVITE後もSIPのメッセージングパス中にとどまることを望む場 合、それはINVITEに、解決されるとそのプロキシのホスト名またはIPアドレ スになるURIを含む、Record-Routeとして知られている、ルーティングに必要 とされるヘッダーフィールドを追加するだろう。この情報は、BobのSIPフォ ンと(200(OK)で返されることになるRecord-Routeヘッダーフィールドによっ て)Aliceのソフトフォンの双方に受信され、ダイアログが継続しているあい だ記憶される。その後biloxy.comのプロキシサーバーは、ACK、BYE、および BYEに対する200(OK)を受信してプロキシするだろう。各プロキシは、それに 続くメッセージングを受信することを独自に決定でき、メッセージングは、 それを受信することを選んだすべてのプロキシを経由するだろう。この能力 は、コール内機能(mid-call features)を提供するプロキシのためにたびたび 使用される。 登録は、SIPにおけるもう一つの通常操作である。登録はbiloxi.comのサーバー がBobの現在位置を知ることができる一つの方法である。初期化時および定 期的に、BobのSIPフォンはSIP登録サーバーとして知られるbiloxi.comのサー バーにREGISTERメッセージを送る。REGISTERメッセージはBobのSIP URIまた はSIPS URI(sip:bob@biloxi.com)と彼が現在ログインしているマシンを関連 付ける(Contactヘッダー中でSIP URIまたはSIPS URIとして伝えられる)。登 録サーバーはこの関連付け(バインディングとも呼ばれる)をデータベース(ロ ケーションサービスと呼ばれる)に書き込む。それはbiloxi.comドメインのプ ロキシが利用できる。ドメインの登録サーバーは、そのドメインのプロキシ と同じ場所に配置されることが多い。SIPサーバーのタイプの区別は論理的な ものであって、物理的なものでないということは重要なコンセプトである。 Bobは、単一デバイスからの登録ということに制限を受けない。例えば、自 宅にある彼のSIPフォンとオフィスにあるSIPフォンの両方で登録を送ること ができる。この情報は共にロケーションサービスに記憶され、Bobの場所を特 Rosenberg, et. al. Standards Track [Page 17] RFC 3261 SIP: Session Initiation Protocol June 2002 定するためにプロキシが様々なタイプの検索を実行することを可能にする。 同様に、二人以上のユーザーを、同時に一つのデバイス上に登録することが できる。 ロケーションサービスはただの抽象的なコンセプトである。それは通常、プ ロキシがURIをインプットして、リクエストをどこに送るかをプロキシに教え る0個以上のURIのセットを受け取ることを可能にする情報を含む。登録はこ の情報を生成するための一つの方法であるが、唯一の方法ではない。管理者 の判断で、任意のマッピング機能を設定できる。 最後に、SIPにおいて登録は、送られてくるSIPリクエストのルーティングに 使用され、送り出されるリクエストの認可には何の役割も果たさないという ことに注意することが重要である。SIPにおいて認可と認証は、セクション26 で議論されるように、チャレンジ応答の仕組みでリクエストごとに、あるいは 下位レイヤースキームを使用して、操作される。 この登録の例についてのSIPメッセージの完全なセットの詳細は、セクション 24.1で述べられている。 OPTIONSを使用してSIPサーバーやクライアントの能力を問い合わせたり、 CANCELを使用してペンディング中のリクエストをキャンセルするといった SIPの付加的な操作は、後のセクションで紹介される。 5 プロトコルの構造 SIPはレイヤー化されたプロトコルとして構造化されている。これは、その 動作が、各ステージ間のゆるい結合のみがある、ほとんど独立した過程にある ステージのセットという形で説明されることを意味する。プロトコルの動作 は、それを描写するために複数のレイヤーとして説明される。これは、一つ のセクションでエレメント間に共通する機能の説明を可能にする。それはど のような形であれ実装に影響しない。エレメントがレイヤーを「含む」と言 うとき、それはそのレイヤーで定義されたルールのセットに従うことを意味 する。 プロトコルで規定されたすべてのエレメントが全レイヤーを含むわけではな い。さらに、SIPで規定されたエレメントは論理的なエレメントであって、物 理的なものではない。物理的に実現されたものは、おそらくトランザクショ ン毎であっても別の論理エレメントとして動作することを選択できる。 SIPの最下位のレイヤーは、構文とエンコーディングである。エンコー ディングは拡張BNFを使用して指定される。完全なBNFはセクション25で規 定されている。SIPメッセージの構造の概要は、セクション7で述べられてい る。 Rosenberg, et. al. Standards Track [Page 18] RFC 3261 SIP: Session Initiation Protocol June 2002 2番めのレイヤーはトランスポートレイヤーである。このレイヤーは、ネット ワーク上でクライアントがどのようにリクエストを送り応答を受け取るか、 そしてサーバーがリクエストを受け取り応答を送るかを定義する。すべての SIPエレメントはトランスポートレイヤーを含む。トランスポートレイヤーに ついてはセクション18で述べられている。 3番めのレイヤーはトランザクションレイヤーである。トランザクションは SIPの基本コンポーネントである。トランザクションは、(トランスポートレ イヤーを利用して)クライアントトランザクションからサーバートランザクショ ンに送られる一つのリクエストと、サーバートランザクションからクライ アントに送り返されるそのリクエストに対するすべての応答である。トラン ザクションレイヤーは、アプリケーションレイヤーの再送、応答のリクエス トへのマッチング、およびアプリケーションレイヤーのタイムアウトを操作 する。ユーザーエージェントクライアント(UAC)が成し遂げるどのような タスクも、一連のトランザクションを使って行われる。トランザクション についての議論はセクション17で述べられている。ユーザーエージェント は、ステートフルプロキシでもそうであるように、トランザクションレイヤー を含む。ステートレスプロキシはトランザクションレイヤーを含まない。 トランザクションレイヤーはクライアントコンポーネント(クライアントトラ ンザクションと呼ばれる)とサーバーコンポーネント(サーバートランザクショ ンと呼ばれる)を持ち、それらは特定のリクエストを処理するために構築される 有限ステートマシンによって表される。 トランザクションレイヤーの上にあるレイヤーはトランザクションユーザー (TU)と呼ばれる。ステートレスプロキシを除く各SIPエンティティは、トラン ザクションユーザーである。TUがリクエストを送ろうとするとき、TUはクラ イアントトランザクションインスタンスを生成し、リクエストを送る先のデ スティネーションIPアドレス、ポート、およびトランスポートと共にリクエ ストをそれに渡す。クライアントトランザクションを生成するTUは、それを キャンセルすることもできる。クライアントがトランザクションをキャンセ ルするとき、クライアントは、サーバーが更なる処理を中止し、トランザク ションが開始される前に存在していたステートに復帰し、そのトランザクショ ンに対して特定のエラー応答を生成するすることを要求する。これは、 CANCELリクエスト(それ自身のトランザクションを設立する)で行われるが、 キャンセルされるトランザクションを参照する(セクション9参照)。 SIPエレメント、すなわち、ユーザーエージェントクライアントとサーバー、 ステートレスおよびステートフルプロキシと登録サーバーは、それらを互い に区別するコアを含む。ステートレスプロキシ以外のコアは、トランザクショ ンユーザーである。UASとUACのコアの動作はメソッドに依存するとはいえ、 すべてのメソッドに対するいくつかの共通のルールがある(セクション8参照)。 UACにおいては、これらのルールはリクエストの構築を律する。UASにおいて は、それらはリクエストの処理と応答の生成を律する。SIPでは登録が重要な 役割を演じるので、REGISTERを操作するUASは、登録サーバーという特別な名 称を与えられている。セクション10では、REGISTERメソッドに対するUACおよ びUASコアの動作を述べている。セクション11では、UAの能力を決定するため に使用される、OPTIONSメソッドに対するUACおよびUASコアの動作を述べて いる。 Rosenberg, et. al. Standards Track [Page 19] RFC 3261 SIP: Session Initiation Protocol June 2002 その他の特定のリクエストはダイアログ内で送られる。ダイアログとは、し ばらくのあいだ持続する2つのユーザーエージェント間のピアツーピアのSIP リレーションシップである。ダイアログは、ユーザーエージェント間のメッ セージの順序付けと、それらのあいだの適切なルーティングを容易にする。 INVITEメソッドは、ダイアログを確立するためにこの仕様で定義された唯一 の方法である。UACがダイアログのコンテキスト内にあるリクエストを送ると き、それはセクション8で議論されるUACの一般ルールに従うが、ダイアログ 内リクエスト(mid-dialog request)のルールにも従う。セクション12ではダ イアログ内でのリクエストの構築に加え、ダイアログについて議論し、その 構築手順やメンテナンスについて示す。 SIPにおいて最も重要なメソッドはINVITEメソッドである。INVITEメソッドは 参加者間でセッションを確立するために使用される。セッションとは、コミュ ニケーションを目的とする、参加者の集まり、およびそれらのあいだのメ ディアの流れである。セクション13では、どのようにセッションが開始され、 一つ以上のSIPダイアログが生じるかを議論する。セクション14では、ダイア ログ内でのINVITEリクエストの使用によって、そのセッションの特性がどの ように修正されるかを議論する。最後に、セクション15では、セッションが どのように終了されるかを議論する。 セクション 8、10、11、12、13、14、および15の手順はすべてUAコアを対象 とする(セクション9はUAコアとプロキシコアの両方に適用する、キャンセル について述べる)。セクション16はプロキシエレメントについて議論する。プ ロキシエレメントはユーザーエージェント間のメッセージのルーティングを 容易にする。 6 定義 以下の用語はSIPにおいて特別な意味を持つ。 Address-of-Record: Address-of-Record(AOR)とは、SIPまたはSIPS URI をユーザーがいるかもしれない別のURIにマップすることができる ロケーションサービスがあるドメインを指し示す、SIPまたはSIPS URIである。通常、ロケーションサービスは登録によって存在する。 AORはしばしばユーザーの「パブリックアドレス」とみなされる。 バックトゥバック ユーザーエージェント(Back-to-Back User Agent): バックトゥバック ユーザーエージェント(B2BUA)とは、リクエス トを受け取り、ユーザーエージェントサーバー(UAS)としてそれを 処理する論理的なエンティティである。リクエストにどのように 答えるべきか決定するためにユーザーエージェントクライアント (UAC)として動作し、リクエストを生成する。プロキシサーバーと は違い、ダイアログのステートを保持し、それが確立したダイア ログ上で送られるすべてのリクエストに関与しなければならない。 UACとUASが結合されたものなので、その動作に関する明示的な定 義は必要とされない。 Rosenberg, et. al. Standards Track [Page 20] RFC 3261 SIP: Session Initiation Protocol June 2002 呼(Call): 呼とは、通常、マルチメディア会話をするためにセットアッ プされるピア間のコミュニケーションについて言及するインフォー マルな用語である。 コールレグ(Call Leg): ダイアログの別名(参考文献[31])。この仕様で は、もう使われない。 コールステートフル(Call Stateful): プロキシは、ダイアログを開始 するINVITEから終了するBYEリクエストまでのあいだダイアログの ステートを保持するとき、コールステートフルである。コールス テートフルなプロキシは常にトランザクションステートフルであ るが、その逆は必ずしも真ではない。 クライアント(Client): クライアントとは、SIPリクエストを送りSIP応 答を受け取るあらゆるネットワークエレメントのことである。ク ライアントはユーザー(人間)と直接対話することも、しないこと もある。ユーザーエージェントクライアントとプロキシはクライ アントである。 カンファレンス(Conference): 複数の参加者を含むマルチメディアセッ ション(下記参照)。 コア(Core): コアは個々のタイプのSIPエンティティに特有な機能を指 定する。すなわち、ステートフルまたはステートレスプロキシに 特有な機能、ユーザーエージェントまたは登録サーバーに特有な 機能。ステートレスプロキシのコア以外のすべてのコアはトラン ザクションユーザーである。 ダイアログ(Dialog): ダイアログとは、しばらくのあいだ持続する2つ のUA間のピアツーピアのSIPリレーションシップである。ダイアロ グは、INVITEリクエストに対する2xx応答のようなSIPメッセージ によって確立される。ダイアログは呼識別子(call identifier)、 ローカルtag、およびリモートtagによって識別される。ダイアロ グは、以前はRFC2543においてコールレグとして知られていた。 ダウンストリーム(Downstream): ユーザーエージェントクライアント からユーザーエージェントサーバーへのリクエストの流れの向き について言及するときの、トランザクション内を進むメッセージ の向き。 最終応答(Final Response): SIPトランザクションを終了しない暫定応 答(Provisional Response)とは逆に、SIPトランザクションを終了 する応答。2xx、3xx、4xx、5xx、および6xxはすべて最終応答であ る。 ヘッダー(Header): ヘッダーとは、SIPメッセージについての情報を伝 えるSIPメッセージの構成要素である。ヘッダーはヘッダーフィー ルドのつながりとして構築される。 ヘッダーフィールド(Header Field): ヘッダーフィールドとは、SIPメッ セージヘッダーの構成要素である。 ヘッダーフィールドは1個以上のフィールド列として出現しうる。 ヘッダーフィールド列はヘッダーフィールド名と、0個以上のヘッ ダーフィールド値で構成される。特定のヘッダーフィールド列上の Rosenberg, et. al. Standards Track [Page 21] RFC 3261 SIP: Session Initiation Protocol June 2002 複数のヘッダーフィールド値はカンマで区切られる。いくつかの ヘッダーフィールドは1つのヘッダーフィールド値しか持つことが できないので、結果として、1つのヘッダーフィールド列として 現れる。 ヘッダーフィールド値(Header Field Value): ヘッダーフィールド値と は、一つの値である。ヘッダーフィールドは0個以上の ヘッダーフィールド値で構成される。 ホームドメイン(Home Domain): SIPユーザーにサービスを提供するドメ イン。通常これは、登録のAddress-of-Record内のURIに存在するド メインである。 通知応答(Informational Response): 暫定応答と同じ。 イニシエータ(Initiator)、発呼側パーティー(Calling Party)、発呼 側(Caller): INVITEリクエストでセッション(およびダイアログ)を開始 するパーティー。発呼側は、ダイアログを確立した最初のINVITE を送ってからそのダイアログの終了まで、この役割を維持する。 招待(Invitation): INVITEリクエストのこと。 被招待側(Invitee)、被招待ユーザー(Invited User)、着呼側パーティー (Called Party)、着呼側(Callee): 新たなセッションを確立するため のINVITEリクエストを受け取るパーティー。着呼側は、INVITEを 受け取ってからそのINVITEで確立されたダイアログの終了まで、 この役割を維持する。 ロケーションサービス(Location Service): ロケーションサービスは、 着呼側のいる可能性のある場所(一つまたは複数)を取得するため に、SIPリダイレクトサーバーあるいはプロキシサーバーによって 使用される。ロケーションサービスはAddress-of-Recordキーとゼ ロ個以上のコンタクトアドレスのバインディングリストを含む。 バインディングは様々な方法によって生成、削除できる。この仕 様では、バインディングをアップデートするREGISTERメソッドを 定義する。 ループ(Loop): プロキシに到達し、転送(forward)され、その後しばら くしてから同じプロキシに戻ってくるリクエスト。それがプロキシ に2度目に到達するとき、それのRequest-URIは初回時と同じであり、 プロキシ操作に影響を及ぼすその他のヘッダーは変更されていな いため、プロキシはそのリクエストに対して初回時と同じ処理決 定を下すことになる。ループしたリクエストはエラーであり、そ れを検出・操作する手順はプロトコルによって記述される。 ルースルーティング(Loose Routing): プロキシがRouteヘッダーフィー ルドの処理のために、この仕様で定義されている手順に従う場合、 そのプロキシはルースルーティングであるといわれる。この手順 は、デスティネーションに向かう途中で訪れる必要があるプロキ シのセット(Routeヘッダーフィールド中に存在する)から、リクエ Rosenberg, et. al. Standards Track [Page 22] RFC 3261 SIP: Session Initiation Protocol June 2002 ストのデスティネーション(Request-URI中に存在する)を分離する。 これらの仕組みに準拠するプロキシはルースルータ(Loose Router) としても知られている。 メッセージ(Message): プロトコルの一部としてSIPエレメント間で送ら れるデータ。SIPメッセージはリクエストか応答のいずれかである。 メソッド(Method): メソッドとは、サーバー上でリクエストが呼び出さ ることを意味する、主要な機能である。メソッドはリクエストメッ セージ自身によって伝えられる。メソッドの例として、INVITE とBYEがある。 アウトバウンドプロキシ(Outbound Proxy): クライアントから のリクエストを受け取るプロキシ(たとえそれがRequest-URIで解 決されたサーバーでなくても)。通常、UAにはマニュアルでアウト バウンドプロキシが設定される。あるいは自動設定プロトコルに よってアウトバウンドプロキシを知ることができる。 パラレルサーチ(Parallel Search): パラレルサーチでは、送られてく るリクエストを受け取ると、プロキシはユーザーのいると思われ る複数の場所にいくつかのリクエストを発行する。シーケンシャ ルサーチのように一つのリクエストを発行して、最終応答を待っ てから次のリクエストを発行するのではなく、パラレルサーチで は、すでに発行したリクエストの結果を待たずに複数のリクエス トを発行する。 暫定応答(Provisional Response): 進行状況を示すためにサーバーが使 用する応答。この応答はSIPトランザクションを終了しない。1xx 応答は暫定応答であり、その他の応答は最終応答とみなされる。 プロキシ(Proxy)、プロキシサーバー(Proxy Server): 他のクライアン トに成り代わってリクエストを生成するために、サーバーやクラ イアントの両方として動作する中間エンティティ。プロキシサー バーは、主としてルーティングの役割を演じる。これは、リクエ ストが、ターゲットユーザーに「より近い」他のエンティティに 送られることを保証することが、プロキシサーバーの役目である ことを意味する。プロキシは、ポリシーを強制するためにも有用 である(例えば、ユーザーが電話をかけることを許可されている ことを確認すること)。プロキシは、リクエストメッセージを転送 (forward)する前に、それを解釈し、必要であればその特定部分を 書き換える。 再帰(Recursion): クライアントが3xx応答のContactヘッダーフィール ドに含まれる一つ以上のURIに対して新規リクエストを生成すると き、クライアントは3xx応答で再帰するという。 リダイレクトサーバー(Redirect Server): リダイレクトサーバーとは、 受け取ったリクエストに対して3xx応答を生成するユーザーエージェ ントサーバーである。そうすることで、別のURIセットにコンタクト することをクライアントに指示する。 Rosenberg, et. al. Standards Track [Page 23] RFC 3261 SIP: Session Initiation Protocol June 2002 登録サーバー(Registrar): 登録サーバーとは、REGISTERリクエストを受 け入れ、そのリクエストで受け取る情報を、操作するドメインの ロケーションサービスに置くサーバーである。 レギュラートランザクション(Regular Transaction): レギュラートラ ンザクションとは、INVITE、ACK、またはCANCEL以外のメソッドを 含むすべてのトランザクションである。 リクエスト(Request): 特定の操作を実行するために、クライアントか らサーバーに送られたSIPメッセージのこと。 応答(Response): クライアントからサーバーに送られたリクエストのス テータスを示すために、サーバーからクライアントに送られたSIP メッセージのこと。 リングバック(Ringback): リングバックとは、発呼側パーティーのアプ リケーションが作り出す、着呼側パーティーが呼び出されている ことを示すシグナル音である。 ルートセット(Route Set): ルートセットとは、特定のリクエストを送 るときにトラバースされなければならないプロキシのリストを表 す、SIPまたはSIPS URIの並びの集まりである。ルートセットは Record-Routeのようなヘッダーから知ることができるし、あるい は、設定することもできる。 サーバー(Server): サーバーとは、リクエストを受信処理し、そのリク エストに応答を送り返すためのネットワークエレメントである。 サーバーの例として、プロキシ、ユーザーエージェントサーバー、 リダイレクトサーバー、および登録サーバーがある。 シーケンシャルサーチ(Sequential Search): シーケンシャルサーチで は、プロキシサーバーは各コンタクトアドレスを順番に試す。す でに試したコンタクトアドレスが最終応答を生成した後にのみ次 のコンタクトアドレスに進む。2xxまたは6xxクラスの最終応答は 常にシーケンシャルサーチを終了する。 セッション(Session): SDP仕様によれば「マルチメディアセッションと は、マルチメディアを送る側と受ける側および送り手から受け手 に流れるデータストリームのセットのことである。マルチメディ アカンファレンスは、マルチメディアセッションの一例である。」 (RFC2327参考文献[1]) (SDPで定義されたセッションは、一つ以上 のRTPセッションから成る。) この定義のように、着呼側を(異な る呼によって)同じセッションに何回も招待可能である。SDPが使 用される場合、セッションは、SDPユーザー名、セッションID、ネッ トワークタイプ、アドレスタイプ、およびoriginフィールドの アドレスエレメントを結合したもので定義される。 SIPトランザクション(SIP Transaction): SIPトランザクションはクラ イアントとサーバーのあいだで発生し、クライアントからサーバー に送られた最初のリクエストから、サーバーからクライアント Rosenberg, et. al. Standards Track [Page 24] RFC 3261 SIP: Session Initiation Protocol June 2002 に送られた最終応答(非1xx)までのすべてのメッセージからなる。 リクエストがINVITEで最終応答が非2xxの場合、トランザクション はその応答に対するACKも含む。INVITEリクエストに対する2xx応 答へのACKは、別のトランザクションである。 スパイラル(Spiral): スパイラルとは、プロキシにルートされてから転 送(forward)され、再び同じプロキシに戻ってくるSIPリクエストの ことである。しかし今度は、オリジナルリクエストとは違う処理決 定を下されることになるある違いがある。通常これは、そのリク エストが前回の到着時とは異なるRequest-URIを持つことを意味す る。ループとは違い、スパイラルはエラー状態ではない。スパイ ラルの典型的な原因は、通話の転送(call forwarding)である。ユー ザーが joe@example.com を呼び出す。example.comのプロキシ はそれをJoeのPCに転送(forward)し、今度はそのPCがそれを bob@example.comに転送(forward)する。このリクエストはexample.com のプロキシにプロキシされて戻される。しかしながら、これはルー プではない。リクエストが別のユーザーに向けられているので、ス パイラルとみなされ、有効な状態である。 ステートフルプロキシ(Stateful Proxy): リクエストを処理するあいだ、 この仕様で定義されているクライアントトランザクションおよび サーバートランザクションのステートマシンを維持する、論理的 なエンティティであり、トランザクションステートフルプロキシ としても知られている。ステートフルプロキシの動作は、セクション 16でさらに詳しく定義されている。(トランザクション)ステートフ ルプロキシは、コールステートフルプロキシと同じではない。 ステートレスプロキシ(Stateless Proxy): リクエストを処理するとき に、この仕様で定義されているクライアントトランザクションあ るいはサーバートランザクションのステートマシンを維持しない、 論理的なエンティティ。ステートレスプロキシは、受け取るすべ てのリクエストをダウンストリームに、および受け取るすべての 応答をアップストリームに転送(forward)する。 ストリクトルーティング(Strict Routing): プロキシがRFC2543および このRFCの以前の処理中版のRoute処理ルールに従う場合、その プロキシはストリクトルーティングであるといわれる。そのルール は、Routeヘッダーフィールドが存在したときに、プロキシに Request-URIのコンテンツを破壊させていた。ルースルーティング 動作を優先して、この仕様ではストリトルーティング動作は使用 されない。ストリクトルーティングを実行するプロキシはストリ クトルータ(Strict Router)としても知られている。 ターゲットリフレッシュリクエスト(Target Refresh Request): ダイア ログ内で送られたターゲットリフレッシュリクエストは、ダイア ログのリモートターゲットを修正することができるリクエスト、 と定義される。 トランザクションユーザー(Transaction USer、TU): トランザクション レイヤーの上にあるプロトコル処理のレイヤー。トランザクショ ンユーザーは、UACコア、UASコア、およびプロキシコアを含む。 Rosenberg, et. al. Standards Track [Page 25] RFC 3261 SIP: Session Initiation Protocol June 2002 アップストリーム(Upstream): ユーザーエージェントサーバーからユー ザーエージェントクライアントに戻る応答の流れの向きについて 言及するときの、トランザクション内を進むメッセージの向き。 URLエンコードされた(URL-encoded): RFC2396 のセクション 2.4(参考 文献[5])に則ってエンコードされた文字列。 ユーザーエージェントクライアント(User Agent Client、UAC): ユーザー エージェントクライアントとは、新しいリクエストを生成し、 それを送るためにクライアントトランザクションのステートマシ ンを使用する、論理的なエンティティ。UACの役目は、そのトラン ザクションが継続するあいだだけ存続する。言い換えるなら、あ るソフトウェアがリクエストを開始した場合、それは、そのトラ ンザクションが継続するあいだUACとして動作する。その後それが リクエストを受け取った場合、それはそのトランザクション処理 のためにユーザーエージェントサーバーの役目を果たす。 UAC コア(UAC Core): トランザクションレイヤーとトランスポートレイ ヤーの上にある、UACに必要とされる処理機能のセット。 ユーザーエージェントサーバー(User Agent Server、UAS): ユーザーエー ジェントサーバーとは、SIPリクエストに対して応答を生成する 論理的なエンティティである。応答は、リクエストを受け入れる、 拒否する、あるいはリダイレクトする。この役目は、そのトラン ザクションが継続するあいだだけ存続する。言い換えるなら、あ るソフトウェアがリクエストに応答する場合、それは、そのトラ ンザクションが継続するあいだUASとして動作する。その後それが リクエストを生成した場合、それはそのトランザクション処理の ためにユーザーエージェントクライアントの役目を果たす。 UAS コア(UAS Core): トランザクションレイヤーとトランスポートレイ ヤーの上にある、UASに必要とされる処理機能のセット。 ユーザーエージェント(User Agent、UA): ユーザーエージェントクライ アントとしてもユーザーエージェントサーバーとしても動作でき る、論理的なエンティティ。 プロキシサーバーおよびリダイレクトサーバーと同様に、UACとUASの役目は トランザクションごとに定義される。例えば、呼を開始するユーザーエー ジェントは、最初のINVITEリクエストを送るときはUACとして動作し、着呼側 からBYEリクエストを受け取るときはUASとして動作する。同様に、同一のソ フトウェアが、あるリクエストにはプロキシサーバーとして動作し、その次 のリクエストにはリダイレクトサーバーとして動作することも可能である。 上で定義されたプロキシサーバー、ロケーションサーバー、および登録サー バーは、論理的なエンティティである。実装ではそれらを一つのアプリケー ションに結合してもよい[MAY]。 7 SIP メッセージ SIPはテキストベースのプロトコルであり、UTF-8文字セット(RFC2279 参考文 献[7])を使用する。 Rosenberg, et. al. Standards Track [Page 26] RFC 3261 SIP: Session Initiation Protocol June 2002 SIPメッセージは、クライアントからサーバーへのリクエストまたはサーバー からクライアントへの応答のいずれかである。 リクエストメッセージ(セクション7.1)と応答メッセージ(セクション7.2)は 共に、文字セットと構文の詳細において、構文は異なるが、RFC2822(参考文献 [3])の基本書式を使用する。(例えば、SIPはRFC2822のヘッダーフィー ルドでは有効でないかもしれないヘッダーフィールドを許可する) 双方のメッ セージタイプは、開始行(start-line)、一つ以上のヘッダーフィールド、ヘッ ダーフィールドの終了を示す空行、およびオプションのメッセージボディ (message-body)から成る。 generic-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line / Status-Line 開始行、各メッセージヘッダー行、および空行は、キャリッジリターン・ラ インフィードの並び(CRLF)で終わらなければならない[MUST]。メッセージボ ディが存在しないときでも、空行がなければならない[MUST]ことに注意する こと。 上記の文字セットの違いを除いて、SIPのメッセージ構文とヘッダーフィール ド構文のほとんどは、HTTP/1.1と同一である。ここで構文とセマンティクスを 繰り返すかわりに、現在のHTTP/1.1仕様(RFC2616参考文献[8])のセクションX.Y を参照するために[HX.Y]という表記を使用する。 しかしながら、SIPはHTTPの拡張ではない。 7.1 リクエスト SIPリクエストは開始行にRequest-Lineを持つことで、他と区別される。 Request-Lineは一つの空白文字(SP)で区切られた、メソッド名、Request-URI、 プロトコルバージョンを含む。 Request-LineはCRLFで終わる。行末のCRLFの並びを除いて、CRやLFは認めら れていない。どのエレメントにもリニアホワイトスペース(LWS)は認められて いない。 Request-Line = Method SP Request-URI SP SIP-Version CRLF メソッド: この仕様では6つのメソッドを定義する。コンタクトインフォ メーションを登録するためのREGISTER、セッションをセットアップ するためのINVITE、ACK、CANCEL、セッションを終了するためのBYE、 およびサーバーにその能力を問い合わせるためのOPTIONSである。 standards track RFCでドキュメント化されているSIP拡張は、付加 的なメソッドを定義するかもしれない。 Rosenberg, et. al. Standards Track [Page 27] RFC 3261 SIP: Session Initiation Protocol June 2002 Request-URI: Request-URIは、セクション19.1で述べられているSIP URI またはSIPS URI、あるいは通常のURI(RFC2396 参考文献[5])であ る。Request-URIは、このリクエストが宛てられたユーザーやサー ビスを示す。Request-URIはエスケープされていないスペースやコ ントロール文字を含んではならず[MUST NOT]、「<>」で囲んでも いけない[MUST NOT]。 SIPエレメントは、例えばRFC2806(参考文献[9])の「tel」URI(※) スキームのような「sip」および「sips」以外のスキームのRequest- URIをサポートしてもよい[MAY]。SIPエレメントは、結果的にSIP URI、SIPS URIまたはその他のスキームのどれかになるどのような 仕組みでも自由に使用して、非SIP URIを解釈してもよい[MAY]。 [※訳注: 「tel」URI は原文のまま。] SIP-Version: リクエストメッセージと応答メッセージは共に使用中の SIPのバージョンを含み、バージョンの順序付け、承諾条件、およ びバージョン番号のアップグレードに関して[H3.1]に従う(HTTPを SIPに、HTTP/1.1をSIP/2.0に置き換えて)。この仕様に準拠するた めに、SIPメッセージを送るアプリケーションは、SIP-Versionと して「SIP/2.0」を含まなければならない[MUST]。SIP-Versionの 文字列は大文字小文字を区別しないが、実装では大文字で送らな ければならない[MUST]。 HTTP/1.1とは違い、SIPはバージョン番号をリテラル文字列として 扱う。実際には、この点はたいして影響を与えないと思われる。 7.2 応答 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を検査したり表示したりする ことを要求されない。 この仕様はReason-Phraseのための特定の文章を提示するが、実装では、例え ばリクエストのAccept-Languageヘッダーフィールドで示されている言語で、 その他の文章を選択してもよい[MAY]。 Rosenberg, et. al. Standards Track [Page 28] RFC 3261 SIP: Session Initiation Protocol June 2002 Status-Codeの最初の桁は応答のクラスを定義する。最後の2桁にはカテゴリ 分けの役目はない。このため、100から199のあいだのどのステータスコード をもつ応答も「1xx応答]、200から299のあいだのどのステータスコードを持 つ応答も「2xx応答」(以下同様)、と呼ばれる。SIP/2.0では最初の桁に6つの 値が許可されている。 1xx: 暫定 -- リクエストが受信され、そのリクエストの処理を継続し ている。 2xx: 成功 -- アクションの受信が成功し、理解され、受け入れられた。 3xx: リダイレクト -- リクエストを完了するために、更なるアクショ ンを取る必要がある。 4xx: クライアントエラー -- リクエストが誤りのある構文を含む、また はこのサーバーではそのリクエストを実行できない。 5xx: サーバーエラー -- サーバーが、明らかに有効なリクエストの実 行に失敗した。 6xx: グローバルな失敗 -- リクエストはどのサーバーでも実行できな かった。 セクション21で、これらのクラスを定義し、それぞれのコードについて述べ る。 7.3 ヘッダーフィールド SIPのヘッダーフィールドは、構文とセマンティクスの双方においてHTTPのヘッ ダーフィールドとよく似ている。特に、SIPのヘッダーフィールドは[H4.2]の、 メッセージヘッダーの構文定義、および複数行に渡るヘッダーフィールドの ルールに従う。しかしながら、後者はHTTPでは、暗黙的なホワイトスペースと 折りたたみ(implicit whiteapace and folding)とともに規定されている。この 仕様では、RFC2234(参考文献[10])に準拠し、記述法に不可欠な部分として、 明示的なホワイトスペースと折りたたみ(explicit whitespace and folding) のみを使用する。 [H4.2]では、同じヘッダーフィールド名でカンマ区切りリストの値を持つ複 数のヘッダーフィールドが、一つのヘッダーフィールドに結合できることも 規定している。それはSIPにも適用されるが、記述法が異なるので細かいルー ルは異なる。具体的には、以下の形式の記述法のSIPヘッダーはすべて、 header = "header-name" HCOLON header-value *(COMMA header-value) 同じ名称のヘッダーフィールドをカンマ区切りリストで結合することが認め られている。Contactヘッダーフィールドは、そのヘッダーフィールド値が 「*」でない限り、カンマ区切りのリストが認められている。 Rosenberg, et. al. Standards Track [Page 29] RFC 3261 SIP: Session Initiation Protocol June 2002 7.3.1 ヘッダーフィールドの書式 ヘッダーフィールドは、RFC2822(参考文献[3])のセクション2.2で与えられて いるものと同じ一般的なヘッダーの書式に従う。各ヘッダーフィー ルドは、フィールド名とそれに続くコロン( : )およびフィールド値から成る。 field-name: field-value セクション25で規定されているメッセージヘッダーの正式な記述法では、コ ロンの前後に任意の数のホワイトスペースを認めている。しかしながら、実 装では、フィールド名とコロンの間にスペースを入れず、コロンとフィールド 値の間にスペースを1個(SP)使用するべきである。 Subject: lunch Subject : lunch Subject :lunch Subject: lunch すなわち、上記はすべて有効で同じ値であるが、最後のものが好ましい形式 である。 ヘッダーフィールドは、2行目以降の先頭に少なくとも1つのSPまたは水平タ ブ(HT)を置くことで、複数行に渡って記述できる。行が中断される個所と次 の行の先頭のホワイトスペースは1つのSP文字として扱われる。そのため、次 の2つは同じである。 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]。最初のフィールド値にその後の各フィールド値をカンマで区 切ってアペンドし、メッセージのセマンティクスを変えずに、複数のヘッダー フィールド列を一つの「field-name: field-value」のペアに結合することが 可能でなければならない[MUST]。このルールの例外は、WWW-Authenticate、 Authorization、Proxy-Authenticate、およびProxy-Authorizationヘッダー フィールドである。これらのフィールド名を持つ複数のヘッダーフィールド Rosenberg, et. al. Standards Track [Page 30] RFC 3261 SIP: Session Initiation Protocol June 2002 列は、メッセージ中に存在してもよい[MAY]が、それらの記述法はセクション7.3に リストされている一般的な形式に従わないので、それらは一つのヘッダー フィールド列に結合されてはならない[MUST NOT]。 実装では、1行に1つの値を持つ形式あるいはカンマ区切り値形式のどのよう な組み合わせによるものであれ、同じフィールド名を持つ複数のヘッダー フィールド列を処理できなければならない[MUST]。 以下のヘッダーフィールド列のグループは有効であり、かつ同じ値である。 Route: Subject: Lunch Route: Route: Route: , Route: Subject: Lunch Subject: Lunch Route: , , 以下の各ブロックは有効であるが、同じ値ではない。 Route: Route: Route: Route: Route: Route: Route: ,, ヘッダーフィールド値の書式は、ヘッダー名ごとに定義される。それは常 に、TEXT-UTF8オクテットの意味不明なシーケンスか、あるいはホワイトス ペース、トークン、セパレーター、引用符で囲まれた文字列の組み合わせの いずれかである。多くの既存のヘッダーフィールドは、値の一般的な書式と セミコロンで区切られてそれに続くパラメータ名(parameter-name)とパラメー タ値(parameter-value)のペアの連続である。 field-name: field-value *(;parameter-name=parameter-value) Rosenberg, et. al. Standards Track [Page 31] RFC 3261 SIP: Session Initiation Protocol June 2002 ヘッダーフィールド値には任意の個数のパラメータペアを付けることができ るが、与えられるどのパラメータ名も2回以上現れてはならない[MUST NOT]。 ヘッダーフィールドを比較するときは、フィールド名は常に大文字小文字を 区別しない。特定のヘッダーフィールドの定義で特に指定されない限り、 フィールド値、パラメータ名、パラメータ値は大文字小文字を区別しない。トー クンは常に大文字小文字を区別しない。特に規定がなければ、引用符で囲 まれた文字列として表現された値は大文字小文字を区別する。 例えば Contact: ;expires=3600 は以下と同等である。 CONTACT: ;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 ヘッダーフィールドの分類 いくつかのヘッダーフィールドはリクエストの中あるいは応答の中でのみ意 味をなす。これらはそれぞれ、リクエストヘッダーフィールド、応答ヘッダー フィールドと呼ばれる。ヘッダーフィールドがそのカテゴリーにマッチし ないメッセージ中に現れた場合(例えば、リクエストヘッダーフィールドが 応答中に)、それは無視されなければならない[MUST]。セクション20で、各ヘッ ダーフィールドの分類を定義している。 7.3.3 短縮形 SIPは、一般的なヘッダーフィールド名を省略された形で表す仕組みを提供 する。これは、メッセージが利用可能なトランスポート上で配送するには大き くなりすぎる可能性があるときに有用である(例えば、UDPを使用するときに MTUを超える)。これらの短縮形はセクション20で定義されている。メッセージ のセマンティクスを変えずることなく、いつでも長い形式のヘッダー名を短縮 形で置き換えしてもよい[MAY]。ヘッダー Rosenberg, et. al. Standards Track [Page 32] RFC 3261 SIP: Session Initiation Protocol June 2002 フィールド名は同一のメッセージ中に、長い形式と短縮形の両方が存在しても よい[MAY]。実装では、各ヘッダー名の長短の形式を双方共に受け入れなけれ ばならない[MUST]。 7.4 ボディ この仕様の拡張で定義される新規リクエストを含むすべてのリクエストは、 特に断りのない限り、メッセージボディを含めともよい[MAY]。ボディの 解釈はリクエストのメソッドに依存する。 応答メッセージでは、リクエストのメソッドと応答のステータスコードが、 あらゆるメッセージボディのタイプと解釈を決定する。すべての応答はボディ を含めてもよい[MAY]。 7.4.1 メッセージボディのタイプ メッセージボディのインターネットメディアタイプは、Content-Typeヘッダー フィールドで与えられなければならない[MUST]。もしボディが何らかのエン コーディングを施されていた場合(例えば圧縮など)、このことはContent- Encodingヘッダーフィールドで示されなければならない[MUST]。そうでない 場合はContent-Encodingは省略されなければならない[MUST]。妥当な場合に は、メッセージボディの文字セットがContent-Typeのヘッダーフィールド値 の一部として示される。 RFC2046(参考文献[11])で定義されている「multipart」というMIMEタイプは、 メッセージのボディ中で使用してもよい[MAY]。マルチパートのメッセージボディ を含むリクエストを送る実装は、セッション記述を非マルチパートのメッセー ジボディで送らなければならない[MUST](リモートの実装が、マルチパート を含まないAcceptヘッダーフィールドでこれを要求する場合)。 SIPのメッセージはバイナリのボディまたはボディの一部を含めてもよい [MAY]。明示的な文字セットのパラメータが送信側から提示されない場合、 「text」タイプのメディア・サブタイプは「UTF-8」の文字セットを初期値と して持つ。 7.4.2 メッセージボディの長さ ボディ長(バイト)はContent-Lengthヘッダーフィールドで提供される。セク ション20.14では、このヘッダーに必要なコンテンツについて詳細に述べてい る。 HTTP/1.1の「chunked」トランスファエンコーディング(transfer encoding) は、SIPで使用してはならない[MUST NOT]。(注意:chunkedエンコーディングは、 連続したchunkとしてボディを転送(transfer)するために(各chunkはそれ自身の サイズインジケーターを持つ)、メッセージのボディを修正する。) Rosenberg, et. al. Standards Track [Page 33] RFC 3261 SIP: Session Initiation Protocol June 2002 7.5 SIPメッセージのフレーム化 HTTPとは違い、SIPの実装はUDPあるいはその他の信頼性の低いデータグラム プロトコルを使用してもよい[MAY]。そのようなデータグラムはそれぞれ一つのリ クエストまたは応答を伝える。信頼性の低いトランスポートの使用時の制約 についてはセクション18参照のこと。 ストリーム指向のトランスポート上でSIPメッセージを処理する実装は、開始 行の前に現れるいかなるCRLFも無視しなければならない[MUST][H4.1]。 Content-Lengthヘッダーフィールド値は、ストリーム中で各SIPメッセー ジの終わりの位置を特定するために使用される。それは、SIPメッセー ジがストリーム指向のトランスポート上で送られるときにはいつでも 存在する。 8 ユーザーエージェントの一般的な動作 ユーザーエージェントはエンドシステムに相当する。それは、リクエストを 生成するユーザーエージェントクライアント(UAC)およびそれらのリクエスト に応答するユーザーエージェントサーバー(UAS)を含む。UACは、外部からの 刺激(ユーザーのボタンクリック、または PSTN ライン上の信号)に基づいて リクエストを生成したり、応答を処理することができる。UASは、リクエスト を受け取り、ユーザー入力、外部からの刺激、プログラム実行結果、あるい はその他の仕組みに基づいて、応答を生成することができる。 UACがリクエストを送るとき、それはいくつかのプロキシサーバーを通過する。 プロキシサーバーは UAS にそのリクエストを転送(forward)する。UASが応答を 生成するとき、その応答はUACに転送(forward)される。 UACおよびUASの処理手順は2つのファクターに強く依存している。一つは、リ クエストまたは応答がダイアログの内部にあるか外部にあるかということ。 2つめは、リクエストのメソッドに基づくということ。ダイアログについては セクション12で十分に議論する。それらは、ユーザーエージェント間のピア ツーピア リレーションシップに相当し、INVITEのような特定のSIPメソッド によって確立される。 このセクションでは、ダイアログの外部のリクエストを処理するときのUACお よびUASの動作のための、メソッドに依存しないルールについて議論する。こ れは当然、それ自身でダイアログを確立するリクエストを含む。 ダイアログ外のリクエストと応答のためのセキュリティ処理手順はセクショ ン26で述べられている。特に、UASとUACが相互に認証するために存在する仕組 みについてである。プライバシー機能の限定されたセットもS/MIMEを用いてボ ディを暗号化することでサポートされている。 Rosenberg, et. al. Standards Track [Page 34] RFC 3261 SIP: Session Initiation Protocol June 2002 8.1 UACの動作 このセクションでは、ダイアログ外のUACの動作を取り上げる。 8.1.1 リクエストの生成 UACによって作成された有効なSIPリクエストは、少なくとも次のヘッダーフィー ルドを含まなければならない[MUST]。To、From、CSeq、Call-ID、Max-Forwards、 およびVia。これらすべてのヘッダーフィールドは、全SIPリクエストに必須 である。これらの6つのヘッダーフィールドは、SIPメッセージの基本的な構成 単位である。その理由は、それらが連帯して、メッセージのアドレッシング、 応答のルーティング、メッセージの伝達(propagation)の制限、メッセージの 順番付け、およびトランザクションの一意な識別を含む、重要なメッセージ ルーティングサービスの大半を提供するからである。これらのヘッダー フィールドは、メソッド、Request-URI、およびSIPバージョンを含む必須の リクエスト行(request line)に加える。 ダイアログの外部で送られるリクエストの例には、セッションを確立する INVITE(セクション 13)および能力を問い合わせるOPTIONS(セクション 11)が 含まれる。 8.1.1.1 Request-URI メッセージの最初のRequest-URIには、ToフィールドのURIの値が設定される べきである[SHOULD]。注目に値する一つの例外は、REGISTERメソッドである。 REGISTERのRequest-URIを設定する動作はセクション10で与えられる。これら のフィールドに同じ値を設定することは、プライバシーのためあるいは利便 性のために望ましくないかもしれない(特に発信元のUAがRequest-URIが運搬 中に変更されることを期待する場合)。 ある特別な状況下では、既存のルートセットがメッセージのRequest-URIに影 響を及ぼすことがある。既存のルートセットとは、UACが外に向けて送り出す ダイアログ外リクエストの宛先となる、一連のサーバーを特定する順番に並 べられたURIセットである。一般に、それらはUA上でユーザーまたはサービス プロバイダによって、マニュアルあるいは他の非SIPの仕組みで設定され る。プロバイダがUAに アウトバウンドプロキシを設定することを望む場合、 それに一つのURI(アウトバウンドプロキシのもの)を持つ既存のルートセット を提供することで、それを行うことが推奨される[RECOMMENDED]。 既存のルートセットが存在する場合、(たとえダイアログがなくても、) リモートのターゲットURIとして望ましいRequest-URIを使用して、セクション 12.2.1.1に詳述されているRequest-URIとRouteヘッダーフィールドを組み 込むための手順に従わなければならない[MUST]。 Rosenberg, et. al. Standards Track [Page 35] RFC 3261 SIP: Session Initiation Protocol June 2002 8.1.1.2 To Toヘッダーフィールドは、まず、希望するリクエストの「論理的」な受信者、 またはこのリクエストのターゲットであるユーザーあるいはリソースの Address-of-Recordを指定する。これは、リクエストの最終的な受信者である かもしれないし、そうでないかもしれない。ToヘッダーフィールドはSIP URI またはSIPS URIを含めてもよい[MAY]が、妥当なときには、その他のURI スキーム(例えば、tel URL(RFC2806 参考文献[9]))を使用することもでき る。すべてのSIP実装はSIP URIスキームをサポートしなければならない[MUST]。 TLSをサポートするいかなる実装も、SIPS URIスキームをサポートしなければ ならない[MUST]。Toヘッダーフィールドは、表示名を考慮に入れている。 UACは、ある特定のリクエストのためのToヘッダーフィールドをどのように組 み込むか、様々な方法で知ることができる。通常、ユーザーがヒューマンイ ンターフェースを介して(おそらく、URIをマニュアルで入力するか、ある種 のアドレス帳から選択して)、Toヘッダーフィールドを提示する。高い頻度で、 ユーザーは完全なURIではなく数字や文字の列を入力するだろう(例えば、 「bob」)。この入力をどのように解釈するかはUAの判断による。その文字列 をSIP URIのユーザー部分を形成するために使用するということは、UAが名前 をドメイン内で解決してSIP URIのアットマークの右側を得ることを望むこと を暗に示す(例えば、sip:bob@example.com)。その文字列をSIPS URIのユー ザー部分を形成するために使用するということは、UAが、通信を安全に行い、 名前がドメイン内で解決されてアットマークの右側が得られることを望むこ とを暗に示す。アットマークの右側は高い頻度でリクエスト送信者のホーム ドメインであるだろう。このことは、そのホームドメインが外に送られるリク エストを処理することを認める。これは、ホームドメイン内でユーザー部分の 解釈が求められる、「スピードダイヤル」のような機能に対して有用である。 ユーザーによって入力された電話番号を解釈すべきドメインを指定することを UAが望まないとき、tel URLが使用されるかもしれない。そうすることで、リク エストが通過する各ドメインがその機会を与えられる。例えば、空港に いるユーザーは、空港のアウトバウンドプロキシにログインして、それを通 してリクエストを送るかもしれない。そのユーザーが「411」(これはアメリ カのローカル電話番号案内の番号である)を入力する場合、それは、ユーザー のホームドメインではなく、空港のアウトバウンドプロキシによって解釈さ れ処理される必要がある。この場合、「tel:411」が正しい選択である。 ダイアログ外のリクエストは、To tagを含んではならない[MUST NOT](リクエス トのToフィールドのtagは、ダイアログの相手を特定する)。ダイアログが確 立されていないので、tagは存在しない。 Toヘッダーフィールドについての詳細はセクション20.39を参照のこと。以下 は、有効なToヘッダーフィールドの例である。 To: Carol Rosenberg, et. al. Standards Track [Page 36] RFC 3261 SIP: Session Initiation Protocol June 2002 8.1.1.3 From Fromヘッダーフィールドは、リクエストを開始した者の論理的なアイデンティ ティを示す。これはおそらく、ユーザーのAddress-of-Recordであろう。To ヘッダーフィールドと同じように、URIおよびオプションとして表示名を含む。 それは、リクエストに適用するための処理ルールを決定するために、SIPエレ メントによって使用される(例えば、自動通話拒否)。このような場合、IP アドレスやホストのFQDNは論理的な名前ではないので、FromのURIがこれらを 含まないことが非常に重要である。 Fromヘッダーフィールドは表示名を考慮している。クライアントのアイデン ティティを隠したままにする場合、UACは「Anonymous」という表示名を、構文 的に正しいが意味を持たない(sip:thisis@anonymous.invalidのような)URIと 共に使用するべきである[SHOULD]。 通常、ある特定のUAによって生成されたリクエスト中のFromヘッダーフィー ルドに存在する値は、ユーザーあるいはユーザーのローカルドメインの管理 者によって、あらかじめ用意されている。ある特定のUAが複数のユーザーに 使用される場合、それは、ユーザーのアイデンティティに対応したURIを含む、 切り替え可能なプロファイルを持っているかもしれない。リクエストの受信 者は、リクエストの発信元がそのFromヘッダーフィールドが主張している者 であるということを確実にするために、リクエストの発信元を認証できる(認 証について詳しくは、セクション22参照のこと)。 Fromフィールドは、UACが選んだ新しいtagを含まなければならない[MUST]。 tagの選択について詳しくは、セクション19.3参照のこと。 Fromヘッダーフィールドに関しての詳細は、セクション20.20参照のこと。 例: From: "Bob" ;tag=a48s From: sip:+12125551212@phone2net.com;tag=887s From: Anonymous ;tag=hyh8 8.1.1.4 Call-ID Call-IDヘッダーフィールドは、連続するメッセージをグループ化するための 一意の識別子として作用する。それは、ダイアログ中のどのUAが送ったもの であれ、すべてのリクエストおよび応答において同じ値でなければならない [MUST]。それは、UAからの各登録においても同じ値であるべきである[SHOULD]。 すべてのダイアログの外部にあるUACによって生成された新規リクエストでは、 Call-IDヘッダーフィールドは、メソッド特有の動作でオーバーライドされな ければ、あらゆる時と場所においてグローバルに一意な値となるよう、UACが 選択しなければならない[MUST]。すべてのSIP UAは、それが作成するCall-ID ヘッダーフィールドが、他のいかなるUAによっても偶然に生成されないこと を保証する手段を持たねばならない。リクエストの修正を要請する特定の失 Rosenberg, et. al. Standards Track [Page 37] RFC 3261 SIP: Session Initiation Protocol June 2002 敗応答の後にリクエストを再試行するときは(例えば、認証に対するチャレ ンジ)、再試行されるリクエストが新規リクエストとみなされることはなく、 そのため新規Call-IDヘッダーフィールドは必要でない、ということに注意す ること。セクション8.1.3.5参照。 Call-IDの生成において、暗号的にランダムな識別子(RFC1750 参考文献[12]) の使用が推奨される[RECOMMENDED]。実装では、「localid@host」形式を使用 してもよい[MAY]。Call-IDは、大文字小文字を区別し、単純に各バイトごとに比 較される。 暗号的にランダムな識別子の使用は、セッションの乗っ取りに対するあ る種の防御を提供し、起こりうる意図しないCall-IDの衝突を減らす。 リクエストのCall-IDヘッダーフィールド値の選択のための準備やヒューマン インターフェースは必要とされない。 Call-IDヘッダーフィールドに関しての更なる情報は、セクション20.8参照の こと。 例: Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com 8.1.1.5 CSeq CSeqヘッダーフィールドは、トランザクションを識別し順番付けするための 手段としての役目を果たす。CSeqは、シーケンス番号とメソッドから成る。 メソッドは、リクエストのメソッドとマッチしなければならない[MUST]。 ダイアログ外の非REGISTERリクエストでは、シーケンス番号値は任意である。 シーケンス番号値は、32ビットの符号なし整数で表現可能でなければならず [MUST]、また、2**31未満でなければならない[MUST]。上記のガイドラインに 従う限り、クライアントはCSeqヘッダーフィールド値を選択するために、そ れが望むいかなる仕組みにおいても使用できる。 セクション12.2.1.1では、ダイアログ内のリクエストに対するCSeqの構築に ついて議論する。 例: CSeq: 4711 INVITE Rosenberg, et. al. Standards Track [Page 38] RFC 3261 SIP: Session Initiation Protocol June 2002 8.1.1.6 Max-Forwards Max-Forwardsヘッダーフィールドは、リクエストがデスティネーションに向 かう過程で通過することができるホップの数を制限するための役目を果たす。 Max-Forwardsは、各ホップで1ずつデクリメントされる整数からなる。リクエ ストがデスティネーションに到達する前にMax-Forwards値が0になった場合、 リクエストは483(Too Many Hops)エラー応答で拒否される。 UACはそれが発信する各リクエストに、値が70であるべき[SHOULD]Max-Forwards ヘッダーフィールドを挿入しなければならない[MUST]。この数は、ループが ないときにどのようなSIPネットワークにおいてもリクエストが却下されない だろうことを保証するが、ループが起こったときにプロキシのリソースを消 費するほど大きくはない、十分に大きな数として選択された。これよりも小 さな値は注意して、またUAがトポロジを知っているネットワークにおいて のみ使用されるべきである。 8.1.1.7 Via Viaヘッダーフィールドは、トランザクションのために使用されるトランスポー トを示し、また応答が送られることになる場所を特定する。Viaヘッダーフィー ルド値は、ネクストホップに到達するために使用されるトランスポートが 選択された後に追加される(これには参考文献[4]の手順の利用が関係するか もしれない)。 UACがリクエストを生成するとき、それはそのリクエストにViaを挿入しなけ ればならない[MUST]。ヘッダーフィールド中のプロトコル名とプロトコルバー ジョンは、それぞれSIPおよび2.0でなければならない[MUST]。Viaヘッダー フィールド値はbranchパラメータを含まなければならない[MUST]。このパラ メータはそのリクエストによって生成されたトランザクションを識別するた めに使用される。このパラメータはクライアントとサーバーの両方に利用さ れる。 branchパラメータ値は、そのUAによって送られるすべてのリクエストに対し て、あらゆる時と場所を通して一意でなければならない[MUST]。このルール の例外は、CANCELと非2xx応答に対するACKである。以下で議論されるように、 CANCELリクエストは、それがキャンセルするリクエストと同じbranchパラメー タ値を持つ。セクション17.1.1.3で議論するように、非2xx応答に対するACK は、INVITEと同じbranch IDを持つ(このINVITEに対する応答をACKは了承する)。 トランザクションIDとしてbranch IDパラメータを使用することを容易 にするための、branch IDパラメータの一意性の特性は、RFC2543の一部 ではなかった。 この仕様に準拠するエレメントによって挿入されたbranch IDは、常に文字列 「z9hG4bK」から始まらなければならない[MUST]。これら7つの文字は、リク エストを受け取るサーバーがbranch IDがこの仕様で述べられる方法で構築さ れたこと(すなわち、グローバルに一意であること)を確定できるように、マ ジッククッキーとして使用される(古いRFC2543の実装がこのような値を選択 しないことを確実にするために、7つで十分だと思われる)。この要求以上の、 Rosenberg, et. al. Standards Track [Page 39] RFC 3261 SIP: Session Initiation Protocol June 2002 branchトークンの細かい書式は実装が決める。 Viaヘッダーのmaddr、ttl、およびsent-byコンポーネントは、リクエストが トランスポートレイヤーで処理されるときに設定される(セクション18参照)。 プロキシのVia処理については、セクション16.6の項目8およびセクション16.7 の項目3で述べられている。 8.1.1.8 Contact Contactヘッダーフィールドは、これに続くリクエストでそのUAの特定のイン スタンスにコンタクトするために使用できるSIP URIまたはSIPS URIを提供 する。Contactヘッダーフィールドは、結果としてダイアログを確立することが できるすべてのリクエストの中に、正確に一つのSIPまたはSIPS URIを含んで 存在しなければならない[MUST]。この仕様で定義されているメソッドでは、 そういうリクエストにはINVITEリクエストのみが含まれる。これらのリクエ ストでは、Contactのスコープはグローバルである。すなわち、Contactヘッ ダーフィールド値は、UAがリクエストを受け取りたいと望むURIを含み、それ 以降のいかなるダイアログ外のリクエストで使用された場合でも、このURIは 有効でなければならない[MUST]。 Request-URIまたは最初のRouteヘッダー値がSIPS URIを含む場合、Contactヘッ ダーフィールドも同様にSIPS URIを含まなければならない[MUST]。 Contactヘッダーフィールドに関しての更なる情報は、セクション20.10参照 のこと。 8.1.1.9 Supported と Require UACが、サーバーが応答に適用できるSIPの拡張をサポートする場合、そのUAC は、それらの拡張のためのオプションタグ(セクション19.2)をリストした Supportedヘッダーフィールドをリクエストに含めるべきである[SHOULD]。 リストされたオプションタグは、標準化過程にあるRFC(standards track RFC) で定義された拡張のみを参照しなければならない[MUST]。これは、クライア ントがサービスを受けるために非標準のベンダーが定義したフィーチャーを 実装することを、サーバーが強要することを阻止するためである。experimental RFCやinformational RFCで定義された拡張は、それらもベンダーが定義した 拡張をドキュメント化するために使用されることが多いので、リクエストの Supportedヘッダーフィールドで使用することから明確に除外される。 UACが、リクエストを処理するためにそのリクエストに適用する拡張を、UAS が理解することを強要したいと望む場合、UACはその拡張のためのオプション タグをリストしたRequireヘッダーフィールドをリクエストに挿入しなければ ならない[MUST]。UACが、リクエストに拡張を適用することを望み、トラバー Rosenberg, et. al. Standards Track [Page 40] RFC 3261 SIP: Session Initiation Protocol June 2002 スされるすべてのプロキシがその拡張を理解することを強要したい場合、UAC はその拡張のためのオプションタグをリストしたProxy-Requireヘッダーフィー ルドをリクエストに挿入しなければならない[MUST]。 Supportedヘッダーフィールドと同じように、RequireおよびProxy-Requireヘッ ダーフィールドのオプションタグは、standards-track RFCで定義されてい る拡張のみを参照しなければならない[MUST]。 8.1.1.10 付加的なメッセージコンポーネント 新しいリクエストが生成され、上に述べられたヘッダーフィールドが適切に 構築された後に、メソッド固有のすべてのヘッダーフィールドの追加と同時 に、すべての付加的なオプションのヘッダーフィールドが追加される。 SIPリクエストは、MIMEエンコードされたメッセージボディを含めてもよい [MAY]。リクエストが含んでいるボディの種類に関わらず、ボディのコンテン ツを特徴付けるために、特定のヘッダーフィールドが作成されなければなら ない。これらのヘッダーフィールドに関しての更なる情報は、セクション 20.11から20.15を参照のこと。 8.1.2 リクエストの送信 その後、リクエストのデスティネーションが算出される。特にローカルポリ シーが規定されていなければ、以下に示すように参考文献[4]で述べられてい る手順でDNSを適用することによって、デスティネーションが確定されなけれ ばならない[MUST]。ルートセットの最初のエレメントがストリクトルーター を表す場合(セクション12.2.1.1で述べられるようにリクエストを形成するこ とになる)、リクエストのRequest-URIに手順が適用されなければならない[MUST]。 そうでなければ、手順は、リクエストの最初のRouteヘッダーフィールド値(存在す れば)に適用される、またはRouteヘッダーフィールドが存在しない場合は、 リクエストのRequest-URIに適用される。これらの手順は、順番に並べられた、 試行するアドレス、ポート、およびトランスポートのセットをもたらす。参 考文献[4]の手順に対する入力としてどのURIが使用されるかに依らず、Request- URIがSIPSリソースを指定する場合には、UACは入力されたURIがSIPS URIであ ったかのように参考文献[4]の手順に従わなければならない[MUST]。 ローカルポリシーは、試行するための別のデスティネーションのセットを規 定してもよい[MAY]。Request-URIがSIPS URIを含む場合、別のいかな るデスティネーションもTLSで接続されなければならない[MUST]。リクエスト がRouteヘッダーフィールドを含まなければ、別のデスティネーションにおけ るそれ以上の制約はない。これは、アウトバウンドプロキシを指定する方法と して、既存のルートセットに代わる単純な選択肢を提供する。しかしながら、 アウトバウンドプロキシを設定するためのそのアプローチは推奨されない[NOT RECOMMENDED]。一つのURIを持つ既存のルートセットがそれの代わりに使用さ れるべきである[SHOULD]。リクエストがRouteヘッダーフィールドを含む場 合、それの先頭の値から得られる場所にリクエストは送られるべきである [SHOULD]が、(RFC2543のものに反して)このドキュメントで規定されるRoute とRequest-URIのポリシーを守ることが確かだと UAが思うどのようなサーバー にも送ってもよい[MAY]。特に、アウトバウンドプロキシを設定されたUAC は、アウトバウンドプロキシにすべてのメッセージを送るというポリシー Rosenberg, et. al. Standards Track [Page 41] RFC 3261 SIP: Session Initiation Protocol June 2002 を採用する代わりに、最初のRouteヘッダーフィールド値で示される場所に リクエストを送ることを試みるべきである[SHOULD]。 これは、Record-Routeヘッダーフィールド値を追加しないアウトバウン ドプロキシが、これ以降のリクエストのパスから除外されることを確実 にする。それは、最初のRouteのURIを解決できないエンドポイントが、 そのタスクをアウトバウンドプロキシに委任することを可能にする。 UACは、サーバーにコンタクトするまで各アドレスを試行するという、ステー トフルエレメントのために参考文献[4]で定義されている手順に従うべきであ る[SHOULD]。それぞれの試行は新規トランザクションを構成し、そのためそ れぞれの試行は、新規branchパラメータを持った異なる先頭のViaヘッダー フィールド値を伝える。さらに、Viaヘッダーフィールドのtransport値には、 ターゲットサーバーに対して確定されたどのようなトランスポートでも設定さ れる。 8.1.3 応答の処理 応答は最初にトランスポートレイヤーで処理され、その後トランザクション レイヤーに上げられる(渡される)。トランザクションレイヤーはそれの処理 を行い、その後それをTUに上げる(渡す)。TUでの応答処理の大半はメソッド 固有である。しかしながら、メソッドに依存しないいくつかの一般的な動作 がある。 8.1.3.1 トランザクションレイヤーのエラー 場合によっては、トランザクションレイヤーから返された応答はSIPメッセー ジではなく、トランザクションレイヤーのエラーだろう。トランザクション レイヤーからタイムアウトエラーを受け取った場合、それは408(Request Timeout)ステータスコードを受け取ったかのように扱われなければならない [MUST]。トランスポートレイヤーから致命的なトランスポートエラーが報告 された場合(一般的に、UDPにおける致命的なICMPエラーまたはTCPにおける接 続失敗のため)、その状態は503(Service Unavailable)ステータスコードとし て扱われなければならない[MUST]。 8.1.3.2 認識できない応答 UACはそれが認識できないどのような最終応答でも、そのクラスのx00応答コー ドに相当するものとして扱わなければならなず[MUST]、すべてのクラスの x00応答コードを処理できなければならない[MUST]。例えば、UACが認識で きない応答コード431を受け取った場合、UACはそれのリクエストに何か問題 があったと安全に仮定し、その応答を400(Bad Request)応答コードを受け取 ったかのように処理できる。UACはそれが認識できない100以外のすべての暫 定応答を183(Session Progress)応答コードとして扱わなければならない[MUST]。 UACは100と183応答を処理できなければならない[MUST]。 Rosenberg, et. al. Standards Track [Page 42] RFC 3261 SIP: Session Initiation Protocol June 2002 8.1.3.3 複数の Via 応答の中に2つ以上のViaヘッダーフィールド値が存在する場合、UACはその メッセージを破棄するべきである[SHOULD]。 リクエストの発信元の前にある付加的なViaヘッダーフィールド値の存 在は、メッセージが間違ってルートされたか、あるいは壊れているこ とを示唆している。 8.1.3.4 3xx応答の処理 リダイレクト応答の受信時には(例えば、301応答ステータスコード)、クラ イアントはリダイレクトされたリクエストに基づいて一つ以上の新しいリク エストを作るために、ContactヘッダーフィールドのURIを使用するべきであ る[SHOULD]。この処理は、セクション16.5と16.6で述べられているように、 3xxクラス応答で再帰するプロキシの処理と似ている。クライアントは 正確に一つのURI(オリジナルリクエストのRequest-URI)を含む最初のターゲッ トセットで処理を開始する。クライアントがそのリクエストに対する3xxクラス 応答に基づく新規リクエストを作ることを望む場合、クライアントはター ゲットセットに、試行するURIを置く。この仕様の制限に従って、クラ イアントはターゲットセットにどのContactのURIを置くか選択できる。プロ キシの再帰と同様に、3xxクラス応答を処理するクライアントは、与えられた いかなるURIもターゲットセットに2回以上追加してはならない[MUST NOT]。 オリジナルリクエストがRequest-URIにSIPS URIを持っていた場合、クライア ントは非SIPS URIに再帰することを選択してもよい[MAY]が、安全ではないURI にリダイレクトすることをユーザーに通知するべきである[SHOULD]。 新規のどのようなリクエストでも、contactとしてオリジナルURIを含む 3xx応答を受け取るかもしれない。2つの場所をお互いにリダイレクトす るように設定することができる。与えられたいかなるURIでもターゲッ トセットに1回だけ置くことで、リダイレクションの無限ループを防げ る。 ターゲットセットが大きくなると、クライアントはそのURIに対してどのよう な順番でも新規リクエストを生成してもよい[MAY]。一般的な仕組み は、Contactヘッダーフィールド値からのqパラメータ値でターゲットセットを 並べ替えることである。それらのURIに対するリクエストは順次に(serially) あるいは並列的に(parallel)生成してもよい[MAY]。大きいものから小 さいものへq値のグループを順次に、そしてそれぞれのq値のグループのURIを 並行して処理することが一つのアプローチである。等しいq値のcontactのあ いだでは任意に選択を行い、q値の大きいものから小さいものの順番で順次処 理だけを実行することが、もう一つの別のアプローチである。 リストのアドレスへのコンタクトが失敗することになった場合、次のパラグ ラフで定義されるように、エレメントは、リストを使い切るまで、リストの 次のアドレスに移る。リストを使いきった場合、リクエストは失敗したこと になる。 Rosenberg, et. al. Standards Track [Page 43] RFC 3261 SIP: Session Initiation Protocol June 2002 失敗は失敗応答コード(399よりも大きいコード)を介して検出されるべきであ る[SHOULD]。ネットワークエラーに対してクライアントトランザクションは、 どのようなトランスポートレイヤーのエラーでもトランザクションユーザー に報告する。いくつかの応答コード(セクション8.1.3.5で詳述する)は、リク エストが再試行できることを示すことに注意すること。再試行されるリクエ ストは失敗とみなされるべきではない。 個々のcontactアドレスに対する失敗を受け取る場合、クライアントは次の contactアドレスを試すべきである[SHOULD]。これは、新規リクエストを配 送するために新規クライアントトランザクションの生成を引き起こす。 3xx応答中のcontactアドレスに基づいてリクエストを生成するために、UACは、 ターゲットセットからRequest-URIに、URIのmethod-paramとheaderパラメー タ(これらのパラメータの定義はセクション19.1.1参照のこと)を除き、すべ てのURIをコピーしなければならない[MUST]。それは、セクション19.1.5のガ イドラインに従って、新規リクエストのヘッダーフィールド値を生成するた めにheaderパラメータを、リダイレクトされたリクエストに関連付けられた ヘッダーフィールド値を上書きして使用する。 ある場合には、contactアドレスで伝えられたヘッダーフィールドが、リダイ レクトされたオリジナルリクエストに存在するリクエストヘッダーフィール ドの代わりに付加されるかも知れないということに注意すること。一般的な ルールとして、ヘッダーフィールドが値のカンマ区切りリストを受け入れる ことができる場合、新しいヘッダーフィールド値は、リダイレクトされたオ リジナルリクエストに存在するいかなる値にも付加してもよい[MAY]。ヘッダー フィールドが複数の値を受け入れない場合、リダイレクトされたオリジナルリ クエストの値は、contactアドレスで伝えられたヘッダーフィールド値で上書 きしてもよい[MAY]。例えば、contactアドレスが以下の値で返される場合、 sip:user@host?Subject=foo&Call-Info= リダイレクトされたオリジナルリクエストのどのようなSubjectヘッダーフィー ルドも上書きされるが、HTTP URLは既存のどのようなCall-Infoヘッダーフィー ルド値にも単に付加されるだけである。 UACはリダイレクトされたオリジナルリクエストで使われていたのと同じTo、 From、およびCall-IDを再利用することが推奨される[RECOMMENDED]が、UACは、 例えば新規リクエストのためにCall-IDヘッダーフィールド値をアップデー トすることも選択してもよい[MAY]。 最後に、新規リクエストが構築されるとすぐに、それは新しいクライアント トランザクション上で送られる。したがって、セクション8.1.1.7で議論され るように、最初のViaフィールドに新しいbranch IDを持たなければならない [MUST]。 Rosenberg, et. al. Standards Track [Page 44] RFC 3261 SIP: Session Initiation Protocol June 2002 その他のすべての点において、リダイレクト応答の受信によって送られるリ クエストは、オリジナルリクエストのヘッダーフィールドとボディを再利用 するべきである[SHOULD]。 ある場合には、Contactヘッダーフィールド値は、受け取ったステータスコー ドおよび有効期限間隔の存在に依存して、UACにおいて一時的あるいは恒久的 にキャッシュされるかもしれない。セクション21.3.2と21.3.3参照のこと。 8.1.3.5 4xx応答の処理 ある種の4xx応答コードは、メソッドに依存しない特定のUA処理を要求する。 401(Unauthorized)または407(Proxy Authentication Required)応答を受け取 った場合、UACは信用証明書(credentials)を持ったリクエストで再試行する ために、セクション22.2およびセクション22.3の認可手順に従うべきである [SHOULD]。 413(Request Entity Too Large)応答を受け取った場合(セクション21.4.11)、 リクエストは、UASが受け入れようとしたものよりも長いボディを含んでいた。 可能であれば、UACは、ボディを省略するかより短いボディを使用して、リク エストを再試行するべきである[SHOULD]。 415(Unsupported Media Type)応答を受け取った場合(セクション21.4.13)、 リクエストは、UASのサポートしないメディアタイプを含んでいた。UACは、 今度は応答中のAcceptヘッダーフィールドにリストされたタイプ、応答中の Accept-Encodingヘッダーフィールドにリストされたエンコーディング、およ び応答中のAccept-Languageにリストされた言語を含むコンテンツだけを使用 して、リクエストの送信を再試行するべきである[SHOULD]。 416(Unsupported URI Scheme)応答を受け取った場合(セクション21.4.14)、 Request-URIがサーバーのサポートしないURIスキームを使用した。クライア ントは、今度はSIP URIを使用して、リクエストを再試行するべきである[SHOULD]。 420(Bad Extension)応答を受け取った場合(セクション21.4.15)、リクエスト はプロキシまたはUASがサポートしないフィーチャーのオプションタグをリス トしたProxy-RequireまたはRequire[※訳注]ヘッダーフィールドを含んでいた。 UACは、今度は応答中のUnsupportedヘッダーフィールドにリストされたすべて の拡張を省略して、リクエストを再試行するべきである[SHOULD]。 [訳注: 原文では「Require or Proxy-Require」となっているが、 「プロキシまたはUAS」という文脈上、順序としては、「Proxy- RequireまたはRequire」が適切。SIP WGでも、これは誤読を招くも のとして認められている。] 上記のすべての場合において、適切な修正を加えた新規リクエストを生成す ることによって、リクエストは再試行される。この新規リクエストは新規の トランザクションを構成する。また、この新規リクエストは、この前に送ら れたリクエストと同じCall-ID、To、およびFromの値を持つべきである[SHOULD] が、CSeqは前回よりも一つ大きなシーケンス番号を含むべきである。 [訳注: 「この新規リクエストは」以降の文は元々は1つの文だが、SHOULDの かかる部分がまぎらわしくなるので、2文に分けた。] Rosenberg, et. al. Standards Track [Page 45] RFC 3261 SIP: Session Initiation Protocol June 2002 まだ定義されていないものも含めその他の4xx応答では、メソッドと使用場面 によって、リトライが可能かもしれないし可能でないかもしれない。 8.2 UASの動作 ダイアログの外部のリクエストがUASによって処理されるとき、メソッドに依 存しない、従うべき処理ルールのセットがある。セクション12で、リクエス トがダイアログの内部にあるか外部にあるかをUASがどのように判断するかに ついての手引きを与える。 リクエスト処理は分割できないことに注意すること。リクエストが受け入れ られるとき、それに関連付けられるすべてのステートの変更が行われなけれ ばならない[MUST]。それが拒否される場合は、すべてのステート変更は実行 されてはならない[MUST NOT]。 UASはこのセクションのこれ以降に書かれているステップの順番でリクエスト を処理するべきである[SHOULD](すなわち、認証から始めて、次にメソッド、 ヘッダーフィールドなどこのセクションの残りの部分全体を通して書かれて いることを検査する)。 8.2.1 メソッド検査 いったんリクエストが認証されると(または認証がスキップされると)、UASは リクエストのメソッドを検査しなければならない[MUST]。UASがリクエストの メソッドを認識したがサポートしていない場合は、405(Method Not Allowed) 応答を生成しなければならない[MUST]。応答の生成のための手順はセクショ ン8.2.6で述べられている。UASは405(Method Not Allowed)応答にAllowヘッ ダーフィールドも加えなければならない[MUST]。Allowヘッダーフィールドは、 メッセージを生成するUASがサポートしているメソッドのセットをリストしな ければならない[MUST]。Allowヘッダーフィールドについてはセクション20.5 で述べられている。 そのメソッドがサーバーによってサポートされているものであれば、処理は 継続する。 8.2.2 ヘッダー検査 UASがリクエスト中のヘッダーフィールドを理解しない(すなわち、そのヘッ ダーフィールドがこの仕様またはサポートされるいかなる拡張でも定義され ていない)場合、サーバーはそのヘッダーフィールドを無視し、メッセージの 処理を継続しなければならない[MUST]。UASはリクエストの処理に必要ではな いすべての変形ヘッダーを無視するべきである[SHOULD]。 8.2.2.1 ToとRequest-URI Toヘッダーフィールドは、Fromフィールドで特定されるユーザーが指定した、 リクエストのオリジナル受信者を特定する。コール転送(forward)、または他の プロキシによる処理があるため、オリジナル受信者がリクエストを処理するUAS かどうかわからない。UASは、ToフィールドがそのUASと同一でないときにリ Rosenberg, et. al. Standards Track [Page 46] RFC 3261 SIP: Session Initiation Protocol June 2002 クエストを受け取るかどうか決定するために、それが望むどのようなポリシー でも適用してもよい[MAY]。しかしながら、UASは、Toヘッダーフィールド中の URIスキーム(例えばtel: URI)(※)を認識できない場合、あるいはToヘッ ダーフィールドがそのUASの既知または現在のユーザーに宛てられたもので ない場合でも、リクエストを受け取ることが推奨される[RECOMMENDED]。 その一方で、UASがリクエストを拒否することにした場合、403(Forbidden)ス テータスコード応答を生成し、それをトランスミッションのためにサーバー トランザクションに渡すべきである[SHOULD]。 [※訳注: tel: URI は原文のまま。] 一方、Request-URIはリクエストを処理するUASを特定する。Request-URIが、 UASのサポートしないスキームを使用する場合、UASはそのリクエストを416 (Unsupported URI Scheme)応答で拒否するべきである[SHOULD]。UASはあるア ドレスに対してのリクエストを受け入れることを望むが、Request-URIがその アドレスと同じでない場合、UASは404(Not Found)応答でリクエストを拒否す るべきである[SHOULD]。一般的に、特定のコンタクトアドレスに自身の Address-of-RecordをバインドするためにREGISTERメソッドを使用するUAは、 そのコンタクトアドレスに等しいRequest-URIを持つリクエストを受ける。受 け取るRequest-URIの、可能性のあるその他のソースには、ダイアログを確立 またはリフレッシュする、そのUAが送るリクエストと応答のContactヘッダー フィールドが含まれる。 8.2.2.2 マージされたリクエスト リクエストがToヘッダーフィールドにtagを持たない場合、UASコアは進行中 のトランザクションに対してそのリクエストを確認しなければならない[MUST]。 From tag、Call-ID、CSeqが進行中のトランザクションに関連付けられている ものと正確に一致するが、リクエストはトランザクションにマッチしない (セクション17.2.3のマッチングルールに基づいて)場合、UASコアは482 (Loop Detected)応答を生成してそれをサーバートランザクションに渡すべき である[SHOULD]。 同じリクエストが異なるパスを通って(最も可能性が高いのはフォーク によって)UASに2度以上到着した。UASは受け取ったそのようなリクエス トの最初のものを処理し、残りのものに対しては482(Loop Detected)で 応答する。 8.2.2.3 Require UASがそれがリクエストを処理する適切なエレメントであると判断する、と仮 定すると、それはRequreヘッダーフィールド(もし存在すれば)を吟味する。 Requireヘッダーフィールドは、リクエストを適切に処理するためにUASがサ ポートすることをUACが期待するSIP拡張について、UASに知らせるためにUAC が使用する。Requireヘッダーフィールドの書式はセクション20.32 で述べられている。Requireヘッダーフィールドにリストされているoption- tagをUASが理解しない場合、それはステータスコード420(Bad Extension)応 答を生成して応答しなければならない[MUST]。UASはUnsupportedヘッダー フィールドを追加し、リクエストのRequireヘッダーフィールドの中で理解 できなかったオプションをその中にリストしなければならない[MUST]。 Rosenberg, et. al. Standards Track [Page 47] RFC 3261 SIP: Session Initiation Protocol June 2002 RequireとProxy-Requireは、SIPのCANCELリクエスト、または非2xx応答に対 するACKリクエストで使用してはならない[MUST NOT]ことに注意すること。こ れらのヘッダーフィールドは、これらのリクエスト中に存在した場合には無 視されなければならない[MUST]。 2xx応答に対するACKリクエストは、最初のリクエストに存在したRequireと Proxy-Requireの値のみを含まなければならない[MUST]。 例: UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0 Require: 100rel UAS->UAC: SIP/2.0 420 Bad Extension Unsupported: 100rel この動作はクライアントとサーバーのやりとり(interaction)が、双方 にすべてのオプションが理解されたときは遅滞なく進行し、(上記の例 のように)オプションが理解されなかったときにのみスローダウンする ということを確実にする。うまく適合したクライアントとサーバーのペ アでは、ネゴシエーションの仕組みによく必要とされるラウンドトリッ プを節約し、やりとりはすばやく進行する。それに加えて、それは、 サーバーが理解できないフィーチャーをクライアントが要求したときの あいまいさも除去する。呼操作フィールド(call handling field)のよう ないくつかの機能は、エンドシステムにのみ関係がある。 8.2.3 コンテンツの処理 UASがクライアントに要求されたすべての拡張を理解できると仮定すると、UAS はメッセージのボディとそれを記述するヘッダーフィールドを吟味する。そ のタイプ(Content-Typeで示される)、言語(Content-Languageで示される)、 あるいはエンコーディング(Content-Encodingで示される)を理解できないボ ディがあり、そのボディ部分がoptional(Content-Dispositionで示される)で なければ、UASは415(Unsupported Media Type)応答でそのリクエストを拒否 しなければならない[MUST]。リクエストが、UASがサポートしないタイプのボ ディを含んだ場合、応答は、それが理解できるすべてのタイプのボディをリ ストしたAcceptヘッダーフィールドを含まなければならない[MUST]。リクエ ストが、UASが理解できないコンテンツのエンコーディングを含んだ場合、応 答は、UASが理解できるエンコーディングをリストしたAccept-Encodingヘッ ダーフィールドを含まなければならない[MUST]。リクエストが、UASが理解で きない言語のコンテンツを含んだ場合、応答は、UASが理解できる言語を示す Accept-Languageヘッダーフィールドを含まなければならない[MUST]。これ以 上のチェックについては、ボディの操作はメソッドとタイプ固有である。コ ンテンツ固有のヘッダーフィールド処理に関しての更なる情報は、セクショ ン7.4およびセクション20.11から20.15を参照のこと。 Rosenberg, et. al. Standards Track [Page 48] RFC 3261 SIP: Session Initiation Protocol June 2002 8.2.4 拡張の適用 応答を生成する際にある種の拡張の適用を望むUASは、その拡張のサポートが、 リクエスト中のSupportedヘッダーフィールドで示されない場合は、そうして はならない[MUST NOT]。希望する拡張がサポートされていない場合、サーバー はベースラインSIPおよびクライアントがサポートするその他の拡張だけに 頼るべきである[SHOULD]。拡張なしではサーバーがリクエストを処理できな いという稀な状況において、そのサーバーは421(Extension Required)応答を 送ってもよい[MAY]。この応答は、特定の拡張のサポートがないと適切な 応答を生成できないことを示す。必要とされる拡張は、応答のRequireヘッダー フィールドに含まれなければならない[MUST]。この動作は、通常、相互運 用性を取れなくするので推奨されていない[NOT RECOMMENDED]。 非421応答に適用されるすべての拡張は、その応答に含まれるRequireヘッダー フィールドにリストされなければならない[MUST]。当然、サーバーはリク エストのSupportedヘッダーフィールドにリストされていない拡張を適用して はならない[MUST NOT]。この結果として、応答中のRequireヘッダーフィール ドはstandards track RFCで定義されているオプションタグのみを含むことに なる。 8.2.5 リクエストの処理 これ以前のサブセクションのチェックをすべてパスしたと仮定すると、UASの 処理はメソッド固有のものになる。セクション10ではREGISTERリクエスト、 セクション11ではOPTIONSリクエスト、セクション13ではINVITEリクエスト、 そしてセクション15ではBYEリクエストを扱う。 8.2.6 応答の生成 UASが、リクエストに対する応答を構築したいときは、この後のサブセクショ ンで詳述されている手順に従う。 このセクションで詳述されていない、該当する応答コードに固有の付加的な 動作も必要とされるかもしれない。 応答の生成に関連するすべての手順が完了するとすぐに、UASはその応答をリ クエストを受け取ったサーバートランザクションに返す。 8.2.6.1 暫定応答の送信 応答の生成のための、メソッドに非固有の主たるガイドラインは、UASは 非INVITEリクエストに対して暫定応答を発行するべきではない[SHOULD NOT] ということである。UASはむしろ、非INVITEリクエストに対して可能な限り早 く最終応答を返すべきである[SHOULD]。 Rosenberg, et. al. Standards Track [Page 49] RFC 3261 SIP: Session Initiation Protocol June 2002 100(Trying)応答が生成されるとき、リクエストに存在するいかなるTimestamp ヘッダーフィールドもこの100(Trying)応答にコピーされなければならない [MUST]。応答の生成に遅延が発生する場合、UASは応答のTimestamp値にdelay 値を追加するべきである[SHOULD]。この値はリクエストの受信と応答の送信 のあいだの時間差を、秒単位で含まなければならない[MUST]。 8.2.6.2 ヘッダーとタグ 応答のFromフィールドはリクエストのFromヘッダーフィールドと等しくなけ ればならない[MUST]。応答のCall-IDヘッダーフィールドはリクエストの Call-IDヘッダーフィールドと等しくなければならない[MUST]。応答のCSeqヘッ ダーフィールドはリクエストのCSeqフィールドと等しくなければならない [MUST]。応答のViaヘッダーフィールド値はリクエストのViaヘッダーフィー ルド値に等しくなければならず[MUST]、同じ並び順を維持しなければならな い[MUST]。 リクエストがTo tagを含んだ場合、応答のToヘッダーフィールドはリクエス トのものと等しくなければならない[MUST]。しかしながら、リクエストのTo ヘッダーフィールドがtagを含まなかった場合は、応答のToヘッダーフィール ドのURIはそのToヘッダーフィールドのURIに等しくなければならない[MUST]。 それに加えて、UASは応答のToヘッダーフィールドにtagを追加しなければな らない[MUST](100(Trying)応答は例外とする。これにはtagがあってもよい [MAY])。このことは、おそらくはダイアログIDのコンポーネントをもたらすこ とによって、応答するUASを特定する役に立つ。同じtagがそのリクエストに対 するすべての応答(最終と暫定の両方)に使用されなければならない[MUST](前 と同じく100(Trying)を例外とする)。tagの生成手順はセクション19.3で定義 されている。 8.2.7 ステートレスUASの動作 ステートレスUASとはトランザクションステートを保持しないUASのことであ る。それは通常どおりリクエストに返答するが、応答が送られた後にUASが通 常は保持するいかなるステートも破棄する。ステートレスUASがリクエストの 再送を受け取る場合、それは、単にリクエストの最初のインスタンスに返答 するかのように、応答を再度生成して再び送る。リクエストが同一の場合、 メソッドに対するリクエスト処理が常に同じ応答という結果にならない限り、 UASはステートレスではありえない。これは、例えば、ステートレス登録サー バーを除外する。ステートレスUASはトランザクションレイヤーを使用しない。 ステートレスUASはトランスポートレイヤーから直接リクエストを受け取り、 トランスポートレイヤーに直接応答を送る。 ステートレスUASの役割は、チャレンジ応答が発行される認証されていないリ クエストを操作するために、主に必要とされる。もしも、認証されていないリ クエストがステートフルに操作されると、認証されていない悪意のある大量の リクエストが、効果的にDoS攻撃状態を作り出し、UASの呼処理をスローダウン Rosenberg, et. al. Standards Track [Page 50] RFC 3261 SIP: Session Initiation Protocol June 2002 または完全に止めてしまうかもしれない大量のトランザクションステートを生 成することがありうる。詳細はセクション26.1.5参照のこと。 ステートレスUASの最も重要な動作は以下である。 o ステートレスUASは暫定応答(1xx)を送ってはならない[MUST NOT]。 o ステートレスUASは応答を再送してはならない[MUST NOT]。 o ステートレスUASはACKリクエストを無視しなければならない[MUST]。 o ステートレスUASはCANCELリクエストを無視しなければならない[MUST]。 o 応答に対してToヘッダーtagがステートレスな方法で生成されなけれ ばならない[MUST](同じリクエストに対しては同じtagを一貫して生成 するやり方で)。tagの生成についての情報はセクション19.3参照のこ と。 他のすべての点において、ステートレスUASはステートフルUASと同じように 動作する。UASはそれぞれの新規リクエストに対して、ステートフルまたはス テートレスのいずれかのモードで動作できる。 8.3 リダイレクトサーバー あるアーキテクチャではリダイレクションによって、リクエストをルート する役目があるプロキシサーバーの処理負荷を減らし、シグナリングパスの 堅牢性を向上させることが望ましいかもしれない。 リダイレクションは、サーバーがリクエストのためのルーティング情報を応 答に含めてクライアントに差し戻すことを認める。それによって、リクエス トのターゲットの場所を特定することを手助けするにもかかわらず、それ自 身をこのトランザクションの今後のメッセージングのループから除外する。 リクエストの発信元がリダイレクションを受け取ったときは、受け取ったURI に基づいて新規リクエストを送る。URIをネットワークのコアからエッジに伝 播することにより、リダイレクションはかなりのネットワークスケーラビリ ティを認める。 リダイレクトサーバーは論理的に、サーバートランザクションレイヤーと、 ある種のロケーションサービスにアクセス権を持つ、トランザクションユー ザーから構成される(登録サーバーとロケーションサービスの詳細についてはセ クション10参照)。このロケーションサービスは事実上、一つのURIとそのURI のターゲットを探すことができる一つ以上の選択可能な場所のセットとのあ いだのマッピング情報を含むデータベースである。 リダイレクトサーバーはそれ自身でいかなるSIPリクエストも発行しない。 CANCEL以外のリクエストを受け取った後で、サーバーはそのリクエストを拒 Rosenberg, et. al. Standards Track [Page 51] RFC 3261 SIP: Session Initiation Protocol June 2002 否するか、ロケーションサービスから選択可能な場所のリストを収集し、ク ラス3xxの最終応答を返す。整形式(well-formed)CANCELリクエストでは、2xx 応答を返すべきである[SHOULD]。この応答はSIPトランザクションを終了する。 リダイレクトサーバーはSIPトランザクション全体を通してトランザクション ステートを保持する。リダイレクトサーバー間の転送(forward)のループを検 知するのはクライアントの義務である。 リダイレクトサーバーがリクエストに対して3xx応答を返すとき、それは Contactヘッダーフィールドに(一つ以上の)選択可能な場所のリストを入れ込 む。Contactヘッダーフィールド値のexpiresパラメータも、Contactデータの 生存期間を示すために供給することができる。 Contactヘッダーフィールドは、試行するための新しい場所またはユーザー名 を与えるURIを含むか、あるいは単に付加的なトランスポートパラメータを指 定することができる。301(Moved Permanently)応答または302(Moved Temporarily) 応答も最初のリクエストでターゲットとされたのと同じ場所とユーザー名を 与えることができるが、試行するための別のサーバーまたはマルチキャスト アドレスのような付加的なトランスポートパラメータ、あるいはSIPトランス ポートのUDPからTCP(あるいはその逆)への変更を指定する。 しかしながら、リダイレクトサーバーはRequest-URIのURIと同じURIにリクエ ストをリダイレクトしてはならない[MUST NOT]。そのかわりに、そのURIが自 分自身を指すものでない場合には、サーバーはリクエストをデスティネーショ ンURIにプロキシしてもよい[MAY]。または、404で拒否してもよい[MAY]。 クライアントがアウトバウンドプロキシを使用しており、そのプロキシ が実際にはリクエストをリダイレクトする場合、無制限にリダイレクト がループする可能性が出てくる。 Contactヘッダーフィールド値はオリジナルにコールしたものとは別のリソー スも参照してもよい[MAY]ということに注意すること。例えば、PSTNゲートウェ イに接続されたSIPコールは、「おかけになった電話番号は変更されました」 というような特別な通知を配送する必要があるかもしれない。 Contact応答ヘッダーフィールドは、SIP URIに制限されずに、着呼側パーティー に到達できる場所を示す適切などのようなURIでも含むことができる。例え ば、電話番号、FAX、ircを表すURI(それらが定義されていれば)、または mailto:(RFC2368 参考文献[32])のURLを含むこともありうる。セクション26. 4.4では、SIPS URIを非SIPS URIにリダイレクトすることの意味と制限につい て議論する。 Contactヘッダーフィールド値のexpiresパラメータは、URIがどのくらいのあ いだ有効かを示す。expiresは秒を表す数字である。このパラメータが提供さ れていない場合、URIがどれだけのあいだ有効かは、Expiresヘッダーフィー ルドの値が決定する。おかしな値は3600に等しい値として扱われるべきであ る[SHOULD]。 Rosenberg, et. al. Standards Track [Page 52] RFC 3261 SIP: Session Initiation Protocol June 2002 これは適度なレベルで、このヘッダーフィールドに絶対時間を認めてい たRFC2543との下位互換性を提供する。絶対時間を受け取った場合、そ れはおかしな値として扱われ、3600に初期化される。 リダイレクトサーバーは、理解できないフィーチャー(理解不能なヘッダー フィールド、Requireの未知のすべてのオプションタグ、またはメソッド名さえ も含む)を無視したうえで、当該リクエストのリダイレクションを進めなけれ ばならない[MUST]。 9 リクエストのキャンセル 前のセクションでは、リクエストの生成、およびあらゆるメソッドのリクエ ストに対する応答を処理するための一般的なUAの動作について議論した。こ のセクションでは、CANCELと呼ばれる汎用メソッドについて議論する。 その名称が示すように、CANCELリクエストは、クライアントから送られたそ れ以前のリクエストをキャンセルするために使用される。具体的には、それ はUASにリクエストの処理を中止してそのリクエストに対してエラー応答を生 成するように依頼する。CANCELは、UASがすでに最終応答を与えたリクエスト には何ら影響しない。このためそれは、応答するのにサーバーが長時間を要 するリクエストをキャンセルするのにもっとも有用である。この理由により CANCELは、応答を生成するのに長時間を要するINVITEリクエストに対しても っとも有用である。この用法では、INVITEに対するCANCELリクエストを受け 取るUAS(まだINVITEに対する最終応答を送っていない)は、呼び出し音を鳴ら すのストップしてから、特定のエラー応答(487)でINVITEに応答することにな る。 CANCELリクエストは、プロキシとユーザーエージェントクライアント双方で 構築し送ることができる。セクション15では、どのようなコンディションで UACがINVITEをCANCELするか、セクション16.10では、プロキシでのCANCELの 使用法を議論する。 ステートフルプロキシは、ダウンストリームエレメントから受け取る応答を 単に転送(forward)するのではなく、CANCELに対して応答する。そのため、 CANCELは各ステートフルプロキシで応答されるので、「ホップバイホップ」 リクエストと呼ばれる。 9.1 クライアントの動作 CANCELリクエストはINVITE以外のリクエストをキャンセルするために送るべ きではない[SHOULD NOT]。 INVITE以外のリクエストは即座に応答されるので、非INVITEリクエスト に対して CANCEL を送ることは常に競合状態(race condition)を作り 出すことになるだろう。 Rosenberg, et. al. Standards Track [Page 53] RFC 3261 SIP: Session Initiation Protocol June 2002 CANCELリクエストを構築するために以下の手順が用いられる。CANCELリクエ スト中のRequest-URI、Call-ID、To、CSeqの数字部分、Fromヘッダーフィール ドは、tagも含めて、キャンセルされるリクエストに含まれるものと同じでな ければならない[MUST]。クライアントが構築したCANCELは、キャンセルされ るリクエストの最初のVia値にマッチする、ただ一つのViaヘッダーフィール ド値を持たなければならない[MUST]。これらのヘッダーフィールドに同じ値 を使用することは、CANCELを、それがキャンセルするリクエストにマッチン グすることを可能にする(セクション9.2で、そのようなマッチングがどのよ うに行われるか示す)。しかしながら、CSeqヘッダーフィールドのメソッド部 分は、CANCELの値を持たなくてはならない[MUST]。これは、それがそれ自身 の権限を持ったトランザクションとして識別され処理されることを認める(セ クション17参照)。 キャンセルされるリクエストがRouteヘッダーフィールドを含む場合、CANCEL リクエストはそのRouteヘッダーフィールドの値を含まなければならない[MUST]。 これはステートレスプロキシがCANCELリクエストを適切にルートするた めに必要とされる。 CANCELリクエストはいかなるRequireあるいはProxy-Requireヘッダーフィー ルドも含んではならない[MUST NOT]。 CANCELが構築されるとすぐに、クライアントは、キャンセルされるリクエス ト(ここでは、オリジナルリクエストと呼ぶ)に対する何らかの応答(暫定また は最終)を受け取っているかどうか調べるべきである[SHOULD]。 暫定応答を一つも受け取っていなければ、CANCELリクエストを送ってはなら ない[MUST NOT]。むしろ、クライアントは、そのリクエストを送る前に暫定 応答の到着を待たなくてはならない[MUST]。オリジナルリクエストがすでに 最終応答を生成している場合、CANCELはすでに最終応答を生成したリクエス トに影響を与えないため、それは有効なノーオペレーション命令(no-op)であ るので、CANCELを送るべきではない[SHOULD NOT]。クライアントがCANCELを 送ることを決定するとき、それはCANCELのためのクライアントトランザクショ ンを生成し、それにデスティネーションアドレス、ポート、トランスポートと 共にCANCELリクエストを渡す。CANCELのためのデスティネーションアドレス、 ポート、トランスポートは、オリジナルリクエストを送るために使用 されたものと同じでなければならない[MUST]。 もし、前に送ったリクエストに対する応答を受け取る前にCANCELを送る ことが許可されていたとしたら、サーバーが、オリジナルリクエストを 受け取る前に、CANCELを受信することが起こりうる。 オリジナルリクエストおよびCANCELトランザクションに関連するトランザク ションは共に独自に完了するということに注意すること。しかしながら、リ クエストをキャンセルするUACがオリジナルリクエストに対する487(Request Terminated)応答を受け取ることに頼ることはできない(RFC2543に準拠する UASはそのような応答を生成しないので)。オリジナルリクエストに対する最 終応答が64*T1秒(T1はセクション17.1.1.1で定義されている)以内にない場合、 Rosenberg, et. al. Standards Track [Page 54] RFC 3261 SIP: Session Initiation Protocol June 2002 クライアントは、オリジナルトランザクションがキャンセルされたとみなす べきであり[SHOULD]、オリジナルリクエストを操作するクライアントトランザ クションを破棄するべきである[SHOULD]。 9.2 サーバーの動作 CANCELメソッドは、サーバー側のTUがペンディング中のトランザクションを キャンセルすることを要求する。TUはCANCELリクエストを取得し、リクエス トのメソッドがCANCELまたはACK以外の何かであると仮定して、セクション 17.2.3のトランザクションマッチング手順を適用して、キャンセルされる トランザクションを決定する。マッチするトランザクションがキャンセル されるトランザクションである。 サーバーでのCANCELリクエスト処理は、サーバーのタイプに依存する。ステー トレスプロキシはそれを転送(forward)するだろう。ステートフルプロキシは それに応答してそれ自身でいくつかのCANCELリクエストを生成するかもしれ ない。またUASはそれに応答するだろう。プロキシでのCANCELの扱いについて はセクション16.10参照のこと。 UASは最初に、セクション8.2に述べられている一般的なUAS処理に従って CANCELリクエストを処理する。しかしながら、CANCELリクエストはホップバ イホップであり、再サブミットできないので、Authorizationヘッダーフィー ルドに適切な信用証明書を得るためにサーバーがチャレンジすることはでき ない。CANCELリクエストはRequireヘッダーフィールドを含まないことにも注 意すること。 上記の手順に従ってCANCELにマッチするトランザクションをUASが見つけられ なかった場合、UASはCANCELに対して481(Call Leg/Transaction Does Not Exist)で応答するべきである[SHOULD]。オリジナルリクエストに対するトラ ンザクションがまだ存在する場合、CANCELリクエスト受信時のUASの動作は、 それがオリジナルリクエストに対して既に最終応答を送ってしまったかどう かに依存する。最終応答を送ってしまった場合、CANCELリクエストは、オリ ジナルリクエストの処理にも、いかなるセッションステートにも、オリジナ ルリクエストに対して生成された応答にも何ら影響を与えない。UASがオリジ ナルリクエストに対して最終応答を発行していなかった場合、その動作はオ リジナルリクエストのメソッドに依存する。オリジナルリクエストがINVITE だった場合、UASはINVITEに対して直ちに487(Request Terminated)で応答す るべきである[SHOULD]。CANCELリクエストは、この仕様で定義される他の どのメソッドとのトランザクション処理にも、影響を与えない。 CANCELが既存のトランザクションにマッチする限り、オリジナルリクエスト のメソッドに関係なく、UASはCANCELリクエスト自体に200(OK)応答で答える。 この応答は、CANCELに対する応答のTo tagとオリジナルリクエストに対する 応答のTo tagが同じであるべきである[SHOULD]ということに注意して、セク ション8.2.6で述べられている手順に従って構築される。CANCELに対する 応答はトランスミッションのためにサーバートランザクションに渡される。 Rosenberg, et. al. Standards Track [Page 55] RFC 3261 SIP: Session Initiation Protocol June 2002 10 登録 10.1 概要 SIPは発見能力(discovery capability)を提供する。ユーザーが他のユーザー とセッションを開始することを望む場合、SIPは、着呼側ユーザーに到達でき る現在のホストを発見しなければならない。この発見処理は、リクエストを 受け取る責任を負い、ユーザーの場所についての知識に基づいてそれを どこに送るか決定し、それをそこに送る、プロキシサーバーおよびリダイレ クトサーバーのようなSIPのネットワークエレメントによって達成されること が多い。これを行うために、SIPのネットワークエレメントは、特定のドメイ ンのためにアドレスのバインディングを提供するロケーションサービスとし て知られる抽象サービスを調べる。これらのアドレスバインディングは、送 られてきたSIP URIまたはSIPS URI(例えば、sip:bob@Biloxi.com)を何らか の形で希望するユーザーに「近い」一つ以上のURI(例えば、sip:bob@engin eering.Biloxi.com)にマップする。つまるところ、プロキシは、希望する受 信者が現在いるユーザーエージェントに、受け取ったURIをマップするロケー ションサービスを調べることになる。 登録は、特定のドメインのためのロケーションサービス内に、Address-of- RecordのURIと一つ以上のコンタクトアドレスを関連付けるバインディングを 生成する。したがって、そのドメインのためのプロキシがRequest-URIが Address-of-Recordにマッチするリクエストを受け取るとき、そのプロキシは リクエストを、そのAddress-of-Recordに登録されているコンタクトアドレス に転送(forward)する。一般的に、あるドメインのロケーションサービスに Address-of-Recordを登録することは、そのAddress-of-Recordに対するリク エストがそのドメインにルートされるときにのみ意味をなす。ほとんどの場 合、これは登録のドメインがAddress-of-RecordのURIのドメインにマッチす る必要があることを意味する。 ロケーションサービスのコンテンツを確定するための方法がいろいろとある。 一つの方法は、管理上のものである。上記の例では、企業データベースへの アクセスを通して、Bobがエンジニアリング部門のメンバーであることがわか る。その一方で、SIPは、バインディングを明確に生成するために、UAのため の仕組みを提供する。この仕組みは登録として知られている。 登録は、登録サーバーとして知られる特別なタイプのUASにREGISTERリクエス トを送ることを必要とする。登録サーバーは、ドメインのためのロケーショ ンサービスのフロントエンドとして動作し、REGISTERリクエストのコンテン ツに基づいてマッピングを読み書きする。このロケーションサービスはそれ から、そのドメインへのリクエストをルーティングする責任を負うプロキシ サーバーによって調べられる。 登録処理全体の図解は図2で与えられている。登録サーバーとプロキシサー バーは、ネットワーク上の一つのデバイスで務めることができる論理的な役 割であることに注意すること。明確化のために、これらの2つのサーバーは Rosenberg, et. al. Standards Track [Page 56] RFC 3261 SIP: Session Initiation Protocol June 2002 図では分割されている。これら2つのサーバーが別々のエレメントの場合、UA は登録サーバーに到達するためにプロキシサーバーを介してリクエストを送 るかもしれない。 SIPはロケーションサービスを実装するための特定の仕組みを指示しない。 唯一の要求は、あるドメインのための登録サーバーはロケーションサービス へのデータを読み書きできなければならず[MUST]、そのドメインのためのプ ロキシまたはリダイレクトサーバーはそのデータを読むことができなければ ならない[MUST]ということである。登録サーバーは、同じドメインのための 特定のSIPプロキシサーバーと同じ場所に配置してもよい[MAY]。 10.2 REGISTERリクエストの構築 REGISTERリクエストはバインディングを追加、削除、問い合わせを行う。 REGISTERリクエストはAddress-of-Recordと一つ以上のコンタクトアドレスの あいだの新規バインディングを追加できる。特定のAddress-of-Recordのため の登録は適切に認可されたサードパーティが実行することができる。クライ アントは以前のバインディングを削除したり、あるAddress-of-Recordに対し てどのバインディングが現在適当かを決定するために問い合わせを行うこと もできる。 述べられたこと以外は、REGISTERリクエストの構築とREGISTERリクエストを 送るクライアントの動作は、セクション8.1とセクション17.1で述べられてい る一般的なUACの動作と同一である。 REGISTERリクエストはダイアログを確立しない。UACはREGISTERリクエストに、 セクション8.1で述べられている既存のルートセットに基づくRouteヘッダー フィールドを含めてもよい[MAY]。Record-Routeヘッダーフィールドは REGISTERリクエストまたは応答において何ら意味を持たず、存在した場合に は無視されなければならない[MUST]。特に、UACはREGISTERリクエストに対す るいかなる応答中のRecord-Routeヘッダーフィールドの存在/不在に基づいて も、新しいルートセットを生成してはならない[MUST NOT]。 以下のヘッダーフィールドは、Contactを除いて、REGISTERリクエストに含め なければならない[MUST]。Contactヘッダーフィールドは含めてもよい[MAY]。 Request-URI: Request-URIは、登録が行われるロケーションサービスの ドメインを示す(例: sip:chicago.com)。SIP URIのuserinfoと@コ ンポーネントが存在してはならない[MUST NOT]。 To: Toヘッダーフィールドは、登録が生成、問い合わせ、あるいは修正 されるAdress-of-Recordを含む。ToヘッダーフィールドとRequest- URIフィールドは、前者がユーザーネームを含むので通常は異なる。 このAddress-of-RecordはSIP URIまたはSIPS URIでなければなら ない[MUST]。 Rosenberg, et. al. Standards Track [Page 57] RFC 3261 SIP: Session Initiation Protocol June 2002 From: Fromヘッダーフィールドは、登録を行う人のAddress-of-Record を含む。リクエストがサードパーティによる登録でなければ、こ の値はToヘッダーフィールドと同じである。 Call-ID: UACからのすべての登録は、特定の登録サーバーに送られる登 録に対して、同じCall-IDヘッダーフィールド値を使用するべきで ある[SHOULD]。 同一のクライアントが異なるCall-ID値を使用した場合、登録サー バーは、遅延したREGISTERリクエストが順番が狂って到着したの か、あるいはそうでないのか検知できない。 CSeq: CSeq値はREGISTERリクエストの適切な並び順を保証する。UAは、 同じCall-IDを持つ各REGISTERリクエストに対してCSeq値を1ずつ インクリメントしなければならない[MUST]。 Contact: REGISTERリクエストは、アドレスバインディングを含むゼロ 個以上の値を持つContactヘッダーフィールドを含めてもよい[MAY]。 UAは、登録サーバーから以前に送った登録への最終応答を受け取るか、以前 のREGISTERリクエストがタイムアウトするまで、新たな登録(すなわち、再送 とは違い新しいContactヘッダーフィールド値を含む)を送ってはならない [MUST NOT]。 Renberg, et. al. Standards Track [Page 58] RFC 3261 SIP: Session Initiation Protocol June 2002 bob +----+ | UA | | | +----+ | |3)INVITE | carol@chicago.com chicago.com +--------+ V +---------+ 2)Store|Location|4)Query +-----+ |Registrar|=======>| Service|<=======|Proxy|sip.chicago.com +---------+ +--------+=======>+-----+ A 5)Resp | | | | | 1)REGISTER| | | | +----+ | | UA |<-------------------------------+ cube2214a| | 6)INVITE +----+ carol@cube2214a.chicago.com carol 図2: REGISTER の例 以下のContactヘッダーパラメータはREGISTERリクエストにおいて特別な意味 を持つ。 action: RFC2543からのactionパラメータは反対されている。UACは actionパラメータを使用するべきではない[SHOULD NOT]。 expires: expiresパラメータは、どれだけの期間バインディングが有効 であってほしいとUAが望むかを示す。値は秒を表す数字である。 このパラメータが提供されない場合、Expiresヘッダーフィールド の値が代わりに使用される。実装では、2**32-1(4294967295秒ま たは136年)よりも大きい値を2**32-1と等しい値として扱っても よい[MAY]。おかしな値は3600と等しい値として扱うべきである [SHOULD]。 10.2.1 バインディングの追加 登録サーバーに送られたREGISTERリクエストはAddress-of-Recordに対する SIPリクエストが転送(forward)されるべき[SHOULD]コンタクトアドレス(一つま たは複数)を含む。Address-of-Recordは、REGISTERリクエストのToヘッダー フィールドに含まれる。 Rosenberg, et. al. Standards Track [Page 59] RFC 3261 SIP: Session Initiation Protocol June 2002 リクエストのContactヘッダーフィールド値は一般的に特定のSIPエンドポイ ントを特定するSIP URIまたはSIPS URIからなる(例えば、sip:carol@cube 2214a.chicago.com)が、どのようなURIスキームでも使用してもよい[MAY]。SIP UA は、例えば、電話番号(tel URLで。RFC2806 参考文献[9])またはEメールア ドレス(mailto: URLで。RFC2368 参考文献[32])をAddress-of-Recordに対す るContactとして選択することができる。 例えば、Carol(Address-of-Recordがsip:carol@chicago.com)は、chicago. comドメインの登録サーバーに登録するだろう。彼女の登録はその後、chicago. comドメインのプロキシサーバーによってCarolのAddress-of-Recordに対する リクエストを彼女のSIPエンドポイントにルートするために使用されるだろう。 クライアントがいったん登録サーバーでバインディングを確立すると、それ は必要に応じて、既存のバインディングに対する新しいバインディングまた は修正を含む登録を送ってもよい[MAY]。REGISTERリクエストに対する 2xx応答は、この登録サーバーでこのAddress-of-Recordに対して登録されて いるバインディングの完全なリストをContactヘッダーフィールドに含む。 REGISTERリクエストのToヘッダーフィールドのAddress-of-RecordがSIPS URI の場合、そのリクエストのすべてのContactヘッダーフィールド値もSIPS URI であるべきである[SHOULD]。クライアントは、SIPS Address-of-Recordの下 には非SIPS URIだけを登録するべきである(コンタクトアドレスで示されるリ ソースのセキュリティが他の方法で保証されているときは)。これは、SIP以 外のプロトコルを呼び出すURIか、またはTLS以外のプロトコルで安全を確保 されているSIPデバイスに当てはまるかもしれない。 登録はすべてのバインディングをアップデートする必要がない。一般的に、 UAはそれ自身のコンタクトアドレスだけをアップデートする。 10.2.1.1 Contactアドレスの有効期限間隔の設定 クライアントがREGISTERリクエストを送るとき、クライアントはどれだけの あいだ登録が有効であってほしいと望むかを示す有効期限間隔を提案してもよ い[MAY](セクション10.3で述べられているように、登録サーバーはそれ自身 のローカルポリシーに基づいて実際の時間間隔を選択する)。 クライアントがバインディングの有効期限間隔を提案することができる二つ の方法がある。ExpiresヘッダーフィールドあるいはContactヘッダーのexpires パラメータを通してである。後者は、一つのREGISTERで二つ以上のバインディ ングが与えられたときに、バインディングごとに有効期限間隔を提案する ことを可能にし、一方、前者は、expiresパラメータを含まないすべての Contactヘッダーフィールド値のための有効期限間隔を提案する。 Rosenberg, et. al. Standards Track [Page 60] RFC 3261 SIP: Session Initiation Protocol June 2002 REGISTERに、提案される有効期限時間を表現するいずれの仕組みも存在 しない場合、クライアントはサーパーに選択させるという要望を示して いる。 10.2.1.2 Contactアドレス間のプリファレンス REGISTERリクエストで二つ以上のContactが送られる場合、登録を行うUAはこ れらのContactヘッダーフィールド値の中のすべてのURIをToフィールドに存 在するaddress-of-recordに関連付けることを意図している。このリストは、 Contactヘッダーフィールド中のqパラメータで優先順位付けできる。qパラ メータは、このaddress-of-recordに対する他のバインディングと比べて、 個々のContactヘッダーフィールド値に対する相対的なプリファレンスを示す。 セクション16.6で、プロキシサーバーがこのプリファレンス値をどのように 使用するかについて述べる。 10.2.2 バインディングの削除 登録はソフトステートであり、リフレッシュされなければ期限切れになるが、 明示的に削除することもできる。クライアントは、セクション10.2.1で述べ られるように登録サーバーによって選択された有効期限間隔に、影響を与え ることを試みることができる。UAはREGISTERリクエスト中のコンタクトアド レスに0という有効期限間隔を指定することで、バインディングの即時削除を 要求する。バインディングがその有効期限間隔が経過する前に削除されるこ とが可能なように、UA はこの仕組みをサポートするべきである[SHOULD]。 REGISTER固有のContactヘッダーフィールド値である「*」は、すべての登録 に適用されるが、Expiresヘッダーが0という値で存在しなければ使用しては ならない[MUST NOT]。 Contactヘッダーフィールド値「*」の使用は、登録を行うUAが、ある Address-of-Recordに関連付けられたすべてのバインディングを、それ らの正確な値を知ることなく、削除することを可能にする。 10.2.3 バインディングの取得 REGISTERリクエストに対する成功応答は、リクエストがContactヘッダーフィー ルドを含んでいたかどうかに関わらず、既存のバインディングの完全なリ ストを含む。REGISTERリクエストに Contactヘッダーフィールドが存在しな かった場合、バインディングのリストは変更されない。 10.2.4 バインディングのリフレッシュ それぞれのUAは、それが以前に確立したバインディングをリフレッシュする 責任を負う。UAは、他のUAによってセットアップされたバインディングをリ フレッシュするべきではない[SHOULD NOT]。 Rosenberg, et. al. Standards Track [Page 61] RFC 3261 SIP: Session Initiation Protocol June 2002 登録サーバーからの200(OK)応答は、現在のすべてのバインディングを列挙す るContactフィールドのリストを含む。UAは、セクション19.1.4の比較ルール を使用して、各コンタクトアドレスがそのUAが生成したものかどうかを確認 するために比較を行う。そのUAが生成したものであれば、expiresパラメータ または(それがなければ)Expiresフィールド値に従って、有効期限時間間 隔をアップデートする。UAはそれから、それの各バインディングに対して、 有効期限間隔が経過する前に、REGISTERリクエストを発行する。UAは、いく つかのアップデートを一つのREGISTERリクエストにまとめてもよい[MAY]。 UAは、一つのブートサイクルのあいだ、すべての登録に対して同一のCall-ID を使用するべきである[SHOULD]。登録のリフレッシュは、リダイレクトした のでなければ、オリジナルの登録と同じネットワークアドレスに送られるべ きである[SHOULD]。 10.2.5 内部クロックの設定 REGISTERリクエストへの応答がDateヘッダーフィールドを含む場合、クライ アントは何らかの内部クロックを設定するための現在時間を知るために、こ のヘッダーフィールドを使用してもよい[MAY]。 10.2.6 登録サーバーの発見 UAは登録を送るアドレスを決定するために3つの方法を使用できる。あらかじ め設定することによって、Address-of-Recordを使用することによって、およ びマルチキャストによってである。この仕様の適用範囲外の方法で、UAに登 録サーバーのアドレスを設定することができる。設定済みの登録サーバーア ドレスがない場合、UAはRequest-URIとしてAddress-of-Recordのホスト部分 を使い、通常のSIPサーバーの位置特定の仕組み(参考文献[4])を使用して、 リクエストをそこに送るべきである[SHOULD]。例えば、ユーザー(sip:carol @chicago.com)のUAは、REGISTERリクエストをsip:chicago.com に宛てて送る。 最後に、UAはマルチキャストを使用するように設定できる。マルチキャスト による登録は、「すべてのSIPサーバー」のwell-knownマルチキャストアドレ スであるsip.mcast.net(IPv4では224.0.1.75)に宛てて送られる。IPv6のwell- knownマルチキャストアドレスはまだ割り当てられていない。この割り当ては 必要になったときにドキュメント化されるだろう。SIP UAはそのアドレスを リッスンして他のローカルユーザーの場所を認識するために使用してもよい[MAY] (参考文献[33]参照)。しかしながら、それらはリクエストに応答しない。 マルチキャストによる登録は、例えば複数の会社が同一のLANを共有 するような、ある種の環境では適切ではない。 10.2.7 リクエストの送信 いったんREGISTERメソッドが構築され、メッセージのデスティネーションが 特定されたら、UACはREGISTERをトランザクションレイヤーに渡すために、セ クション8.1.2で述べられている手順に従う。 Rosenberg, et. al. Standards Track [Page 62] RFC 3261 SIP: Session Initiation Protocol June 2002 REGISTERに対する応答が得られなかったためにトランザクションレイヤーが タイムアウトエラーを返す場合、UACは同じ登録サーバーにすぐに再試行する べきではない[SHOULD NOT]。 即時再試行もまたタイムアウトする可能性が高い。タイムアウトを引き 起こした状況が正されるための理にかなう時間だけ待つことは、ネット ワーク上の不要な負荷を軽減する。特定の時間間隔は指示されていない。 10.2.8 エラー応答 UAが423(Interval Too Brief)応答を受け取る場合、UAは、REGISTERリクエス トのすべてのコンタクトアドレスの有効期限間隔を423(Interval Too Brief) 応答のMin-Expiresヘッダーフィールドの有効期限間隔以上にした後で、登 録を再試行してもよい[MAY]。 10.3 REGISTERリクエスト処理 登録サーバーは、REGISTERリクエストに応答し、それの管理ドメイン内のプ ロキシサーバーとリダイレクトサーバーがアクセス可能なバインディングの リストを保持するUASである。登録サーバーは、セクション8.2とセクション 17.2に従ってリクエストを操作するが、REGISTERリクエストのみを受け入れ る。登録サーバーは6xx応答を生成してはならない[MUST NOT]。 登録サーバーは必要に応じてREGISTERリクエストをリダイレクトしてもよ い[MAY]。登録サーバーにとって一般的な一つの用法は、マルチキャスト REGISTERリクエストを登録サーバー自身のユニキャストインターフェースに 302(Moved Temporarily)応答でリダイレクトするために、マルチキャストイ ンターフェースをリッスンすることだろう。 登録サーバーは、REGISTERリクエストにRecord-Routeヘッダーフィールドが 含まれていた場合には、それを無視しなければならない[MUST]。登録サーバー は、REGISTERリクエストに対するいかなる応答にもRecord-Routeヘッダー フィールドを含めてはならない[MUST NOT]。 REGISTERを未知のリクエストとして扱い、Record-Routeヘッダーフィー ルド値を追加したプロキシサーバーをトラバースしたリクエストを、登 録サーバーが受け取るかもしれない。 登録サーバーはそれがバインディングを保持するドメインのセットを知って いなければならない(例えば、設定することによって)。REGISTERリクエス トは登録サーバーに受け取られた順番に処理されなければならない[MUST]。 REGISTERリクエストはまた、非分割的に処理されなければならない[MUST]。 つまり、個々のREGISTERリクエストは完全に処理されるか、あるいはまった く処理されないかのいずれかである。各REGISTERメッセージは、他のいかな る登録またはバインディングの変更からも独立して処理されなければな らない[MUST]。 Rosenberg, et. al. Standards Track [Page 63] RFC 3261 SIP: Session Initiation Protocol June 2002 REGISTERリクエストを受け取るとき、登録サーバーは以下のステップにした がう。 1. 登録サーバーは、Request-URIで識別されるドメインのためのバイ ンディングにアクセスできるかどうか確定するために Request-URI を検査する。アクセスできず、かつ、登録サーバーがプロキシサー バーとしても動作する場合、登録サーバーは、セクション16で 述べられているメッセージをプロキシするための通常の動作にし たがって、宛先にされているドメインにリクエストを転送(forward) するべきである[SHOULD]。 2. 登録サーバーがすべての必要な拡張をサポートすることを保証す るために、登録サーバーはセクション8.2.2でUASのために述べら れているようにRequireヘッダーフィールド値を処理しなければな らない[MUST]。 3. 登録サーバーはUACを認証するべきである[SHOULD]。SIPユーザー エージェントの認証のための仕組みはセクション22に述べら れている。登録の動作は、SIPのための通常の認証フレームワーク を決してオーバーライドしない。認証仕組みが利用できない 場合、登録サーバーは、リクエストの発信元のアイデンティティ を主張するものとしてFromのアドレスを採用してもよい[MAY]。 4. 登録サーバーは、認証されたユーザーがこのAddress-of-Recordに 対する登録を修正することが認可されているかどうか確定するべ きである[SHOULD]。例えば、登録サーバーは、ユーザーがバイ ンディングを修正するための認可を持つAddress-of-Recordのリス トにユーザー名をマップした認可データベースを調べるかもしれ ない。認証されたユーザーがバインディングを修正することを認 可されていない場合、登録サーバーは403(Forbidden)を返して残 りのステップをスキップしなければならない[MUST]。 サードパーティによる登録をサポートするアーキテクチャでは、 一つのエンティティが、複数のAddress-of-Recordに関連付けられ た登録をアップデートする責任を負うかもしれない。 5. 登録サーバーはリクエストのToヘッダーフィールドからAddress- of-Recordを抽出する。Address-of-RecordがRequest-URIのドメイ ンに対して有効でない場合、登録サーバーは404(Not Found)応答 を送って残りのステップをスキップしなければならない[MUST]。 それからそのURIは正規化形式(canonical form)に変換されなけれ ばならない[MUST]。そうするために、(user-param を含む)すべて のURIパラメータが削除されなければならない[MUST]。そしてエス ケープされたいかなるキャラクタもエスケープされていない形に変 換されなければならない[MUST]。その結果はバインディングリスト へのインデックスとして役に立つ。 Rosenberg, et. al. Standards Track [Page 64] RFC 3261 SIP: Session Initiation Protocol June 2002 6. 登録サーバーはリクエストがContactヘッダーフィールドを含むか どうか確認する。含まれていなければ、最後のステップまでスキッ プする。Contactヘッダーフィールドが存在する場合、登録サー バーは、特別な値「*」とExpiresフィールドを含む一つのContact フィールド値があるかどうか確認する。リクエストが追加のContact フィールドまたはゼロ以外の有効期限時間を持つ場合、リクエス トは無効であり、登録サーバーは400(Invalid Request)を返して 残りのステップをスキップしなければならない[MUST]。持たない 場合には、登録サーバーは、Call-IDがそれぞれのバインディング に対して保存してある値と合致するかどうか確認する。合致しな い場合、登録サーバーはそのバインディングを削除しなければな らない[MUST]。合致する場合、登録サーバーはリクエストのCSeq がそのバインディングのために保存されている値よりも大きいと きにのみ、そのバインディングを削除しなければならない[MUST]。 そうでなければ、アップデートは中止されなければならず[MUST]、 また、リクエストは失敗する。 7. 登録サーバーは、Contactヘッダーフィールドの各コンタクトアド レスを順番に処理する。各アドレスに対して、登録サーバーは以 下のように有効期限間隔を決定する。 - フィールド値がexpiresパラメータを持っている場合、その値を 要求された有効期限として扱わなければならない[MUST]。 - そのようなパラメータはないがリクエストがExpiresヘッダー フィールドを持つ場合、その値を要求された有効期限として扱わ なければならない[MUST]。 - どちらもない場合、ローカルで設定されている初期値を要求され た有効期限として扱わなければならない[MUST]。 登録サーバーは要求された有効期限間隔よりも有効期限を短くする ように選択してもよい[MAY]。要求された有効期限間隔がゼロより大き く、かつ(AND)1時間未満で、かつ(AND)登録サーバーで設定されて いる最小値よりも小さい場合にのみ、登録サーバーは423(Interval Too Brief)応答で登録を拒否してもよい[MAY]。この応答は、登録サー バーが受け取ることを望む有効期限間隔の最小値を示すMin-Expires ヘッダーフィールドを含まなければならない[MUST]。それから残り のステップをスキップする。 登録サーバーが登録間隔(registration interval)を設定すること を認めることは、登録サーバーが保持することを必要とするステー トを制限し、登録が古くなる可能性を減らす一方で、過剰に頻 繁な登録のリフレッシュから登録サーバーを保護する。登録の有 効期限間隔は、サービスの生成において頻繁に使用される。一つ の例は、あるターミナルでユーザーが短時間のあいだだけ有効で あるときの、follow-meサービスである。したがって、登録サーバー は短期間の登録を受け入れるべきである。リクエストは、その間隔 があまりにも短いためにリフレッシュが登録サーバーのパフォーマ ンスを落とす場合にのみ、拒否されるべきである。 Rosenberg, et. al. Standards Track [Page 65] RFC 3261 SIP: Session Initiation Protocol June 2002 それから、各アドレスに対して、登録サーバーはURI比較ルールを 使用して現在のバインディングのリストを検索する。バインディ ングが存在しない場合、それは仮に追加される。バインディング が存在する場合、登録サーバーはCall-ID値を確認する。既存のバ インディング中のCall-ID値がリクエストのCall-ID値と異なる場 合、そのバインディングは、有効期限時間がゼロであれば削除さ れ、そうでなければアップデートされなければならない[MUST]。 Call-ID値が同じ場合、登録サーバーはCSeq値を比較する。CSeq値 が既存のバインディングのものより大きい場合、それは上記のよ うにバインディングをアップデートするか削除しなければならな い[MUST]。大きくない場合、アップデートは中止されなければな らず[MUST]、そのためリクエストは失敗する。 このアルゴリズムは、同一のUAからくる順番が狂ったリクエスト が無視されることを確実にする。 各バインディングレコードは、リクエストからCall-IDとCSeq値を 記録する。 バインディングのアップデートは、バインディングのすべてのアッ プデートと追加が成功する場合にだけ、コミットされなければ ならない[MUST](すなわち、プロキシまたはリダイレクトサーバー から見えるようにされる)。一つでも失敗した場合(例えば、バッ クエンドデータベースのコミットが失敗したため)、リクエスト は500(Server Error)応答で失敗しなければならず[MUST]、すべて の仮のバインディングアップデートは削除されなければならない [MUST]。 8. 登録サーバーは200(OK)応答を返す。応答は現在のすべてのバイン ディングを列挙するContactヘッダーフィールド値を含まなければ ならない[MUST]。各Contact値は、登録サーバーによって選択され た有効期限間隔を示すexpiresパラメータを含まなければならない [MUST]。応答はDateヘッダーフィールドを含むべきである[SHOULD]。 11 能力の問い合わせ SIPメソッドのOPTIONSは、UAが、他のUAまたはプロキシサーバーにそれの能 力を問い合わせることを許可する。これは、クライアントが、相手を呼び出 さずに(without ringing)サポートされているメソッド、コンテントタイプ、 拡張、CODECなどについての情報を発見することを可能にする。例えば、ク ライアントがINVITEに、デスティネーションのUASがサポートしているという 確証がないオプションをリストしたRequireヘッダーフィールドを挿入する前 に、そのクライアントは、このオプションがSupportedヘッダーフィールドで 返されるかどうか知るために、デスティネーションのUASにOPTIONSで問い合 わせることができる。すべてのUAはOPTIONSメソッドをサポートしなければな らない[MUST]。 OPTIONSリクエストのターゲットは、Request-URIによって特定される(Request- URIは他のUAまたはSIPサーバーを特定することができる)。OPTIONSがプロキ シサーバーに宛てて送られる場合、Request-URIは、それがREGISTERリクエス トに対して設定される方法と同じように、ユーザー部分なしで設定される。 Rosenberg, et. al. Standards Track [Page 66] RFC 3261 SIP: Session Initiation Protocol June 2002 あるいは、Max-Forwardsヘッダーフィールドの値が0でOPTIONSリクエストを 受け取るサーバーは、Request-URIに関係なくそのリクエストに応答してもよい[MAY]。 この動作はHTTP/1.1では一般的である。この動作は、インクリメントさ れたMax-Forwards値で連続してOPTIONSリクエストを送ることによって、 個々のホップサーバーの能力を確認するための「traceroute」機能とし て使用することができる。 一般的なUA動作の場合のように、トランザクションレイヤーは、OPTIONSが何 の応答も生み出さない場合にタイムアウトエラーを返すことができる。これ は、ターゲットは到達不可能でそれゆえ利用できないということを示すかも しれない。 OPTIONSリクエストは、確立されたダイアログで後ほど使用できる能力を相手 に問い合わせるために、そのダイアログの一部として送ってもよい[MAY]。 11.1 OPTIONSリクエストの構築 OPTIONSリクエストは、セクション8.1.1で議論したSIPリクエストのための標 準ルールを使用して構築される。 OPTIONSの中にContactヘッダーフィールドが存在してもよい[MAY]。 UACが応答で受け取りたいと望むメッセージボディのタイプを示すために、 Acceptヘッダーフィールドが含まれるべきである[SHOULD]。一般的に、これ は、UAのメディア能力(例えばSDP(application/sdp))を記述するために使 用される書式に設定される。 OPTIONSリクエストに対する応答は、オリジナルリクエストのRequest-URIが 適用範囲にされると仮定される。しかしながら、確立されたダイアログの一 部としてOPTIONSが送られるときにのみ、今後のリクエストがOPTIONSに対す る応答を生成したサーバーに受け取られることが保証される。 OPTIONSリクエストの例: OPTIONS sip:carol@chicago.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 Max-Forwards: 70 To: From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 OPTIONS Contact: Accept: application/sdp Content-Length: 0 Rosenberg, et. al. Standards Track [Page 67] RFC 3261 SIP: Session Initiation Protocol June 2002 11.2 OPTIONSリクエストの処理 OPTIONSに対する応答は、セクション8.2.6で議論したSIP応答の標準ルールを 使用して構築される。選択される応答コードは、リクエストがINVITEだった ときに選択されるものと同じでなければならない[MUST]。すなわち、UASが呼 を受け取る準備ができていれば200(OK)が返され、UASがビジーであれば486 (Busy Here)が返されるなどである。これは、OPTIONSリクエストがUASの基本 状態を確定するために使用されることを可能にする。この状態は、UASがINVITE リクエストを受け入れるかどうかの印とすることができる。 ダイアログ内で受け取った OPTIONS リクエストは、ダイアログ外で構築され たものと同じ200(OK)応答を生成し、かつ、ダイアログに何ら影響を与えない。 OPTIONSのこの使用方法には、OPTIONSリクエストとINVITEリクエストのプロ キシでの操作の違いを原因とする制限がある。フォークされたINVITEが複数 の200(OK)応答を返すことになる一方、フォークされた OPTIONSはただひとつ の200(OK)応答を返すことになる。これは非INVITE操作を使用してプロキシで 処理されるためである。規範となる詳細についてはセクション16.7参照のこ と。 OPTIONSに対する応答がプロキシサーバーによって生成される場合、プロキシ はサーバーの能力を列挙する200(OK)を返す。その応答はメッセージボディ を含まない。 Allow、Accept、Accept-Encoding、Accept-Language、およびSupportedヘッ ダーフィールドはOPTIONSリクエストに対する200(OK)応答中に存在するべき である[SHOULD]。応答がプロキシによって生成される場合、プロキシはメソッ ドを不可知なために意味が曖昧になるのでAllowヘッダーフィールドは省略 されるべきである[SHOULD]。Contactヘッダーフィールドは200(OK)応答に存 在してもよく[MAY]、3xx応答と同じセマンティクスを持つ。つまり、ユーザー へ到達する選択肢名とメソッドのセットを列挙してもよい。Warningヘッダー フィールドは存在してもよい[MAY]。 メッセージボディを送ってもよい[MAY]。それのタイプはOPTIONSリクエ ストのAcceptヘッダーフィールドによって確定される(Acceptヘッダーフィー ルドが存在しない場合にはapplication/sdpが初期値である)。タイプがメディ ア能力を記述するものを含む場合、UASはその目的のために、その応答にボディ を含めるべきである[SHOULD]。application/sdpの場合にそのようなボディを 構築することについての詳細は、参考文献[13]で述べられている。 Rosenberg, et. al. Standards Track [Page 68] RFC 3261 SIP: Session Initiation Protocol June 2002 UASによって生成されたOPTIONSに対する応答の例(セクション11.1のリクエス トに対応する): SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 ;received=192.0.2.4 To: ;tag=93810874 From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 OPTIONS Contact: Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Accept: application/sdp Accept-Encoding: gzip Accept-Language: en Supported: foo Content-Type: application/sdp Content-Length: 274 (SDPは表示していない) 12 ダイアログ ユーザーエージェントのためのキーコンセプトはダイアログのコンセプトで ある。ダイアログは、しばらくのあいだ持続する2つのユーザーエージェント 間のピアツーピアのSIPリレーションシップを表す。ダイアログは、ユーザー エージェント間のメッセージの順序付けと、それらのあいだの適切なルーティ ングを容易にする。ダイアログは、その中でSIPメッセージを解釈するため のコンテキストを表す。セクション8では、ダイアログ外のリクエストと応答 のための、メソッドに依存しないUA処理について議論した。このセクション では、それらのリクエストと応答がダイアログを構築するためにどのように 使用されるのか、そしてそれに続くリクエストと応答がダイアログ内でどの ように送られるのかを議論する。 ダイアログは各UAにおいて、Call-ID値、ローカルタグ、およびリモートタグ から成るダイアログIDで識別される。ダイアログに関係する各UAにおけるダ イアログIDは同じではない。特に、一つのUAにおけるローカルタグは、相手 UAにおけるリモートタグに等しい。これらのタグは、一意なダイアログIDの 生成を容易にする不透明トークン(opaque token)である。 ダイアログIDは、すべての応答およびToフィールドにtagを含むいかなるリク エストとも関連付けられている。メッセージのダイアログIDを計算するルー ルは、SIPエレメントがUACであるかUASであるかに依存する。UACでは、その ダイアログIDの Call-ID値はメッセージのCall-IDに設定され、リモートタ グはメッセージのToフィールドのtagに設定され、ローカルタグはメッセー Rosenberg, et. al. Standards Track [Page 69] RFC 3261 SIP: Session Initiation Protocol June 2002 ジのFromフィールドのtagに設定される(これらのルールはリクエストと応 答の両方に適用される)。UASについては予想できるように、ダイアログIDの Call-ID値はメッセージのCall-IDに設定され、リモートタグはメッセージの Fromフィールドのtagに設定され、ローカルタグはメッセージのToフィール ドのtagに設定される。 ダイアログは、そのダイアログ内で更にメッセージ送信を行うために必要と される、ステートの特定の要素を含む。このステートは、ダイアログID、ロー カルシーケンス番号(UAからその相手へのリクエストを順番付けするために使 用される)、リモートシーケンス番号(相手からUAへのリクエストを順番付け するために使用される)、ローカルURI、リモートURI、リモートターゲット、 「secure」というブーリアンフラグ、およびルートセット(順番に並べられた URIのリスト)から成る。ルートセットは、相手にリクエストを送るためにト ラバースする必要があるサーバーのリストである。ダイアログは、暫定応答 で生成されたときになる「early」状態になることができ、その後2xx最終応 答が到着するときに「confirmed」ステートに移行する。その他の応答に対し て、またはそのダイアログ上でまったく応答が到着しない場合には、earlyダ イアログは終了する。 12.1 ダイアログの生成 ダイアログは、特定のメソッドを持つリクエストに対する失敗ではない応答 の生成を通して生成される。この仕様では、(リクエストがINVITEだった) To tagを持つ2xx応答および101から199応答のみがダイアログを確立するだ ろう。リクエストに対する非最終応答で確立されたダイアログは、early ステートにあり、それはearlyダイアログと呼ばれる。拡張でダイアログ を生成するための他の方法を定義してもよい[MAY]。セクション13で、 INVITEメソッド固有の更なる詳細について述べる。ここでは、メソッドに 依存しないダイアログステートの生成のための処理を記述する。 UAは以下に述べられるように、ダイアログIDコンポーネントに値を割り当て なければならない[MUST]。 12.1.1 UASの動作 UASが、ダイアログを確立する応答(例えば、INVITEに対する2xx)でリクエ ストに応答するとき、そのUASはリクエストからすべてのRecord-Routeヘッダー フィールド値を応答にコピーしなければならず[MUST](UASが知っていようと 知らなかろうと、URI、URI パラメータ、およびすべてのRecord-Routeヘッダー フィールドパラメータを含む)、それらの値の順番も保持しなければならない [MUST]。UASは、応答にContactヘッダーフィールドを追加しなければ ならない[MUST]。そのContactヘッダーフィールドは、UASが、ダイアログ中 のそれ以後のリクエスト(INVITEの場合は2xx応答に対する ACKを含む)にコン タクトしてほしいと望むアドレスを含む。通常、このURIのホスト部分は、そ のホストのIPアドレスまたはFQDNである。Contactヘッダーフィールドで提供 されるURIはSIP URIまたはSIPS URIでなければならない[MUST]。ダイアログ を開始したリクエストが、(それが存在したとして)Request-URIヘッダーフィー Rosenberg, et. al. Standards Track [Page 70] RFC 3261 SIP: Session Initiation Protocol June 2002 ルド値に、または先頭のRecord-Routeヘッダーフィールド値にSIPS URIを 含んでいた場合、またはRecord-Routeヘッダーフィールドが存在しないとき にContactヘッダーフィールドを含んでいた場合、応答中のContactヘッダー フィールドはSIPS URIでなければならない[MUST]。そのURIはグローバルスコー プを持つべきである[SHOULD](すなわち、このダイアログ外のメッセージで も同じURIを使用できる)。同じように、INVITEのContactヘッダーフィールド 中のURIのスコープも、このダイアログに限定されない。そのためそれは、た とえこのダイアログ外であっても、UACへのメッセージ中で使用できる。 それからUASは、ダイアログのステートを構築する。このステートはダイアロ グの継続するあいだ保持されなければならない[MUST]。 リクエストがTLS上で到着し、Request-URIがSIPS URIを含んだ場合、「secure」 フラグがTRUEに設定される。 ルートセットには、リクエストから順番にすべてのURIパラメータを維持した まま取り出した、Record-Routeヘッダーフィールド中のURIリストを設定しな ければならない[MUST]。リクエストにRecord-Routeヘッダーフィールドが存 在しない場合、ルートセットには空のセットを設定しなければならない[MUST]。 このルートセットは、たとえそれが空でも、このダイアログの今後のリクエ ストのための既存のいかなるルートセットもオーバーライドする。リモート ターゲットには、リクエストのContactヘッダーフィールドのURIを設定しな ければならない[MUST]。 リモートシーケンス番号には、リクエストのCSeqヘッダーフィールドのシー ケンス番号値を設定しなければならない[MUST]。ローカルシーケンス番号は、 空でなければならない[MUST]。ダイアログIDの呼識別子(call identifier) コンポーネントには、リクエストのCall-ID値が設定されなければならない [MUST]。ダイアログIDのローカルタグコンポーネントには、リクエスト(常に tagを含む)に対する応答のToフィールドのtagが設定されなければならず[MUST]、 ダイアログIDのリモートタグコンポーネントには、リクエストのFromフィー ルドのtagを設定しなければならない[MUST]。UASは、Fromフィールドにtagを 持たないリクエストを受け取ることに備えなければならない[MUST]。この場 合、tagはNull値を持つとみなされる。 これは、Fromのtagを義務付けていなかったRFC2543との下位互換性を保 つためである。 リモートURIには、FromフィールドのURIを設定しなければならず[MUST]、ロー カルURIには、ToフィールドのURIを設定しなければならない[MUST]。 12.1.2 UACの動作 ダイアログを確立できるリクエスト(例えばINVITE)をUACが送るとき、それ はリクエストのContactヘッダーフィールドに、グローバルスコープ(すなわ ち、それと同じSIP URIがこのダイアログ外のメッセージでも使用できる)を 持つSIPまたはSIPS URIを提供しなければならない[MUST]。リクエストが、値 がSIPS URIであるRequest-URIまたは先頭のRouteヘッダーフィールドを持つ 場合、ContactヘッダーフィールドはSIPS URIを含まなければならない[MUST]。 Rosenberg, et. al. Standards Track [Page 71] RFC 3261 SIP: Session Initiation Protocol June 2002 UACが、ダイアログを確立する応答を受け取るとき、それはダイアログのステー トを構築する。このステートは、そのダイアログが継続するあいだ保持されな ければならない[MUST]。 リクエストがTLS上で送られ、Request-URIがSIPS URIを含んでいた場合、 「secure」フラグがTRUEに設定される。 ルートセットには、応答から逆順にすべてのURIパラメータを維持したまま取 り出した、Record-Routeヘッダーフィールド中のURIリストを設定しなければ ならない[MUST]。応答にRecord-Routeヘッダーフィールドが存在しない場合、 ルートセットには空のセットを設定しなければならない[MUST]。このルート セットは、たとえそれが空でも、このダイアログの今後のリクエストのため の既存のいかなるルートセットもオーバーライドする。リモートターゲット には、応答のContactヘッダーフィールドのURIを設定しなければならない[MUST]。 ローカルシーケンス番号には、リクエストのCSeqヘッダーフィールドのシー ケンス番号値を設定しなければならない[MUST]。リモートシーケンス番号は、 空でなければならない[MUST](それは、リモートUAがダイアログ内でリクエス トを送るときに確立される)。ダイアログIDの呼識別子(call identifier)コ ンポーネントには、リクエストのCall-ID値が設定されなければならない[MUST]。 ダイアログIDのローカルタグコンポーネントには、リクエストのFromフィー ルドのtagが設定されなければならず[MUST]、ダイアログIDのリモートタグコ ンポーネントには、応答のToフィールドのtagを設定しなければならない[MUST]。 UACは、Toフィールドにtagを持たない応答を受け取ることに備えなければな らない[MUST]。この場合、tagはNull値を持つとみなされる。 これは、Toのtagを義務付けていなかったRFC2543との下位互換性を保つ ためである。 リモートURIには、ToフィールドのURIを設定しなければならず[MUST]、ロー カルURIには、FromフィールドのURIを設定しなければならない[MUST]。 12.2 ダイアログ内のリクエスト 2つのUA間でいったんダイアログが確立されると、どちらかが必要なときにそ のダイアログ内で新規トランザクションを開始してもよい[MAY]。リクエストを送 るUAは、そのトランザクションにおいてUACの役割を果たす。リクエストを受 け取るUAは、UASの役割を果たす。これらの役割は、ダイアログを確立したト ランザクションの間にUAが果たす役割とは異なるかもしれないことに注意する こと。 ダイアログ内のリクエストはRecord-RouteおよびContactヘッダーフィールド を含めてもよい[MAY]。しかしながら、これらのリクエストは、リモート ターゲットURIを修正するかもしれないが、ダイアログのルートセットを修正 する要因にはならない。具体的には、ターゲットリフレッシュリクエストで ないリクエストはダイアログのリモートターゲットURIを修正しない。また、 ターゲットリフレッシュリクエストであるリクエストはダイアログのリモー トターゲットURIを修正する。INVITEで確立されたダイアログにおいては、定 Rosenberg, et. al. Standards Track [Page 72] RFC 3261 SIP: Session Initiation Protocol June 2002 義されている唯一のターゲットリフレッシュリクエストはre-INVITE(セクショ ン14参照)である。他の拡張は、その他の方法で確立されたダイアログのた めの別のターゲットリフレッシュリクエストを定義するかもしれない。 ACKはターゲットリフレッシュリクエストではない(NOT)ことに注意する こと。 ターゲットリフレッシュリクエストはダイアログのリモートターゲットURIの みをアップデートし、Record-Routeから形成されたルートセットはアップデー トしない。後者をアップデートすることは、RFC2543に準拠したシステムと の下位互換性に関する深刻な問題を招くことになる。 12.2.1 UACの動作 12.2.1.1 リクエストの生成 ダイアログ内のリクエストは、そのダイアログの一部として保存されている ステートの多くのコンポーネントを使用して構築される。 リクエストのToフィールドのURIには、ダイアログステートのリモートURIが 設定されなければならない[MUST]。リクエストのToヘッダーフィールドのtag には、ダイアログIDのリモートタグが設定されなければならない[MUST]。リ クエストのFrom URIには、ダイアログステートのローカルURIが設定されなけ ればならない[MUST]。リクエストのFromヘッダーフィールドのtagには、ダイ アログIDのローカルタグを設定しなければならない[MUST]。リモートタグの 値がNullの場合、tagパラメータはToヘッダーフィールドから省略されなけれ ばならない[MUST]。ローカルタグの値がNullの場合、tagパラメータはFromヘッ ダーフィールドから省略されなければならない[MUST]。 これ以降のリクエストにおけるオリジナルリクエストのToおよびFromヘッ ダーフィールドのURIの利用は、URIをダイアログの特定のために使用 していたRFC2543との下位互換性のためになされる。この仕様では、ダ イアログの特定のためにtagだけが使用される。この仕様の今後の改定 において、ダイアログ内リクエスト(mid-dialog request)にオリジナル のToとFromのURIを反映することを必須とすることは反対されるだろう。 リクエストのCall-IDには、そのダイアログのCall-IDが設定されなければな らない[MUST]。ダイアログ内のリクエストは、厳密に単調に増加する連続し たCSeqシーケンス番号(1ずつ増加する)をそれぞれの方向で含まなければなら ない[MUST](当然、ACKとCANCELを例外とする。それらの番号は承認されるリ クエストまたはキャンセルされるリクエストに等しい)。したがって、ローカ ルシーケンス番号が空でない場合、ローカルシーケンス番号の値は1だけ増加 しなければならず[MUST]、この値はCSeqヘッダーフィールドに置かれなけれ ばならない[MUST]。ローカルシーケンス番号が空の場合、セクション8.1.1.5 のガイドラインを使用して初期値が選択されなければならない[MUST]。CSeq ヘッダーフィールド値のメソッドフィールドは、リクエストのメソッドとマッ チしなければならない[MUST]。 Rosenberg, et. al. Standards Track [Page 73] RFC 3261 SIP: Session Initiation Protocol June 2002 32ビットの長さでは、クライアントは、繰り返しが必要になるまでに、 単一の呼の中で1秒に1回のリクエストを約136年間生成できる。シーケ ンス番号の初期値は、それと同じ呼でそれ以降に送るリクエストで、繰 り返しが起こらないように選ばれる。0以外の初期値は、クライアント が時間に基づくシーケンス番号の初期値を使用することを可能にする。 例えば、クライアントは、32ビット秒クロックの上位31ビット (31 most significant bits)をシーケンス番号の初期値として選ぶこと ができる。 UACはリクエストのRequest-URIとRouteヘッダーフィールドを構築するために、 リモートターゲットとルートセットを使用する。 ルートセットが空の場合、UACはRequest-URIにリモートターゲットのURIを置 かなければならない[MUST]。UACはリクエストにRouteヘッダーフィールドを 追加してはならない[MUST NOT]。 ルートセットが空でなく、ルートセットの最初のURIがlrパラメータ(セクショ ン19.1.1参照)を含む場合、UACはRequest-URIにリモートターゲットのURIを置 かなければならず[MUST]、ルートセット値を(すべてのパラメータも含めて)そ の順番で包含するRouteヘッダーフィールドを含めなければならない[MUST]。 ルートセットが空でなく、ルートセットの最初のURIがlrパラメータを含まな い場合、UACはルートセットの最初のURIを、Request-URIに認められていない すべてのパラメータを取り去って、Request-URIに置かなければならない[MUST]。 UACは、残りのルートセット値を(すべてのパラメータも含めて)その順番で包 含するRouteヘッダーフィールドを追加しなければならない[MUST]。それから UACは、Routeヘッダーフィールドに最後の値として、リモートターゲットの URIを置かなければならない[MUST]。 例えば、リモートターゲットがsip:user@remoteuaで、ルートセットが以下 の値を含む場合、 ,,, リクエストは、以下のRequest-URIとRouteヘッダーフィールドとともに形成 される。 METHOD sip:proxy1 Route: ,,, ルートセットの最初のURIがlrパラメータを含まない場合、指示された プロキシはこのドキュメントで述べられているルーティングの仕組み を理解せず、メッセージを転送(forward)する間にRequest-URIを受け取っ た最初のRouteヘッダーフィールド値で置き換えて、RFC2543で規定さ れているとおりに動作する。Routeヘッダーフィールドの最後にRequest- URIを置くことは、ストリクトルーターを通るときにもそのRequest-URIの Rosenberg, et. al. Standards Track [Page 74] RFC 3261 SIP: Session Initiation Protocol June 2002 情報を維持する(リクエストがルースルータに到達したときに、それは Request-URIに戻される)。 UACは、ダイアログ内のいかなるターゲットリフレッシュリクエストにも Contactヘッダーフィールドを含めるべきであり[SHOULD]、それを変更する必 要がないなら、URIはダイアログ内のそれ以前のリクエストで使用されたもの と同じであるべきである[SHOULD]。secureフラグがTRUEの場合、そのURIは SIPS URIでなければならない[MUST]。セクション12.2.2で議論されるように、 ターゲットリフレッシュリクエストのContactヘッダーフィールドは、リモー トターゲットのURIをアップデートする。これは、UAのアドレスがダイアログ の継続期間中に変わる場合に、UAが新しいコンタクトアドレスを提供するこ とを可能にする。 しかしながら、ターゲットリフレッシュリクエストでないリクエストは、ダ イアログのためのリモートターゲットのURIに影響を与えない。 リクエストのは残りの部分はセクション8.1.1で述べられているように形成さ れる。 リクエストが構築されるとすぐに、サーバーのアドレスが計算されて、ダイ アログ外のリクエストのためのものと同じ手順(セクション8.1.2)を使用して リクエストが送られる。 セクション8.1.2の手順は、通常、Routeヘッダーフィールドの先頭の値 またはRouteヘッダーフィールドが存在しない場合にはRequest-URIによ って示されるアドレスに、リクエストが送られるという結果になる。特 定の制限に従うと、それらはリクエストが代替アドレス(例えば、 ルートセットで表されていないデフォルトのアウトバウンドプロキシ) に送られることを可能にする。 12.2.1.2 応答の処理 UACはトランザクションレイヤーからリクエストに対する応答を受け取る。 クライアントトランザクションがタイムアウトを返す場合、これは408(Request Timeout)応答として処理される。 ダイアログ内で送られたリクエストに対する 3xx 応答を受け取るUACの動作 は、リクエストがダイアログ外で送られた場合と同じである。この動作はセ クション8.1.3.4で述べられている。 しかしながら、UACが代替の場所を試すとき、それはリクエストのRoute ヘッダーを構築するためにダイアログのルートセットを依然として使用 する、ということに注意すること。 ターゲットリフレッシュリクエストに対して2xx応答をUACが受け取るとき、 それはダイアログのリモートターゲットURIをその応答のContactヘッダーフィー ルド(もし存在すれば)のURIで置き換えなければならない[MUST]。 Rosenberg, et. al. Standards Track [Page 75] RFC 3261 SIP: Session Initiation Protocol June 2002 ダイアログ内のリクエストに対する応答が481(Call/Transaction Does Not Exist)または408(Request Timeout)の場合、UACはダイアログを終了するべき である[SHOULD]。そのリクエストに対して何らの応答も受け取らない場合に も、UACはダイアログを終了するべきである[SHOULD](クライアントトランザ クションはタイムアウトについてTUに通知するだろう)。 INVITEが開始したダイアログでは、ダイアログの終了はBYEを送ること からなる。 12.2.2 UASの動作 ダイアログ内で送られるリクエストは、他のいかなるリクエストとも同様、 非分割である。特定のリクエストがUASに受け入れられる場合、それに関連付 けられるすべてのステートの変更が行われる。リクエストが拒否される場合、 ステートの変更は行われない。 INVITEのようないくつかのリクエストは、ステートのいろいろな部分に 影響することに注意すること。 UASはトランザクションレイヤーからリクエストを受け取る。リクエストがTo ヘッダーフィールドにtagを持つ場合、UASコアはそのリクエストに対応する ダイアログ識別子(dialog identifier)を計算し、それを既存のダイアログと 比較する。マッチするものがあれば、これはダイアログ内リクエスト(mid- dialog request)である。この場合、セクション8.2で議論されているダイア ログ外のリクエストのためのものと同じ処理ルールを、UASは最初に適用する。 リクエストがToヘッダーフィールドにtagを持つが、ダイアログ識別子が既存 のどのダイアログにもマッチしない場合、そのUASはクラッシュしてリスター トしたか、あるいは別の(おそらく故障した)UASに対するリクエストを受け取 ったのかもしれない(それらのUASは、リカバリを提供しているもう一方のUAS に対するTo tagであったことを、そのUASが識別できるように、To tagを構築 できる)。別の可能性は、やってくるリクエストが単純にミスルートされ ただけということである。To tagに基づいて、UASはそのリクエストを受け入 れても拒否してもよい[MAY]。容認できるTo tagへのリクエストを受け入れる ことは、堅牢性を提供し、それゆえ、ダイアログはたとえクラッシュしても存 続する。この能力をサポートすることを望むUAは、リブートをまたいだとして も単調に増加するCSeqシーケンス番号を選択すること、ルートセットの再構 築、および範囲外のRTPタイムスタンプとシーケンス番号を受け取ること、の ようないくつかの問題を考慮しなければならない。 UASが、ダイアログを再生成することを望まないので、そのリクエストを拒否 したい場合は、481(Call/Transaction Does Not Exist)応答でリクエストに 応答してそれをサーバートランザクションに渡さなければならない[MUST]。 Rosenberg, et. al. Standards Track [Page 76] RFC 3261 SIP: Session Initiation Protocol June 2002 ダイアログのステートをどのような形であれ変更しないリクエストをダイア ログ内で受け取ることがあるかもしれない(例えば、OPTIONSリクエスト)。 それらはダイアログ外で受け取られたかのように処理される。 リモートシーケンス番号が空の場合、それはリクエスト中のCSeqヘッダーの シーケンス番号値に設定されなければならない[MUST]。リモートシーケンス 番号は空ではないが、リクエストのシーケンス番号がリモートシーケンス番 号よりも小さい場合、そのリクエストは順番が狂っており、500(Server Internal Error)応答で拒否されなければならない[MUST]。リモートシーケン ス番号が空でなく、リクエストのシーケンス番号がリモートシーケンス番号 よりも大きい場合、そのリクエストは順番どおりである。CSeqシーケンス番 号がリモートシーケンス番号より2以上大きいこともありうる。これはエラー 状態ではなく、UASは前回受け取ったリクエストよりも2以上大きなCSeq値を 持つリクエストを受け取って処理できるようになっているべきである[SHOULD]。 それからUASは、リモートシーケンス番号にリクエスト中のCSeqヘッダーフィー ルド値のシーケンス番号値を設定しなければならない[MUST]。 UACによって生成されたリクエストにプロキシがチャレンジする場合、 UACは信用証明書を持つリクエストを再提出しなければならない。再提 出されたリクエストは新しいCSeq番号を持つ。UASは最初のリクエスト を見ることはないので、CSeq番号が飛んでいることに気付くだろう。こ のような番号の飛びは、いかなるエラー状態を表すものでもない。 UASがターゲットリフレッシュリクエストを受け取るときは、ダイアログのリ モートターゲットURIをそのリクエストのContactヘッダーフィールドのURI( もし存在すれば)で置き換えなければならない[MUST]。 12.3 ダイアログの終了 ダイアログ外のリクエストが非2xx最終応答を生成する場合、メソッドに依存 しないで、そのリクエストに対する暫定応答を介して生成されたいかなる earlyダイアログも終了される。confirmedダイアログを終了するための仕組み はメソッド固有である。この仕様では、BYEメソッドがセッションとそれに関 連付けられたダイアログを終了する。詳細についてはセクション15参照のこ と。 13 セッションの開始 13.1 概要 ユーザーエージェントクライアントがセッションの開始を望むとき(例えば、 オーディオ、ビデオ、またはゲーム)、それはINVITEリクエストを作成する。 INVITEリクエストはサーバーにセッションの確立を依頼する。このリクエス トは、最終的にその招待を受け入れる可能性があるひとつ以上のUASに到達す るように、プロキシによって転送(forward)されるかもしれない。これらのUAS は、その招待を受け入れるかどうかユーザーに問い合わせる必要があることが Rosenberg, et. al. Standards Track [Page 77] RFC 3261 SIP: Session Initiation Protocol June 2002 多い。しばらくして、それらのUASは2xx応答を送ることでその招待を受け入れ ることができる(そのセッションが確立されることを意味する)。招待が受け 入れられなかった場合、拒否の理由によって、3xx、4xx、5xx、あるいは6xx 応答が送られる。最終応答を送る前に、UASは、着呼側ユーザーにコンタクト している進捗状態をUACに報告するために、暫定応答(1xx)を送ることもでき る。 おそらくひとつ以上の暫定応答を受け取った後、UACはひとつ以上の2xx応答 またはひとつの非2xx最終応答を受け取る。INVITEに対する最終応答を受け取 るまでにかかる長い時間のために、INVITEトランザクションの信頼性の仕組 みは、(OPTIONSのような)他のリクエストのものとは異なる。最終応答を受 け取るとすぐに、UACはそれが受け取るすべての最終応答に対してACKを送る 必要がある。このACKを送るための手順は、応答の種類に依存する。300から 699までの最終応答では、ACK処理はトランザクションレイヤーで行われ、ひ とつのルールセット(セクション17参照)に従う。2xx応答では、ACKはUACコア で生成される。 INVITEに対する2xx応答はセッションを確立し、また、INVITEを発行したUAと 2xx応答を生成したUAとの間にダイアログを生成する。したがって、(INVITEが フォークされたために)異なる複数のリモートUAから複数の2xx応答を受け取る とき、それぞれの2xxは異なるダイアログを確立する。これらのすべてのダイ アログは同一の呼の一部である。 このセクションでは、INVITEを使用したセッションの確立の詳細について述 べる。INVITEをサポートするUAは、ACK、CANCEL、およびBYEもサポートしな ければならない[MUST]。 13.2 UACの処理 13.2.1 最初のINVITE の生成 最初のINVITEはダイアログ外のリクエストに相当するので、その構築はセク ション8.1.1の手順に従う。INVITEの特別な場合には付加的な処理が要求され る。 Allowヘッダーフィールド(セクション20.5)がINVITE中に存在するべきである [SHOULD]。それは、INVITEを送るUA上でダイアログの継続中にどのメソッド を呼び出すことができるかを示す。例えば、ダイアログ内でINFOリクエス ト(参考文献[34])を受け取ることができるUAは、INFOメソッドを列挙する Allowヘッダーフィールドを含むべきである[SHOULD]。 Supportedヘッダーフィールド(セクション20.37)がINVITE中に存在するべき である[SHOULD]。それはUACが理解できるすべての拡張を列挙する。 Rosenberg, et. al. Standards Track [Page 78] RFC 3261 SIP: Session Initiation Protocol June 2002 Acceptヘッダーフィールド(セクション20.1)がINVITE中に存在してもよい[MAY]。 それは、UAが、それが受け取る応答と、INVITEで確立されたダイアログ内で それに送られるそれ以降のすべてのリクエストにおいて、どのContent-Type を受け入れ可能かを示す。Acceptヘッダーはさまざまなセッション記述形式 のサポートを示すために特に有用である。 UACは、招待の有効性を制限するためにExpiresヘッダーフィールド(セクショ ン22.19)を追加してもよい[MAY]。Expiresヘッダーフィールドで示さ れた時間に達し、INVITEに対する最終回答を受け取っていなかった場合、セ クション9にあるように、UACコアはINVITEに対してCANCELを生成するべきで ある[SHOULD]。 UACは、なかでもSubjectヘッダーフィールド(セクション20.36)、Organization ヘッダーフィールド(セクション20.25)、およびUser-Agentヘッダーフィール ド(セクション20.41) を追加することが役に立つものと見なしてもよい[MAY]。 これらはすべてINVITEに関連する情報を含む。 UACはINVITEにメッセージボディを追加することを選択してもよい[MAY]。セクショ ン8.1.1.10では、メッセージボディを記述するために必要になるヘッダー フィールド(なかでもContent-Type)をどのように構築するかについて述べ ている。 セッション記述を含むメッセージボディのための特別なルールがある - セッ ション記述に対応するContent-Dispositionは「session」である。SIPでは、 一つのUAが、それが提案するセッションの説明を含むオファー(offer)と呼 ばれるセッション記述を送る、オファー/アンサーモデルを使用する。オファー は、希望するコミュニケーション手段(オーディオ、ビデオ、ゲーム)、 それらの手段のパラメータ(例えばCODECタイプ)、およびアンサー側からメ ディアを受け取るためのアドレスを示す。相手UAは、どのコミュニケーショ ン手段が受け入れられるか、それらの手段に適用するパラメータ、およびオ ファー側からメディアを受け取るためのアドレスを示す、アンサーと呼ばれ る別のセッション記述で応答する。SIP INVITEが結果的に複数のダイアログ になった場合、それぞれが別個のオファー/アンサーのやり取りがあるように、 オファー/アンサーのやりとりはダイアログのコンテキスト内にある。オファー /アンサーモデルは、オファーとアンサーをいつ行うことができるかについて の制限を定義する(例えば、オファーを処理している間は新たなオファーは作 成できない)。このことは、オファーとアンサーがSIPメッセージのどこに現 れることができるかについての制限を課すことになる。この仕様では、 オファーとアンサーはINVITEリクエストとそれに対する応答、およびACKに だけ現れることができる。オファーとアンサーの用法は更に制限される。最初 のINVITEトランザクションに対するルールは以下のようである。 o 最初のオファーは、INVITE中にあるか(そこにない場合には)UASから UACに返される最初の信頼性のある非失敗メッセージ中になければな らない[MUST]。この仕様では、それは2xx最終応答である。 Rosenberg, et. al. Standards Track [Page 79] RFC 3261 SIP: Session Initiation Protocol June 2002 o 最初のオファーがINVITE中にある場合、アンサーは、UASからUACに返 されるそのINVITEに関連する信頼性のある非失敗メッセージ中になけ ればならない[MUST]。この仕様では、それは、そのINVITEに対する最 終2xx応答のみである。それとまったく同じアンサーを、アンサーが送 られる前に送られるいかなる暫定応答中にも置いてもよい[MAY]。 UACは、それが受け取る最初のセッション記述をアンサーとして扱わ なければならず[MUST]、最初のINVITEに対するそれ以降の応答中のい かなるセッション記述も無視しなければならない[MUST]。 o 最初のオファーが、UASからUACに返される最初の信頼性のある非失敗 メッセージ中にある場合、アンサーはそのメッセージに対する承認 (acknowledgement)中になければならない[MUST](この仕様では、2xx 応答に対するACK)。 o 最初のオファーに対するアンサーを送ったか受け取った後に、UACは、 そのメソッドに対して規定されたルールに基づくリクエスト中に それに続く次のオファーを生成してもよい[MAY]。しかし、 それができるのは、それ以前のすべてのオファーに対するアンサー を送っていて[※訳注]、かつ、アンサーを受け取っていないいかなる オファーも送っていない場合だけである。 [訳注: 原文では「received」だが、「send」であると考えられる。 この件は、SIP WGでも仕様のバグとして認められている。] o UASは最初のオファーに対するアンサーをいったん送ったか受け取っ たら、最初のINVITEに対するいかなる応答中でも、それに続く次のオ ファーを生成してはならない[MUST NOT]。これは、この仕様だけに基 づくUASが最初のトランザクションが完了するまで次のオファーを決 して生成できないことを意味する。 具体的には、この仕様のみに準拠するUAについて、上記のルールは2つのやり とり(exchanges)を規定する。オファーがINVITE中にありアンサーが2xx中 (おそらくは同じ値で1xxにも)にあることを、あるいはオファーが2xx中に ありアンサーがACK中にあることをである。INVITEをサポートするすべての ユーザーエージェントはこれら2つのやりとりをサポートしなければなら ない[MUST]。 セッション記述プロトコル(SDP)(RFC2327 参考文献[1])は、セッションを記 述する手段としてすべてのユーザーエージェントがサポートしなければなら ず[MUST]、オファーとアンサーを構築するためのそれの用法は、参考文献[13] で定義されている手順にしたがわなければならない[MUST]。 上で述べられたオファー/アンサーモデルの制限事項は、Content-Disposition ヘッダーフィールド値が「session」であるボディにのみ適用される。したがっ て、INVITEとACK双方がボディメッセージを含むことが可能である(例えば、 INVITEが写真(Content-Disposition: render)を運び、ACKがセッション記述を 運ぶ(Content-Disposition: session))。 Content-Dispositionヘッダーフィールドがない場合、Content-Typeが 「application/sdp」のボディはdispositionが「session」であること を示す。一方、その他のContent-Typeは「render」を示す。 Rosenberg, et. al. Standards Track [Page 80] RFC 3261 SIP: Session Initiation Protocol June 2002 いったんINVITEが生成されると、UACは、ダイアログ外でリクエストを送るた めに定義されている手順(セクション8)に従う。これは、結果として、そ のリクエストを送りそのUACに応答を配信する、クライアントトランザクショ ンを構築することになる。 13.2.2 INVITEに対する応答の処理 いったんINVITEがINVITEクライアントトランザクションに渡されると、UACは そのINVITEに対する応答を待つ。INVITEクライアントトランザクションが応 答ではなくタイムアウトを返す場合、TUはあたかも408(Request Timeout)応 答を受け取ったかのように動作する(セクション8.1.3で述べられているよう に)。 13.2.2.1 1xx応答 一つ以上の最終応答を受け取る前に、ゼロ個、1個、あるいは複数個の暫定応 答が到着するかもしれない。INVITEリクエストに対する暫定応答は「earlyダ イアログ」を生成することができる。暫定応答がToフィールドにtagを持ち、 その応答のダイアログIDが既存のダイアログにマッチしない場合、セクショ ン12.1.2で定義されている手順を用いてダイアログが構築される。 earlyダイアログは、最初のINVITEトランザクションが完了する前に、UACが ダイアログ内で相手にリクエストを送る必要がある場合にのみ必要とされる。 暫定応答中に存在するヘッダーフィールドは、ダイアログがearlyステートに ある限り適用できる(例えば、暫定応答中のAllowヘッダーフィールドは、 ダイアログがearlyステートにあるあいだだけ使用できるメソッドを含む)。 13.2.2.2 3xx応答 3xx応答は、着呼側に到達できるかもしれない新しいアドレスを提供する一つ 以上のContactヘッダーフィールド値を含むことができる。3xx応答のステー タスコード(セクション21.3参照)次第で、UACはその新しいアドレスを試すこ とを選択してもよい[MAY]。 13.2.2.3 4xx、5xx、および6xx応答 INVITEに対して、一つの非2xx最終応答を受け取るかもしれない。4xx応答、 5xx応答、および6xx応答は、エラーについての付加的な情報を得ることがで きる場所を示すContactヘッダーフィールド値を含むことができる。それ以降 の最終応答(エラー状態のときだけ到着する)は、無視されなければならない [MUST]。 すべてのearlyダイアログは、非2xx応答の受信時に終了するとみなされる。 Rosenberg, et. al. Standards Track [Page 81] RFC 3261 SIP: Session Initiation Protocol June 2002 非2xx最終応答を受け取った後、UACコアはINVITEトランザクションが完了し たとみなす。INVITEクライアントトランザクションは、その応答に対するACK の生成を操作する(セクション17参照)。 13.2.2.4 2xx応答 フォークするプロキシがあるため、一つのINVITEリクエストに対して複数の 2xx応答がUACに到着するかもしれない。各応答はToヘッダーフィールドのtag パラメータによって区別され、それぞれ別個のダイアログ識別子を持った別 個のダイアログに相当する。 2xx応答中のダイアログ識別子が既存のダイアログのダイアログ識別子にマッ チする場合、そのダイアログは「confirmed」ステートに移行しなければなら ず[MUST]、セクション12.2.1.2の手順を用いて、2xx応答に基づいてそのダイ アログのルートセットを再計算しなければならない[MUST]。さもなければ、 セクション12.1.2の手順を用いて、「confirmed」ステートの新しいダイアロ グが構築されなければならない[MUST]。 再計算されるステートの要素はルートセットだけであるということに注 意すること。例えばダイアログ内で送られる最も大きいシーケンス番 号(リモートとローカルのもの)といったステートの他の要素は、再計算 されない。ルートセットのみが下位互換性のために再計算される。RFC 2543では、Record-Routeヘッダーフィールドのミラーリングを 2xxにの み義務付けており、1xxには義務付けていなかった。しかしながら、ダ イアログ内リクエスト(mid-dialog request)が、例えばシーケンス番 号を修正して、earlyダイアログ内で送られたのかもしれないので、ダ イアログのステート全体をアップデートすることはできない。 UACコアは、トランザクションレイヤーから受け取った各2xxに対して ACKリ クエストを生成しなければならない[MUST]。ACKのヘッダーフィールドは、 CSeqと認証に関するヘッダーフィールドを除き、ダイアログ内で送られるす べてのリクエストと同じ方法で構築される(セクション12参照)。CSeqヘッダー フィールドのシーケンス番号は、同意される(Acknowledged)INVITEのものと同 じでなければならない[MUST]が、CSeqのメソッドはACKでなければならない [MUST]。ACKはINVITEと同じ信用証明書を含まなければならない[MUST]。 2xxが(上記のルールに基づく)オファーを含む場合、ACKはボディでアンサー を伝えなければならない[MUST]。2xx応答中のオファーが受け入れ不可能な場 合、UACコアはACK中に有効なアンサーを生成してそれから直ちにBYEを送らな ければならない[MUST]。 いったんACKが構築されると、デスティネーションのアドレス、ポート、およ びトランスポートを確定するために参考文献[4]の手順が使用される。しかし ながら、リクエストは送信のために、クライアントトランザクションではな く、トランスポートレイヤーに直接渡される。これは、トランザクションレ イヤーではなくUACコアがACKの再送を操作するためである。ACKのトリガーと なった2xx最終応答の再送が到着するたびに、ACKはクライアントトランスポー トに渡されなければならない[MUST]。 Rosenberg, et. al. Standards Track [Page 82] RFC 3261 SIP: Session Initiation Protocol June 2002 UACコアは、最初の2xx応答を受信してから64*T1秒後に、INVITEトランザクショ ンが完了するとみなす。この時点で、establishedダイアログに移行してい ないすべてのearlyダイアログは終了される。いったんUACコアによってINVITE トランザクションが完了したとみなされると、これ以上の2xx応答が到着する とは期待されない。 INVITEに対するどのような2xx応答に同意した(acknowledge)後でも、UACがそ のダイアログの継続を望まない場合は、UACはセクション15で述べられている ようにBYEリクエストを送ることで、そのダイアログを終了しなければならな い[MUST]。 13.3 UASの処理 13.3.1 INVITEの処理 UASコアはトランザクションレイヤーからINVITEリクエストを受け取る。UAS は最初にセクション8.2のリクエスト処理手順を実行する。この処理はダイア ログの内部および外部両方のリクエストに適用されるものである。 これらの処理ステートが応答を生成せずに完了されると仮定すると、UASコア は付加的な処理手順を実行する。 1. リクエストがExpiresヘッダーフィールドを含むINVITEの場合、 UASコアはこのヘッダーフィールド値で示される秒数のタイマーを 設定する。タイマーが切れるとき、招待は期限切れになったとみ なされる。UASが最終応答を生成する前に招待が期限切れになる場 合には、487(Request Terminated)応答が生成されるべきである [SHOULD]。 2. リクエストがダイアログ内リクエスト(mid-dialog request)であ る場合、セクション12.2.2で述べられているメソッドに依存しな い処理が最初に適用される。それもセッションを修正するかもし れない。セクション14で詳細を述べる。 3. リクエストがToヘッダーフィールドにtagを持つが、ダイアログ識 別子が既存のどのダイアログにもマッチしない場合、UASはクラッ シュしてリスタートしたのかもしれないし、あるいは別の(おそら く故障した)UASへのリクエストを受け取ったのかもしれない。こ のような状況下で堅牢性を実現するためのガイドラインをセクショ ン12.2.2で提供する。 これ以降の処理は、INVITEがダイアログ外のもので、したがって、新規セッ ションを確立するためのものであると仮定している。 INVITEはセッション記述を含むかもしれない。この場合、UASはそのセッショ ンのためのオファーを提示されている。たとえINVITEがダイアログ外のもの であっても、ユーザーはすでにそのセッションの参加者である可能性がある。 これは、ユーザーが他の複数の参加者から同一のマルチキャストカンファレ ンスに招待されたときに起こり得る。希望するなら、UASはこの重複を検知す Rosenberg, et. al. Standards Track [Page 83] RFC 3261 SIP: Session Initiation Protocol June 2002 るために、セッション記述内で識別子を使用してもよい[MAY]。例え ば、SDPはorigin(o)フィールドにセッションIDとバージョン番号を含む。ユー ザーがすでにそのセッションのメンバーであり、セッション記述に含まれ ているセッションパラメータが変化していなければ、UASはそのINVITEを黙っ て受け入れてもよい[MAY](すなわち、ユーザーに注意を促さずに2xx応答を 送る)。 INVITEがセッション記述を含まない場合、UASはセッションに参加することを 依頼されており、UACはUASがセッションのオファーを提供することを頼んで いる。UASは、UACに返す最初の信頼性のある非失敗メッセージでオファーを 提供しなければならない[MUST]。この仕様では、それはINVITEに対する2xx応 答である。 UASは進捗状態を示したり、招待を受け入れたり、招待をリダイレクトしたり、 あるいは招待を拒否することができる。これらすべての場合において、UASは セクション8.2.6で述べられている手順を用いて応答を作成する。 13.3.1.1 進捗状態 UASが直ちに招待に答えられない場合、UACに対してある種の進捗状態を示す ことを選ぶことができる(例えば、電話が鳴っているという合図)。これは 101〜199の暫定応答で実現される。これらの暫定応答はearlyダイアログを確 立し、それゆえセクション8.2.6の手順に加えてセクション12.1.1の手順にし たがう。UASは望むだけの数の暫定応答を送ってもよい[MAY]。それらは 各々、同一のダイアログIDを示さなければならない[MUST]。しかしながら、 これらは信頼性を持って送られることはない。 UASがINVITEに答えるために長い時間を希望する場合、プロキシがトランザク ションをキャンセルすることを防ぐために、「時間の延長(extension)」を依 頼する必要がある。プロキシは、トランザクション内の応答と応答の間に3分 の間隔があるときに、トランザクションをキャンセルするオプションを持つ。 キャンセルを防ぐために、UASは非100暫定応答を(暫定応答のロストの可能性 に対処するため)毎分、送らなければならない[MUST]。 ユーザーが保留されたとき、または呼び出しに答えずにコミュニケーショ ンが行われることを可能にするPSTNシステムと相互に動作するときに、 INVITEトランザクションは延長された期間中継続できる。後者は、音声 自動応答システム(IVR)において一般的である。 13.3.1.2 INVITEがリダイレクトされる UASが呼のリダイレクトを決定した場合、3xx応答が送られる。300(Multiple Choices)応答、301(Moved Permanently)応答、あるいは302(Moved Temporarily) 応答は、試行されるべき一つ以上の新しいアドレスのURIを含むContactヘッ Rosenberg, et. al. Standards Track [Page 84] RFC 3261 SIP: Session Initiation Protocol June 2002 ダーフィールドを含むべきである[SHOULD]。その応答は、再送を処理する、 INVITEサーバートランザクションに渡される。 13.3.1.3 INVITEが拒否される 着呼側がそのエンドシステムでもう一つの呼を受け取れないあるいは受け取 りたくないときがある。そのような場合、486(Busy Here)が返されるべきで ある[SHOULD]。他のどのエンドシステムでもこの呼を受け入れられないこと をUASが知っている場合、かわりに600(Busy Everywhere)応答が送られるべき である[SHOULD]。しかしながら、一般的にUASがこのことを知ることができる 可能性は低く、そのためこの応答は通常使用されない。応答は、再送を処理 する、INVITEサーバートランザクションに渡される。 INVITEに含まれているオファーを拒否するUASは、488(Not Acceptable Here) 応答を返すべきである[SHOULD]。そのような応答は、オファーがなぜ拒否さ れたのかを説明するWarningヘッダーフィールド値を含むべきである[SHOULD]。 13.3.1.4 INVITEが受け入れられる UASコアは2xx応答を生成する。この応答はダイアログを確立するのでセクショ ン8.2.6の手順に加えてセクション12.1.1の手順に従う。 INVITEに対する2xx応答は、AllowヘッダーフィールドとSupportedヘッダー フィールドを含むべきであり[SHOULD]、Acceptヘッダーフィールドを含めても よい[MAY]。これらのヘッダーフィールドを含むことで、呼が継続する間、調 査せずに、UACがUASのサポートしている機能と拡張を確定することが可能に なる。 INVITEリクエストがオファーを含んでいて、UASがまだアンサーを送っていな い場合、2xxはアンサーを含まなければならない[MUST]。INVITEがオファーを 含まなかった場合、UAS がまだオファーを送っていなかったら、2xxはオファー を含まなければならない[MUST]。 応答が構築されるとすぐに、それはINVITEサーバートランザクションに渡さ れる。しかしながら、INVITEサーバートランザクションは、この最終応答を 受け取ってそれをトランスポートに渡すと同時に破棄されるということに注 意すること。したがって、ACKが到着するまでのあいだ定期的にその応答を直 接トランスポートに渡す必要がある。2xx応答は、T1秒で始まり、T2秒になる まで再送のたびに2倍になる時間間隔で、トランスポートに渡される(T1 とT2はセクション17で定義される)。応答の再送は、その応答に対するACKリ クエストを受け取るときに停止する。これは、応答を送るためにどのような トランスポートプロトコルを使用するかによらない。 Rosenberg, et. al. Standards Track [Page 85] RFC 3261 SIP: Session Initiation Protocol June 2002 2xxはエンドツーエンドで再送されるので、UASとUACの間にUDPのホッ プがあるかもしれない。これらのホップをまたぐ確実な配送を保証す るために、UASでのトランスポートに信頼性があったとしても、応答は 定期的に再送される。 サーバーがACKを受け取ることなく2xx応答を64*T1秒のあいだ再送する場合、 ダイアログはコンファームされ(confirmed)るが、セッションは終了されるべ きである[SHOULD]。これは、セクション15で述べられているようにBYEで実現 される。 14 既存セッションの変更 成功したINVITEリクエスト(セクション13参照)は、オファー/アンサーモデル を使用して2つのユーザーエージェント間にダイアログとセッションを確立す る。セクション12で、ターゲットリフレッシュリクエストを使ってどのよう に既存のダイアログを修正するかを説明する(例えば、ダイアログのリモー トターゲットのURIを変更する)。このセクションでは実際のセッションを修 正する方法を述べる。この修正は、アドレスやポートの変更、メディアスト リームの追加、メディアストリームの削除、などを伴うことができる。これ は、セッションを確立したのと同じダイアログ内で新規INVITEリクエストを 送ることによって実現できる。既存のダイアログ内で送られたINVITEリクエ ストはre-INVITEとして知られている。 単一のre-INVITEは、ダイアログとセッションのパラメータを同時に変 更できるということに注意すること。 発呼側と着呼側のいずれも既存のセッションを変更できる。 メディアの失敗を検知したときのUAの動作はローカルポリシー次第である。 しかしながら、ネットワークトラフィックが混雑しているときにトラフィッ クをあふれさせることを避けるため、re-INVITEやBYEを自動生成することは 推奨されない[NOT RECOMMENDED]。いかなる場合でも、これらのメッセージが 自動で送られる場合は、ランダムな間隔の後で送られるべきである[SHOULD]。 上記のパラグラフは自動的に生成されるre-INVITEとBYEについて述べて いる、ということに注意すること。メディアの失敗時にユーザーがハン グアップする場合、UAはBYEリクエストを通常どおりに送る。 14.1 UACの動作 INVITE中のセッション記述に適用されるのと同じオファー/アンサーモデル( セクション13.2.1)がre-INVITEにも適用される。結果として、例えば、メ ディアストリームの追加を望むUACは、そのメディアストリームを含む新規オ ファーを生成し、それをINVITEリクエストで相手に送る。変更部分だけでは なく、完全なセッション記述が送られることに注意することが重要である。 これは、様々なエレメントにおけるステートレスなセッション処理、および フェールオーバーとリカバリ能力をサポートする。もちろん、UACはセッショ Rosenberg, et. al. Standards Track [Page 86] RFC 3261 SIP: Session Initiation Protocol June 2002 ン記述なしでre-INVITEを送ってもよい[MAY]。この場合、re-INVITEに 対する信頼性のある最初の非失敗応答がオファーを含む(この仕様では、これ は2xx応答である)。 セッション記述の書式がバージョン番号を表現する能力を持っている場合、オ ファー側はセッション記述のバージョンが変更されたことを示すべきであ る[SHOULD]。 re-INVITEのTo、From、Call-ID、CSeq、およびRequest-URIは、セクション12 で述べられている、既存ダイアログ内での通常のリクエストのためのものと 同じルールに従って設定される。 UASは通常re-INVITEの受信時にユーザーに知らせないので、UACはAlert-Info ヘッダーフィールドまたは 「alert」という値のContent-Dispositionを持つ ボディを追加しないことを選択してもよい[MAY]。 フォークすることができるINVITEとは異なり、re-INVITEは決してフォークし ない。そのため、常に一つの最終応答を生成する。re-INVITEが決してフォー クしないことの理由は、ダイアログを確立した相手UAインスタンスとして Request-URIがターゲットを特定するからである(そのユーザーの Address-of- Recordを特定するのではなく)。 どちらかの方向で他のINVITEトランザクションが進行しているあいだ、UACは ダイアログ内で新規INVITEトランザクションを開始してはならない[MUST NOT] ということに注意すること。 1. 進行中のINVITEクライアントトランザクションがある場合、TUは 新規INVITEを開始する前に、そのトランザクションがCompletedま たはTerminatedステートになるまで待たなければならない[MUST]。 2. 進行中のINVITEサーバートランザクションがある場合、TUは新規 INVITEを開始する前に、そのトランザクションがconfirmedまたは Terminatedステートになるまで待たなければならない[MUST]。 しかしながら、UAはINVITEトランザクションが進行している間に通常のトラン ザクションを開始してもよい[MAY]。また、UAは通常のトランザクションが進行 している間にINIVTEトランザクションを開始してもよい[MAY]。 UAがre-INVITEに対する非2xx最終応答を受け取る場合、あたかもre-INVITEが 発行されなかったかのように、セッションパラメータは変更されずにそのま までなければならない[MUST]。セクション12.2.1.2で述べられているように、 非2xx応答が、481(Call/Transaction Does Not Exist)、408(Request Timeout)、 またはre-INVITEに対する応答が何もない(すなわち、INVITEクライアントト ランザクションによってタイムアウトが返された)場合、UACはダイアログを 終了するということに注意すること。 Rosenberg, et. al. Standards Track [Page 87] RFC 3261 SIP: Session Initiation Protocol June 2002 UACがINVITEに対する491応答を受け取る場合、UACは以下のようにして選ばれ たタイマーTを開始するべきである[SHOULD]。 1. UACがそのダイアログIDのCall-IDの所有者である場合(つまり、そ のUACがその値を生成した場合)、Tは2.1秒から4秒のあいだで10ミ リ秒単位でランダムに選択された値を持つ。 2. UACがそのダイアログIDのCall-IDの所有者でない場合、Tは0秒か ら2秒のあいだで10ミリ秒単位でランダムに選択された値を持つ。 タイマーが切れるとき、そのセッション修正を行うことをまだ望むなら、UAC はre-INVITEをもう一度試みる。例えば、呼がBYEで既に切断されていた場 合、re-INVITEは行われないだろう。 re-INVITEを送信することと、re-INVITEへの2xx応答に対するACKの生成のた めのルールは、最初のINVITEのためのもの(セクション13.2.1)と同じである。 14.2 UASの動作 セクション13.3.1では、こちらにやってくるre-INVITEをこちらにやってくる 最初のINVITEと区別するための手順、および既存のダイアログに対する re-INVITEを操作するための手順を述べている。 2番めのINVITEを、それよりも小さいCSeqシーケンス番号を持つ最初のINVITEに対 する最終応答を送る前に、同じダイアログ上で受け取るUASは、2番めのINVITE に対して500(Server Internal Error)応答を返さなければならず[MUST]、0秒 から10秒のあいだでランダムに選ばれた値を持つRetry-Afterヘッダーフィー ルドを含まなければならない[MUST]。 あるダイアログ上で送ったINVITEが進行している間に、そのダイアログ上でも う一つのINVITEを受け取るUASは、受け取ったそのINVITEに対して491(Request Pending)応答を返さなければならない[MUST]。 UAが既存のダイアログに対するre-INVITEを受け取る場合、セッション記述中 のバージョン識別子または(バージョン識別子がない場合は)セッション記述 のコンテンツを、それが変更されていないかどうか確認するために、チェッ クしなければならない[MUST]。セッション記述が変更されていた場合、UASは、 おそらくはユーザーに確認を取った後で、セッションパラメータをしかるべ く調整しなければならない[MUST]。 セッション記述のバージョン番号付けは、新しくカンファレンスにやっ てきた者の能力を受け入れるため、メディアを追加/削除するため、あ るいはユニキャストカンファレンスからマルチキャストカンファレンス に変更するために使用できる。 Rosenberg, et. al. Standards Track [Page 88] RFC 3261 SIP: Session Initiation Protocol June 2002 新しいセッション記述が受け入れられない場合、UASはre-INVITEに対して488 (Not Acceptable Here)応答を返すことでそれを拒否できる。この応答は Warningヘッダーフィールドを含むべきである[SHOULD]。 UASが2xx応答を生成したのにいつまでもACKを受け取らない場合、UASはダイ アログを終了するためにBYEを生成するべきである[SHOULD]。 UASはre-INVITEに対して180(Ringing)応答を生成しないことを選択してもよい[MAY]。 これは、UACが通常この情報をユーザーに与えないためである。同じ理由から、 UASはre-INVITEに対する応答で、Alert-Infoヘッダーフィールドやalertとい う値のContent-Dispositionを持つボディを使わないことを選択してもよい[MAY]。 (INVITEがオファーを含まなかったため)2xxでオファーを提供するUASは、SDP の場合について参考文献[13]で述べられているように、既存のセッションを アップデートするオファーを送る際の制約に従って、あたかもUASが新た に電話をかけているかのようにオファーを構築するべきである[SHOULD]。具 体的には、それはそのUAがサポートすることを望むメディアの書式とタイプを できるだけ含むべきである[SHOULD]ことを意味する。UASは、セッション記述 が以前のセッション記述と、相手側のサポートを必要とするメディアの書式、 トランスポート、または他のパラメータにおいて重複することを保証しなけれ ばならない[MUST]。これは、相手がセッション記述を拒否する必要性を避ける ためである。しかしながら、それがUACにとって受け入れられないものである 場合、UACは有効なセッション記述を持つアンサーを生成するべきであり [SHOULD]、次いでそのセッションを終了するためにBYEを送る。 15 セッションの終了 このセクションでは、SIPで確立されたセッションを終了するための手順につ いて述べる。セッションのステートとダイアログのステートは非常に密接に 関連している。セッションがINVITEで開始されるとき、個々のUASからのそれ ぞれの1xxまたは2xx応答はダイアログを生成し、その応答がオファー/アンサー 交換を完了する場合、それはセッションも生成する。結果として、それぞ れのセッションは(それを生成する結果を招いた)一つのダイアログと「関連 付け」られる。最初のINVITEが非2xx最終応答を生成する場合、それはリクエ ストに対する応答で生成された(もしあれば)すべてのセッションと(もしあれ ば)すべてのダイアログを終了する。トランザクションを完了することで、非 2xx最終応答は更なるセッションがINVITEの結果として生成されることを防ぐ。 特定のセッションやまだ確立していないセッションを終了するためにBYEリク エストが使用される。この場合の特定のセッションとは、ダイアログの向こ う側に相手UAがいるセッションのことである。ダイアログ上でBYEを受け取る ときは、そのダイアログに関連付けられたすべてのセッションを終了するべ きである[SHOULD]。UAはダイアログ外でBYEを送ってはならない[MUST NOT]。 発呼側のUAはconfirmedダイアログあるいはearlyダイアログのいずれに対し てもBYEを送ってもよい[MAY]。着呼側のUAはconfirmedダイアログ上でBYE を送ってもよい[MAY]が、earlyダイアログ上でBYEを送ってはならない [MUST NOT]。 Rosenberg, et. al. Standards Track [Page 89] RFC 3261 SIP: Session Initiation Protocol June 2002 しかしながら、着呼側のUAは、それが送った2xx応答に対するACKを受け取る まで、あるいはサーバートランザクションがタイムアウトするまではconfirmed ダイアログ上でBYEを送ってはならない[MUST NOT]。どのSIP拡張もダイアログ に関連付けられた他のアプリケーションレイヤーステートを定義していなかっ た場合、BYEはダイアログも終了する。 INVITEに対する非2xx応答がダイアログおよびセッションに与える強い影響は CANCELの使用を魅力のあるものにする。CANCELはINVITEに対する非2xx応答( 特に、487)を強いる。したがって、UACが呼び出しの試み(call attempt)を完 全にやめたいと望む場合、UACはCANCELを送ることができる。INVITEがそれに 対する2xx最終応答(一つまたは複数)を生じる結果になる場合は、CANCELが進 行している間にUASが招待を受け入れたことを意味する。UACは2xx応答で確立 されたセッションを継続してもよい[MAY]し、またはそれらをBYEで終了しても よい[MAY]。 「電話を切る(haging up)」という考えは、SIPではしっかりと定義され ていない。たとえ一般的な考えであるとしても、それはある特定のユー ザーインターフェースに固有のものである。通常、ユーザーが電話を切 るときには、セッションを確立する試みを終了すること、およびすでに 生成されたすべてのセッションを終了することを望むことを示す。発呼 側のUAにとってこれは、最初のINVITEが最終応答を生成していない場合 にはCANCELリクエストを、そして最終応答後のすべてのconfirmedダイ アログに対してはBYEを意味する。着呼側のUAにとっては、これは通常 BYEを意味する。つまり、推定されるように、ユーザーが電話に出ると き2xxが生成されるので、電話を切ることはACKを受信した後にBYEを生 成することになる。これは、ユーザーが ACK の受信前に電話を切るこ とができないという意味ではなく、ユーザーの電話の中のソフトウェア が適切にクリーンアップを行うために短時間だけステートを保持する必 要があることを単に意味する。ユーザーが電話に出る前にそれを拒否す ることを特定のUIが可能にする場合、403(Forbidden)がそれを表現する ための良い方法である。上記のルールにより、BYEを送ることはできな い。 15.1 BYEリクエストによるセッションの終了 15.1.1 UACの動作 BYEリクエストはダイアログ内の他のいかなるリクエストとも同様に、セクショ ン12で述べられているように構築される。 BYEが構築されるとすぐに、UACコアは新規の非INVITEクライアントトランザ クションを生成し、それにBYEリクエストを渡す。UACはBYEリクエストがクラ イアントトランザクションに渡されるとすぐにセッションが終了した(したが って、メディアの送信またはリッスンを停止する)とみなさなければならない [MUST]。BYEに対する応答が481(Call/Transaction Does Not Exist)または408 (Request Timeout)の場合、あるいはBYEに対する応答を何も受け取らない場 Rosenberg, et. al. Standards Track [Page 90] RFC 3261 SIP: Session Initiation Protocol June 2002 合(すなわち、クライアントトランザクションからタイムアウトが返された)、 UACはセッションとダイアログが終了したとみなさなければならない[MUST]。 15.1.2 UASの動作 UASは最初にセクション8.2で述べられている一般的なUASの処理に従って BYEリクエストを処理する。BYEリクエストを受け取るUASコアは、それが既存 のダイアログにマッチするかどうかを確認する。BYEが既存のダイアログにマッ チしない場合、UASコアは481(Call/Transaction Does Not Exist)応答を生 成してそれをサーバートランザクションに渡すべきである[SHOULD]。 このルールは、UACが送ったtagを持たないBYEは拒否されることを示す。 これはtagなしのBYEを許可していたRFC2543からの変更である。 既存のダイアログに対してBYEリクエストを受け取るUASコアは、そのリクエ ストを処理するためにセクション12.2.2の手順に従わなければならない[MUST]。 処理が終了したらすぐに、UASはセッションを終了するべきである[SHOULD]( それゆえ、メディアの送信とリッスンを中止する)。セッションの終了を選択 できない唯一のケースは、たとえダイアログ内の他の参加者がセッションへ の関わりを終了しても参加が可能な、マルチキャストセッションの場合であ る。セッションへの参加を終えるかどうかに関わらず、UASコアはBYEに対し て2xx応答を生成しなければならず[MUST]、送信するためにそれをサーバート ランザクションに渡さなければならない[MUST]。 UASは、そのダイアログに対して受け取っているいかなるペンディング中のリ クエストに対しても依然として応答しなければならない[MUST]。それらのペ ンディング中のリクエストに対して487(Request Terminated)応答を生成する ことが推奨される[RECOMMENDED]。 16 プロキシの動作 16.1 概要 SIPプロキシは、SIPリクエストをユーザーエージェントサーバーに、SIP応答 をユーザーエージェントクライアントにルートするエレメントである。リク エストはUASにたどり着くまでにいくつかのプロキシをトラバースするかもし れない。各プロキシはルーティングの決定を行い、リクエストを次のエレメ ントに転送(forward)する前にそれを修正する。応答は、リクエストがトラ バースしたプロキシの組を逆にたどってルートされる。 SIPエレメントにとって、プロキシになるということは論理的な役割を果たす ことである。リクエストが到着するとき、プロキシの役割を果たすことがで きるエレメントは、それ自身がそのリクエストに応答する必要があるかどう かを最初に確定する。例えば、リクエストが異常な形になっているかもし れないし、そのエレメントがプロキシとして動作する前にクライアントから の信用証明書を必要とするかもしれない。エレメントは、あらゆる適切なエ Rosenberg, et. al. Standards Track [Page 91] RFC 3261 SIP: Session Initiation Protocol June 2002 ラーコードで応答してもよい[MAY]。リクエストに直接応答するとき、 エレメントはUASの役割を演じており、セクション8.2で述べられているよう に動作しなければならない[MUST]。 プロキシは、それぞれの新規リクエストに対して、ステートフルまたはステー トレスのいずれかのモードで動作できる。ステートレスで動作するとき、 プロキシは単に転送(forward)を行うエレメントとして動作する。それは各リ クエストをダウンストリームに、そのリクエストに基づいてターゲットの決定 とルーティングの決定を行うことで確定された一つのエレメントに転送 (forward)する。それは受け取ったすべての応答を単にアップストリームに転送 (forward)する。ステートレスプロキシは、メッセージを転送(forward)すると すぐにそれについての情報を破棄する。ステートフルプロキシは、送られてく る各リクエストと送られてくるリクエストを処理した結果として送るすべての リクエストについての情報(具体的には、トランザクションステート)を憶えて いる。ステートフルプロキシはこの情報を、そのリクエストに関連する今後の メッセージの処理に影響を与えるために使用する。ステートフルプロキシは、 リクエストをフォークしたり、複数のデスティネーションにルートすることを 選択してもよい[MAY]。一つ以上の場所に転送(forward)されるすべてのリクエ ストはステートフルで操作されなければならない[MUST]。 ある状況下では、プロキシは、トランザクションがステートフルにならずに (TCPのような)ステートフルトランスポートを利用してリクエストを転送 (forward)してもよい[MAY]。例えば、プロキシは、一つのTCP接続から のリクエストを他のトランザクションにステートレスに転送してもよい[MAY] (そのリクエストが到着したのと同じコネクションを逆方向に、応答を転送 (forward)するのに十分な情報をメッセージ中に置きさえすれば)。異なるトラ ンスポートタイプ(プロキシのTUは、そのどちらかで確実な配送が行われるこ とを保証するための積極的な役割を果たさなければならない)のあいだで転送 (forward)されるリクエストは、トランザクションがステートフルな状態で転 送(forward)されなければならない[MUST]。 ステートフルプロキシは、ステートレスになることを妨げるようなことを最 初に何もしていなければ(例えば、フォークや100応答の生成)、リクエスト の処理中にいつでもステートレス動作に移行してもよい[MAY]。そのよ うな移行を行うとき、すべてのステートは単純に破棄される。プロキシは CANCELリクエストを開始するべきではない[SHOULD NOT]。 リクエストに対してステートレスまたはステートフルに動作するときに関わ る処理の多くは同じである。これ以降のいくつかのサブセクションは、ステー トフルプロキシの視点から書かれている。最後のサブセクションは、ステート レスプロキシが異なった動作をする点について述べている。 16.2 ステートフルプロキシ ステートフルで動作するとき、プロキシは純粋にSIPトランザクション処理エ ンジンである。その動作は、ここでは、セクション17で定義されるサーバー トランザクションおよびクライアントトランザクションの観点からモデル化 する。ステートフルプロキシは、プロキシコアとして知られる上位層のプロ キシ処理コンポーネント(図3参照)によって一つ以上のクライアントトランザ クションに関連付けられた、サーバートランザクションを持つ。送られてく Rosenberg, et. al. Standards Track [Page 92] RFC 3261 SIP: Session Initiation Protocol June 2002 るリクエストはサーバートランザクションによって処理される。サーバート ランザクションからのリクエストはプロキシコアに渡される。プロキシコア は、一つ以上のネクストホップの場所を選択して、そのリクエストをどこに ルートするか決定する。各ネクストホップの場所に対して送り出すリクエス トは、それら自身に関連付けられたクライアントトランザクションによって 処理される。プロキシコアはクライアントトランザクションからの応答を収 集し、それらをサーバートランザクションに応答を送るために使用する。 ステートフルプロキシは、受け取った各新規リクエストに対する新規サーバー トランザクションを生成する。リクエストのすべての再送はその後、セクショ ン17で述べられているように、そのサーバートランザクションによって 操作される。プロキシコアは、セクション8.2.6で述べられているように、そ のサーバートランザクション上で即時暫定応答を送ることに関してはUASとし て動作しなければならない[MUST](例えば100 Trying)。したがって、ステート フルプロキシは非INVITEリクエストに対して100(Trying)応答を生成するべき ではない[SHOULD NOT]。 これはプロキシの動作モデルであって、ソフトウェアの動作モデルではない。 実装では、このモデルが定義する外部動作を再現するどのようなアプローチ をとることもできる。 すべての新規リクエスト(未知のメソッドを持つものも含む)に対して、リク エストをプロキシしようとするエレメントは、必ず以下の事をしなければな らない[MUST]。 1. リクエストの有効性を検証する(セクション16.3) 2. ルーティング情報の前処理を行う(セクション16.4) 3. リクエストのターゲット(一つまたは複数)を確定する(セクション16.5) +--------------------+ | | +---+ | | | C | | | | T | | | +---+ +---+ | Proxy | +---+ CT = クライアントトランザクション | S | | "Higher" Layer | | C | | T | | | | T | ST = サーバートランザクション +---+ | | +---+ | | +---+ | | | C | | | | T | | | +---+ +--------------------+ 図3: ステートフルプロキシのモデル Rosenberg, et. al. Standards Track [Page 93] RFC 3261 SIP: Session Initiation Protocol June 2002 4. 各ターゲットにリクエストを転送(forward)する(セクション16.6) 5. すべての応答を処理する(セクション16.7) 16.3 リクエストの有効性検証 エレメントはリクエストをプロキシする前に、メッセージの有効性を検証し なければならない[MUST]。有効なメッセージは以下のチェックをパスしなけ ればならない。 1. 構文の合理性 2. URIスキーム 3. Max-Forwards 4. (任意の)ループ検知 5. Proxy-Require 6. Proxy-Authorization これらのチェックのうちどれかが失敗する場合、エレメントはユーザーエー ジェントサーバーとして動作して(セクション8.2参照)エラーコードで応答し なければならない[MUST]。 プロキシはマージされたリクエストを検知する必要はないことに注意するこ と。そして、マージされたリクエストをエラー状態として扱ってはならない [MUST NOT]ことにも注意すること。リクエストを受け取るエンドポイントが、 セクション8.2.2.2で述べられているようにマージを解決する。 1. 構文の合理性チェック リクエストは、サーバートランザクションで操作できるように、整形式 (well-formed)でなければならない[MUST]。これらの「リクエストの有効性 検証」ステップあるいは「リクエストの処理」セクションの結果として残っ た部分から成るコンポーネントは、整形式でなければならない[MUST]。そ れ以外のすべてのコンポーネントは、整形式かそうでないかに関わらず、 無視されてメッセージが転送(forward)されるときには変更されずにそのま まであるべきである[SHOULD]。例えば、エレメントは、Dateヘッダー フィールドの書式が正しくないことを理由にしてリクエストを拒否しな い。同様に、プロキシはリクエストを転送(forward)する前に、正しくない 書式のDateヘッダーフィールドを削除しない。 このプロトコルは拡張されることを考慮して設計されている。将来の拡張 ではいつでも新しいメソッドやヘッダーフィールドを定義できる。エレメ ントは、それが知らないメソッドやヘッダーフィールドをリクエストが含 むことを理由にして、そのリクエストをプロキシすることを拒否してはな らない[MUST NOT]。 Rosenberg, et. al. Standards Track [Page 94] RFC 3261 SIP: Session Initiation Protocol June 2002 2. URIスキームチェック Request-URIがプロキシの理解できないスキームのURIを持っている場合、 プロキシは416(Unsupported URI Scheme)応答でそのリクエストを拒否す るべきである[SHOULD]。 3. Max-Forwardsチェック Max-Forwardsヘッダーフィールド(セクション20.22)は、SIPリクエストが トラバースできるエレメントの数を制限するために使用される。 リクエストがMax-Forwardsヘッダーフィールドを含まない場合は、この チェックをパスする。 リクエストが、0よりも大きいフィールド値を持つMax-Forwardsヘッダー フィールドを含む場合は、このチェックをパスする。 リクエストが、フィールド値ゼロ(0)を持つMax-Forwardsヘッダーフィー ルドを含む場合、エレメントはそのリクエストを転送(forward)してはなら ない[MUST NOT]。リクエストがOPTIONSのためのものだった場合、エレメン トは最終受信者として動作してセクション11に基づいて応答してもよい [MAY]。そうでなければ、エレメントは483(Too many hops)応答を返さなけ ればならない[MUST]。 4. 任意のループ検知チェック エレメントはリクエストを転送(forward)する前に、転送(forward)のループ をチェックしてもよい[MAY]。リクエストが、そのプロキシによってそ れ以前のリクエストに入れられたのと同じsent-by値を持つViaヘッダー フィールドを含む場合、そのリクエストは、以前、このエレメントによって 転送(forward)されている。そのリクエストはループしているか、あるいは そのエレメントを通って正規にスパイラルしている。リクエストがループし ているかどうか確定するために、エレメントは、セクション16.6のステッ プ8に述べられているbranchパラメータの計算をこのメッセージで実行し て、それをViaヘッダーフィールド値で受け取ったパラメータと比較しても よい[MAY]。パラメータがマッチした場合、そのリクエストはループして いる。異なっていた場合は、そのリクエストはスパイラルしており、処理 は継続する。ループが検知された場合、エレメントは482(Loop Detected) 応答を返してもよい[MAY]。 5. Proxy-Requireチェック 将来のこのプロトコルの拡張では、プロキシによる特別な操作を要求する 機能を導入するかもしれない。エンドポイントは、これらの機能を使用す るリクエストに、プロキシがその機能を理解できなければリクエストを処 理しないことを伝えるための、Proxy-Requireヘッダーフィールドを含める だろう。 Rosenberg, et. al. Standards Track [Page 95] RFC 3261 SIP: Session Initiation Protocol June 2002 リクエストが、このエレメントが理解できない一つ以上のオプションタグ を持つProxy-Requireヘッダーフィールド(セクション20.29)を含む場合、 そのエレメントは420(Bad Extension)応答を返さなければならない[MUST]。 その応答はエレメントが理解できなかったオプションタグをリストした Unsupported(セクション20.40)ヘッダーフィールドを含まなければならな い[MUST]。 6. Proxy-Authorizationチェック エレメントがリクエストを転送(forward)する前に信用証明書を必要とする 場合、そのリクエストはセクション22.3で述べられているように検査されな ければならない[MUST]。セクション22.3では、検査が失敗した場合にエレ メントが何をしなければならないかも定義している。 16.4 ルート情報の前処理 プロキシはリクエストのRequest-URIを検査しなければならない[MUST]。リク エストのRequest-URIが、以前にこのプロキシがRecord-Routeヘッダーフィー ルドに置いた値を含んでいる場合(セクション16.6の項目4参照)、プロキシは リクエストのRequest-URIをRouteヘッダーフィールドの最後の値に置き換え て、Routeヘッダーフィールドからその値を削除しなければならない[MUST]。 それからプロキシは、この修正されたリクエストを受け取ったかのように処 理を進めなければならない[MUST]。 これは、リクエストをプロキシ(エンドポイントかもしれない)に送るエ レメントがストリクトルーターであるときにのみ起こる。受信時のこの書 き換えは、それらのエレメントとの下位互換を可能にするために必要で ある。これはまた、この仕様に従うエレメントがストリクトルーティン グを行うプロキシを経てもRequest-URIを維持することを可能にする(セ クション12.2.1.1参照)。 この要求は、プロキシが以前にRecord-Routeヘッダーフィールドに置い たURIを検知するためにステートを保持することを、プロキシに義務付 けるものではない。そうではなくてプロキシは、それらのURIがのちほ ど現れたときに、それらがそのプロキシが提供した値であることを認識 するのに十分な情報だけをそれらのURIに置くことが必要である。 Request-URIがmaddrパラメータを含む場合、プロキシはその値が、プロキシ が責任を負うように設定されたアドレスまたはドメインのセットの中にある かどうか確認しなければならない[MUST]。Request-URIがプロキシが責任を負 う値のmaddrパラメータを持ち、リクエストがそのRequest-URIで(明示的ある いはデフォルトで)示されるポートとトランスポートを使用して受信された場 合、プロキシはmaddrおよびすべての非デフォルトのポートまたはトランスポー トパラメータを取り去ってリクエストにそれらの値が存在しなかったかの ように処理を継続しなければならない[MUST]。 Rosenberg, et. al. Standards Track [Page 96] RFC 3261 SIP: Session Initiation Protocol June 2002 そのプロキシにマッチするmaddrを持つが、そのURIで示されるのとは違 うポートとトランスポートで、リクエストは到着するかもしれない。そ のようなリクエストは、示されたポートとトランスポートを使用してそ のプロキシに転送(forward)される必要がある。 最初のRouteヘッダーフィールド値がこのプロキシを示す場合、プロキシはリ クエストからその値を削除しなければならない[MUST]。 16.5 リクエストのターゲットの決定 次に、プロキシはリクエストのターゲット(一つまたは複数)を計算する。ター ゲットのセットは、リクエストのコンテンツであらかじめ決定されている か、あるいは抽象ロケーションサービスから取得されるかのいずれかである。 セット中のそれぞれのターゲットはURIで表される。 リクエストのRequest-URIがmaddrパラメータを含む場合、ターゲットセット に唯一のターゲットとしてそのRequest-URIが置かれなければならず[MUST]、 プロキシはセクション16.6の処理に進まなければならない[MUST]。 Request-URIのドメインがこのエレメントが責任を負わないドメインを示す場 合、ターゲットセットに唯一のターゲットとしてそのRequest-URIが置かれな ければならず[MUST]、エレメントはリクエストの転送(forward)のタスク(セク ション16.6)に進まなければならない[MUST]。 プロキシが、それが責任を負わないドメインに対するリクエストを受け 取るかもしれない、多くの状況がある。送り出される呼を操作するファ イアウォールプロキシ(HTTPプロキシが送り出されるリクエストを操作す る方法で)は、これが起こる可能性が高い場合のひとつの例である。 リクエストのためのターゲットセットが上述のようにあらかじめ決定されて いない場合は、Request-URIのドメインに対する責任をそのエレメントが負う ことを意味し、エレメントはリクエストをどこに送るか決定するために、そ れが望むどのような仕組みでも使用してもよい[MAY]。これらのどの仕組みも、抽 象ロケーションサービスにアクセスすることとしてモデル化できる。これは、 SIP登録サーバーによって作成されたロケーションサービスから情報を取得す ること、データベースから読み出すこと、プレゼンスサーバーを調べること、 他のプロトコルを使用することからなるか、あるいは単純に、それらを置き換 えるアルゴリズム的な処理をRequest-URIに対して実行することからなる。登 録サーバーによって構築されたロケーションサービスにアクセスするとき、 Request-URIはインデックスとして使用される前に、最初にセクション10.3で 述べられているように正規化(canonicalized)されなければならない[MUST]。 これらの仕組みの出力は、ターゲットセットを構築するために使用される。 プロキシがターゲットセットを決定するために十分な情報を、Request-URIが 提供しない場合、プロキシは485(Ambiguous)応答を返すべきである[SHOULD]。 この応答は、試行する新しいアドレスのURIを含むContactヘッダーフィール ドを含むべきである[SHOULD]。例えば、sip:John.Smith@company.comに対 Rosenberg, et. al. Standards Track [Page 97] RFC 3261 SIP: Session Initiation Protocol June 2002 するINVITEは、複数のJohn Smithをリストしているロケーションサービスを 参照するプロキシでは、あいまい(ambiguous)かもしれない。詳細はセクショ ン21.4.23参照。 リクエスト中の情報またはリクエストに関する情報、あるいはエレメントの 現在の環境が、ターゲットセットの構築に使用してもよい[MAY]。例えば、以下 の条件によって、異なるセットが構築されるかもしれない。 ・ヘッダーフィールドまたはボディの、コンテンツあるいはその存在 ・リクエストの到着する時間 ・リクエストが到着したインターフェース ・前回のリクエストの失敗 ・エレメントの現在の稼動レベル 可能性のあるターゲットはこれらのサービスを介して場所を特定されるので、 それらのURIはターゲットセットに追加される。ターゲットはターゲットセッ トに一度だけ置くことができる。ターゲットのURIが(URIタイプの等価性の定 義に基づいて)すでにターゲットセットに存在する場合、それは再度追加され てはならない[MUST NOT]。 プロキシは、オリジナルリクエストのRequest-URIがこのプロキシが責任を負 うリソースを示さない場合に、ターゲットセットに付加的なターゲットを追 加してはならない[MUST NOT]。 プロキシは、転送(forward)を行う間にだけリクエストのRequest-URI を(プロキシがそのURIに対して責任を負う場合)変更できる。プロキシ がそのURIに対して責任を負わない場合、以下に述べるように、それは 3xxまたは416応答で再帰を行わない。 オリジナルリクエストのRequest-URIがこのプロキシが責任を負うリソースを 示す場合、プロキシはリクエストの転送(forward)処理を始めた後にターゲット セットへのターゲット追加を継続してもよい[MAY]。プロキシは新しいターゲッ トを確定するために、その処理中に取得したどのような情報でも使用してもよ い[MAY]。例えば、プロキシはターゲットセットにリダイレクト応答(3xx)で取 得したコンタクト先を組み込むことを選択できる。プロキシが、ターゲット セットを構築している間に情報の動的ソースを使用する場合(例えば、SIP登 録サーバーを調べる場合)、プロキシはリクエストを処理するあいだそのソー スを監視するべきである[SHOULD]。新しい場所が有効になったら、それをター ゲットセットに追加するべきである[SHOULD]。上述のように、与えられたいか なるURIも2回以上ターゲットセットに追加してはならない[MUST NOT]。 URIをターゲットセットに1回だけ追加することを認めることは、不要な ネットワークトラフィックを減らし、また、リダイレクトのリクエストか らコンタクト先を組み込む場合には無限回の再帰を防止する。 例えば、普通のロケーションサービスは、ターゲットURIと送られてくるリ クエストのURI(request URI)が等しい、「no-op」である。リクエストは更な る処理のために特定のネクストホップに送られる。セクション16.6の項目6で Rosenberg, et. al. Standards Track [Page 98] RFC 3261 SIP: Session Initiation Protocol June 2002 述べられているリクエストの転送(forward)処理のあいだ、SIPまたはSIPS URIで 表現されているそのネクストホップのアイデンティティがRouteヘッダーフィー ルドの先頭の値としてリクエストに挿入される。 Request-URIがこのプロキシの存在しないリソースを示す場合、プロキシは 404(Not Found)応答を返さなければならない[MUST]。 上記のすべてを適用した後でもターゲットセットが空のままの場合、プロキ シはエラー応答を返さなければならない[MUST]。それは480(Temporarily Unavailable)応答であるべきである[SHOULD]。 16.6 リクエストの転送(forward) ターゲットセットが空でなくなるとすぐに、プロキシはリクエストの転送 (forward)を開始してもよい[MAY]。ステートフルプロキシはターゲットセット をどのような順番で処理してもよい[MAY]。ステートフルプロキシは複数のター ゲットを順に処理してもよい[MAY]。これは、各クライアントトランザクション を、次を開始する前に完了することを可能にする。ステートフルプロキシはす べてのターゲットのクライアントトランザクションを同時に開始してもよい [MAY]。ステートフルプロキシはターゲットセットを任意にグループ分けして もよい[MAY]。そうして、グループを順番に、各グループ中のターゲットを同 時に処理する。 一般的な順番付けの仕組みは、Contactヘッダーフィールドから取得したター ゲットのqvalueパラメータを使用する(セクション20.10参照)。ターゲット はqvalueの最も大きいものから最も小さいものの順で処理される。同じqvalue を持つターゲットは同時に処理されるかもしれない。 ステートフルプロキシは、応答を受け取ったときにターゲットセットを保持 し、転送(forward)された各リクエストに対する応答をオリジナルリクエストと 関連付けるための仕組みを持たなければならない。このモデルにとって、 この仕組みは、最初のリクエストを転送(forward)する前にプロキシレイ ヤーで生成された「応答コンテキスト(response context)」である。 各ターゲットに対して、プロキシは以下の手順に従ってリクエストを転送 (forward)する。 1. 受け取ったリクエストのコピーを作成する。 2. Request-URIをアップデートする。 3. Max-Forwardsヘッダーフィールドをアップデートする。 4. 任意にRecord-Routeヘッダーフィールド値を追加する。 5. 任意に付加的なヘッダーフィールドを追加する。 6. ルーティング情報の後処理をする。 7. ネクストホップのアドレス、ポート、およびトランスポートを確 定する。 Rosenberg, et. al. Standards Track [Page 99] RFC 3261 SIP: Session Initiation Protocol June 2002 8. Viaヘッダーフィールド値を追加する。 9. 必要なら、Content-Lengthヘッダーフィールドを追加する。 10. 新しいリクエストを転送(forward)する。 11. タイマーCを設定する。 これらの各手順を以下に詳述する。 1. リクエストをコピーする プロキシは受け取ったリクエストをコピーすることから始める。 コピーは最初の状態では、受け取ったリクエストのすべてのヘッ ダーフィールドを含まなければならない[MUST]。以下で述べられ る処理で詳述されていないフィールドは取り除いてはならない [MUST NOT]。コピーはヘッダーフィールドの順番を受け取ったリ クエストのとおり維持するべきである[SHOULD]。プロキシは一般 的なフィールド名を持つフィールド値を並べ替えてはならない [MUST NOT](セクション7.3.1参照)。プロキシはメッセージボディ を追加、修正、削除してはならない[MUST NOT]。 実際の実装ではコピーを実行する必要はない。主要な要件は、各 ネクストホップの処理が同じリクエストで開始されるということ である。 2. Request-URI コピーのスタートライン中のRequest-URIは、このターゲットのURI で置き換えられなければならない[MUST]。URIがRequest-URIで許 可されていない何らかのパラメータを含む場合、それらは取り除 かれなくてはならない[MUST]。 これはプロキシの役割の本質である。これはプロキシがリクエス トをそれのデスティネーションにルートする仕組みである。 ある状況下では、受け取ったRequest-URIは修正されることなしに ターゲットセットに置かれる。そのターゲットに対しては、上記 の置き換え処理では事実上何も行われない(no-op)。 3. Max-Forwards コピーがMax-Forwardsヘッダーフィールドを含む場合、プロキシ はその値を1だけ減少させなければならない[MUST]。 コピーがMax-Forwardsヘッダーフィールドを含まない場合、プロ キシは、1つのフィールド値と共にそれを追加しなければならなず [MUST]、そのフィールド値は70であるべきである[SHOULD]。 いくつかの既存のUAは、リクエストでMax-Forwardsヘッダーフィー ルドを提供しない。 Rosenberg, et. al. Standards Track [Page 100] RFC 3261 SIP: Session Initiation Protocol June 2002 4. Record-Route このプロキシが、このリクエストで生成されたダイアログ(リクエ ストがダイアログを生成したと仮定している)の今後のリクエスト のパスに残ることを望む場合は、たとえRouteヘッダーフィールド が既に存在していたとしても、Record-Routeヘッダーフィールド 値をこのコピーの既存のすべてのRecord-Routeヘッダーフィール ド値の前に挿入しなければならない[MUST]。 ダイアログを確立するリクエストはプリロードされたRouteヘッダー フィールドを含むかもしれない。 このリクエストがすでにダイアログの一部である場合、プロキシ は、ダイアログの今後のリクエストのパスに残ることを望む場合、 Record-Routeヘッダーフィールド値を挿入するべきである[SHOULD]。 セクション12で述べられているように通常のエンドポイント操作 においては、これらのRecord-Routeヘッダーフィールド値は、エ ンドポイントが使用するルートセットに何の影響も及ぼさない。 プロキシが、既にダイアログの一部であるリクエストにRecord-Route ヘッダーフィールド値を挿入しないことを選択する場合、プロキ シはパスに残ることができる。しかしながら、エンドポイントが ダイアログの再構成に失敗したときにプロキシはパスから取り除 かれる。 プロキシはいかなるリクエストにもRecord-Routeヘッダーフィー ルド値を挿入してもよい[MAY]。リクエストがダイアログを開始し ない場合、エンドポイントはその値を無視する。エンドポイント がRouteヘッダーフィールドを構築するためにRecord-Routeヘッダー フィールド値をどのように使用するかのついての詳細は、セクショ ン12を参照のこと。 リクエストのパス中の各プロキシは、Record-Routeヘッダーフィー ルド値を追加するかどうかを独自に選択する。リクエストにRecord- Routeヘッダーフィールドが存在することは、プロキシが値を追加す ることを義務化するものではない。 Record-Routeヘッダーフィールド値に置かれたURIは、SIP URIまた はSIPS URIでなければならない[MUST]。このURIはlrパラメータを 含まなければならない[MUST](セクション19.1.1参照)。このURIは リクエストが転送(forward)される各デスティネーションごとに異な ってもよい[MAY]。プロキシが、これ以降のリクエストのパスにある ネクストダウンストリームエレメントがそのトランスポートをサ ポートするという知識(例えばプライベートネットワーク内で)を持 つのでなければ、URIはトランスポートパラメータを含むべきでは ない[SHOULD NOT]。 このプロキシが提供するURIは、ルーティングの決定を行うために 他のエレメントによって使用される。一般的に、このプロキシは そのエレメントがどのような能力を持つのか知るすべはない。そ のため、それはそれ自身をSIP実装の必須エレメントに限定しなけ ればならない。すなわち、SIP URI、および、TCPまたはUDPトラン スポートのいずれかである。 Rosenberg, et. al. Standards Track [Page 101] RFC 3261 SIP: Session Initiation Protocol June 2002 Record-Routeヘッダーフィールドに置かれたURIは、参考文献[4] のサーバーの位置特定手順が適用されたときに、それ以降のリク エストが同じSIPエレメントに到着するように、それを挿入したエ レメント(または適切な代理)になるように解決されなければなら ない[MUST]。Request-URIがSIPS URIを含むか、またはRouteヘッ ダーフィールドの先頭の値が(項目6の後処理の後に)SIPS URIを含 む場合、Record-Routeヘッダーフィールドに置かれたURIはSIPS URIでなければならない[MUST]。さらに、リクエストがTLS上で受 信されたのでなければ、プロキシはRecord-Routeヘッダーフィー ルドを挿入しなければならない[MUST]。同様に、TLS上でリクエス トを受け取るが、Request-URIまたは(項目6の後処理の後に)Route ヘッダーフィールドの先頭の値に、SIPS URIを持たないリクエス トを生成するプロキシは、SIPS URIでないRecord-Routeヘッダー フィールドを挿入しなければならない[MUST]。 セキュリティの境界にあるプロキシは、ダイアログ全体を通して その境界にい続けなければならない。 Record-Routeヘッダーフィールドに置かれたURIが、応答で送り返 される過程で書き換えられる必要がある場合、そのURIはその時点 で場所を特定するのに十分明確でなければならない[MUST]。(リク エストはこのプロキシを通ってスパイラルするかもしれず、結果 的に一つ以上のRecord-Routeヘッダーフィールド値が追加される ことになる)。セクション16.7の項目8でURIを十分に明確にする仕 組みを推奨する。 プロキシはRecord-Routeヘッダーフィールド値にパラメータを含 めてもよい[MAY]。これらは、INVITEに対する200(OK)応答のよう な、リクエストに対するある種の応答で返される。このようなパ ラメータは、プロキシではなくメッセージにステートを保持するた めに有用であるかもしれない。 プロキシがどれかのタイプのダイアログのパスにいることが必要 な場合(例えば、ファイアウォールをまたぐダイアログ)、それ は、それが理解できないメソッドを持つすべてのリクエストに(そ のメソッドがダイアログセマンティクスを持つかもしれないので) Record-Routeヘッダーフィールド値を追加するべきである[SHOULD]。 プロキシがRecord-Routeヘッダーフィールドに置くURIは、それが 発生したトランザクションで生成されたすべてのダイアログの生 存期間のあいだのみ有効である。例えばダイアログステートフ ルプロキシは、Request-URIにその値を持つ今後のリクエストの受 け入れを、ダイアログが終了した後は、拒否してもよい[MAY]。 当然ながら、非ダイアログステートフルプロキシはダイアログが いつ終了したかについての概念を持たないが、非ダイアログステー トフルプロキシは今後のリクエストのダイアログ識別子と比較する ために十分な情報をその値にエンコードしてもよく[MAY]、その情 報にマッチしないリクエストを拒否してもよい[MAY]。エンドポイ ントはダイアログ外で提供されたRecord-Routeヘッダーフィールド から取得したURIを使用してはならない[MUST NOT]。エンドポイント のRecord-Routeヘッダーフィールドの用法についての詳細はセクショ Rosenberg, et. al. Standards Track [Page 102] RFC 3261 SIP: Session Initiation Protocol June 2002 ン12を参照のこと。 プロキシがダイアログ中のすべてのメッセージを観察する必要が ある特定のサービスでは、Record-Routeすることが必要とされる かもしれない。しかしながら、それは処理を遅くし、スケーラビ リティを損なうので、プロキシは特定のサービスで必要とされた 場合にのみRecord-Routeするべきである。 Record-Route処理は、ダイアログを開始するすべてのSIPリクエス トで動作するように設計されている。この仕様においては、INVITE がそのような唯一のリクエストであるが、プロトコルの拡張はそ の他のものを定義してもよい[MAY]。 5. 付加的なヘッダーフィールドを追加する プロキシは、この時点で、他のすべての適切なヘッダーフィール ドをコピーに追加してもよい[MAY]。 6. ルーティング情報の後処理をする プロキシは、リクエストがデスティネーションに配送される前に 特定のプロキシのセットを通ることを義務化する、ローカルポリ シーを持ってもよい[MAY]。プロキシは、そのようなプロキシはす べてルースルータであることを保証しなければならない[MUST]。 一般的に、これは、プロキシが同じ管理ドメイン内にいる場合に だけ確実に知ることができる。このプロキシのセットはURIのセッ トで表される(それぞれのURIは、lrパラメータを含む)。このセッ トは、コピーのRouteヘッダーフィールドの(存在すれば)すべての 既存の値の前に挿入されなければならない[MUST]。Routeヘッダー フィールドがない場合には、URIのリストを含めて、Routeヘッダー フィールドが追加されなければならない[MUST]。 プロキシが、リクエストがひとつの特定のプロキシを通ることを 義務付けるローカルポリシーを持つ場合、Routeヘッダーフィール ドにRoute値を挿入することの代替手段は、下記の項目10の転送 (forward)ロジックをバイパスして、そのかわりにその特定のプロキ シのアドレス、ポート、トランスポートに単純にリクエストを送る ことである。リクエストがRouteヘッダーフィールドを持つ場合、 ネクストホップのプロキシがルースルータであると知っているの でなければ、この代替手段を使用してはならない[MUST NOT]。 そうでなければ、このアプローチは使用してもよい[MAY]が、上記の Route挿入の仕組みがそれの操作の堅牢性、フレキシビリティ、 普遍性と一貫性のために好ましい。さらに、Request-URIがSIPS URI を含む場合、そのプロキシと通信するためにTLSを使用しなければ ならない[MUST]。 コピーがRouteヘッダーフィールドを含む場合、プロキシはそれの 最初の値に含まれるURIを検査しなければならない[MUST]。そのURI がlrパラメータを含まない場合、プロキシはコピーを以下のよう に修正しなければならない[MUST]。 Rosenberg, et. al. Standards Track [Page 103] RFC 3261 SIP: Session Initiation Protocol June 2002 - プロキシはRouteヘッダーフィールドに、それの最後の値として、 Request-URIを置かなければならない[MUST]。 - それからプロキシは、最初のRouteヘッダーフィールド値を Request-URIに置いて、Routeヘッダーフィールドからその値を 削除しなければならない[MUST]。 RouteヘッダーフィールドにRequest-URIを追加することは、スト リクトルーティングを行うエレメントを通してそのRequest-URIの 情報を渡すために使用される仕組みの一部である。最初の Routeヘッダーフィールド値をRequest-URIに移動することは、ス トリクトルーティングを行うエレメントが受け取ることを期待し ている形に(それ自身のURIをRequest-URIに、次に通る場所を最初 のRouteヘッダーフィールド値に)そのメッセージを形成すること になる。 7. ネクストホップのアドレス、ポート、およびトランスポートを確定 する プロキシは、RouteおよびRequest-URIの値に依存せずに特定のIPア ドレス、ポート、トランスポートにリクエストを送るためのローカ ルポリシーを持ってもよい[MAY]。そのようなポリシーは、ルース ルータであるサーバーに対応するIPアドレス、ポート、トランス ポートをプロキシが確実に知らない場合は、使用してはならない [MUST NOT]。しかしながら、特定のネクストホップを通してリクエ ストを送るためのこの仕組みは推奨されない[NOT RECOMMENDED]。 そのかわりに上述したようにこの目的のためにはRouteヘッダー フィールドが使用されるべきである。 このようなオーバーライドの仕組みがない場合には、リクエス トをどこに送るか決定するために、以下のように参考文献[4]にリ ストされている手順を、プロキシは適用する。プロキシが、上記 のステップ6で述べられたようにストリクトルーティングを行うエ レメントに送るリクエストを再形成した場合、プロキシはリクエ ストのRequest-URIにそれらの手順を適用しなければならない[MUST]。 そうでなければ、プロキシはその手順を最初のRouteヘッダーフィー ルド値に(存在すれば)、さもなければRequest-URIに適用しなけ ればならない[MUST]。この手順は順番に並べられたタプル(tuples) (アドレス、ポート、トランスポート)のセットを生成する。参考 文献[4]の手順の入力としてどのURIが使用されるかに関係なく、 Request-URIがSIPSリソースを明示する場合、プロキシは入力され たURIがSIPS URIであるかのように参考文献[4]の手順にしたがわ なければならない[MUST]。 参考文献[4]で述べられているように、プロキシはそのセットの最 初のタプルにメッセージを配送することを試み、そして配送の試 みが成功するまでセットの中を順番に処理していかなければなら ない[MUST]。 それぞれのタプルの試行では、プロキシはそのタプルに適切なよ うにメッセージを形成してステップ8から10で述べられているよう に新規クライアントトランザクションを使用してそのリクエスト を送らなければならない[MUST]。 Rosenberg, et. al. Standards Track [Page 104] RFC 3261 SIP: Session Initiation Protocol June 2002 各試行は新規クライアントトランザクションを使用するので、そ れは新しいbranchを意味することになる。したがって、ステップ8 で挿入されるViaヘッダーフィールドで提供されるbranchパラメー タは、各試行で異ならなければならない[MUST]。 クライアントトランザクションがそれのステートマシンから、リ クエスト送信の失敗またはタイムアウトの報告をする場合、プロ キシは、順番に並べられたセット中の次のアドレスで処理を継続 する。順番に並べられたセットの最後までいった場合、リクエス トはターゲットセットのこのエレメントに転送(forward)できない。 プロキシは応答コンテキストに何も置く必要はないが、ターゲッ トセットのこのエレメントがあたかも408(Request Timeout)最終 応答を返したかのように動作する。 8. Viaヘッダーフィールド値を追加する プロキシは、コピーの既存のViaヘッダーフィールド値の前にVia ヘッダーフィールド値を挿入しなければならない[MUST]。この値 の構築はセクション8.1.1.7と同じガイドラインに従う。これ は、プロキシが、そのbranchのためのグローバルに一意で必須の マジッククッキーを含む、それ自身のbranchパラメータを計算す ることを意味する。このことは、プロキシ経由のスパイラルまた はループしたリクエストの異なるインスタンスでは、branchパラ メータが異なることを暗示する、ということに注意。 ループを検知することを選択するプロキシは、branchパラメータ の構築に使用する値に関して付加的な制約を持つ。ループを検知 することを選択するプロキシは、実装によって2つの部分に分離可 能なbranchパラメータを作成するべきである[SHOULD]。最初の部 分は上述のようにセクション8.1.1.7の制約を満たさなければなら ない[MUST]。2つめの部分はループ検知を実行するため、およびルー プをスパイラルと区別するために使用される。 ループの検知は、リクエストがプロキシに戻ってきたときに、リ クエストの処理に大きな影響を及ぼすフィールドが変更されてい ないことを検証をすることによって実行される。branchパラメー タのこの部分に置かれる値は、それらのすべてのフィールド(すべ てのRoute、Proxy-Require、およびProxy-Authorizationヘッダー フィールドを含む)を反映するべきである[SHOULD]。これは、リク エストがプロキシにルートされて戻ってきて、それらのフィール ドの一つが変更されていた場合に、それがループではなくスパイ ラルとして扱われること(セクション16.3参照)を保証するためで ある。この値を生成するための一般的な方法は、(存在するかもし れないすべてのProxy-RequireとProxy-Authorizationヘッダー フィールドに加えて)To tag、From tag、Call-IDヘッダーフィール ド、受け取ったリクエストの(変換前の)Request-URI、先頭のVia ヘッダー、およびCSeqヘッダーフィールドのシーケンス番号の 暗号ハッシュを計算することである。 Rosenberg, et. al. Standards Track [Page 105] RFC 3261 SIP: Session Initiation Protocol June 2002 ハッシュを計算するために使用されるアルゴリズムは実装に依存 するが、16進数で表現されたMD5(RFC1321 参考文献[35])が妥当な 選択である。(Base64はトークンとして許可されない。) プロキシがループを検知することを望む場合、それが供給する branchパラメータは、送られてくるRequest-URIとリクエストの許 可(admission)とルーティング決定に影響を及ぼすすべてのヘッダー フィールドを含めて、リクエスト処理に影響を及ぼすすべての 情報に依存しなければならない[MUST]。これは、ループしたリク エストとこのサーバーに戻ってくる前にルーティングパラメータ が変更されたリクエストを区別するために必要である。 リクエストのメソッドはbranchパラメータの計算に含めてはなら ない[MUST NOT]。特に、CANCELリクエストとACKリクエスト(非2xx 応答に対する)は、それがキャンセルまたは同意する対応するリク エストのものと同じbranch値を持たなければならない[MUST]。 branchパラメータは、リクエストを操作するサーバーで、リクエス トを関連付けるために使用される。(セクション17.2.3およびセク ション9.2参照)。 9. 必要であれば、Content-Lengthヘッダーフィールドを追加する リクエストがストリームベースのトランスポートを使用して送ら れることになり、かつ、コピーがContent-Lengthヘッダーフィー ルドを含まない場合、プロキシはリクエストのボディに対して正 しい値を持つContent-Lengthヘッダーフィールドを挿入しなけれ ばならない[MUST](セクション20.14参照)。 10. リクエストを転送(forward)する ステートフルプロキシは、セクション17.1に述べられているよう にこのリクエストのために新規クライアントトランザクションを 生成してそのトランザクションにステップ7で決定されたアドレス、 ポート、トランスポートを使用してリクエストを送るように指示 しなければならない[MUST]。 11. タイマーCを設定する INVITEリクエストがいつまでも最終応答を生成しない場合を操作 するために、TUはタイマーCと呼ばれるタイマーを使用する。タイ マーCは、INVITEリクエストがプロキシされたときにそれぞれのク ライアントトランザクションに対して設定されなければならな い[MUST]。タイマーCは3分よりも長くなければならない[MUST]。 セクション16.7の項目2で、このタイマーを暫定応答でどのように アップデートするかについて議論する。また、セクション16.8で、 タイマーが切れたときの処理について議論する。 Rosenberg, et. al. Standards Track [Page 106] RFC 3261 SIP: Session Initiation Protocol June 2002 16.7 応答の処理 エレメントが応答を受け取るとき、エレメントはその応答にマッチするクラ イアントトランザクションの場所を特定することを最初に試みる(セクション 17.1.3)。一つも見つからない場合、エレメントはその応答を(たとえそれが 通知応答だとしても)ステートレスプロキシ(以下に記述されている)として処 理しなければならない[MUST]。マッチするものが見つかった場合、応答はク ライアントトランザクションに渡される。 対応するクライアントトランザクション(あるいはより一般的には、関 連付けられたリクエストを送ったという知識)が見つからない応答を転 送(forward)することは堅牢性を高める。とりわけそれは、INVITEリク エストに対する「遅れた」2xx応答が適切に転送(forward)されることを 保証する。 クライアントトランザクションが応答をプロキシレイヤーに渡すときは、以 下の処理が行われなければならない[MUST]。 1. 適切な応答コンテキストを探し出す。 2. 暫定応答に対してタイマーCをアップデートする。 3. 最初のViaを取り除く。 4. 応答コンテキストに応答を追加する。 5. この応答が直ちに転送(forward)されるべきかどうか確認する。 6. 必要なときは、応答コンテキストから最適な最終応答を選択する。 応答コンテキストに関連付けられたすべてのクライアントトランザクション が終了した後に、最終応答が一つも転送(forward)されていない場合、プロキシ は、これまでに見たそれらのなかから「最適の」応答を選択して転送(forward) しなければならない。 転送(forward)される各応答において、以下の処理が実行されなければならない [MUST]。各リクエストに対して2つ以上の応答が転送(forward)されることがあり 得る。少なくとも各暫定応答と一つの最終応答である。 7. 必要であれば認可のためのヘッダーフィールド値を集約する 8. 任意でRecord-Routeヘッダーフィールド値を書き換える 9. 応答を転送(forward)する 10. 必要なすべてのCANCELリクエストを生成する Rosenberg, et. al. Standards Track [Page 107] RFC 3261 SIP: Session Initiation Protocol June 2002 上記の各手順を以下に詳述する。 1. コンテキストを見つける プロキシは、オリジナルリクエストを転送(forward)する前に、セク ション16.6で述べられているキーを使用して、それが生成した「 応答コンテキスト」を探し出す。残りの処理手順はこのコンテキ ストで行われる。 2. 暫定応答に対してタイマーCをアップデートする INVITEトランザクションにおいて、応答がステータスコード101〜 199(すなわち、100以外)の暫定応答である場合、プロキシはその クライアントトランザクションのタイマーCをリセットしなければ ならない[MUST]。タイマーCは別の値にリセットしてもよい[MAY] が、この値は3分よりも長くなければならない[MUST]。 3. Via プロキシは応答から最初のViaヘッダーフィールド値を取り除く。 応答にViaヘッダーフィールド値が一つも残らない場合、その応答 はこのエレメントに宛てられたものであるので、転送(forward)して はならない[MUST NOT]。このセクションで述べられている残りの 処理はこのメッセージには実行されない。そのかわりに、セクショ ン8.1.3で述べられているUACの処理ルールに従う(トランス ポートレイヤーの処理は既に行われている)。 例えば、セクション10で述べられているようにエレメントがCANCEL リクエストを生成するときにこれが起こる。 4. コンテキストに応答を追加する 受け取った最終応答は、このコンテキストに関連付けられたサー バートランザクションで最終応答が生成されるまで、応答コンテ キストに保存される。その応答は、そのサーバートランザクショ ンで返される最適な最終応答の候補になるかもしれない。この応 答からの情報は、この応答が選択されなかったとしても、最適な 応答を形成するときに必要になるかもしれない。 プロキシが、3xx応答のコンタクト先をターゲットセットに追加す ることで、それらのうちのどれかに再帰(recurse)することを選択 した場合、プロキシは応答を応答コンテキストに追加する前にそ の応答からそれらを取り除かなければならない[MUST]。しかしな がら、プロキシは、オリジナルリクエストのRequest-URIがSIPS URIの場合に非SIPS URIに再帰するべきではない[SHOULD NOT]。 Rosenberg, et. al. Standards Track [Page 108] RFC 3261 SIP: Session Initiation Protocol June 2002 プロキシが3xx応答のすべてのコンタクト先に再帰する場合、プロ キシはその結果としてのコンタクト先を持たない応答を応答コンテ キストに追加するべきではない[SHOULD NOT]。 応答を応答コンテキストに追加する前にコンタクト先を取り除く ことは、アップストリームの次のエレメントがこのプロキシがす でに試行した場所を再試行することを防止する。 3xx応答はSIP URI、SIPS URI、および非SIP URIが混ざったものを 含むかもしれない。プロキシは、SIP URIおよびSIPS URIに再帰す ることを選択し、残りを最終応答で返される可能性のある応答コ ンテキストに置くかもしれない。 プロキシが、Request-URIのスキームがSIPでなかった(しかしオリ ジナルに受け取ったリクエストのスキームはSIPまたはSIPSであっ た)(すなわち、プロキシするときにプロキシがスキームをSIPまた はSIPSからそれ以外のものに変更した)リクエストに対して416( Unsupported URI Scheme)応答を受け取る場合、プロキシはターゲッ トセットに新しいURIを追加するべきである[SHOULD]。このURI は、今試行したばかりの非SIP URIに対応するSIP URIであるべき である[SHOULD]。tel URLの場合は、tel URLのtelephone-subscriber 部分をSIP URIのユーザー部分に、そしてホスト部分に前回のリク エストを送ったドメインを設定することで、これが実現できる。 tel URLからSIP URIを形成することについての更なる詳細は、セ クション19.1.6参照のこと。 3xx応答と同様に、プロキシがSIP URIまたはSIPS URIで試行する ことによって416で「再帰」する場合、416応答は応答コンテキス トに追加されるべきではない[SHOULD NOT]。 5. 転送(forward)する応答を確認する 最終応答がサーバートランザクションで送られてしまうまで、以 下の応答は直ちに転送(forward)されなければならない[MUST]。 - 100(Trying)以外のすべての暫定応答 - すべての2xx応答 6xx応答を受け取る場合、それは直ちに転送(forward)されないが、 ステートフルプロキシはペンディングされているすべてのクライア ントトランザクションをセクション10で述べられているようにキャ ンセルするべきであり[SHOULD]、このコンテキストでいかなる新規 branchも生成してはならない[MUST NOT]。 これは、6xxを直ちに転送(forward)することを義務付けていたRFC 2543からの変更である。INVITEトランザクションにおいては、この アプローチは2xxが別のbranchで到着する可能性があるという問題を Rosenberg, et. al. Standards Track [Page 109] RFC 3261 SIP: Session Initiation Protocol June 2002 かかえていた。その場合、プロキシはその2xxを転送(forward)しな ければならないだろう。結果として、決して起こることが認められ るべきでない、2xx応答が後に続く6xx応答をUACが受け取ることがあ りうる。新しいルールの下では、6xxを受け取ったときに、プロキシ はCANCELリクエストを発行し(これによって、通常、すべての未解決 のクライアントトランザクションが487応答という結果になる)、そ れからその時点で6xxをアップストリームに転送(forward)する。 サーバートランザクションで最終応答が送られた後で、以下の応 答が直ちに転送(forward)されなければならない[MUST]。 - INVITEリクエストに対するすべての2xx応答 ステートフルプロキシはそれ以外の応答を直ちに転送(forward)して はならない[MUST NOT]。特に、ステートフルプロキシはすべての100 (Trying)応答を転送(forward)してはならない[MUST NOT]。「最適な」 応答として後に転送(forward)するための候補である応答が、「コン テキストに応答を追加する」手順で述べられているように収集さ れた。 直ちに転送(forward)するために選ばれたすべての応答は、「認可の ためのヘッダーフィールド値をまとめる」から「Record-Route」 の手順で述べられているように処理されなければならない[MUST]。 この手順は、次の手順と合わせて、ステートフルプロキシが非INVITE リクエストに対して正確に一つの最終応答を転送(forward)すること と、INVITEリクエストに対して正確に一つの非2xx応答または一つ 以上の2xx応答を転送(forward)することを保証する。 6. 最適な応答を選択する ステートフルプロキシは、上記のルールによって最終応答が一つ も直ちに転送(forward)されておらず、この応答コンテキスト中の すべてのクライアントトランザクションが終了している場合、応答 コンテキストのサーバートランザクションに対して最終応答を送 らなければならない[MUST]。 ステートフルプロキシは、受け取って応答コンテキストに保存さ れたものの中から「最適な」最終応答を選ばなければならない[MUST]。 応答コンテキストの中に最終応答が一つもない場合、プロキシは サーバートランザクションに408(Request Timeout)応答を送らな ければならない[MUST]。 さもなくば、プロキシは応答コンテキストに保存された応答の中 から一つの応答を転送(forward)しなければならない[MUST]。プロキ シは応答コンテキストに6xxクラス応答があればその中から選択し なければならない[MUST]。6xxクラス応答が存在しない場合、プロ キシは応答コンテキストに保存されている最下位の応答クラスか ら選択するべきである[SHOULD]。プロキシは選択したクラスから どの応答を選択してもよい[MAY]。プロキシは、このリクエストの Rosenberg, et. al. Standards Track [Page 110] RFC 3261 SIP: Session Initiation Protocol June 2002 再提出に影響を及ぼす情報を提供する応答にプリファレンスを与 えるべきである[SHOULD]。例えば、4xxクラスが選択された場合に は、401、407、415、420、484というように。 503(Service Unavailable)応答を受け取るプロキシは、今後プロ キシするかもしれないすべてのリクエストも503を生成すると確定 できなければ、それをアップストリームに転送(forward)するべきで はない[SHOUL NOT]。言い換えると、503を転送(forward)するという ことは、そのプロキシが、503を生成したリクエスト中のRequest- URIに対してだけでなく、どのリクエストにもサービスできないこ とをそれ自身が知っていることを意味する。受け取った唯一の応 答が503の場合、プロキシは500応答を生成してそれをアップスト リームに転送(forward)するべきである[SHOULD]。 転送(forward)された応答は、「認可のためのヘッダーフィールド値 をまとめる」から「Record-Route」の手順で述べられているよう に処理されなければならない[MUST]。 例えば、プロキシが4つの場所にリクエストを転送(forward)し、 503、407、501、および404応答を受け取った場合、それは407( Proxy Authentication Required)応答を転送(forward)することを選 択できる。 ダイアログの確立には1xxおよび2xx応答が関与するかもしれない。 リクエストがTo tagを含まないとき、応答中のTo tagはダイアロ グを生成するリクエストに対する複数の応答を区別するためにUAC が使用する。プロキシは、リクエストがTo tagを含んでいなけれ ば、1xxまたは2xx応答のToヘッダーフィールドにtagを挿入しては ならない[MUST NOT]。プロキシは1xxまたは2xx応答のToヘッダー フィールドのtagを修正してはならない[MUST NOT]。 プロキシは、To tagを含まなかったリクエストに対する1xx応答の Toヘッダーフィールドにtagを挿入しないかもしれないので、プロ キシはそれ自身で非100暫定応答を発行できない。しかしながら、 プロキシは、プロキシとして同じエレメントを共有するUASにリク エストをブランチできる。このUASは、そのリクエストのイニシエー ターとearlyダイアログに入ることで、それ自身の暫定応答を返 すことができる。UASはプロキシから分離した処理である必要は ない。それはプロキシと同じコード空間に実装されたバーチャル UASであり得る。 3-6xx応答はホップバイホップで配送される。3-6xx応答を発行す るとき、エレメントは、通常ダウンストリームエレメントから受 け取った応答に基づいてそれ自身の応答を発行しながら、実質的 にUASとして動作している。エレメントはTo tagを含まなかった リクエストに対する3-6xx応答を単純に転送(forward)するときは、 To tagを保つべきである[SHOULD]。 プロキシはTo tagを含むリクエストに対する転送(forward)されたい かなる応答のTo tagも修正してはならない[MUST NOT]。 Rosenberg, et. al. Standards Track [Page 111] RFC 3261 SIP: Session Initiation Protocol June 2002 プロキシが転送(forward)された3-6xx応答のTo tagを置き換えても アップストリームエレメントに対して重大な影響はないが、オリジ ナルのtagを保つことはデバッグの役に立つかもしれない。 プロキシがいくつかの応答から情報を集約するとき、それらの中 からTo tagを選択することは任意であり、新しいTo tagを生成す ることはデバッグを容易にするかもしれない。これは、例えば、 401(Unauthorized)と407(Proxy Authentication Required)チャレ ンジを結合するとき、あるいは暗号化されておらず認証もされて いない3xx応答のContact値を結合するときに、起こる。 7. 認可のためのヘッダーフィールド値を集約する 選択された応答が401(Unauthorized)あるいは407(Proxy Authenti cation Required)の場合、プロキシは、この応答コンテキストで これまでに受け取った他のすべての401(Unauthorized)と407(Proxy Authentication Required)応答からすべてのWWW-Authenticateヘッ ダーフィールドとProxy-Authenticateヘッダーフィールドを収 集し、転送(forward)する前にそれらをこの応答に修正せずに追加し なければならない[MUST]。結果としての401(Unauthorized)または 407(Proxy Authentication Required)応答はいくつかのWWW- Authenticateおよび(AND)Proxy-Authenticateヘッダーフィールド 値を持つことがあり得る。 リクエストが転送(forward)されたデスティネーションのどれかある いはすべてが信用証明書を要求していたかもしれないので、これ は必須である。クライアントは、そのリクエストをリトライする ときに、それらすべてのチャレンジを受け取り、それらの各々に 対して信用証明書を供給する必要がある。この動作の動機付けは セクション26で提供される。 8. Record-Route 選択した応答がもともとこのプロキシが提供したRecord-Routeヘッ ダーフィールド値を含む場合、プロキシはその応答を転送 (forward)する前にその値を書き換えることを選択してもよい[MAY]。 これはそのプロキシが、次のアップストリームエレメントおよびダ ウンストリームエレメントに、それ自身の別のURI(複数)を提供する ことを可能にする。プロキシはどのような理由でもこの仕組みを使 用することを選択してもよい。例えば、それはマルチホームホスト に対して有用である。 プロキシがTLS上でリクエストを受け取り、非TLS接続でそれを送 る場合、プロキシはRecord-RouteヘッダーフィールドのURIをSIPS URIに書き換えなければならない[MUST]。プロキシが非TLS接続で リクエストを受け取り、TLS上でそれを送る場合、プロキシは Record-RouteヘッダーフィールドのURIをSIP URIに書き換えなけ ればならない[MUST]。 Rosenberg, et. al. Standards Track [Page 112] RFC 3261 SIP: Session Initiation Protocol June 2002 プロキシによって提供された新しいURIは、リクエストのRecord- Routeヘッダーフィールドに置かれるURIに対するものと同じ制約 (セクション16.6のステップ4参照)を、以下の変更点と共に満たさ なければならない[MUST]。 今後のリクエストのパスにある次のアップストリーム(ダウンスト リームとは逆に)エレメントが、そのトランスポートをサポートす るという知識を持っていない限り、URIはトランスポートパラメー タを含むべきではない[SHOULD NOT]。 プロキシが応答のRecord-Routeヘッダーフィールドの修正を決定 するとき、それが実行する操作のひとつは、それが挿入したRecord- Route値を見つけ出すことである。そのリクエストがスパイラルし、 プロキシがスパイラルの各繰り返し(iteration)でRecord-Routeを 挿入した場合、応答の中に正しい値を見つけること(それは反対方 向への適切な繰り返し(iteration)でなければならない)は厄介で ある。上記のルールは、Record-Routeヘッダーフィールド値の書 き換えを望むプロキシが、書き換える正しいRecord-Routeヘッダー フィールドが選択されるように、Record-Routeヘッダーフィールド に十分に明瞭なURIを挿入することを推奨する。これを実現する ために推奨される[RECOMMENDED]仕組みは、プロキシがURI のユーザー部分にそのプロキシのインスタンスのための一意の識 別子を追加することである。 応答が到着するとき、プロキシはプロキシのインスタンスにマッ チする識別子を持つ最初のRecord-Routeを修正する。修正によっ て、そのURIのユーザー部分に追加されたこのデータ片を持たない URIを得ることになる。次の繰り返し(iteration)時に、同じアル ゴリズム(そのパラメータを持つ最初のRecord-Routeヘッダーフィー ルド値を見つける)が、そのプロキシが挿入した次のRecord-Route ヘッダー値を適確に抽出する。 プロキシがRecord-Routeヘッダーフィールド値を追加したリクエ ストに対するすべての応答がRecord-Routeヘッダーフィールドを 含むわけではない。応答がRecord-Routeヘッダーフィールドを含 む場合、それはプロキシが追加した値を含む。 9. 応答を転送(forward)する 「認可のためのヘッダーフィールド値を集約する」から「Record- Route」で述べられている手順を実行した後で、プロキシは選択さ れた応答に対して、プロキシの機能特有のどのような操作でも実 行してもよい[MAY]。プロキシはメッセージボディを、追加、修正、 あるいは削除してはならない[MUST NOT]。特に規定されなければ、 プロキシは、セクション16.7の項目3で議論されているViaヘッダー フィールド値以外のいかなるヘッダーフィールド値も取り除い てはならない[MUST NOT]。特に、プロキシは、それがこの応答に Rosenberg, et. al. Standards Track [Page 113] RFC 3261 SIP: Session Initiation Protocol June 2002 関連付けられたリクエストを処理するときに次のViaヘッダーフィー ルド値に追加したのかもしれないいかなるreceivedパラメータ も削除してはならない[MUST NOT]。プロキシは、応答コンテキス トに関連付けられたサーバートランザクションに応答を渡さなけ ればならない[MUST]。このことで、今現在の最初のViaヘッダー フィールド値で示される場所に応答が送られることになる。サーバー トランザクションが既にその送信を操作するために有効でない場 合、エレメントはその応答をサーバートランスポートに送ることに よってステートレスに転送(forward)しなければならない[MUST]。 サーバートランザクションは、応答送信の失敗を示すか、あるいは それのステートマシン内でタイムアウトを知らせるかもしれない。 これらのエラーは、必要に応じて診断目的でログに記録されるが、 プロトコルはプロキシが是正措置を取ることを何ら要求しない。 最終応答を転送(forward)した後でも、プロキシは応答コンテキス トに関連付けられたすべてのトランザクションが終了するまで、そ の応答コンテキストを保持しなければならない[MUST]。 10. CANCELを生成する 転送(forward)された応答が最終応答であった場合、プロキシは この応答コンテキストに関連付けられたペンディング中のすべての クライアントトランザクションに対してCANCELリクエストを生成し なければならない[MUST]。プロキシは6xx応答を受け取ったとき にも、この応答コンテキストに関連付けられたペンディング中の すべてのクライアントトランザクションに対してCANCELリクエス トを生成するべきである[SHOULD]。ペンディング中のクライアン トトランザクションとは、暫定応答を受け取っているが最終応答 は受け取っておらず(それは進行中状態である)、それに対して関 連付けられたCANCELも生成していないものである。CANCELリクエ ストの生成はセクション9.1で述べられている。 最終応答転送(forward)時にペンディング中のクライアントトラン ザクションをCANCELする要件は、エンドポイントがINVITEに対する 複数の200(OK)応答を受け取らないことを保証するものではない。 CANCELリクエストが送られて処理される前に、2つ以上のブランチ で200(OK)応答が生成されるかもしれない。さらに、将来の拡張が CANCELリクエストを発行するためのこの要件をオーバーライドす るかもしれないことを予期するのが妥当である。 16.8 タイマーCの処理 万一タイマーCが切れる場合、プロキシはそれが選んだ何らかの値でタイマー をリセットするか、あるいはクライアントトランザクションを終了するかし なければならない[MUST]。クライアントトランザクションが暫定応答を受け 取っている場合、プロキシはそのトランザクションにマッチするCANCELリク エストを生成しなければならない[MUST]。クライアントトランザクションが 暫定応答を受け取っていない場合、プロキシはそのトランザクションがあた かも408(Request Timeout)応答を受け取ったかのように動作しなければなら ない[MUST]。 Rosenberg, et. al. Standards Track [Page 114] RFC 3261 SIP: Session Initiation Protocol June 2002 プロキシがタイマーをリセットすることを許可することは、タイマーが切れ たときに現在の状態(例えば稼動率)に基づいてトランザクションの生存期 間をプロキシが動的に伸張する事を可能にする。 16.9 トランスポートエラーの操作 トランスポートレイヤーがリクエストの転送(forward)を試みるときに(セクショ ン18.4参照)、プロキシにエラーを通知する場合、プロキシは転送(forward)され たリクエストが503 (Service Unavailable)応答を受け取ったかのように動作 しなければならない[MUST]。 プロキシが応答を転送(forward)するときにエラー通知を受けたときは、その応 答をやめる。プロキシは、この通知が原因でこの応答コンテキストに関連付 けられたまだ残っているすべてのクライアントトランザクションをキャンセ ルするべきではない[SHOULD NOT]。 プロキシがそれのまだ残っているクライアントトランザクションをキャ ンセルする場合、一つの悪意のあるまたは誤った動作をするクライアン トが、それのViaヘッダーフィールドを通してすべてのトランザクショ ンを失敗させる原因になることがありうる。 16.10 CANCELの処理 ステートフルプロキシはいつでも、それが生成したCANCEL以外のどのような リクエストに対してでもCANCELを生成してもよい[MAY](セクション9.1 で述べられているように、そのリクエストに対する暫定応答を受け取ること を前提として)。プロキシは、マッチするCANCELリクエストを受け取るとき、 応答コンテキストに関連付けられたペンディング中のどのようなクライアン トトランザクションもキャンセルしなければならない[MUST]。 ステートフルプロキシは、INVITEのExpiresヘッダーフィールドで指定された 期間の経過に伴い、ペンディング中のINVITEクライアントトランザクション に対してCANCELを生成してもよい[MAY]。しかしながら、関係するエンドポイ ントがトランザクション終了の合図をすることを引き受けるので、通常これを 行う必要はない。 CANCELリクエストが、ステートフルプロキシでそれ自身のサーバートランザ クションによって操作されるとはいえ、それのための新規応答コンテキストは 生成されない。その代わりに、プロキシレイヤーは、このCANCELに関連付けら れたリクエストを操作するサーバートランザクションのために、それの既存の 応答コンテキストを検索する。マッチする応答コンテキストが見つかった場 合、そのエレメントはCANCELリクエストに対して直ちに200(OK)応答を返さ なければならない[MUST]。この場合、エレメントはセクション8.2で定義 されているようにユーザーエージェントサーバーとして動作している。さら に、エレメントはセクション16.7のステップ10で述べられているように、そ のコンテキストのすべてのペンディング中のクライアントトランザクションに 対してCANCELを生成しなければならない[MUST]。 応答コンテキストが見つからない場合、エレメントはCANCELを適用するリク エストに関する知識を何ら持っていない。それはCANCELリクエストをステー トレスで転送(forward)しなければならない[MUST](それは関連付けられたリク エストをこれより前にステートレスで転送(forward)してしまっているのかもし れない)。 Rosenberg, et. al. Standards Track [Page 115] RFC 3261 SIP: Session Initiation Protocol June 2002 16.11 ステートレスプロキシ ステートレスで動作するとき、プロキシは単にメッセージを転送(forward)する ものである。ステートレスに動作するときに実行されるほとんどの処理は、 ステートフルに動作するときと同じである。相違点をここで詳述する。 ステートレスプロキシはトランザクションに関するいかなる概念も、あるい はステートフルプロキシの動作を記述するために使用される応答コンテキス トに関するいかなる概念も持たない。その代わりに、ステートレスプロキシ は、リクエストと応答の両方で、トランスポートレイヤー(セクション18参照) から直接メッセージを取り込む。結果として、ステートレスプロキシはそれ 自身でメッセージを再送しない。しかしながら、ステートレスプロキシはそ れが受け取るすべての再送を転送(forward)する(ステートレスプロキシは再送を オリジナルメッセージと区別する能力を持たない)。更には、リクエストをス テートレスで操作するとき、エレメントはそれ自身の100(Trying)応答をまた は他のいかなる暫定応答も生成してはならない[MUST NOT]。 ステートレスプロキシはセクション16.3で述べられているようにリクエスト を検証しなければならない[MUST]。 ステートレスプロキシは以下のことを例外として、セクション16.4から16.5 で述べられているリクエスト処理手順にしたがわなければならない[MUST]。 o ステートレスプロキシは、ターゲットセットからただ一つのターゲッ トを選択しなければならない[MUST]。この選択は、メッセージ中の フィールドと時間によって変化しないサーバーのプロパティのみを基に しなければならない[MUST]。特に、再送されたリクエストは、それが 処理される毎に同じデスティネーションに転送(forward)されなければな らない[MUST]。更に、CANCELリクエストとRouteされていないACKリク エストは、それらが関連付けられているINVITEと同じ選択を行わなけ ればならない[MUST]。 ステートレスプロキシは下記のことを例外として、セクション16.6で述べら れているように、リクエスト処理手順にしたがわなければならない[MUST]。 o あらゆる時間と空間に渡って一意であるbranch IDのための要件は、 ステートレスプロキシにも同様に適用される。しかしながら、ステー トレスプロキシは、セクション16.6の項目8で述べられているように branch IDの最初のコンポーネントを計算するために単純に乱数発生 器を使用できない。これは、リクエストの再送が同じ値を必要とする ためであり、ステートレスプロキシはオリジナルリクエストと再送を 区別できないためである。したがって、branchパラメータをユニーク にするコンポーネントは、再送されたリクエストが転送(forward)される たびに同じでなければならない[MUST]。よってステートレスプロキシ では、branchパラメータは、再送時に変化しないメッセージパラメー タを組み合わせた関数で計算されなければならない[MUST]。 Rosenberg, et. al. Standards Track [Page 116] RFC 3261 SIP: Session Initiation Protocol June 2002 ステートレスプロキシは、トランザクション全体を通してそれのbranch IDの一意性を保証するために、それが望むどのようなテクニックでも 使用してもよい[MAY]。しかしながら、以下の手順が推奨される[RECOMMENDED]。 プロキシは受け取ったリクエストの最初のViaヘッダーフィールドの branch IDを調査する。それがマジッククッキーで始まる場合、送り 出されるリクエストのbranch IDの最初のコンポーネントは、受け取 ったbranch IDのハッシュとして計算される。そうでなければ、branch IDの最初のコンポーネントは、受け取ったリクエストの最初のVia、 Toヘッダーフィールドのtag、Fromヘッダーフィールドのtag、Call-ID ヘッダーフィールド、CSeq番号(メソッドではない)、およびRequest- URIのハッシュとして計算される。これらのフィールドの一つは異な る2つのトランザクションにおいて常に異なる。 o セクション16.6で規定されている他のすべてのメッセージ変換は、再 送されたリクエストの変換と同じ結果にならなければならない[MUST]。 特に、プロキシがRecord-Route値を挿入するか、またはRouteヘッダー フィールドにURIを入れる場合には、プロキシはリクエストの再送 にも同じ値を置かなければならない[MUST]。Viaのbranchパラメータ では、変換が、時間によって変化しない設定または再送によって変化 しないリクエストのプロパティに基づかなければならない[MUST]こと を、これは意味する。 o ステートレスプロキシは、セクション16.6の項目10でステートフルプ ロキシのために述べられているように、リクエストをどこに転送 (forward)するか決定する。リクエストは、クライアントトランザク ションを通してではなく直接トランスポートレイヤーに送られる。 ステートレスプロキシは再送されたリクエストを同じデスティネーショ ンに転送(forward)しなければならず、それらに同一のbranchパラメータ を追加しなければならないので、メッセージ自身からの情報と時間によっ て変化しない設定データをそれらの計算に使用する。設定状態が時間に よって変化する場合(例えば、ルーティングテーブルがアップデート される場合)、その変更に影響を受ける可能性のあるいかなるリクエス トも、その変更の前後、トランザクションタイムアウト時間と同じ期間 だけ、ステートレスに転送(forward)されないかもしれない。その期間に、 影響を受けるリクエストを処理する方法は実装が決める。一般的な解決 策は、それらをトランザクションステートフルに転送(forward)することで ある。 ステートレスプロキシは、CANCELリクエストに対して特別な処理を実行して はならない[MUST NOT]。CANCELリクエストは他のいかなるリクエストとも同 じように上記のルールによって処理される。特に、ステートレスプロキシは、 他のいかなるリクエストに適用するのとも同じRouteヘッダー処理をCANCELリ クエストにも適用する。 Rosenberg, et. al. Standards Track [Page 117] RFC 3261 SIP: Session Initiation Protocol June 2002 セクション16.7で述べられているような応答の処理は、ステートレスに動作 するプロキシには適用されない。応答がステートレスプロキシに到着すると き、そのプロキシは最初の(先頭の)Viaヘッダー値のsent-by値を検査しなけ ればならない[MUST]。そのアドレスがそのプロキシにマッチする場合(このプ ロキシが以前のリクエストに挿入した値と等しい場合)、プロキシは応答から そのヘッダーフィールド値を取り除いて次のViaヘッダーフィールド値で示さ れる場所にその結果を転送(forward)しなければならない[MUST]。プロキシは メッセージボディを追加、修正、削除してはならない[MUST NOT]。特に規定さ れていなければ、プロキシは他のいかなるヘッダーフィールド値も取り除い てはならない[MUST NOT]。アドレスがプロキシにマッチしない場合、メッセー ジはだまって破棄されなければならない[MUST]。 16.12 プロキシのルート処理のまとめ ローカルポリシーがない場合、プロキシがRouteヘッダーフィールドを含むリ クエストで実行する処理は以下のようにまとめることができる。 1. プロキシはRequest-URIを検査する。それがこのプロキシが所持す るリソースを示す場合、プロキシはロケーションサービスを実行 した結果でそれを置き換える。そうでなければ、プロキシはRequest- URIを変更しない。 2. プロキシは最初のRouteヘッダーフィールド値のURIを検査する。 それがこのプロキシを示す場合、プロキシはそれをRouteヘッダー フィールドから取り除く(このルートノードに到着したので)。 3. プロキシはリクエストを最初のRouteヘッダーフィールド値のURI または(Routeヘッダーフィールドが存在しない場合には)Request- URIのURIで示されるリソースに転送(forward)する。プロキシはリク エストを転送(forward)するときに、そのURIに参考文献[4]の手順を 適用して、使用するアドレス、ポート、トランスポートを決定す る。 リクエストのパス上でストリクトルーティングを行うエレメントに出会わな い場合、Request-URIは常にリクエストのターゲットを示す。 16.12.1 例 16.12.1.1 基本的なSIP台形 このシナリオは、双方のプロキシがRecord-Routeを行う、基本的なSIP台形 (U1 -> P1 -> P2 -> U2)のものである。以下がそのフローである。 Rosenberg, et. al. Standards Track [Page 118] RFC 3261 SIP: Session Initiation Protocol June 2002 U1が、 INVITE sip:callee@domain.com SIP/2.0 Contact: sip:caller@u1.example.com をP1に送る。P1はアウトバウンドプロキシである。P1はdomain.comに対して 責任を負わないので、DNSをルックアップし、そこに送る。P1はRecord-Route ヘッダーフィールド値も追加する。 INVITE sip:callee@domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: P2がこれを受け取る。P2はdomain.comに対して責任を負うので、ロケーショ ンサービスを実行してRequest-URIを書き換える。P2はRecord-Routeヘッダー フィールド値も追加する。Routeヘッダーフィールドがないので、P2はリクエ ストをどこに送るか決定するために新しいRequest-URIを解決する。 INVITE sip:callee@u2.domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: Record-Route: u2.domain.comの着呼側はこれを受け取り、200 OKで応答する。 SIP/2.0 200 OK Contact: sip:callee@u2.domain.com Record-Route: Record-Route: u2の着呼側はまた、それのダイアログステートのリモートターゲットURIに sip:caller@u1.example.comを設定し、それのルートセットに以下の値を設定 する。 (,) これはP2によってP1にそれからU1に通常どおり転送(forward)される。今度は、 U1がそれのダイアログステートのリモートターゲットURIに sip:callee@u2.domain.comを設定し、それのルートセットに以下の値を設定 する。 (,) すべてのルートセットエレメントがlrパラメータを含むので、U1は以下の BYEリクエストを構築する。 BYE sip:callee@u2.domain.com SIP/2.0 Route: , Rosenberg, et. al. Standards Track [Page 119] RFC 3261 SIP: Session Initiation Protocol June 2002 (プロキシを含む)他のすべてのエレメントがするように、U1は、リクエスト をどこに送るか決定するために、最初のRouteヘッダーフィールド値のURIを DNSを使用して解決する。これはP1に行く。P1はRequest-URIで示されるリソー スに対して責任を負わないことに気付くので、それに変更を加えない。P1 は自分がRouteヘッダーフィールドの最初の値であることがわかるので、その 値を取り除き、リクエストをP2に転送(forward)する。 BYE sip:callee@u2.domain.com SIP/2.0 Route: P2もRequest-URIで示されるリソースに対して責任を負わないことに気付くの で(P2はu2.domain.comにではなくdomain.comに対して責任を負う)、それに変 更を加えない。P2は最初のRouteヘッダーフィールド値に自分自身がいるのに 気付くので、それを取り除き、Request-URIに対するDNSルックアップの結果 に基づいて以下のものをu2.domain.comに転送(forward)する。 BYE sip:callee@u2.domain.com SIP/2.0 16.12.1.2 ストリクトルーティングを行うプロキシのトラバース このシナリオでは、4つのプロキシを横断してダイアログが確立する。それぞ れのプロキシはRecord-Routeヘッダーフィールド値を追加する。3つめのプロ キシはRFC2543および多くの進行中の研究で規定されているストリクトルー ティング手順を実装している。 U1->P1->P2->P3->P4->U2 U2に到着するINVITEは以下のヘッダーフィールドを含む INVITE sip:callee@u2.domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: Record-Route: Record-Route: Record-Route: U2はこれに対して200 OKで応答する。後ほど、U2は最初のRouteヘッダーフィー ルド値に基づいて以下のBYEリクエストをP4に送る。 BYE sip:caller@u1.example.com SIP/2.0 Route: Route: Route: Route: Rosenberg, et. al. Standards Track [Page 120] RFC 3261 SIP: Session Initiation Protocol June 2002 P4はRequest-URIで示されるリソースに対して責任を負わないので、これをそ のままにしておく。P4は自分が最初のRouteヘッダーフィールド値のエレメン トであることに気付くので、それを取り除く。それから、最初のRouteヘッダー フィールド値になったsip:p3.middle.comに基づいてリクエストを送る準備 をする。しかしP4はこのURIがlrパラメータを含んでいないことに気付くので、 送る前にリクエストを以下のように改善する。 BYE sip:p3.middle.com SIP/2.0 Route: Route: Route: P3はストリクトルーターなので、以下のものをP2に転送(forward)する。 BYE sip:p2.example.com;lr SIP/2.0 Route: Route: P2は、request-URIがP2がRecord-Routeヘッダーフィールドに置いた値である ことに気付くので、更に処理を進める前に以下のようにリクエストを書き換 える。 BYE sip:caller@u1.example.com SIP/2.0 Route: P2はu1.example.comに対して責任を負わないので、Routeヘッダーフィールド 値の解決を行った結果に基づいてリクエストをP1に送る。 P1は自分が最初のRouteヘッダーフィールド値にいることに気付くので、それ を取り除き、以下の結果を得る。 BYE sip:caller@u1.example.com SIP/2.0 P1はu1.example.comに対して責任を負わず、またRouteヘッダーフィールドが 一つもないので、P1はRequest-URIに基づいてリクエストをu1.example.comに 転送(forward)する。 16.12.1.3 Record-Routeヘッダーフィールド値の書き換え このシナリオでは、U1とU2は異なるプライベート名前空間にいる。そして、 それらはプロキシP1を介してダイアログに入る。プロキシP1は名前空間のあ いだのゲートウェイとして動作する。 U1->P1->U2 Rosenberg, et. al. Standards Track [Page 121] RFC 3261 SIP: Session Initiation Protocol June 2002 U1は以下のものを送る。 INVITE sip:callee@gateway.leftprivatespace.com SIP/2.0 Contact: P1はそれのロケーションサービスを使用し、以下のものをU2に送る。 INVITE sip:callee@rightprivatespace.com SIP/2.0 Contact: Record-Route: U2は以下の200 (OK)をP1に送り返す。 SIP/2.0 200 OK Contact: Record-Route: P1は、U1が有用であると考える値を提供するために、それのRecord-Routeヘッ ダーパラメータを書き換えて、以下のものをU1に送る。 SIP/2.0 200 OK Contact: Record-Route: 後ほど、U1は以下のBYEリクエストをP1に送る。 BYE sip:callee@u2.rightprivatespace.com SIP/2.0 Route: これをP1は、以下のものとしてU2に転送(forward)する。 BYE sip:callee@u2.rightprivatespace.com SIP/2.0 17 トランザクション SIPはトランザクションプロトコルである。つまり、コンポーネント間の相互 作用が、独立したメッセージ交換の連続で起こる。具体的には、SIPトランザ クションは一つのリクエストとそのリクエストに対する何らかの応答(ゼロ個 以上の暫定応答および一つ以上の最終応答を含む)から成る。リクエストが INVITEであったときのトランザクション(INVITEトランザクションとして知ら れている)の場合には、最終応答が2xx応答でなかった場合に限り、トランザ クションはACKも含む。応答が2xxだった場合、ACKはそのトランザクションの 一部とはみなされない。 この場合分けの理由は、INVITEに対するすべての200(OK)応答をUACに配 送することの重要性に根ざす。それらをすべてUACに配送するために、 Rosenberg, et. al. Standards Track [Page 122] RFC 3261 SIP: Session Initiation Protocol June 2002 UASのみがそれらの再送の責任を負い(セクション13.3.1.4参照)、UACの みがそれらにACKで同意する責任を負う(セクション13.2.2.4参照)。こ のACKはUACによってのみ再送されるので、それは事実上それ自身のトラ ンザクションであるとみなされる。 トランザクションはクライアントの側面とサーバーの側面を持つ。クライア ントの側面はクライアントトランザクションとして知られており、サーバー の側面はサーバートランザクションとして知られている。クライアントトラ ンザクションはリクエストを送り、サーバートランザクションは応答を送る。 クライアントトランザクションとサーバートランザクションはいくつのエレ メントにでも組み込める論理的な機能である。具体的には、それらはユーザー エージェントとステートフルプロキシサーバーの中に存在する。セクショ ン4の例を考える。この例では、UACがクライアントトランザクションを実行 し、それのアウトバウンドプロキシがサーバートランザクションを実行する。 アウトバウンドプロキシは、インバウンドプロキシ中のサーバートランザク ションにリクエストを送る、クライアントトランザクションも実行する。そ のプロキシは、今度は、そのリクエストをUASのサーバートランザクションに 送る、クライアントトランザクションも実行する。これは図4に示されている。 +---------+ +---------+ +---------+ +---------+ | +-+|リクエスト|+-+ +-+|リクエスト|+-+ +-+|リクエスト|+-+ | | |C||--------->||S| |C||--------->||S| |C||--------->||S| | | |l|| ||e| |l|| ||e| |l|| ||e| | | |i|| ||r| |i|| ||r| |i|| ||r| | | |e|| ||v| |e|| ||v| |e|| ||v| | | |n|| ||e| |n|| ||e| |n|| ||e| | | |t|| ||r| |t|| ||r| |t|| ||r| | | | || || | | || || | | || || | | | |T|| ||T| |T|| ||T| |T|| ||T| | | |r|| ||r| |r|| ||r| |r|| ||r| | | |a|| ||a| |a|| ||a| |a|| ||a| | | |n|| ||n| |n|| ||n| |n|| ||n| | | |s|| 応答 ||s| |s|| 応答 ||s| |s|| 応答 ||s| | | +-+|<---------|+-+ +-+|<---------|+-+ +-+|<---------|+-+ | +---------+ +---------+ +---------+ +---------+ UAC アウトバウンド インバウンド UAS プロキシ プロキシ 図4: トランザクションの関係 ステートレスプロキシはクライアントトランザクションまたはサーバートラ ンザクションを含まない。トランザクションは(一方の側に)UAまたはステー トフルプロキシと(そしてもう一方の側に)UAまたはステートフルプロキシの 間に存在する。SIPトランザクションに関して言えば、ステートレスプロキシ は実質的にトランスペアレントである。クライアントトランザクションの目 的は、クライアントが組み込まれているエレメント(このエレメントをトラン ザクションユーザーまたはTUと呼ぶ。TUはUAまたはステートフルプロキシで ある)からリクエストを受け取り、リクエストをサーバートランザクションに 確実に配送することである。 Rosenberg, et. al. Standards Track [Page 123] RFC 3261 SIP: Session Initiation Protocol June 2002 クライアントトランザクションは、応答を受け取って、応答の再送や許可さ れない応答(例えばACKに対する応答)を除去しながらそれをTUに配送する 責任も負う。それに加えて、INVITEリクエストの場合には、クライアント トランザクションは、2xx応答を受け入れるすべての最終応答に対する ACKリクエストを生成する責任も負う。 同様に、サーバートランザクションの目的は、トランスポートレイヤーから リクエストを受け取り、それをTUに配送することである。サーバートランザ クションはネットワークからすべてのリクエストの再送をフィルターする。 サーバートランザクションはTUからの応答を受け入れ、ネットワーク上で送 信するためにトランスポートレイヤーにそれを配送する。INVITEトランザク ションの場合には、サーバートランザクションは2xx応答を除くすべての最終 応答に対するACKを取り込む。 2xx応答とそれのACKは特別な扱いを受ける。この応答はUASのみが再送する。 そしてそれのACKはUACのみが生成する。このエンドツーエンドの処置は、呼 を受け入れた完全なユーザーセットを発呼側が知るために必要とされる。こ の特別な操作のため、2xxの再送はトランザクションレイヤーではなくUAコア で操作される。同様に、2xxに対するACKの生成はUAコアで操作される。パス上 の各プロキシは、INVITEに対する2xx応答とそれに対応するACKを単に転送 (forward)するだけである。 17.1 クライアントトランザクション クライアントトランザクションはステートマシンを保持することによってそ の機能を提供する。 TUは単純なインターフェースを介してクライアントトランザクションとコミュ ニケートする。TUが新規トランザクションの開始を望むときは、クライア ントトランザクションを生成し、それに、送るSIPリクエスト、およびそれを 送る先のIPアドレス、ポート、トランスポートを渡す。クライアントトラン ザクションはそれのステートマシンの実行を開始する。有効な応答はクライ アントトランザクションからTUに渡される。 TUによって渡されたリクエストのメソッドによって、クライアントトランザク ションのステートマシンは2種類存在する。一つはINVITEリクエストのための クライアントトランザクションを操作する。このタイプのマシンはINVITEクラ イアントトランザクションと呼ばれる。もう一つのタイプはINVITEとACK以外 のすべてのリクエストのためのクライアントトランザクションを操作する。こ れは非INVITEクライアントトランザクションと呼ばれる。ACKに対するクライ アントトランザクションはない。TUがACKを送ることを望む場合は、送信する ために直接トランスポートレイヤーに渡す。 Rosenberg, et. al. Standards Track [Page 124] RFC 3261 SIP: Session Initiation Protocol June 2002 INVITEトランザクションは、その拡張された持続時間のために他のメソッド のトランザクションと異なる。通常、INVITEに応答するために人間による入 力が求められる。応答を送るために予期される長い遅延は3ウェイハンドシェ イクを主張する。その一方、他のメソッドのリクエストは迅速に完了するこ とが予期される。非INVITEトランザクションは2ウェイハンドシェイクに依存 するので、TUは非INVITEリクエストに対して直ちに応答するべきである[SHOULD]。 17.1.1 INVITEクライアントトランザクション 17.1.1.1 INVITEトランザクションの概要 INVITEトランザクションは3ウェイハンドシェイクから成る。クライアントト ランザクションがINVITEを送り、サーバートランザクションが応答を送る。 そしてクライアントトランザクションがACKを送る。信頼性がないトランスポー ト(UDPなど)では、クライアントトランザクションは、T1秒で開始し再送の たびに倍になる時間間隔で、リクエストを再送する。T1はラウンドトリップ 時間(RTT)の予測値であり、初期値は500msである。ここで述べるほとんどす べてのトランザクションタイマーはT1に対応し、T1を変更することでそれら の値が調整される。リクエストは信頼性のあるトランスポート上では再送さ れない。1xx応答を受け取った後、すべての再送は完全に停止し、クライアン トはさらなる応答を待つ。サーバートランザクションは、サーバートランザ クションによって信頼性をもって送信されない付加的な1xx応答を送ることが できる。最終的に、サーバートランザクションは最終応答を送ることを決定 する。信頼性のないトランスポートでは、その応答は定期的に再送され、信 頼性のあるトランスポートでは、それは一度だけ送られる。クライアントト ランザクションで受け取る各最終応答に対して、クライアントトランザクショ ンはACKを送る。その目的は、応答の再送を抑えるためである。 17.1.1.2 形式的な説明 INVITEクライアントトランザクションのためのステートマシンを図5に示す。 TUがINVITEリクエストで新規クライアントトランザクションを開始するとき は、最初のステートである「Calling」に入らなければならない[MUST]。クラ イアントトランザクションはリクエストを送信するためにリクエストをトラ ンスポートレイヤーに渡さなければならない[MUST](セクション18参照)。信 頼性がないトランスポートが使用されることになる場合、クライアントトラ ンザクションは、値T1でタイマーAを開始しなければならない[MUST]。信頼性 のあるトランスポートが使用されることになる場合、クライアントトランザ クションはタイマーAを開始するべきでない[SHOULD NOT](タイマーAはリクエ ストの再送を制御する)。いかなるトランスポートにおいても、クライアント トランザクションは、値64*T1秒でタイマーBを開始しなければならない[MUST] (タイマーBはトランザクションのタイムアウトを制御する)。 タイマーAが切れるとき、クライアントトランザクションはリクエストをトラ ンスポートレイヤーに渡すことによってそれを再送しなければならず[MUST]、 値2*T1でタイマーをリセットしなければならない[MUST]。トランザクション Rosenberg, et. al. Standards Track [Page 125] RFC 3261 SIP: Session Initiation Protocol June 2002 レイヤーのコンテキスト内での再送の正式な定義は、以前にトランスポート レイヤーに送ったメッセージを取得してそれをトランスポートレイヤーにも う一度渡すことである。 タイマーAが2*T1秒後に切れるとき、リクエストは再び再送されなければなら ない[MUST](クライアントトランザクションが依然としてこのステートにある と仮定している)。この処理は、各送信の後に2倍になる間隔でリクエス トが再送されるように継続しなければならない[MUST]。これらの再送はクラ イアントトランザクションが「Calling」ステートにあるあいだだけ行われる べきである[SHOULD]。 T1の初期値は500msである。T1は、クライアントトランザクションとサーバー トランザクションのあいだのRTTの推定値である。エレメントは(推奨されて はいないが[NOT RECOMMENDED])インターネット接続を許可しない閉じた、プ ライベートネットワーク内で、より小さいT1の値を使用してもよい[MAY]。よ り大きな値をT1に選択してもよく[MAY]、これはRTTがより大きいことがあらか じめわかっている場合(例えば高遅延アクセスリンク上で)に推奨される [RECOMMENDED]。T1の値がどのようなものであれ、このセクションで述べられ ている指数関数的に増加する再送のバックオフが使用されなければならな い[MUST]。 タイマーBが切れるときにクライアントトランザクションが依然として 「Calling」ステートにある場合、クライアントトランザクションはタイムア ウトが起こったことをTUに通知するべきである[SHOULD]。クライアントトラ ンザクションはACKを生成してはならない[MUST NOT]。64*T1という値は、信 頼性のないトランスポートの場合に7つのリクエストを送るのに必要な時間に 等しい。 クライアントトランザクションが「Calling」ステートにある間に暫定応答を 受け取る場合、それは「Proceeding」ステートに移行する。「Proceeding」 ステートでは、クライアントトランザクションは、これ以上リクエストを再 送すべきではない[SHOULD NOT]。さらに、暫定応答はTUに渡されなければな らない[MUST]。「Proceeding」ステートにあるあいだは、これ以上のいかな る暫定応答もTUに渡されなければならない[MUST]。 「Calling」または「Proceeding」ステートにあるときは、ステータスコード 300から699までの応答の受信で、クライアントトランザクションを「Completed」 に移行させなければならない[MUST]。クライアントトランザクションは受け 取った応答をTUに渡さなければならず[MUST]、たとえトランスポートに信頼 性があったとしてもクライアントトランザクションはACKリクエストを生成し て(応答からACKを構築するためのガイドラインはセクション17.1.1.3で与え られる)それから送信するためにそのACKをトランスポートレイヤーに渡さな ければならない[MUST]。ACKはオリジナルリクエストが送られたのと同じアド レス、ポート、およびトランスポートに送られなければならない[MUST]。ク ライアントトランザクションは「Completed」ステートに入ったときに、信頼 性のないトランスポートでは少なくとも32秒、信頼性のあるトランスポー トではゼロ秒の値を持ったタイマーDを開始するべきである[SHOULD]。タイマー Dは、信頼性のないトランスポートが使用されたときにサーバートランザク ションが「Completed」ステートにとどまることができる時間を反映する。こ Rosenberg, et. al. Standards Track [Page 126] RFC 3261 SIP: Session Initiation Protocol June 2002 れは、初期値が64*T1であるINVITEサーバートランザクションのタイマーHに 等しい。しかしながら、クライアントトランザクションはサーバートランザ クションが使用しているT1の値を知らないので、タイマーDをT1に基づいて決 める代わりに、絶対最小値として32秒が使われる。 「Completed」ステートにある間に受け取った最終応答のいかなる再送も、 ACKを再送するためにトランスポートレイヤーにACKを再び渡すことの原因に ならなければならない[MUST]が、新しく受け取った応答はTUに渡してはなら ない[MUST NOT]。応答の再送とは、セクション17.1.3のルールに基づき、同 じクライアントトランザクションにマッチするすべての応答であると定義さ れている。 Rosenberg, et. al. Standards Track [Page 127] RFC 3261 SIP: Session Initiation Protocol June 2002 |TUからのINVITE タイマーAが切れる |INVITEが送られる Aをリセット、 V タイマーBが切れる INVITEが送られる +-----------+ or トランスポートエラー +---------| |--------------------+TUに通知 | | Calling | | +-------->| |------------------->| +-----------+ 2xx | | | TUに2xx | | |1xx | 300-699 +---------------+ |TUに1xx | ACKが送られる| | | TUに応答 | 1xx V | | TUに1xx +-----------+ | | +---------| | | | | |Proceeding |------------------->| | +-------->| | 2xx | | +-----------+ TUに2xx | | 300-699 | | | ACKが送られる| | | TUに応答 | | | | | 注意: |300-699 V | |ACKが送られる+-----------+トランスポートエラー| 取られるアク | +---------| |TUに通知 | ションの上に | | | Completed |------------------->| イベントを示 | +-------->| | | すラベルを付 | +-----------+ | けた遷移 | ^ | | | | | タイマーDが切れる | +---------------+ | - | | | V | +-----------+ | | | | | Terminated|<-------------------+ | | +-----------+ 図5: INVITEクライアントトランザクション クライアントトランザクションが「Completed」ステートにある間にタイマーD が切れる場合、クライアントトランザクションは「Terminated」ステートに移 らなければならない[MUST]。 「Calling」または「Proceeding」ステートのいずれかにあるときに、2xx応 答を受信することは、クライアントトランザクションが「Terminated」ステー トに入る原因にならなければならず[MUST]、その応答はTUに渡されなけれ ばならない[MUST]。この応答の操作は、TUがプロキシコアかUACコアかに Rosenberg, et. al. Standards Track [Page 128] RFC 3261 SIP: Session Initiation Protocol June 2002 依存する。UACコアはこの応答に対するACKの生成を操作し、その一方でプロキ シコアは常にアップストリームに200(OK)を転送(forward)する。プロキシとUAC のあいだの200(OK)処理の違いが、その操作がトランザクションレイヤーで行 われないことの理由である。 クライアントトランザクションは、それが「Terminated」ステートに入ると すぐに破棄されなければならない[MUST]。これは正しい動作を保証するため に実際に必要である。その理由は、INVITEに対する2xx応答が異なる処理を施 されるからである。つまり、各2xx応答はプロキシによって転送(forward)され、 UACにおけるACKの操作は異なる。したがって、各2xxは(転送(forward)できる ように)プロキシコアに渡される必要があり、また(同意できるように)UACコア に渡される必要がある。トランザクションレイヤー処理は起こらない。 トランスポートによって応答が受け取られるといつでも、トランスポートレ イヤーが(セクション17.1.3のルールを使用して)マッチするクライアントト ランザクションを見つけない場合、応答は直接コアに渡される。マッチする クライアントトランザクションは最初の2xxによって破棄されているので、そ れ以降の2xxはマッチするものを見つけられず、よってコアに渡される。 17.1.1.3 ACKリクエストの構築 このセクションでは、クライアントトランザクション内で送られるACKリクエ ストの構築について規定する。2xxに対するACKを生成するUACコアは、これで はなく、セクション13で述べられているルールに従わなければならない[MUST]。 クライアントトランザクションによって構築されるACKリクエストは、クライ アントトランザクションによってトランスポートに渡されたリクエスト(これ をオリジナルリクエストと呼ぶ)に含まれるヘッダーフィールドの値と同じ、 Call-ID、From、およびRequest-URIの値を含まなければならない[MUST]。ACK のToヘッダーフィールドは承認する応答のToヘッダーフィールドと同じでな ければならず[MUST]、したがって、tagパラメータが追加されることによりオ リジナルリクエストのToヘッダーフィールドとは通常異なることになる。ACK は一つのViaヘッダーフィールドを含まなければならず[MUST]、これはオリジ ナルリクエストの最初のViaヘッダーフィールドと同じでなければならない [MUST]。ACKのCSeqヘッダーフィールドはシーケンス番号にオリジナルリクエ ストにあったのと同じ値を含まなければならない[MUST]が、メソッドパラメー タは「ACK」でなければならない[MUST]。 Rosenberg, et. al. Standards Track [Page 129] RFC 3261 SIP: Session Initiation Protocol June 2002 それに対する応答が承認されることになるINVITEがRouteヘッダーフィールド を持っていた場合、それらのヘッダーフィールドはACKに現れなければならない [MUST]。これは、ダウンストリームのどのようなステートレスプロキシを通 してもACKが適切にルートされることを保証するためである。 どのようなリクエストでもボディを含めてもよい[MAY]とはいえ、ボディ が理解されない場合でもリクエストが拒否されることができないので、ACK中 のボディは特別である。したがって、非2xxに対するACKにボディを置くこと は推奨されない[NOT RECOMMENDED]が、置く場合には、INVITEに対する応答が 415でないとすると、ボディタイプはINVITE中に現れたものに制限される。 INVITEに対する応答が415であった場合、ACK中のボディは、415のAcceptヘッ ダーフィールドに列挙されていたタイプのいずれかにしてもよい[MAY]。 例として、次のリクエストを考える。 INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff To: Bob From: Alice ;tag=88sja8x Max-Forwards: 70 Call-ID: 987asjd97y7atg CSeq: 986759 INVITE このリクエストへの非2xx最終応答に対するACKリクエストは以下のようにな るかもしれない。 ACK sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff To: Bob ;tag=99sa0xk From: Alice ;tag=88sja8x Max-Forwards: 70 Call-ID: 987asjd97y7atg CSeq: 986759 ACK 17.1.2 非INVITEクライアントトランザクション 17.1.2.1 非INVITEトランザクションの概要 非INVITEトランザクションはACKを使用しない。それは単純なリクエストと応 答の相互のやりとりである。信頼性のないトランスポートでは、T1で開始しT2 になるまで倍になる時間間隔で、リクエストは再送される。暫定応答を受け 取る場合、信頼性のないトランスポートでは再送が継続するが、時間間隔は T2で行われる。サーバートランザクションは、リクエストの再送を受け取っ たときのみ、それが送った最後の応答(暫定応答または最終応答でありうる) を再送する。これが、暫定応答後であってもリクエストの再送を継続する必 要がある理由である。それは最終応答の確実な配送を保証するためである。 Rosenberg, et. al. Standards Track [Page 130] RFC 3261 SIP: Session Initiation Protocol June 2002 INVITEトランザクションとは異なり、非INVITEトランザクションは2xx応答に 対する特別な操作がない。その結果、非INVITEに対するただひとつの2xx応答 がUACに配送されることになる。 17.1.2.2 形式的な説明 非INVITEクライアントトランザクションのためのステートマシンを図6に示す。 それはINVITEのためのステートマシンに非常に似ている。 TUがリクエストで新規クライアントトランザクションを開始するときに 「Trying」ステートに入る。このステートに入るとき、クライアントトラン ザクションは64*T1秒後に切れるようにタイマーFをセットするべきである [SHOULD]。リクエストは送信するためにトランスポートレイヤーに渡されな ければならない[MUST]。信頼性のないトランスポートを使用している場合、 クライアントトランザクションはT1秒後に切れるようにタイマーEをセットし なければならない[MUST]。まだこのステートにある間にタイマーEが切れる 場合、タイマーEはリセットされるが、今回はMIN(2*T1, T2)の値になる。 タイマーが再び切れるときは、MIN(4*T1, T2)にリセットされる。この処理は、 T2を上限として指数関数的に増加する時間間隔で再送が起こるように継続す る。T2の初期値は4秒であり、非INVITEサーバートランザクションがリクエス トに即座に応答しない場合に、それに応答するために要する時間を表す。T1 とT2の初期値に対して、これは、500ミリ秒、1秒、2秒、4秒、4秒、4秒、・・・ という結果になる。 クライアントトランザクションが依然として「Trying」ステートにあるあい だにタイマーFが切れる場合、クライアントトランザクションはTUにタイムア ウトを通知するべきであり[SHOULD]、その後「Terminated」ステートに入る べきである[SHOULD]。「Trying」ステートにある間に暫定応答を受け取る場 合、その応答はTUに渡されなければならず[MUST]、その後、そのクライアント トランザクションは「Processing」ステートに移行するべきである[SHOULD]。 「Trying」ステートにある間に最終応答(ステータスコード200から699)を 受け取る場合、その応答はTUに渡されなければならず[MUST]、クライアントト ランザクションは「Completed」ステートに移行しなければならない[MUST]。 「Proceeding」ステートにある間にタイマーEが切れる場合、リクエストは再 送のためにトランスポートレイヤーに渡されなければならず[MUST]、タイマー EはT2秒でリセットされなければならない[MUST]。「Proceeding」ステートに ある間にタイマーFが切れる場合、TUはタイムアウトを通知されなければなら ず[MUST]、クライアントトランザクションは「Terminated」ステートに移行し なければならない[MUST]。「Proceeding」ステートにある間に最終応答(ス テータスコード200から699)を受け取る場合、その応答はTUに渡されなければ ならず[MUST]、クライアントトランザクションは「Completed」ステートに移 行しなければならない[MUST]。 クライアントトランザクションが「Completed」ステートに入るとすぐに、そ れは、信頼性のないトランスポートに対してはT4秒後に切れるように、信頼 性のあるトランスポートに対してはゼロ秒後に切れるようにタイマーKをセッ トしなければならない[MUST]。「Completed」ステートは、受け取るかもしれ ない応答のすべての付加的な再送(これはクライアントトランザクションが信 Rosenberg, et. al. Standards Track [Page 131] RFC 3261 SIP: Session Initiation Protocol June 2002 頼性のないトランスポートに対してのみ残ることの理由である)をバッファー するために存在する。T4は、ネットワークがクライアントトランザクション とサーバートランザクションのあいだのメッセージをクリアするために要す る時間を表す。T4の初期値は5秒である。応答が、セクション17.1.3で規定さ れているルールを使用して同じトランザクションにマッチするとき、それは 再送である。このステートにある間にタイマーKが切れる場合、クライアント トランザクションは「Terminated」ステートに移行しなければならない[MUST]。 トランザクションが「Terminated」ステートになったら、それはすぐに破棄 されなければならない[MUST]。 17.1.3 応答をクライアントトランザクションにマッチングする クライアントのトランスポートレイヤーが応答を受け取るとき、セクション 17.1.1と17.1.2の処理を行うことができるように、それはどのクライアント トランザクションが応答を操作するか決定しなければならない。最初のVia ヘッダーフィールドのbranchパラメータがこのために使用される。応答は以下 の2つの条件の下でクライアントトランザクションにマッチする。 1. 応答が、トランザクションを生成したリクエストの最初のViaヘッ ダーフィールドのbranchパラメータと同じbranchパラメータ値を 最初のViaヘッダーフィールドに持つ場合。 2. CSeqヘッダーフィールドのメソッドパラメータが、トランザクショ ンを生成したリクエストのメソッドにマッチする場合。CANCEL リクエストは別のトランザクションを構成するが、同じbranchパ ラメータ値を共有するので、メソッドは必要になる。 リクエストがマルチキャストで送られる場合、異なるサーバーによって複数 の応答を生成することがあり得る。これらの応答はすべて最初のViaに同じ branchパラメータを持つが、To tagは異なる。上記のルールに基づいて最初 に受け取った応答が使用され、他のものは再送とみなされる。それはエラー ではない。マルチキャストSIPは、一つの応答を処理することに限定される、 初歩的な「単一ホップ発見のような(single-hop-discovery-like)」サービス のみを提供する。詳細についてはセクション18.1.1参照のこと。 Rosenberg, et. al. Standards Track [Page 132] RFC 3261 SIP: Session Initiation Protocol June 2002 17.1.4 トランスポートエラーの操作 |TUからのリクエスト |リクエストを送る タイマーE V リクエストを送る +-----------+ +-----------------| |-------------------------+ | | Trying | タイマーF | +---------------->| | or トランスポートエラー| +-----------+ TUに通知 | 200-699 | | | TUに応答 | |1xx | +--------------------+ |TUに応答 | | | | | タイマーE V タイマーF | | リクエストを送る+-----------+ or トランスポートエラー | | +--------------| | TUに通知 | | | |Proceeding |------------------------>| | +------------->| |-----+ | | +-----------+ |1xx | | | ^ |TUに応答 | | 200-699 | +--------+ | | TUに応答 | | | | | | V | | +-----------+ | | | | | | | Completed | | | | | | | +-----------+ | | ^ | | | | | タイマーK | +-------------------+ | - | | | V | 注意: +-----------+ | | | | 取られるアク | Terminated|<------------------------+ ションの上に | | イベントを示 +-----------+ すラベルを付 けた遷移 図6: 非INVITEクライアントトランザクション クライアントトランザクションがリクエストを送るためにそれをトランスポー トレイヤーに送るときに、トランスポートレイヤーが失敗を示す場合、以下の 手順に従う。 Rosenberg, et. al. Standards Track [Page 133] RFC 3261 SIP: Session Initiation Protocol June 2002 クライアントトランザクションはトランスポートの失敗が起こったことをTU に通知するべきであり[SHOULD]、クライアントトランザクションは直接 「Terminated」ステートに遷移するべきである[SHOULD]。TUは参考文献[4]で 述べられているフェールオーバーの仕組みを操作する。 17.2 サーバートランザクション サーバートランザクションは、TUにリクエストを配送することに対して、お よび応答の確実な送信に対しての責任を負う。サーバートランザクションは ステートマシンを介してこれを実現する。サーバートランザクションはリク エストを受け取ったときにコアによって生成され、そのリクエストに対する トランザクション操作が求められる(常にこうであるとは限らない)。 クライアントトランザクションと同様に、ステートマシンは受け取ったリク エストがINVITEかどうかに依存する。 17.2.1 INVITEサーバートランザクション INVITEサーバートランザクションのステート図を図7に示す。 サーバートランザクションがリクエストのために構築されるとき、それは 「Proceeding」ステートに入る。サーバートランザクションは、TUが200ミリ 秒以内に暫定応答または最終応答を生成するということを知らない限り、 100(Trying)応答を生成しなければならない[MUST]。知っている場合は、100 (Trying)応答を生成してもよい[MAY]。この暫定応答は、ネットワーク混雑を 避けるために、リクエストの再送を迅速に抑えるために必要になる。100 (Trying)応答は、Toヘッダーフィールドのtagの挿入が(リクエストに一つも存 在しないときに)「してもよい[MAY]」から「するべきではない[SHOULD NOT]」 にダウングレードされることを除いて、セクション8.2.6の手順に従って 構築される。リクエストはTUに渡されなければならない[MUST]。 TUは暫定応答をいくつでもサーバートランザクションに渡す。サーバートラ ンザクションが「Proceeding」ステートにあるあいだは、これらは、送信す るためにトランスポートレイヤーに渡されなければならない[MUST]。それら はトランザクションレイヤーによって信頼性を持って送られず(それらはトラ ンザクションレイヤーによって再送されない)、サーバートランザクションの ステートを変更する原因にもならない。「Proceeding」ステートにあるあい だにリクエストの再送を受け取る場合、TUから受け取った最新の暫定応答は 再送するためにトランスポートレイヤーに渡されなければならない[MUST]。 セクション17.2.3のルールに基づいて同じサーバートランザクションにマッ チするリクエストは再送である。 「Proceeding」ステートにある間に、TUがサーバートランザクションに2xx応 答を渡す場合、サーバートランザクションはこの応答を送信するためにトラン スポートレイヤーに渡さなければならない[MUST]。それはサーバートランザク Rosenberg, et. al. Standards Track [Page 134] RFC 3261 SIP: Session Initiation Protocol June 2002 ションによって再送されない。2xxの再送はTUによって操作される。サーバー トランザクションは、次いで「Terminated」ステートに移行しなければならな い[MUST]。 「Proceeding」ステートにある間に、TUがサーバートランザクションに 300から699までのステータスコードで応答を渡す場合、その応答は、送信す るためにトランスポートレイヤーに渡されなければならず[MUST]、ステート マシンは「Completed」ステートに入らなければならない[MUST]。信頼性のな いトランスポートでは、T1秒で切れるようにタイマーGがセットされ、信頼性 のあるトランスポートではセットされない。 これは、信頼性のあるトランスポートでも常に応答が再送されていた、 RFC2543からの変更である。 「Completed」ステートに入ったとき、すべてのトランスポートにおいてタイ マーHが64*T1秒で切れるようにセットされなければならない[MUST]。タイマー Hは、サーバートランザクションがいつ応答の再送を止めるかを決定する。 それの値は、クライアントトランザクションがリクエスト送信のリトライを 継続する時間であるタイマーBと同じになるように選択される。タイマーGが 切れる場合、応答はもう一度再送のためにトランスポートレイヤーに渡され、 タイマーGはMIN(2*T1, T2)秒で切れるようにセットされる。それ以降、タイ マーGが切れるときは、応答は、送信するために再びトランスポートに渡され、 タイマーGはT2を超えない限り倍の値でリセットされる。超える場合は、T2で リセットされる。これは、非INVITEクライアントトランザクションの「Trying」 ステートにおけるリクエストの再送動作と同じである。さらに、「Completed」 ステートにある間にリクエストの再送を受け取る場合、サーバーは応答 を再送するためにトランスポートに渡すべきである[SHOULD]。 サーバートランザクションが「Completed」ステートにある間にACKを受 け取る場合、サーバートランザクションは「Confirmed」ステートに移行しな ければならない[MUST]。このステートではタイマーGが無視されるので、応答 のすべての再送は停止する。 「Completed」ステートにある間にタイマーHが切れる場合は、ACKがいつ までも受け取れなかったことを示す。この場合、サーバートランザクション は「Terminated」ステートに移行しなければならず[MUST]、トランザクショ ンの失敗が起こったことをTUに通知しなければならない[MUST]。 Rosenberg, et. al. Standards Track [Page 135] RFC 3261 SIP: Session Initiation Protocol June 2002 |INVITE |INVITEをTUに渡す INVITE V100を送る(TUが200ms以内に送らない場合) 応答を送る +-----------+ +--------| |--------+TUから101-199 | | Proceeding| |応答を送る +------->| |<-------+ | | トランスポートエラー | | TUに通知 | |--------------------->+ +-----------+ | TUから300-699 | |TUから2xx | 応答を送る | |応答を送る | | +------------------------>+ | | INVITE V タイマーGが切れる | 応答を送る +-----------+ 応答を送る | +--------| |--------+ | | | Completed | | | +------->| |<-------+ | +-----------+ | | | | ACK | | | - | +------------------------>+ | タイマーHが切れる | V or トランスポートエラー| +-----------+ TUに通知 | | | | | Confirmed | | | | | +-----------+ | | | |タイマーIが切れる | |- | | | V | +-----------+ | | | | | Terminated|<---------------------+ | | +-----------+ 図7: INVITEサーバートランザクション Rosenberg, et. al. Standards Track [Page 136] RFC 3261 SIP: Session Initiation Protocol June 2002 「Confirmed」ステートの目的は、最終応答の再送がトリガーとなって到着し たすべての付加的なACKメッセージを吸収することである。このステートに入 るとき、タイマーIが、信頼性のないトランスポートではT4秒で切れるように、 信頼性のあるトランスポートではゼロ秒で切れるようにセットされる。タイ マーIが切れるとすぐに、サーバーは「Terminated」ステートに移行しなけれ ばならない[MUST]。 トランザクションは、「Terminated」ステートに入るとすぐに破棄されなけ ればならない[MUST]。クライアントトランザクションと同様に、これはINVITE に対する2xx応答の信頼性を保証するために必要とされる。 17.2.2 非INVITEサーバートランザクション 非INVITEサーバートランザクションのためのステートマシンを図8に示す。 このステートマシンは「Trying」ステートの中で初期化され、初期化される ときにINVITEとACK以外のリクエストを渡される。このリクエストはTUに渡さ れる。「Trying」ステートに入るとすぐに、それ以降のすべてのリクエスト の再送は捨てられる。セクション17.2.3で規定されるルールを使用して同じ サーバートランザクションにマッチするリクエストは再送である。 「Trying」ステートにある間に、TUがサーバートランザクションに暫定 応答を渡す場合、サーバートランザクションは「Proceeding」ステートに入 らなければならない[MUST]。その応答は、送信するためにトランスポートレ イヤーに渡されなければならない[MUST]。「Proceeding」ステートにあるあ いだにTUから受け取るそれ以降のすべての暫定応答は、送信するためにトラ ンスポートレイヤーに渡されなければならない[MUST]。「Proceeding」ステー トにある間にリクエストの再送を受け取る場合、送られた最新の暫定 応答が、再送するためにトランスポートレイヤーに渡されなければならない [MUST]。「Proceeding」ステートにある間に、TUが最終応答(ステータス コード200〜699)をサーバーに渡す場合、トランザクションは「Completed」 ステートに入らなければならず[MUST]、その応答は、送信するためにトラン スポートレイヤーに渡されなければならない[MUST]。 サーバートランザクションが「Completed」ステートに入るときは、タイマー Jを、信頼性のないトランスポートでは64*T1秒で切れるように、信頼性のあ るトランスポートではゼロ秒で切れるようにセットしなければならない[MUST]。 「Completed」ステートにある間に、サーバートランザクションは、リク エストの再送を受け取るといつでも、最終応答を、再送するためにトランス ポートレイヤーに渡さなければならない[MUST]。TUがサーバートランザクショ ンに渡す他のすべての最終応答は、「Completed」ステートにある間に 捨てられなければならない[MUST]。サーバートランザクションはタイマーJが 切れるまでこのステートに留まる。タイマーJが切れる時点で、サーバートラ ンザクションは「Terminated」ステートに移行しなければならない[MUST]。 サーバートランザクションは、「Terminated」ステートに入るとすぐに破棄 されなければならない[MUST]。 Rosenberg, et. al. Standards Track [Page 137] RFC 3261 SIP: Session Initiation Protocol June 2002 17.2.3 リクエストをサーバートランザクションにマッチングする サーバーがネットワークからリクエストを受け取るとき、リクエストは既存 のトランザクションにマッチされなければならない。これは以下の方法で実 現される。 リクエストの最初のViaヘッダーフィールドのbranchパラメータが検査される。 それが存在し、「z9hG4bK」というマジッククッキーで始まる場合、そのリク エストはこの仕様に準拠するクライアントトランザクションによって生成さ れた。したがって、branchパラメータはそのクライアントが送ったすべての トランザクションに渡って一意である。以下の場合、リクエストはトランザ クションにマッチする。 1. リクエスト中のそのbranchパラメータが、トランザクションを生成し たリクエストの最初のViaヘッダーフィールドのものと同じであり、 かつ、 2. リクエストの最初のViaにあるsent-byの値が、トランザクションを生 成したリクエストのものと同じであり、かつ、 3. トランザクションを生成したリクエストのメソッドがINVITEであるACK 以外で、リクエストのメソッドがトランザクションを生成したものと マッチする。 このマッチングルールは、INVITEトランザクションと非INVITEトランザク ションの双方に同じように適用される。 sent-by値はマッチング処理の一部として使用される。なぜならば、異 なるクライアントからの偶然あるいは悪意を持ったbranchパラメータの 重複がおこりうるからである。 最初のViaヘッダーフィールドにbranchパラメータが存在しない場合、または マジッククッキーを含まない場合は、以下の手順が使用される。これはRFC 2543準拠の実装との下位互換に対処するためにある。 INVITEリクエストは、Request-URI、To tag、From tag、Call-ID、CSeq、お よび最初のViaヘッダーフィールドがトランザクションを生成したINVITEリク エストのものとマッチする場合に、トランザクションにマッチする。この場 合、そのINVITEはトランザクションを生成したオリジナルのINVITEの再送で ある。ACKリクエストは、Request-URI、From tag、Call-ID、CSeq番号(メソッ ドではない)、および最初のViaヘッダーフィールドがトランザクションを 生成したINVITEのものとマッチし、ACKのTo tagがサーバートランザクション が送った応答のTo tagにマッチする場合に、トランザクションにマッチする。 マッチングはそれら各々のヘッダーフィールドに対して定義されているマッ チングルールに基づいて行われる。ACKのマッチング処理にToヘッダーフィー ルドのtagを含めることは、プロキシで2xxに対するACKを他の応答に対するACK Rosenberg, et. al. Standards Track [Page 138] RFC 3261 SIP: Session Initiation Protocol June 2002 と明確に区別する役に立つ。そのプロキシは双方の応答を転送(forward)してい るかもしれない(これは特異な状態で起こる。具体的には、プロキシがリクエ ストをフォークしてそれからクラッシュしたとき、応答は別のプロキシに配 送されるかも知れず、そのプロキシは複数の応答をアップストリームに転送 (forward)することになる)。以前のACKにマッチしたINVITEトランザクションに マッチするACKリクエストは、その(以前の)ACKの再送とみなされる。 Rosenberg, et. al. Standards Track [Page 139] RFC 3261 SIP: Session Initiation Protocol June 2002 |リクエストを受け取る |TUに渡す V +-----------+ | | | Trying |-------------+ | | | +-----------+ |TUから200-699 | |応答を送る |Tuから1xx | |応答を送る | | | リクエスト V TUから1xx | 応答を送る +-----------+応答を送る | +--------| |--------+ | | | Proceeding| | | +------->| |<-------+ | +<--------------------| | | |トランスポートエラー +-----------+ | |TUに通知 | | | | | | |TUから200-699 | | |応答を送る | | リクエスト V | | 応答を送る +-----------+ | | +--------| | | | | | Completed |<------------+ | +------->| | +<--------------------| | |トランスポートエラー +-----------+ |TUに通知 | | |タイマーJが切れる | |- | | | V | +-----------+ | | | +-------------------->| Terminated| | | +-----------+ 図8: 非INVITEサーバートランザクション 他のすべてのリクエストメソッドでは、Request-URI、To tag、From tag、 Call-ID、Cseq(メソッドを含む)、および最初のViaヘッダーフィールドがト ランザクションを生成したリクエストのものとマッチする場合に、リクエス トはトランザクションにマッチする。マッチングは、それら各々のヘッダー Rosenberg, et. al. Standards Track [Page 140] RFC 3261 SIP: Session Initiation Protocol June 2002 フィールドに対して定義されているマッチングルールに基づいて行われる。 非INVITEリクエストが既存のトランザクションにマッチするとき、それはそ のトランザクションを生成したリクエストの再送である。 マッチングルールはRequest-URIを含むので、サーバーは応答をトランザク ションにマッチすることができない。TUが応答をサーバートランザクションに 渡すときは、その応答のターゲットにされた特定のサーバートランザクション に渡さなければならない。 17.2.4 トランスポートエラーの操作 サーバートランザクションが応答を送るためにそれをトランスポートレイヤー に送るときに、トランスポートレイヤーが失敗を示す場合、以下の手順に 従う。 最初に、応答をバックアップに配送することを試みる参考文献[4]の手順に従 う。参考文献[4]の失敗の定義に基づいて、万一それらがすべて失敗する場合、 サーバートランザクションは失敗が起こったことをTUに通知するべきであり [SHOULD]、次いで「Terminated」ステートに移行するべきである[SHOULD]。 18 トランスポート トランスポートレイヤーは、ネットワークトランスポート上でのリクエスト と応答の実際の送信に責任を負う。これは、コネクション指向のトランスポー トの場合には、リクエストや応答に使用するコネクションの決定を含む。 トランスポートレイヤーは、TCPやSCTP、あるいはそれらの上のTLSのような トランスポートプロトコルのための持続するコネクションを管理する責任を 負う(トランスポートレイヤーに対してオープンされたコネクションを含む)。 これは、クライアントトランスポートやサーバートランスポートによって開か れたオープンされたコネクションを含むため、コネクションはクライアントと サーバーのトランスポート機能のあいだで共有される。これらのコネクショ ンは、コネクションの遠端のアドレス、ポート、トランスポートプロトコル から形成されるタプルによってインデックス付けされる。トランスポートレ イヤーによってコネクションがオープンされるとき、このインデックスがデ スティネーションのIP、ポート、トランスポートに設定される。トランスポー トレイヤーがコネクションを受け入れるとき、このインデックスはソース のIPアドレス、ポート番号、トランスポートに設定される。ソースポートは 短命(ephemeral)であることが多いが、実際に短命(ephemeral)であるのか参 考文献[4]の手順で選択されたのか知ることができないので、トランスポート レイヤーが受け入れたコネクションはほとんど再利用されることはない、と いうことに注意すること。その結果、コネクション指向のトランスポートを 利用する「ピア」関係にある2つのプロキシは、使用中の2つのコネクション を多くの場合持つ。それぞれの方向で開始されたトランザクション用のもの である。 Rosenberg, et. al. Standards Track [Page 141] RFC 3261 SIP: Session Initiation Protocol June 2002 コネクション上で最後のメッセージを送るか受け取った後も、実装で定義 されたある時間のあいだ、そのコネクションはオープンされたままであるこ とが推奨される[RECOMMENDED]。この期間は少なくとも、トランザクションを 「instantiation」から「Terminated」ステートに至らせるためにエレメント が必要とする時間の最大値と同じであるべきである[SHOULD]。これは、トラ ンザクションがそれが開始されたのと同じコネクション上で完了される可能性 を高めるためである(例えば、リクエスト、応答、それとINVITEの場合には 非2xx応答に対するACK)。これは通常、少なくとも64*T1である(T1の定義はセ クション17.1.1.1参照)。しかしながら、例えばタイマーC(セクション16.6 の項目11)に大きな値を使用しているエレメントでは、この値はより大きくな るかもしれない。 すべてのSIPエレメントはUDPとTCPを実装しなければならない[MUST]。SIPエ レメントはその他のプロトコルを実装してもよい[MAY]。 UAに対してTCPを義務化することはRFC2543からの大きな変更である。こ れは、以下で議論されるように、TCPを使わなければならない[MUST]大 きなメッセージを操作するための必要性から生じた。したがって、たと えエレメントが大きなメッセージを送ることがないとしても、それを受 け取ることはあるかもしれず、それを操作できる必要があるかもしれ ない。 18.1 クライアント 18.1.1 リクエストの送信 トランスポートレイヤーのクライアント側はリクエストを送ることと応答を 受け取ることに対して責任を負う。トランスポートレイヤーのユーザーはク ライアントトランスポートに、リクエスト、IPアドレス、ポート、トランス ポートと、おそらくはマルチキャストデスティネーションのためのTTLを渡す。 リクエストがあと200バイトかそれ未満でパスのMTUのサイズに達する場合、 またはリクエストが1300バイトより大きくてパスのMTUが未知の場合、リクエ ストは、例えばTCPのような、RFC2914(参考文献[43])の輻輳(ふくそう)制御さ れたトランスポートプロトコルを使用して送られなければならない[MUST]。こ れによって先頭のViaで示したものからトランスポートプロトコルが変わる場 合は、先頭のViaの値は変更されなければならない[MUST]。これはUDP上でメッ セージのフラグメント化を防ぎ、大きなメッセージのための輻輳制御を提供す る。しかしながら、実装はデータグラムの最大パ ケットサイズまでのメッ セージを操作できなければならない[MUST]。UDPにおいては、IPとUDPのヘッ ダーサイズを含めて、このサイズは65,535バイトである。 メッセージサイズとMTUのあいだの200バイトの「バッファ」は、SIPの 応答がリクエストよりも大きくなることがあるという事実に対応する。 これは例えばINVITEに対する応答へのRecord-Routeヘッダーフィール ド値の追加のために起こる。余分なバッファのために、応答はリクエス トよりもおよそ170バイト大きくなることができ、それでもIPv4でフラ グメント化しない(約30バイトはIPSecがないとして、IP/UDPで消費され Rosenberg, et. al. Standards Track [Page 142] RFC 3261 SIP: Session Initiation Protocol June 2002 る)。MTUが未知の時には、イーサネットのMTUが1500バイトであるとい う仮定に基づいて、1300が選択される。 エレメントが、これらのメッセージサイズ制限のために、そうでなければUDPで 送られた筈のリクエストをTCPで送った場合に、コネクションを確立する試み がICMP Protocol Not Supportedを生成するかTCPのリセットを招く結果にな るなら、エレメントはUDPを使ってリクエストを再試行するべきである[SHOULD]。 これは、TCPをサポートしないRFC2543準拠の実装との下位互換を提供するた めだけである。この仕様の今後の改定において、この動作は反対されること が予想される。 マルチキャストアドレスにリクエストを送るクライアントは、デスティネー ションのマルチキャストアドレスを含むmaddrパラメータをViaヘッダーフィー ルド値に追加しなければならず[MUST]、IPv4では、値1のttlパラメータを 追加するべきである[SHOULD]。IPv6のマルチキャストの用法はこの仕様では 定義されておらず、必要性が生じたときに将来の標準化の対象になるだろう。 これらのルールはSIPにおけるマルチキャストのしっかりとした目的のある制 限をもたらす。それの主要な働きは、リクエストを同種(homogeneous)サーバー のグループに配送して「単一ホップ発見のような(single-hop-discovery- like)」サービスを提供することである(いずれか一つのサーバーからの応答 を処理することだけが必要とされる)。この機能は登録に対して最も有用であ る。実際、セクション17.1.3のトランザクション処理に基づいて、クライア ントトランザクションは最初の応答を受け入れ、その他のすべては同じViaの branch識別子を含むので、それらを再送とみなす。 リクエストが送られる前に、クライアントトランスポートはViaヘッダーフィー ルドにsent-byフィールドの値を挿入しなければならない[MUST]。このフィー ルドはIPアドレスまたはホスト名、およびポートを含む。FQDNの使用が推 奨される[RECOMMENDED]。このフィールドは以下に述べられる特定の状況下で 応答を送るために使用される。ポートがない場合の初期値はトランスポート に依存する。UDP、TCP、SCTPでは5060、TLSでは5061である。 信頼性のあるトランスポートでは、応答は通常、リクエストを受け取ったコ ネクション上で送られる。したがって、クライアントトランスポートはリク エストを送るために使用したのと同じコネクション上で応答を受け取ること に備えなければならない[MUST]。エラー状況下では、サーバーは、応答を送 るために新たなコネクションのオープンを試みるかもしれない。このケース を対処するために、トランスポートレイヤーは、リクエストを送ったソースIP アドレスとsent-byフィールド中のポート番号上でやってくるコネクションを 受け取ることにも備えなければならない[MUST]。それはまた、参考文献[4] Rosenberg, et. al. Standards Track [Page 143] RFC 3261 SIP: Session Initiation Protocol June 2002 のセクション5で述べられている手順に基づいてサーバーが選択するいかなる アドレスとポート上でやってくるコネクションでも受け取る用意をしていなけ ればならない[MUST]。 信頼性のないユニキャストトランスポートでは、リクエストを送ったソースIP アドレス(応答はソースアドレスに送り返されるので)とsent-byフィールドの ポート番号で応答を受け取るための用意を、クライアントトランスポートは しなければならない[MUST]。さらに、信頼性のあるトランスポートと同様に、 特定の場合には応答は別の場所に送られる。クライアントは、参考文献[4]の セクション5で述べられている手順に基づいてサーバーが選択するいかなるア ドレスとポート上で受け取る応答でも受け取る用意をしていなければならな い[MUST]。 マルチキャストでは、リクエストが送られた先と同じマルチキャストグルー プとポートで応答を受け取る用意を、クライアントトランスポートはしなけ ればならない[MUST](すなわち、それはリクエストを送ったマルチキャストグ ループのメンバーになる必要がある)。 リクエストが、既存のコネクションがオープンしているあるIPアドレス、ポー ト、およびトランスポートに向けられた場合、そのリクエストを送るため にこのコネクションを使用することを推奨する[RECOMMENDED]が、別のコネク ションをオープンして使用してもよい[MAY]。 リクエストがマルチキャストを使用して送られる場合、それはそのトランス ポートユーザーによって提供されるグループアドレス、ポート、およびTTLに 送られる。リクエストがユニキャストの信頼性のないトランスポートを使用 して送られる場合、それはそのトランスポートユーザーによって提供される IPアドレスおよびポートに送られる。 18.1.2 応答の受信 応答を受け取るとき、クライアントトランスポートは最初のViaヘッダーフィー ルド値を検査する。そのヘッダーフィールド値のsent-byパラメータの値が、 リクエストに挿入するためにクライアントトランスポートに設定されている 値に対応しない場合、その応答はだまって捨てられなければならない[MUST]。 存在するクライアントトランザクションがあれば、クライアントトランスポー トはその応答を既存のトランザクションにマッチさせることを試みるため に、セクション17.1.3のマッチング手順を使用する。マッチするものがある 場合、その応答はそのトランザクションに渡されなければならない[MUST]。 そうでなければ、その応答は更なる処理のために(それがステートレスプロキ シ、ステートフルプロキシ、あるいはUAであるか否かにかかわらず)コアに渡 されなければならない[MUST]。これらの「コースから外れた」応答の操作は、 コアに依存する(例えば、プロキシがそれらを転送(forward)するのに対して、 UAはそれを捨てる)。 Rosenberg, et. al. Standards Track [Page 144] RFC 3261 SIP: Session Initiation Protocol June 2002 18.2 サーバー 18.2.1 リクエストの受信 サーバーは、そのサーバーと通信する目的で「渡される」SIP URIまたはSIPS URI(参考文献[4])のDNSルックアップの結果になる可能性があるどのようなIP アドレス、ポート、トランスポートの組み合わせのリクエストを受け取るこ とにも備えるべきである[SHOULD]。このコンテキストにおいて、「渡される」 ということには、あるREGISTERリクエストまたはリダイレクト応答のContact ヘッダーフィールドにURIを置くこと、またはリクエストや応答の Record-RouteヘッダーフィールドにURIを置くことも含まれる。URIはまた、 それをWebページや名刺に掲載することによっても「渡す」ことができる。 サーバーはすべての公開インターフェースのデフォルトSIPポート(TCPとUDPで は5060、TCP上のTLSでは5061)上のリクエストをリッスンすることが推奨され る[RECOMMENDED]。典型的な例外はプライベートネットワークのときや、同一 ホスト上で複数のサーバーインスタンスが走っているときである。サーバー がUDPのためにリッスンするいかなるポートとインターフェースも、サーバー はTCPに対してもそれと同じポート、インターフェースをリッスンしなければ ならない[MUST]。これは、メッセージが大きすぎる場合は、メッセージはUDP ではなくてTCPで送られる必要があるかもしれないからである。結果として、 その逆は正しくない。サーバーは、それがTCPのために特定のアドレスとポー トをリッスンしているからというだけで、UDPのためにそれと同じアドレスと ポートをリッスンする必要はない。もちろんその他にサーバーが特定のアド レスとポートをリッスンする必要がある理由があるかもしれない。 サーバートランスポートが何らかのトランスポート上でリクエストを受け取 るとき、それは最初のViaヘッダーフィールド値のsent-byパラメータの値を 検査しなければならない[MUST]。sent-byパラメータのホスト部分がドメイン 名を含む場合、あるいはそれがパケットのソースアドレスと異なるIPアドレ スを含む場合、サーバーはそのViaヘッダーフィールド値にreceivedパラメー タを追加しなければならない[MUST]。このパラメータはソースアドレス(この ソースアドレスからパケットを受け取った)を含まなければならない[MUST]。 これは、応答がリクエストがやって来たソースIPアドレスに送られなければ ならないので、サーバーのトランスポートレイヤーが応答を送るのを支援す るためである。 サーバートランスポートが受け取ったリクエストの、以下のような部分を考 えてみる。 INVITE sip:bob@Biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060 リクエストは192.0.2.4というソースIPアドレスと共に受け取られた。リクエ ストを上に渡す前に、トランスポートは、receivedパラメータを追加する。 そのため、リクエストの一部は以下のようになるだろう。 INVITE sip:bob@Biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=192.0.2.4 Rosenberg, et. al. Standards Track [Page 145] RFC 3261 SIP: Session Initiation Protocol June 2002 次に、サーバートランスポートはリクエストをサーバートランザクションに マッチしようとする。それはセクション17.2.3に述べられているマッチング ルールを使用してそれを行う。マッチするサーバートランザクションが見つ かる場合、リクエストは、処理のためにそのトランザクションに渡される。 マッチするものが見つからない場合、リクエストはコアに渡される。コアは そのリクエストのための新規サーバートランザクションを構築することを決 定するかもしれない。UASコアがINVITEに対して2xx応答を送るとき、サーバー トランザクションは破棄されるということに注意すること。これは、ACKが 到着するときに、マッチするサーバートランザクションが一つもないだろう ことを意味し、このルールに基づいてACKはUASコアに渡されてそこで処理さ れることを意味する。 18.2.2 応答の送信 サーバートランスポートは応答をどこに送るか決定するために、最初のViaヘッ ダーフィールドの値を使用する。それは以下の手順に従わなければならない [MUST]。 o sent-protocolがTCPやSCTP、あるいはそれらの上のTLSのような信頼 性のあるトランスポートプロトコルの場合、応答は、そのトランザク ションを生成したオリジナルリクエストの発信元への既存のコネクショ ンを使用して(そのコネクションがまだオープンしていれば)送られ なければならない[MUST]。これは、サーバートランスポートがサーバー トランザクションとトランスポートコネクションのあいだの関係を 保持することを要求する。そのコネクションがもはやオープンしてい ない場合、サーバーは、もし存在すればreceivedパラメータのIPアド レスへのコネクションを、sent-by値のポートを使用して、またはポー トが指定されていなければそのトランスポートのデフォルトポート を使用して、オープンするべきである[SHOULD]。そのコネクションの 試みが失敗する場合、コネクションをオープンして応答を送るための IPアドレスとポートを決定するために、サーバーは参考文献[4]のサー バーのための手順を使うべきである[SHOULD]。 o そうでなければ、Viaヘッダーフィールド値がmaddrパラメータを含む 場合、sent-byで示されるポート、または存在しなければポート5060 を使用して、そこにリストされているアドレスに応答が転送(forward)さ れなければならない[MUST]。アドレスがマルチキャストアドレスの場 合、ttlパラメータで示されるTTLを使用して、あるいはそのパラメー タが存在しないときはTTLを1として、応答が送られるべきである[SHOULD]。 o そうでなければ(信頼性のないユニキャストトランスポートでは)、最 初のViaがreceivedパラメータを持つ場合、sent-by値で示されるポー ト、あるいは明示的に指定されていないときは5060を使用して、received パラメータのアドレスに応答が送られなければならない[MUST]。これ が例えばICMPの「port unreachable」応答を引き出すなどして失敗 する場合、応答をどこに送るか決定するために、参考文献[4]のセク ション5の手順を使うべきである[SHOULD]。 Rosenberg, et. al. Standards Track [Page 146] RFC 3261 SIP: Session Initiation Protocol June 2002 o そうでなければ、それがreceiverにtag付けされていなかった場合、 参考文献[4]のセクション5に述べられている手順を使って、sent-by 値によって示されるアドレスに応答が送られなければならない{MUST]。 18.3 フレーム化 メッセージ指向のトランスポート(UDPなど)の場合、メッセージがContent- Lengthヘッダーフィールドを持っているなら、メッセージボディは多くのバ イトを含むと想定される。トランスポートパケット中のボディの終わり以降 に付加的なバイトがある場合、それらは破棄されなければならない[MUST]。 トランスポートパケットがメッセージが終わる前に終了する場合、これはエ ラーとみなされる。メッセージが応答である場合、それは破棄されなければ ならない[MUST]。メッセージがリクエストである場合、エレメントは400(Bad Request)応答を生成するべきである[SHOULD]。メッセージがContent-Length ヘッダーフィールドを持たない場合、メッセージボディはトランスポートパ ケットの終わりで終了すると想定される。 ストリーム指向のトランスポート(TCPなど)の場合、Content-Lengthヘッダー フィールドはボディのサイズを示す。Content-Lengthヘッダーフィールドは、 ストリーム指向のトランスポートとともに使用されなければならない[MUST]。 18.4 エラー操作 エラー操作は、メッセージがリクエストであるか応答であるかに依存しない。 トランスポートユーザーが、信頼性のないトランスポート上でメッセージを 送ることを要求し、その結果がICMPエラーの場合、動作はICMPエラーのタイ プに依存する。ホスト、ネットワーク、ポートまたはプロトコルのunreachable エラー、あるいはパラメータに問題があるエラーは、トランスポートレイヤー がトランスポートユーザーに送信時の失敗を通知する原因になるべきである [SHOULD]。Source quenchとTTL exceededのICMPエラーは無視するべきであ る[SHOULD]。 トランスポートユーザーが信頼性のあるトランスポート上でリクエストを送 ることを要求し、その結果がコネクションの失敗である場合、トランスポー トレイヤーはトランスポートユーザーに送信時の失敗を通知するべきである [SHOULD]。 19 コモンメッセージコンポーネント SIPメッセージ中の様々な場所に現れる(時にはメッセージの外に)、個別に議 論する価値がある、SIPメッセージの特定のコンポーネントがある。 Rosenberg, et. al. Standards Track [Page 147] RFC 3261 SIP: Session Initiation Protocol June 2002 19.1 SIP URIとSIPS URI SIP URIまたはSIPS URIはコミュニケーションリソースを特定する。すべての URIと同様に、SIP URIとSIPS URIはWebページ、Eメールメッセージ、あるい は印刷物に掲載できる。それらはリソースとコミュニケーションセッション を開始し保持するために十分な情報を含んでいる。 コミュニケーションリソースの例としては以下のものがある。 o オンラインサービスのユーザー o マルチライン電話上のアピアランス o メッセージングシステム上のメールボックス o ゲートウェイサービスにおけるPSTN番号 o 組織内のグループ(例えば、［sales(セールス)」や「helpdesk(ヘ ルプデスク)」 SIPS URIはリソースに安全にコンタクトすることを指定する。これは特に、 UACとそのURIを所持するドメイン間でTLSが使用されることを意味する。そこ からは、ユーザーに到達するために、特定のセキュリティの仕組みがその ドメインのポリシーに依存する安全なコミュニケーションが利用される。そ のリソースと安全にコミュニケーションすることを望む場合は、SIP URIによ って記述されるいかなるリソースも、スキームを変更するだけでSIPS URIに 「アップグレード」できる。 19.1.1 SIP URIコンポーネントとSIPS URIコンポーネント 「sip:」および「sips:」スキームはRFC2396(参考文献[5])のガイドラインに 従う。それらはmailto URLに似た形式を使用し、SIP request-headerフィー ルドとSIP message-bodyの指定を可能にする。これは、Webページ上またはE- メールメッセージ中でURIを使って開始されたセッションのサブジェクト、メ ディアタイプ、または緊急度を指定することを可能にする。SIP URIやSIPS URIの正式な構文はセクション25で提示される。SIP URIの場合の一般的な形式 は以下のようである。 sip:user:password@host:port;uri-parameters?headers SIPS URIの形式は、スキームがsipに代わってsipsになることを除いて、これ と同じである。これらのトークンおよびいくつかの拡張されたトークンは以 下のような意味を持つ。 user: 宛先となるhostにおける特定のリソースの識別子。このコンテキ スト中の用語「host」はドメインをさすことが多い。URIの 「userinfo」はこのuserフィールド、passwordフィールドおよび それに続く@から成る。URIのuserinfo部分はオプションであり、 デスティネーションホストがユーザーという観念を持たないとき、 Rosenberg, et. al. Standards Track [Page 148] RFC 3261 SIP: Session Initiation Protocol June 2002 またはホスト自身が特定されるリソースであるときは、省略しても よい[MAY]。SIP URIまたはSIPS URIに@記号が存在する場合、user フィールドを空にしてはならない[MUST NOT]。 宛先となるホストが電話番号を処理することが可能な場合、例えば インターネットテレフォニーゲートウェイの場合、RFC2806(参考 文献[9])で定義されているtelephone-subscriberフィールドを、 userフィールドを埋めるために使用してもよい[MAY]。セクション19.1.2 で述べられる、SIP URIおよびSIPS URIでtelephone-subscriberフィ ールドをエンコードするための特別なエスケープのルールがある。 password: userに関連付けられたパスワード。SIP URIおよびSIPS URI の構文はこのフィールドの存在を認めるが、それの使用は推奨され ない[NOT RECOMMENDED]。なぜなら、クリアテキストで認証情報を渡 す(URIなど)ことは、それが使用されるほとんどすべてのケースでセ キュリティリスクになることが証明されているからである。例えば、 このフィールドでPINナンバーを送ることは、PINを暴露することに なる。 passwordフィールドはuser部分の単なる拡張であることに注意する こと。そのフィールドのpassword部分に特別な意味を与えることを 望まない実装は、「user:password」を単に一つの文字列として扱っ てもよい[MAY]。 host: SIPリソースを提供するホスト。host部分は、FQDN、あるいは数 値のIPv4またはIPv6アドレスを含む。可能な場合は、FQDN形式を 使用することが推奨される[RECOMMENDED]。 port: リクエストが送られるポート番号。 URI parameters: そのURIから構築されるリクエストに影響するパラメー タ。 URI parametersは、hostportコンポーネントの後に追加され、セ ミコロンで区切られる。 URIparametersは次の形式を取る。 parameter-name "=" parameter-value URIには任意の個数のURI parametersを含められるとはいえ、どの parameter-nameも2回以上現れてはならない[MUST NOT]。 この拡張可能な仕組みは、transport、maddr、ttl、user、 method、およびlrパラメータを含む。 Rosenberg, et. al. Standards Track [Page 149] RFC 3261 SIP: Session Initiation Protocol June 2002 transportパラメータは、参考文献[4]で規定されているように、 SIPメッセージを送るために使用されるトランスポートの仕組み を決定する。SIPはどのようなネットワークトランスポートプロト コルでも使用できる。パラメータ名はUDP(RFC768 参考文献[14])、 TCP(RFC761 参考文献[15])、およびSCTP(RFC2960 参考文献[16]) のために定義されている。SIPS URIでは、transportパラメータは 信頼性のあるトランスポートを示さなければならない[MUST]。 maddrパラメータは、hostフィールドから得られるいかなるアドレ スも無視して、このユーザーのためにコンタクトするサーバーア ドレスを示す。maddrパラメータが存在するとき、URIのportおよ びtransportコンポーネントはmaddrパラメータ値で示されるアド レスに適用される。参考文献[4]は、リクエストを送るためにデス ティネーションのアドレス、ポート、トランスポートを取得する ための、transport、maddr、およびhostportの適切な解釈につい て述べている。 maddrフィールドは、ルーズソースルーティングの単純な形式とし て使用されている。これは、デスティネーションに向かう途中で トラバースしなければならないプロキシをURIが指定することを可 能にする。maddrパラメータをこのように使用しつづけることには 強く水を差されている(それを可能にする仕組みは反対されて いる)。実装はその代わりに、必要であれば既存のルートセットを 制定して(セクション8.1.1.1参照)、このドキュメントで述べられ ているRouteの仕組みを使用するべきである。これは、トラバー スされるノードを記述するための完全なURIを与える。 ttlパラメータは、UDPマルチキャストパケットの存続時間の値を 決定する。ttlパラメータは、maddrがマルチキャストアドレスで、 かつトランスポートプロトコルがUDPの場合にのみ使用されなけれ ばならない[MUST]。例えば、ttlが15で、239.255.255.1への マルチキャストを使用してalice@atlanta.comへのコールを指定 するには、次のURIが使用されるだろう。 sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15 有効なtelephone-subscriber文字列のセットは、有効なuser文字 列のサブセットである。userのURI parameterは、期せずして電話 番号に似ているユーザー名と電話番号を区別するために存在する。 user文字列がtelephone-subscriberとしてフォーマットされた電 話番号を含む場合、userパラメータ値「phone」が存在するべきで ある[SHOULD]。このパラメータがない場合でも、SIP URIおよび SIPS URIの受信者は、ユーザー名のための名前空間のローカル制限 が許可する場合は、@の前の部分を電話番号として解釈してもよい [MAY]。 URIから構築されたSIPリクエストのメソッドは、methodパラメー タで指定できる。 Rosenberg, et. al. Standards Track [Page 150] RFC 3261 SIP: Session Initiation Protocol June 2002 lrパラメータが存在するときは、このリソースに対して責任を負 うエレメントがこのドキュメントで規定されているルーティング の仕組みを実装することを示す。このパラメータは、プロキシ がRecord-Routeヘッダーフィールド値に置くURIで使用される。ま た、既存のルートセットのURIに現れるかもしれない。 このパラメータは、RFC2543とbis-05までのrfc2543bisドラフトの ストリクトルーティングの仕組みを実装するシステムとの下位 互換を実現するために使用される。このパラメータを含まないURI に基づいてリクエストを送る用意をしているエレメントは、受信 側エレメントがストリクトルーティングを実装し、Request-URIの 情報を保持するためにメッセージを再形成すると仮定できる。 uri-parameterの仕組みは拡張可能なので、SIPエレメントは 理解できないどのようなuri-parameterもだまって無視しなければ ならない[MUST]。 Headers: URIから構築されるリクエストに含められるヘッダーフィー ルド。 SIPリクエストのHeadersフィールドは、「?」の仕組みでURI中 に指定できる。ヘッダー名と値は、アンパサンドで区切られた hname = hvalueの対でエンコードされる。特別なhnameである「body」 は、関連付けられたhvalueがSIPリクエストのメッセージボディで あることを示す。 表1は、URIが現れるコンテキストに基づくSIP URIおよびSIPS URIコンポーネ ントの使用方法をまとめたものである。external列には、SIPメッセージ外の どこか(例えば、Webページや名刺の上)に現れるURIを記述する。「m」と マークされたエントリは必須、「o」とマークされたエントリはオプション、 「-」とマークされたエントリは許可されていない。URIを処理するエレメン トは、許可されていないコンポーネントがあった場合にはそれを無視するべ きである[SHOULD]。2番めの列は、オプションのエレメントの初期値を示す( それが存在しない場合の)。「--」はそのエレメントがオプションでないかあ るいは初期値を持たないことを示す。 Contactヘッダーフィールド中のURIは、そのヘッダーフィールドが現れるコ ンテキストに依存した異なる制限を持つ。一つはダイアログを確立し維持す るメッセージ(INVITEとそれに対する200(OK)応答)に適用する。他は登録とリ ダイレクトメッセージ(REGISTER、それに対する200(OK)応答、およびあらゆ るメソッドに対する3xxクラス応答)に適用する。 Rosenberg, et. al. Standards Track [Page 151] RFC 3261 SIP: Session Initiation Protocol June 2002 19.1.2 文字エスケープ要求事項 dialog reg./redir. Contact/ default Req.-URI To From Contact R-R/Route external user -- o o o o o o password -- o o o o o o host -- m m m m m m port (1) o - - o o o user-param ip o o o o o o method INVITE - - - - - o maddr-param -- o - - o o o ttl-param 1 o - - o - o transp.-param (2) o - - o o o lr-param -- o - - - o o other-param -- o o o o o o headers -- - - - o - o (1): デフォルトポート値はトランスポートおよびスキームに依存する。UDP、 TCP、SCTPを使用するsip:の初期値は5060である。TCP上でTLSを使用するsip:、 およびTCP上のsips:の初期値は5061である。 (2): デフォルトトランスポートはスキームに依存する。sip:ではUDPである。 sips:ではTCPである。 表1: SIPヘッダーフィールド値、Request-URI、referencesのためのURIコン ポーネントの使用方法と初期値 SIPは、SIP URI中でエスケープされなければならないキャラクタセットを 定義する際にRFC2396(参考文献[5])の要求とガイドラインに従い、エスケー プにそれの「"%" HEX HEX」の仕組みを使用する。RFC2396(参考文献[5])に よると、 与えられたどのURIコンポーネント内で実際に予約されているキャラク タセットも、そのコンポーネントによって定義される。一般的に、文 字がエスケープされたUS-ASCIIエンコーディングで置き換えられるとき に(参考文献[5])、URIのセマンティクスが変更される場合、その文字は 予約される。スペースや制御文字、URIの区切り文字などの、除外され たUS-ASCII文字(RFC2396 参考文献[5])も、エスケープされなければな らない[MUST]。URIはエスケープされていないスペースと制御文字を含 んではならない[MUST NOT]。 各コンポーネントにおいて、有効なBNFセットの拡張が、厳密にどの文字がエ スケープされずに現れるかを定義する。他のすべての文字はエスケープされ なければならない[MUST]。 例えば、「@」はuserコンポーネントのキャラクタセットに含まれていな いので、ユーザー「j@sOn」は少なくとも@記号を、「j%40sOn」のように、エ ンコードされなければならない。 Rosenberg, et. al. Standards Track [Page 152] RFC 3261 SIP: Session Initiation Protocol June 2002 セクション25のhnameトークンとhvalueトークンの拡張は、ヘッダーフィール ド名とヘッダーフィールド値中のURIで予約されているすべての文字がエスケー プされなければならない[MUST]ことを示す。 ユーザーコンポーネントのtelephone-subscriberサブセットは、エスケープ 時の特別な考慮を要する。telephone-subscriberに関するRFC2806(参考文献 [9])の記述で予約されていないキャラクタセットは、さまざまな構文の要 素に、SIP URIで使用されるときにエスケープする必要がある多くの文字を 含む。userルールのためのBNF拡張に現れない、telephone-subscriber 中に出てくる文字はいずれも、エスケープされなければならない[MUST]。 文字エスケープはSIP URIあるいはSIPS URIのhostコンポーネントでは許可さ れていないことに注意すること(それの拡張では「%」文字は有効ではない)。 これはドメイン名の国際化の要求が完成した時点で将来的に変更される可能 性が高い。現在の実装では、hostコンポーネントで受け取ったエスケープ文 字をそれのエスケープされていない形とリテラルに同じものとして処理する ことで堅牢性を高めることを試みてはならない[MUST NOT]。IDN(ドメイン名 の国際化)の要求に合致するために必要とされる動作は、大きく異なるかもし れない。 19.1.3 SIP URIとSIPS URIの例 sip:alice@atlanta.com sip:alice:secretword@atlanta.com;transport=tcp sips:alice@atlanta.com?subject=project%20x&priority=urgent sip:+1-212-555-1212:1234@gateway.com;user=phone sips:1212@gateway.com sip:alice@192.0.2.4 sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com sip:alice;day=tuesday@atlanta.com 上記の最後のURIの例は、userフィールド値「alice;day=tuesday」を持つ。 上で定義されたエスケープのルールは、このフィールドでセミコロンがエス ケープされずに現れることを許可する。このプロトコルの目的のために、 そのフィールドは不透明(opaque)である。その値の構造は、そのリソースに 責任を負うSIPエレメントに対してのみ有用である。 19.1.4 URIの比較 この仕様中のいくつかの操作は、2つのSIP URIまたはSIPS URIが等価かどう か決定することを要求する。この仕様では、登録サーバーはREGISTERリクエ ストのContact URIのバインディングを比較する必要がある(セクション10.3 参照)。SIP URIおよびSIPS URIは以下のルールに従って同等性を比較さ れる。 o SIP URIとSIPS URIは決して等価にならない。 Rosenberg, et. al. Standards Track [Page 153] RFC 3261 SIP: Session Initiation Protocol June 2002 o SIP URIおよびSIPS URIのuserinfoの比較は大文字小文字を区別する。 これには、userinfoがパスワードを含むかtelephone-subscriberとし てフォーマットされている場合も含まれる。他のすべてのURIのコン ポーネントの比較は、明示的に定義されていなければ、大文字小文字 を区別しない。 o SIP URIおよびSIPS URIを比較するときに、パラメータとヘッダーの 並び順は重要ではない。 o 「reserved」セット中のもの以外のキャラクタ(RFC2396 参考文 献[5]参照)は、それらの「"%" HEX HEX」エンコーディングと等価で ある。 o ホスト名のDNSルックアップの結果としてのIPアドレスは、そのホス ト名とマッチしない。 o 2つのURIが等価であるためには、user、password、host、およびport コンポーネントがマッチしなければならない。 userコンポーネントを省略するURIは、それを含むURIにマッチしない。 passwordコンポーネントを省略するURIは、それを含むURIにマッチし ない。 初期値を持つコンポーネントを省略するURIは、そのコンポーネント を明示的にそれの初期値とともに含むURIにはマッチしない。例えば、 オプションのportコンポーネントを省略するURIは、明示的にport 5060を宣言しているURIにはマッチしない。transport-parameter、 ttl-parameter、user-parameter、およびmethodの各コンポーネント についても同じことが言える。 sip:user@hostがsip:user@host:5060と等価ではないと定義するこ とは、RFC2543からの変更である。アドレスをURIから導出すると き、等価なURIからは等価なアドレスが期待される。 sip:user@host:5060というURIは常にポート5060に解決される。 sip:user@hostというURIは、参考文献[4]で定義されているDNS SRV の仕組みを通して他のポートに解決されるかもしれない。 o URIのuri-parameterコンポーネントは、以下のように比較される。 - 双方のURIに現れるどのようなuri-parameterもマッチしなければな らない。 - 一つのURIのみに現れるuser、ttl、あるいはmethodのuri-parameter は、それが初期値を含んでいたとしてもマッチしない。 - maddrパラメータを含むURIは、maddrパラメータを含まないURIにマッ チしない。 - 一つのURIのみに現れるその他すべてのuri-parameterは、URIを比 較するときは無視される。 Rosenberg, et. al. Standards Track [Page 154] RFC 3261 SIP: Session Initiation Protocol June 2002 o URIのheaderコンポーネントは決して無視されない。存在するいかな るheaderコンポーネントも、URIがマッチするためには、両方のURIに 存在してマッチしなければならない[MUST]。マッチングルールは、セ クション20の各ヘッダーフィールドに対して定義されている。 以下の各組のURIは等価である。 sip:%61lice@atlanta.com;transport=TCP sip:alice@AtLanTa.CoM;Transport=tcp sip:carol@chicago.com sip:carol@chicago.com;newparam=5 sip:carol@chicago.com;security=on sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com sip:alice@atlanta.com?subject=project%20x&priority=urgent sip:alice@atlanta.com?priority=urgent&subject=project%20x 以下の各組のURIは同等ではない。 SIP:ALICE@AtLanTa.CoM;Transport=udp (異なるusername) sip:alice@AtLanTa.CoM;Transport=UDP sip:bob@biloxi.com (異なるポートに解決されることがある) sip:bob@biloxi.com:5060 sip:bob@biloxi.com (異なるトランスポートに解決されることがある) sip:bob@biloxi.com;transport=udp sip:bob@biloxi.com (異なるポートとトランスポートに解決されることがある) sip:bob@biloxi.com:6000;transport=tcp sip:carol@chicago.com (異なるheaderコンポーネント) sip:carol@chicago.com?Subject=next%20meeting sip:bob@phone21.boxesbybob.com (phone21.boxesbybob.comが解決され sip:bob@192.0.2.4 る結果がたとえそうだったとしてもマッチ しない) イコールは推移的[訳注]ではないという点に注意。 [訳注: 推移的(transitive)に関する補足情報。 a R b、b R cのとき、a R cが成立するとき、Rは推移的(transitive) と言う。 例: ・a = b、b = c のとき a = cと言える場合 → イコールは推移的 ・a < b、b < c のとき a < cと言える場合 → 大なりは推移的 ・ドメインa-b間に信頼関係、b-c間に信頼関係が成立すると き、a-c間にも信頼関係が成立する場合 → 推移的な信頼関係 ※Windows Active Directoryがこれに当てはまる。 ] o sip:carol@chicago.com と sip:carol@chicago.com;security=on は等価である o sip:carol@chicago.com と sip:carol@chicago.com;security=off は等価である Rosenberg, et. al. Standards Track [Page 155] RFC 3261 SIP: Session Initiation Protocol June 2002 o sip:carol@chicago.com;security=on と sip:carol@chicago.com;security=off は等価ではない 19.1.5 URIからリクエストを作る 実装はURIから直接リクエストを作るときは気をつける必要がある。名刺やWeb ページの、および登録されている連絡先といったプロトコル内部のソースの ものであっても、URIは不適切なヘッダーフィールドやボディ部分を含むかも しれない。 実装は、提供されたどのようなtransport、maddr、ttl、またはuserパラメー タも、形成されたリクエストのRequest-URIに含めなければならない[MUST]。 URIがmethodパラメータを含む場合は、リクエストのメソッドとしてそれの値 が使用されなければならない[MUST]。methodパラメータはRequest-URIに置い てはならない[MUST NOT]。未知のURIパラメータはメッセージのRequest-URI に置かなければならない[MUST]。 実装は、URI中のすべてのヘッダーまたはボディ部分の存在を、それらをメッ セージに含める要望として処理し、リクエストをコンポーネントごとに引き 受ける(honor)ことを選択するべきである[SHOULD]。 実装は次の明らかに危険なヘッダーフィールドを引き受ける(honor)べきでは ない[SHOULD NOT]。それは、From、Call-ID、CSeq、Via、およびRecord-Route である。 実装は、悪意ある攻撃に無断で使用されることがないように、リクエストさ れたどのようなRouteヘッダーフィールド値も引き受ける(honor)べきではな い[SHOULD NOT]。 実装は、それの場所や能力を不正に知らせることになるかもしれないヘッダー フィールドを含めるためのリクエストを引き受ける(honor)べきではない [SHOULD NOT]。これには、Accept、Accept-Encoding、Accept-Language、 Allow、Contact(ダイアログの用途で)、Organization、Supported、および User-Agentが含まれる。 実装はリクエストされたすべての記述的ヘッダーフィールド(Content-Disposition、 Content-Encoding、Content-Language、Content-Length、Content-Type、Date、 Mime-Version、およびTimestamp)の正確さを検証するべきである[SHOULD]。 与えられたURIからメッセージを構築することによって形成されたリクエスト が有効なSIPリクエストでない場合、そのURIは無効である。実装はこのリク エストの送信を続行してはならない[MUST NOT]。その代わりに、それが起こ ったコンテキスト中で無効なURIに対して取られるべき措置をとるべきである。 構築されたリクエストはいろいろな形で無効になることがある。それに は、ヘッダーフィールドの構文エラー、URIパラメータの無効な組み合 わせ、あるいはメッセージボディの正しくない記述が(これだけではな いが)含まれる。 Rosenberg, et. al. Standards Track [Page 156] RFC 3261 SIP: Session Initiation Protocol June 2002 与えられたURIから形成されたリクエストを送ることは、その実装で利用でき ない能力を要求するかもしれない。例えば、URIは実装されていないトラン スポートや拡張の使用を示するかもしれない。実装は、それの能力に合うよ うにこれらのリクエストを修正するのではなく、送ることを拒否するべきで ある[SHOULD]。実装は、それがサポートしない拡張を要求するリクエストを 送ってはならない[MUST NOT]。 例えば、そのようなリクエストは、未知のあるいは明らかにサポート されていない値を持つRequireヘッダーパラメータまたはURIのmethodパ ラメータの存在を通して形成されることがある。 19.1.6 SIP URIとtel URLを関係付ける tel URL(RFC2806 参考文献[9])がSIP URIまたはSIPS URIに変換されるとき、 tel URLのtelephone-subscriber部分全体(すべてのパラメータを含む)はSIP URIまたはSIPS URIのuserinfo部分に置かれる。 したがって、tel:+358-555-1234567;postd=pp22 は次のようになる sip:+358-555-1234567;postd=pp22@foo.com;user=phone または sips:+358-555-1234567;postd=pp22@foo.com;user=phone 次のようにはならない sip:+358-555-1234567@foo.com;postd=pp22;user=phone または sips:+358-555-1234567@foo.com;postd=pp22;user=phone 通常、SIP URIまたはSIPS URIにこのように変換された等価なtel URLは、等 価なSIP URIまたはSIPS URIを生み出さないかもしれない。SIP URIまたはSIPS URIのuserinfoは大文字小文字を区別する文字列として比較される。tel URL の大文字小文字を区別しない部分の不一致とtel URLパラメータの並べ替えは tel URLの等価性に影響を与えない。しかし、それらから形成されるSIP URI の等価性には影響を与える。 例えば、 tel:+358-555-1234567;postd=pp22 tel:+358-555-1234567;POSTD=PP22 は等価であるが、 sip:+358-555-1234567;postd=pp22@foo.com;user=phone sip:+358-555-1234567;POSTD=PP22@foo.com;user=phone Rosenberg, et. al. Standards Track [Page 157] RFC 3261 SIP: Session Initiation Protocol June 2002 は等価ではない。 同様に、 tel:+358-555-1234567;postd=pp22;isub=1411 tel:+358-555-1234567;isub=1411;postd=pp22 は等価であるが sip:+358-555-1234567;postd=pp22;isub=1411@foo.com;user=phone sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phone は等価でない。 この問題を軽減するために、SIPまたはSIPS URIのuserinfo部分に置く telephone-subscriberを構築するエレメントは、telephone-subscriberの 大文字小文字を区別しないすべての部分を小文字に畳み込み、さらに、 isdn-subaddressとpost-dialを例外として(これは最初に発生し、また、 その順通りに発生するので)、telephone-subscriberをレキシカル(lexical) に並べ替えるべきである[SHOULD]。(将来拡張されるパラメータを除くtel URLのすべてのコンポーネントは、大文字小文字を区別しないで比較され るように定義されている。) この提案に従って、以下の2つは tel:+358-555-1234567;postd=pp22 tel:+358-555-1234567;POSTD=PP22 次のようになり sip:+358-555-1234567;postd=pp22@foo.com;user=phone 以下の2つは tel:+358-555-1234567;tsp=a.b;phone-context=5 tel:+358-555-1234567;phone-context=5;tsp=a.b 次のようになる sip:+358-555-1234567;phone-context=5;tsp=a.b@foo.com;user=phone 19.2 オプションタグ オプションタグはSIPの新しいオプション(拡張)を指定するために使用される 一意の識別子である。これらのタグはRequireヘッダーフィールド(セクショ ン20.32)、Proxy-Requireヘッダーフィールド(セクション20.29)、Supported ヘッダーフィールド(セクション20.37)、およびUnsupportedヘッダーフィー ルド(セクション20.40)で使用される。これらのオプションは、それらのヘッ ダーフィールド中で「option-tag = token」形式のパラメータとして現れる (トークンの定義についてはセクション25参照のこと)ことに注意すること。 Rosenberg, et. al. Standards Track [Page 158] RFC 3261 SIP: Session Initiation Protocol June 2002 オプションタグはstandards track RFCで定義される。これは過去の慣例から の変更であり、複数ベンダーの相互運用性を継続することを確実にするため に制定された(セクション20.32とセクション20.37の議論を参照)。簡単に参 照できることを保証するために、オプションタグのIANAレジストリが使用さ れる。 19.3 タグ 「tag」パラメータはSIPメッセージのToフィールドとFromフィールドで使用 される。それは、ダイアログの各参加者からの、2つのtagとCall-IDの組み合 わせであるダイアログを特定するための一般的な仕組みとしての役目を 果たす。UAがダイアログ外のリクエストを送るとき、それは、ダイアログID の「半分」を提供するFrom tagのみを含む。ダイアログは応答(一つまたは複 数)で完成する。各応答はToヘッダーフィールドに残りの半分を与える。SIP リクエストのフォークとは、一つのリクエストから複数のダイアログが確立 できることを意味する。このことも、両方の側から提供されるダイアログ識 別子の必要性を説明する。受信側の協力なしには、発信側は一つのリクエス トで確立される複数のダイアログを明確化することができない。 tagがリクエストや応答に挿入されるためにUAによって生成されるとき、それ はグローバルに一意で、32ビットのランダム性を持って暗号的にランダムで なければならない[MUST]。この選択の要求の特性は、UAがINVITEのFromヘッ ダーに、その同じINVITEに対する応答のToヘッダーに置くだろうものとは異 なるtagを置くことである。これはUAがそれ自身をセッションに招待するため に必要になる。これはPSTNゲートウェイで呼を「ヘアピンする」ための一般 的なケースである。同様に、異なる呼に対する2つのINVITEは別のFrom tagを 持ち、異なる呼に対する2つの応答は別のToタグを持つだろう。 グローバルな一意性に対する要求とは別に、tagを生成するためのアルゴリズ ムは実装に固有である。tagはフォールトトレラントシステムにおいて役に立 つ。そこでは、サーバーの故障後に代わりのサーバーでダイアログが回復さ れる。故障したサーバー上のダイアログの一部としてバックアップがリクエ ストを認識でき、したがってそれがダイアログとそれに関連する他のすべて のステートの回復を試みるべきであると決定できるようなtagを、UASは選択 できる。 20 ヘッダーフィールド ヘッダーフィールドの一般的な構文はセクション7.3に含まれている。 このセクションでは、ヘッダーフィールドの完全なセットを、構文、意味、お よび使用方法の注意事項と共に列挙する。このセクション全体を通して、現 在のHTTP/1.1仕様(RFC2616 参考文献[8])のセクションX.Yを参照するために、 [HX.Y]という表記を使用する。各ヘッダーフィールドの例も与えられている。 Rosenberg, et. al. Standards Track [Page 159] RFC 3261 SIP: Session Initiation Protocol June 2002 メソッドとプロキシ処理に関連するヘッダーフィールドについての情報は、 表2と表3にまとめられている。 「where」列は、そのヘッダーフィールドが使用されるリクエストと応答のタ イプについて述べる。この列の値は以下のようである。 R: そのヘッダーフィールドはリクエスト中にのみ現れる。 r: そのヘッダーフィールドは応答中にのみ現れる。 2xx、4xx、など: 数値や数字の範囲は応答コードを示す。それと共にそ のヘッダーフィールドを使用できる。 c: そのヘッダーフィールドはリクエストから応答にコピーされる。 「where」列の空のエントリは、そのヘッダーフィールドがすべてのリ クエストおよび応答に存在できることを示す。 「proxy」列は、プロキシがヘッダーで実行することができる動作について述 べる。 a: そのヘッダーフィールドが存在しない場合、プロキシはそれを追加 または結合できる。 m: プロキシは既存のヘッダーフィールド値を修正できる。 d: プロキシはヘッダーフィールド値を削除できる。 r: プロキシはそのヘッダーフィールドを読めなければならず、それゆ えこのヘッダーフィールドは暗号化できない。 その次の6列は、メソッド中のヘッダーフィールドの存在に関係する。 c: Conditional; そのヘッダーフィールドに対する要求はメッセージの コンテキストに依存する。 m: そのヘッダーフィールドは必須である。 m*: そのヘッダーフィールドは送られるべき[SHOULD]だが、クライアン ト/サーバーはそのヘッダーフィールドがないメッセージを受信す ることに備える必要がある。 o: そのヘッダーフィールドはオプションである。 t: そのヘッダーフィールドは送られるべき[SHOULD]だが、クライアン ト/サーバーはそのヘッダーフィールドがないメッセージを受信す ることに備える必要がある。 ストリームベースのプロトコル(例えばTCP)がトランスポートと して使用される場合、そのヘッダーフィールドが送られなければ ならない[MUST]。 Rosenberg, et. al. Standards Track [Page 160] RFC 3261 SIP: Session Initiation Protocol June 2002 *: そのヘッダーフィールドは、メッセージボディが空でない場合に要 求される。詳細についてはセクション20.14、20.15、7.4参照のこ と。 -: そのヘッダーフィールドは適用不可能である。 「オプション」は、あるエレメントがそのヘッダーフィールドをリクエスト または応答に含めてもよく[MAY]、UAはリクエストまたは応答にそのヘッダー が存在する場合にそれを無視してもよい[MAY]ことを意味する(このルールの 例外は、20.32で議論されるRequireヘッダーフィールドである)。「必須」の ヘッダーフィールドは、リクエスト中に存在しなければならず[MUST]、その リクエストを受け取るUASによって理解されなければならない[MUST]。必須の 応答ヘッダーフィールドは、応答中に存在しなければならず[MUST]、その応 答を処理するUACによって理解されなければならない[MUST]。「適用不可能」 は、そのヘッダーフィールドがリクエスト中に存在してはならない[MUST NOT] ことを意味する。誤ってリクエスト中に置かれた場合、それはそのリク エストを受け取るUASによって無視されなければならない[MUST]。同様に、 応答に対して「適用不可能」とラベル付けされたヘッダーフィールドは、 UASがそのヘッダーフィールドを応答中に置いてはならず[MUST NOT]、UAC は応答中のそのヘッダーを無視しなければならない[MUST]ことを意味する。 UAは理解できない拡張ヘッダーパラメータを無視するべきである[SHOULD]。 いくつかの一般的なヘッダーフィールド名の短縮形も、メッセージ全体のサイ ズが問題となるときに使用するために定義されている。 Contactヘッダーフィールド、Fromヘッダーフィールド、およびToヘッダー フィールドはURIを含む。そのURIがカンマ、疑問符、あるいはセミコロンを含 む場合、そのURIはカギ括弧(< と >)で囲まれなければならない[MUST]。いか なるURI parameterもこれらの括弧内に含められる。URIがカギ括弧で囲まれ ていない場合、セミコロンで区切られたどのようなパラメータもURI parameter ではなくheader-parameterである。 20.1 Accept Acceptヘッダーフィールドは[H14.1]で定義されている構文に従う。Acceptヘッ ダーフィールドが存在しない場合にサーバーがapplication/sdpという初期値 を仮定するべきである[SHOULD]ということを除けば、セマンティクスも同じで ある。 空のAcceptヘッダーフィールドは、どの形式も受け入れられないことを意味 する。 Rosenberg, et. al. Standards Track [Page 161] RFC 3261 SIP: Session Initiation Protocol June 2002 例: Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________ Accept R - o - o m* o Accept 2xx - - - o m* o Accept 415 - c - c c c Accept-Encoding R - o - o o o Accept-Encoding 2xx - - - o m* o Accept-Encoding 415 - c - c c c Accept-Language R - o - o o o Accept-Language 2xx - - - o m* o Accept-Language 415 - c - c c c Alert-Info R ar - - - o - - Alert-Info 180 ar - - - o - - Allow R - o - o o o Allow 2xx - o - m* m* o Allow r - o - o o o Allow 405 - m - m m m Authentication-Info 2xx - o - o o o Authorization R o o o o o o Call-ID c r m m m m m m Call-Info ar - - - o o o Contact R o - - m o o Contact 1xx - - - o - - Contact 2xx - - - m o o Contact 3xx d - o - o o o Contact 485 - o - o o o Content-Disposition o o - o o o Content-Encoding o o - o o o Content-Language o o - o o o Content-Length ar t t t t t t Content-Type * * - * * * CSeq c r m m m m m m Date a o o o o o o Error-Info 300-699 a - o o o o o Expires - - - o - o From c r m m m m m m In-Reply-To R - - - o - - Max-Forwards R amr m m m m m m Min-Expires 423 - - - - - m MIME-Version o o - o o o Organization ar - - - o o o 表2: ヘッダーフィールドの概要(A〜O) Rosenberg, et. al. Standards Track [Page 162] RFC 3261 SIP: Session Initiation Protocol June 2002 Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________________ Priority R ar - - - o - - Proxy-Authenticate 407 ar - m - m m m Proxy-Authenticate 401 ar - o o o o o Proxy-Authorization R dr o o - o o o Proxy-Require R ar - o - o o o Record-Route R ar o o o o o - Record-Route 2xx,18x mr - o o o o - Reply-To - - - o - - Require ar - c - c c c Retry-After 404,413,480,486 - o o o o o 500,503 - o o o o o 600,603 - o o o o o Route R adr c c c c c c Server r - o o o o o Subject R - - - o - - Supported R - o o m* o o Supported 2xx - o o m* m* o Timestamp o o o o o o To c(1) r m m m m m m Unsupported 420 - m - m m m User-Agent o o o o o o Via R amr m m m m m m Via rc dr m m m m m m Warning r - o o o o o WWW-Authenticate 401 ar - m - m m m WWW-Authenticate 407 ar - o - o o o 表3: ヘッダーフィールドの概要(P〜Z); (1): tagが追加されてコピーされ ることもある Accept: application/sdp;level=1, application/x-private, text/html 20.2 Accept-Encoding Accept-Encodingヘッダーフィールドは、Acceptに似ているが、応答で受け入 れ可能なcontent-codings[H3.5]を制限する。[H14.3]を参照のこと。SIPに おけるセマンティクスは[H14.3]で定義されているものと同じである。 空のAccept-Encodingヘッダーフィールドは認められている。それは Accept-Encoding: identity と等価である。つまり、identityエンコーディ ング(エンコーディングなしの意味)だけが許可されているということで ある。 Accept-Encodingヘッダーフィールドが存在しない場合、初期値であるidentity をサーバーは仮定するべきである[SHOULD]。 Rosenberg, et. al. Standards Track [Page 163] RFC 3261 SIP: Session Initiation Protocol June 2002 これはHTTPの定義とは若干異なる。HTTPの定義では、存在しない場合はどの ようなエンコーディングでも使用できるが、identityエンコーディングが好 ましい。 例: Accept-Encoding: gzip 20.3 Accept-Language Accept-Languageヘッダーフィールドは、応答中でメッセージボディとして運 ばれるreasonフレーズ、セッション記述、あるいはステータス応答に好まし い言語を示すために、リクエストで使用される。Accept-Languageヘッダー フィールドが存在しない場合、そのクライアントに対してはすべての言語が認 められるとサーバーは仮定するべきである[SHOULD]。 Accept-Languageヘッダーフィールドは[H14.4]で定義されている構文に従う。 言語をqパラメータに基づいて順番付けするルールはSIPにも適用される。 例: Accept-Language: da, en-gb;q=0.8, en;q=0.7 20.4 Alert-Info INVITEリクエスト中に存在するとき、Alert-InfoヘッダーフィールドはUASに 対して代替の呼び出し音(ring tone)を指定する。180(Ringing)応答中に存在 するとき、Alert-InfoヘッダーフィールドはUACに対して代替の呼び出し音 (ringback tone)を指定する。典型的な使用方法は、プロキシが特有の呼び出 し機能を提供するためにこのヘッダーを挿入することである。 Alert-Infoヘッダーフィールドはセキュリティリスクを持ち込むことがある。 これらのリスクとそれを操作する方法は、Call-Infoヘッダーフィールドにつ いて議論しているセクション20.9で(リスクが同一のため)議論する。 さらに、ユーザーはこの機能を選択的に無効にすることができるべきである [SHOULD]。 これは、信頼できないエレメントによってこのヘッダーが使用されるこ とで生じるかもしれない混乱を防ぐ役に立つ。 例: Alert-Info: Rosenberg, et. al. Standards Track [Page 164] RFC 3261 SIP: Session Initiation Protocol June 2002 20.5 Allow Allowヘッダーフィールドは、そのメッセージを生成するUAがサポートするメ ソッドの組を列挙する UAが理解するACKとCANCELを含むすべてのメソッドは、Allowヘッダーが存在 するときはその中のメソッドのリストに含まれなければならない[MUST]。 Allowヘッダーフィールドがないことを、メッセージを送るUAがどのメソッド もサポートしないという意味に解釈してはならない[MUST NOT]。そうではな くむしろ、それは、UAがどのメソッドをサポートするかについてのいかなる 情報も提供していないことを示唆する。 OPTIONS以外のメソッドに対する応答中でAllowヘッダーフィールドを供給す ることは、必要とされるメッセージの数を減らす。 例: Allow: INVITE, ACK, OPTIONS, CANCEL, BYE 20.6 Authentication-Info Authentication-Infoヘッダーフィールドは相互認証にHTTPダイジェスト認証 を提供する。UASは、Authorizationヘッダーフィールドに基づきダイジェス ト認証を使用して正しく認証されたリクエストに対する2xx応答中に、この ヘッダーフィールドを含めてもよい[MAY]。 構文とセマンティクスはRFC2617(参考文献[17])で規定されているものに従う。 例: Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c" 20.7 Authorization Authorizationヘッダーフィールドは、UAの認証の信用証明書を含む。セクショ ン22.2でAuthorizationヘッダーフィールドの使用方法の概略を示し、セクショ ン22.4でHTTP認証で使用されるときの構文とセマンティクスを述べる。 Proxy-Authorizationに加えてこのヘッダーフィールドは、複数ヘッダーフィー ルド値に関する一般ルールを破る。カンマ区切りのリストではないが、このヘッ ダーフィールド名は複数回存在でき、セクション7.3で述べられてる通常のルー ルを使用して一つのヘッダーに結合してはならない[MUST NOT]。 Rosenberg, et. al. Standards Track [Page 165] RFC 3261 SIP: Session Initiation Protocol June 2002 下記の例では、Digestパラメータは引用符で囲まれていない。 Authorization: Digest username="Alice", realm="atlanta.com", nonce="84a4cc6f3082121f32b42a2187831a9e", response="7587245234b3434cc3412213e5f113a5432" 20.8 Call-ID Call-IDヘッダーフィールドは、特定の招待または特定のクライアントのすべ ての登録を一意に識別する。一つのマルチメディアカンファレンスは異なる Call-IDでいくつかの呼を引き起こすことができる(例えば、ユーザーが一 個人を(長時間継続している)同一の呼に複数回招待する場合)。Call-IDは大 文字小文字を区別し、単純にバイトごとに比較される。 Call-IDヘッダーフィールドの短縮形は i である。 例: Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4 20.9 Call-Info Call-Infoヘッダーフィールドは、それがリクエスト中あるいは応答中のどち らで見つけられるかに応じて、発呼側または着呼側についての付加的な情報 を提供する。URIの目的は「purpose」パラメータで述べられる。「icon」パ ラメータは、発呼側または着呼側のアイコン表示に適切な画像を示す。「info」 パラメータは一般的に、例えばWebページを介して、発呼側あるいは着呼側 を説明する。「card」パラメータは、例えば、vCard(参考文献[36])または LDIF(参考文献[37])で名刺を提供する。追加のトークンをIANAとセクション27 の手順を使用して登録できる。 Call-Infoヘッダーフィールドの利用はセキュリティリスクを引き起こすこと がある。着呼側が悪意のある発呼側が提供したURIを取り出す場合、着呼側は、 不適切または不快なコンテンツ、危険または不法なコンテンツ、などを表示 するリスクにさらされる。したがって、UAは、そのヘッダーフィールドを発 信したエレメントの信頼性を検証でき、そのエレメントを信頼できる場合に のみ、Call-Infoヘッダーフィールドの情報を描画することが推奨される [RECOMMENDED]。プロキシもこのヘッダーフィールドをリクエストに挿入でき るので、これは相手UAでなくてもよい。 例: Call-Info: ;purpose=icon, ;purpose=info Rosenberg, et. al. Standards Track [Page 166] RFC 3261 SIP: Session Initiation Protocol June 2002 20.10 Contact Contactヘッダーフィールド値は、URIを提供する。そのURIの意味は、それが含 まれるリクエストまたは応答のタイプに依存する。 Contactヘッダーフィールド値は、表示名、URIパラメータを持つURI、および ヘッダーパラメータを含むことができる。 このドキュメントではContactのパラメータ「q」と「expires」を定義する。 これらのパラメータはContactがREGISTERリクエスト、REGISTER応答、または 3xx応答中に存在するときにのみ使用される。追加のパラメータが他の仕様で 定義されるかもしれない。 ヘッダーフィールド値が表示名を含むとき、URI(すべてのURIパラメータを含 む)は「<」と「>」で囲まれる。「<」と「>」が存在しない場合、URIの後 のすべてのパラメータはURIパラメータではなく、ヘッダーパラメータである。 表示名はトークンあるいは(より大きな文字セット(※)が望まれる場合は)引用 符で囲まれた文字列にできる。 [訳注: 「より大きな文字セット(a larger character set)」は、 US-ASCII(Basic Latin)を基本セットとして、それより大きな 文字セットを指すと推測される。] 「display-name」が空であっても、「addr-spec」がカンマ、セミコロン、ま たは疑問符を含む場合は「name-addr」形式が使用されなければならない[MUST]。 display-nameと「<」の間にLWSがあってもなくてもよい。 表示名、URIとURIパラメータ、およびヘッダーパラメータをパースするため のこれらのルールは、ToとFromのヘッダーフィールドにも適用される。 Contactヘッダーフィールドは、HTTPのLocationヘッダーフィールドに 似た機能を果たす。そうではあるが、HTTPのLocationヘッダーフィール ドは引用符で囲まれていない一つのアドレスを認めるだけである。URI は予約文字としてカンマとセミコロンを含むので、それらはそれぞれ ヘッダーの区切り文字およびパラメータの区切り文字と間違えられること がある。 Contactヘッダーフィールドの短縮形は(movedの) m である。 例: Contact: "Mr. Watson" ;q=0.7; expires=3600, "Mr. Watson" ;q=0.1 m: ;expires=60 Rosenberg, et. al. Standards Track [Page 167] RFC 3261 SIP: Session Initiation Protocol June 2002 20.11 Content-Disposition Content-Dispositionヘッダーフィールドは、メッセージボディまたは(マル チパートメッセージでは)メッセージボディ部分がUACやUASによってどのよう に解釈されるかを説明する。このSIPヘッダーフィールドはMIMEのContent-Type (RFC2183 参考文献[18])を拡張する。 Content-Dispositionヘッダーのいくつかの新しい「disposition-types」が SIPで定義された。「session」という値は、ボディ部分が呼またはearly(呼 以前の)メディアのいずれかに対するセッションを記述することを示す。 「render」という値は、ボディ部分がユーザーに対して表示(display)される か、そうでなければ描画/再生/提示(render)されるべきであることを示す。 (SIPメッセージのMIMEボディはユーザーに対して表示されないことが多いの で)MIMEボディがメッセージ全体のレンダリングの一部として表示されるとい う暗示的意味を避けるために、「inline」ではなく「render」という値が使 用されることに注意すること。下位互換性のために、Content-Disposition ヘッダーがない場合、サーバーは、Content-Typeがapplication/sdpのボディは dispositionが「session」であると仮定する一方、その他のcontentタイプは 「render」であると仮定するべきである[SHOULD]。 「icon」というdispositionタイプは、ボディ部分が、発呼側または着呼側の アイコン表示に適切な画像を含むことを示す。それは、メッセージが受け取 られたとき、あるいはダイアログが行われているあいだずっと、ユーザー エージェントが通知目的で描画してもよい。「alert」という値は、ボディ部分 がオーディオクリップのような情報を含むことを示す。それは、ユーザーに リクエスト(通常、ダイアログを開始するリクエスト)の受信に対する注意を 喚起する試みとしてユーザーエージェントが再生するべきである。この注意 喚起のボディは、例えば電話の呼び出し音として180(Ringing)暫定応答が 送られた後に再生することができる。 ユーザーにコンテンツを描画/再生/提示(render)するdispositionタイプを持 ついかなるMIMEボディも、メッセージが適切に認証されたときにのみ処理さ れるべきである。 handling-paramは、contentタイプまたはdispositionタイプが理解できない メッセージボディを受け取った場合に、UASがどのように動作するべきかを記 述する。このパラメータは「optional」と「required」という値を定義して いる。handling-paramがない場合は、「required」と仮定されるべきであ る[SHOULD]。handling-paramについてはRFC3204(参考文献[19])に述べられて いる。 このヘッダーフィールドがない場合、MIMEタイプがcontent dispositionの初 期値を決定する。ない場合は「render」と仮定される。 例: Content-Disposition: session Rosenberg, et. al. Standards Track [Page 168] RFC 3261 SIP: Session Initiation Protocol June 2002 20.12 Content-Encoding Content-Encodingヘッダーフィールドはmedia-typeのモディファイアとして 使用される。これが存在するとき、その値はentity-bodyにどんな付加的なコ ンテンツコーディングが適用されているかを示し、それゆえContent-Typeヘッ ダーフィールドによって参照されるmedia-typeを取得するためにどんなデコー ディングの仕組みが適用されなければならない[MUST]かを示す。 Content-Encodingは、ボディの基礎を成すメディアタイプのアイデンティティ を失わずにそれを圧縮することを可能にするために主に使用される。 entity-bodyに複数のエンコーディングが適用されている場合、適用された順 番でコンテンツコーディングがリストされなければならない[MUST]。 すべてのcontent-coding値は大文字小文字を区別しない。IANAはcontent-coding 値トークンのレジストリとしての役を務める。content-codingの構文の定義に ついては[H3.5]を参照のこと。 クライアントはコンテントエンコーディングをリクエスト中のボディに適用 してもよい[MAY]。サーバーは応答中のボディにコンテントエンコーディング を適用してもよい[MAY]。サーバーはリクエストのAccept-Encodingヘッダー フィールドにリストされているエンコーディングのみを使用しなければならな い[MUST]。 Content-Encodingヘッダーフィールドの短縮形は e である。 例: Content-Encoding: gzip e: tar 20.13 Content-Language [H14.12]参照。 例: Content-Language: fr 20.14 Content-Length Content-Lengthヘッダーフィールドは、受信者に送られたmessage-bodyのサ イズを、オクテットの個数(10進数)で示す。アプリケーションは、エンティ ティのメディアタイプに関係なく、送られるmessage-bodyのサイズを示すた めにこのフィールドを使用するべきである[SHOULD]。ストリームベースのプ ロトコル(TCPなど)がトランスポートとして使用される場合は、このヘッダー フィールドが使用されなければならない[MUST]。 message-bodyのサイズにはヘッダーフィールドとボディを分けるCRLFを含ま ない。ゼロ以上のいかなるContent-Lengthも有効な値である。メッセージ中 にボディが存在しない場合、Content-Lengthヘッダーフィールドはゼロに設 定されなければならない[MUST]。 Rosenberg, et. al. Standards Track [Page 169] RFC 3261 SIP: Session Initiation Protocol June 2002 Content-Lengthを省略する能力は、応答を動的に生成するCGIライクの スクリプトの作成を容易にする。 このヘッダーフィールドの短縮形は l である。 例: Content-Length: 349 l: 173 20.15 Content-Type Content-Typeヘッダーフィールドは受信者に送られたmessage-bodyのメディ アタイプを示す。「media-type」エレメントは[H3.7]で定義されている。 Content-Typeヘッダーフィールドはボディが空でない場合は必ず存在しなけ ればならない[MUST]。ボディが空でContent-Typeヘッダーフィールドが存在 する場合、その特定のタイプのボディの長さがゼロであることを示す(例え ば、空の音声ファイル)。 このヘッダーの短縮形は c である。 例: Content-Type: application/sdp c: text/html; charset=ISO-8859-4 20.16 CSeq リクエスト中のCSeqヘッダーフィールドは、一つの10進数のシーケンス番号 とリクエストメソッドを含む。シーケンス番号は32ビットの符号なし整数で 表現可能でなければならない[MUST]。CSeqのメソッド部分は大文字小文字を 区別する。CSeqヘッダーは、ダイアログ内のトランザクションを順番付ける ため、トランザクションを一意に特定するための手段を提供するため、そし て新規リクエストとリクエストの再送を区別するため、の役に立つ。2つの CSeqヘッダーフィールドは、シーケンス番号とメソッドが同一であれば、等 価であるとみなされる。 例: CSeq: 4711 INVITE 20.17 Date Dateヘッダーフィールドは日付と時間を含む。HTTP/1.1とは違い、SIPは、日 付に最新のRFC1123(参考文献[20])の書式のみをサポートする。RFC 1123ではあらゆるタイムゾーンを許可するが、[H3.3]にあるように、SIPは SIP-dateのタイムゾーンをGMTに制限する。RFC1123のdateは大文字小文字を 区別する。 Dateヘッダーフィールドは、リクエストまたは応答が最初に送られた時間を 反映する。 Rosenberg, et. al. Standards Track [Page 170] RFC 3261 SIP: Session Initiation Protocol June 2002 Dateヘッダーフィールドは、時間の概念を取得するためのバッテリーバッ クアップされたクロックを持たない単純なエンドシステムによって使 用されることがある。しかしながら、それはGMT形式なので、クライア ントがGMTからのオフセットを知っている必要がある。 例: Date: Sat, 13 Nov 2010 23:29:00 GMT 20.18 Error-Info Error-Infoヘッダーフィールドは、エラーステータス応答についての付加的 な情報へのポインタを提供する。 SIPのUACは、PCソフトクライアント上でのポップアップウィンドウやオー ディオから、一般の電話やゲートウェイを介して接続されたエンドポ イント上でのオーディオオンリーにまでわたるユーザーインターフェー ス能力を持つ。詳細な理由フレーズを含むエラーステータスコードを送 ることと録音されたオーディオを再生することのいずれかを選択してエ ラーを生成することをサーバーに強いるのではなく、Error-Infoヘッダー フィールドはその両方を送ることを可能にする。UACは次に、どちら のエラーインジケーターを発呼側に表示/再生するかという選択肢を持 つ。 UACは、Error-InfoヘッダーフィールドのSIP URIまたはSIPS URIをリダイレク トのContactであるかのように処理し、新規INVITEを生成してもよい[MAY]。 その結果として、録音されたアナウンスのセッションが確立されることにな る。非SIP URIをユーザーに対して表示/再生してもよい[MAY]。 例: SIP/2.0 404 The number you have dialed is not in service Error-Info: 20.19 Expires Expiresヘッダーフィールドは、メッセージ(またはコンテンツ)がそれ以降期 限切れになる相対時間を与える。 これの正確な意味は、メソッドに依存する。 INVITEの期限切れ時間は、その招待で生じるセッションの実際の継続時間に 影響しない。しかしながら、セッション記述プロトコルがセッションの継続 時間のタイムリミットを表現する能力を提供するかもしれない。 このフィールドの値は、リクエストの受信時から計測された0と(2**32)-1の あいだの、秒を表す整数(10進数)である。 Rosenberg, et. al. Standards Track [Page 171] RFC 3261 SIP: Session Initiation Protocol June 2002 例: Expires: 5 20.20 From Fromヘッダーフィールドはリクエストのイニシエータを示す。これはダイ アログのイニシエータとは異なるかもしれない。着呼側が発呼側に送るリ クエストは、Fromヘッダーフィールドに着呼側のアドレスを使用する。 オプションの「display-name」は、ヒューマンユーザーインターフェースに よって表示されることを意図している。システムは、クライアントのアイデ ンティティが隠されたままになっている場合、表示名「Anonymous」を使用す るべきである[SHOULD]。「display-name」が空であっても、「addr-spec」が カンマ、セミコロン、または疑問符を含む場合は「name-addr」形式が使用さ れなければならない[MUST]。構文の問題はセクション7.3.1で議論さ れている。 2つのFromヘッダーフィールドは、そのURIがマッチし、かつ、パラメータが マッチする場合は、等価である。一方のヘッダーフィールドにあり、他方に はない拡張パラメータは、比較では無視される。これは、表示名、および、 カギ括弧(< と >)の有無は、マッチングに影響を与えないということを意味する。 表示名、URIとURIパラメータ、およびヘッダーフィールドパラメータをパース するためのルールについてはセクション20.10参照のこと。 Fromヘッダーフィールドの短縮形は f である。 例: From: "A. G. Bell" ;tag=a48s From: sip:+12125551212@server.phone2net.com;tag=887s f: Anonymous ;tag=hyh8 20.21 In-Reply-To In-Reply-Toヘッダーフィールドは、この呼が参照する、または折り返される Call-IDを列挙する。これらのCall-IDは、クライアントがキャッシュして、 折り返しかける電話のIn-Reply-Toヘッダーフィールドに含められるかもしれ ない。 これはACD(automatic call distribution)システムが折り返し電話を 最初の呼の発信元にルートすることを可能にする。これはまた、着呼側 が以前彼らが発信した呼への折り返し電話のみを受け入れられるように 呼をフィルターすることを可能にする。このフィールドはリクエスト認 証のための代替ではない。 Rosenberg, et. al. Standards Track [Page 172] RFC 3261 SIP: Session Initiation Protocol June 2002 例: In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com 20.22 Max-Forwards Max-Forwardsヘッダーフィールドは、リクエストを次のダウンストリームサー バーに転送(forward)できるプロキシまたはゲートウェイの数を制限するため に、すべてのSIPメソッドと共に使用しなければならない。これは、リクエス トチェーン内で失敗またはループしているように見えるリクエストチェーン を、クライアントがトレースすることを試みるときにも有用である。 Max-Forwards値は、このリクエストメッセージが転送(forward)されることを認 められている残り回数を示す0〜255の整数である。このカウントは、そのリ クエストを転送(forward)する各サーバーで減少させられる。推奨される初期値 は70である。 このヘッダーフィールドは、他の方法でループの検知を保証できないエレメ ントによって挿入されるべきである。例えば、B2BUAはMax-Forwardsヘッダー フィールドを挿入するべきである。 例: Max-Forwards: 6 20.23 Min-Expires Min-Expiresヘッダーフィールドは、ソフトステートエレメントのためにサポー トされる(そのサーバーで管理される)最小リフレッシュ間隔を伝える。これは、 登録サーバーによって保存されるContactヘッダーフィールドを含む。 Min-Expiresヘッダーフィールドは、0から(2**32)-1までの10進整数を含む。 423(Interval Too Brief)応答中でのこのヘッダーフィールドの用法は、 セクション10.2.8、10.3、および21.4.17で述べられている。 例: Min-Expires: 60 20.24 MIME-Version [H19.4.1]参照。 例: MIME-Version: 1.0 Rosenberg, et. al. Standards Track [Page 173] RFC 3261 SIP: Session Initiation Protocol June 2002 20.25 Organization Organizationヘッダーフィールドはリクエストまたは応答を発行するエンティ ティが所属する組織の名称を伝える。 このフィールドは呼をフィルターするためにクライアントソフトウェア が使用してもよい[MAY]。 例: Organization: Boxes by Bob 20.26 Priority Priorityヘッダーフィールドは、クライアントが認識するリクエストの緊急 度を示す。Priorityヘッダーフィールドは、SIPリクエストが受信側の人また はエージェントに対して持つべき優先順位を記述する。例えばそれは、呼 のルーティングや受け入れの決定において考慮に入れられるかもしれない。 これらの決定で、Priorityヘッダーフィールドを含まないメッセージは、あ たかもそれが「normal」というPriorityを指定したかのように扱われるべき である[SHOULD]。Priorityヘッダーフィールドは、ルータのパケットフォワー ディングの優先順位やPSTNゲートウェイのサーキットへのアクセスといっ たようなコミュニケーションリソースの用法に影響を与えない。Priorityヘッ ダーフィールドは「non-urgent」、「normal」、「urgent」、および 「emergency」を持つことができるが、追加の値がどこかで定義されることが あり得る。「emergency」という値は、生命、身体、または財産が差し迫った危 機にあるときにのみ使用されることが推奨される[RECOMMENDED]。さもなけれ ば、このヘッダーフィールドに対して定義されたセマンティクスがない。 これらは、RFC2076(参考文献[38])の値に「emergency」を追加したもの である。 例: Subject: A tornado is heading our way! Priority: emergency または Subject: Weekend plans Priority: non-urgent 20.27 Proxy-Authenticate Proxy-Authenticateヘッダーフィールド値は、認証チャレンジを含む。 このヘッダーフィールドの使用方法は[H14.33]で定義されている。使用方法 についての更なる詳細についてはセクション22.3参照のこと。 Rosenberg, et. al. Standards Track [Page 174] RFC 3261 SIP: Session Initiation Protocol June 2002 例: Proxy-Authenticate: Digest realm="atlanta.com", domain="sip:ss1.carrier.com", qop="auth", nonce="f84f1cec41e6cbe5aea9c8e88d359", opaque="", stale=FALSE, algorithm=MD5 20.28 Proxy-Authorization Proxy-Authorizationヘッダーフィールドは、認証を求めるプロキシにクライ アントがそれ自身(またはそれのユーザー)の身元を明らかにすることを可能 にする。Proxy-Authorizationフィールド値は、プロキシのためのユーザーエー ジェントの認証情報および(または)要求されているリソースの領域(realm) を含む信用証明書から成る。 このヘッダーフィールドの使用方法の定義についてはセクション22.3を参照 のこと。 Authorizationに加えてこのヘッダーフィールドは、複数ヘッダーフィールド 名に関する一般ルールを破る。カンマ区切りのリストではないが、このヘッ ダーフィールド名は複数回存在でき、セクション7.3.1で述べられてる通常の ルールを使用して一つのヘッダーに結合してはならない[MUST NOT]。 例: Proxy-Authorization: Digest username="Alice", realm="atlanta.com", nonce="c60f3082ee1212b402a21831ae", response="245f23415f11432b3434341c022" 20.29 Proxy-Require Proxy-Requireヘッダーフィールドは、プロキシによってサポートされなけれ ばならない、プロキシが理解する(proxy-sensitive)機能を示すために使用さ れる。このメッセージの構造と使用例の詳細についてはセクション20.32参照 のこと。 例: Proxy-Require: foo 20.30 Record-Route Record-Routeヘッダーフィールドは、ダイアログ中のそれ以降のリクエスト をプロキシを通してルートさせるために、そのプロキシによってリクエスト に挿入される。 Routeヘッダーフィールドと共にそれを使用することについての例はセクショ ン16.12.1で述べられている。 Rosenberg, et. al. Standards Track [Page 175] RFC 3261 SIP: Session Initiation Protocol June 2002 例: Record-Route: , 20.31 Reply-To Reply-Toヘッダーフィールドは、Fromヘッダーフィールドと異なるかもしれ ない論理的な戻りURIを含む。例えば、そのURIは、受け取れなかった電話 あるいは確立されなかったセッションに折り返しかけるために使用してもよい[MAY]。 ユーザーが匿名(anonymous)のままでいることを望む場合、Reply-Toヘッダー フィールドはリクエストから省略されるかまたはどのような個人情報も漏ら さないような方法で存在させられるべきである[SHOULD]。 「display-name」が空であっても、「addr-spec」がカンマ、セミコロン、ま たは疑問符を含む場合は「name-addr」形式が使用されなければならない[MUST]。 構文の問題はセクション7.3.1で議論されている。 例: Reply-To: Bob 20.32 Require Requireヘッダーフィールドは、リクエストを処理するためにUASがサポート することをUACが期待するオプションについて、UACがUASに伝えるために使用 される。オプションのヘッダーではあるが、Requireが存在する場合はそれを 無視してはならない[MUST NOT]。 Requireヘッダーフィールドはセクション19.2で述べられているオプションタ グのリストを含む。各オプションタグは、リクエストを処理するために理解 されなければならない[MUST]SIPの拡張を定義する。これは、ある特定の拡張 ヘッダーフィールドのセットが理解される必要があることを示すためによく 利用される。この仕様に準拠するUACは、standards-track RFCに一致するオ プションタグのみを含まなければならない[MUST]。 例: Require: 100rel 20.33 Retry-After Retry-Afterヘッダーフィールドは、リクエストを行うクライアントがどれく らいのあいだサービスを利用できないと予測されるかを示すために500 (Server Internal Error) または503(Service Unavailable)応答で、また、 着呼側パーティーが再び有効になると予測されるのはいつかを示すために 404(Not Found)、413(Request Entity Too Large)、480(Temporarily Unavailable)、486(Busy Here)、600(Busy)、あるいは603(Decline)応答で Rosenberg, et. al. Standards Track [Page 176] RFC 3261 SIP: Session Initiation Protocol June 2002 使用できる。このフィールドの値は、応答があった時間後の秒をあらわす 正の整数(10進数)である。 折り返し電話の時間についての付加情報を示すオプションのコメントを使用 できる。オプションの「duration」パラメータは、着呼側パーティーが有効 になりはじめる時間から開始してどれだけのあいだ到達可能であるかを示す。 durationパラメータが与えられない場合、サービスは無期限に利用可能であ ると仮定される。 例: Retry-After: 18000;duration=3600 Retry-After: 120 (I'm in a meeting) 20.34 Route Routeヘッダーフィールドは、リストされたプロキシのセットを経由してリク エストをルーティングさせるために使用される。Routeヘッダーフィールド の使用例はセクション16.12.1で述べられている。 例: Route: , 20.35 Server Serverヘッダーフィールドは、リクエストを操作するためにUASが使用するソ フトウェアについての情報を含む。 サーバーの具体的なソフトウェアバージョンを明かすことは、セキュリティ ホールを含むことが知られているソフトウェアへの攻撃に対してサーバーが より脆弱になることを認めるかもしれない。実装者はServerヘッダーフィー ルドを、設定可能なオプションにするべきである[SOULD]。 例: Server: HomeServer v2 20.36 Subject Subjectヘッダーフィールドは、呼の概要を提供するか、または呼の性質を示 す。そうすることでセッション記述をパースすることなしに呼のフィルタリ ングを可能にする。セッション記述は招待と同じサブジェクト表示を使用す る必要はない。 このヘッダーフィールドの短縮形は s である。 Rosenberg, et. al. Standards Track [Page 177] RFC 3261 SIP: Session Initiation Protocol June 2002 例: Subject: Need more boxes s: Tech Support 20.37 Supported Supportedヘッダーフィールドは、UACまたはUASがサポートするすべての拡張 を列挙する。 Supportedヘッダーフィールドは、UACまたはUASで理解される、セクション19. 2で述べられているオプションタグのリストを含む。この仕様に準拠するUAは standards-track RFCに一致するオプションタグのみを含まなければならない [MUST]。空の場合は、拡張がひとつもサポートされないことを意味する。 Supportedヘッダーフィールドの短縮形は k である。 例: Supported: 100rel 20.38 Timestamp Timestampヘッダーフィールドは、UACがUASにそのリクエストをいつ送ったの かについて述べる。 このヘッダーフィールドを含むリクエストに対する応答をどのように生成す るかについての詳細は、セクション8.2.6参照のこと。このヘッダーを利用す る規範となる動作はここでは定義されないが、それは拡張あるいはSIPアプリ ケーションがRTT予測値を取得することを可能にする。 例: Timestamp: 54 20.39 To Toヘッダーフィールドはリクエストの論理的な受信者を指定する。 オプションの「display-name」は、ヒューマンユーザーインターフェースに よって表示されることを意図している。「tag」パラメータは、ダイアログを 特定するための一般的な仕組みとしての役に立つ。 「tag」パラメータの詳細についてはセクション19.3参照のこと。 Rosenberg, et. al. Standards Track [Page 178] RFC 3261 SIP: Session Initiation Protocol June 2002 Toヘッダーフィールドが等価かどうかの比較は、Fromヘッダーフィールドの 比較と同じである。表示名、URIとURIパラメータ、およびヘッダーフィールド パラメータをパースするためのルールについてはセクション20.10参照のこと。 このヘッダーの短縮形は t である。 以下は有効なToヘッダーフィールドの例である。 To: The Operator ;tag=287447 t: sip:+12125551212@server.phone2net.com 20.40 Unsupported Unsupportedヘッダーフィールドは、UASがサポートしない機能を列挙する。 モチベーションについてはセクション20.32を参照のこと。 例: Unsupported: foo 20.41 User-Agent User-Agentヘッダーフィールドは、リクエストを開始するUACについての情報 を含む。このヘッダーフィールドのセマンティクスは[H14.43]で定義されてい る。 ユーザーエージェントの具体的なソフトウェアバージョンを明かすことは、 セキュリティホールを含むことが知られているソフトウェアへの攻撃に対し てユーザーエージェントがより脆弱になることを認めるかもしれない。実装 者はUser-Agentヘッダーフィールドを、設定可能なオプションにするべきで ある[SOULD]。 例: User-Agent: Softphone Beta1.5 20.42 Via Viaヘッダーフィールドは、これまでにリクエストがたどったパスと、応答を ルートするときにたどるべきパスを示す。Viaヘッダーフィールド値のbranch IDパラメータは、トランザクション識別子としての役に立ち、ループ検知の ためにプロキシに利用される。 Viaヘッダーフィールド値は、メッセージを送るために使用されるトランスポー トプロトコル、クライアントのホスト名またはネットワークアドレス、お よびおそらくはそれが応答を受け取ることを望むポート番号を含む。Viaヘッ ダーフィールド値は、maddr、ttl、received、およびbranchなどのパラメー Rosenberg, et. al. Standards Track [Page 179] RFC 3261 SIP: Session Initiation Protocol June 2002 タ(意味と使用方法は他のセクションで述べられている)を含むこともできる。 この仕様に準拠する実装では、branchパラメータの値はセクション8.1.1.7で 述べられている「z9hG4bK」というマジッククッキーで始まらなければならな い[MUST]。 ここで定義されているトランスポートプロトコルは、「UDP」、「TCP」、 「TLS」、および「SCTP」である。「TLS」はTCP上のTLS(TLS over TCP)を意 味する。リクエストがSIPS URIに対して送られるとき、プロトコルは「SIP」 を示したままで、トランスポートプロトコルはTLSになる。 Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7 Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207 ;branch=z9hG4bK77asjd このヘッダーの短縮形は v である。 この例では、メッセージは2つのアドレス、192.0.2.1 と 192.0.2.207、を持 つマルチホームホストから開始された。送信者はどのネットワークインター フェースが使用されるかということについて間違った推測をした。Erlang.bell- telephone.comはミスマッチに気付き、前のホップのViaヘッダーフィールド 値に(そのパケットが実際にやって来たアドレスを含む)パラメータを追加した。 ホストまたはネットワークアドレスとポート番号は、SIP URIの構文 に従うために必要ではない。特に、以下に示すように「:」または「/」 の両側にLWSをおくことが許可されている。 Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16 ;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1 この仕様では、すべてのリクエストにbranchパラメータが存在することを必 須としているが、ヘッダーフィールドのBNFはそれがオプションであることを 示している。このことは、branchパラメータを挿入することを必須としてい なかったRFC2543エレメントとの相互運用を可能にする。 2つのViaヘッダーフィールドは、そのsent-protocolとsent-by-fieldが同一 で、かつ、どちらも同じパラメータのセットを持ち、かつ、すべてのパラ メータ値が同一の場合、等価である。 20.43 Warning Warningヘッダーフィールドは応答のステータスについての付加情報を伝える ために使用される。Warningヘッダーフィールド値は応答で送られ、3桁の警 告コード、ホスト名、および警告文を含む。 「warn-text」は、応答を受け取るユーザー(人間)が理解できる可能性が最も 高い自然言語であるべきである。この決定は、ユーザーの場所、リクエスト のAccept-Languageフィールド、あるいは応答のContent-Languageフィールド Rosenberg, et. al. Standards Track [Page 180] RFC 3261 SIP: Session Initiation Protocol June 2002 のような利用可能な情報に基づいて下すことができる。デフォルトの言語は i-default(参考文献[21])である。 現在定義されている「warn-code」が以下にリストされている。それぞれには 推奨されるwarn-textとその意味説明が英語で付いている。これらの警告は、 セッション記述によって引き起こされた失敗について述べている。警告コー ドの最初の桁は、SIP固有の警告であることを示す3で始まる。Warningの300 から329はセッション記述のキーワードの問題を示すために予約されている。 330から339はセッション記述で要求された基本的なネットワークサービスに 関係する警告。370から379はセッション記述で要求された定量的なQoSパラメー タに関係する警告。そして、390から399は上記のカテゴリに当てはまらな いその他の警告である。 300 Incompatible network protocol (互換性がないネットワークプロ トコル): セッション記述に含まれる一つ以上のネットワークプロ トコルが利用できない。 301 Incompatible network address formats (互換性がないネットワー クアドレス書式): セッション記述に含まれる一つ以上の ネットワークアドレス書式が利用できない。 302 Incompatible transport protocol (互換性がないトランスポート プロトコル): セッション記述で述べられている一つ以上のトラン スポートプロトコルが利用できない。 303 Incompatible bandwidth units (互換性がない帯域幅の単位): セッ ション記述に含まれる一つ以上の帯域幅測定単位が理解できな かった。 304 Media type not available (利用できないメディアタイプ): セッ ション記述に含まれている一つ以上のメディアタイプが利用でき ない。 305 Incompatible media format (互換性がないメディアの書式): セッション記述に含まれている一つ以上のメディアの書式が利用で きない。 306 Attribute not understood (理解できない属性): セッション記述 中の一つ以上のメディア属性がサポートされていない。 307 Session description parameter not understood (理解できないセッ ション記述パラメータ): 上にリストされた以外のパラメータを 理解できなかった。 330 Multicast not available (マルチキャストは利用できない): ユー ザーがいる場所のサイトはマルチキャストをサポートしていない。 331 Unicast not available (ユニキャストは利用できない): ユーザー がいる場所のサイトはユニキャストによるコミュニケーションを サポートしていない(通常、ファイアウォールが存在するため)。 Rosenberg, et. al. Standards Track [Page 181] RFC 3261 SIP: Session Initiation Protocol June 2002 370 Insufficient bandwidth (帯域不足): セッション記述で指定され た帯域またはメディアで定義された帯域が、利用できることがわ かっているものを超えている。 399 Miscellaneous warning (その他の警告): ユーザー(人間)に提示さ れる、またはログに残される任意の情報を警告文に含めることが できる。この警告を受け取るシステムは、どのような自動動作も とってはならない[MUST NOT]。 1xxおよび2xxはHTTP/1.1に採用されている。 セクション27.2で定義されているように、追加のwarn-codeを、IANAを通して 定義できる。 例: Warning: 307 isi.edu "Session parameter 'foo' not understood" Warning: 301 isi.edu "Incompatible network address type 'E.164'" 20.44 WWW-Authenticate WWW-Authenticateヘッダーフィールド値は、認証チャレンジを含む。使用方 法の更なる詳細についてはセクション22.2を参照のこと。 例: WWW-Authenticate: Digest realm="atlanta.com", domain="sip:boxesbybob.com", qop="auth", nonce="f84f1cec41e6cbe5aea9c8e88d359", opaque="", stale=FALSE, algorithm=MD5 21 応答コード 応答コードはHTTP/1.1応答コードに合致し、拡張されている。すべてのHTTP/ 1.1応答コードが割り当てられているわけではなく、ここでは割り当てられて いるものだけについて述べる。他のHTTP/1.1応答コードは使用されるべきで はない[SHOULD NOT]。また、SIPは新しいクラス6xxを定義する。 21.1 暫定応答 1xx 暫定応答は(通知応答としても知られている)、コンタクトしたサーバーが更 なるアクションを実行しており、まだ確定的な応答を持たないことを示す。 サーバーは、最終応答を取得するまでに200ミリ秒以上を要することが予想さ れる場合に1xx応答を送る。1xx応答は信頼性を持って送信されないことに注 意すること。それはクライアントがACKを送る原因にならない。暫定(1xx)応 答はメッセージボディ(セッション記述を含む)を含めてもよい[MAY]。 Rosenberg, et. al. Standards Track [Page 182] RFC 3261 SIP: Session Initiation Protocol June 2002 21.1.1 100 Trying (試行中) この応答は、リクエストがネクストホップサーバーに受け取られており、こ の呼に成り代わって、特に指定されていないアクションが取られていること を示す(例: データベースが調べられている)。この応答は他のすべての暫定 応答と同様に、UACによるINVITEの再送を停止させる。100(Trying)応答は、 ステートフルプロキシによってアップストリームに決して転送(forward)されな いという点において他の暫定応答と異なる。 21.1.2 180 Ringing (呼び出し中) INVITEを受け取るUAがユーザーに注意を促そうと試みている。この応答はロー カルの呼び出し音を開始するために使用してもよい[MAY]。 21.1.3 181 Call Is Being Forwarded (呼が転送(forward)されている) サーバーは、別のデスティネーションのセットに呼が転送(forward)されている ことを示すために、このステータスコードを使用してもよい[MAY]。 21.1.4 182 Queued (キューに入れられた) 着呼側パーティーは一時的に電話に出られないが、サーバーはその呼を拒否 するのではなくキューに入れることにした。着呼側が電話に出られるように なったとき、それは適切な最終ステータス応答を返す。理由フレーズは呼の ステータスについての更なる詳細を与えてもよい[MAY]。例えば、"5 calls queued; expected waiting time is 15 minutes" (「5つの呼がキューに入れ られている。予想待ち時間は15分」)。サーバーは、キューに入れられた呼の ステータスについて、発呼側をアップデートするためにいくつかの182 (Queued)応答を発行してもよい[MAY]。 21.1.5 183 Session Progress (セッションの進捗状況) 183(Session Progress)応答は、特に区別のない呼の進捗状況についての情報 を伝えるために使用される。Reason-Phrase、ヘッダーフィールド、あるいは メッセージボディを、呼の進捗状況についての更なる詳細を伝えるために使 用してもよい[MAY]。 21.2 成功応答 2xx リクエストが成功した。 21.2.1 200 OK リクエストは成功した。応答で戻された情報は、リクエストで使用されたメ ソッドに依存する。 Rosenberg, et. al. Standards Track [Page 183] RFC 3261 SIP: Session Initiation Protocol June 2002 21.3 リダイレクト応答 3xx 3xx応答は、ユーザーの新たな場所についての、あるいは呼を満足させること ができるかもしれない代替サービスについての情報を与える。 21.3.1 300 Multiple Choices (複数の選択肢がある) リクエスト中のアドレスが解決されて、各々がそれ自身の特定の場所を持つ いくつかの選択肢が得られた。そしてユーザー(またはUA)は好みのコミュニ ケーションエンドポイントを選び、それのリクエストをその場所にリダイレ クトすることができる。 この応答は、Acceptリクエストヘッダーフィールドで許可された場合に、リ ソースの特性と場所のリストが収められたメッセージボディを含めてもよい [MAY]。ユーザーまたはUAはそこから最も好ましい一つを選ぶことができる。 しかしながら、このメッセージボディのためのMIMEタイプはひとつも定義され ていない。 選択肢はContactフィールド(セクション20.10)としてもリストされるべきで ある[SHOULD]。HTTPとは違い、SIPの応答は、いくつかのContactフィールド またはContactフィールド中にアドレスのリストを含めてもよい[MAY]。 UAはContactヘッダーフィールド値を自動リダイレクションに使用してもよい[MAY]。 あるいは選択の確認をユーザーに依頼してもよい[MAY]。しかしながら、 この仕様ではそのような自動選択のためのいかなる標準も定義しない。 着呼側に複数の異なる場所で到達可能で、かつ、サーバーがリクエスト をプロキシすることができないまたは好まない場合に、このステータス 応答がふさわしい。 21.3.2 301 Moved Permanently (恒久的に移動した) Request-URIのアドレスでユーザーをもはや見つけることができないので、リ クエストを行っているクライアントはContactヘッダーフィールド(セクショ ン20.10)で与えられた新しいアドレスで再試行するべきである[SHOULD]。リ クエストをする側は、すべてのローカルディレクトリ、アドレス帳、および ユーザーの場所のキャッシュをこの新しい値でアップデートし、今後のリク エストをリストされたアドレスにリダイレクトするべきである[SHOULD]。 21.3.3 302 Moved Temporarily (一時的に移動した) リクエストを行っているクライアントはContactヘッダーフィールド(セクショ ン20.10)で与えられた新しいアドレスでリクエストを再試行するべきである [SHOULD]。新しいリクエストのRequest-URIは、応答のContactヘッダーフィー ルドの値を使用する。 Rosenberg, et. al. Standards Track [Page 184] RFC 3261 SIP: Session Initiation Protocol June 2002 Contact URIの有効期間ははExpires(セクション20.19)ヘッダーフィールドま たはContactヘッダーフィールドのexpiresパラメータを介して示すことがで きる。プロキシとUAは両方とも有効期限時間のあいだこのURIをキャッシュし てもよい[MAY]。明示的な有効期限時間がない場合、そのアドレスは再帰のた めに一度だけ有効であり、将来のトランザクションのためにキャッシュしては ならない[MUST NOT]。 ContactヘッダーフィールドからキャッシュされたURIが失敗する場合、リダ イレクトしたリクエストのRequest-URIをもう一度だけ試してもよい[MAY]。 一時的なURIは有効期限時間よりも早く無効になってしまったのかもし れず、新しい一時アドレスが有効かもしれない。 21.3.4 305 Use Proxy (プロキシを使用せよ) リクエストしたリソースは、Contactフィールドで与えられたプロキシを通し てアクセスされなければならない[MUST]。ContactフィールドはプロキシのURI を与える。受信者はプロキシを経由してこの一つのリクエストを繰り返すこ とを期待されている。305(Use Proxy)応答はUASによってのみ生成されなけれ ばならない[MUST]。 21.3.5 380 Alternative Service (代替サービス) 呼は成功しなかったが、代わりのサービスが可能である。 代わりのサービスは応答のメッセージボディで述べられている。そのような ボディの書式はここで定義されず、将来の標準化の対象になるかもしれない。 21.4 リクエスト失敗応答 4xx 4xx応答は、特定のサーバーからの確定的な失敗応答である。クライアントは 同じリクエストを、それを修正しないで、再試行するべきではない[SHOULD NOT] (例: 適切なauthorizationを追加する)。しかしながら、同じリクエストを別 のサーバーに送れば成功するかもしれない。 21.4.1 400 Bad Request (不正なリクエスト) リクエストが異常な構文のため理解できなかった。Reason-Phraseは更に詳し く構文の問題を特定するべきである[SHOULD]。 例: "Missing Call-ID header field" (Call-IDヘッダーフィールドが見つか らない) 21.4.2 401 Unauthorized (認可されていない) リクエストはユーザー認証を要求する。この応答はUASと登録サーバーが発行 する。一方、407(Proxy Authentication Required)はプロキシサーバーが使 用する。 Rosenberg, et. al. Standards Track [Page 185] RFC 3261 SIP: Session Initiation Protocol June 2002 21.4.3 402 Payment Required (料金支払いが必要) 将来の使用のために予約されている。 21.4.4 403 Forbidden (禁止) サーバーはリクエストを理解したが、それを実行することを拒否している。 認証は役に立たないので、リクエストは繰り返されるべきではない[SHOULD NOT]。 21.4.5 404 Not Found (見つからない) Request-URIで指定されたドメインにユーザーが存在しないという確定的な情 報をサーバーが持っている。このステータスは、リクエストの受信者が操作す るどのドメインにもRequest-URIのドメインがマッチしない場合にも返される。 21.4.6 405 Method Not Allowed (メソッドが許可されていない) Request-Lineで指定されたメソッドは理解されたが、Request-URIで特定され るアドレスに対して許可されていない。 応答は、示されたアドレスに対して有効なメソッドのリストを含むAllowヘッ ダーフィールドを含まなければならない[MUST]。 21.4.7 406 Not Acceptable (受け入れできない) リクエストによって特定されたリソースは、リクエストで送られたAcceptヘッ ダーフィールドによれば、受け入れ不能なコンテンツ特性を持つ応答エンティ ティを生成することしかできない。 21.4.8 407 Proxy Authentication Required (プロキシ認証が必要) このコードは401(Unauthorized)と似ているが、クライアントがそれ自身をま ずはじめにプロキシで認証しなければならない[MUST]ことを示す。SIPのアク セス認証についてはセクション26とセクション22.3で説明されている。 このステータスコードは、着呼側ではなくコミュニケーションチャンネル(例 えば、テレフォニーゲートウェイ)へのアクセスが認証を要求するときにア プリケーションに対して使用できる。 21.4.9 408 Request Timeout (リクエストがタイムアウトした) サーバーは、例えば時間内にユーザーの場所を確定できなかった場合など、 適切な時間内に応答を生成できなかった。クライアントは、後ほどいつでも、 修正なしでそのリクエストを繰り返してもよい[MAY]。 Rosenberg, et. al. Standards Track [Page 186] RFC 3261 SIP: Session Initiation Protocol June 2002 21.4.10 410 Gone (リソースが既に存在しない) リクエストされたリソースがそのサーバーでもはや利用不可能で、転送 (forward)先のアドレスもわからない。この状態は恒久的なものであると考えら れる。その状態が恒久的なものかどうかサーバーが知らない、あるいは確定す るための機能を持たない場合、代わりにステータスコード404(Not Found)が使用 されるべきである[SHOULD]。 21.4.11 413 Request Entity Too Large (リクエストのエンティティが大きすぎる) リクエストのentity-bodyが、サーバーが処理をいとわない、または処理でき るサイズよりも大きいので、サーバーはリクエストの処理を拒否している。 サーバーは、クライアントがリクエストを継続するのを防ぐために、コネク ションをクローズしてもよい[MAY]。 その状態が一時的である場合、サーバーは、それが一時的でありどのくらい の時間経過後にクライアントが再び試行してもよい[MAY]かを示すために、 Retry-Afterヘッダーフィールドを含めるべきである[SHOULD]。 21.4.12 414 Request-URI Too Long (Request-URIが長すぎる) サーバーが解釈をいとわずに行う長さよりもRequest-URIが長いので、サーバー はリクエストを処理することを拒否している。 21.4.13 415 Unsupported Media Type (サポートされていないメディアタイプ) リクエストのメッセージボディが、リクエストされたメソッドに対してその サーバーでサポートしていない書式なので、サーバーはリクエスト を処理することを拒否している。サーバーは、コンテンツの個々の問題に応 じてAccept、Accept-Encoding、またはAccept-Languageヘッダーフィールド を使用して、受け入れ可能な書式のリストを返さなければならない [MUST]。この応答のUACでの処理についてはセクション8.1.3.5で述べられて いる。 21.4.14 416 Unsupported URI Scheme (サポートされていないURIスキーム) Request-URIのURIのスキームがサーバーの知らないものなので、サーバーは リクエストを処理できない。この応答のクライアントでの処理についてはセ クション8.1.3.5で述べられている。 21.4.15 420 Bad Extension (不正な拡張) Proxy-Require(セクション20.29)またはRequire(セクション20.32)ヘッダー フィールドで指定されたプロトコル拡張を、サーバーは理解しなかった。サー バーは応答のUnsupportedヘッダーフィールドに、サポートしていない拡張 のリストを含めなければならない[MUST]。この応答のUACでの処理について はセクション8.1.3.5で述べられている。 Rosenberg, et. al. Standards Track [Page 187] RFC 3261 SIP: Session Initiation Protocol June 2002 21.4.16 421 Extension Required (拡張が必要) UASはリクエストを処理するために特定の拡張を必要とするが、この拡張はリ クエストのSupportedヘッダーフィールドにリストされていない。このステー タスコードを持つ応答は、必要とされる拡張を列挙するRequireヘッダー フィールドを含めなければならない[MUST]。 UASは、クライアントに対していかなる有用なサービスも本当に提供できない のでなければ、この応答を使用するべきではない[SHOULD NOT]。そのかわり、 望ましい拡張がSupportedヘッダーフィールドにリストされていない場合は、 サーバーはベースラインSIP能力とクライアントがサポートしている拡張を使 用してリクエストを処理するべきである[SHOULD]。 21.4.17 423 Interval Too Brief (間隔が短すぎる) リクエストによってリフレッシュされたリソースの有効期限時間が短すぎる ため、サーバーはリクエストを拒否している。この応答は、Contactヘッダー フィールドの有効期限時間が短すぎた登録を拒否するために登録サーバーが 使用できる。この応答とそれに関連するMin-Expiresヘッダーフィールドの使 用についてはセクション10.2.8、10.3、および20.23で述べられている。 21.4.18 480 Temporarily Unavailable (一時的に利用不可) 着呼側のエンドシステムにうまくコンタクトしたが、着呼側は現在電話を受 けられない(例えば、ログインしていない、着呼側とのコミュニケーション を妨げる方法でログインしている、または「取り込み中」機能を作動させて いる)。この応答は、Retry-Afterヘッダーフィールドで電話をかけるのに都 合のいい時間を示してもよい[MAY]。そのユーザーは別の場所でも電話を受け られるということがありうる(このサーバーの知らないうちに)。理由フレー ズは、なぜ着呼側が電話に出られないのかについてのより明確な理由を示すべ きである[SHOULD]。この値はUAによって設定可能であるべきである[SHOULD]。 ステータス486(Busy Here)を、呼の失敗についての特定の理由をより明確に示 すために使用してもよい[MAY]。 このステータスは、Request-URIで特定されるユーザーを認識するがそのユー ザーに対する有効な転送(forward)場所を現在持っていないリダイレクトサー バーまたはプロキシサーバーによっても返される。 21.4.19 481 Call/Transaction Does Not Exist (呼またはトランザクションが存在しない) このステータスは、既存のどのダイアログやトランザクションにもマッチし ないリクエストをUASが受け取ったことを示す。 21.4.20 482 Loop Detected (ループが検知された) サーバーがループを検知した(セクション16.3の項目4)。 Rosenberg, et. al. Standards Track [Page 188] RFC 3261 SIP: Session Initiation Protocol June 2002 21.4.21 483 Too Many Hops (ホップが多すぎる) サーバーが値ゼロのMax-Forwardsヘッダーフィールド(セクション20.22)を含 むリクエストを受け取った。 21.4.22 484 Address Incomplete (アドレスが不完全) サーバーが不完全なRequest-URIを持つリクエストを受け取った。付加情報が 理由フレーズで提供されるべきである[SHOULD]。 このステータスコードは重複ダイヤリングを可能にする。重複ダイヤリ ングでは、クライアントはダイヤル文字列の長さを知らない。クライア ントはユーザーに更なる入力を促しながら、484(Address Incomplete) ステータス応答を受け取らなくなるまで徐々に長くなる文字列を送る。 21.4.23 485 Ambiguous (不明瞭) Request-URIが不明瞭だった。応答はContactヘッダーフィールドに、可能性 がある不明瞭ではないアドレスのリストを含めてもよい[MAY]。選択肢を 明らかにすることでユーザーまたは組織のプライバシーを犯すことがある。 不明瞭なRequest-URIに対して、404(Not Found)で応答するかまたは可能性の ある選択肢のリストを隠すようにサーバーを設定することが可能でなければ ならない[MUST]。 以下はRequest-URI(sip:lee@example.com)を持つリクエストに対する応答の 例である。 SIP/2.0 485 Ambiguous Contact: Carol Lee Contact: Ping Lee Contact: Lee M. Foote いくつかのEメールシステムやボイスメールシステムはこの機能を提供 する。セマンティクスが異なるので3xxと区別してステータスコードは 使用される。300では、提供された選択肢で同じ人やサービスに到達す ると推測される。3xx応答に対しては自動選択やシーケンシャルサーチ が意味をなすのに対して、485(Ambiguous)応答に対してはユーザーの介 入が要求される。 21.4.24 486 Busy Here (ここは現在ビジー) 着呼側のエンドシステムにうまくコンタクトしたが、着呼側は現在このエン ドシステムで別の呼を受け取りたいと思っていないか受け取れない。この応 答は、Retry-Afterヘッダーフィールドで電話をかけるのに都合のいい時間を 示してもよい[MAY]。そのユーザーは、例えばボイスメールサービスを Rosenberg, et. al. Standards Track [Page 189] RFC 3261 SIP: Session Initiation Protocol June 2002 介して、別の場所でも電話を受けられるということがありうる。この呼を他 のどのエンドシステムも受け入れることができないことをクライアントが知 っている場合、ステータス600(Busy Everywhere)が使用されるべきである [SHOULD]。 21.4.25 487 Request Terminated (リクエストが終了させられた) リクエストはBYEまたはCANCELリクエストで終了させられた。この応答はCANCEL リクエスト自身に対しては決して返されない。 21.4.26 488 Not Acceptable Here (ここでは受け入れ不能) この応答は606(Not Acceptable)と同じ意味を持つが、Request-URIでアドレ ス指定された特定のリソースに対してのみ適用されるので、リクエストは他 の場所で成功するかもしれない。 OPTIONSリクエストに対する200(OK)応答のメッセージボディと同じように、 INVITEのAcceptヘッダーフィールド(または存在しなければapplication/sdp) に従ってフォーマットされた、メディア能力の記述を含むメッセージボディが 応答中に存在してもよい[MAY]。 21.4.27 491 Request Pending (リクエストペンディング) リクエストは、同じダイアログ内にペンディング中のリクエストを持つUASに 受け取られた。セクション14.2で、このようなグレア(glare)な状況をどのよ うに解決するかについて述べる。 21.4.28 493 Undecipherable (解読不能) リクエストをUASが受け取った。そのリクエストにはその受信者が適切な暗号 解読鍵を所持しないかあるいは提供しない、暗号化されたMIMEボディを含ん でいた。この応答は、このUAに送られるMIMEボディを暗号化するために使用 されるべき適切な公開鍵を含む1個のボディを持ってもよい[MAY]。この応答 コードの用法の詳細はセクション23.2で述べられている。 21.5 サーバーでの失敗応答 5xx 5xx応答は、サーバー自身がエラーを起こしたときに与えられる失敗応答であ る。 21.5.1 500 Server Internal Error (サーバー内部エラー) サーバーがリクエストを遂行することを妨げる予期しない状態に遭遇した。 クライアントは特定のエラー状態を表示してもよく[MAY]、数秒後にリク エストを再試行してもよい[MAY]。 その状態が一時的なものである場合、サーバーはRetry-Afterヘッダーフィー ルドを使用して、クライアントがいつリクエストを再試行できるか示してもよ い[MAY]。 Rosenberg, et. al. Standards Track [Page 190] RFC 3261 SIP: Session Initiation Protocol June 2002 21.5.2 501 Not Implemented (実装されていない) サーバーはリクエストを遂行するために必要とされる機能をサポートしてい ない。これは、UASがリクエストメソッドを認識せず、いかなるユーザーに対 してもそれをサポートできないときに適切な応答である。(プロキシはメソッ ドに依らずすべてのリクエストを転送(forward)する) サーバーがリクエストメソッドは認識するがそのメソッドが許可されていな いかサポートされていないときには、405(Method Not Allowed)が送られるこ とに注意すること。 21.5.3 502 Bad Gateway (不正なゲートウェイ) サーバーが、ゲートウェイまたはプロキシとして動作している間に、リ クエストの遂行を試みてアクセスしたダウンストリームサーバーから無効な 応答を受け取った。 21.5.4 503 Service Unavailable (サービスを利用できない) サーバーは、一時的な過負荷またはメンテナンスのため、一時的にリクエス トを処理できない。サーバーは、Retry-Afterヘッダーフィールドでクライア ントがいつリクエストを再試行するべきか示してもよい[MAY]。Retry- Afterが与えられない場合、クライアントは500(Server Internal Error)応答 を受け取ったかのように動作しなければならない[MUST]。 503(Service Unavailable)を受け取るクライアント(プロキシまたはUAC)は、 代替のサーバーにリクエストの転送(forward)を試みるべきである[SHOULD]。そ れは、(もし存在すれば)Retry-Afterヘッダーフィールドで指定された期間、 そのサーバーに他のどのようなリクエストも転送(forward)するべきではない [SHOULD NOT]。 サーバーは503(Service Unavailable)で応答する代わりに、コネクションを 拒否するかリクエストを取りやめてもよい[MAY]。 21.5.5 504 Server Time-out (サーバータイムアウト) サーバーは、リクエストの処理を試みてアクセスした外部サーバーからタイ ムリな応答を受け取らなかった。Expiresヘッダーフィールドで指定した期 間内にアップストリームサーバーから応答がない場合、408(Request Timeout) が代わりに使用されるべきである。 21.5.6 505 Version Not Supported (サポートされていないバージョン) サーバーはリクエストで使用されたSIPプロトコルのバージョンをサーポート していないかサポートを拒否している。サーバーは、クライアントとして同 じメジャーバージョンを使用するリクエストを、このエラーメッセージ以外 では完了できないか完了するつもりがないことを示している。 Rosenberg, et. al. Standards Track [Page 191] RFC 3261 SIP: Session Initiation Protocol June 2002 21.5.7 513 Message Too Large (メッセージが大きすぎる) メッセージ長がサーバーの処理能力を超えたので、サーバーはリクエストを 処理できなかった。 21.6 グローバル失敗応答 6xx 6xx応答は、サーバーが、Request-URIで示された特定のインスタンスだけで はなく特定のユーザーについての確定的な情報を持つことを示す。 21.6.1 600 Busy Everywhere (どの場所もビジー) 着呼側のエンドシステムにうまくコンタクトしたが、着呼側はビジーで今は 呼を受けることを望んでいない。この応答は、Retry-Afterヘッダーフィール ドで電話をかけるのに都合のいい時間を示してもよい[MAY]。着呼側が呼 を断る理由を明かすことを望まない場合、着呼側は代わりにステータスコー ド603(Decline)を使用する。このステータス応答は、他のどのエンドポイン ト(例えばボイスメールシステム)もそのリクエストに答えないことをクラ イアントが知っている場合にのみ返される。そうでなければ、486(Busy Here) が返されるべきである。 21.6.2 603 Decline (辞退) 着呼側のマシンにうまくコンタクトしたが、ユーザーが明らかに参加するこ とを望まないか参加できない。この応答はRetry-Afterヘッダーフィールドで 電話をかけるのに都合のいい時間を示してもよい[MAY]。このステータス 応答は、他のどのエンドポイントもそのリクエストに答えないことをクライ アントが知っている場合にのみ返される。 21.6.3 604 Does Not Exist Anywhere (どこにも存在しない) Request-URIで示されたユーザーがどこにも存在しないという信頼できる情報 をサーバーが持っている。 21.6.4 606 Not Acceptable (受け入れ不能) ユーザーのエージェントにうまくコンタクトしたが、例えばリクエストし たメディア、帯域、またはアドレッシングスタイルのようなセッション記述 の、何らかのアスペクトが受け入れ不可能だった。 606(Not Acceptable)応答は、ユーザーはコミュニケーションを望んでいるが 記述されたセッションを十分にサポートできないことを意味する。606(Not Acceptable)応答は、記述されたセッションをなぜサポートできないのかを述 べる理由のリストをWarningヘッダーフィールドに含めてもよい[MAY]。 Warningの理由コードはセクション20.43にリストされている。 Rosenberg, et. al. Standards Track [Page 192] RFC 3261 SIP: Session Initiation Protocol June 2002 OPTIONSリクエストに対する200(OK)応答のメッセージボディと同じように、 INVITEのAcceptヘッダーフィールド(または存在しなければapplication/sdp) に従ってフォーマットされた、メディア能力の記述を含むメッセージボディが 応答中に存在してもよい[MAY]。 ネゴシエーションが頻繁に必要とされることがないことが望まれるので、新 規ユーザーが既存のカンファレンスへの参加を招待されるときにはネゴシエー ションが可能ではないかもしれない。606(Not Acceptable)応答に対処する かどうか決定するのは招待を開始した者次第である。 このステータス応答は、他のどのエンドポイントもそのリクエストに答えな いことをクライアントが知っている場合にのみ返される。 22 HTTP認証の使用法 SIPはHTTPの認証に基づく認証のためのステートレスなチャレンジベースの 仕組みを提供する。プロキシサーバーまたはUAがリクエスト(セクション22. 1で与えられることを例外とする)を受け取るといつでも、それはリクエスト の開始者に開始者のアイデンティティの保証を提供することをチャレンジして もよい[MAY]。開始者が特定されるとすぐにリクエストの受信者は、このユー ザーが当該のリクエストをすることを認可されているかどうか確認するべきで ある[SHOULD]。このドキュメントではどの認可システムも推奨もしくは議論し ない。 このセクションで述べられる「ダイジェスト」認証の仕組みは、メッセー ジの完全性や機密性がない、メッセージ認証とリプレイ防御のみを提供する。 活動的な攻撃者がSIPリクエストおよび応答を修正することを防ぐために、ダ イジェスト認証で提供される上記の防御手段およびそれ以上の防御手段がと られる必要がある。 「基本」認証はその貧弱なセキュリティのために、使用が反対されていると いうことに注意すること。サーバーは「基本」認可スキームを使用する信用 証明書を受け入れてはならない[MUST NOT]。また、サーバーは「基本」でチャ レンジしてもいけない[MUST NOT]。これはRFC2543からの変更である。 22.1 フレームワーク SIP認証のフレームワークはHTTPのもの(RFC2617 参考文献[17])と非常に似通 っている。特に、auth-scheme、auth-param、challenge、realm、realm-value、 およびcredentialsのBNFは同一である(スキームとして「Basic」を使用する ことは許可されていないが)。SIPでは、UASはUACのアイデンティティをチャ レンジするために401(Unauthorized)応答を使用する。それに加えて、登録サー バーとリダイレクトサーバーは認証のために401(Unauthorized)応答を使用し てもよい[MAY]が、プロキシは使用してはならず[MUST NOT]、その代わりに407 Rosenberg, et. al. Standards Track [Page 193] RFC 3261 SIP: Session Initiation Protocol June 2002 (Proxy Authentication Required)応答を使用してもよい[MAY]。様々なメッセー ジにProxy-Authenticate、Proxy-Authorization、WWW-Authenticate、および Authorizationを含める要求は、RFC2617(参考文献[17])に述べられているも のと同じである。 SIPは正規ルートURL(canonical root URL)の概念を持たないので、防御空間 (protection space)の考えはSIPでは異なって解釈される。realm文字列だけ で防御ドメイン(protection domain)を定義する。これはRequest-URIとrealm が共に防御ドメインを定義していたRFC2543からの変更である。 防御ドメインの以前のこの定義は、UACが送ったRequest-URIとチャレン ジしているサーバーが受け取ったRequest-URIが異なるかも知れず、実 際に、UACは最終的なRequest-URIの形を知らないかもしれないので、若 干の混乱を生じた。また、以前の定義はRequest-URI中のSIP URIの存在 に依存しており、代替のURIスキーム(例えば、tel URL)を考慮に入れ ていないように思えた。 受け取ったリクエストを認証するユーザーエージェントやプロキシサーバー のオペレータは、オペレータのサーバーのためのrealm文字列の生成のための 以下のガイドラインを遵守しなければならない[MUST]。 o realm文字列はグローバルに一意でなければならない[MUST]。realm文 字列がRFC2617(参考文献[17])のセクション3.2.1の推奨に従って ホスト名もしくはドメイン名を含むことが推奨される[RECOMMENDED]。 o realm文字列はユーザーに対して表示することができる、人間が読む ことのできる識別子を提示するべきである[SHOULD]。 例: INVITE sip:bob@biloxi.com SIP/2.0 Authorization: Digest realm="biloxi.com", <...> 一般的に、SIP認証は特定のrealm(防御ドメイン)に対して意味を持つ。した がって、ダイジェスト認証では、そのような各防御ドメインはそれ自身のユー ザー名とパスワードのセットを持つ。サーバーが特定のリクエストに対し て認証を要求しない場合、それはパスワードを持たない(""というパスワード) デフォルトのユーザー名である「anonymous」を受け入れてもよい[MAY]。 同様に、多くのユーザーを代表するPSTNゲートウェイのようなUACは、個々の ユーザーのアカウントではなく、自身のrealmのためにそれ自身のデバイス固 有のユーザー名とパスワードを持ってもよい[MAY]。 サーバーはほとんどのSIPリクエストに合理的にチャレンジできるが、認証に 対して特別な操作を必要とする、このドキュメントで定義された2つのリクエ ストがある。それはACKとCANCELである。 Rosenberg, et. al. Standards Track [Page 194] RFC 3261 SIP: Session Initiation Protocol June 2002 (ダイジェスト認証のように)nonceを計算するために使用される値を伝えるた めに応答を用いる認証スキームの下では、ACKを含め、応答を必要としないす べての応答では問題が発生する。この理由により、サーバーに受け入れられ たINVITE中のいかなる信用証明書も、ACKのためにそのサーバーで受け入れら れなければならない[MUST]。ACKメッセージを生成するUACは、ACKが対応する INVITE中に現れたすべてのAuthorizationとProxy-Authorizationヘッダーフィー ルド値を複写する。サーバーはACKに対してチャレンジを行ってはならな い[MUST NOT]。 CANCELメソッドは応答(2xx)を必要とするが、CANCELリクエストは再提出され ることができないので、サーバーはCANCELリクエストに対してチャレンジを 試みてはならない[MUST NOT]。一般的に、CANCELリクエストは、キャンセル されることになるリクエストを送ったのと同じホップから来る場合、サーバー に受け入れられるべきである[SHOULD](ある種のトランスポートレイヤーまたは ネットワークレイヤーのセキュリティアソシエーション(セクション26.2. 1で述べられているように)が備えられているという条件で)。 UACがチャレンジを受け取るとき、UACデバイスが当該のrealmのための信用証 明書をまだ知らない場合は、UACは(WWW-Authenticateヘッダーフィールドま たはProxy-Authenticateヘッダーフィールドのいずれかに現れる)チャレンジ のrealmパラメータのコンテンツをユーザーに表示するべきである[SHOULD]。 UAにそれのrealmのための信用証明書をあらかじめ設定するサービスプロバイ ダーは、あらかじめ設定されたデバイスでチャレンジされるときに、ユーザー がこのrealmのためにユーザー自身の信用証明書を提示する機会を持てない ということに注意するべきである。 最後に、UACが適切なrealmに関連付けられた信用証明書の場所を見つけるこ とができたとしても、この信用証明書はもはや有効でないかもしれない、あ るいはチャレンジしているサーバーが何らかの理由で(特にパスワードなしの 「anonymous」が提出されたとき)この信用証明書を受け入れない可能性が存 在することに注意すること。この場合には、サーバーはチャレンジを繰り返 すか、または403(Forbidden)で応答することができる。UACは拒否されたばか りの信用証明書を持つリクエストを再度試みてはならない[MUST NOT](しかし、 nonceが古くなっていた場合は、リクエストを再試行できる)。 22.2 ユーザー・ユーザー間認証 UASがUACからリクエストを受け取るとき、UASはリクエストが処理される前に 発信元を認証してもよい[MAY]。信用証明書がリクエスト中に(Authorization ヘッダーフィールドに)提供されていない場合、UASはそのリクエストを401 (Unauthorized)ステータスコードで拒否することで、信用証明書を提供する ように発信元にチャレンジできる。 応答のWWW-Authenticateヘッダーフィールドが401(Unauthorized)応答メッセー ジに含まれなければならない[MUST]。フィールド値は認証スキームを示す 少なくとも一つのチャレンジとそのrealmに適用可能なパラメータからなる。 Rosenberg, et. al. Standards Track [Page 195] RFC 3261 SIP: Session Initiation Protocol June 2002 以下は401チャレンジのWWW-Authenticateヘッダーフィールドの例である。 WWW-Authenticate: Digest realm="biloxi.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" 発信元のUACが401(Unauthorized)を受け取るとき、それは可能であれば、適 切な信用証明書を持つリクエストを再度発信するべきである[SHOULD]。UACは 処理を進める前に発信元のユーザーからの入力を必要とするかもしれない。 認証の信用証明書が(ユーザーによって直接、あるいは内部の鍵束(keyring) から探し出して)供給されるとすぐに、UAはその信用証明書を、与えられたTo ヘッダーフィールド値とrealmのためにキャッシュして、これらの値をそのデ スティネーションへの次のリクエストに再利用することを試みるべきである [SHOULD]。UAはそれが望むどのような方法ででも信用証明書をキャッシュして もよい[MAY]。 realmに対する信用証明書の位置を特定できない場合、UACはユーザー名 「anonymous」、パスワードなし(""というパスワード)でリクエストを再試行 してもよい[MAY]。 信用証明書の位置が一度特定されると、UAがUASまたは登録サーバーで自身を 認証したい場合は、(必ずしもそうではないが、通常は401 (Unauthorized)応 答の受信後に)リクエストへAuthorizationヘッダーフィールドを含めることで それを実行してもよい[MAY]。Authorizationフィールド値は、リクエストされ るリソースのrealmのためのUAの認証情報を含む信用証明書、および認証とリプ レイ防御のサポートに必要とされるパラメータからなる。 以下はAuthorizationヘッダーフィールドの例である。 Authorization: Digest username="bob", realm="biloxi.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="sip:bob@biloxi.com", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41" UACが401(Unauthorized)応答または407(Proxy Authentication Required)応 答の受信後に信用証明書を持つリクエストを再提出するとき、UACはアップデー トしたリクエストを送るときに通常行うように、CSeqヘッダーフィールド 値をインクリメントしなければならない[MUST]。 Rosenberg, et. al. Standards Track [Page 196] RFC 3261 SIP: Session Initiation Protocol June 2002 22.3 プロキシ・ユーザー間認証 同様に、UACがプロキシサーバーにリクエストを送るとき、プロキシサーバー はリクエストが処理される前に発信元を認証してもよい[MAY]。信用証明書が リクエスト中に(Proxy-Authorizationヘッダーフィールドに)提供されていな い場合、プロキシはそのリクエストを407(Proxy Authentication Required)ス テータスコードで拒否することで、信用証明書を提供するように発信元にチャ レンジできる。プロキシは、リクエストされたリーソースのためにそのプロ キシに適用可能なProxy-Authenticate値を持つ407(Proxy Authentication Required)メッセージを埋め込まなければならない[MUST]。 参考文献[17]で述べられているProxy-AuthenticateおよびProxy- Authorizationを並列的に使用する方法には一つの相違点がある。プロキシ はProxy-Authorizationヘッダーフィールドに値を追加してはならない[MUST NOT]。 すべての407(Proxy Authentication Required)応答は、他のすべての応答のた めの手順と同じ手順に従って、UACに向けてアップストリームに転送 (forward)されなければならない[MUST]。認証を依頼したプロキシのrealmのた めの信用証明書を含むProxy-Authorizationヘッダーフィールド値を追加するこ とはUACの義務である。 プロキシがProxy-Authorizationヘッダーフィールド値を追加してリク エストを再提出した場合、プロキシは新しいリクエストのCSeqをインク リメントする必要がある。しかしながらこれは、CSeq値が異なるために、 オリジナルリクエストを提出したUACにUASからの応答を破棄させる原因 になる。 発信元のUACが407(Proxy Authentication Required)を受け取るとき、それは 可能であれば、適切な信用証明書を持つリクエストを再発信するべきである [SHOULD]。それは、401に対して応答するために上で与えられたrealmパラメー タの表示手順と同じ手順に従うべきである。 realmに対する信用証明書の位置を特定できない場合、UACはユーザー名 「anonymous」、パスワードなし(""というパスワード)でリクエストの再試行 を試みてもよい[MAY]。 UACはまた、再発信したリクエストで使用した信用証明書をキャッシュするべ きである[SHOULD]。 プロキシの信用証明書キャッシュのために、以下のルールが推奨される [RECOMMENDED]。 UAが特定のCall-IDを持つリクエストに対する401/407応答でProxy-Authenticate ヘッダーフィールド値を受け取る場合、UAはそれと同じCall-IDを含む今後の すべてのリクエストにそのrealmのための信用証明書を組み込むべきである。 これらの信用証明書は複数のダイアログに渡ってキャッシュされてはならない [MUST NOT]。しかしながら、アウトバウンドプロキシが存在するときに、UA がローカルアウトバウンドプロキシのrealmを設定されている場合、UAは複数 Rosenberg, et. al. Standards Track [Page 197] RFC 3261 SIP: Session Initiation Protocol June 2002 のダイアログに渡ってそのrealmのための信用証明書をキャッシュしてもよ い[MAY]。これは、ダイアログ内の将来のリクエストが、Routeヘッダーのパス のどのプロキシでも必要とされない信用証明書を含むことがあり得ることを意 味するということに注意すること。 UAがプロキシサーバーで自身を認証したい場合は、(必ずしもそうではないが、 通常は407(Proxy Authentication Required)応答の受信後に)リクエストへ Proxy-Authorizationヘッダーフィールド値を含めることでそれを実行しても よい[MAY]。リクエストのProxy-Authorizationヘッダーフィールド値は、認証 を求めるプロキシに対してクライアント自身(あるいはそれのユーザー)を特定 することを可能にする。Proxy-Authorizationヘッダーフィールド値は、その プロキシに対するUAの認証情報および(または)リクエストされるリソース のrealmからなる。 Proxy-Authorizationヘッダーフィールド値は、realmがrealmパラメータで特 定されるプロキシに対してのみ適用される(このプロキシは以前にProxy-Auth enticateフィールドを使用して認証を要求していたのかもしれない)。複数の プロキシが連鎖的に使用されるとき、realmがProxy-Authorizationヘッダー フィールド値で指定されたrealmパラメータにマッチしないいかなるプロキシ もその値を破壊してはならない[MUST NOT]。 realmをサポートしない認証スキームがProxy-Authorizationヘッダーフィー ルドで使用される場合、プロキシサーバーはProxy-Authorizationヘッダー フィールドの中のどれかの値がそのプロキシサーバーが有効な信用証明書であ るとみなす値を持つかどうかを確定するために、Proxy-Authorizationヘッダー フィールドのすべての値のパースを試みなければならない[MUST]。これは 大きいネットワークでは非常に時間を消費する可能性があるので、プロキシ サーバーはProxy-Authorizationヘッダーフィールドでrealmをサポートする 認証スキームを使用するべきである[SHOULD]。 リクエストが(セクション16.7で述べられているように)フォークされる場合、 さまざまなプロキシサーバーおよび(または)UAがUACにチャレンジすることを 望むかもしれない。この場合、フォークを行うプロキシサーバーはこれらの チャレンジを一つの応答にまとめる責任を負う。フォークされたリクエスト に対する応答で受け取ったWWW-AuthenticateおよびProxy-Authenticateのそ れぞれの値は、フォークを行ったプロキシによってUAに送られる一つの応答 の中に置かれなければならない[MUST]。これらのヘッダーフィールド値の並 び順は重要ではない。 プロキシサーバーがリクエストに答えてチャレンジを発行するとき、そ れはUACが有効な信用証明書を持つリクエストで再試行するまで、リク エストをプロキシしない。フォークを行うプロキシは、認証を求める複 数のプロキシサーバーに同時にリクエストを転送(forward)するかもしれな い。リクエストを転送(forward)されたそれぞれのプロキシは同様に、発信 元のUACが各プロキシのrealmで認証されるまでそのリクエストを転送 (forward)しない。UACが各チャレンジに対して信用証明書を提供しない Rosenberg, et. al. Standards Track [Page 198] RFC 3261 SIP: Session Initiation Protocol June 2002 場合、チャレンジを発行したプロキシサーバーはデスティネーション ユーザーの位置が特定されるかもしれないUAにリクエストを転送 (forward)しない。したがって、フォークの長所の大部分は失われる。 複数のチャレンジを含む401(Unauthorized)または407(Proxy Authentication Required)に答えてリクエストを再提出するとき、UACは、UACが信用証明書を 供給することを望む各WWW-Authenticate値に対するAuthorization値と各Proxy- Authenticate値に対するProxy-Authorization値を含めてもよい[MAY]。上述の ようにリクエスト中の複数の信用証明書は、realmパラメータで区別されるべ きである[SHOULD]。 同じrealmに関連付けられた複数のチャレンジが一つの401(Unauthorized)また は407(Proxy Authentication Required)に現れることが可能である。これは例 えば、同じ管理ドメイン内の複数のプロキシ(共通のrealmを使用する)に、 フォークされたリクエストが到達するときに起こりうる。したがって、リクエ ストを再試行するとき、UACは、同じrealmパラメータ値を持つ複数の信用証明 書をAuthorizationヘッダーフィールドまたはProxy-Authorizationヘッダー フィールドに供給してもよい[MAY]。同じrealmに対しては同じ信用証明書が使 用されるべきである[SHOULD]。 22.4 ダイジェスト認証スキーム このセクションでは、HTTPダイジェスト認証スキームをSIPに適用するために 必要とされる修正点と明確化について述べる。SIPスキームの使用法はほぼ完 全にHTTP(参考文献[17])のものと同じである。 RFC2543はRFC2069(参考文献[39])で定義されているHTTPダイジェストに基づ いているので、RFC2617をサポートするSIPサーバーはRFC2069と下位互換があ ることを保証しなければならない[MUST]。この下位互換のための手順はRFC2617 で規定されている。しかしながら、SIPサーバーは基本認証を受け入れたり要 求したりしてはならない[MUST NOT]ことに注意すること。 ダイジェスト認証のルールは、以下に述べる相違点と「HTTP/1.1」を「SIP/2.0」 に置き換えることを除けば、参考文献[17]で定義されているものに従う。 1. チャレンジに含まれるURIは以下のBNFを持つ。 URI = SIP-URI / SIPS-URI 2. RFC2617のBNFは、HTTPダイジェスト認証のためのAuthorization ヘッダーフィールドのuriパラメータが引用符に囲まれていないとい う誤りを持つ。(RFC2617のセクション3.5の例は正しい。)SIPでは、 uriは引用符に囲まれていなければならない[MUST]。 Rosenberg, et. al. Standards Track [Page 199] RFC 3261 SIP: Session Initiation Protocol June 2002 3. digest-uri-valueのBNFは以下である。 digest-uri-value = Request-URI ; セクション25で定義されて いるものと同じ 4. Etagに基づいてnonceを選択する手順の例はSIPではうまくいかな い。 5. キャッシュ操作に関するRFC2617(参考文献[17])の文章はSIPに適 用しない。 6. RFC2617(参考文献[17])は、サーバーが、リクエスト行(request line)のURIとAuthorizationヘッダーフィールドに含まれるURIが 同じリソースをさしているかチェックすることを要求する。SIPの コンテキストでは、いくつかのプロキシでの転送(forward)のために、 これら2つのURIは異なるユーザーを参照するかもしれない。その ためSIPでは、サーバーは、Authorizationヘッダーフィールド値 のRequest-URIがユーザー(そのユーザーに対する転送(forward)され た、または直接の呼を、サーバーは受け入れる)に対応することを チェックしてもよい[MAY]が、それら2つのフィールドが等 価でないことは必ずしも失敗ではない。 7. ダイジェスト認証スキームにおけるメッセージ完全性を保証する ためのA2の計算を明確にするためとして、実装者は、entity-body が空のときは(すなわち、SIPメッセージがボディを持たないとき)、 entity-bodyのハッシュが解決されると空文字列のMD5ハッシュに なると仮定するべきである。すなわち以下のようになる。 H(entity-body) = MD5("") = "d41d8cd98f00b204e9800998ecf8427e" 8. RFC2617では、qopコマンドが送られていなければ、cnonce値が Authorizationヘッダーフィールドで(およびその延長としてProxy- Authorizationによって)送られてはならない[MUST NOT]というこ とに特に言及している。したがって、cnonceに依存するどのよう なアルゴリズムも(「MD5-Sess」を含む)qopコマンドが送られるこ とを要求する。「qop」パラメータの使用は、RFC2069との下位互 換のためにRFC2617ではオプションである。RFC2543はRFC2069が基 になったので、クライアントやサーバーが受け取ることに対して 「qop」パラメータは残念ながらオプションのままとしなければな らない。しかしながら、サーバーはWWW-Authenticateヘッダー フィールド値とProxy-Authenticateヘッダーフィールド値で常に 「qop」パラメータを送らなければならない[MUST]。クライアント がチャレンジのヘッダーフィールドで「qop」パラメータを受け取 る場合は、その結果として生じるすべてのauthorizationヘッダー フィールドでその「qop」パラメータを送らなければならない[MUST]。 Rosenberg, et. al. Standards Track [Page 200] RFC 3261 SIP: Session Initiation Protocol June 2002 RFC2543はAuthentication-Infoヘッダーフィールドの使用を許可しなかった( それはRFC2069を効果的に使用した)。しかしながら、これはボディ上の完全 性チェックと相互認証を提供するので、これからはこのヘッダーフィールド の使用を許可する。RFC2617(参考文献[17])は、リクエストでqop属性を使用 した下位互換のための仕組みを定義する。これらの仕組みは、クラ イアントがRFC2069で規定されていなかったRFC2617の新しい仕組みをサ ポートするかどうか確定するためにサーバーによって使用されなければなら ない[MUST]。 23 S/MIME SIPメッセージはMIMEボディを伝える。そしてMIMEスタンダードは完全性と機 密性の双方を確保するためにMIMEコンテンツを保護するための仕組みを 包含する(「multipart/signed」と「application/pkcs7-mime」というMIMEタ イプを含む。RFC1847(参考文献[22])、RFC2630(参考文献[23])、およびRFC2633 (参考文献[24])参照)。しかしながら、実装者は、SIPメッセージのボディ(特 にSDP)を見たり修正したりすることに頼るネットワーク中継媒体(通常のプロ キシサーバーではない)がまれに存在し、セキュアMIMEはこの種の中継媒体が 機能することを妨げるかもしれない、ということに注意する必要がある。 これは特に、特定のタイプのファイアウォールに当てはまる。 RFC2543で述べられている、SIPメッセージのヘッダーフィールドおよび ボディを暗号化するためのPGPの仕組みは、反対されている。 23.1 S/MIMEの証明書 S/MIMEの目的のためにエンドユーザーを特定するために使用される証明書は、 サーバーによって使用されるものと一つの重要な点が異なる。所有者のアイ デンティティが特定のホスト名に対応することを表明するのではなく、これ らの証明書は所有者がエンドユーザーのアドレスで特定されることを表明す る。このアドレスはSIP URIまたはSIPS URIの「userinfo」、「@」、および 「domainname」部分を結合して構成される(言い換えると、bob@biloxy.com形 式のEメールアドレス)。これは通常、ユーザーのAddress-of-Recordに対応す る。 これらの証明書は、SIPメッセージのボディに署名したり暗号化したりするた めに使用される鍵にも関連付けられる。ボディは送信者(送信者は必要に応じ てメッセージとともに公開鍵を含めるかもしれない)の秘密鍵で署名されるが、 ボディは目的とする受信者の公開鍵で暗号化される。明らかに、送信者はメッ セージボディを暗号化するために受信者の公開鍵をあらかじめ知っていな ければならない。公開鍵はUAのバーチャルな鍵束に保存できる。 Rosenberg, et. al. Standards Track [Page 201] RFC 3261 SIP: Session Initiation Protocol June 2002 S/MIMEをサポートする各ユーザーエージェントは、エンドユーザーの証明書 に限定した鍵束を持たなければならない[MUST]。この鍵束は、Address-of- Recordとそれに対応する証明書のあいだでマッピングを行うべきである。長 い時間の間に、ユーザーは、シグナリングの発信元のURI(Fromヘッダーフィー ルド)に同じAddress-of-Recordを埋め込むときは同じ証明書を使用するべきで ある[SHOULD]。 エンドユーザーの証明書の存在に依存するいかなる仕組みも、エンド ユーザーアプリケーションに証明書を提供する一元化された機関が今日ほとん ど存在しないので、非常に制限される。しかしながら、ユーザーは既知の公 共の認証機関から証明書を取得するべきである[SHOULD]。代替として、ユー ザーは自己署名証明書を生成してもよい[MAY]。自己署名証明書の意味すると ころは、セクション26.4.2でさらに検討される。実装は、設置時にあらかじめ 設定された証明書も使用できる。その中には、すべてのSIPエンティティ間に存 在する以前の信頼関係が存在する。 エンドユーザーの証明書を取得する問題に加えて、エンドユーザーの証明書 を配布するよく知られた集中化されたディレクトリはほとんどない。しかし ながら、証明書の所有者は必要に応じて公共のディレクトリに証明書を公開 するべきである[SHOULD]。同様に、UACは、公共のディレクトリで発見された SIPリクエストのターゲットURIに対応する証明書を(手動または自動で)イン ポートするための仕組みをサポートするべきである[SHOULD]。 23.2 S/MIMEの鍵交換 SIPそれ自身は、以下の方法で公開鍵を配布する手段としても利用できる。 SIPのためにS/MIMEでCMS SignedDataメッセージが使用されるときはいつでも、 それは署名を検証するために必要な公開鍵を持つ証明書を含まなければなら ない[MUST]。 UACがダイアログを開始するS/MIMEボディを含むリクエストを送るとき、ある いはダイアログのコンテキスト外で非INVITEリクエストを送るときは、ボディを S/MIME 'multipart/signed' CMS SignedDataのボディとして構築するべきであ る[SHOULD]。希望するCMSサービスがEnvelopedData (そしてターゲットユー ザーの公開鍵が既知)の場合、UACはSignedDataメッセージの中にカプセル化 されたEnvelopedDataメッセージを送るべきである[SHOULD]。 UASが証明書を含むS/MIME CMSボディを持つリクエストを受け取るとき、UAS は最初に、可能であれば認証局のための利用可能なすべてのルート証明書と ともに、証明書を検証するべきである[SHOULD]。UASはまた、証明書のサブジェ クトを確定(S/MIMEでは、SubjectAltNameが適切なアイデンティティを含む) Rosenberg, et. al. Standards Track [Page 202] RFC 3261 SIP: Session Initiation Protocol June 2002 して、この値をリクエストのFromヘッダーフィールドと比較するべきである [SHOULD]。証明書が自己署名されているか未知の機関によって署名されてい るためにそれを検証できない場合、あるいは検証可能だがそれのサブジェク トがリクエストのFromヘッダーフィールドに一致しない場合、UASはそれのユー ザーに証明書のステータス(証明書のサブジェクト、それの署名者、および すべての鍵指紋情報を含む)を通知して、処理を進める前に明示的な許可を求 めなければならない[MUST]。証明書がうまく検証できて証明書のサブジェク トがSIPリクエストのFromヘッダーフィールドに一致する場合、あるいはユー ザーが(通知の後に)明示的にその証明書の使用を認める場合、UASはこの証 明書を、その証明書の所持者のAddress-of-Recordでインデックス付けして、 ローカルの鍵束に追加するべきである[SHOULD]。 UASが、ダイアログ中の最初のリクエストに答えるS/MIMEボディを含む応答、 あるいはダイアログのコンテキスト外の非INVITEリクエストに対する応答を 送るとき、UASはS/MIME 'multipart/signed' CMS SignedDataボディとしてそ のボディを構築するべきである[SHOULD]。希望するCMSサービスがEnvelopedData の場合、UASはSignedDataメッセージの中にカプセル化されたEnvelopedData メッセージを送るべきである[SHOULD]。 UACが証明書を含むS/MIME CMSボディを持つ応答を受け取るとき、UACは最初 に、可能であれば利用可能なすべてのルート証明書とともに、証明書を検証 するべきである[SHOULD]。UACはまた、証明書のサブジェクトを確定して、こ の値を応答のToフィールドと比較するべきである[SHOULD]。その2つは明確に 異なるかもしれないが、これは必ずしもセキュリティの侵害を示すものでは ない。証明書が自己署名されているか未知の機関によって署名されているた めにそれを検証できない場合、UACはそれのユーザーに証明書のステータス( 証明書のサブジェクト、それの署名者、およびすべての鍵指紋情報を含む)を 通知して、処理を進める前に明示的な許可を求めなければならない[MUST]。 証明書がうまく検証できて証明書のサブジェクトが応答のToヘッダーフィー ルドに一致する場合、あるいはユー ザーが(通知の後に)明示的にその証明 書の使用を認める場合、UACはこの証明書を、その証明書の所持者のAddress- of-Recordでインデックス付けして、ローカルの鍵束に追加するべきである [SHOULD]。UACがそれ以前のどのトランザクションでもUASに対してそれ自身 の証明書を送信していなかった場合、それは次のリクエストまたは応答にCMS SignedDataボディを使用するべきである[SHOULD]。 将来のいつかの時点で、UAがそれの鍵束の中の値に一致するFromヘッダー フィールドを含むリクエストまたは応答を受け取るとき、そのUAはこれらの メッセージで提示された証明書をそれの鍵束の中の既存の証明書と比較するべ きである[SHOULD]。食い違いがある場合、UAはそれのユーザーに証明書の変 更を(望ましくは、これが潜在的なセキュリティの侵害であることを示す言葉 で)通知して、シグナリングの処理を継続する前にユーザーの許可を得なけれ Rosenberg, et. al. Standards Track [Page 203] RFC 3261 SIP: Session Initiation Protocol June 2002 ばならない[MUST]。ユーザーがこの証明書を認める場合、このAddress-of- Recordに対するそれ以前の値と共にそれが鍵束に追加されるべきである[SHOULD]。 しかしながら、この鍵交換の仕組みは、自己署名証明書または無名の機関 によって署名された証明書が使用されるときは、安全な鍵交換を保障しない ということに十分注意すること。それはよく知られた攻撃に対して無防備で ある。著者の意見として、それが提供するセキュリティは一般に何もないよ りもましという程度のものであるが、実際には、広く使用されているSSHアプ リケーションと同等である。これらの制限はセクション26.4.2でさらに詳し く検討される。 UAが受信者にとって未知の公開鍵で暗号化されたS/MIMEボディを受け取る場 合、それはそのリクエストを493(Undecipherable)応答で拒否しなければなら ない[MUST]。この応答は(可能であれば、拒否されるリクエストのToヘッダー フィールドで与えられたすべてのAddress-of-Recordに対応する)応答者にと って有効な証明書を「certs-only」という「smime-type」パラメータを持つ MIMEボディの中に含むべきである[SHOULD]。 いかなる証明書も持たずに送られた493(Undecipherable)は、応答者が、S/MIME 署名をサポートするにもかかわらず、S/MIMEで暗号化されたメッセージを利 用できないか利用するつもりがないことを示す。 オプションではないS/MIMEボディを含むリクエストを(「required」という Content-Dispositionヘッダーの「handling」パラメータとともに)受け取る ユーザーエージェントは、MIMEタイプを理解できない場合はそのリクエスト を415(Unsupported Media Type)応答で拒否しなければならない[MUST]という ことに注意すること。S/MIMEが送られるときにそのような応答を受け取るユー ザーエージェントは、それのユーザーにリモートデバイスがS/MIMEをサポート しないことを通知するべきであり[SHOULD]、引き続き必要に応じてそのリクエ ストをS/MIMEなしで再度送ってもよい[MAY]。しかしながら、この415応答 はダウングレード攻撃(downgrade attack)の構成要素となるかもしれない。 ユーザーエージェントがリクエストでS/MIMEボディを送るが、安全が確保さ れていないMIMEボディを含む応答を受け取る場合、そのUACはそれのユーザー にセッションの安全が確保されないことを通知するべきである[SHOULD]。し かしながら、S/MIMEをサポートするユーザーエージェントが安全ではないボ ディを持つリクエストを受け取る場合、それは安全が確保されたボディで応 答するべきではない[SHOULD NOT]。しかし、それが送信者からS/MIMEを期待 する場合は(例えば、送信者のFromヘッダーフィールド値が鍵束のアイデン ティティに一致するために)、そのUASはそれのユーザーにセッションの安全 が確保されないことを通知するべきである[SHOULD]。 前述のテキストで持ち上がる多くの状況は、変則的な証明書管理イベントが 起こるときにユーザーへの通知を要求する。ユーザーはこれらの状況下で何 をすべきかたずねるだろう。あくまでも、証明書の予期せぬ変更あるいはセ キュリティが期待されるときにセキュリティが確保されていないことが警告 Rosenberg, et. al. Standards Track [Page 204] RFC 3261 SIP: Session Initiation Protocol June 2002 の理由であって、必ずしも攻撃が起こっていることを示さない。ユーザーは すべてのコネクションの試みを中止するかもしれない、あるいは受け取った コネクションリクエストを拒否するかもしれない。テレフォニーの用語では、 彼らは電話を切り、そしてかけなおす。ユーザーは相手にコンタクトする代 替手段を見つけて相手の鍵が合法的に変更されていることを確認することを 望むかもしれない。ユーザーは、例えば、秘密鍵の機密性が危うくなった と疑うときなど、ときには証明書の変更をせざるを得ないということに注意 すること。ユーザーの秘密鍵がもはや秘密でなくなったとき、ユーザーは新 しい鍵を合法的に生成して、そのユーザーの古い鍵を保持するいかなるユー ザーとも信頼関係を再度確立しなければならない。 最後に、ダイアログの過程で、UAがダイアログ中で以前に交換した証明書と 一致しない証明書をCMS SignedDataメッセージ中で受け取る場合、UAはそれ のユーザーに、望ましくはこれが潜在的なセキュリティの侵害であることを 示す言葉で、変更を通知しなければならない[MUST]。 23.3 MIMEボディの安全確保 SIPに関係する2つのタイプのSecure MIMEボディがある。これらのボディの使 用は、わずかな変更とともにS/MIME仕様(参考文献[24])に従うべきであ る。 o 「multipart/signed」はCMS分離署名とともに使用されなければなら ない[MUST]。 これは非S/MIME準拠の受信者との下位互換を可能にする。 o S/MIMEボディはContent-Dispositionヘッダーフィールドを持つべき であり[SHOULD]、「handling」パラメータの値は「required」である べきである[SHOULD]。 o UACがそれの鍵束に、リクエストを送りたいと思う相手のAddress-of- Recordと関連付けられた証明書を持たない場合、UACは暗号化された 「application/pkcs7-mime」MIMEメッセージを送ることができない。 UACは、リモート側の証明書を請願するために、CMS分離署名を持つ OPTIONSメッセージのような最初のリクエストを送ってもよい[MAY] (署名はセクション23.4で述べられているタイプの「message/sip」ボ ディ上にあるべきである[SHOULD])。 S/MIMEの将来の標準化作業が証明書によらない鍵を定義するかも しれないことに注意すること。 o S/MIMEボディの送信者は、更なるコミュニケーションのために能力と プリファレンスを表現するために「SMIMECapabilities」(参考文献[24] のセクション2.5.2参照)属性を使用するべきである[SHOULD]。送信者 は受信者がCMS SignedDataメッセージで応答することを促すために 「preferSignedData」能力を使ってもよい[MAY](例えば、上記のよう Rosenberg, et. al. Standards Track [Page 205] RFC 3261 SIP: Session Initiation Protocol June 2002 にOPTIONSリクエストを送るとき)ということに特に注意すること。 o S/MIMEの実装は、デジタル署名アルゴリズムとしてSHA1を、暗号化アル ゴリズムとして3DESを最低限サポートしなければならない[MUST]。他の すべての署名と暗号化のアルゴリズムもサポートしてもよい[MAY]。実 装は「SMIMECapabilities」属性で、これらのアルゴリズムに対するサ ポートをネゴシエートできる。 o SIPメッセージの各S/MIMEボディはただ一つの証明書で署名されるべ きである[SHOULD]。UAが複数の署名を持つメッセージを受け取る場合、 最外部の署名がこのボディのための一つの証明書であるとして扱われ るべきである。パラレル署名(parallel signature)は使用されるべき ではない[SHOULD NOT]。 以下はSIPメッセージ中の暗号化されたS/MIME SDPボディの例である。 INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Contact: Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Disposition: attachment; filename=smime.p7m handling=required ******************************************************* * Content-Type: application/sdp * * * * v=0 * * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com * * s=- * * t=0 0 * * c=IN IP4 pc33.atlanta.com * * m=audio 3456 RTP/AVP 0 1 3 99 * * a=rtpmap:0 PCMU/8000 * ******************************************************* Rosenberg, et. al. Standards Track [Page 206] RFC 3261 SIP: Session Initiation Protocol June 2002 23.4 S/MIMEを使用したSIPヘッダーのプライバシーと完全性: SIPトンネリング エンドツーエンド認証、SIPヘッダーフィールドの完全性または機密性をある 程度提供する手段として、S/MIMEは「message/sip」タイプのMIMEボディ内に SIPメッセージ全体をカプセル化して、通常のSIPボディと同じ方法でこれら のボディに対してMIMEセキュリティを適用することができる。これらのカプ セル化されたSIPリクエストおよび応答は独自のダイアログやトランザクショ ンを構成しない。それらは、完全性を検証するため、あるいは付加情報を供 給するために使用される「外部」メッセージのコピーである。 UASがトンネルした「message/sip」S/MIMEボディを含むリクエストを受け取 る場合、それはトンネルした「message/sip」ボディを同じsmime-typeで応答 に含めるべきである[SHOULD]。 従来のすべてのMIMEボディ(例えばSDP)は、それらもS/MIMEのセキュリティ の恩恵を受けられるように「内部」メッセージにアタッチされるべきである [SHOULD]。「message/sip」ボディは、リクエストで安全ではない何らかの MIMEタイプも送信されるべき場合には、「multipart/mixed」MIMEボディの 一部として送ることができる、ということに注意すること。 23.4.1 SIPヘッダーの完全性と機密性の特性 S/MIMEの完全性または機密性の仕組みが使用されるとき、「内部」メッ セージの値と「外部」メッセージの値の間に食い違いが出てくるかもし れない。このドキュメントで記述されているすべてのヘッダーフィールドの ためにそのような違いに対処するためのルールは、このセクションで与えら れる。 ルースタイムスタンプの目的のために、「message/sip」をトンネルするすべ てのSIPメッセージは「内部」と「外部」の両方のヘッダーにDateヘッダーを 含むべきである[SHOULD]。 23.4.1.1 完全性 完全性チェックが実行されるときはいつでも、ヘッダーフィールドの完全性 は20で述べられているSIPの比較ルールを使用して、署名されたボディ中の ヘッダーフィールドの値を「外部」メッセージのそれとマッチングすることに よって決定されるべきである。 プロキシサーバーによって合法的に修正できるヘッダーフィールドは、 Request-URI、Via、Record-Route、Route、Max-Forwards、およびProxy- Authorizationである。これらのヘッダーフィールドがエンドツーエンドで元 の状態を保っていない場合、実装はこれをセキュリティの侵害とみなすべき ではない[SHOULD NOT]。このドキュメントで定義されているその他のすべて のヘッダーフィールドに対する変更は完全性侵害の構成要素になる。ユーザー は食い違いを通知されなければならない[MUST]。 Rosenberg, et. al. Standards Track [Page 207] RFC 3261 SIP: Session Initiation Protocol June 2002 23.4.1.2 機密性 メッセージが暗号化されるとき、「外部」メッセージに存在しないヘッダー フィールドが暗号化されたボディに含まれるかもしれない。 いくつかのヘッダーフィールドはリクエストおよび応答で必須であるため、 常にプレーンテキストの形態(version)を持たなければならない。これらの ヘッダーフィールドには、To、From、Call-ID、CSeq、Contactが含まれる。 Call-ID、CSeq、またはContactの暗号化された代替を提供することはおそら く有用でないとはいえ、「外部」のToまたはFromに情報として代替を提供す ることは許可されている。暗号化されたボディ中の値は、トランザクション やダイアログを特定する目的で使用されないことに注意すること。それらは 単に通知目的のためにある。暗号化されたボディ中のFromヘッダーフィール ドが「外部」メッセージの値と異なる場合、暗号化されたボディ内の値がユー ザーに対して表示されるべきである[SHOULD]が、いかなる将来のメッセー ジの「外部」ヘッダーフィールド中でも使用されてはならない[MUST NOT]。 ユーザーエージェントは主としてエンドツーエンドのセマンティクスを持つ ヘッダーフィールドの暗号化を望むだろう。それにはSubject、Reply-To、 Organization、Accept、Accept-Encoding、Accept-Language、Alert-Info、 Error-Info、Authentication-Info、Expires、In-Reply-To、Require、 Supported、Unsupported、Retry-After、User-Agent、Server、および Warningが含まれる。これらのヘッダーフィールドのどれかが暗号化されたボ ディ中に存在する場合、そのヘッダーフィールド値をユーザーに対して表示 するかあるいはUAの内部ステートを設定する必要があったとしても、「外部」 のヘッダーフィールドの代わりにそれらが使用されるべきである。しかしな がらそれらは、いかなる将来のメッセージの「外部」ヘッダーでも使用する べきではない[SHOULD NOT]。 Dateヘッダーフィールドが存在する場合、それは常に「内部」と「外部」の ヘッダーで同じでなければならない[MUST]。 MIMEボディは「内部」メッセージにアタッチされるので、実装は通常MIME固 有のヘッダーフィールドを暗号化する。それにはMIME-Version、Content-Type、 Content-Length、Content-Language、Content-Encoding、およびContent- Dispositionが含まれる。「外部」メッセージはS/MIMEボディのための適切な MIMEヘッダーフィールドを持つ。これらのヘッダーフィールドは(およびそれ らに続くいかなるMIMEボディも)SIPメッセージで受け取った普通のMIMEヘッ ダーフィールドおよびボディとして扱われるべきである。 以下のヘッダーフィールドを暗号化することは特に有用ではない。 Min-Expires、Timestamp、Authorization、Priority、およびWWW-Authenticate。 このカテゴリはプロキシサーバーによって変更されることがあるヘッダー フィールドも含む(すぐ前のセクションで述べられている)。UAは、これらが 「外部」メッセージに含まれないのであれば、これらを決して「内部」メッ Rosenberg, et. al. Standards Track [Page 208] RFC 3261 SIP: Session Initiation Protocol June 2002 セージに含めるべきでない[SHOULD][訳注: 原文では「SHOULD never」なので、 要求レベルは[SHOULD NOT]とするほうが適切]。暗号化されたボディでこれら のどれかのヘッダーフィールドを受け取るUAは、暗号化されている値を無視 するべきである[SHOULD]。 SIPの拡張は追加のヘッダーフィールドを定義するかもしれないということに 注意すること。それらの拡張の著者は、そのようなヘッダーフィールドの完 全性と機密性の特性について述べるべきである。SIP UAが完全性を侵害する 未知のヘッダーフィールドに遭遇する場合、それはそのヘッダーフィールド を無視しなければならない[MUST]。 23.4.2 トンネリングの完全性と認証 S/MIMEボディ内でSIPメッセージをトンネリングすることは、送信者が安全確 保を望むヘッダーフィールドがCMS分離署名で署名されて「message/sip」MIME ボディ中に複製(replicate)されている場合、そのSIPヘッダーフィールドに 対して完全性を提供する。 「message/sip」ボディが少なくとも基本的なダイアログ識別子(To、From、 Call-ID、CSeq)を含むなら、署名されたMIMEボディは限定された認証を提供 できる。ボディに署名するために使用された証明書が受信者に知られていな いために検証できない場合、最低限、ダイアログ中で後から来るリクエスト がそのダイアログを開始したのと同じ証明書の所有者によって送信されたこ とを確認するためにその署名が使用できる。署名されたMIMEボディの受信者 が証明書を信用するにたる何らかの強い誘因を持つ場合(それを検証すること ができた、信頼できるリポジトリからそれを取得した、あるいはそれをよく 使用する)、証明書のサブジェクトのアイデンティティをより強く断定するも のとして、署名を利用することができる。 ヘッダーフィールド全体の追加や削減に関して起こりうる混乱を取り除くた めに、送信者はリクエストからすべてのヘッダーフィールドを署名されたボ ディに複写するべきである[SHOULD]。完全性の保護を要求するいかなるメッ セージボディも、「内部」メッセージにアタッチされなければならない[MUST]。 署名されたボディを持つメッセージ中にDateヘッダーが存在する場合、受信 者は必要に応じてそのヘッダーフィールドの値を自身の内部時計と比較する べきである[SHOULD]。大幅な時間の不一致(1時間単位あるいはそれ以上)が検 出される場合、ユーザーエージェントはユーザーに異常を警告し、これが潜 在的なセキュリティの侵害であることを注意するべきである[SHOULD]。 受信者によってメッセージに完全性の侵害が検知される場合、それがリクエス トであればそのメッセージを403(Forbidden)応答で拒否してもよい[MAY]。ある いはいかなる既存のダイアログも終了してもよい[MAY]。UAはユーザーにこの 状況を通知し、どのように続行するかについての明確な指示を請うべきである [SHOULD]。 Rosenberg, et. al. Standards Track [Page 209] RFC 3261 SIP: Session Initiation Protocol June 2002 以下は、トンネルされた「message/sip」ボディの使用例である。 INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 Content-Length: 568 --boundary42 Content-Type: message/sip INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: Content-Type: application/sdp Content-Length: 147 v=0 o=UserA 2890844526 2890844526 IN IP4 here.com s=Session SDP c=IN IP4 pc33.atlanta.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 --boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required Rosenberg, et. al. Standards Track [Page 210] RFC 3261 SIP: Session Initiation Protocol June 2002 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --boundary42- 23.4.3 トンネリング暗号化 この仕組みをCMS EnvelopedDataメッセージS/MIMEボディ内の「message/ sip」MIMEボディを暗号化するために使用することも望ましいかもしれないが、 実際にはほとんどのヘッダーフィールドが少なくともいくらかはネットワー クに使用されている。S/MIMEでの暗号化の一般的な用途はメッセージヘッダー というよりもむしろSDPのようなメッセージボディの安全を確保することで ある。SubjectやOrganizationのようないくつかの通知ヘッダーフィールドは、 おそらくはエンドツーエンドの安全性を保障する。将来のSIPアプリケーショ ンで定義されるヘッダーも不明瞭さを要求するかもしれない。 ヘッダーフィールド暗号化の、他の見込みある応用例は選択的な匿名(selective anonymity)である。リクエストは、個人情報を含まないFromヘッダーフィー ルド(例えば、sip:anonymous@anonymizer.invalid)を用いて構築されるか もしれない。しかしながら、発信元の本当のAddress-of-Recordを含む別の Fromヘッダーフィールドは、ダイアログのエンドポイントに対してのみ可視 である「message/sip」MIMEボディ内に暗号化されるかもしれない。 この仕組みが匿名のために使用される場合、Fromヘッダーフィールド は、送信者に関連付けられた適切なS/MIME鍵を検索するための証明書の鍵 束へのインデックスとして、もはやメッセージの受信者が利用することは できない、ということに注意すること。メッセージはまず復号され、そし て「内部の」Fromヘッダーフィールドがインデックスとして使用されなけ ればならない[MUST]。 エンドツーエンドの完全性を提供するために、暗号化された「message/sip」 MIMEボディは送信者によって署名されるべきである[SHOULD]。これは、双方 共にタイプが「application/pkcs7-mime」である、暗号化されたボディと署 名を含む「multipart/signed」MIMEボディを生成する。 Rosenberg, et. al. Standards Track [Page 211] RFC 3261 SIP: Session Initiation Protocol June 2002 以下の暗号化されて署名されたメッセージの例では、アスタリスク(*)で囲ま れたテキストは暗号化されている。 INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 To: Bob From: Anonymous ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 Content-Length: 568 --boundary42 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m handling=required Content-Length: 231 *********************************************************** * Content-Type: message/sip * * * * INVITE sip:bob@biloxi.com SIP/2.0 * * Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 * * To: Bob * * From: Alice ;tag=1928301774 * * Call-ID: a84b4c76e66710 * * CSeq: 314159 INVITE * * Max-Forwards: 70 * * Date: Thu, 21 Feb 2002 13:02:03 GMT * * Contact: * * * * Content-Type: application/sdp * * * * v=0 * * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com * * s=Session SDP * * t=0 0 * * c=IN IP4 pc33.atlanta.com * * m=audio 3456 RTP/AVP 0 1 3 99 * * a=rtpmap:0 PCMU/8000 * *********************************************************** Rosenberg, et. al. Standards Track [Page 212] RFC 3261 SIP: Session Initiation Protocol June 2002 --boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --boundary42- 24 例 以下の例では、簡潔さのためにメッセージボディとそれに対応するContent- LengthおよびContent-Typeヘッダーフィールドを省略することが多い。 24.1 登録 開始時にBobが登録を行う。メッセージフローは図9に示されている。 登録に通常要求される認証は簡略化のために示されていないということに注 意すること。 biloxi.com Bobの 登録サーバー ソフトフォン | | | REGISTER F1 | |<---------------| | 200 OK F2 | |--------------->| 図9: SIPの登録の例 F1 REGISTER Bob -> Registrar REGISTER sip:registrar.biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 To: Bob From: Bob ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Expires: 7200 Content-Length: 0 Rosenberg, et. al. Standards Track [Page 213] RFC 3261 SIP: Session Initiation Protocol June 2002 登録は2時間後に期限が切れる。登録サーバーは200 OKで応答する。 F2 200 OK Registrar -> Bob SIP/2.0 200 OK Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.4 To: Bob ;tag=2493k59kd From: Bob ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Expires: 7200 Content-Length: 0 24.2 セッションセットアップ この例はセクション4のセッションセットアップ例の全詳細を含む。メッセー ジフローは図1に示されている。これらのフローは最低限要求されるヘッダー フィールドを示すということに注意すること。AllowやSupportedのような他 のいくつかのヘッダーフィールドが通常は存在する。 F1 INVITE Alice -> atlanta.com proxy INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 Max-Forwards: 70 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 142 (AliceのSDPは示されていない) Rosenberg, et. al. Standards Track [Page 214] RFC 3261 SIP: Session Initiation Protocol June 2002 F2 100 Trying atlanta.com proxy -> Alice SIP/2.0 100 Trying Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Content-Length: 0 F3 INVITE atlanta.com proxy -> biloxi.com proxy INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 Max-Forwards: 69 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 142 (AliceのSDPは示されていない) F4 100 Trying biloxi.com proxy -> atlanta.com proxy SIP/2.0 100 Trying Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Content-Length: 0 Rosenberg, et. al. Standards Track [Page 215] RFC 3261 SIP: Session Initiation Protocol June 2002 F5 INVITE biloxi.com proxy -> Bob INVITE sip:bob@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 Max-Forwards: 68 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 142 (AliceのSDPは示されていない) F6 180 Ringing Bob -> biloxi.com proxy SIP/2.0 180 Ringing Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 ;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob ;tag=a6c85cf From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 Contact: CSeq: 314159 INVITE Content-Length: 0 F7 180 Ringing biloxi.com proxy -> atlanta.com proxy SIP/2.0 180 Ringing Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob ;tag=a6c85cf From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 Contact: CSeq: 314159 INVITE Content-Length: 0 Rosenberg, et. al. Standards Track [Page 216] RFC 3261 SIP: Session Initiation Protocol June 2002 F8 180 Ringing atlanta.com proxy -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob ;tag=a6c85cf From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 Contact: CSeq: 314159 INVITE Content-Length: 0 F9 200 OK Bob -> biloxi.com proxy SIP/2.0 200 OK Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 ;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob ;tag=a6c85cf From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 131 (BobのSDPは示されていない) F10 200 OK biloxi.com proxy -> atlanta.com proxy SIP/2.0 200 OK Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob ;tag=a6c85cf From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 131 (BobのSDPは示されていない) Rosenberg, et. al. Standards Track [Page 217] RFC 3261 SIP: Session Initiation Protocol June 2002 F11 200 OK atlanta.com proxy -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob ;tag=a6c85cf From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 131 (BobのSDPは示されていない) F12 ACK Alice -> Bob ACK sip:bob@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9 Max-Forwards: 70 To: Bob ;tag=a6c85cf From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 ACK Content-Length: 0 AliceとBobのあいだのメディアセッションは今確立された。 Bobが最初に電話を切る。BobのSIPフォンはそれ自身のCSeq番号空間(この例 では、231で始まる)を保持することに注意すること。Bobがリクエストを行っ ているので、ToとFromのURIおよびtagが交換された。 F13 BYE Bob -> Alice BYE sip:alice@pc33.atlanta.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 Max-Forwards: 70 From: Bob ;tag=a6c85cf To: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: 0 Rosenberg, et. al. Standards Track [Page 218] RFC 3261 SIP: Session Initiation Protocol June 2002 F14 200 OK Alice -> Bob SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 From: Bob ;tag=a6c85cf To: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: 0 SIPコールフローのドキュメント(参考文献[40])がSIPメッセージの更なる例 を含んでいる。 25 SIPプロトコルのための拡張BNF このドキュメントで規定されているすべての仕組みは、文章とRFC2234( 参考文献[10])で定義されている拡張BNF形式の両方で記述されている。RFC 2234のセクション6.1で、この仕様で使用する中心的なルールセットを定義し ているので、ここでは繰り返さない。実装者は、この使用を理解するために その表記法とRFC2234の内容を熟知している必要がある。SP、LWS、HTAB、CRLF、 DIGIT、ALPHAなどの特定の基本ルールは大文字で表記される。ルール名を明 確にするために定義中でカギ括弧が使用される。 構文的には角括弧の使用は冗長である。それは、特定のパラメータの使用がオ プションであることの意味論的なヒントとして使用される。 25.1 基本ルール 以下のルールは、パースする基本構成物を記述するために、この仕様全体を 通して使用される。US-ASCIIでコード化されたキャラクタセットはANSI X3.4-1986で定義されている。 alphanum = ALPHA / DIGIT Rosenberg, et. al. Standards Track [Page 219] RFC 3261 SIP: Session Initiation Protocol June 2002 いくつかのルールがRFC2396(参考文献[5])から組み入れられるが、それらが RFC2234(参考文献[10])に準拠するように更新される。これには以下のものが 含まれる。 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" / "$" / "," unreserved = alphanum / mark mark = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")" escaped = "%" HEXDIG HEXDIG SIPヘッダーフィールド値は、継続行がスペースまたは水平タブで始まるなら複 数行に折りたためる。折りたたみを含むすべての空白文字(linear white space) は、SPと同じセマンティクスを持つ。受信者は、フィールド値を解釈する前あ るいはメッセージをダウンストリームに転送(forward)する前に、いかなる linear white spaceでも一つのSPに置き換えてもよい[MAY]。これはRFC2616 (参考文献[8])で述べられているように、HTTP/1.1と正確に同じ動作をするこ とを意図されている。SWSコンストラクトはlinear white spaceがオプション のときに、一般にトークンと分離記号の間で使用される。 LWS = [*WSP CRLF] 1*WSP ; linear whitespace SWS = [LWS] ; sep whitespace ヘッダー名を値の残りの部分から分離するために、コロンが使用される。コ ロンは上記のルールにより、その前にホワイトスペース(改行は認められない)、 後にホワイトスペース(改行も含む)が認められている。HCOLON はこの構成概 念を定義する。 HCOLON = *( SP / HTAB ) ":" SWS TEXT-UTF8ルールは、メッセージパーサーによって解釈されることを意図され ていない記述的フィールドと値でのみ使用される。*TEXT-UTF8 という語は、 UTF-8キャラクタセット(RFC2279 参考文献[7])の文字を含む。TEXT-UTF8-TRIM ルールは引用符で囲まれた文字列ではない(先行するLWSと後に続くLWSが意味 を持たない)、記述的フィールドのコンテンツに使用される。これに関しては、 SIPはISO8859-1キャラクタセットを使用するHTTPと異なる。 TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char) TEXT-UTF8char = %x21-7E / UTF8-NONASCII UTF8-NONASCII = %xC0-DF 1UTF8-CONT / %xE0-EF 2UTF8-CONT / %xF0-F7 3UTF8-CONT / %xF8-Fb 4UTF8-CONT / %xFC-FD 5UTF8-CONT UTF8-CONT = %x80-BF Rosenberg, et. al. Standards Track [Page 220] RFC 3261 SIP: Session Initiation Protocol June 2002 CRLFはヘッダーフィールド継続の一部としてのみ、TEXT-UTF8-TRIMの定義で 認められている。TEXT-UTF8-TRIMの値を解釈する前に、折りたたみLWSが一つ のSPで置き換えられることが期待されている。 プロトコルの要素の一部で、16進数文字が使用される。いくつかの要素(認証) は16進数のアルファベット文字を小文字にする必要がある。 LHEX = DIGIT / %x61-66 ;小文字のa-f 多くのSIPヘッダーフィールド値は、LWSまたは特別な文字で区切られた複数 の語から成る。特に指定されなければ、トークンは大文字小文字を区別しな い。これらの特別な文字は、パラメータ値で使用されるために、引用符で囲 まれた文字列中になければならない[MUST]。この語の構成は、ほとんどのセ パレータの使用を可能にするためにCall-IDで使われる。 token = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) separators = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" / SP / HTAB word = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" / "(" / ")" / "<" / ">" / ":" / "\" / DQUOTE / "/" / "[" / "]" / "?" / "{" / "}" ) エレメント間でトークンまたはセパレータが使用されるとき、これらの文字 の前後にホワイトスペースが認められることが多い。 STAR = SWS "*" SWS ; アスタリスク SLASH = SWS "/" SWS ; スラッシュ EQUAL = SWS "=" SWS ; 等号 LPAREN = SWS "(" SWS ; 左括弧 RPAREN = SWS ")" SWS ; 右括弧 RAQUOT = ">" SWS ; 右角括弧 LAQUOT = SWS "<"; 左角括弧 COMMA = SWS "," SWS ; カンマ SEMI = SWS ";" SWS ; セミコロン COLON = SWS ":" SWS ; コロン LDQUOT = SWS DQUOTE; 開き二重引用符 RDQUOT = DQUOTE SWS ; 閉じ二重引用符 Rosenberg, et. al. Standards Track [Page 221] RFC 3261 SIP: Session Initiation Protocol June 2002 コメント文字を括弧で括ることによって、いくつかのSIPヘッダーフィールド にコメントを含めることができる。コメントは、フィールド値定義の一部に 「comment」を含むフィールドにのみ許可されている。他のすべてのフィール ドでは、括弧はフィールド値の一部とみなされる。 comment = LPAREN *(ctext / quoted-pair / comment) RPAREN ctext = %x21-27 / %x2A-5B / %x5D-7E / UTF8-NONASCII / LWS ctextは、左括弧、右括弧、バックスラッシュを除くすべての文字を含む。文 字列は、二重引用符で囲まれている場合、一語としてパースされる。引用符 で囲まれた文字列中では、引用符(")とバックスラッシュ(\)はエスケープさ れる必要がある。 quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE qdtext = LWS / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII バックスラッシュ文字( \ )は、引用符で囲まれた文字列およびコメント構成 物の中でのみ、一文字引用の仕組みとして使用してもよい[MAY]。 HTTP/1.1とは異なり、CR文字とLF文字は行の折りたたみとヘッダー分割の衝 突を避けるためにこの仕組みでエスケープできない。 quoted-pair = "\" (%x00-09 / %x0B-0C / %x0E-7F) SIP-URI = "sip:" [ userinfo ] hostport uri-parameters [ headers ] SIPS-URI = "sips:" [ userinfo ] hostport uri-parameters [ headers ] userinfo = ( user / telephone-subscriber ) [ ":" password ] "@" user = 1*( unreserved / escaped / user-unreserved ) user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" password = *( unreserved / escaped / "&" / "=" / "+" / "$" / "," ) hostport = host [ ":" port ] host = hostname / IPv4address / IPv6reference hostname = *( domainlabel "." ) toplabel [ "." ] domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum Rosenberg, et. al. Standards Track [Page 222] RFC 3261 SIP: Session Initiation Protocol June 2002 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv6reference = "[" IPv6address "]" IPv6address = hexpart [ ":" IPv4address ] hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] hexseq = hex4 *( ":" hex4) hex4 = 1*4HEXDIG port = 1*DIGIT 電話加入者のためのBNFはRFC2806(参考文献[9])でみつけることができる。し かしながら、SIP URIのユーザー部分で許可されていないのにそこで認められ ているいかなる文字もエスケープされなければならない[MUST]ことに注意す ること。 uri-parameters = *( ";" uri-parameter) uri-parameter = transport-param / user-param / method-param / ttl-param / maddr-param / lr-param / other-param transport-param = "transport=" ( "udp" / "tcp" / "sctp" / "tls" / other-transport) other-transport = token user-param = "user=" ( "phone" / "ip" / other-user) other-user = token method-param = "method=" Method ttl-param = "ttl=" ttl maddr-param = "maddr=" host lr-param = "lr" other-param = pname [ "=" pvalue ] pname = 1*paramchar pvalue = 1*paramchar paramchar = param-unreserved / unreserved / escaped param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$" headers = "?" header *( "&" header ) header = hname "=" hvalue hname = 1*( hnv-unreserved / unreserved / escaped ) hvalue = *( hnv-unreserved / unreserved / escaped ) hnv-unreserved = "[" / "]" / "/" / "?" / ":" / "+" / "$" SIP-message = Request / Response Request = Request-Line *( message-header ) CRLF [ message-body ] Request-Line = Method SP Request-URI SP SIP-Version CRLF Request-URI = SIP-URI / SIPS-URI / absoluteURI absoluteURI = scheme ":" ( hier-part / opaque-part ) hier-part = ( net-path / abs-path ) [ "?" query ] net-path = "//" authority [ abs-path ] abs-path = "/" path-segments Rosenberg, et. al. Standards Track [Page 223] RFC 3261 SIP: Session Initiation Protocol June 2002 opaque-part = uric-no-slash *uric uric = reserved / unreserved / escaped uric-no-slash = unreserved / escaped / ";" / "?" / ":" / "@" / "&" / "=" / "+" / "$" / "," path-segments = segment *( "/" segment ) segment = *pchar *( ";" param ) param = *pchar pchar = unreserved / escaped / ":" / "@" / "&" / "=" / "+" / "$" / "," scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) authority = srvr / reg-name srvr = [ [ userinfo "@" ] hostport ] reg-name = 1*( unreserved / escaped / "$" / "," / ";" / ":" / "@" / "&" / "=" / "+" ) query = *uric SIP-Version = "SIP" "/" 1*DIGIT "." 1*DIGIT message-header = (Accept / Accept-Encoding / Accept-Language / Alert-Info / Allow / Authentication-Info / Authorization / Call-ID / Call-Info / Contact / Content-Disposition / Content-Encoding / Content-Language / Content-Length / Content-Type / CSeq / Date / Error-Info / Expires / From / In-Reply-To / Max-Forwards / MIME-Version / Min-Expires / Organization / Priority / Proxy-Authenticate / Proxy-Authorization / Proxy-Require / Record-Route / Reply-To Rosenberg, et. al. Standards Track [Page 224] RFC 3261 SIP: Session Initiation Protocol June 2002 / Require / Retry-After / Route / Server / Subject / Supported / Timestamp / To / Unsupported / User-Agent / Via / Warning / WWW-Authenticate / extension-header) CRLF INVITEm = %x49.4E.56.49.54.45 ; 大文字のINVITE ACKm = %x41.43.4B ; 大文字のACK OPTIONSm = %x4F.50.54.49.4F.4E.53 ; 大文字のOPTIONS BYEm = %x42.59.45 ; 大文字のBYE CANCELm = %x43.41.4E.43.45.4C ; 大文字のCANCEL REGISTERm = %x52.45.47.49.53.54.45.52 ; 大文字のREGISTER Method = INVITEm / ACKm / OPTIONSm / BYEm / CANCELm / REGISTERm / extension-method extension-method = token Response = Status-Line *( message-header ) CRLF [ message-body ] Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF Status-Code = Informational / Redirection / Success / Client-Error / Server-Error / Global-Failure / extension-code extension-code = 3DIGIT Reason-Phrase = *(reserved / unreserved / escaped / UTF8-NONASCII / UTF8-CONT / SP / HTAB) Informational = "100" ; Trying (試行中) / "180" ; Ringing (呼び出し中) / "181" ; Call Is Being Forwarded (呼が転送されている) / "182" ; Queued (キューに入れられた) / "183" ; Session Progress (セッションの進捗状況) Rosenberg, et. al. Standards Track [Page 225] RFC 3261 SIP: Session Initiation Protocol June 2002 Success = "200" ; OK Redirection = "300" ; Multiple Choices (複数の選択肢がある) / "301" ; Moved Permanently (恒久的に移動した) / "302" ; Moved Temporarily (一時的に移動した) / "305" ; Use Proxy (プロキシを使用せよ) / "380" ; Alternative Service (代替サービス) Client-Error = "400" ; Bad Request (不正なリクエスト) / "401" ; Unauthorized (認証されていない) / "402" ; Payment Required (料金支払いが必要) / "403" ; Forbidden (禁止) / "404" ; Not Found (見つからない) / "405" ; Method Not Allowed (メソッドが許可されていない) / "406" ; Not Acceptable (受け入れできない) / "407" ; Proxy Authentication Required (プロキシ認証が必要) / "408" ; Request Timeout (リクエストがタイムアウトした) / "410" ; Gone (リソースがもう存在しない) / "413" ; Request Entity Too Large (リクエストのエンティティが大きすぎる) / "414" ; Request-URI Too Large (Request-URIが長すぎる) / "415" ; Unsupported Media Type (サポートされていないメディアタイプ) / "416" ; Unsupported URI Scheme (サポートされていないURIスキーム) / "420" ; Bad Extension (不正な拡張) / "421" ; Extension Required (拡張が必要) / "423" ; Interval Too Brief (間隔が短すぎる) / "480" ; Temporarily not available (一時的に利用不可) / "481" ; Call Leg/Transaction Does Not Exist (コールレグまたはトランザクションが存在しない)[訳注: 21.4.19では「Leg」がない] / "482" ; Loop Detected (ループが検知された) / "483" ; Too Many Hops (ホップが多すぎる) / "484" ; Address Incomplete (アドレスが不完全) / "485" ; Ambiguous (不明瞭) / "486" ; Busy Here (ここはビジー) / "487" ; Request Terminated (リクエストが終了させられた) / "488" ; Not Acceptable Here (ここでは受け入れ不能) / "491" ; Request Pending (リクエストペンディング) / "493" ; Undecipherable (解読不能) Server-Error = "500" ; Internal Server Error (内部サーバーエラー)[訳注: 21.5.1ではServer Internal Error] / "501" ; Not Implemented (実装されていない) / "502" ; Bad Gateway (不正なゲートウェイ) / "503" ; Service Unavailable (サービスを利用できない) / "504" ; Server Time-out (サーバータイムアウト) / "505" ; SIP Version not supported (サポートされていないSIPバージョン)[訳注: 21.5.6では「SIP」がない] / "513" ; Message Too Large (メッセージが大きすぎる) Rosenberg, et. al. Standards Track [Page 226] RFC 3261 SIP: Session Initiation Protocol June 2002 Global-Failure = "600" ; Busy Everywhere (どの場所もビジー) / "603" ; Decline (辞退) / "604" ; Does not exist anywhere (どこにも存在しない) / "606" ; Not Acceptable (受け入れ不能) Accept = "Accept" HCOLON [ accept-range *(COMMA accept-range) ] accept-range = media-range *(SEMI accept-param) media-range = ( "*/*" / ( m-type SLASH "*" ) / ( m-type SLASH m-subtype ) ) *( SEMI m-parameter ) accept-param = ("q" EQUAL qvalue) / generic-param qvalue = ( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." 0*3("0") ] ) generic-param = token [ EQUAL gen-value ] gen-value = token / host / quoted-string Accept-Encoding = "Accept-Encoding" HCOLON [ encoding *(COMMA encoding) ] encoding = codings *(SEMI accept-param) codings = content-coding / "*" content-coding = token Accept-Language = "Accept-Language" HCOLON [ language *(COMMA language) ] language = language-range *(SEMI accept-param) language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" ) Alert-Info = "Alert-Info" HCOLON alert-param *(COMMA alert-param) alert-param = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) Allow = "Allow" HCOLON [Method *(COMMA Method)] Authorization = "Authorization" HCOLON credentials credentials = ("Digest" LWS digest-response) / other-response digest-response = dig-resp *(COMMA dig-resp) dig-resp = username / realm / nonce / digest-uri / dresponse / algorithm / cnonce / opaque / message-qop / nonce-count / auth-param username = "username" EQUAL username-value username-value = quoted-string digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT digest-uri-value = rquest-uri ; HTTP/1.1で規定されているrequest-uriと同じ message-qop = "qop" EQUAL qop-value Rosenberg, et. al. Standards Track [Page 227] RFC 3261 SIP: Session Initiation Protocol June 2002 cnonce = "cnonce" EQUAL cnonce-value cnonce-value = nonce-value nonce-count = "nc" EQUAL nc-value nc-value = 8LHEX dresponse = "response" EQUAL request-digest request-digest = LDQUOT 32LHEX RDQUOT auth-param = auth-param-name EQUAL ( token / quoted-string ) auth-param-name = token other-response = auth-scheme LWS auth-param *(COMMA auth-param) auth-scheme = token Authentication-Info = "Authentication-Info" HCOLON ainfo *(COMMA ainfo) ainfo = nextnonce / message-qop / response-auth / cnonce / nonce-count nextnonce = "nextnonce" EQUAL nonce-value response-auth = "rspauth" EQUAL response-digest response-digest = LDQUOT *LHEX RDQUOT Call-ID = ( "Call-ID" / "i" ) HCOLON callid callid = word [ "@" word ] Call-Info = "Call-Info" HCOLON info *(COMMA info) info = LAQUOT absoluteURI RAQUOT *( SEMI info-param) info-param = ( "purpose" EQUAL ( "icon" / "info" / "card" / token ) ) / generic-param Contact = ("Contact" / "m" ) HCOLON ( STAR / (contact-param *(COMMA contact-param))) contact-param = (name-addr / addr-spec) *(SEMI contact-params) name-addr = [ display-name ] LAQUOT addr-spec RAQUOT addr-spec = SIP-URI / SIPS-URI / absoluteURI display-name = *(token LWS)/ quoted-string contact-params = c-p-q / c-p-expires / contact-extension c-p-q = "q" EQUAL qvalue c-p-expires = "expires" EQUAL delta-seconds contact-extension = generic-param delta-seconds = 1*DIGIT Content-Disposition = "Content-Disposition" HCOLON disp-type *( SEMI disp-param ) disp-type = "render" / "session" / "icon" / "alert" / disp-extension-token Rosenberg, et. al. Standards Track [Page 228] RFC 3261 SIP: Session Initiation Protocol June 2002 disp-param = handling-param / generic-param handling-param = "handling" EQUAL ( "optional" / "required" / other-handling ) other-handling = token disp-extension-token = token Content-Encoding = ( "Content-Encoding" / "e" ) HCOLON content-coding *(COMMA content-coding) Content-Language = "Content-Language" HCOLON language-tag *(COMMA language-tag) language-tag = primary-tag *( "-" subtag ) primary-tag = 1*8ALPHA subtag = 1*8ALPHA Content-Length = ( "Content-Length" / "l" ) HCOLON 1*DIGIT Content-Type = ( "Content-Type" / "c" ) HCOLON media-type media-type = m-type SLASH m-subtype *(SEMI m-parameter) m-type = discrete-type / composite-type discrete-type = "text" / "image" / "audio" / "video" / "application" / extension-token composite-type = "message" / "multipart" / extension-token extension-token = ietf-token / x-token ietf-token = token x-token = "x-" token m-subtype = extension-token / iana-token iana-token = token m-parameter = m-attribute EQUAL m-value m-attribute = token m-value = token / quoted-string CSeq = "CSeq" HCOLON 1*DIGIT LWS Method Date = "Date" HCOLON SIP-date SIP-date = rfc1123-date rfc1123-date = wkday "," SP date1 SP time SP "GMT" date1 = 2DIGIT SP month SP 4DIGIT ; 日 月 年 (例: 02 Jun 1982) time = 2DIGIT ":" 2DIGIT ":" 2DIGIT ; 00:00:00 - 23:59:59 wkday = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun" month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" Error-Info = "Error-Info" HCOLON error-uri *(COMMA error-uri) Rosenberg, et. al. Standards Track [Page 229] RFC 3261 SIP: Session Initiation Protocol June 2002 error-uri = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) Expires = "Expires" HCOLON delta-seconds From = ( "From" / "f" ) HCOLON from-spec from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) from-param = tag-param / generic-param tag-param = "tag" EQUAL token In-Reply-To = "In-Reply-To" HCOLON callid *(COMMA callid) Max-Forwards = "Max-Forwards" HCOLON 1*DIGIT MIME-Version = "MIME-Version" HCOLON 1*DIGIT "." 1*DIGIT Min-Expires = "Min-Expires" HCOLON delta-seconds Organization = "Organization" HCOLON [TEXT-UTF8-TRIM] Priority = "Priority" HCOLON priority-value priority-value = "emergency" / "urgent" / "normal" / "non-urgent" / other-priority other-priority = token Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) / other-challenge other-challenge = auth-scheme LWS auth-param *(COMMA auth-param) digest-cln = realm / domain / nonce / opaque / stale / algorithm / qop-options / auth-param realm = "realm" EQUAL realm-value realm-value = quoted-string domain = "domain" EQUAL LDQUOT URI *( 1*SP URI ) RDQUOT URI = absoluteURI / abs-path nonce = "nonce" EQUAL nonce-value nonce-value = quoted-string opaque = "opaque" EQUAL quoted-string stale = "stale" EQUAL ( "true" / "false" ) algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess" / token ) qop-options = "qop" EQUAL LDQUOT qop-value *("," qop-value) RDQUOT qop-value = "auth" / "auth-int" / token Proxy-Authorization = "Proxy-Authorization" HCOLON credentials Rosenberg, et. al. Standards Track [Page 230] RFC 3261 SIP: Session Initiation Protocol June 2002 Proxy-Require = "Proxy-Require" HCOLON option-tag *(COMMA option-tag) option-tag = token Record-Route = "Record-Route" HCOLON rec-route *(COMMA rec-route) rec-route = name-addr *( SEMI rr-param ) rr-param = generic-param Reply-To = "Reply-To" HCOLON rplyto-spec rplyto-spec = ( name-addr / addr-spec ) *( SEMI rplyto-param ) rplyto-param = generic-param Require = "Require" HCOLON option-tag *(COMMA option-tag) Retry-After = "Retry-After" HCOLON delta-seconds [ comment ] *( SEMI retry-param ) retry-param = ("duration" EQUAL delta-seconds) / generic-param Route = "Route" HCOLON route-param *(COMMA route-param) route-param = name-addr *( SEMI rr-param ) Server = "Server" HCOLON server-val *(LWS server-val) server-val = product / comment product = token [SLASH product-version] product-version = token Subject = ( "Subject" / "s" ) HCOLON [TEXT-UTF8-TRIM] Supported = ( "Supported" / "k" ) HCOLON [option-tag *(COMMA option-tag)] Timestamp = "Timestamp" HCOLON 1*(DIGIT) [ "." *(DIGIT) ] [ LWS delay ] delay = *(DIGIT) [ "." *(DIGIT) ] To = ( "To" / "t" ) HCOLON ( name-addr / addr-spec ) *( SEMI to-param ) to-param = tag-param / generic-param Unsupported = "Unsupported" HCOLON option-tag *(COMMA option-tag) User-Agent = "User-Agent" HCOLON server-val *(LWS server-val) Rosenberg, et. al. Standards Track [Page 231] RFC 3261 SIP: Session Initiation Protocol June 2002 Via = ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm) via-parm = sent-protocol LWS sent-by *( SEMI via-params ) via-params = via-ttl / via-maddr / via-received / via-branch / via-extension via-ttl = "ttl" EQUAL ttl via-maddr = "maddr" EQUAL host via-received = "received" EQUAL (IPv4address / IPv6address) via-branch = "branch" EQUAL token via-extension = generic-param sent-protocol = protocol-name SLASH protocol-version SLASH transport protocol-name = "SIP" / token protocol-version = token transport = "UDP" / "TCP" / "TLS" / "SCTP" / other-transport sent-by = host [ COLON port ] ttl = 1*3DIGIT ; 0 から 255 Warning = "Warning" HCOLON warning-value *(COMMA warning-value) warning-value = warn-code SP warn-agent SP warn-text warn-code = 3DIGIT warn-agent = hostport / pseudonym ; デバッグで使用するためにWarningヘッダー ; を追加するサーバーの名前または匿名 warn-text = quoted-string pseudonym = token WWW-Authenticate = "WWW-Authenticate" HCOLON challenge extension-header = header-name HCOLON header-value header-name = token header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) message-body = *OCTET 26 セキュリティの考慮: スレットモデルとセキュリティ利用の推奨 SIPは安全を確保するのが容易ではないプロトコルである。中継媒体を使用す ること、多面的な信頼関係、信頼がまったくないエレメント間での予想され る利用、およびユーザー・トゥ・ユーザーでの操作が、セキュリティを些細 な問題とは程遠いものにしている。大規模な調整がなく、多様な環境と用途 で現在実施可能なセキュリティのソリューションが必要とされる。これらの 種々の要求に合うように、SIPの異なる側面と用途に適用可能ないくつかの別 個の仕組みが要求されるだろう。 Rosenberg, et. al. Standards Track [Page 232] RFC 3261 SIP: Session Initiation Protocol June 2002 SIPシグナリングそれ自体のセキュリティは、RTPのようにSIPと協調して使用 されるプロトコルのセキュリティ、またはSIPが伝えるかもしれないすべての 固有のボディのセキュリティの意味あいには何ら影響しない(SIPの安全確保 においてMIMEセキュリティが重要な役割を演じるけれども)、ということに注 意すること。セッションに関連付けられたいかなるメディアも、関連付けら れるすべてのSIPシグナリングに依存せずにエンドツーエンドで暗号化できる。 メディアの暗号化はこのドキュメントの適用範囲外である。 この後に続く検討事項ではまず始めに、SIPのセキュリティの必要性を広く認 める、よく知られたスレットモデル一式を吟味する。これらのスレットに対 処するために要求されるセキュリティサービスのセットがそれに続いて詳述 され、その後にこれらのサービスを提供するために使用できるいくつかのセ キュリティの仕組みの説明が続く。次に、SIPのセキュリティを向上するた めにこれらの仕組みが使用される典型的な配備とともに、SIPの実装者に 対する要求が列挙される。プライバシーに関するいくつかの注意事項でこの セクションを終える。 26.1 攻撃とスレットモデル このセクションでは、多くのSIPの配備に共通するはずのいくつかのスレット について詳述する。これらのスレットはSIPが要求する各セキュリティサービ スを説明するために特に選ばれている。 以下の例はSIPに対するスレットの完全なリストを提供するものではない。そ うではなくて、これらは全種類のスレットを防ぐ可能性が高い特定のセキュ リティサービスの必要性を明らかにする「よく知られている」スレットであ る。 これらの攻撃は、攻撃者がネットワーク上のすべてのパケットを読むことが できる可能性がある環境を想定している。SIPはパブリックインターネット上 で多く使用されることが予想される。ネットワーク上の攻撃者はパケットを 修正できるかもしれない(おそらく何らかの進入された中継媒体で)。攻撃者 は、サービスを盗み取り、通信の盗聴、あるいはセッションを混乱させるこ とを望むかもしれない。 26.1.1 登録の乗っ取り SIPの登録の仕組みはユーザーエージェントが登録サーバーに、(Address- of-Recordで指定される)ユーザーの位置が特定される場所にあるデバイスと して、自身の身元を明かすことを可能にする。登録サーバーはREGISTERメッ セージのFromヘッダーフィールドで主張されているアイデンティティを評価 して、このリクエストがToヘッダーフィールドのAddress-of-Recordに関連付 けられているコンタクトアドレスを修正できるかどうか確定する。これら2つ のフィールドは同じであることが多いとはいえ、サードパーティがユーザー の代わりにコンタクト先を登録することができる多くの有効な配備がある。 Rosenberg, et. al. Standards Track [Page 233] RFC 3261 SIP: Session Initiation Protocol June 2002 その一方、SIPリクエストのFromヘッダーフィールドはUAの所持者によって任 意に修正されることがありうる。そしてこれは悪意ある登録に対してドアを 開くことになる。Address-of-Recordに関連付けられたコンタクト先の変更を 認可されたパーティーにうまくなりすました攻撃者は、例えばURIに対する 既存のすべてのコンタクト先の登録を取り消して攻撃者自身のデバイスを適 切なコンタクトアドレスとして登録できる。それによって、なりすまされた ユーザーに対するすべてのリクエストを攻撃者のデバイスに向かわせる。 このスレットは、リクエスト発信元の暗号的保障の欠如に頼るスレットの仲 間に属する。有用なサービスに相当するすべてのSIP UAS(例えば、SIPリク エストとトラディショナルな電話通話に相互に作用するゲートウェイ)は、そ れが受け取るリクエストを認証することでそれのリソースへのアクセスを制 御することを望むかもしれない。例えばSIPフォンといったエンドユーザー のUAであっても、リクエストの発信元のアイデンティティを確かめることに 関心を持つ。 このスレットは、SIPエンティティがリクエストの発信元を認証することを可 能にするセキュリティサービスの必要性を明らかにする。 26.1.2 サーバーになりすます リクエストが行くことになるドメインは一般的にRequest-URIで指定される。 UAはリクエストを配送するために、通常このドメインのサーバーに直接コン タクトする。しかしながら、攻撃者がリモートサーバーになりすまして、UA のリクエストが別のパーティーに途中で傍受/妨害される可能性が常に存在す る。 例えば、chicago.comドメインのリダイレクトサーバーが別のドメイン( biloxi.com)のリダイレクトサーバーになりすます場合について考えてみる。 ユーザーエージェントはbiloxi.comにリクエストを送るが、chicago.comのリ ダイレクトサーバーが偽造された応答で答える。その応答はbiloxi.comから の応答に対する適切なSIPヘッダーフィールドを持つ。リダイレクト応答中の 偽造されたコンタクトアドレスは発信元のUAを不適切なあるいは安全でない リソースに導く、またはbiloxy.comに対するリクエストが成功することを単 に妨害するかもしれない。 このスレットの仲間には大量のメンバーがおり、その多くはクリティカルで ある。登録の乗っ取りスレットとは逆に、biloxi.comに送られた登録が chicago.comによって傍受/妨害される場合について考えてみる。chicago.com は傍受/妨害した登録に対して偽造した301(Moved Permanently)応答で返答す る。この応答はbiloxy.comから来るように見えるかもしれず、さらにchicago. comを適切な登録サーバーとして指定する。発信元UAからの将来のすべての REGISTERリクエストはchicago.comに行くことになるだろう。 このスレットの防御には、UAがリクエストを送るサーバーをUAが認証できる 手段が要求される。 Rosenberg, et. al. Standards Track [Page 234] RFC 3261 SIP: Session Initiation Protocol June 2002 26.1.3 メッセージボディの改竄 当然のことだが、SIP UAは信頼できるプロキシサーバー経由でリクエストを ルートする。その信頼がどのように確立されたかに関係なく(プロキシの認証 についてはこのセクションの別の場所で議論する)、UAはプロキシがリクエス トをルートすることを信用できるが、そのリクエストに含まれるボディを検 査あるいはもしかすると修正することを信用できない。 SIPメッセージボディをメディアセッションのためのセッション暗号化鍵を伝 えるために使用するUAを考えてみる。それはシグナリングを適切に配送する ためにコンタクトするドメインのプロキシサーバーを信用するが、そのドメ インの管理者が今後のメディアセッションを復号化できることを望まないか もしれない。さらに悪いことに、そのプロキシサーバーに悪意がある場合、 それは、仲介者(man-in-the-middle)として動作するかあるいは発信元UAが要 求したセキュリティ特性を変更するかのいずれかで、セッション鍵を修正す るかもしれない。 このスレットの仲間はセッション鍵にのみ適用するのではなく、SIPにおいて エンドツーエンドで伝えられるもっとも考えられる形のコンテンツにも適用 する。これらにはとりわけ、ユーザーに対して表示/再生されるべきMIMEボ ディ、SDP、あるいはカプセル化されたテレフォニーシグナルが含まれる。 攻撃者は、例えばそれ以降の音声通話を盗聴するために、RTPメディアスト リームを盗聴装置に向けるために、SDPボディの修正を試みるかもしれない。 例えばSubjectといったSIPのいくつかのヘッダーフィールドは、エンドツー エンドで意味を持つということにも注意すること。UAはボディと同様にこ れらのヘッダーフィールドも保護するかもしれない(例えば、Subjectヘッ ダーフィールドを変更する悪意のある中継媒体は重要なリクエストをスパム に見えるようにするかもしれない)。しかしながら、多くのヘッダーフィール ドはプロキシによって合法的に検査されるか変更されるかするので、すべて のヘッダーフィールドがエンドツーエンドで安全確保されるべきではない。 これらの理由により、UAはSIPメッセージボディと、ある限られた場合には ヘッダーフィールドを、エンドツーエンドで安全確保することを望むかもしれ ない。ボディに対して要求されるセキュリティサービスには、機密性、完全 性、および認証が含まれる。これらのエンドツーエンドサービスは、プロキ シサーバーのような中間媒体とのやりとりを安全にするために使用される手 段から独立しているべきである。 26.1.4 セッションの破壊 最初のメッセージングによってダイアログが確立されるとすぐに、ダイアロ グおよび(または)セッションのステートを修正するそれ以降のリクエストが 送られる。セッション中の主要な部分が、そのようなリクエストが攻撃者に よって偽造されないことを確実にできることが重要である。 Rosenberg, et. al. Standards Track [Page 235] RFC 3261 SIP: Session Initiation Protocol June 2002 サードパーティーの攻撃者が、セッションのパラメータ(To tag、From tagな ど)を知るために、2つのパーティーによって共有されているダイアログのい くつかの最初のメッセージを捕らえ、セッションにBYEリクエストを挿入する 場合について考えてみる。攻撃者は、どちらかの参加者から来たように見え るリクエストを偽造することを選ぶかもしれない。ターゲットからBYEを受け 取るとすぐに、セッションは完了前に破壊される。 同様のセッション途中のスレット(mid-session threat)には、セッションを 変更する、偽造されたre-INVITEの送信が含まれる(おそらく、セッションの 安全性を低下させるか、盗聴攻撃の一部としてメディアストリームをリダイ レクトする)。 このスレットに対する最も効果的な対策は、BYEの送信者の認証である。この 場合には、受信者は、(送信者の完全なアイデンティティを確認するのではな く)対応するダイアログが確立されていたのと同じパーティーからBYEが来た ということだけを知る必要がある。また、機密性のために攻撃者がセッショ ンのパラメータを知ることができない場合、攻撃者はBYEを偽造できない。し かしながら、(プロキシサーバーのような)ある種の中継媒体は、セッション が確立されるときにそれらのパラメータを検査する必要がある。 26.1.5 サービス拒否および増幅 サービス拒否(DoS)攻撃は、通常特定のネットワークエレメントのインター フェースに過剰な量のネットワークトラフィックを送ることで、それを利用不 可能にすることに焦点を当てている。分散サービス拒否(DDoS)攻撃は、一人 のネットワークユーザーが複数のネットワークホストにターゲットホストを 多量のネットワークトラフィックであふれさせることを可能にする。 多くのアーキテクチャにおいて、SIPプロキシサーバーは、世界中のIPエンド ポイントからリクエストを受け入れるためにパブリックインターネットに面 している。SIPは、SIPシステムの実装者またはオペレータに認識されて対処 されなければならないDDoS攻撃の多くの潜在的な機会を作り出す。 攻撃者は、変造されたソースIPアドレス、およびリクエストの発信元として ターゲットにされたホストを特定するViaヘッダーフィールドを含む偽のリク エストを生成し、このリクエストを多くのSIPネットワークエレメントに送る。 それによって、不運なSIP UAまたはプロキシを、ターゲットを狙ったDoSトラ フィックを生成するために使用する。 同様に、攻撃者はリクエスト中でターゲットホストを特定する変造された Routeヘッダーフィールド値を使い、そのようなメッセージを、ターゲットに 送られるメッセージングを増幅するフォークを行うプロキシに送るかもしれ ない。 Rosenberg, et. al. Standards Track [Page 236] RFC 3261 SIP: Session Initiation Protocol June 2002 リクエストによって開始されるSIPダイアログが、反対方向に向けて発信され る多数のトランザクションを生み出すことになると攻撃者が確信するときは、 同様な効果を出すためにRecord-Routeが使用されることがありうる。 登録サーバーによってREGISTERリクエストが適切に認証され認可されなけれ ば、多くのDoS攻撃が利用できるようになる。攻撃者は管理ドメインの何人か あるいはすべてのユーザーの登録を削除でき、それによってそれらのユーザー が新規セッションに招待されることを妨げる。攻撃者はまた、登録サーバー および関連するいかなるプロキシサーバーでもDoS攻撃における増幅器とし て使えるように、与えられたAddress-of-Recordに対して同一のホストを指定 する多量のコンタクト先を登録することがありうる。攻撃者はまた、非常に 多くのバインディングを登録することによって登録サーバーの利用可能なメ モリおよびディスクリソースを枯渇することを試みるかもしれない。 SIPリクエストを送信するためにマルチキャストを使用することは、DoS攻撃 の可能性を劇的に増大させる可能性がある。 これらの問題は、DoSのリスクを最小化するアーキテクチャを定義する一般的 な必要性、およびこのクラスの攻撃のセキュリティの仕組みのための推奨 事項を心に留める必要性を明らかにする。 26.2 セキュリティの仕組み 上述のスレットから、SIPプロトコルに要求される基本的なセキュリティサー ビスは、メッセージングの機密性と完全性を保持すること、リプレイ攻撃あ るいはメッセージのなりすましを防ぐこと、セッション参加者の認証とプラ イバシーを提供すること、およびDoS攻撃を防ぐこと、であることを収穫した。 SIPメッセージのボディは、機密性、完全性、および認証のセキュリティサー ビスを単独で要求する。 SIP固有の新しいセキュリティの仕組みを定義するのではなく、SIPは可能 であればどのような場合でも、HTTPとSMTP空間に由来する既存のセキュリティ モデルを再利用する。 メッセージの完全な暗号化は、シグナリングの機密性を保持するのに最適な 手段を提供する。それはまた、悪意のあるいかなる中継媒体によってもメッ セージが修正されないことを保障する。しかしながら、Request-URI、Route、 そしてViaのようなメッセージフィールドは、SIPリクエストが正しくルート されるようにほとんどのネットワークアーキテクチャにおいてプロキシに対 して可視である必要があるので、SIPのリクエストと応答はその全体を単純に エンドツーエンドで暗号化できない。プロキシサーバーは、SIPが機能するた めにメッセージのいくつかのフィーチャーも修正する必要があることにも注 意すること(例えば、Viaヘッダーフィールド値を追加する)。したがって、 プロキシサーバーは、SIP UAにある程度信頼されなければならない。この目的 のために、SIPのための下位層のセキュリティの仕組みが推奨される。それ Rosenberg, et. al. Standards Track [Page 237] RFC 3261 SIP: Session Initiation Protocol June 2002 は、SIPのリクエストまたは応答全体をホップバイホップで回線上で暗号化し、 エンドポイントがリクエストを送るプロキシサーバーのアイデンティティを 検証することを可能にする。 SIPエンティティはまた、安全な方法でお互いを特定する必要もある。SIPエ ンドポイントが相手UAまたはプロキシサーバーに対してそれのユーザーのア イデンティティを表明するとき、そのアイデンティティは何らかの方法で検 証可能であるべきである。SIPではこの要求に対応するために、暗号化認証の 仕組みが提供される。 SIPメッセージボディのための独立したセキュリティの仕組みは、エンドツー エンドの相互認証の代替手段を提供するとともに、ユーザーエージェント が中継媒体を信用しなければならないというある程度の制限を与える。 26.2.1 トランスポートレイヤーとネットワークレイヤーのセキュリティ トランスポートレイヤーまたはネットワークレイヤーのセキュリティは、メッ セージの機密性と完全性を保障しながら、シグナリングトラフィックを暗号化 する。 下位層のセキュリティの確立にはしばしば証明書が使用され、これらの証明 書は多くのアーキテクチャにおいて認証手段を提供するためにも使用される。 トランスポートレイヤーとネットワークレイヤーでセキュリティを提供する よく知られている2つの選択肢は、それぞれTLS(参考文献[25])とIPSec(参考 文献[26])である。 IPSecはネットワークレイヤープロトコルのツールのセットであり、伝統的な IP(Internet Protocol)の安全な代替として使用できる。IPSecは、ホストの組 または管理ドメインが互いに既存の信頼関係を持つアーキテクチャにおいて、 もっとも普通に使用される。IPSecは、ホストのOSレベルで、または(VPNアー キテクチャでのように)特定のインターフェースから受け取るすべてのトラ フィックに対して機密性と完全性を提供するセキュリティゲートウェイ上で、 通常は実装される。IPSecはまた、ホップバイホップでも使用できる。 多くのアーキテクチャにおいてIPSecはSIPアプリケーションとの統合を要求 しない。 IPSecはおそらく、SIPホストに直接セキュリティを追加するのが困 難であろう配備に最適である。最初のホップのプロキシサーバーと、あらか じめ共有されている鍵関係を持つUAも、IPSecを使用する候補である。SIPの ためのIPSecのいかなる配備も、SIPの安全を確保するために要求されるプロ トコルツールを記述するIPSecプロファイルを要求する。このドキュメントで はそのようなプロファイルは与えていない。 Rosenberg, et. al. Standards Track [Page 238] RFC 3261 SIP: Session Initiation Protocol June 2002 TLSは、コネクション指向のプロトコル上で(このドキュメントではTCP)トラ ンスポートレイヤーのセキュリティを提供する。「tls」(TCP上のTLSをあら わす)をViaヘッダーフィールド値またはSIP URIの中で、希望するトランスポー トプロトコルとして指定できる。TLSは、既存の信頼関係がないホスト間に ホップバイホップのセキュリティが要求されるアーキテクチャに最適である。 例えば、Aliceは彼女のローカルプロキシサーバーを信頼している。そのプ ロキシサーバーは証明書の交換後にBobのローカルプロキシサーバー(Bobはこ れを信頼している)を信頼することを決定する。したがって、BobとAliceは安 全に通信できる。 TLSはSIPアプリケーションと緊密に結び付けられなければならない。トラン スポートの仕組みはSIPではホップバイホップで定められるので、プロキシ サーバーにTLS上でリクエストを送るUAはエンドツーエンドでTLSが使用され ることの保障をなんら持たない。 SIPアプリケーションでTLSが使用されるときは、TLS_RSA_WITH_AES_128_CBC_SHA 暗号スイート(参考文献[6])が実装者によって最低限サポートされなければな らない[MUST]。下位互換のために、プロキシサーバー、リダイレクトサーバー、 および登録サーバーはTLS_RSA_WITH_3DES_EDE_CBC_SHAをサポートするべきで ある[SHOULD]。実装者はまた、他のいかなる暗号スイートをサポートしてもよ い[MAY]。 26.2.2 SIPS URIスキーム SIPS URIスキームは、スキーム文字列が「sip」ではなく「sips」であるが、 SIP URIの構文(19で述べられている)を遵守する。しかしながら、SIPSのセマ ンティクスはSIP URIと大きく異なる。SIPSは、リソースに安全に到達するべ きであることをそのリソースが指定することを可能にする。 SIPS URIは特定のユーザーのためのAddress-of-Record(そのユーザーが(ユー ザーの名刺、ユーザーのリクエストのFromヘッダーフィールド、REGISTERリ クエストのToヘッダーフィールドで)標準的(canonically)に知られているURI) として使用できる。リクエストのRequest-URIとして使用されるとき、SIPSス キームは、Request-URIのドメイン部分に対して責任を負うSIPエンティティ に到達するまで、リクエストが転送(forward)される各ホップがTLSで安全を確保 されなければならないことを表す。それが当該のドメインに到達するとすぐ に、ローカルセキュリティとルーティングポリシーにしたがって、かなりの 可能性でUASへの最後のホップのためにTLSを使用して、操作される。 リクエストの発信元によって使用されるとき(リクエストの発信元がSIPS URI をターゲットのAddress-of-Recordとして使用する場合のように)、SIPSは、 ターゲットドメインへのリクエストパス全体が安全確保されることを決定す る。 SIPSスキームは、Request-URIに加えて、Address-of-Record、コンタクトア ドレス(Contactヘッダーのコンテンツ(REGISTERメソッドのそれも含む))、お よびRouteヘッダーの中に含めることで、今日SIP URIがSIPで使用されるその 他の多くのやり方に適用できる。それぞれの場合において、SIPS URIスキー Rosenberg, et. al. Standards Track [Page 239] RFC 3261 SIP: Session Initiation Protocol June 2002 ムはこれら既存のフィールドが安全なリソースを指定することを可能にする。 SIPS URIがこれらのいかなるコンテキストで参照される方法も、参考文献[4] で詳述されているそれ自身のセキュリティ特性を持つ。 SIPSの使用は、暗号スイートTLS_RSA_WITH_AES_128_CBC_SHAが使用されるべ き[SHOULD]ことと同様に、相互TLS認証が使用されるべきである[SHOULD]こと を必然とする。認証処理で受け取った証明書は、クライアントが保持するルー ト証明書で検証されるべきである[SHOULD]。証明書の検証失敗は、リクエ ストの失敗という結果になるべきである[SHOULD]。 SIPS URIスキームにおいて、トランスポートはTLSに依存せず、したがっ て「sips:alice@atlanta.com;transport=tcp」と「sips:alice@atlanta.com; transport=sctp」はともに有効である(そうではあるが、UDPはSIPSにとっ て有効なトランスポートではないということに注意すること)ということ に注意すること。「transport=tls」の使用は、リクエストのひとつのホッ プにはっきりと限定されることを理由のひとつとして、結果的に反対さ れた。これはRFC2543からの変更である。 SIPS URIをAddress-of-Recordとして配布するユーザーは、安全ではないトラ ンスポート上でリクエストを拒否するデバイスをオペレートすることを選択 するかもしれない。 26.2.3 HTTP認証 SIPはHTTP認証に基づくチャレンジ能力を提供する。それはチャレンジと信用 証明書を伝えるヘッダーフィールドと、401および407応答コードに依存する。 SIPにおけるHTTPダイジェスト認証スキームの再利用は、大きな修正をするこ となしに、リプレイ防御と一方向認証を可能にする。 SIPにおけるダイジェスト認証の使用方法はセクション22で詳述されている。 26.2.4 S/MIME 上で議論したように、機密性のためにエンドツーエンドでSIPメッセージ全体 を暗号化することは、ネットワークの中継媒体(プロキシサーバーのような) がメッセージを正しくルートするために特定のヘッダーフィールドを見る必 要があるので適切ではなく、これらの中継媒体がセキュリティのつながりか ら除外される場合には、SIPメッセージは本質的にルート不可能になる。 しかしながら、S/MIMEはSIP UAがSIP内でMIMEボディを暗号化し、メッセージ ヘッダーに影響を及ぼすことなくこれらのボディをエンドツーエンドで安全 にすることを可能にする。S/MIMEは、相互認証と共に、メッセージボディの ためのエンドーツーエンドの機密性と完全性を提供できる。S/MIMEを、SIPメッ セージトンネリングを介してSIPヘッダーフィールドのための完全性と機密性の フォームを提供するために使用することも可能である。 Rosenberg, et. al. Standards Track [Page 240] RFC 3261 SIP: Session Initiation Protocol June 2002 SIPにおけるS/MIMEの使用方法はセクション23で詳述されている。 26.3 セキュリティの仕組みの実装 26.3.1 SIPの実装者に対する要求事項 プロキシサーバー、リダイレクトサーバー、および登録サーバーはTLSを実装 しなければならず[MUST]、相互認証と一方向認証の双方をサポートしなけれ ばならない[MUST]。UAがTLSを開始する能力があることが強く推奨される[RECOMMENDED]。 UAはまた、TLSサーバーとして動作する能力を持ってもよい[MAY]。プロキシ サーバー、リダイレクトサーバー、および登録サーバーは、それらの標準的 な(canonical)ホスト名に対応するsubjectを持つサイト証明書を所持す るべきである[SHOULD]。UAはTLSでの相互認証のためにそれ自身の証明書を持 ってもよい[MAY]が、このドキュメントではそれらの使用法についての規 定を示さない。TLSをサポートするすべてのSIPエレメントは、TLSネゴシエー ション中に受け取った証明書を検証するための仕組みを持たなければな らない[MUST]。これには認証機関(望むべくは、Webブラウザのためのルート 証明書を発行するディストリビューターに匹敵する、よく知られたサイト証 明書ディストリビューター)で発行された一つ以上のルート証明書を所持する ことが必要になる。 TLSをサポートするすべてのSIPエレメントは、SIPS URIスキームもサポート しなければならない[MUST]。 プロキシサーバー、リダイレクトサーバー、登録サーバー、およびUAは、IPSec もしくは他の下位レイヤーのセキュリティプロトコルも実装してもよい[MAY]。 UAがプロキシサーバー、リダイレクトサーバー、または登録サーバーにコン タクトを試みるとき、そのUACはTLS接続を開始するべきである[SHOULD] (そのTLS接続上でSIPメッセージを送る)。アーキテクチャの一部は、 UASはそのようなTLS接続でもリクエストを受け取ってもよい[MAY]。 プロキシサーバー、リダイレクトサーバー、登録サーバー、およびUAは、22 で要求されているすべてのアスペクトを包含するダイジェスト認証を実装し なければならない[MUST]。プロキシサーバー、リダイレクトサーバー、およ び登録サーバーは、少なくとも一つのダイジェスト領域(Digest realm)を設 定されるべき[SHOULD]であり、与えられたサーバーでサポートされる「realm」 文字列はそのサーバーのホスト名またはドメイン名に一致するべきである[SHOULD]。 UAはMIMEボディの署名と暗号化、およびセクション23で述べられているよう なS/MIMEでの信用証明書の移動をサポートしてもよい[MAY]。UAがTLSまた はIPSecのための証明書を検証するために一つ以上の認証機関のルート証明書 を所持する場合、それは必要に応じてS/MIMEの証明書を検証するためにこれら を再利用することが可能であるべきである[SHOULD]。UAはS/MIMEの証明書を検 証することだけのためにルート証明書を所持してもよい[MAY]。 Rosenberg, et. al. Standards Track [Page 241] RFC 3261 SIP: Session Initiation Protocol June 2002 S/MIME実装が出てきて問題がさらにわかってきた時点で、将来のセキュ リティ拡張がS/MIMEに関する規範的な強度をアップグレードするかもし れないことが予想される、ということに注意すること。 26.3.2 セキュリティソリューション これらのセキュリティの仕組みを合わせた操作は、既存のWebおよびEメー ルのセキュリティモデルにある程度従うことができる。高いレベルでは、 UAはダイジェストのユーザー名とパスワードでそれ自身をサーバー(プロキシ サーバー、リダイレクトサーバー、および登録サーバー)に対して認証し、サー バーはTLSで配送されたサイト証明書でそれ自身をホップ一つ先のUAに対してま たはホップ一つ先の別のサーバーに対して(あるいはその逆で)認証する。 ピアツーピアレベルでは、通常UAはお互いを認証するためにネットワークを 信頼する。しかしながら、ネットワークが直接認証(direct authentication) を提供しないか、あるいはネットワーク自体が信用できない場合、直接認証 を提供するためにS/MIMEも使用できる。 以下は、セクション26.1で述べられている種類のスレットを防ぐために、こ れらのセキュリティの仕組みが様々なUAとサーバーによって使用される実 例である。実装者とネットワーク管理者はこのセクションの残りの部分で与 えられる規範となるガイドラインに従ってもよい[MAY]とはいえ、これらは単 に実装の例としてのみ提供されている。 26.3.2.1 登録 UAがオンラインになり、それのローカル管理ドメインに登録するとき、それ は登録サーバーとTLS接続を確立するべきである[SHOULD](セクショ ン10で、UAがどのようにして登録サーバーに到達するかについて述べている)。 登録サーバーはUAに証明書を提供するべき[SHOULD]であり、その証明書によ って特定されるサイトはUAが登録しようとするドメインに一致しなければな らない[MUST]。例えば、UAが「alice@atlanta.com」というAddress-of- Recordの登録をしようとする場合、サイト証明書はatlanta.comドメイン内の ホストを特定しなければならない(例えばsip.atlanta.com)。それがTLSの Certificateメッセージを受け取るとき、UAは証明書を検証して証明書によっ て特定されるサイトを検査するべきである[SHOULD]。証明書が無効であった り、取り消されている、またはそれが適切なパーティーを特定しない場合、 UAはREGISTERメッセージを送ってはならない[MUST NOT]。そうでなければ登 録を処理を進める。 登録サーバーから有効な証明書が提供されたとき、UAはその登録サーバー がUAをリダイレクト、パスワードを盗む、またはそれに似た何らかの攻撃 を試みる攻撃者ではないことがわかる。 Rosenberg, et. al. Standards Track [Page 242] RFC 3261 SIP: Session Initiation Protocol June 2002 UAはそれから、登録サーバーから受け取ったサイト証明書に一致するRequest- URIに宛てられるべき[SHOULD]REGISTERリクエストを生成する。UAが既存のTLS 接続上でREGISTERリクエストを送るとき、登録サーバーは401(Proxy Authentication Required)応答でリクエストにチャレンジするべきである[SHOULD]。 応答のProxy-Authenticationヘッダーフィールド中の「realm」パラメータは、 サイト証明書で以前に与えられたドメインと一致するべきである[SHOULD]。 UACがチャレンジを受け取るとき、それはユーザーに信用証明書を促すか、ま たはチャレンジの「realm」パラメータに一致する鍵束から適切な信用証明書 を取り出すべきである[SHOULD]。この信用証明書のユーザー名はREGISTERリ クエストのToヘッダーフィールド中のURIの「userinfo」部分に一致するべき である[SHOULD]。ダイジェストの信用証明書が適切なProxy-Authorizationヘッ ダーフィールドに挿入されるとすぐに、REGISTERは登録サーバーに対して 再提出されるべきである。 登録サーバーはユーザーエージェントにそれ自身を認証することを要求 するので、攻撃者にとってユーザーのAddress-of-RecordのためのREGISTER リクエストを偽造することは難しいだろう。REGISTERは機密性があるTLS 接続上で送られるので、攻撃者はリプレイ攻撃のために信用証明書を記 録するためにREGISTERを傍受することができないということにも注意す ること。 いったん登録が登録サーバーに受け入れられると、登録サーバーがこの管理 ドメインのユーザーに対するリクエストが送られるプロキシサーバーとして も動作する場合には、UAはこのTLS接続をオープンしたままにするべきであ る[SHOULD]。既存のTLS接続は、ちょうど登録を完了したUAに対してやってく るリクエストを配送するために再利用される。 UAはすでにTLS接続の反対側のサーバーを認証しているので、この接続上 をやってくるすべてのリクエストはそのプロキシサーバーを通ってきた ことがわかる。攻撃者は、そのプロキシサーバーを通して送られたよう に見える偽のリクエストを生成できない。 26.3.2.2 ドメイン間リクエスト AliceのUAが、bob@biloxi.comというリモート管理ドメインのユーザーとのセッ ションを開始することを望むとする。また、ローカル管理ドメイン(atlanta. com)はローカルアウトバウンドプロキシをもっているものとする。 管理ドメインに対するインバウンドリクエストを操作するプロキシサーバー は、ローカルアウトバウンドプロキシとしても動作してもよい[MAY]。便宜上、 atlanta.comの場合はこうであるとする(そうでなければ、この時点でユー ザーエージェントは別のサーバーと新たにTLS接続を開始するだろう)。ク ライアントが前のセクションで述べられている登録処理を完了していると仮定 すると、クライアントは他のユーザーにINVITEリクエストを送るときに、 Rosenberg, et. al. Standards Track [Page 243] RFC 3261 SIP: Session Initiation Protocol June 2002 ローカルプロキシサーバーとのTLS接続を再利用するべきである[SHOULD]。UA はユーザーに不必要に信用証明書を促すことを避けるために、INVITE中で キャッシュされた信用証明書を再利用するべきである[SHOULD]。 ローカルアウトバウンドプロキシサーバーが、UAによってINVITEで提示され た信用証明書を検証したとき、それはそのメッセージをどのようにルートす るか決定するためにRequest-URIを検査するべきである[SHOULD](参考文献[4] 参照)。Request-URIの「domainname」部分がbiloxi.comではなくローカルド メイン(atlanta.com)に一致した場合、プロキシサーバーはどのようにしたら 最もうまくリクエストされたユーザーに到達できるかを決定するために、自 身のロケーションサービスを調べる。 「alice@atlanta.com」が例えば「alex@atlanta.com」にコンタクト を試みていたら、ローカルプロキシはAlexが登録を行ったときに登録サー バーと確立したTLS接続に対してリクエストをプロキシしただろう。Alex はこのリクエストを彼の認証済みチャンネル上で受け取るので、Aliceの リクエストがローカル管理ドメインのプロキシサーバーによって認可さ れていることを、彼は保証されている。 しかしながら、この場合にはRequest-URIがリモートドメインを指定する。 atlanta.comのローカルアウトバウンドプロキシサーバーは、したがって、 biloxi.comのリモートプロキシサーバーとTLS接続を確立するべきである [SHOULD]。このTLS接続中の双方の参加者はサイト証明書を所持するサーバー なので、相互TLS認証が起こるべきである[SHOULD]。接続のそれぞれの側は、 証明書にあらわれるドメイン名をSIPメッセージのヘッダーフィールドと比較 するということに注意して、他方の証明書を検証し検査するべきである [SHOULD]。例えば、atlanta.comのプロキシサーバーはこの時点で、リモート 側から受け取った証明書がbiloxi.comのドメインと一致することを検証するべ きである[SHOULD]。それがそのように行われてTLSネゴシエーションが完了し、 2つのパーティー間で安全なチャンネルが確立されるとすぐに、atlanta.comの プロキシはbiloxi.comにINVITEリクエストを転送(forward)できる。 次にbiloxi.comのプロキシサーバーは、atlanta.comのプロキシサーバーの証 明書を検査して、その証明書が主張するドメインをINVITEリクエストのFrom ヘッダーフィールドの「domainname」部分と比較するべきである[SHOULD]。 biloxiのプロキシは、プロキシ元の管理ドメインにマッチしないリクエスト を拒否することを要求する、厳格なセキュリティポリシーを持ってもよい [MAY]。 スパムを生成するために利用されることが多いSMTPの「オープンリレー」 に相当するものをSIPで防ぐために、このようなセキュリティポリシー を設けてもよい。 Rosenberg, et. al. Standards Track [Page 244] RFC 3261 SIP: Session Initiation Protocol June 2002 しかしながら、このポリシーは、リクエストがそれ自身のものだとするドメ インから来たことのみを保障する。それは、atlanta.comがどのようにAlice を認証したかということをbiloxi.comが確認することを認めない。biloxi.com がatlanta.comの認証ポリシーを知る他の何らかの方法を持つ場合に限り、 Aliceが彼女のアイデンティティをどのように証明したかを確認できる可能性 がある。biloxi.comはそれから、biloxi.comと共通の認証ポリシーを共有す るために、管理上知らないドメインから来るリクエストを禁止するさらに厳 格なポリシーを制定できる。 INVITEがbiloxiのプロキシによって承認されるとすぐに、プロキシサーバー は、このリクエストのターゲットであるユーザー(この場合は「bob@biloxi. com」)に関連付けられている既存のTLSチャンネル(もしあれば)を特定するべ きである[SHOULD]。INVITEはこのチャンネルを通してBobにプロキシされるべ きである。リクエストは以前にbiloxiのプロキシであるとして認証されたTLS 接続上で受け取られるので、BobはFromヘッダーフィールドが改竄されてお らず、atlanta.comはAliceを検証済みであることを知る(Aliceのアイデンティ ティを信じるかどうかは必ずしも確かではないが)。 それらがリクエストを転送(forward)する前に、双方のプロキシサーバーは、 このダイアログの将来のすべてのリクエストがこれらのプロキシサーバーを通 過するように、リクエストにRecord-Routeヘッダーフィールドを追加するべ きである[SHOULD]。それによってそのプロキシサーバーはこのダイアログの 存続する間、セキュリティサービスを提供し続けることができる。そのプロ キシサーバーがRecord-Routeにそれら自身を追加しない場合、将来のメッセー ジはAliceとBobのあいだをいかなるセキュリティサービスもなしで(S/MIME のようななんらかの独立したエンドツーエンドのセキュリティに2つのパー ティーが合意していなければ)、エンドツーエンドで直接渡る。この点に関し て、SIP台形モデルは、サイトプロキシ間の合意の約束事がAliceとBobのあい だで十分に安全なチャンネルを提供できる、良い仕組みを提供する。 このアーキテクチャ上で獲物を狙う攻撃者は、例えば、BYEリクエス トを偽造してそれをBobとAliceのあいだのシグナリングストリームに挿 入することができない。その理由は、攻撃者がセッションのパラメータ を確認する方法がなく、完全性の仕組みがAliceとBobのあいだのトラ フィックを推移的に(transitively)防御するからである。 26.3.2.3 ピアツーピアのリクエスト それとは別に、ローカルアウトバウンドプロキシを持たない、carol@chicago. comというアイデンティティを主張するUAを考えてみる。Carolがbob@biloxi. comにINVITEを送ることを望むとき、彼女のUAはbiloxiのプロキシと(与えら れたRequest-URIにどうしたら最もうまく到達できるかを決定するために、参 考文献[4]で述べられている仕組みを使用して)直接TLS接続を開始するべきで ある[SHOULD]。彼女のUAがbiloxiのプロキシから証明書を受け取るとき、彼女 がTLS接続でINVITEを送る前にそれが検証されるべきである[SHOULD]。Carol はbiloxiのプロキシに彼女のアイデンティティを提供する手段をもたないが、 Rosenberg, et. al. Standards Track [Page 245] RFC 3261 SIP: Session Initiation Protocol June 2002 彼女はINVITEの「message/sip」ボディ上にCMS分離署名を持っている。この 場合、Carolはbiloxi.comと正式な関係を持たないので、彼女がbiloxi.comの realmに何らかの信用証明書を持つことはおそらくないだろう。biloxiのプロ キシは、Fromヘッダーフィールドの「domainname」部分にbiloxi.comを持たな いリクエストにチャレンジすることさえ不可能にする厳格なポリシーを持って もよい[MAY]。それはこれらのユーザーを認証されていない(unauthenticated) として処理する。 biloxiのプロキシは、認証されていないすべてのリクエストがbob@biloxy.com (すなわち、)に対して登録されている適切なコンタクト アドレスにリダイレクトされるべきである、というBobのためのポリシーを持 つ。Carolは彼女がbiloxiのプロキシと確立したTLS接続上でリダイレクト応答 を受け取るので、彼女はそのコンタクトアドレスの真実性を信用する。 Carolはそれから、指定されたアドレスとTCP接続を確立して、受け取ったコン タクトアドレスを含むRequest-URIを持つ新規INVITEを送るべきである[SHOULD] (リクエストが万全になるようにボディ中の署名を再計算して)。Bobはこ のINVITEを安全ではないインターフェース上で受け取るが、彼のUAはリクエス トのFromヘッダーフィールドを検査し、(この場合には)それを認識する。そし て引き続いてローカルにキャッシュされている信用証明書とINVITEのボディの 署名中の信用証明書をマッチする。彼は同様の方法で応答し、彼自身をCarol に対して認証し、そして安全なダイアログが開始する。 時折、管理ドメインのファイアウォールやNATが、UAに対する直接のTCP 接続の確立を不可能にすることがある。この場合、プロキシサーバーは もしかすると信頼という意味合いを持たない方法で、ローカルポリシー が指示するようにリクエストをUAにリレーできるかもしれない(例えば、 既存のTLS接続の使用を見合わせてリクエストをクリアテキストのTCP上 で転送(forward)して)。 26.3.2.4 DoS防御 これらのセキュリティソリューションを利用するアーキテクチャに対するサー ビス拒否攻撃のリスクを最小限に抑えるため、実装者は以下のガイドラインに 注意するべきである。 SIPプロキシサーバーが運用されているホストがパブリックインターネットか らルート可能なとき、それは防御的な運用ポリシー(ソースルートされたトラ フィックをブロックして、望ましくはpingトラフィックをフィルターして)で 管理ドメインに配備されるべきである[SHOULD]。TLSとIPSecの双方は管理ド メインの末端で、安全なトンネルとソケットを集約するためにセキュリティ アソシエーションに参加する要塞ホストも使用できる。これらの要塞ホスト は、管理ドメイン内のSIPホストが不要なメッセージングに邪魔されないこと を保証しながら、サービス拒否攻撃の矢面に立つこともできる。 Rosenberg, et. al. Standards Track [Page 246] RFC 3261 SIP: Session Initiation Protocol June 2002 どのようなセキュリティソリューションが配備されるかに関係なく、プロキ シサーバーに向けられた膨大な量のメッセージはプロキシサーバーのリソー スを動かなくし、望ましいトラフィックがデスティネーションに到達するこ とを妨げることがある。プロキシサーバーでSIPトランザクションを処理する ことに関連する計算コストが存在し、そのコストはステートレスプロキシサー バーに対するものよりもステートフルプロキシサーバーに対するものの方が 大きい。したがって、ステートフルプロキシはステートレスプロキシサー バーよりも膨大な量のメッセージの影響を受けやすい。 UAとプロキシサーバーは、疑わしいリクエストに、通常の応答の再送アルゴ リズムを使わないで一つの401(Unauthorized)または407(Proxy Authentication Required)のみでチャレンジするべきであり[SHOULD]、結果として認証されて いないリクエストにはステートレスに動作する。 401(Unauthorized)または407(Proxy Authentication Required)ステー タス応答の再送は、トラフィックをサードパーティーに向かわせるため に変造したヘッダーフィールド値(例えばVia)を使用する攻撃者の問 題を増大する。 まとめると、TLSのような仕組みを介したプロキシサーバーの相互認証は、 性質の悪い中継媒体がサービスを拒否することができる変造されたリクエス トや応答を持ち込む可能性を劇的に減らす。これは攻撃者が無害なSIPノード を増幅を仲介するものにすることを十分に難しくする。 26.4 制限事項 これらのセキュリティの仕組みは、慎重に適用されるときには多くのスレッ トを防ぐが、実装者とネットワークオペレータが理解しておかなければなら ない、仕組みの適用範囲における制限事項がある。 26.4.1 HTTPダイジェスト認証 SIPでHTTPダイジェスト認証を使用する際の主要な制限の一つは、ダイジェス ト認証の完全性の仕組みがSIPではあまり良く機能しないということである。 具体的には、それはRequest-URIとメッセージのメソッドの保護は提供するが、 UAがもっとも安全確保を望む可能性が高い、いかなるヘッダーフィールドの 保護も提供しない。 RFC2617で述べられている既存のリプレイ防御の仕組みもSIPではいくつか の制限がある。例えば、next-nonceの仕組みはパイプラインリクエスト をサポートしない。リプレイ防御にはnonce-countの仕組みが使用されるべ きである。 HTTPダイジェスト認証の別の制限は、realmの適用範囲である。ダイジェスト 認証は、ユーザーがリソース(ユーザーが契約しているサービスプロバイダ のように、それとの間にあらかじめ存在する関係がある(これはとても一 Rosenberg, et. al. Standards Track [Page 247] RFC 3261 SIP: Session Initiation Protocol June 2002 般的なケースであり、よってダイジェスト認証は非常に有用な機能を提供す る))に対してユーザー自身を認証することを望むときに有用である。それと は対照的に、TLSの適用範囲は、証明書がグローバルに検証可能であることが 多いので、ドメイン間あるいは複数realmにおよび、そのためUAはあらかじめ 存在する関係を持たないサーバーを認証できる。 26.4.2 S/MIME S/MIMEの仕組みに関する最大で未解決の欠陥は、エンドユーザーに対して広く 普及している公開鍵インフラの欠如である。自己署名証明書(あるいはダイアロ グ中の一方の参加者が検証できない証明書)が使用される場合、セクション23.2 で述べられているSIPベースの鍵交換の仕組みは、攻撃者がS/MIMEボディを 検査して修正する可能性があるman-in-the-middle攻撃の影響を受けやすい。攻 撃者はダイアログの2つのパーティー間の最初の鍵交換を傍受し、既存のCMS分 離署名をリクエストと応答から取り除き、攻撃者が供給する証明書(正しい Address-of-Recordに対する証明書であるように見える)を含む別のCMS分離署名 を挿入する必要がある。それぞれのパーティーは、実際には攻撃者の公開鍵を 持つが、相手と鍵を交換したと思うだろう。 攻撃者は、2つのパーティー間の最初の鍵交換のときにのみこの脆弱性を利用 できるということに注意することが重要である。それ以降の場合には、鍵の 改変はUAにとってはっきりと目に付く。攻撃者が長い間(可能性として、何日 も、何週間も、あるいは何年も経過して)2つのパーティー間の将来のすべて のダイアログのパスに留まりつづけることも難しいだろう。 SSHは最初の鍵交換時に同じman-in-the-middle攻撃の影響を受けやすい。SSHは 完全でないけれども、その一方でコネクションのセキュリティを向上させるこ とは広く認められている。鍵指紋の使用は、SSHと同じようにSIPにもいくらか の支援を提供するだろう。例えば、2つのパーティーが音声通話セッションを確 立するためにSIPを使用する場合、各々は相手から受け取った鍵の指紋を読み取 るだろう。そしてそれはオリジナルと比較される。仲介者(man-in-the-middle) にとって、参加者のシグナリングをエミュレートする(クリッパーチップベース の安全な電話で使用された行為)よりも音声をエミュレートするほうがはるかに 難しいに違いない。 S/MIMEの仕組みは、UAが暗号化されたリクエストを前置きなしに送ること を可能にする(UAが鍵束にデスティネーションのAddress-of-Recordに対する 証明書を所持する場合)。しかしながら、Address-of-Recordのために登録さ れたどの個別のデバイスも、デバイスの現在のユーザーによって前回採用さ れた証明書を保持しないことがありうる。そしてそれゆえに、暗号化された Rosenberg, et. al. Standards Track [Page 248] RFC 3261 SIP: Session Initiation Protocol June 2002 リクエストを適切に処理することはできない。このことは結局、回避可能な 何らかのエラーシグナリングとなる。これは特に暗号化されたリクエストが フォークされたときに起こる可能性が高い。 S/MIMEに関連する鍵は、デバイス(UA)ではなく特定のユーザー(Address-of- Record)に関連付けられたときにもっとも有用である。ユーザーがデバイス間 を移動するとき、UA間で秘密鍵を安全に送信することは難しいかもしれない。 そのような鍵がどのようにデバイスに取得されるかはこのドキュメントの適 用範囲外である。 そのほかのS/MIMEの仕組みのより平凡な問題は、巨大なメッセージが、特 にセクション23.4で述べられているSIPトンネリングの仕組みが使用される ときに、生成されることがあるということである。そのため、S/MIMEトンネ リングが使用されるときはトランスポートプロトコルとしてTCPを使用するこ とを推奨する[RECOMMENDED]。 26.4.3 TLS TLSに関して最も一般的に表明される懸念は、TLSがUDP上で走ることができな いということである。すなわち、TLSは基礎となるコネクション指向のトラン スポートプロトコルを必要とする(それはこのドキュメントではTCPを意味する)。 ローカルプロキシサーバーおよび(または)登録サーバーにとって、多くのUA と長時間存続するTLS接続を同時にたくさん維持することも困難かもしれ ない。これはいくつかのスケーラビリティに関する妥当な懸念を、特に集約 的な暗号スイートに対して、もたらす。長時間存続するTLS接続の冗長性を維 持することも、特にUAが単独でそれらの確立に責任を負うときに、厄介かもし れない。 TLSは、SIPエンティティがそれの近辺のサーバーを認証することのみを認め る。TLSは厳密にホップバイホップのセキュリティを提供する。TLSあるいは このドキュメントで規定されているいかなる仕組みも、クライアントが それが直接のTCP接続を形成することができないプロキシサーバーを認証する ことを認めない。 26.4.4 SIPS URI TLSをリクエストパスのすべてのセグメントで実際に使用することは、終端の UASがTLS上で到達可能でなければならないことを必要とする(おそらくは、コ ンタクトアドレスとしてSIPS URIを登録して)。これがSIPSの望ましい用法で ある。しかしながら、多くの有効なアーキテクチャは、リクエストパスの一 部分の安全を確保するためにTLSを使用し、例えば、UASへの最後のホップ に対しては他の何らかの仕組みに頼る。したがってSIPSは、TLSの用法が 真にエンドツーエンドであることを保障できない。多くのUAはやってくるTLS 接続を受け入れないので、たとえTLSをサポートするUAであっても上記のTLSの 制限事項のセクションで述べられているように、UASとしてTLS上のリクエスト を受け取るために、持続するTLS接続を維持することを要求されるかもしれ ない、ということに注意すること。 Rosenberg, et. al. Standards Track [Page 249] RFC 3261 SIP: Session Initiation Protocol June 2002 SIPS Request-URIに対するSIPSバインディングを提供するために、ロケーショ ンサービスは必須とされない。ロケーションサービスは(セクション10.2.1 で述べられているように)一般的にユーザー登録で利用されるが、他の様々な プロトコルおよびインターフェースがAddress-of-Recordのためのコンタクト アドレスを供給することもたぶんあり得る。そしてこれらのツールは必要に 応じてSIPS URIをSIP URIに自由にマッピングする。ロケーションサービスは バインディングを問い合わせられたときには、SIPS Request-URIを持つリク エストを受け取ったかどうかに関わらず、それのコンタクトアドレスを返す。 リダイレクトサーバーがロケーションサービスにアクセスしている場合、コ ンタクトアドレスの正当性を決定するためにリダイレクトのContactヘッダー フィールドを処理するかどうかは、そのエンティティ次第である。 TLSがターゲットドメインまでのリクエストセグメントのすべてで使用される ことを保証することは、多少面倒である。非準拠または信用できない、途中 にある暗号的に認証されたプロキシサーバーがSIPSに関する転送(forward)の ルール(およびセクション16.6の一般的な転送(forward)のルール)を無視するこ とを選ぶかもしれないことが見込まれる。そのような悪意のある中継媒体は、 例えば、安全性を落とす(downgrade)ための試みとしてリクエストのターゲッ トをSIPS URIからSIP URIに変更することがあり得る。 それとは別に、中継媒体が合法的にリクエストのターゲットをSIPS URIから SIP URIに変更するかもしれない。そのため、Request-URIにSIPS URIスキー ムを使用するリクエストの受信者は、リクエストパス全体で(クライアントか ら先で)SIPSが使用されたということをRequest-URIだけから仮定できない。 これらの懸念に対処するため、SIP URIまたはSIPS URIを含むRequest-URIを 持つリクエストの受信者は、Toヘッダーフィールド値を検査してそれがSIPS URIを含むかどうか確認することが推奨される[RECOMMENDED](Request-URIの URIがToヘッダーフィールドのURIと同じスキームを持つが等価ではない場合 でも、それはセキュリティの侵害にならないことに注意すること)。クライア ントはリクエストのRequest-URIとToヘッダーフィールドに違う値を入れるこ とを選択するかもしれないが、SIPSが使用されるときにはこの不一致はセキュ リティ侵害の可能性があると解釈され、結果的にリクエストは受信者に拒否さ れることがあり得る。受信者はまた、ローカル管理ドメインに到達するまでの リクエストパス全体でTLSが使用されたかどうかをダブルチェックするために Viaヘッダーの連なりも検査してもよい[MAY]。エンドツーエンドでTo ヘッダーフィールドがオリジナルの形で伝えられることを保証する役に立つ ように、発信元のUACがS/MIMEを使用することもできる。 Request-URIのスキームがトランジット中に不適切に修正されたと信じる理由 をUASが持つ場合、UAはそれのユーザーにセキュリティ侵害の可能性があるこ とを通知するべきである[SHOULD]。 Rosenberg, et. al. Standards Track [Page 250] RFC 3261 SIP: Session Initiation Protocol June 2002 ダウングレード攻撃を防御するためのさらなる対策として、SIPSリクエスト のみを受け入れるエンティティは、安全ではないポート上のコネクションを 拒否してもよい[MAY]。 エンドユーザーは間違いなく確実にSIPS URIとSIP URIのあいだの違いを見分 けるだろう。そして無条件反射的にそれらをマニュアルで編集するかもしれ ない。これはセキュリティに貢献することもセキュリティを落とすこともあ り得る。例えば、攻撃者が、プロキシサーバーのすべてのSIPSレコードを 事実上削除する偽のレコードセットを挿入してDNSキャッシュを改竄する場合、 このプロキシサーバーをトラバースするすべてのSIPSリクエストは失敗する かもしれない。しかしながら、ユーザーがSIPS Address-of-Recordに対する 何度もの呼び出しが失敗しているのがわかるときは、SIPSからSIPにスキーム をマニュアルで変換する何らかのデバイス上に呼び出しが行っていて再試行 していることがあり得る。もちろんこれに対するいくつかの防護手段はあ るが(デスティネーションのUAが真に偏執的な場合はすべての非SIPSリクエス トを拒否することがあり得る)、それは注意するに値する制限事項である。 良い面をあげれば、ユーザーがSIP URIだけを提示されるときでさえも「SIPS」 を利用できることをユーザーは知るだろう。 26.5 プライバシー SIPメッセージは送信者に関する細心の注意を要する情報を含むことが多い。 それには、伝えなければならないことだけではなく、誰と通話するのか、い つどれくらいの時間通話するのか、そしてどこからセッションに参加するの かも含まれる。多くのアプリケーションとそれのユーザーは、この種のプラ イベート情報をそれを知る必要がないいかなるパーティからも隠すことを要 求する。 プライベート情報が暴かれるそれほど直接的でない方法もある、ということ に注意すること。ユーザーまたはサービスが、人名と組織の所属(これは Address-of-Recordの大部分について述べている)から推測可能なアドレスで 到達可能なことを選択する場合、リストに載っていない「電話番号」を持つ ことでプライバシーを保証する慣例的な方法は信用できない。ユーザーロケー ションサービスは、発呼側に対してセッション招待の受信者の具体的な所在を 暴露することで、セッション招待の受信者のプライバシーを侵害することがあ り得る。したがって実装は各ユーザーごとに、どの種類の場所と有効性の情報 が特定のクラスの発信者に渡されるかを制限することができるべきである [SHOULD]。これが、継続中のSIPワークで調査されることが期待されている問題 のすべてのクラスである。 ときとしてユーザーは、アイデンティティを運ぶヘッダーフィールド中の情 報を秘密にすることを望むかもしれない。これはリクエストの発信元を表す Fromおよび関連するヘッダーだけに適用するのではなく、Toにも適用できる。 スピードダイヤルのニックネームやターゲットグループのための展開されて いない識別子(unexpanded identifier)を最終デスティネーションに伝えるこ とは適切でないかもしれず、リクエストがルートされるときにいずれかが Request-URIから削除されるだろう。しかし、その2つが最初に同じであれば、 Rosenberg, et. al. Standards Track [Page 251] RFC 3261 SIP: Session Initiation Protocol June 2002 Toヘッダーフィールドでは変更されない。したがって、Request-URIと異なる Toヘッダーフィールドを生成することがプライバシー保護のために望ましい かもしれない[MAY]。 27 IANA条項 SIPアプリケーションで使用されるすべてのメソッド名、ヘッダーフィールド 名、ステータスコード、およびオプションタグは、RFCのIANA条項のセクショ ンの指示にしたがってIANAに登録される。 仕様は、IANAがhttp://www.iana.org/assignments/sip-parametersの下に4つ の新規サブレジストリを生成することを指示する。その4つとは、そこに既に 存在するヘッダーフィールドのサブレジストリに追加される、オプションタ グ(Option Tags)、警告コード(Warning Codes (warn-codes))、メソッド (Methods)、および応答コード(Response Codes)である。 27.1 オプションタグ この仕様はhttp://www.iana.org/assignments/sip-parametersの下にオプショ ンタグ(Option Tags)サブレジストリを制定する。 オプションタグは、拡張に対するSIP互換性の仕組みをサポートするために、 Require、Supported、Proxy-Require、およびUnsupportedのようなヘッダー フィールドで使用される(セクション19.2参照)。オプションタグ自体は、特 定のSIPオプション(すなわち、拡張)に関連付けられた文字列である。それは SIPエンドポイントに対するオプションを特定する。 オプションタグはstandards track RFCで発表されたときにIANAによって登録 される。RFCのIANA条項のセクションは、発表されたRFCの番号と共に、IANA レジストリに現れる以下の情報を含まなければならない。 o オプションタグの名称。名称はどのような長さでもよい[MAY]が、20 文字以下であるべきである[SHOULD]。名称はalphanum文字(セクショ ン25参照)のみから成らなければならない[MUST]。 o 拡張を説明する説明文。 27.2 警告コード(Warn-Code) この仕様はhttp://www.iana.org/assignments/sip-parametersの下に警告コー ド(Warn-codes)サブレジストリを制定し、セクション20.43にリストされてい るwarn-codesをそれに追加し始める。さらなるwarn-codesはRFC刊行物によって 登録される。 Rosenberg, et. al. Standards Track [Page 252] RFC 3261 SIP: Session Initiation Protocol June 2002 warn-codesの表のための説明文は以下のようである。 警告コードは、トランザクションの失敗がセッション記述プロトコル(SDP)( RFC2327 参考文献[1])の問題に起因するとき、SIP応答メッセージのステータ スコードを補足する情報を提供する。 「warn-code」は3桁から成る。最初の桁である3はSIP固有の警告を示す。 将来の仕様が3xx以外のwarn-codesの使用を記述するまで、3xx warn-codes だけを登録できる。 警告の300から329はセッション記述のキーワードの問題を示すために予約さ れている。330から339はセッション記述で要求された基本的なネットワーク サービスに関係する警告。370から379はセッション記述で要求された定量的 なQoSパラメータに関係する警告。そして、390から399は上記のカテゴリに当 てはまらないその他の警告である。 27.3 ヘッダーフィールド名 このセクションは、http://www.iana.org/assignments/sip-parameters にある、ヘッダーの下位登録に関するIANAの指示を廃止(obsolete)する。 新規ヘッダーフィールド名を登録するために、以下の情報がRFC文書で提供さ れる必要がある。 o ヘッダーが登録されるRFC番号 o 登録されることになるヘッダーフィールド名 o 定義されていれば、そのヘッダーフィールドの短縮形 いくつかの一般的で広く使用されているヘッダーフィールドは、一文字の短縮 形に割り当ててもよい[MAY](セクション7.3.3)。短縮形はSIPワーキンググルー プのレビュー後にのみ割り当てでき、その後にRFCが発行される。 27.4 メソッドと応答コード この仕様は、http://www.iana.org/assignments/sip-parametersの下にメソッ ド(Method)と応答コード(Response-Code)サブレジストリを制定し、以下のよう にそれの定義を開始する。当初のメソッドの表は以下のとおりである。 Rosenberg, et. al. Standards Track [Page 253] RFC 3261 SIP: Session Initiation Protocol June 2002 INVITE [RFC3261] ACK [RFC3261] BYE [RFC3261] CANCEL [RFC3261] REGISTER [RFC3261] OPTIONS [RFC3261] INFO [RFC2976] 応答コードの表は当初セクション21の、通知(Informational)、成功(Success)、 リダイレクト(Redirection)、クライアントエラー(Client-Error)、サーバー エラー(Server-Error)、およびグローバル失敗(Global-Failure)が使用され る。表は以下の形式をもつ。 タイプ(例: Informational) 番号 デフォルトの理由フレーズ [RFC3261] 新規応答コードまたはメソッドを登録するために、以下の情報がRFC文書で提 供される必要がある。 o メソッドまたは応答コードが登録されるRFC番号 o 登録されることになる応答コード番号またはメソッド名 o 必要に応じて、応答コードに対するデフォルトの理由フレーズ 27.5 「message/sip」MIMEタイプ このドキュメントでは、SIPメッセージがSIP内のボディとしてトンネルされ ることを許可するために「message/sip」MIMEメディアタイプを登録する。こ れは主としてエンドツーエンドの安全のためである。このメディアタイプは 以下の情報で定義される。 メディアタイプ名: メッセージ メディアサブタイプ名: sip 必要なパラメータ: なし オプションのパラメータ: バージョン バージョン: 同封されたメッセージのSIPバージョン番号(例: "2.0")。 存在しない場合、バージョンはデフォルトとして"2.0"になる。 エンコードスキーム: 8ビットのヘッダーからなるSIPメッセージ。オプショ ンとしてバイナリのMIMEオブジェクトがそれに続く。そのときは、SIP メッセージはバイナリとして処理されなければならない。通常の状態 では、SIPメッセージはバイナリデータの送信が可能なトランスポートで 運ばれ、特別なエンコードは必要とされない。 Rosenberg, et. al. Standards Track [Page 254] RFC 3261 SIP: Session Initiation Protocol June 2002 セキュリティの考慮: 下記参照 S/MIMEと協調したセキュリティの仕組みとしての、これの用法の モチベーションと例は23.4で与えられている。 27.6 新規Content-Dispositionパラメータの登録 このドキュメントではContent-Dispositionヘッダーの4つの新しい 「disposition-types」も登録する。その4つとは、alert、icon、session、 およびrenderである。これらの値がIANAレジストリでContent-Dispositionの ために記録されることを著者は要求する。 モチベーションと例を含め、これらの「disposition-types」の説明は、セク ション20.11で与えられている。 以下は、IANAレジストリにふさわしい簡単な説明である。 alert ボディはユーザーに注意を喚起するためのカスタムの呼び出し音 である icon ボディはユーザーにアイコンとして表示される render ボディはユーザーに表示されるべきである session ボディは、例えばRFC2327のSDPボディと同様に、コミュニ ケーションセッションを記述する 28 RFC2543からの変更点 このRFCはRFC2543を改訂する。大部分はRFC2543との下位互換を保っている。 ここで述べられている変更点は、RFC2543で発見された多くのエラーを修正し、 RFC2543で詳述されていないケースについての情報を提供する。プロトコルは ここでは、さらにはっきりとしたレイヤーモデルで提示されている。 われわれは相違点を、場合によっては相互運用性や正確な操作に影響を与え るRFC2543からの重要な変更である機能的動作と、RFC2543とは異なるが相互 運用性の問題が発生する原因にならない機能的動作、に分割する。その上、 ここでは文章化されていない、数え切れないほどの説明もあった。 28.1 重要な機能変更 o 相手が呼び出しに答える前にその呼の切断をUACが望むときは、CANCEL を送る。オリジナルのINVITEが依然として2xxを送る場合、UACはそれ からBYEを送る。BYEは、RFC2543ではいつでも送ることができたのに 対して、既存のコールレグ(このRFCではダイアログと呼ぶようになっ た)上でのみ送ることができる。 o SIPのBNFは、RFC2234に準拠するように変換された。 Rosenberg, et. al. Standards Track [Page 255] RFC 3261 SIP: Session Initiation Protocol June 2002 o SIP URL(※)のBNFは、ユーザー部分でさらに大きな文字セットを許可 するように、より一般化された。さらに、比較ルールがおもに大文字 小文字を区別しないように単純化され、パラメータが存在するときの 比較操作が詳述された。もっとも重要な変更は、初期値を持つパラ メータを含むURIが、そのパラメータを持たないURIにマッチしない ことである。 [※訳注: SIP URL は原文のまま。] o Viaの隠蔽を削除した。不明瞭にする処理を実行するためにネクスト ホップに頼っていたので、それは重大な信用問題(trust issue)を抱 えていた。その代わりに、Viaの隠蔽は、ステートフルプロキでロー カルの実装の選択で行うことができる。そのため、記述されなくなっ た。 o RFC2543では、CANCELトランザクションとINVITEトランザクションが 混ざり合っていた。それらは分割された。ユーザーがINVITEを送り、 次いでCANCELを送るとき、それでもINVITEトランザクションは正常に 終了する。UASはオリジナルのINVITEリクエストに対して487応答で応 答する必要がある。 o 同様に、CANCELトランザクションとBYEトランザクションも混ざり合 っていた。RFC2543は、UASがBYEを受け取ったときはINVITEに対して 応答を送らないことを認めていた。ここではそれは認められない。オ リジナルのINVITEは応答を必要とする。 o RFC2543では、UAはUDPをサポートすることだけが必要とされていた。 このRFCでは、UAはUDPとTCPをサポートすることを必要とされる。 o RFC2543では、フォークを行うプロキシは、複数のチャレンジがある 場合にはダウンストリームエレメントからひとつのチャレンジだけを 渡されていた。このRFCでは、プロキシはすべてのチャレンジを収集 して、それらを転送(forward)された応答に入れることになっている。 o ダイジェスト認証の信用証明書では、URIは引用符に囲まれている必 要がある。これはRFC2617とRFC2069では双方共に一貫性がないので、 それらからははっきりわからない。 o SDP処理は別の仕様(参考文献[13])に分割され、SIPを介して有効にト ンネルされる、正式なオファー/アンサー交換処理として、さらに完 全に規定された。SDPは、ベースラインSIP実装でINVITE/200または 200/ACKに対して認められる。RFC2543はSDPを、ひとつのトランザク ション中のINVITE、200、およびACKで使用する能力をほのめかしてい たが、うまく規定されていなかった。より複雑なSDPの用法が拡張で 認められる。 Rosenberg, et. al. Standards Track [Page 256] RFC 3261 SIP: Session Initiation Protocol June 2002 o URIおよびViaヘッダーフィールドでのIPv6の完全なサポートを追加し た。ViaでのIPv6のサポートは、Viaヘッダーフィールドのパラメータ が角括弧とコロンを許可することを要求した。これらの文字は以前は 許可されていなかった。理論上これは、古い実装との間に相互運用性 の問題を生ずる。しかしながら、ほとんどの実装は、これらのパラメー タ中ですべてのASCIIの非コントロール文字を受け入れることが観測さ れた。 o DNSのSRV手順が別の仕様(参考文献[4])に文書化された。この手順は SRVとNAPTRリソースレコードの双方を使用し、もはやRFC2543で述べ られているようにはSRVからのデータを結合しない。 o Max-Forwardsの使用を必須にすることで、ループ検知がオプションに なった。RFC2543のループ検知手順には、エラーでないときにスパイ ラルをエラー状態であると報告するであろう重大なバグがあった。オ プションのループ検知手順はさらに完全にそして正確にここで規定さ れた。 o 今ではタグはダイアログ識別の基本的な要素なので、タグの使用が必 須になった(RFC2543ではタグはオプションだった)。 o クライアントがどの拡張をサポートするかをサーバーに示すことを可 能にする、Supportedヘッダーフィールドを追加した。サーバーはそ れらの拡張を応答に適用し、応答のRequireでそれらの使用法を示す。 o いくつかのヘッダーフィールドのBNFから拡張パラメータが欠落して いたので、それらが追加された。 o RouteとRecord-Routeの構築操作は、RFC2543では明確さがまったく足 りず、アプローチも正しくなかった。それはこの仕様で、かなり書き 直された(また非常に単純化された)。これはおそらく間違いなく最大 の変更点である。最初のリクエストがRecord-Routeの外で何らかの方 法で取得したRouteヘッダーフィールド値のセットを持つ「あらかじ めロードされたルート(pre-loaded routes)」を使用しない配備のた めに、下位互換性が依然として提供される。それらの状況では、新し い仕組みは相互運用可能ではない。 o RFC2543では、メッセージの行はCR、LF、あるいはCRLFで区切ること ができた。この仕様ではCRLFだけを許可する。 Rosenberg, et. al. Standards Track [Page 257] RFC 3261 SIP: Session Initiation Protocol June 2002 o CANCELとACKでのRouteの使用はRFC2543ではよく定義されていなかっ た。それがしっかりと規定された。リクエストがRouteヘッダーフィー ルドを持っていた場合、そのリクエストへの非2xx応答に対する CANCELまたはACKは同じRouteヘッダーフィールド値を伝える必要があ る。2xx応答に対するACKは、その2xx応答のRecord-Routeから知った Route値を使用する。 o RFC2543はひとつのUDPパケットで複数のリクエストを認めていた。こ の用法は削除された。 o Expiresヘッダーフィールドとパラメータでの絶対時間の用法は削除 された。それは、時間が同期されていない(これは一般的に起こる)エ レメントで相互運用性の問題を生じていた。その代わりに相対時間が 使用される。 o Viaヘッダーフィールド値のbranchパラメータは、すべてのエレメン トで使用することが必須になった。それは今では一意なトランザクショ ン識別子の役割を演じる。これは、RFC2543からの複雑でバグを抱 えたトランザクション識別ルールを回避する。前のホップがそのパラ メータをグローバルに一意にしたかどうかを確定するために、パラメー タ値でマジッククッキーが使用され、それが存在しないときは比較 は古いルールに戻る。したがって、相互運用性が保障される。 o RFC2543では、TCP接続のクローズはCANCELと等価であるとされてい た。これはプロキシ間のTCPコネクションに対しては、実装がほとんど 不可能(そして間違い)だった。これは、TCP接続のステートとSIP処理 の間につながりがないので、撤廃された。 o RFC2543は、UAが別のトランザクションが進行中に新しいトランザク ションを開始できるかどうかについて触れていなかった。それがここ で規定された。それは非INVITEリクエストでは許可され、INVITEでは 却下される。 o PGPが削除された。それは十分に規定されていなかった。また、さら に完成されたPGP MIMEと互換性がなかった。それはS/MIMEで置き換え られた。 o エンドツーエンドのTLSのために「sips」URIスキームが追加された。 このスキームはRFC2543と下位互換がない。Request-URI中にSIPS URI を持つリクエストを受け取る既存のエレメントは、おそらくそのリク エストを拒否するだろう。これは実際のところ機能(feature)である と言える。つまりそれは、SIPS URIに対する呼がパスのすべてのホッ プが安全確保されている場合にのみ配送されることを保障する。 Rosenberg, et. al. Standards Track [Page 258] RFC 3261 SIP: Session Initiation Protocol June 2002 o 追加のセキュリティ機能がTLSと共に追加された。これらについては、 さらに長く完成されたセキュリティの考慮セクションで述べられてい る。 o RFC2543では、アップストリームに101から199までの暫定応答を転送 (forward)するためにプロキシは要求されなかった。これはMUSTに変更 された。それ以降の多くの機能は101から199までのすべての暫定応答の 配送に依存するので、これは重要である。 o RFC2543では503応答コードについてほとんど語られていなかった。そ れは、プロキシにおいて失敗あるいは過負荷状態を示す重要な用途が あることがわかった。これは何らかの特別な扱いを必要とする。具体 的には、503の受信は、DNSのSRVルックアップの結果である次のエレ メントにコンタクトを試みるトリガーになるべきである。また、503 応答は特定の状況下でのみプロキシによってアップストリームに転送 (forward)される。 o RFC2543は、サーバーのUA認証の仕組みについて、十分に明らかに しなかったが、定義した。それは削除された。その代わりに、RFC2617 の相互認証が認められた。 o UAは、最初のINVITEに対するACKを受け取るまで、呼に対してBYEを送 れない。潜在的な競合状態(race condition)に導くが、これはRFC2543 では許可されていた。 o UAまたはプロキシは、リクエストに対する暫定応答を受け取るまで、 トランザクションに対してCANCELを送れない。潜在的な競合状態 (race condition)に導くが、これはRFC2543では許可されていた。 o 登録におけるactionパラメータは反対された。それはいかなる有用な サービスに対しても不適当で、アプリケーション処理がプロキシで適 用されたときにコンフリクトを生じた。 o RFC2543はマルチキャストに対して多数の特別ケースを持っていた。 例えば、特定の応答が抑制されたり、タイマーが調整されたりする などである。マルチキャストはより限定された役割を演じるようにな った。そして、プロトコル操作は、ユニキャストとは対照的にマルチ キャストの用法には影響されない。その結果としての制限事項が記述 された。 o 基本認証は完全に削除され、それの使用は禁止された。 Rosenberg, et. al. Standards Track [Page 259] RFC 3261 SIP: Session Initiation Protocol June 2002 o プロキシはもはや6xxを受信したときにそれを即座に転送(forward)しな い。その代わりに、ペンディング中のbranchを即座にCANCELする。こ れは、2xxが後に続く6xxをUACが受け取ることになる潜在的な競合状 態を回避する。この競合状態を除くすべての場合において、結果は同 じになる。つまり、6xxがアップストリームに転送(forward)される。 o RFC2543はリクエストのマージの問題を解決しなかった。これは、リ クエストがプロキシでフォークして、後にひとつのエレメントで再び 一緒になったときに起こる。マージの操作はUAでのみ行われ、 手順は最初のリクエスト以外はすべて拒否するように定義された。 28.2 軽微な機能変更 o ユーザーに対してオプションのコンテンツを提示するために、 Alert-Info、Error-Info、およびCall-Infoヘッダーフィールドが追 加された。 o Content-Language、Content-Disposition、およびMIME-Versionヘッ ダーフィールドが追加された。 o 両方のパーティーがお互いに同時にre-INVITEを送る場合に対処する ために「グレア操作(glare handling)」の仕組みが追加された。これ は新しい491(Request Pending)エラーコードを使用する。 o 受け取れなかった電話またはメッセージに後ほど折り返すことをサポー トするために、In-Reply-ToおよびReply-Toヘッダーフィールドが 追加された。 o 有効なSIPトランスポートとして、TLSおよびSCTPが追加された。 o 通話中に失敗をいつでも操作するために、さまざまな仕組みが記述さ れていた。それらが全般的に統一された。終了するためにBYEが送ら れる。 o RFC2543は、INVITEに対する応答の再送をTCP上で義務化していたが、 それは2xxに対してだけ必要であったことに気づいた。それは不十分 なプロトコルのレイヤー化の結果であった。ここで定義された、さら に首尾一貫したトランザクションレイヤーによって、それはもはや不 要になった。INVITEに対する2xx応答だけがTCP上で再送される。 o クライアントトランザクションマシンとサーバートランザクションマ シンは、再送カウントではなくタイムアウトに基づいて駆動するよう になった。これは、ステートマシンがTCPとUDPに対して適切に規定さ れることを可能にする。 o Dateヘッダーフィールドは、ユーザーエージェントの日付を自動設定 するための単純な手段を提供するために、REGISTERに対する応答で使 用される。 o 登録サーバーが、短すぎる期間の有効期限を持つ登録を拒否すること を許可した。423応答コードとMin-Expiresをこの目的のために定義し た。 Rosenberg, et. al. Standards Track [Page 260] RFC 3261 SIP: Session Initiation Protocol June 2002 29 規範的な参考文献 [1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [4] Rosenberg, J. and H. Schulzrinne, "SIP: Locating SIP Servers", RFC 3263, June 2002. [5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002. [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [9] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000. [10] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [11] Freed, F. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [12] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with SDP", RFC 3264, June 2002. [14] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [15] Postel, J., "DoD Standard Transmission Control Protocol", RFC 761, January 1980. Rosenberg, et. al. Standards Track [Page 261] RFC 3261 SIP: Session Initiation Protocol June 2002 [16] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [17] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [18] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. [19] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, December 2001. [20] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [21] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [22] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. [23] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. [24] Ramsdell B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [25] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [26] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. 30 有益な参考文献 [27] R. Pandya, "Emerging mobile and personal communication systems," IEEE Communications Magazine, Vol. 33, pp. 44--52, June 1995. [28] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. Rosenberg, et. al. Standards Track [Page 262] RFC 3261 SIP: Session Initiation Protocol June 2002 [29] Schulzrinne, H., Rao, R. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [30] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November 2000. [31] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [32] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998. [33] E. M. Schooler, "A multicast user directory service for synchronous rendezvous," Master's Thesis CS-TR-96-18, Department of Computer Science, California Institute of Technology, Pasadena, California, Aug. 1996. [34] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [35] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [36] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998. [37] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000. [38] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997. [39] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: Digest Access Authentication", RFC 2069, January 1997. [40] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., Willis, D., Rosenberg, J., Summers, K. and H. Schulzrinne, "SIP Call Flow Examples", Work in Progress. [41] E. M. Schooler, "Case study: multimedia conference control in a packet-switched teleconferencing system," Journal of Internetworking: Research and Experience, Vol. 4, pp. 99--120, June 1993. ISI reprint series ISI/RS-93-359. Rosenberg, et. al. Standards Track [Page 263] RFC 3261 SIP: Session Initiation Protocol June 2002 [42] H. Schulzrinne, "Personal mobility for multimedia services in the Internet," in European Workshop on Interactive Distributed Multimedia Systems and Services (IDMS), (Berlin, Germany), Mar. 1996. [43] Floyd, S., "Congestion Control Principles", RFC 2914, September 2000. Rosenberg, et. al. Standards Track [Page 264] RFC 3261 SIP: Session Initiation Protocol June 2002 A タイマー値の表 表4は、この仕様で使用されている各種タイマーの意味と初期値をまとめたも のである。 タイマー 値 セクション 意味 __________________________________________________________________________ T1 500ms default セクション17.1.1.1 RTT予測値 T2 4s セクション17.1.2.2 非INVITEリクエストおよび INVITEに対する応答のための 最大再送間隔 T4 5s セクション17.1.2.2 メッセージがネットワーク上 に残存する最大期間 Timer A initially T1 セクション17.1.1.2 UDPだけのためのINVITEリクエ ストの再送間隔 Timer B 64*T1 セクション17.1.1.2 INVITEトランザクションの タイムアウトタイマー Timer C > 3min セクション16.6の プロキシのINVITEトランザクション 項目11 のタイムアウト Timer D > 32s for UDP セクション17.1.1.2 応答の再送のための待ち時間 0s for TCP/SCTP Timer E initially T1 セクション17.1.2.2 UDPだけのための非INVITEリク エストの再送間隔 Timer F 64*T1 セクション17.1.2.2 非INVITEトランザクションの タイムアウトタイマー Timer G initially T1 セクション17.2.1 INVITEに対する応答の 再送間隔 Timer H 64*T1 セクション17.2.1 ACK受信のための待ち時間 Timer I T4 for UDP セクション17.2.1 ACK再送のための待ち時間 0s for TCP/SCTP Timer J 64*T1 for UDP セクション17.2.2 非INVITEリクエストの再送 0s for TCP/SCTP のための待ち時間 Timer K T4 for UDP セクション17.1.2.2 応答の再送のための待ち時間 0s for TCP/SCTP 表4: タイマーのまとめ Rosenberg, et. al. Standards Track [Page 265] RFC 3261 SIP: Session Initiation Protocol June 2002 謝辞 コメントと提案をいただいた、IETF MMUSICおよびSIPワーキンググループの メンバーに感謝したい。詳細なコメントは、Ofir Arkin、Brian Bidulock、 Jim Buller、Neil Deason、Dave Devanathan、Keith Drage、Bill Fenner、 Cedric Fluckiger、Yaron Goland、John Hearty、Bernie Hoeneisen、Jo Hornsby、Phil Hoffer、Christian Huitema、Hisham Khartabil、Jean Jervis、 Gadi Karmi、Peter Kjellerstedt、Anders Kristensen、Jonathan Lennox、 Gethin Liddell、Allison Mankin、William Marshall、Rohan Mahy、Keith Moore、Vern Paxson、Bob Penfield、Moshe J. Sambol、Chip Sharp、Igor Slepchin、Eric Tremblay、Rick Workmanらが提供してくれた。 Brian Rosenは編纂したBNFを提供してくれた。 Jean Mahoneyはテクニカルライティングの支援をしてくれた。 この作業は、特に参考文献[41,42]を基にしている。 Rosenberg, et. al. Standards Track [Page 266] RFC 3261 SIP: Session Initiation Protocol June 2002 著者の連絡先 著者の連絡先は、エディター、ライター、RFC2543のオリジナルの著者の順で、 アルファベット順にリストされている。リストされているすべての著者は、 このドキュメントに大量の文書を積極的に寄稿してくれた。 Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave East Hanover, NJ 07936 USA EMail: jdrosen@dynamicsoft.com Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA EMail: schulzrinne@cs.columbia.edu Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland EMail: Gonzalo.Camarillo@ericsson.com Alan Johnston WorldCom 100 South 4th Street St. Louis, MO 63102 USA EMail: alan.johnston@wcom.com Rosenberg, et. al. Standards Track [Page 267] RFC 3261 SIP: Session Initiation Protocol June 2002 Jon Peterson NeuStar, Inc 1800 Sutter Street, Suite 570 Concord, CA 94520 USA EMail: jon.peterson@neustar.com Robert Sparks dynamicsoft, Inc. 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024 USA EMail: rsparks@dynamicsoft.com Mark Handley International Computer Science Institute 1947 Center St, Suite 600 Berkeley, CA 94704 USA EMail: mjh@icir.org Eve Schooler AT&T Labs-Research 75 Willow Road Menlo Park, CA 94025 USA EMail: schooler@research.att.com Rosenberg, et. al. Standards Track [Page 268] RFC 3261 SIP: Session Initiation Protocol June 2002 完全な著作権表記 Copyright (c) The Internet Society (2002). All Rights Reserved. 本記述とその翻訳は複写し他に提供することができる。また論評を加えた派 生的製品や、この文書を説明したり、その実装を補助するもので、上記の著 作権表示およびこの節を付加するものはすべて、全体であってもその一部で あっても、いっさいの制約を課されること無く、準備、複製、発表、配布す ることができる。しかし、この文書自体にはいかなる方法にせよ、著作権表 示やインターネットソサエティもしくは他のインターネット関連団体への参 照を取り除くなどの変更を加えてはならない。インターネット標準を開発す るために必要な場合は例外とされるが、その場合はインターネット標準化過 程で定義されている著作権のための手続きに従わなければならない。またRFC を英語以外の言語に翻訳する必要がある場合も例外である。 以上に述べられた制限は永久的なものであり、インターネットソサエティも しくはその継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ トソサエティおよびIETFは、この情報がいかなる権利も侵害していないとい う保証、商用利用および特定目的への適合性への保証を含め、また、これら だけに限らずすべての保証について、明示的もしくは暗黙的の保証は行われ ない。 謝辞 RFC編集者の職務のための資金は、現在、インターネットソサエティによって 提供されている。 --------------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただし、 この権利の設定は原文から新たな翻訳を作成し公開することを妨げるものではあり ません。本翻訳物は、本著作権表示を含めて改変しないことを条件に再配布を許可 します。翻訳の正確さについては一切保証しません。原文とあわせてご利用くだ さい。 2004年 --------------------------------------------------------------------------- Rosenberg, et. al. Standards Track [Page 269]