Network Working Group J. Lennox Request for Comments: 3880 X. Wu Category: Standards Track H. Schulzrinne Columbia University October 2004 呼処理言語(CPL): インターネット電話サービスのユーザー制御のための言語 Call Processing Language (CPL): A Language for User Control of Internet Telephony Services 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準トラッ クプロトコルを規定するものであり、改善のための議論や提案を依頼するもの である。標準化の段階や、プロトコルの位置付けについては、最新版の "Internet Official Protocol Standards" (STD 1)を参照されたい。この文書 の配信は無制限である。 著作権表記 Copyright (C) The Internet Society (2004). 概要 本文書は、呼処理言語(Call Processing Language/CPL)を定義する。CPLは、 インターネット電話サービスの記述と制御を行うための言語である。CPLは ネットワークサービスまたはユーザーエージェントに実装できるように設計さ れている。シンプルで、また拡張可能であり、画像クライアントで簡易に編集 でき、OSやシグナリングプロトコルには依存しないように意図されている。 CPLはユーザーが任意のプログラムを実行できないサーバー上で実行するのに 適している。なぜなら、変数やループ、外部プログラムを実行する機能がない ためである。 Lennox, et al. Standards Track [Page 1] RFC 3880 CPL October 2004 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. 本文書の規約 . . . . . . . . . . . . . . . . . . . . . 4 2. CPLスクリプトの構造 . . . . . . . . . . . . . . . . . . . . . 4 2.1. 上位階層の構造 . . . . . . . . . . . . . . . . . . . . 4 2.2. 呼処理アクションの理論的構造 . . . . . . . . . . . . . 5 2.3. ロケーションモデル . . . . . . . . . . . . . . . . . . 6 2.4. XMLの構造 . . . . . . . . . . . . . . . . . . . . . . . 6 3. スクリプトの構造： 概要 . . . . . . . . . . . . . . . . . . . 7 4. スイッチ . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. アドレススイッチ . . . . . . . . . . . . . . . . . . . 9 4.1.1. 「address-switch」のSIPでの用法 . . . . . . . . 11 4.2. 文字列スイッチ . . . . . . . . . . . . . . . . . . . . 12 4.2.1. 「string-switch」のSIPでの用法 . . . . . . . . 13 4.3. 言語スイッチ . . . . . . . . . . . . . . . . . . . . . 14 4.3.1. 「language-switch」のSIPでの用法 . . . . . . . 14 4.4. タイムスイッチ . . . . . . . . . . . . . . . . . . . . 15 4.4.1. iCalendarの差異と実装上の課題 . . . . . . . . . 20 4.5. 優先度スイッチ . . . . . . . . . . . . . . . . . . . . 21 4.5.1. 「priority-switch」のSIPでの用法 . . . . . . . 22 5. ロケーションの修飾子 . . . . . . . . . . . . . . . . . . . . . 22 5.1. 明示的ロケーション . . . . . . . . . . . . . . . . . . 23 5.1.1. 「location」のSIPでの用法 . . . . . . . . . . . 23 5.2. ロケーションの検索 . . . . . . . . . . . . . . . . . . 24 5.2.1. 「lookup」のSIPでの用法 . . . . . . . . . . . . 25 5.3. ロケーションの削除 . . . . . . . . . . . . . . . . . . 25 5.3.1. 「remove-location」のSIPでの用法 . . . . . . . 26 6. シグナリング操作 . . . . . . . . . . . . . . . . . . . . . . . 26 6.1. プロキシ . . . . . . . . . . . . . . . . . . . . . . . 26 6.1.1. 「proxy」のSIPでの用法 . . . . . . . . . . . . 29 6.2. リダイレクト . . . . . . . . . . . . . . . . . . . . . 29 6.2.1. 「redirect」のSIPでの用法 . . . . . . . . . . . 30 6.3. 拒否 . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.3.1. 「reject」のSIPでの用法 . . . . . . . . . . . . 30 7. 非シグナリング操作 . . . . . . . . . . . . . . . . . . . . . . 31 7.1. メール . . . . . . . . . . . . . . . . . . . . . . . . 31 7.1.1. メール情報の提案内容 . . . . . . . . . . . . . 32 7.2. ログ . . . . . . . . . . . . . . . . . . . . . . . . . 32 8. サブアクション . . . . . . . . . . . . . . . . . . . . . . . . 33 9. 補足情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 10. デフォルトの動作 . . . . . . . . . . . . . . . . . . . . . . . 35 11. CPLの拡張 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 12. 例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 12.1. 例: 呼のリダイレクト(無条件) . . . . . . . . . . . . . 37 12.2. 例: 呼転送 ビジー/無応答 . . . . . . . . . . . . . . . 38 12.3. 例: リダイレクトとデフォルトの呼の転送 . . . . . . . . 39 Lennox, et al. Standards Track [Page 2] RFC 3880 CPL October 2004 12.4. 例: 呼の審査 . . . . . . . . . . . . . . . . . . . . . 40 12.5. 例: 優先度と言語のルーティング . . . . . . . . . . . . 41 12.6. 例: 発呼の審査 . . . . . . . . . . . . . . . . . . . . 42 12.7. 例: time-of-dayルーティング . . . . . . . . . . . . . . 43 12.8. 例: ロケーションのフィルタリング . . . . . . . . . . . 44 12.9. 例: 非シグナリング操作 . . . . . . . . . . . . . . . . 45 12.10. 例: 仮定上の拡張 . . . . . . . . . . . . . . . . . . . 46 12.11. 例: 複雑な例 . . . . . . . . . . . . . . . . . . . . . 48 13. セキュリティの考慮事項 . . . . . . . . . . . . . . . . . . . . 49 14. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 14.1. urn:ietf:params:xml:ns:cplのURN下位名前登録 . . . . . . 49 14.2. スキーマ登録 . . . . . . . . . . . . . . . . . . . . . 50 14.3. MIME登録 . . . . . . . . . . . . . . . . . . . . . . . 50 15. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 A. タイムスイッチを解決するためのアルゴリズム . . . . . . . . . . 52 B. H.323でのCPL使用案 . . . . . . . . . . . . . . . . . . . . . . 53 B.1.「address-switch」のH.323での用法 . . . . . . . . . . . . 53 B.2.「string-switch」のH.323での用法 . . . . . . . . . . . . . 55 B.3.「language-switch」のH.323での用法 . . . . . . . . . . . . 55 B.4.「priority-switch」のH.323での用法 . . . . . . . . . . . . 55 B.5.「location」のH.323での用法 . . . . . . . . . . . . . . . 56 B.6.「lookup」のH.323での用法 . . . . . . . . . . . . . . . . 56 B.7.「remove-location」のH.323での用法 . . . . . . . . . . . . 56 C. CPL用のXMLスキーマ . . . . . . . . . . . . . . . . . . . . . . 56 規範となる参考文献 . . . . . . . . . . . . . . . . . . . . . . . . 70 有益な参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . 71 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 完全な著作権表示 . . . . . . . . . . . . . . . . . . . . . . . . . 74 1. はじめに 呼処理言語(Call Processing Language/CPL)はインターネット電話サービスを 記述・制御するために使用できる言語である。これは特定のシグナリングの アーキテクチャやプロトコルに縛られない。つまり、セッション開始プロトコ ル(Session Initiation Protocol/SIP)[1]とH.323 [16]の両方に使用されるこ とが予想される。 CPLは大量のサービスと機能を記述するための能力は十分あるが、インター ネット電話サーバー内で安全に稼働できる範囲の能力に限定されている。これ は、ユーザーがインターネット電話サービス以外の、より複雑な(かつ危険な) ことをできないようにする意図からである。この言語はTuring-completeでは なく、ループや再帰を記述する方法は提供していない。 CPLはまた、画像ツールで容易に製作・編集ができるように設計されている。 拡張可能マークアップ言語(Extensible Markup Language/XML)[2]に基づいて いるため、パースが簡単であり、またそのための多くのパーサーが公開されて おり利用できる。 Lennox, et al. Standards Track [Page 3] RFC 3880 CPL October 2004 言語構造はアクションに沿ってマップしているため、編集する側は、たとえ手 書きであっても、有効なスクリプトすべてが理解できる。また、この言語は、 呼を処理する際に問題を検出するためではなく、サーバーがスクリプトを受信 したときにその有効性を容易に確認できるように設計されている。 インターネット電話サーバーと高度なクライアントの両方に、CPLが実装され ることが予想される。というのは、いずれもユーザーの呼を効果的に処理した り指示することができるためである。本文書は主にサーバーにおける用法を扱 う。クライアントとサーバー間でスクリプトを送信する仕組みがこれから必要 になる。本文書ではこのような仕組みについて記述しないが、関連する文書に 記載されると予想される。 CPLアーキテクチャのためのフレームワークと要件はRFC 2824「Call ProcessingLanguage Framework and Requirements」[17]に記載されている。 1.1. 本文書の規約 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」はRFC 2119のBCP 14[3]に記載され るとおりに解釈されるべきであり、CPL準拠の実装のための実装レベルを示す ものである。 一部の段落は、このように字下げして書かれる。このような段落には、設 計で選択する際に参考になる考察や、実装者へのアドバイス、将来的な開 発やCPLの拡張に関する考察が書かれている。このような段落はCPLの仕様 にとって重要なものではなく、また、規範ではない。 2. CPLスクリプトの構造 2.1. 上位階層の構造 CPLスクリプトは2つのタイプの情報から成り立つ。スクリプトに関する補助情 報(ancillary information)と呼処理アクション(call processing actions)で ある。 呼処理アクションは、呼のセットアップイベント時に電話シグナリングサー バー(telephony signalling server)が実行する操作と決定を記述する構造化 ツリーである。呼処理アクションには2つのタイプがある。トップレベルアク ション(top-levelactions)とサブアクション(subactions)である。トップレベ ルアクションとは、サーバーに届くシグナリングイベントによって引き起こさ れるアクションである。2つのトップレベルアクションが定義されている。1つ 目は「incoming(着信)」で、発信先(destination)がスクリプトの所有者であ り、着呼時に実行されるアクションである。2つ目は「outgoing(発信)」で、 発信元(originator)がスクリプトの所有者であり、着呼時に実行されるアク ションである。 Lennox, et al. Standards Track [Page 4] RFC 3880 CPL October 2004 サブアクション(subaction)とは、他のアクションから呼び出される可能性の あるアクションである。CPLは、サブアクションを再帰的に呼び出すことを禁 止する。セクション8を参照のこと。 補助情報は、サーバーが適切にスクリプトを処理するために必要な情報だが、 直接には操作や決定を記述しない。現在のところ、補助情報は定義されていな いが、拡張で使用できるように、セクションが確保されている。 2.2. 呼処理アクションの理論的構造 理論的には、呼処理アクションは、実行可能な操作や可能な決定を記述する、 ノードの集合によって記述される。ノードは、ノードの正確なアクションを指 定するパラメータをいくつか持ってもよい。また、決定またはアクションの結 果によって、それら(訳注: パラメータ)には通常はアウトプットもある。 CPLアクションの図説は、図1を参照されたい。ノードとアウトプットは、略式 では、ボックスと矢印であると考えられる。この説明を利用して、アクション を図式的に適宜編集できるように、CPLは設計されている。ノードは、1個の ルートノードで始まる1個のツリーに配列される。ノードは、1個のルートノー ドで始まる1個のツリーに配列される。アクションが実行されるとき、アク ションのトップレベルのノードが記述しているアクションまたは決定が実行さ れる。そのノードの結果に基づいて、サーバーはノードのアウトプットのいず れかに従い、さらに、指定される次のノードが実行される。この処理は、指定 されるアウトプットがないノードに達するまで続く。図式は巡回しないため、 限られた予測可能な数のノードを経た後にそうなる。 あるノードのアウトプットが別のノードを指定していない場合、CPLサーバー がノード固有またはプロトコル固有のアクションを実行すべきであることを示 す。ノードの一部には、関連付けられている特定のデフォルトの動作がある。 他のノードのデフォルトの動作は、基本となるシグナルプロトコルにおける暗 黙的なものか、または、サーバー管理者が設定する可能性がある。この点に関 する詳細は、セクション10を参照のこと。 Lennox, et al. Standards Track [Page 5] RFC 3880 CPL October 2004 _________________ ___________________ ________ busy | Address-switch | | location | | proxy |--------\ Call-->| field: origin | ->| url: sip:jones@ |->|timeout:| timeout| | subfield: host | / | example.com | | 10s |--------| |-----------------|/ |___________________| | | failure| | subdomain-of: | |________|--------| | example.com | | |-----------------| ___________________________________________/ | otherwise | /........................................ | |\|. Voicemail . |_________________| \. ____________________ . ->| location | __________ . . | url: sip:jones@ | | redirect | . . | voicemail. |->| | . . | example.com | |__________| . . |____________________| . ........................................ 図1: CPLのアクション例: 図解版 2.3. ロケーションモデル 柔軟性の理由から、CPLに必要な情報のひとつである、呼が方向付けられる位 置のセットは、ノードのパラメータとして指定されない。その代わりに、この 位置セットは、処理アクションの実行全体の暗黙的なグローバル変数として格 納される。これによって、このような操作(言語理解の単純さと扱いやすさを 損ねる可能性がある)に対応する、一般的な言語を必要とすることなく、位置 を外部ソースから取得したり、フィルタするなどのことができるようになる。 位置セットの追加、取得、またはフィルタという特定の操作は、セクション5 で説明する。 着信のトップレベルの呼処理アクションである場合、位置セットは、空のセッ トに初期化される。送信アクションの場合、呼の送信先アドレスに初期化され る。 2.4. XMLの構造 構文上、CPLスクリプトは、XMLドキュメントで表される。XMLの詳細について は、XML仕様[2]を参照のこと。また本仕様を実装する場合、[2]に精通してい る必要がある。ただし、概要で説明したように、XMLは階層構造のタグで構築 され、各タグには複数の属性がある。XMLは見た目にも構造的にも、HTML[10] に非常によく似ている。理由は、どちらの言語も、より古く、大規模なSGML規 格[19]を単純化したもののためである。 Lennox, et al. Standards Track [Page 6] RFC 3880 CPL October 2004 図1にあるCPLスクリプトの図式に相当する、XMLドキュメントの図2を参照のこ と。CPLのノードと出力のどちらも、XMLタグで表される。パラメータはXMLタ グ属性で表される。通常、ノードタグには出力タグが含まれるが、その逆もあ る(いくつか例外はある: セクション5.1、5.3、7.1、7.2参照)。 ノードと別のノードとの出力間を接続する場合、外側にあるノードの出力のタ グ内で、指示先のノードを示すタグを囲むことで示される。収束 (convergence)(1つのノードを指示する複数の出力)は、セクション8で詳しく 論じるサブアクションによって示される。 CPLスクリプトのより上位の階層構造は、補助情報、サブアクション、トップ レベルアクションの各部分に対応するタグによって、順番に示される。この、 より上位階層の情報は、専用のタグ「cpl」(XMLドキュメントの一番外側のタ グ)ですべて囲まれている。 CPLのための完全なXMLスキーマは、付録Cに記載している。公式の構文につい ては、付録を参照のこと。 3. スクリプトの構造： 概要 前述のように、CPLスクリプトは、補助情報、サブアクション、トップレベル アクションから構成される。「cpl」ノードの完全な構文は、図3に示す。
Lennox, et al. Standards Track [Page 7] RFC 3880 CPL October 2004
図2: CPLのスクリプト例: XML版 タグ: 「cpl」 パラメータ: なし サブタグ: 「ancillary」 セクション9を参照のこと。 「subaction」 セクション8を参照のこと。 「outgoing」 このユーザーからの発呼で実行されるトップ レベルアクション 「incoming」 このユーザーへの着呼で実行されるトップ レベルアクション 図3: トップレベル「cpl」タグの構文 トップレベルアクションとサブアクションという呼処理動作はどちらも、ノー ドと出力のツリーで構成される。ノードと出力は、どちらもXMLタグで記述さ れる。CPLノードには4つの分類がある。スイッチ(CPLスクリプトが行える選択 を示す)、ロケーションの修飾子(位置セットから位置を追加または削除す る)、シグナリング操作(基礎のプロトコルでシグナリングイベントを発生させ る)、非シグナリング操作(基礎のプロトコルに影響を与えない動作をトリガす る)である。 4. スイッチ スイッチは、CPLスクリプトが行える選択を示し、元の発呼リクエストまたは 呼とは独立した項目のどちらかに基づく。 すべてのスイッチは、変数にマッチする可能性のある条件一覧として配列され る。各条件はノードの出力に相当する。出力は、条件が真の場合に実行する必 要がある、次のノードを指示する。条件は、スクリプトで出現した順に試行さ れる。最初にマッチするノードに相当する出力が取られる。 すべてのスイッチタイプに適用される、特殊なスイッチ出力が2つある。 出力「not-present」は、出力一覧のどこで発生してもよい[MAY]が、スイッチ とマッチする変数が、元の呼確立リクエストに存在しなかった(not present) 場合に、真になる。(本文書では、このことを情報が「ない」(absent)と記載 する場合がある。) Lennox, et al. Standards Track [Page 8] RFC 3880 CPL October 2004 出力「otherwise」は、指定する場合、最後に指定される出力でなければなら ない[MUST]が、マッチする条件が他にないときに、マッチする。 マッチする条件がなく、「otherwise」出力がスクリプトに存在しない場合、 デフォルトのスクリプト動作が取られる。この点について、詳しくはセクショ ン10を参照のこと。 スイッチには、何も出力を含めなくてもよい[MAY]。また、「otherwise」アウ トプットを含むだけでもよい[MAY]。 このようなスイッチは特に有益なものではないが、自動的にCPLスクリプト をを生成するツールによって作成される可能性がある。 4.1. アドレススイッチ address-switchによって、CPLスクリプトは、元の発呼リクエストに存在する アドレスの1つに基づいて、判断することができるようになる。図4に概要を示 す。 ノード: 「address-switch」 出力: 「address」 マッチする特定のアドレス パラメータ: 「field」 「origin」、「destination」、 「original-destination」 「subfield」 「address-type」、「user」、 「host」、「port」、「tel」、 「display」 (「password」と「alias-type」も) 出力: 「address」 パラメータ: 「is」 完全一致 「contains」 文字列の一部がマッチ(「display」用のみ) 「subdomain-of」 サブドメインのマッチ(「host」、「tel」 用) 図4: 「address-switch」ノードの構文 アドレススイッチには、「field」と「subfield」という2つのノードパラメー タがある。必須の「field」パラメータによって、呼の元のアドレス (「origin」field)、現在の送信先アドレス(「destination」field)、または 元の送信先(「original- destination」field)のうち、どのアドレスをスイッ チと扱うかについて、スクリプトで指定できるようになる。元の送信先とは、 以前に転送が呼び出される前に、呼が保持していた送信先である。サーバー で、その他のfield値を定義してもよい[MAY]。 オプションの「subfield」では、アドレスのどの部分を考慮すべきかを指定す る。指定できるsubfield値は、「address-type」、「user」、「host」、 「port」、「tel」、「display」である。プロトコル独自の値用に、その他の subfield値を定義してもよい[MAY](「password」subfieldは、セクション4.1. 1でSIP用に定義されている。「alias-type」subfieldは、付録B.1でH.323用に Lennox, et al. Standards Track [Page 9] RFC 3880 CPL October 2004 定義されている。)。subfieldが指定されていない場合、「entire」アドレス がマッチする。この文が正確に意味するところは、基礎の各シグナリングプロ トコルで定義される。サーバーで、その他のsubfield値を定義してもよい [MAY]。 subfieldは、以下のように定義される。 address-type: 基礎となるアドレスのタイプ(つまり、アドレスをURIで表 すことができる場合は、URIスキーム)を示す。本文書で特に話題に するタイプは、「sip」、「tel」、「h323」である。アドレスタイ プは、大文字小文字を区別しない。すべての定義済みアドレスタイ プの値を保持する。 user: このアドレスのサブフィールドは、電子メール型アドレスの場合、 アドレスのユーザー部を示す。電話番号スタイルのアドレスの場 合、加入者番号を含む。このsubfieldは、大文字小文字を区別す る。なくてもよい。 host: このアドレスのサブフィールドは、そのアドレスに対応するイン ターネットホスト名またはIPアドレスを、ホスト名、IPv4、IPv6[9] いずれかのテキスト表現形式で示す。ホスト名は、文字列と比較さ れる。IPアドレスは、数値で比較される。(特に、IPv6の省略された ゼロビットブロック(omitted-zero-bits block)「:: 」の存在や位置 は、マッチング目的の場合、重要ではない。)ホスト名は、IPアドレ スと等しくなることはない。IPアドレスではDNS名前解決は実行され ない。IPv4アドレスは、IPv6アドレスが、「v4-in-v6」型の埋め込 みの場合でも、IPv6アドレスと等しくなることはない。この subfieldは、大文字小文字を区別しない。なくてもよい。 ホスト名のみの場合、サブドメインのマッチングは、「subdomain- of」マッチ演算子で対応される。「subdomain-of」演算子では、ホ スト名やマッチパターンの先頭にドット(複数もあり)があれば、無 視される。 port: このサブフィールドはアドレスのTCPまたはUDPポート番号を示し、 数値上は10進書式である。10進数のみを含まなければならない [MUST]ので、大文字小文字は区別されない。先頭のゼロ(複数もあ り)は無視される。 tel: このサブフィールドは、アドレスが電話の加入者番号を含む場合、そ の番号を示す。大文字小文字は区別されない(電話番号には、 「A」、「B」、「C」、「D」という記号が含まれる可能性がある)。 また、なくてもよい。「subdomain-of」マッチ演算子を使用して マッチされる可能性がある。電話番号の区切り文字は、破棄され る。 Lennox, et al. Standards Track [Page 10] RFC 3880 CPL October 2004 display: このサブフィールドは、1個のアドレスに対応する「表示名 (display name)」、つまりユーザーに見える名前を示す。これは Unicode文字列であり、セクション4.2に記載されている大文字小文 字を区別しないアルゴリズムを使用してマッチされる。この subfieldに「contains」演算子を適用してもよい。なくてもよい。 まったく未知のsubfieldの場合、サーバーは、提示された時点で、問題を指摘 してスクリプトを拒否してもよい[MAY]。未知のsubfieldが含まれるスクリプ トを実行する場合、サーバーは、「not-present」出力を有効なものと考えな ければならない[MUST]。 「address」出力タグは、可能なパラメータ3つの中から、許容されるマッチン グ種類を示す、1つだけを採用することができる。 is: 「address-switch」でマッチされているサブフィールドが、演算子の 引数と正確にマッチする場合、このマッチ演算子を持つアウトプッ トに続く。どのsubfieldに使用してもよく、subfieldが指定されな かった場合はアドレス全体に使用してもよい。 subdomain-of: このマッチ演算子は、サブフィールド「host」「tel」に対 してのみ適用される。前者の場合、マッチ対象のホスト名が、マッ チ演算子のパラメータで示されるドメインのサブドメインである場 合にマッチする。したがって、「subdomain-of="example.com"」 は、ホスト名「example.com」、「research.example.com」、 「zaphod.sales.internal.example.com」にマッチする。IPアドレス は、この演算子に対するパラメータとして指定することができる。 ただし、正確に一致する場合のみである。「tel」サブフィールドで は、マッチされている電話番号が、マッチ演算子の引数とマッチす る局番(prefix)を持つ場合、アウトプットはマッチする。 subdomain-of="1212555" は、電話番号「1 212 555 1212」にマッチ する。 contains: このマッチ演算子は、サブフィールド「display」に対してのみ 適用される。マッチ対象の表示名に、文字列の一部がマッチする パラメータが含まれる場合、出力はマッチする。 4.1.1. 「address-switch」のSIPでの用法 SIPの場合、「origin」アドレスは、「From」ヘッダーのアドレスに相当し、 「destination」は「Request-URI」に相当し、「original-destination」は 「To」ヘッダーに相当する。 アドレスの「display」subfieldは、(存在する場合)アドレスの表示名部であ る。SIPの構文上、「destination」アドレスフィールドに、「display」 subfieldが含まれることはない。 Lennox, et al. Standards Track [Page 11] RFC 3880 CPL October 2004 アドレスの「address-type」subfieldは、そのアドレスのURIスキームで ある。他のアドレスフィールドは、この「address-type」によって変わる。 SIP URIの場合、「user」、「host」、「port」subfieldは、URI構文の 「user」、「host」、「port」要素に相当する。(RFC 3261[1]の定義に従う と、ポートを指定しないSIP URIは、明示的なポートと同じではない。前者 は、portのsubfieldが存在しないことで示される。)「tel」subfieldは、 「user=phone」パラメータがURIに指定される場合、またはサーバーがユー ザー部を電話番号と認識するように構成される場合に、視覚的なセパレータが 取り除かれたURIの「ユーザー」部であると定義される。その他のsubfieldと して、「password」は、SIP URIの「password」要素に相当すると定義されて おり、大文字小文字が区別される。ただし、このフィールドの使用は、一般的 なセキュリティ上の理由から、推奨されない[NOT RECOMMENDED]。 tel URLでは、「tel」と「user」サブフィールドは加入者名である。 前者の場合、視覚的分離記号は外される。「host」と「port」サブフィールド はどちらも提示されない。 h323 URLの場合、subfieldは、付録Bに記載されるスキームに従ったセットで もよい[MAY]。 他のURIスキームの場合、本仕様によって「address-type」subfieldのみが定 義される。サーバーは他の定義済みsubfieldを設定してもよい[MAY]し、新規 のsubfieldに対応してもよい[MAY]。 SIPメッセージのアドレス用にsubfieldが指定されない場合、マッチ対象の文 字列は、アドレスのURI部である。「is」マッチの場合、標準的なSIP URIの マッチング規則が使用される。「contains」マッチの場合、URIが一語一語使 用される。 4.2. 文字列スイッチ string-switchによって、CPLスクリプトは、発呼リクエストに存在する自由書 式の文字列に基づいて、判断することができるようになる。図5に概要を示 す。 ノード: 「string-switch」 出力: 「string」 マッチする特定の文字列 パラメータ: 「field」 「subject」、または「organization」、 「user-agent」、「display」 出力: 「string」 パラメータ: 「is」 完全一致 「contains」 文字列の一部がマッチ 図5: 「string-switch」ノードの構文 Lennox, et al. Standards Track [Page 12] RFC 3880 CPL October 2004 Stringスイッチには1個のノードパラメータ「field」がある。必須の 「field」パラメータは、マッチ対象の文字列を指定する。 string-switchは、使用されるコールシグナリングプロトコルによって変わ る。 以下のように、4つのフィールドが定義される。これら各フィールドの値は、 他に構造が定義されていない、自由形式のUnicode文字列である。 subject: 呼のサブジェクト。 organization: 呼の発信元の組織。 user-agent: 発呼リクエストを行ったプログラムまたはデバイスの名前。 display: 呼に関連付けられる自由形式のテキストで、受信側に表示される ことが意図されており、シグナリングプロトコルによって他のセマ ンティクスは定義されていない。 文字列は、大文字小文字を区別しないUnicode文字列として、以下の方法で マッチされる。はじめに、文字列は、Unicode Standard Annex #15 [5]で規定 されるように、「互換構文」(Compatibility Composition / KC)形式に標準化 される。それから、文字列は、Unicode Standard Annex #21 [6]で規定されて いるとおり、ロケールを区別しない、条件なしのマッピングを使って比較され る。 最初の段階を実行するコードは、JavaとPerlで利用可能である。UAX 15の Annex 5のリンク[5]を参照のこと。Javaの標準クラスライブラリの大文字 小文字を区別しない文字列比較では、すでに第2段階を実行している。他の Unicodeを意識するライブラリも同様のはずである。 文字列マッチングの出力タグは、「string」という名前であり、「is」または 「contains」のいずれかが必須のパラメータである。前者は文字列全体のマッ チを示し、後者はサブストリングのマッチを示す。 4.2.1. 「string-switch」のSIPでの用法 SIPの場合、field「subject」、「organization」、「user-agent」は、SIPの 同名のヘッダーフィールドに相当する。メッセージで出現する場合、文字通り に使用される。 field「display」は使用されず、また存在することはない。 Lennox, et al. Standards Track [Page 13] RFC 3880 CPL October 2004 4.3. 言語スイッチ language-switchによって、CPLスクリプトは、呼の発信元が通信で使用したい 言語に基づいて、判断することができるようになる。 図6に概要を示す。 ノード: 「language-switch」 出力: 「language」 マッチする特定の文字列 パラメータ: なし 出力: 「language」 パラメータ: 「matches」 提示された言語が呼のlanguage-rangeに マッチする場合、マッチする 図6: 「language-switch」ノードの構文 language-switchはパラメータを取らない。 「language」出力は「matches」という1つのパラメータを取る。パラメータの 値は、RFC 3066[7]で定義されているように、language-tagである。また、パ ラメータの値は、RFC 3066で定義されているように、language-rangesのセッ トを指定した可能性もある。CPLサーバーは、リクエストで指定された language-rangesに対して、スクリプトで指定された各language-tagを確認す る。 language-rangesとlanguage-tagsのマッチ方法の詳細は、RFC 3066を参照のこ と。簡単に説明すると、language-rangeは、language-tagとまったく同一か、 language-tagの接頭辞とまったく同一であり、接頭辞に続く最初の文字が 「-」である場合に、マッチする。 発呼側が特殊なlanguage-range「*」を指定した場合、マッチングの目的から これは無視される。「0」の値の「q」を使用する言語も無視される。 このスイッチは提示しなくてもよい[MAY]。 4.3.1. 「language-switch」のSIPでの用法 「language-switch」スイッチのlanguage-rangesは、SIPの「Accept- Language」から取得される。最初のSIPリクエストにこのヘッダーフィールド が含まれない場合、スイッチは存在しない。 スイッチにおけるCPLの最初のマッチというセマンティクスのために、 「Accept-Language」ヘッダーフィールドの0以外の「q」値は無視されると いうことに注意。 Lennox, et al. Standards Track [Page 14] RFC 3880 CPL October 2004 4.4. タイムスイッチ time-switchによって、CPLスクリプトは、スクリプトが実行された時間か日付 (またはその両方)に基づいて、判断することができるようになる。図7に概要 を示す。 time-switchスイッチは基本のシグナリングプロトコルには依存しない。 ノード: 「time-switch」 出力: 「time」 マッチする指定時間 パラメータ: 「tzid」 RFC 2445タイムゾーン識別子 「tzurl」 RFC 2445タイムゾーンURL 出力: 「time」 パラメータ: 「dtstart」 間隔の開始(RFC 2445 DATE-TIME) 「dtend」 間隔の終了(RFC 2445 DATE-TIME) 「duration」 間隔の長さ(RFC 2445 DURATION) 「freq」 再帰頻度(「secondly」、「minutely」、 「 hourly」、「daily」、「weekly」、 「monthly」、「yearly」のいずれか) 「interval」 反復の繰り返し回数 「until」 反復の限度 (RFC 2445 DATE-TIME) 「count」 反復の発生数 「bysecond」 1分内の秒の一覧 「byminute」 1時間内の分の一覧 「byhour」 1日内の時間の一覧 「byday」 1週間の日の一覧 「bymonthday」 1月の日の一覧 「byyearday」 1年の日の一覧 「byweekno」 1年の週の一覧 「bymonth」 1年の月の一覧 「wkst」 作業週の最初の日 「bysetpos」 イベント指定のセット内の値のリスト 図7: 「time-switch」ノードの構文 time-switchは、RFC 2445[8]のInternet Calendaring and Scheduling Core Object Specification(iCalendar COS)における、時間の再帰間隔の仕様の多 くに基づいている。 これによって、CPLスクリプトをカレンダーから自動的に生成することがで きるようになる。また、時間間隔を指定する既存の作業の広範囲を、再利 用できるようにもなる。 将来的に、RFC 2445を更新したり、廃止する標準化過程のドキュメントが発行 される場合、そのドキュメントで再帰操作に加えられる変更または明確化は、 CPLのtime-switchにも同様に適用される。 Lennox, et al. Standards Track [Page 15] RFC 3880 CPL October 2004 ある瞬間が特定の再帰内に含まれるかどうかを判断するアルゴリズムは、付録 Aに示す。 「time-switch」タグは、「tzid」と「tzurl」という2つのオプションのパラ メータを取る。これらはどちらもRFC 2445(それぞれセクション4.8.3.1と4.8. 3.5)で定義される。「tzid」は、参照されるタイムゾーン定義を使用する識別 ラベルである。フォワードスラッシュ(スラッシュ)で始まる場合、定義予定の グローバルタイムゾーン登録を指す。それ以外の場合、サーバーでローカルに 定義される。「tzurl」は、タイムゾーンについて、最新のVTIMEZONE定義を取 得可能なネットワーク上の場所を指定する。 フォワードスラッシュで始まらない「tzid」ラベルはローカルで定義される が、サーバーは少なくとも、Olsonのタイムゾーンデータベース[9]に使用され る名前付けスキームに対応することが推奨される[RECOMMENDED]。Olsonスキー ムを使用するタイムゾーンデータベースの例は、ほとんどのUnix風システムに あるzoneinfoファイルと、標準のJava TimeZoneクラスである。 サーバーは、スクリプトのアップロード時に、「tzid」と「tzurl」参照をタ イムゾーン定義に解決すべきである[SHOULD]。定期的にこの解決を更新して、 最新のタイムゾーン定義を取得してもよい[MAY]。「tzurl」が無効になった場 合、サーバーはURLから取得した最新の有効データを記憶すべきである [SHOULD]。 スクリプトが、CPLサーバーが認識しない、または解決できない「tzid」と 「tzurl」を使用してアップロードされた場合、スクリプトのアップロード時 に、これを診断して拒否すべきである[SHOULD]。「tzid」または「tzurl」の どちらも存在しない場合、このtime-switch内のすべての非UTC時間は、「浮動 (floating)」時間(つまり、CPLサーバーのローカルタイムゾーンで指定され た)と解釈されるべきである。 サマータイムが1年の間に変わるため、特定のタイムゾーンでtime-switch を指定する必要がある。UTCオフセットでは十分ではない。つまり、米国東 部では午前9時から午後5時までを示す時間帯のルーティング規則は、10月 末からは午前8時から午後4時を示すようになる。 CPLサーバーの作者は、サマータイムの開始時と終了時に、ローカルタイムが 不連続になる間隔を、注意して正確に操作すべきである。特に注意が必要なの は、時計を遅らせる場合が2回以上発生する可能性がある、ということであ る。付録Aのアルゴリズムは、この点に正しく対応できると考えられている。 タイムノードは、出力を取得中に、期間のリストを指定する。必須のパラメー タが2つある。「dtstart」(リストの最初の期間について開始時間の指定)と、 「dtend」(終了時間の指定)または「duration」(期間の継続期間の指定)のい Lennox, et al. Standards Track [Page 16] RFC 3880 CPL October 2004 ずれかである。「dtstart」と「dtend」パラメータは、RFC 2445[8]のセク ション4.3.5で既定されるように、iCalendar COS DATE-TIME値としてフォー マットされる。タイムゾーンはトップレベルの「time-switch」タグで指定さ れるため、形式1または2(浮遊時間またはUTC時間)のみを使用できる。 「duration」パラメータは、RFC 2445のセクション4.3.6で既定されるよう に、iCalendar COS DURATIONパラメータとして指定される。DATE-TIMEと DURATIONの構文はいずれも、ISO 8601[20]の対応する構文のサブセットであ る。 再帰間隔の場合、「duration」パラメータは、後続の間隔が重複しない程度に 小さくしなければならない[MUST]。非再帰間隔の場合、長さが正の有効期間で あれば、許容される。長さが0または負の継続期間は、許可されない。 他にパラメータが指定されていない場合、タイムノードは1期間のみの時間を 示す。より複雑なセットの間隔は、反復として構成される。再帰は、「freq」 パラメータ(再帰規則の種類を示す)を含めることで指定される。 「dtstart」、「dtend」、「duration」以外のパラメータは、「freq」が存在 しない場合は指定すべきではない[SHOULD NOT]。ただし、CPLはこのようなパ ラメータが存在するスクリプトを受け入れて、他のパラメータを無視すべきで ある[SHOULD]。 「freq」パラメータは、以下の値のいずれかを取る。「secondly」は、1秒以 上の間隔に基づいて、繰り返し期間を指定する。「minutely」は、1分以上の 間隔に基づいて、繰り返し期間を指定する。「hourly」は、1時間以上の間隔 に基づいて、繰り返し期間を指定する。「daily」は、1日以上の間隔に基づい て、繰り返し期間を指定する。「weekly」は、1週以上の間隔に基づいて、繰 り返し期間を指定する。「monthly」は、1ヵ月以上の間隔に基づいて、繰り返 し期間を指定する。「yearly」は、1年以上の間隔に基づいて、繰り返し期間 を指定する。この値では、大文字小文字を区別しない。 「interval」パラメータには、再帰規則を繰り返す回数を示す正の整数が含ま れる。デフォルト値は「1」であり、「secondly」規則では毎秒、 「minutely」規則では毎分、「hourly」規則で毎時間、「daily」規則では毎 日、「weekly」規則では毎週、「monthly」規則では毎月、「yearly」規則で は毎年を意味する。 「until」パラメータは、包括的な方法で再帰規則を制約する、iCalendar COS DATEまたはDATE-TIMEの値を定義する。「until」で指定される値が指定した 再帰で同期される場合、この日付または日付時刻は、再帰の最終インスタン スになる。日付時刻値として指定される場合、UTC時間形式で指定されなけれ Lennox, et al. Standards Track [Page 17] RFC 3880 CPL October 2004 ばならない[MUST]。これが存在せず、「count」パラメータも存在しない場 合、再帰は永久的に繰り返されると考えられる。 「count」パラメータは、再帰を範囲指定するときの発生回数を定義する。 「dtstart」パラメータは、最初の発生としてカウントされる。「until」と 「count」パラメータは、同じ「time」出力に出現してはならない [MUST NOT]。 「bysecond」パラメータでは、1分以内の秒数をカンマ区切りにした一覧を指 定する。有効な値は0〜59である。「byminute」パラメータでは、1時間以内の 分数をカンマ区切りにした一覧を指定する。有効な値は0〜59である。 「byhour」パラメータでは、1日以内の時間数をカンマ区切りにした一覧を指 定する。有効な値は0〜23である。 「byday」パラメータでは、1週以内の日数をカンマ区切りにした一覧を指定す る。「MO」は月曜日、「TU」は火曜日、「WE」は水曜日、「TH」は木曜日、 「FR」は金曜日、「SA」は土曜日、「SU」は日曜日を示す。この値では、大文 字小文字を区別しない。 また、各「byday」値の前には、正の整数(+n)または負の整数(-n)を付けるこ とができる。このような整数が付く場合、「monthly」または「yealy」再帰内 で、特定日付のn番目の発生を示す。たとえば、「monthly」規則内で、+1MO (または単に1MO)はその月の最初の月曜日を示し、-1MOはその月の最終月曜日 を示す。整数の修飾子が存在しない場合、指定された頻度内で、このタイプの 日付すべてを意味する。たとえば、「monthly」規則内で、MOはその月の月曜 日すべてを示す。 「bymonthday」パラメータでは、1ヵ月以内の日数をカンマ区切りにした一覧 を指定する。有効な値は1〜31、または-31〜-1である。たとえば、-10は、そ の月の最終日から10日前を示す。 「byyearday」パラメータでは、1年以内の日数をカンマ区切りにした一覧を指 定する。有効な値は1〜366、または-366〜-1である。たとえば、-1はその年の 最終日(12月31日)を示し、-306はその年の最終日から306日前(3月1日)を示 す。 「byweekno」パラメータでは、1年の週を指定する序数をカンマ区切りにした 一覧を指定する。有効な値は1〜53、または-53〜-1である。 これは、ISO 8601[20]で定義されている週の番号付けに従った週に対応する。 1週は7日間と定義され、週の開始日(「wkst」を参照)と定義される週の日に開 始される。カレンダー年の週番号1は、そのカレンダー年の少なくとも4日を含 む最初の週である。このパラメータは、「yearly」規則の場合にのみ有効であ る。たとえば、3は、その年の3番目の週を示す。 Lennox, et al. Standards Track [Page 18] RFC 3880 CPL October 2004 注意: 月曜日が週の初めと仮定すると、木曜日が1月1日か、または閏年で 水曜日が1月1日の場合にのみ、週53が生じる。 「bymonth」パラメータでは、1年以内の月数をカンマ区切りにした一覧を指定 する。有効な値は1〜12である。 「wkst」パラメータは、週間の作業開始日を指定する。有効値は、「MO」、 「TU」、「WE」、「TH」、「FR」、「SA」、「SU」である。これは、 「weekly」の再帰が1よりも大きな間隔であり、「byday」パラメータが指定さ れている場合に重要である。また、「byweekno」パラメータが指定されている 場合にも、「yearly」の再帰で重要である。デフォルト値は、ISO 8601[20]に 従い、「MO」である。 「bysetpos」パラメータでは、規則で既定されたイベントセット内で、n番目 の発生に相当する値を、カンマ区切りにした一覧を指定する。有効な値は1〜 366、または-366〜-1である。これは、別のbyxxxパラメータと必ず同時に使用 しなければならない[MUST]。例えば、「その月の最終作業日」は以下のように 表される。