Network Working Group H. Schulzrinne Request for Comments: 4412 Columbia U. Category: Standards Track J. Polk Cisco Systems February 2006 セッション開始プロトコル(SIP)の 通信リソース優先度 Communications Resource Priority for the Session Initiation Protocol (SIP) 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準ト ラックプロトコルを規定するものであり、改善のための議論や提案を依頼す るものである。標準化の段階や、プロトコルの位置付けについては、最新版 の"Internet Official Protocol Standards" (STD 1)を参照されたい。この 文書の配信は無制限である。 著作権表記 Copyright (C) The Internet Society (2006). 概要 本文書は、リソースの優先度を通信するための2つの新規セッション開始プロ トコル(Session Initiation Protocol/SIP)ヘッダーフィールド、 「Resource-Priority」と「Accept-Resource-Priority」を定義する。 「Resource-Priority」ヘッダーフィールドは、SIPユーザーエージェント (電話ゲートウェイやIP電話など)とSIPプロキシの動作に影響を与える可能 性がある。IPルーターの転送動作に直接影響を及ぼすことはない。 目次 1. はじめに ....................................................... 3 2. 用語 ........................................................... 6 3. Resource-PriorityとAccept-Resource-Priorityの SIPヘッダーフィールド ......................................... 6 3.1. 「Resource-Priority」ヘッダーフィールド ................... 6 3.2. 「Accept-Resource-Priority」ヘッダーフィールド ........... 8 3.3. 「Resource-Priority」と「Accept-Resource-Priority」 の使用方法 ............................................... 8 3.4. 「resource-priority」オプションタグ ....................... 9 4. 優先順位を付けたリクエストを受信するSIP要素の動作 ............. 9 4.1. はじめに ................................................. 9 4.2. 一般規則 ................................................. 9 4.3. Resource-Priorityが指定されたRequireヘッダーの使用方法 .. 10 4.4. Resource-Priorityが指定されたOPTIONSリクエスト .......... 10 Schulzrinne & Polk Standards Track [Page 1] RFC 4412 SIP Resource Priority February 2006 4.5. リクエストの優先的取り扱いのアプローチ .................. 11 4.5.1. 先取 ................................................ 11 4.5.2. 優先順位のキュー処理 ................................ 12 4.6. エラー条件 .............................................. 12 4.6.1. はじめに ............................................ 12 4.6.2. 未知の名前空間または優先順位 ........................ 13 4.6.3. 認証エラー .......................................... 13 4.6.4. 認可エラー .......................................... 14 4.6.5. リソース不足 ........................................ 14 4.6.6. ビジー .............................................. 14 4.7. 要素固有の動作 .......................................... 15 4.7.1. ユーザーエージェントクライアントの動作 .............. 15 4.7.2. ユーザーエージェントサーバーの動作 .................. 15 4.7.3. プロキシの動作 ...................................... 16 5. サードパーティの認証 .......................................... 17 6. 下位互換性 .................................................... 17 7. 例 ............................................................ 17 7.1. 単純な通話 .............................................. 18 7.2. 受信側が名前空間を理解しない ............................ 19 8. 複数が平行する名前空間の処理 .................................. 21 8.1. 一般規則 ................................................ 21 8.2. 有効な順序処理の例 ...................................... 21 8.3. 無効な順序処理の例 ...................................... 22 9. 名前空間の登録 ................................................ 23 10. 名前空間の定義 .............................................. 24 10.1. はじめに ................................................ 24 10.2. 「DSN」名前空間 ........................................ 24 10.3. 「DRSN」名前空間 ........................................ 25 10.4. 「Q735」名前空間 ........................................ 25 10.5. 「ETS」名前空間 ........................................ 26 10.6. 「WPS」名前空間 ........................................ 26 11. セキュリティの考慮事項 ...................................... 27 11.1. 一般的な注意 ............................................ 27 11.2. 認証と認可 .............................................. 27 11.3. 機密性と完全性 .......................................... 28 11.4. 匿名性 .................................................. 29 11.5. DoS攻撃 ................................................ 29 12. IANA条項 .................................................... 30 12.1. はじめに ................................................ 30 12.2. 「Resource-Priority」と「Accept-Resource-Priority」 ヘッダーフィールドのIANA登録 ............................ 30 12.3. オプションタグresource-priorityのIANA登録 .............. 31 12.4. 応答コード417のIANA登録 ................................ 31 12.5. IANA Resource-Priority名前空間の登録 .................... 31 12.6. IANA Priority-Valueの登録 .............................. 32 13. 謝辞 ........................................................ 32 14. 参考文献 .................................................... 33 Schulzrinne & Polk Standards Track [Page 2] RFC 4412 SIP Resource Priority February 2006 1. はじめに 緊急時、通信リソース(電話回路、IP帯域、回路交換ネットワークとIPネット ワーク間のゲートウェイなど)が輻輳状態になる場合がある。使用量が多い場 合、自然災害や人災でリソースの損失が発生した場合、人が引き起こした緊 急時にネットワークに対して攻撃があったときに、輻輳が発生する可能性が ある。この輻輳によって、緊急時の援助、回復、法律の実施にあたる個人 が、作業を調整することが困難になる。IPネットワークが、パブリックおよ びプライベートの回路交換(電話)ネットワークと共に、集中型ネットワーク またはハイブリッド型ネットワークの一部になるとき、このような緊急時で もネットワークが補助できるようにすることが必要である。 また、高い優先度の通信リクエストがエンドシステムに到達した場合、ユー ザーは低い優先度の通信アクティビティを中断し、エンドシステムのリソー スを高い優先度の通信試行に専用とすることができる。 緊急時に援助するIPベースのサービスは多数ある。本文書は、セッション開 始プロトコル(Session Initiation Protocol/SIP) [RFC3261]を伴うリアル タイム通信アプリケーションのみを対象にしている。たとえば、Voice-over- IP、マルチメディアカンファレンス、インスタントメッセージ、プレゼンス などである。 SIPアプリケーションには最低でも5つの異なるリソースを伴い、各リソース が足りなくなったり、緊急時に輻輳する可能性がある。このリソースには、 ゲートウェイリソース、回路交換ネットワークのリソース、IPネットワーク のリソース、受信がエンドシステムのリソース、SIPプロキシリソースが含 まれる。IPネットワークリソースはSIPシグナリングの範囲外なので、本文 書の対象外である。 SIP要素のリソースが乏しい場合でなくても、SIPゲートウェイは、進行中の 通話に優先度の印を付けてもうよい。たとえば、公衆交換電話網(PSTN)を使 用して、SIPゲートウェイが開始したISUP (ISDN User Part) IAM (Initial Address Message)などである。 緊急時の応答を改善するには、緊急状況によるリソース不足のときに、SIP でシグナリングされたリソースへのアクセスに優先度を付ける必要がある。 これを「リソースの優先順位付け」と呼ぶ。このメカニズム自体は常に準備 が整っていても、実質的にリソース不足の際の呼処理にのみ影響がある可能 性がある。 現在、リクエスト発信者がこのようなリソースの優先付けするリクエストを 希望することをSIP要素に示すことができるメカニズムは、SIPには備わって いない。本文書はこの要件に対処するために、特定のSIPリクエストにラベ ルを付けるSIPプロトコル要素を追加する。 Schulzrinne & Polk Standards Track [Page 3] RFC 4412 SIP Resource Priority February 2006 本文書は、リソースの優先度を通信するための2つの新規SIPヘッダーフィー ルド、「Resource-Priority」と「Accept-Resource-Priority」を定義する。 「Resource-Priority」ヘッダーフィールドは、公衆交換電話網(Public Switched Telephone Network/PSTN)のゲートウェイと端末、SIPプロキシサー バーなどのSIPユーザーエージェントが、PSTN通話に与える優先度など、SIP リクエストの取り扱いに影響を与えるときに使用してもよい[MAY]。PSTNゲー トウェイの場合、動作はPSTNの類似スキームに変換される。たとえば、PSTN からIP方向とIPからPSTN方向の両方にITU勧告Q.735.3 [Q.735.3]の優先順位 決定メカニズムを使用するなどである。別の例としてITU勧告I.255.3 [I.255.3]も上げられる。 「Resource-Priority」が指定されたSIPリクエストは、次のような場合に異 なる扱いがされる可能性がある。 1. 中継回線などでリクエストがPSTNゲートウェイのリソースにアクセスす る優先度を上げることができる。 2. IP電話などのユーザー端末で、優先度が低いリクエストを高いリクエス トが割り込むことができる。 3. リクエストは、(Q.735.3 [Q.735.3]の設備などを使用する)電話網にある 1つのマルチレベル優先ドメインから、別のドメインへ情報を伝達するこ とができる。このとき、SIPプロキシがヘッダーフィールドを検査または 修正することはない。 4. SIPプロキシとバックトゥバックユーザーエージェントでは、高い優先 順位のリクエストが既存のシグナリングリクエストに取って代わる場 合や、低い優先度のときにPSTNゲートウェイの容量制限を迂回する場合 がある。 このヘッダーフィールドはPriorityヘッダーフィールド([RFC3261]、セク ション20.26)と関連性はあるがセマンティクスは異なる。Priorityヘッダー フィールドは、受信ユーザーまたは受信ユーザーエージェントにとってSIP リクエストが持つ重要度について記述する。たとえば、Priorityヘッダー フィールドは、モバイル機器やアシスタントへの呼ルーティングに関する 決定、および呼の受け入れに関する決定に組み込まれる可能性がある。たと えば、PriorityヘッダーフィールドはPSTNゲートウェイまたはプロキシリ ソースの使用に影響を与えない。さらに、ユーザーエージェントクライアン ト(UAC)は、任意の「Priority」値をアサートすることができ、「Resource- Priority」ヘッダーフィールド値の使用は認可を前提としている。 「Resource-Priority」ヘッダーフィールドは、パケットの転送優先順位な ど、IPルーターの転送動作や通信リソースの使用方法に直接影響を与えるこ とはないが、こうした影響を引き起こすためにResource-Priorityヘッダー フィールドを使用する手順が他のドキュメントで定義される可能性がある。 Schulzrinne & Polk Standards Track [Page 4] RFC 4412 SIP Resource Priority February 2006 リソース優先順位決定メカニズムに参加していない既存のRFC 3261実装は、 通常のRFC 3261セクション8.2.2の規則に従う。つまり、「UASがリクエスト のヘッダーフィールドを理解していない場合(言い換えると、ヘッダー フィールドがこの仕様またはこの仕様をサポートしている拡張で定義されて いない場合)、サーバーはヘッダーフィールドを無視し、メッセージの処理 を継続しなければならない[MUST]。」したがって、resource-priorityオプ ションタグが指定されたRequireヘッダーフィールドがリクエストに含まれ なければ、このメカニズムを使用しても、既存の実装からはまったく無視さ れる。 本文書で説明するメカニズムは、緊急電話システムで緊急時への備えとして 使用することができるが、緊急時に備えるネットワークに占める位置はごく 一部でしかない。また、緊急の用途だけに制限されるものではない。 このメカニズムの目的は、[RFC3487]の要件を満たすことである。また、すべ てのSIPおよびリアルタイム転送プロトコル(Real-Time Transport Protocol/ RTP)[RFC3550]が透過的なネットワーク([RFC3487]で定義)で機能するように 構築されている。このようなネットワークでは、すべてのネットワーク要素 およびSIPプロキシは、有効なSIPリクエストを変更せずに通過させる。この 点が重要な理由は、エッジネットワークがリソース優先度決定メカニズムを 認識しておらず、優先度決定リクエストに特殊な権限を与えないようなネッ トワークに、このメカニズムが展開されることが多くなると予想されるため である。その後、優先度決定リクエストはメカニズムを認識しているPSTN ゲートウェイまたはSIP要素群に到達する。 「Resource-Priority」ヘッダーフィールドに関して動作するSIPプロキシ とユーザーエージェント(UA)のことは、簡略化してRPアクターと呼ぶ。 「Resource-Priority」ヘッダーフィールドを伝達するリクエストとそうで はないリクエストを同じSIP要素が処理することは一般的である可能性が ある。 政府団体や標準化団体が、ネットワーク用にさまざまな優先順位決定スキー ムを開発してきた。ユーザーは、SIPクライアントを変更せずにこのような ネットワークの一部を操作して、認可済み優先順位を取得する機能を希望し ている。また、1つの呼が、異なる運営団体が実行しているSIP要素をトラ バースし、異なる優先順位決定メカニズムに従う可能性がある。こうした 優先順位にグローバルな指示はないため、多様な優先順位リスト(本文書で は名前空間と呼ぶ)から各リクエストに複数の値を含めることができる。 通常、各SIP要素は、1つの名前空間のみをサポートするが、セクション8で は複数の名前空間をサポートする必要がある場合の状況についても説明 する。 リソースへのアクセスに優先順位を付けると、サービスを拒否する機会にな るため、このような優先順位を付けたすべての呼は、標準のSIPセキュリティ (セクション11)または他の適切なメカニズムを使用した認証または認可を前 提としている。 Schulzrinne & Polk Standards Track [Page 5] RFC 4412 SIP Resource Priority February 2006 本文書は、以下のセクションから構成されている。セクション2では用語を定 義し、セクション3では新規SIPヘッダーフィールドの構文を定義し、セク ション4ではプロトコルの動作について説明する。SIPリクエストを区別して 扱う2つの主要メカニズム(つまり、割り込み(preemption)とキュー処理 (queueing))についてセクション4.5で説明する。セクション4.6ではエラー 条件について説明する。セクション4.7.1〜4.7.3では、特定のSIP要素の動 作について詳細を説明する。サードパーティ認証については、セクション5 で簡単に説明する。セクション6では、この機能が、機能をサポートしてい ない既存システムに与える影響について説明する。 呼は、複数の名前空間を備える複数の管理ドメイン、または同じ名前空間の 複数の要素をトラバースする可能性があるため、このようなすべてのドメイ ンと要素が同じ名前空間に同じアルゴリズムを適用することが強く推奨され る。そうしないと、権限を持つユーザのエンドツーエンド環境が危うくなる 可能性がある。 セクション7ではプロトコルの例を示す。セクション8では、リクエストに複 数の名前空間を含む場合、1つの要素が複数の名前空間を処理する可能性が ある場合に発生する状況について説明する。セクション9では、名前空間の 登録時に指定が必要な情報を列挙する。セクション10では、本文書で登録さ れる5つの名前空間のプロパティを定義する。セキュリティ問題はセクショ ン11で検討しているが、本文書は新規のセキュリティメカニズムを定義しな い。セクション12ではIANA条項について説明し、本文書に関連するパラメー タを登録する。 2. 用語 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」はRFC 2119のBCP 14[RFC2119]に 記載されるとおりに解釈されるべきであり、CPL準拠の実装のための実装 レベルを示すものである。 3. Resource-PriorityとAccept-Resource-PriorityのSIPヘッダーフィールド このセクションでは、「Resource-Priority」と「Accept-Resource- Priority」のSIPヘッダーフィールド構文を定義する。動作についてはセク ション4で説明する。 3.1. 「Resource-Priority」ヘッダーフィールド 「Resource-Priority」リクエストヘッダーフィールドは、「はじめに」で 説明したように、リソースへのアクセスに優先順位を付けたいときにSIPリ クエストに印を付ける。 Schulzrinne & Polk Standards Track [Page 6] RFC 4412 SIP Resource Priority February 2006 SIPダイアログまたはSIPセッション内ですべてのリクエストが「Resource- Priority」ヘッダーフィールドを使用するというプロトコルの要件はない。 ローカルの管理ポリシーによって、すべてのリクエストに「Resource- Priority」ヘッダーフィールドを含めることを必須としてもよい[MAY]。 本仕様を実装する場合、明示的なユーザーリクエストによって含めること、 またはすべてのリクエストに自動的に含めることを許可しなければならな い[MUST]。 「Resource-Priority」ヘッダーフィールドの構文を以下に示す。「token- nodot」の構文は[RFC3265]から複写した。 Resource-Priority = "Resource-Priority" HCOLON r-value *(COMMA r-value) r-value = namespace "." r-priority namespace = token-nodot r-priority = token-nodot token-nodot = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) 「Resource-Priority」ヘッダーフィールドの例を以下に示す。 Resource-Priority: dsn.flash 「Resource-Priority」ヘッダーフィールドの「r-value」パラメータは、 リクエスト発信元が希望したリソースの優先度を示す。 各リソース値(r-value)は、'namespace' '.' 'priority value'という書式 である。この値は、「namespace」トークンで識別される名前空間から引用 される。名前空間と優先順位は、ピリオドを含まないASCIIトークンで大文 字と小文字は区別しない。したがって、たとえば「dsn.flash」と 「DSN.Flash」は同等である。各名前空間には1つ以上の優先順位値がある。 名前空間と各名前空間内の優先順位値は、IANAに登録しなければならない [MUST](セクション12)。初期段階の名前空間の登録については、セクショ ン12.5で説明する。 リクエストは複数の名前空間を持つ複数の管理ドメインをトラバースする可 能性があるため、同じメッセージに複数の名前空間を列挙する機能が必要で ある。ただし、特定の名前空間が同じSIPメッセージに複数回出現してはなら ない[MUST NOT]。指定方法は、1つのヘッダーフィールド内でカンマ区切り のリストに示す場合、複数のヘッダーフィールドに示す場合、または組み合 わせる場合のいずれでも同等である。ヘッダーフィールド内の「r-values」 の順序に重要性はない。したがって、たとえば次に示す3つの断片的なヘッ ダー例は同等である。 Resource-Priority: dsn.flash, wps.3 Resource-Priority: wps.3, dsn.flash Schulzrinne & Polk Standards Track [Page 7] RFC 4412 SIP Resource Priority February 2006 Resource-Priority: wps.3 Resource-Priority: dsn.flash 3.2. 「Accept-Resource-Priority」ヘッダーフィールド 「Accept-Resource-Priority」応答ヘッダーフィールドは、SIPユーザーエー ジェントサーバーが処理するリソース値(r-values)を列挙する(これは、 リソース値が指定された呼が、十分なリソースを検出し、リソース確保に成 功するという意味ではない)。「Accept-Resource-Priority」ヘッダーフィー ルドの構文を以下に示す。 Accept-Resource-Priority = "Accept-Resource-Priority" HCOLON [r-value *(COMMA r-value)] 例を以下に示す。 Accept-Resource-Priority: dsn.flash-override, dsn.flash, dsn.immediate, dsn.priority, dsn.routine 一部の管理ドメインは、応答でドメインに関する情報を公開しすぎるような 「Accept-Resource-Priority」ヘッダーフィールドの使用を無効にすること を選択してもよい[MAY]。ただし、このような動作は推奨されない [NOT RECOMMENDED]。このヘッダーフィールドの目的はトラブルシューティ ングのためである。 3.3. 「Resource-Priority」と「Accept-Resource-Priority」の使用方法 次の表は、RFC 3261の表2 [RFC3261]の値を拡張したものである(PRACK (PRA と表記)メソッドは[RFC3262]、SUBSCRIBE (SUB)とNOTIFY (NOT)メソッド は[RFC3265]、UPDATE(UPD)メソッドは[RFC3515]、INFO (INF)メソッド は[RFC2976]、PUBLISH(PUB)メソッドは[RFC3903]に記載されている)。 ヘッダーフィールド where proxy INV ACK CAN BYE REG OPT PRA ---------------------------------------------------------------- Resource-Priority R amdr o o o o o o o Accept-Resource-Priority 200 amdr o - o o o o o Accept-Resource-Priority 417 amdr o - o o o o o ヘッダーフィールド where proxy SUB NOT UPD MSG REF INF PUB ---------------------------------------------------------------- Resource-Priority R amdr o o o o o o o Accept-Resource-Priority 200 amdr o o o o o o o Accept-Resource-Priority 417 amdr o o o o o o o Schulzrinne & Polk Standards Track [Page 8] RFC 4412 SIP Resource Priority February 2006 他のリクエストメソッドが独自の処理規則を定義する可能性がある[MAY]。 特に規定がなければ、受信者はそのようなヘッダーフィールドを無視しても よい[MAY]。 3.4. 「resource-priority」オプションタグ 本文書は、「resource-priority」オプションタグも定義する。動作について はセクション4.3で説明する。また、IANA登録はセクション12.3で説明する。 4. 優先順位を付けたリクエストを受信するSIP要素の動作 4.1. はじめに 本仕様をサポートするすべてのSIPユーザーエージェントとプロキシサーバー は、ある程度共通する動作を共有する。共有する動作についてはセクション 4.2で説明する。「resource-priority」オプションタグが「Require」ヘッ ダーフィールドにあるときの動作については、セクション4.3で説明する。 セクション4.4はOPTIONSRequireの扱いについて説明する。2つの基本的な リソース競合の解決メカニズムである先取とキュー処理については、セク ション4.5で説明する。セクション4.6では、リクエストの失敗時に発生する 状況について説明する。ユーザーエージェントクライアントとプロキシサー バーのそれぞれに固有の動作については、セクション4.7で説明する。 4.2. 一般規則 「Resource-Priority」ヘッダーフィールドは、すべてのSIPリクエストメッ セージに適用できる可能性がある。次のリクエストタイプを実装する場合、 本仕様に準拠するには、最低でもResource-Priorityヘッダーをサポートし なければならない[MUST]。 o INVITE [RFC3261] o ACK [RFC3261] o PRACK [RFC3262] o UPDATE [RFC3311] o REFER [RFC3515] 実装では、次のリクエストタイプで「Resource-Priority」ヘッダーフィー ルドをサポートすべきである[SHOULD]。 o MESSAGE [RFC3428] o SUBSCRIBE [RFC3265] o NOTIFY [RFC3265] Schulzrinne & Polk Standards Track [Page 9] RFC 4412 SIP Resource Priority February 2006 これは、すべての実装が、ここに列挙しているすべてのリクエストをサポー トする義務があるという意味ではない。 SIP要素が上記以外のリクエストで「Resource-Priority」ヘッダーフィール ドを受信した場合、[RFC3261]の規則に従って、Resource-Priorityヘッダー フィールドを無視してもよい[MAY]。 簡単に説明すると、RPアクターは優先順位が付けられたリクエストを受信す るときに、次の手順を実行する。エラー動作についてはセクション4.6で説 明する。 1. RPアクターが名前空間のいずれも認識しない場合、 「Resource-Priority」ヘッダーフィールドがない場合と同様にそのリク エストを扱う。 2. ローカルポリシーに従ってリクエストを認可し、確実に指定された優先 順位のレベルを使用するようにする。リクエストが認可されない場合は 拒否する。認可ポリシーの例については、「セキュリティの考慮事項」 (セクション11)で説明する。 3. リクエストが認可され、リソースが使用できる場合(輻輳がない場合)、 リクエストを通常どおりに処理する。リクエストが認可されていても リソースが使用できない場合(輻輳がある場合)、他の現在のセッション よりも先取するか、リクエストを優先順位キューに挿入する(セクショ ン4.5参照)。 4.3. Resource-Priorityが指定されたRequireヘッダーの使用方法 標準的なSIP動作に従い、SIPリクエストに「resource-priority」オプション タグが指定された「Require」ヘッダーフィールドを含むときに、SIPユー ザーエージェントが本文書に記載されているSIP拡張をサポートしていない 場合、420 (Bad Extension)で応答しなければならない[MUST]。また、応答 の「Unsupported」ヘッダーフィールドには「resource-priority」を含め る。 「Proxy-Require」ヘッダーフィールドに「resource-priority」オプ ションタグを使用することは推奨されない[NOT RECOMMENDED]。 4.4. Resource-Priorityが指定されたOPTIONSリクエスト 要素がメカニズムをサポートするかどうかを決定するときにOPTIONSリクエ ストを使用することができる。本仕様に準拠する実装は、すべての有効な リソース値を列挙したOPTIONS応答の「Accept-Resource-Priority」ヘッ ダーフィールドを返すべきである[SHOULD]。ただし、RPアクターを設定し て、このような値を返さないように設定したり、権限を持つリクエスト送信 者にのみ返すように設定してもよい[MAY]。 標準のSIP動作に従い、OPTIONS応答には「resource-priority」オプション タグを指定した「Supported」ヘッダーフィールドを含めなければならな い[MUST]。 Schulzrinne & Polk Standards Track [Page 10] RFC 4412 SIP Resource Priority February 2006 RFC 3261のセクション11に従って、プロキシは値がゼロの「Max-Forwards」 ヘッダーフィールドを含むリクエストを受信した場合、UACがプロキシと ユーザーエージェントサーバー両方の機能を検出できるように、OPTIONSリ クエストに応答してもよい[MAY]。 4.5. リクエストの優先的取り扱いのアプローチ SIP要素は、リソース優先順位決定メカニズムを使用して、リクエストのルー ティング、認証要件、ネットワーク容量制御の上書き、ログ処理など、多様 な動作を修正することができる。リソースの優先順位決定メカニズムは、 リクエスト自体の取り扱い、ゲートウェイで外向きのPSTN通話のマーキン グ、またはリクエストによって作成されたセッションのマーキングに影響を 与える可能性がある(本文書では、セッションと呼という用語を同じ意味で 使用しており、どちらも2つ以上のパーティ間の連続するデータストリーム のことを指す。セッションはSIPダイアログによって確立する)。 以下に、割り込み(preemption)と優先順位のキュー処理(priority queueing)と いう2つの共通するアルゴリズムを定義する。先取は、SIPリクエストで作成 されたセッションにのみ適用されるが、優先順位のキュー処理には、セッ ションとリクエスト処理のどちらも適用することができる。両方のアルゴリ ズムを同じ要素で結合できる場合があるが、本文書で説明する名前空間では 結合されない。アルゴリズムは名前スペースごとに定義することができ、 場合によっては、1つの管理ドメイン固有にすることもできる。リクエスト のルーティングやネットワーク管理制御など、他の動作は本仕様で定義して いない。 当然ながら、このメカニズム、名前空間、リソース値を理解するSIP要素の みが2つのアルゴリズムを実行することができる。セクション4.6.2.では、 RPアクターがリクエストに含まれる優先順位値を理解していない場合に発生 する状況について説明している。 4.5.1. 先取 先取ポリシーに従うRPアクターは、既存セッションを分離して、高い優先順 位の受信セッションが入る余裕を作ることができる。セッションに必要な帯 域量や回路数を変える必要があるときに、1つの高い優先順位のセッション が、複数低い優先順位のセッションを置き換えることができる。特記がなけ れば、優先順位が同じリクエストを他のリクエストが先取することはない。 上述のように、SIPリクエスト自体の処理は先取されない。つまりプロキシ はセッションを管理しないため、プロキシ先取を実行しない。 [RFC4411]にはこの動作の詳細情報と例が記載されている。 先取のUASの動作については、セクション4.7.2.1で説明する。 Schulzrinne & Polk Standards Track [Page 11] RFC 4412 SIP Resource Priority February 2006 4.5.2. 優先順位のキュー処理 優先順位のキュー処理ポリシーでは、使用できるリソースが見つからないリ クエストは、優先順位を付けたキューに格納される。特記がない場合、リク エストは先着順(first-come, first-served order)にキューに格納される。 各優先順位値が固有のキューを持つ場合や、複数の優先順位値が1つのキュー を共有する場合がある。リソースが使用できるようになった場合、RPアク ターは、キューのサービスポリシーに従い、高い優先順位の空ではない キューからリクエストを選択する。先着順に、最も長く待機していたキュー のリクエストがサービスされる。各キューが保持できる保留リクエストの数 は有限である。新たに受信した リクエスト用の優先順位値ごとのキューが 一杯の場合、リクエストは直ちに拒否される。このとき、セクション4.6.5 とセクション4.6.6で指定されるステータスコードが指定される。 さらに、優先順位のキュー処理ポリシーによって、各優先順位クラスに待機 時間の制限を課してもよい[MAY]。この場合、指定した待機時間を超えたリク エストはキューから削除され、408 (Request Timeout)エラー応答がリクエ スト発信元に返される。 最終的に、RPアクターは、すべてのキューを合計したグローバルなキューサ イズ制限を課し、低い優先順位の待機リクエストを 408 (Request Timeout) エラー応答で削除してもよい[MAY]。セッションは確立していない時点なの で、この処理に先取の意味がない。 キュー処理のUASの動作については、セクション4.7.2.2で説明する。 4.6. エラー条件 4.6.1. はじめに このセクションでは、複数種類のRPアクター(トランクゲートウェイ、ライン ゲートウェイ、IP電話など、多様なインスタンスのUASを含む)とプロキシで 共有されるエラー動作について説明する。 リソース優先順位の指定を含むリクエストが失敗する原因は次の4つのいず れかである。 o RPアクターが優先順位値を理解していない場合(セクション4.6.2) o リクエスト発信元が認証されない場合(セクション4.6.3) o 認証されたリクエスト発信元にこのようなリクエストを作成する権限が ない場合(セクション4.6.4) o 権限が認可されたリクエストでもリソースが不十分な場合(セクション 4.6.5) Schulzrinne & Polk Standards Track [Page 12] RFC 4412 SIP Resource Priority February 2006 一般的に、Resource-Priorityヘッダーを含むリクエストの処理時に発生する 順序でこれらのエラー例について説明する。ただし、この順序は絶対的なも のではない。たとえば、特定のリソース値をサービスできないまたはキュー 処理できないことがわかっているRPアクターは、ローカルポリシーの問題と して、認可を実行しなくてもよい[MAY]。これは、結果は変わらず、負荷処 理が増えるだけのためである。 4.6.2. 未知の名前空間または優先順位 RPアクターがリクエストに含まれるリソース値を理解しない場合、取り扱い 方法は、「Require」の「resource-priority」オプションタグが存在するか どうかによって変わる。 1. オプションタグがない場合、RPアクターは「Resource-Priority」ヘッ ダーフィールドがリクエストに含まれている場合と同様にリクエストを 扱い、デフォルトの優先順位で処理する。理解できないリソース値は、 修正または削除してはならない[MUST NOT]。 2. オプションタグがある場合、リクエストを417 (Unknown Resource-Priority)応答コードでリクエストを拒否しなけれ ばならない[MUST]。 UASへの途中でプロキシがUACと共通の名前空間を共有していてもUACとUASが このような名前空間を共通して持っている場合、呼を正常に完了する方法が 他にはないため、ケース(1)をデフォルトにする必要がある。 前述したように、一般的にSIPリクエストには複数の「Resource-Priority」 ヘッダーフィールドが含めることができる。これは、有効なリソース値の独 自セットをそれぞれが持つ複数の管理ドメインを、リクエストがトラバース する必要がある場合に必須な処理である。たとえば、そのドメイン内にいる ほとんどの個人向けにDSN/DRSN名前空間もサポートしている米国政府のネッ トワークでは、ETS名前空間を有効にする場合もある。 ローカルポリシーに従って、417 (Unknown Resource-Priority)応答には、 受け入れ可能なリソース値を列挙した「Accept-Resource-Priority」ヘッ ダーフィールドを含めてもよい[MAY]。 4.6.3. 認証エラー リクエストが認証されない場合、リクエスト発信元が適切な資格情報を挿入 できるように、401 (Unauthorized)応答または407 (Proxy Authentication Required)応答が返される。 Schulzrinne & Polk Standards Track [Page 13] RFC 4412 SIP Resource Priority February 2006 4.6.4. 認可エラー RPアクターは、認識できる名前空間と優先順位が指定されているが、そのレ ベルのサービスの権限が発信元にない認証済みリクエストを受信した場合、 受信した要素は403 (Forbidden)応答を返さなければならない[MUST]。 4.6.5. リソース不足 リソース不足条件は、RPアクターが認可済みリクエストを受信し、リソース が不足している状態で、他セッションの先取やキューへの格納ができない場 合に、プロキシサーバーとユーザーエージェントサーバー、特にトランク ゲートウェイで発生する可能性がある。リクエストが失敗する理由として、 RPアクターの処理能力が不十分なためにSIPリクエストを処理できない場合、 または帯域やトランクの容量が不十分なためにSIPリクエストのセッション 作成をリクエストされたセッションを確立できない場合がある。 RPアクターがシグナリングの負荷を処理できないためにリクエストが失敗す る場合、RPアクターは503 (Service Unavailable)で応答する。 十分な帯域がない場合、またはトランク数が不十分な場合、488 (Not Acceptable Here)応答を使用して、ゲートウェイのリソースが足りな いなど、メディアパスの機能が原因でRPアクターがリクエストを拒否してい ることを示す。この場合、[RFC3261]は、488応答に拒否の理由を指定した 「Warning」ヘッダーフィールドを含めるべきである[SHOULD]と勧めている。 警告コード370 (Insufficient Bandwidth)が一般的である。 キュー処理を実装しているシステムで、リクエストをキューに格納する場 合、リクエストがキューに指定された最長待機時間を超える場合、UASは408 (Request Timeout)を返す。 4.6.6. ビジー リソースの競合は、UASに1回線しかないため、またはすべての回線にアク ティブな通話があるために、別の呼を受け入れることができないときに、UAS に呼のリクエストが到達したときに発生する。呼のリクエストが、すべての アクティブな呼と比較して、同等か低い優先順位値を示す場合、UASは486 (Busy here)応答を返す。 そうではなくリクエストがキューに格納されている場合、デバイスのキュー に指定されている最長待機時間を超えたとき、UASは408 (Request Timeout) を返す。 プロキシはすべてのブランチで486 (Busy Here)応答を取得した場合、600 (Busy Everywhere)応答を発信元に返すことができる。 Schulzrinne & Polk Standards Track [Page 14] RFC 4412 SIP Resource Priority February 2006 4.7. 要素固有の動作 4.7.1. ユーザーエージェントクライアントの動作 本仕様をサポートするSIP UACには、高いリソースアクセス優先順位を必要と するリクエストに、「Resource-Priority」ヘッダーフィールドを生成する 機能が必要である[MUST]。前述したように、UACは、1つのSIPリクエストに 複数のリソース値を生成できるべきてある[SHOULD]。 417 (Unknown Resource-Priority)応答の受信時に、UACは以降のリクエスト を同じリソースとまたは異なるリソース値で試行してもよい[MAY]。使用可 能な場合、「Accept-Resource-Priority」ヘッダーフィールドで返された値 セットから、認可済みリソース値を選択すべきである[SHOULD]。 4.7.1.1. 先取アルゴリズムを使用したユーザーエージェントクライアント の動作 UACは、先取を引き起こす可能性がある優先順位値を要求する場合、 [RFC4411]で説明されるように、セッションが中断された理由を説明するBYE リクエストのReasonヘッダーフィールドを理解しなければならない[MUST]。 4.7.1.2. キュー処理アルゴリズムを使用したユーザーエージェントクライア ントの動作 標準のSIPプロトコル規則では、現在はビジーだが元のリクエストをキュー に格納したRPアクターから、UACは182 (Queued)応答を受信する準備を整え なければならない[MUST]。UACは、ユーザーが呼が失敗したと勘違いしない ように、このキューステータスを何らかの音声や画面表示でユーザーに示し てもよい[MAY]。 4.7.2. ユーザーエージェントサーバーの動作 「Resource-Priority」を指定したときの正確な効果は、UAS、名前空間、 ローカルポリシーの種類によって変わる。 4.7.2.1. ユーザーエージェントサーバーと先取アルゴリズム 本仕様に準拠するUASは、有効な名前空間と高い優先順位値を使用した新規の セッション確立がある場合、それを優先し、有効な名前空間と低い優先度値 を使用して確立したセッションを中止しなければならない[MUST]。ただし、 ローカルポリシーに何らかの通話待機機能がある場合は例外である。セッ ションが中止される場合、先取が実行された理由を示す「Reason」ヘッダー フィールドを指定したBYEメソッドが使用される。 実装者には、複数の回線を持つIP電話(つまり、複数のセッションを同時に 処理できるデバイス)が先取を実装する方法について、複数の多数の選択肢 Schulzrinne & Polk Standards Track [Page 15] RFC 4412 SIP Resource Priority February 2006 がある。当然ながら、そのデバイスが複数ある同時セッションをすべて使っ ている場合、セッションのいずれかを置換する必要がある。デバイスはセッ ションを置換する場合、優先順位が高い呼の到達に関して、実装で着呼側に 警告してもよい[MAY]。ローカルまたは名前空間のポリシーによって、詳細 情報を設定することもできる。 [RFC4411]は、セッションを意図的に中断する場合、または管理上の理由で 中断する場合、BYEを送信した理由(この場合は先取イベント)を示すBYEメ ソッドのReasonヘッダーを含めることで、追加情報を提示する。RFC 4411の メカニズムによって、中止が発生した位置(「UAで」、「予約内で」、 「IP/PSTNゲートウェイ」)を示すことができる。また、RFC 4411には、各理 由のコールフロー例が記載されている。 4.7.2.2. ユーザーエージェントサーバーとキューベースのポリシー 本仕様に準拠するUASは、その要素のリソースがビジーの場合、 182 (Queued)応答を生成すべきである[SHOULD]。ただし、リクエスト処理し て最終応答を生成することができる場合は除く。このような暫定メッセージ の頻度は、[RFC3261]で管理される。 4.7.3. プロキシの動作 SIPプロキシは、「Resource-Priority」ヘッダーフィールドを無視してもよ い[MAY]。SIPプロキシは、Resource-Priorityヘッダーフィールドを含む未 認証のリクエストを拒否してもよい[MAY]。 「Require」ヘッダーフィールドがメッセージに含まれる場合、平行する フォークのうち、resource-priorityメカニズムをサポートするブランチの みが成功するようにする。 RFC 3261のセクション23に従ってS/MIMEのカプセル化を使用する場合、特別 な考慮が必要である。セクション3.3で表にしているように、プロキシは 「Resource-Priority」ヘッダーフィールドを修正することができる。した がって、RFC 3261のセクション23.4.1.1に記載されている完全性チェックを 適用しないことができる。プロキシによる検査または修正が必要な可能性が あるため、UACはプロキシサーバーに対してヘッダー情報を処理する機能を 希望する場合、ヘッダーフィールドは「外側の(outer)」メッセージにも配 置しなければならない[MUST]。[RFC3420]で説明しているようにメッセージ の一部が完全性を保護されている場合、または暗号化されている場合にも同 様の考慮が適用される。 S/MIMEを使用しない場合、または「Resource-Priority」ヘッダーフィールド が「外側の」ヘッダーにある場合、ローカルポリシーで許容されていれば、 SIPプロキシはRequireの「Resource-Priority」を上下したり、新規の 「Resource-Priority」ヘッダーを挿入してもよい[MAY]。 Schulzrinne & Polk Standards Track [Page 16] RFC 4412 SIP Resource Priority February 2006 ステートフルプロキシが特定のリソース優先順位レベルを認可した場合、お よびリソースの優先順位レベルを含む応答に対して特別な扱いをする場合、 プロキシは、応答に含まれる高い値を無視すべきである[SHOULD]。これは、 攻撃に共謀するユーザーエージェントが不正に優先順位レベルを上げる操作 を防ぐためである。 SIPプロキシは、ルーティングの決定に「Resource-Priority」の指示を使用 してもよい[MAY]。たとえば、特定のリソース優先順位に予約されているSIP ノードまたはSIP URIに対象を変更する場合などである。 リソースの優先順位指示を含むリクエストがフォークする場合のプロキシに 特殊な考慮事項はない。 その他の場合、プロキシの動作は、セクション4.7.2で説明しているユーザー エージェントサーバーと同じである。 5. サードパーティの認証 場合によっては、RPアクターには、リクエスト発信元を認証できない場合、 または認証済みユーザーにそのリクエストを作成する権限があることを判断 できない場合がある。このような場合、SIPエンティティは、このアプリケー ションに固有ではない一般的なSIPメカニズムを利用してもよい。認証済みID 管理メカニズム[RFC3893]を使用すると、サードパーティがリクエスト発信元 のIDを検証し、そのIDをRPアクターに対して証明することができる。相互信 頼関係があるネットワークでは、SIPがアサートするIDメカニズム[RFC3325] は、RPアクターがリクエスト発信元のIDを判断するときに役立つ。 6. 下位互換性 本文書に記載されているリソース優先順位決定メカニズムは、[RFC3261]に 従うSIPシステムと完全に下位互換性がある。メカニズムを理解しないシス テムは、標準の(上げていない)サービス優先順位のみを配信することがで きる。ユーザーエージェントサーバーとプロキシは、他の未知のヘッダー フィールドと同様に「Resource-Priority」ヘッダーフィールドを無視し、 他のRequireと同様に扱うことができる。当然ながら、リクエストが成功す る場合もある。 7. 例 SDPメッセージのボディ、BYEとACKの交換は、RFC 3665[RFC3665]の場合と同 じであり、短くするために省略される。 Schulzrinne & Polk Standards Track [Page 17] RFC 4412 SIP Resource Priority February 2006 7.1. 単純な通話 User A User B | | | INVITE F1 | |----------------------->| | 180 Ringing F2 | |<-----------------------| | | | 200 OK F3 | |<-----------------------| | ACK F4 | |----------------------->| | Both Way RTP Media | |<======================>| | | このシナリオでは、User AがUser Bへの呼を直接完了する。AからBへの発 呼は、リソース優先順位決定の指示でマークされる。 F1 INVITE User A -> User B INVITE sip:UserB@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: BigGuy ;tag=9fxced76sl To: LittleGuy Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Resource-Priority: dsn.flash Contact: Content-Type: application/sdp Content-Length: ... ... F2 180 Ringing User B -> User A SIP/2.0 180 Ringing Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: BigGuy ;tag=9fxced76sl To: LittleGuy ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Length: 0 Schulzrinne & Polk Standards Track [Page 18] RFC 4412 SIP Resource Priority February 2006 F3 200 OK User B -> User A SIP/2.0 200 OK Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: BigGuy ;tag=9fxced76sl To: LittleGuy ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: ... ... 7.2. 受信側が名前空間を理解しない この例では、受信するUAが「dsn」名前空間を理解しないため、417 (Unknown Resource-Priority)ステータスコードを返す。メッセージF5〜F7のメッセー ジは、最初の例と実質的に同じなので、詳細は省略した。 User A User B | | | INVITE F1 | |----------------------->| | 417 R-P failed F2 | |<-----------------------| | ACK F3 | |----------------------->| | | | INVITE F4 | |----------------------->| | 180 Ringing F5 | |<-----------------------| | 200 OK F6 | |<-----------------------| | ACK F7 | |----------------------->| | | | Both Way RTP Media | |<======================>| Schulzrinne & Polk Standards Track [Page 19] RFC 4412 SIP Resource Priority February 2006 F1 INVITE User A -> User B INVITE sip:UserB@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: BigGuy ;tag=9fxced76sl To: LittleGuy Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Require: resource-priority Resource-Priority: dsn.flash Contact: Content-Type: application/sdp Content-Length: ... ... F2 417 Resource-Priority failed User B -> User A SIP/2.0 417 Unknown Resource-Priority Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: BigGuy ;tag=9fxced76sl To: LittleGuy ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Accept-Resource-Priority: q735.0, q735.1, q735.2, q735.3, q735.4 Contact: Content-Type: application/sdp Content-Length: 0 F3 ACK User A -> User B ACK sip:UserB@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 Max-Forwards: 70 From: BigGuy ;tag=9fxced76sl To: LittleGuy ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 ACK Content-Length: 0 Schulzrinne & Polk Standards Track [Page 20] RFC 4412 SIP Resource Priority February 2006 F4 INVITE User A -> User B INVITE sip:UserB@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: BigGuy ;tag=9fxced76sl To: LittleGuy Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 INVITE Require: resource-priority Resource-Priority: q735.3 Contact: Content-Type: application/sdp Content-Length: ... ... 8. 複数が平行する名前空間の処理 8.1. 一般規則 単一のSIPリクエストには、複数の名前空間からリソース値を含めてもよい [MAY]。前述したように、RPアクターは認識していないすべての名前空間を 無視する。この仕様では、残っているリソース値から1つをRPアクターが選 択して処理する場合(通常、最も高い優先順位を持つものを選択する場合)に のみ対処する。 RPアクターが複数の名前空間を理解する場合、このような名前空間の全リ ソース値からローカルで総合の順序を作成しなければならない[MUST]。この とき、各名前空間内の相対的順序は維持する。1つの管理ドメイン内で同じ 順序を使用することが推奨される[RECOMMENDED]。ただし、すべての管理ド メインでこのような順序を同じにする必要はない。 8.2. 有効な順序処理の例 fooとbarという2つの名前空間をサポートするRPアクターの例を以下に複数 示す。fooの優先順位値は3(最高)、2、1(最低)である。barの優先順位値は C(最高)、B、A(最低)である。 Schulzrinne & Polk Standards Track [Page 21] RFC 4412 SIP Resource Priority February 2006 以下にSIP要素が使用できる優先順位値の順序を5つ列挙する。 Foo.3 Foo.3 Bar.C (最高の優先順位) Foo.2 Bar.C Foo.3 Foo.1 または Foo.2 または Foo.2 Bar.C Bar.B Foo.1 Bar.B Foo.1 Bar.B Bar.A Bar.A Bar.A (最低の優先順位) Bar.C (最高の優先順位) Foo.3 Bar.B (どちらも同じ優先順位で扱われる (先着順(FIFO))) または Foo.2 Bar.A (どちらも同じ優先順位で扱われる (先着順(FIFO))) Foo.1 (最低の優先順位) Bar.C (最高の優先順位) Foo.3 または Foo.2 Foo.1 (最低の優先順位) 上記の最後の例では、Bar.AとBar.Bは無視される。 8.3. 無効な順序処理の例 上記の優先順位値の順序に従うと、次の順序の組み合わせ例は受け入れられ ない[NOT]。また、設定してはならない[MUST NOT]。 Example 1 Example 2 Example 3 --------- --------- --------- Foo.3 Foo.3 Bar.C Foo.2 Bar.A Foo.1 Foo.1 または Foo.2 または Foo.3 Bar.C Bar.B Foo.2 Bar.A Foo.1 Bar.A Bar.B Bar.C Bar.B Example 4 --------- Bar.C Foo.1 Bar.B または Foo.3 Bar.A Foo.2 Schulzrinne & Polk Standards Track [Page 22] RFC 4412 SIP Resource Priority February 2006 これらの例は無効な理由は、次のグローバルな順序が名前空間内の順序と矛 盾するためである。 o Example 1では、Bar.AはBar.Bよりも高い順序にされている。 o Example 2では、Bar.AはBar.BとBar.Cよりも高い順序にされている。 o Example 3では、Foo.1はFoo.2とFoo.3よりも高い順序にされている。 o Example 4では、Foo.1はFoo.3とFoo.2よりも高い順序にされている。 9. 名前空間の登録 Resource-Priorityヘッダーフィールドの使用を組織で検討している場合、 名前空間と優先順位値の既存の組み合わせが自分たちの要件に適合するかど うかを調査すべきである。たとえば、各国の緊急事態を最優先にして応答す る組織は、今後のネットワークで優先的な取り扱いをするためにこのメカニ ズムを利用することを議論している。管轄区域では、既存のIANAに登録され た名前空間を使用できる場合は再利用すべきである[SHOULD]。本文書の目的 は、同じ目的をサービスして同じ優先順位レベルを使用する各管轄区域ごと に一意の名前空間を持たせることではないためである。これによって相互運 用可能性が大幅にに向上し、開発時間が減る。また、将来的に相互運用の機 能で名前空間を別の名前空間にマッピングする必要性が出てきたときでも、 おそらく混乱が減ると予想される。 以下に新規名前空間を登録するときに必要な手順について説明する。 新規の名前空間は、[RFC2434]の「Standards Action (標準化活動)」ポリ シーに従って標準化過程のRFCで定義しなければならない[MUST]。また、次 の面を含めなければならない[MUST]。 o 名前空間のラベルを定義する必要がある。これは、SIP Resource-PriorityヘッダーフィールドのIANAレジストリ内で一意な名前 空間のラベルである。 o 名前空間が使用している優先順位レベル(「r-priority」値)を列挙する 必要がある。使用できるのは有限のリストのみであり、たとえば任意の 整数やトークンは使用できないということに注意。 o 優先順位のキュー処理("queue")または割り込み("preemption")のどちらを 名前空間に使用するかを指定した、優先順位アルゴリズム(セクション 4.5)。キュー処理を使用する場合、名前空間は、通常の優先順位を持つ リクエストをキューに格納するかどうかを示してもよい[MAY]。先取また は優先順位のキュー処理とは異なる新規の「所定のアルゴリズム」があ る場合、そのアルゴリズムはすべてのRPアクター(UAC、UAS、プロキシ) を考慮にいれて記述する必要がある。 Schulzrinne & Polk Standards Track [Page 23] RFC 4412 SIP Resource Priority February 2006 o 名前空間は、IANAのsip-parametersのResource-Priority優先順位値の登 録で、優先順位値の既存のリストを参照するか、相対的な優先順位で 優先順位値の有限なリストを新規に定義することができる。新規の優先 順位値は、特定の名前空間と関連付けられた既存のIANA登録済みリスト に追加すべきではない[SHOULD NOT]。相互運用性の問題を引き起こす可 能性があるためである。特記がなければ、すべての優先順位値は、優先 順位値がないリクエストよりも高い優先順位を与えていると仮定される。 o この新規名前空間に固有の新規のSIP応答コードには、説明と登録が必要 である。 o 参考文献は、新規のWarningヘッダーフィールドの警告コード(RFC 3261、 セクション27.2)について規定し、説明する必要がある。 o 参考文献では、名前空間の機能をまとめた次の表に新規の行を規定し、 IANAのResource-Priority名前空間登録に含める必要がある。 意図する 新規警告 新規応答 名前空間 レベル アルゴリズム コード コード 参考文献 --------- ------ ---------------- --------- -------- ---------