Network Working Group J. Rosenberg
Request for Comments: 4596 P. Kyzivat
Category: Informational Cisco Systems
July 2006
セッション開始プロトコル(SIP)発呼側プリファレンス拡張の使用方法
に関するガイドライン
Guidelines for Usage of the Session Initiation Protocol (SIP)
Caller Preferences Extension
本文書の位置付け
本文書は、インターネットコミュニティに情報を提供するためのものであ
る。いかなるインターネット標準も規定しない。本文書の配信は無制限で
ある。
著作権表記
Copyright (C) The Internet Society (2006).
概要
本文書には、セッション開始プロトコル(Session Initiation Protocol/SIP)
の発呼側プリファレンス拡張の使用方法に関するガイドラインを記載してい
る。また、具体的なアプリケーション例を使用して発呼側プリファレンスの
利点について説明し、適切な操作を示す使用例を提供し、登録されている
フィーチャータグの適用可能性に関するガイダンスを提供し、RFC 3741のセ
クション7.2に指定されているアルゴリズムに一致するプリファレンスと機
能の簡単な実装についても説明する。
Rosenberg & Kyzivat Informational [Page 1]
RFC 4596 Caller Preferences Uses July 2006
目次
1. はじめに ....................................................... 4
2. 発呼側プリファレンスの動機 ..................................... 5
2.1. ワンナンバー ............................................. 7
2.2. 音声メールへの直接発呼 ................................... 7
3. 発呼側プリファレンスの使用例 ................................... 8
3.1. 異なるUAに対するINVITEとMESSAGEのルーティング ............. 8
3.1.1. 目的の動作 ......................................... 8
3.1.2. 解決策 ............................................. 9
3.2. 暗黙的なプリファレンスに一致しない単一の連絡先 .......... 10
3.2.1. 目的の動作 ........................................ 10
3.2.2. 解決策 ............................................ 10
3.3. パッケージベースのルーティング .......................... 11
3.3.1. 目的の動作 ........................................ 11
3.3.2. 解決策 ............................................ 11
3.4. パッケージルーティングII ................................ 12
3.4.1. 目的の動作 ........................................ 12
3.4.2. 解決策 ............................................ 13
3.5. 音声/ビデオと音声のみ .................................... 13
3.5.1. 目的の動作 ........................................ 13
3.5.2. 解決策 ............................................ 14
3.6. 音声/ビデオの強制 ........................................ 15
3.6.1. 目的の動作 ........................................ 15
3.6.2. 解決策 ............................................ 15
3.7. サードパーティ呼制御: メディアの強制 .................... 16
3.7.1. 目的の動作 ........................................ 16
3.7.2. 解決策 ............................................ 16
3.8. メディアの重複の最大化 .................................. 17
3.8.1. 目的の動作 ........................................ 17
3.8.2. 解決策 ............................................ 17
3.9. 多言語回線 .............................................. 18
3.9.1. 目的の動作 ........................................ 18
3.9.2. 解決策 ............................................ 19
3.10. 音声メールの回避 ........................................ 20
3.10.1. 目的の動作 ...................................... 20
3.10.2. 解決策 .......................................... 20
3.11. 通話の回避 .............................................. 21
3.11.1. 目的の動作 ...................................... 21
3.11.2. 解決策 .......................................... 21
3.12. 音声メールの希望 ........................................ 22
3.12.1. 目的の動作 ...................................... 22
3.12.2. 解決策 .......................................... 22
3.13. 役員へのルーティング .................................... 22
3.13.1. 目的の動作 ...................................... 22
3.13.2. 解決策 .......................................... 22
Rosenberg & Kyzivat Informational [Page 2]
RFC 4596 Caller Preferences Uses July 2006
3.14. 役員との通話 ............................................ 23
3.14.1. 目的の動作 ...................................... 23
3.14.2. 解決策 .......................................... 24
3.15. 携帯電話のみ ............................................ 24
3.15.1. 目的の動作 ...................................... 24
3.15.2. 解決策 .......................................... 24
3.16. 同時の複数言語 .......................................... 25
3.16.1. 目的の動作 ...................................... 25
3.16.2. 解決策 .......................................... 25
3.17. 発信番号 ................................................ 26
3.17.1. 目的の動作 ...................................... 26
3.17.2. 解決策 .......................................... 26
3.18. 発信番号(その2) ........................................ 27
3.18.1. 目的の動作 ...................................... 27
3.18.2. 解決策 .......................................... 27
3.19. 同僚への転送 ............................................ 28
3.19.1. 目的の動作 ...................................... 28
3.19.2. 解決策 .......................................... 28
4. 能力の使用例 .................................................. 30
4.1. Webリダイレクト .......................................... 30
4.2. 音声メールのアイコン .................................... 30
5. フィーチャータグの用法 ........................................ 31
5.1. 伝統的な携帯電話 ........................................ 31
5.2. 伝統的なオフィス電話 .................................... 32
5.3. PCメッセージングアプリケーション ........................ 32
5.4. スタンドアロン型ビデオ電話 .............................. 33
6. プリファレンス/能力マッチングの実装例 ........................ 33
6.1. ヘッダーからのフィーチャーセットの抽出 .................. 34
6.2. フィーチャーパラメータからの値の抽出 .................... 35
6.3. 2つの値範囲の比較 ........................................ 36
6.4. フィーチャーセットどうしのマッチング .................... 36
6.5. 発呼側プリファレンスに基づく連絡先の選択と並べ替え ...... 37
6.5.1. Reject-Contactの処理 .............................. 37
6.5.2. Accept-Contactの処理 .............................. 37
7. セキュリティの考慮事項 ........................................ 38
8. 謝辞 .......................................................... 38
9. 有益な参考文献 ................................................ 38
Rosenberg & Kyzivat Informational [Page 3]
RFC 4596 Caller Preferences Uses July 2006
1. はじめに
着呼側能力[2]のセッション開始プロトコル(Session Initiation Protocol/
SIP) [1]拡張には、UA (User Agent)がREGISTERリクエストで機能を登録で
きるメカニズムが説明されている。発行者は、リクエストの処理方法に関す
るプリファレンス(好み)を明示的、または暗黙的に表現することができる。
この操作は、SIPの発呼側プリファレンス[3]で説明されている
Accept-ContactとReject-Contactの各ヘッダーフィールドで達成される。
発呼側プリファレンス拡張は、多数のアプリケーションを支援する有効な
ツールとして役立っている。ただし、その汎用性のために、どのような状況
でも正しくまた効率的に使用するのが困難になっている。この問題を改善す
るために、本文書は、発呼側プリファレンス拡張の使用例の概要としての機
能を果たす。
注意: 本文書の意図は、読者がRFC 3840と3841を理解できるよう支援する
ことである。両文書を読む代わりになることは意図していない。RFC 3840
と3841に定義されているメカニズムを意識せずに、本文書に記載してい
る例を完全に理解することはできない。
まず、セクション2では、発呼側プリファレンス拡張によって可能になるいく
つかの具体的なアプリケーションについて説明することで、拡張を使用する
利点について明示している。セクション3では、発呼側プリファレンスを表現
する詳細な使用例について説明する。各使用例では、状況を提示し、発呼側
プリファレンスを使用してその状況の要件を処理する方法について説明し、
一致する操作の結果を示すことで目的の動作が発生したことを検証する。
これらの使用例によって、発呼側プリファレンス仕様が完成しており、特定
の要件群を満たすことができる、ということが実証される。
発呼側プリファレンス仕様は、SIPの変更処理[4]よりも先に発行されたの
で、[4]に対する要件の文書は発行されなかった。本文書は、ある程度まで
要件を「埋め戻す(backfill)」。ただし、これは学問的な実験ではない。と
いうのも、本文書の使用例の発展にしたがって、結果的に発呼側プリファレ
ンス文書が変更されたためである。また、本文書の使用例によって、実装者
はアプリケーションに発呼側プリファレンスを使用する方法を理解すること
もできる。
セクション4では、着呼側能力仕様に関するアプリケーションについて論じ
ている。セクション5では、[2]に記載されているフィーチャータグの登録例
について論じている。発呼側プリファレンスの正しい使用方法は、フィー
チャータグタグのセマンティクスを正しく解釈することに左右される。タグ
の詳細と、一般的な使用方法の登録例についても提示する。
Rosenberg & Kyzivat Informational [Page 4]
RFC 4596 Caller Preferences Uses July 2006
セクション6では、ほとんどの部分でRFC 2533 [6]を実装する必要がない、
マッチングアルゴリズムに対する実装アプローチの概要を説明する。
2. 発呼側プリファレンスの動機
本質的に、SIPはユーザーの待ち合わせを容易にするプロトコルである。
発呼側と着呼側は、通信を可能にするセッション情報を交換するために、待
ち合わせる必要がある。ユーザーがネットワークに接続するポイントは複数
あるため、待ち合わせ処理は複雑である。着呼ユーザー(着呼側)は、たとえ
ば携帯電話、PDA、オフィス電話、自宅電話、複数あるPCベースの通信アプ
リケーションのいずれかを持っている可能性がある。誰かがそのユーザーに
発呼した場合、どのデバイスにその呼がルーティングされるだろうか。
確かに、呼はすべてのデバイスへ同時にルーティングすることもできる。こ
の処理は、並行フォーキングと呼ばれる。ただし、そのような動作が常に望
ましい訳ではない。ユーザーの好みとして、特定の順序で登録デバイスを試
行されることが望まれる場合がある。たとえば、携帯電話に最初に電話を
かけ、応答がない場合、オフィス電話にかけることを好むユーザーがいる。
また、携帯電話に最初に電話をかけ、次に自宅電話とオフィス電話に同時に
かけ、いずれも応答がない場合、音声メールに転送することを好むユーザー
もいる。このような多様性は、find-me/follow-me機能と呼ばれる。
SIPは多様な方法でfind-me/follow-me機能に対応している。最も基本的な方
法は、SIPの登録処理によるものである。ユーザーに連絡できる各デバイス
は、ネットワークに登録される。この登録によって、Addresses-of-Record
(AOR)と呼ばれるユーザーの標準名(canonical name)とデバイスとが関連付
けられる。AORはSIP URIである。各登録にはプリファレンス値を含めること
ができる。プリファレンス値は、他のデバイスと比較して、そのデバイスで
呼を受信する相対的な優先度を示す。誰かがそのAORに発呼すると、
RFC 3261準拠のプロキシは、管理ポリシーがユーザーのプリファレンスより
優先されない限り、プリファレンスの順に登録デバイスを試行する。
SIP登録のプリファレンス値にできるのは、基本的なfind-me/follow-me機能
を提供することだけである。より複雑な機能に対応するために、呼処理言語
(Call Processing Language/CPL) [5]が規定された。CPLは、特定の呼ルー
ティング指示を提示するXMLスクリプトである。ユーザーはそのスクリプト
をネットワークにアップロードし、サーバーに対して呼のルーティング方法
を指示することができる。たとえば、CPLスクリプトによって、家族からの
電話は常に携帯電話にルーティングし、勤務時間(午前9時～午後5時)はオ
フィス電話に呼をルーティングし、勤務時間後は携帯電話にルーティングす
るようにプロキシに指示することができる。
Rosenberg & Kyzivat Informational [Page 5]
RFC 4596 Caller Preferences Uses July 2006
CPLスクリプトと登録のプリファレンス値のどちらも、着呼側の観点からサー
ビスの操作について記述している、という点に注意する必要がある。つま
り、これらは着呼側に対する呼をネットワークがルーティングする方法につ
いて記述している。ただし、好みがあるのは着呼側だけではない。発呼側に
も呼のルーティング方法に関する好みがある。たとえば、携帯電話に連絡を
取りたい場合はよくある。現在の電話網では、この処理を実現するには、
ユーザーがデバイスごとに別の番号を持つ必要がある。この方法では、発呼
側が携帯電話に連絡する場合、携帯電話の番号をダイヤルする。この場合、
ユーザーは相手の連絡先番号のリストを保持し、適切な番号を選択する必要
がある。はるかに優れたアプローチは、ユーザーが単一の
Addresses-of-Recordを保持することである。誰かが相手の携帯電話に連絡
を取りたい場合、AORに発呼する。ただし、携帯電話に呼をルーティングす
るというプリファレンスを指定する。
実際のところ、発呼側は、呼のルーティング方法について幅広い好みを持っ
ている可能性がある。たとえば、直接音声メールに発呼することを好む場合
がある。
音声メールには発呼しないことを好む場合もある。また、ビデオに対応する
デバイスで連絡を取ることを好む場合がある(ビデオ会議が望ましいため)。
さらに、ユーザーが在席していないときは、応答できる受付係がいるデバイ
スに連絡を取りたい場合もある。
SIP発呼側プリファレンス拡張を使用すると、発呼を処理する方法について、
発呼側がこうした好みを表現することができる。このような好みは、目的の
デバイスのプロパティに関して表現される。デバイスのプロパティとは、デ
バイスに関する何らかの情報を伝達する名前と値のペアである。たとえば、
プロパティ「mobility」には、「mobile」や「fixed」という値が考えられ
る。発呼側が携帯電話に連絡を取りたい場合、呼のセットアップリクエスト
(INVITEメソッド)に、プロパティ「mobility」が「mobile」に設定されたデ
バイスに呼をルーティングすべきである、と示す情報を含める。デバイスが
ネットワークに登録されるときに、デバイスは登録の一部として自身のプロ
パティ(着呼側能力とも呼ばれる)を含める。この方法で、プロキシは、発呼
側プリファレンスと、ユーザーに登録されている多様なデバイスの能力とを
対応付け、適切に呼をルーティングする。
本文書は発呼側プリファレンスを扱っているが、発呼側を表すSIPユーザー
エージェントの観点から扱っている。
本文書の発呼側プリファレンスは、SIPリクエストに配置された構文上の要素
を使用して表現される。本文書は、人間のユーザーからユーザーエージェン
トに対してプリファレンスを伝達する方法については扱うつもりはない。
したがって、本文書は、ユーザーエージェントの開発者にとって、最も価値
ある存在になる可能性がある。
Rosenberg & Kyzivat Informational [Page 6]
RFC 4596 Caller Preferences Uses July 2006
発呼側プリファレンス拡張は、多様な呼のルーティングアプリケーションと
機能に対応することができる。特に重要な例の2つは、「ワンナンバー」と
「音声メールへの直接発呼」である。
2.1. ワンナンバー
現在の回路交換式電話網では、ユーザーは複数のデバイスを持ち、各デバイ
スには異なる電話番号が関連付けられている。一般的に、ユーザーはそのよ
うな番号をすべて名刺に列挙している。携帯電話、オフィス電話、自宅のオ
フィス電話などである。また、すべての番号を保存し、管理する必要がある
ユーザーもいる。番号を完全で最新の状態に維持するのは困難である。さら
に悪いことに、誰かに電話をかけたいときは、試す番号を選択する必要があ
る。あるときは特定のデバイス(携帯電話)に連絡したいが、またあるときは
どのデバイスでも連絡したい場合がある。後者の場合、ユーザーは1回に1つ
ずつ、各番号を試すことを強いられる。これは非効率的であり、たとえば運
転中にそのような操作は困難である。
代替案として、ユーザーは単一のアドレスを持つことができる。これは、他
のユーザーに名刺で渡す唯一無二のアドレスである。発呼側が携帯電話に連
絡を取りたい場合、その唯一のアドレスを選択し、デバイスの種類のプルダ
ウンメニューにアクセスする。このメニューには、自宅電話、オフィス電
話、携帯電話が含まれる。発呼側が携帯電話を選択すると、携帯電話に対し
て発呼される。ユーザーは2つ以上の番号を管理または保守する必要はなく
なる。単一の番号で十分になるのである。
一方、発呼側が、どのデバイスであろうとユーザーに連絡を取りたい場合、
1つの番号に発呼し、好みのデバイスは選択しない。ネットワークは同時に
全デバイスに発呼するため、できるだけ速くユーザーに連絡を取ることがで
きる。
このワンナンバーサービスには発呼側プリファレンスが利用される。携帯電
話のプリファレンスを表現するには、発呼側のデバイスはSIP INVITEリクエ
ストにヘッダーを含め、「mobility」が「mobile」のデバイスに連絡を取る
という希望を示す。
2.2. 音声メールへの直接発呼
多くの場合、移動中の多忙な役員は、同僚に対してメッセージを音声で迅速
に渡すことを希望する。たとえば、上司が従業員に対して、特定の顧客に電
話し、保留中の問題を解決するように指示する場合がある。このような場
合、その上司は従業員と実際に話したい訳ではない。単に音声メッセージを
残したいだけである。電話での会話には長時間かかる可能性があるが、音声
メッセージは短時間で要領を得た内容にすることができる。また、音声メッ
セージは目的の内容の正確な記録として役立つ一方、流れ去る音声の会話は
忘れられたり、間違って記憶されたりする可能性がある。
Rosenberg & Kyzivat Informational [Page 7]
RFC 4596 Caller Preferences Uses July 2006
現在の回路交換式電話網では、多くの場合、誰かの音声メールに直接発呼し
てメッセージを残す方法はない。場合によっては、音声メールシステムのメ
イン番号にダイヤルし、目的の相手の内線番号を入力し、特定のプロンプト
を入力することでメッセージを残す可能性もある。この操作には時間がかか
り、発呼側がメインの音声メッセージ番号を知っている必要がある。
または、携帯電話のアドレス帳に、「音声メッセージを残す」というアドレ
ス帳の各エントリに使用できるオプションがある可能性もある。
このオプションを選択すると、そのユーザーの音声メッセージに直接発呼さ
れる。音声メッセージが直ちに選択され、メッセージのプロンプトが示され
る。実際には短いあいさつが再生されるので、発呼側は録音手順へ直接進む
ことができる。
そのため、発呼側の時間が節約され、多数の相手に録音メッセージを迅速に
残すことも非常に容易である。
この機能は、発呼側プリファレンス拡張を使用して実現できる。
ユーザーが「音声メッセージを残す」オプションを選択すると、電話はSIP
INVITEリクエストを送信し、「msgserver」属性の値が「true」のデバイス
を好むことを示す発呼側プリファレンスヘッダーフィールドを含める。この
結果、プロキシは登録済みの音声メッセージサービスに直接呼をルーティン
グする。さらに、発呼側が音声メッセージへの直接発呼を要求していること
を音声メッセージサーバーが認識すると、そのような場合に明示的に指定さ
れている短いあいさつを再生することができる。
3. 発呼側プリファレンスの使用例
各使用例には、状況と目的の動作を併記している。また、多様な発呼側プリ
ファレンスヘッダーとプロキシの処理ロジックが、最終的に適切な決定にな
る方法についても例示している。
3.1. 異なるUAに対するINVITEとMESSAGEのルーティング
3.1.1. 目的の動作
Addresses-of-Record (AOR) Yには、Y1とY2という2つの連絡先がある。Y1は
電話であり、標準操作のINVITE、ACK、OPTIONS、BYE、CANCELに対応している
がMESSAGEに対応していない。一方、Y2はポケベルであり、OPTIONSとMESSAGE
のみをに対応している。発呼側XはポケベルメッセージをYに送信することを
望んでいる。通話とポケベルの両ネットワークには多数のトラフィックがあ
るため、対応できないデバイスにメッセージを分岐する必要はない、という
目標がある。したがって、この処理は、YのINVITEはY1にのみ配信し、Yに対
するMESSAGEはY2にのみ配信することで達成される。
Rosenberg & Kyzivat Informational [Page 8]
RFC 4596 Caller Preferences Uses July 2006
3.1.2. 解決策
Y1は以下のような登録(抜粋)を作成する。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact:<sip:Y1@pc.example.com>
;methods="INVITE,ACK,OPTIONS,BYE,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip"
;mobility="mobile"
Y2は以下のような登録(抜粋)を作成する。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc.example.com>
;methods="OPTIONS,MESSAGE"
;uri-user="<Y2>"
;uri-domain="example.com"
;+sip.message
;schemes="sip,im"
;mobility="mobile"
UAC (User Agent Client/ユーザーエージェントクライアント)がINVITEを送
信すると、example.comのプロキシに到達する。リクエストに発呼側プリファ
レンスはない。ただし、[3]のセクション7.2.2に従って、以下のような暗黙
的なrequireフラグ付きAccept-Contactプリファレンスをプロキシは構築
する。
(& (sip.methods="INVITE"))
RFC 2533 [6]のマッチングアルゴリズムを、このフィーチャーセットとY1と
Y2が登録したフィーチャーセットに適用すると、Y1のフィーチャーセットの
みが一致する。Accept-Contactの述部にはrequireフラグが設定されている
ため、Y2は破棄され、INVITEはY1にルーティングされる。
リクエストがMESSAGEだった場合、プロキシは、以下のようにrequireフラグ
が設定された(requireフラグ付き)暗黙的なAccept-Contactのプリファレン
スを構築する。
(& (sip.methods="MESSAGE"))
これはY2のフィーチャーセットには一致するが、Y1には一致しない。した
がって、Y1は破棄され、リクエストはY2にルーティングされる。
Rosenberg & Kyzivat Informational [Page 9]
RFC 4596 Caller Preferences Uses July 2006
3.2. 暗黙的なプリファレンスに一致しない単一の連絡先
3.2.1. 目的の動作
AOR YにはY1という単一の連絡先しかない。これは電話なので、標準的な操作
のINVITE、ACK、OPTIONS、BYE、CANCELには対応しているが、MESSAGEには対
応していない。発呼側XはMESSAGEリクエストを送信する。目的の動作は、そ
の単一の連絡先が405応答が生成できるように、リクエストがそこにルーティ
ングされることである。
3.2.2. 解決策
単一の連絡先Y1は以下のような登録(抜粋)を生成する。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>
;methods="INVITE,ACK,OPTIONS,BYE,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip"
;mobility="fixed"
;class="personal"
XはMESSAGEリクエストを送信する。明示的な発呼側プリファレンスはない。
その結果は、以下のように暗黙的なrequireフラグ付きAccept-Contactプリ
ファレンスである。
(& (sip.methods="MESSAGE"))
Y1は一致せず、Accept-Contact述部にはrequireフラグが設定されているた
め、Y1は破棄される。ただし、RFC 3841のセクション7.2.4に従って、一致
するターゲットがない場合、元のターゲットセットが使用される。そのた
め、リクエストは、要望どおりに1つの元のターゲットであるY1へ送信され
る。そしてY1は405で応答する。
複数の連絡先があり、いずれもAccept-Contact述部に一致しなかった場合、
すべての連絡先を含む元のターゲットセットが復元される。そして、すべて
の連絡先がRFC 3261のセクション16.6に従って処理される。
Rosenberg & Kyzivat Informational [Page 10]
RFC 4596 Caller Preferences Uses July 2006
3.3. パッケージベースのルーティング
3.3.1. 目的の動作
AOR YにはY1、Y2、…Ynという複数の連絡先がある。それぞれ、標準的な操作
のINVITE、ACK、OPTIONS、BYE、CANCELに対応し、「dialog」イベントパッ
ケージ[7]のSUBSCRIBEにも対応している。YにはYpという別の連絡先もあり、
これはプレゼンスエージェント(presence agent/PA) [8]である。Ypは
「presence」イベントパッケージのSUBSCRIBEリクエストにのみ対応するこ
とができる。
目標は、プレゼンスのSUBSCRIBEリクエストはYpにルーティングされ、ダイア
ログパッケージのINVITEとSUBSCRIBEはY1…Ynに分岐されることである。
3.3.2. 解決策
Y1…Ynは以下のようなREGISTERリクエスト(抜粋)を生成する。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Yi@pc.example.com>
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE"
;events="dialog"
;uri-user="<Yi>"
;uri-domain="example.com"
;audio
;schemes="sip"
;mobility="fixed"
;class="personal"
また、Ypは以下のようなREGISTERリクエスト(抜粋)を生成する。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Yp@pc.example.com>;methods="SUBSCRIBE"
;events="presence"
;uri-user="<Yp>"
;uri-domain="example.com"
;schemes="sip,pres"
;mobility="fixed"
;class="business"
プレゼンスのSUBSCRIBEリクエストは、example.comのプロキシに到達する。
明示的なプリファレンスはないため、リクエストから暗黙的なrequireフラ
グ付きAccept-Contactプリファレンスが構築される。
(& (sip.methods="SUBSCRIBE") (sip.events="presence"))
Rosenberg & Kyzivat Informational [Page 11]
RFC 4596 Caller Preferences Uses July 2006
RFC 3841のセクション7.2.4に従い、このフィーチャーセットはYpが登録した
フィーチャーセットにのみ一致する。requireフラグが設定されているため、
一致しない連絡先はターゲットセットから削除される。
したがって、Y1…Ynは破棄される。リクエストは残りの連絡先であり、PAを
表すYpに送信される。
明示的なプリファレンス値がないINVITEリクエストは、結果的に、以下のよ
うな暗黙的なrequireフラグ付きAccept-Contactプリファレンスになる。
(& (sip.methods="INVITE"))
暗黙的なAccept-ContactフィーチャーセットはY1...Ynに一致するが、Ypには
一致しない。RFC 3841のセクション7.2.4の採点アルゴリズムを使用すると、
この述部に対するY1...Ynのスコアは1.0である。結果として、各連絡先の発
呼側プリファレンスQaは1.0である。登録にはq値が含まれていなかったた
め、1.0のデフォルトq値が各Contact URIに適用される。発呼側および着呼
側のプリファレンスは同じですべて1.0なので、連絡先の並べ替えはない。
その結果、プロキシは、Y1...Ynをリクエストのターゲットとして同一の価
値があると考え、恐らく、リクエストをそれぞれに分岐させる。
明示的なプリファレンスがないdialogイベントパッケージのSUBSCRIBEリクエ
ストは、結果として暗黙的なrequireフラグ付きAccept-Contactプリファレン
スになる。
(& (sip.methods="SUBSCRIBE") (sip.events="dialog"))
これはY1...Ynにのみ一致するので、Ypは破棄され、リクエストはINVITEと
同様に残りの連絡先にルーティングされる。
3.4. パッケージルーティングII
3.4.1. 目的の動作
このケースは、セクション3.3とほぼ同じである。ただし、Y1...Ynは登録か
ら「events」フィーチャータグを削除している。Ypの登録方法はセクション
3.3と同じである。ここでも、presenceイベントパッケージのSUBSCRIBEは、
Ypにルーティングされるのが望ましい。
Rosenberg & Kyzivat Informational [Page 12]
RFC 4596 Caller Preferences Uses July 2006
3.4.2. 解決策
Y1...Ynの登録は以下のようになる。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Yi@pc.example.com>
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE"
;uri-user="<Yi>"
;uri-domain="example.com"
;audio
;schemes="sip"
;mobility="fixed"
;class="personal"
発呼側が(明示的なプリファレンスなしで) presenceイベントパッケージの
SUBSCRIBEを送信すると、プロキシは以下のように暗黙的なプリファレンスを
計算する。
(& (sip.methods="SUBSCRIBE") (sip.events="presence"))
この述部はY1…YnとYpに一致する。ただし、この述部に対するY1…Ynのスコ
アは0.5であり、Ypのスコアは1.0である。結果として、Y1...Ynの発呼側プリ
ファレンスQaは0.5であり、Ypの発呼側プリファレンスQaは1.0である。着呼
側はq値を提示しなかったため、プロキシはデフォルトの1.0を仮定する。そ
のため、すべての連絡先は同じ等価クラスに含まれる。これらの連絡先はQa
で並べ替えられるため、Ypが最初になり、Y1～Ynが続く。したがって、リク
エストはまずYpにルーティングされ、それが失敗すると、Y1…Ynにルーティ
ングされる。
3.5. 音声/ビデオと音声のみ
3.5.1. 目的の動作
Xは、音声/ビデオ通話を開始する招待をYに送信する。この招待のSDPには、
m=audio行とm=video行の両方が含まれる。AOR YにはY1とY2という2つの連絡
先がある。Y1は通常の音声電話を表し、YはY1で通話を受け取りたいと考え
ている。Y1は音声/ビデオ通話に応答するが、ビデオは拒否する。Y2は、必要
な場合にのみ使用される音声/ビデオ電話を表す。発呼側は、ビデオに対応す
るデバイスが発呼に応答することを本当は望んでいるが、第2の選択肢とし
て、音声のみの通話も受け入れる。
Rosenberg & Kyzivat Informational [Page 13]
RFC 4596 Caller Preferences Uses July 2006
3.5.2. 解決策
Y1は以下のような登録(抜粋)を生成する。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>;q=1.0
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip,tel"
;mobility="fixed"
;class="business"
Y2は以下のような登録(抜粋)を生成する。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc.example.com>;q=0.6
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<Y2>"
;uri-domain="example.com"
;audio
;video
;schemes="sip,tel"
;mobility="fixed"
;class="business"
q値が異なると、「最後の手段」のデバイスとしてY2を選択できるというこ
とに注意。
ビデオに対応するデバイスへ優先的に呼をルーティングさせるには、発呼側
Xが以下のようなINVITE(抜粋)を送信する。
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *
;methods="INVITE"
;video
プロキシはこれをフィーチャーセットに変換する。このフィーチャーセット
はY2とY1に一致する。ただし、Y2のスコアは1.0であり、Y1は0.5である。
2つの連絡先はq値によって並べ替えられ、等価クラスに分類される。等価ク
ラスは2つあり、それぞれに1つの連絡先がある。結果として、発呼側プリ
ファレンス値は並べ替えに何も影響を及ぼさない。発呼は、より優先度が高
いY1がまず試行され、Y1は発呼に応答し、ビデオストリームを拒否する。そ
のため、目的の動作は達成されない。
Rosenberg & Kyzivat Informational [Page 14]
RFC 4596 Caller Preferences Uses July 2006
目的の動作を達成するには、INVITEのAccept-Contactヘッダーフィールドに
「explicit」タグと「require」タグを追加する(セクション3.6参照)。ただ
し、この処理の結果、通話はできるがビデオがない場合、通話が失敗する結
果になる可能性もある。[3]で議論されているように、「require」タグと
「explicit」タグはどちらも、プリファレンスが一致しない限りリクエスト
をどのような方法でもサービスできない場合にのみ、使用されるのが一般的
である。これは、このセクションのケースではない。
3.6. 音声/ビデオの強制
3.6.1. 目的の動作
このケースは、セクション3.5と似ている。ただし、Xは音声/ビデオ通話を必
須とし、それが不可能な場合は、音声通話を成立させるのではなく、通話を
失敗させたいと考えている。
3.6.2. 解決策
解決策はセクション3.5と似ているが、Accept-Contactヘッダーフィールドに
は以下のように「explicit」タグと「require」タグが含まれる。そのため、
明示的にビデオへの対応を指定していないUAとの間に通話は成立しない。
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;video;require;explicit
これはexample.comプロキシに到達する。この明示的なフィーチャーセット
は、Y2とY1のフィーチャーセットに一致する。ただし、Y1の一致スコアは1で
はない。「explicit」タグと「require」タグが提示されているため、Y1は破
棄される。そのため、Y2のみが残る。したがって、呼はビデオ電話にルー
ティングされるが、ユーザーがそこにいない場合でも、音声電話は鳴らな
い。
「require」タグと「explicit」タグの両方が提示されているため、ビデオ
への対応を示すフィーチャータグを含まない連絡先は破棄される。したがっ
て、ビデオに対応していても、そのことを示していないUAの場合、このケー
スではそのUAに到達しない。これが、UAはすべての能力を示すことが重要で
ある、という理由である。
この問題は、複数の能力を示しているがビデオは示していない連絡先につい
てのみ当てはまる、ということに注意。何も能力を示していない連絡先は、
発呼側プリファレンスから「免除(immune)」されるので、破棄されない。
Rosenberg & Kyzivat Informational [Page 15]
RFC 4596 Caller Preferences Uses July 2006
3.7. サードパーティ呼制御: メディアの強制
3.7.1. 目的の動作
Zはサードパーティ呼制御(3pcc)コントローラ[9]であり、XからYへの音声/
ビデオを確立しようとしている。XにはX1とX2、YにはY1とY2という連絡先が
ある。X1とX2には、それぞれY1とY2と同じ能力がある。Zはオファーなしの招
待をXに送信し、Xから提示されるオファーを使用してYに招待を送信する必要
がある。オファーなしの招待をXに送信するとき、3pccコントローラは、音声
のみの連絡先(X1)よりも音声/ビデオの連絡先(X2)が選択されるように確保
する必要がある。
3.7.2. 解決策
X1は以下のような登録(抜粋)を生成する。
REGISTER sip:example.com SIP/2.0
To: sip:X@example.com
Contact: <sip:X1@pc.example.com>;q=1.0
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<X1>"
;uri-domain="example.com"
;audio
;schemes="sip,tel"
;mobility="fixed"
;class="business"
X2は以下のような登録(抜粋)を生成する。
REGISTER sip:example.com SIP/2.0
To: sip:X@example.com
Contact: <sip:X2@pc.example.com>;q=0.6
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<X2>"
;uri-domain="example.com"
;audio
;video
;schemes="sip,tel"
;mobility="fixed"
;class="business"
ZはINVITEに以下のようなAccept-Contactヘッダーフィールドを含める。
INVITE sip:X@example.com SIP/2.0
Accept-Contact: *;audio;video;require;explicit
Rosenberg & Kyzivat Informational [Page 16]
RFC 4596 Caller Preferences Uses July 2006
この発呼側プリファレンスはX1とX2の両方に一致する。ただし、一致するの
はスコアが0.5のX1とスコアが1のX2である。「require」タグと「explicit」
タグがあるため、Xのプリファレンスに関係なく、X1は破棄される。した
がって、呼はX2にルーティングされる。
セクション3.6と同じ注意がここでも適用される。一般的に、リクエスト処理
に厳密には必要ではない機能(ビデオ)への対応を必須とするのは推奨されな
い。
3.8. メディアの重複の最大化
3.8.1. 目的の動作
AOR Yには2つの連絡先がある。Y1は通常の音声電話で、Y2は音声とセッショ
ン指向IM [10]の両方に対応可能なPCである。Xは、音声、ビデオ、セッショ
ン指向IMに対応可能なPCである。Xは音声通話を確立する目的でYに発呼す
る。ただし、Xは、発呼側が使用できる機能を最大にするために、Xのメディ
ア能力と最大限に重複するデバイスと接続することを希望している。
3.8.2. 解決策
Y1は以下のような登録(抜粋)を生成する。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@phone.example.com>
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip,tel"
;mobility="fixed"
;class="business"
Rosenberg & Kyzivat Informational [Page 17]
RFC 4596 Caller Preferences Uses July 2006
Y2は以下のような登録(抜粋)を生成する。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc.example.com>
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,MESSAGE"
;uri-user="<Y2>"
;uri-domain="example.com"
;audio
;+sip.message
;schemes="sip,tel"
;mobility="fixed"
;class="business"
この解決策には、発呼側が発呼側プリファレンスに対応する必要がある。発
呼側は、INVITEに、対応するメディアタイプをすべて列挙した
Accept-Contactヘッダーフィールドを含める。この場合、以下のようにな
る。
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;audio;video;+sip.message
Y1とY2の両方がこの述部に一致する。Y1は0.33のスコアで一致し、Y2は0.66
のスコアで一致する。Accept-Contact述部は1つしかないため、各連絡先のQa
はスコアと等価である。
登録済みの連絡先はq値によって並べ替えられ、等価クラスに分類される。
1.0のq値を持つ等価クラスは1である。このクラスの2つの連絡先は、Qa値に
基づいて並べ替えされる。Y2の方がQaが高いため、最初に使用され、その次
にY1が使用される。その結果、要望どおり、メディア能力が最大限に重複す
るデバイスに呼がルーティングされる。
連絡先を除外する意図はなく、順序を付けるだけなので、「require」タグ
も「explicit」タグも使用されていないことに注意。
3.9. 多言語回線
3.9.1. 目的の動作
AOR Yはオフィスの共有回線を表す。オフィス内の複数の従業員は、Yに対し
て電話を登録している。従業員の一部は英語のみを話し、一部はスペイン語
を流ちょうに話すが英語能力はあまりなく、一部は英語とスペイン語の両方
を流ちょうに話す。英語のみを話す発呼側からの呼は、英語を流ちょうに話
す全従業員に並行して分岐される。呼に応答がない場合、英語を少し話す従
業員の電話が鳴る。スペイン語のみを話す発呼側からの呼は、スペイン語を
話す従業員にのみ分岐される。
Rosenberg & Kyzivat Informational [Page 18]
RFC 4596 Caller Preferences Uses July 2006
3.9.2. 解決策
英語のみを話すY1電話のユーザーは、以下のようなREGISTER (抜粋)を生成
する。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>;languages="en"
スペイン語を話し、英語は少ししか話せない電話Y2のユーザーは、以下のよ
うなREGISTER (抜粋)を生成する。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2-es@pc2.example.com>;languages="es"
Contact: <sip:Y2-en@pc2.example.com>;languages="en";q=0.2
Y2には2つの連絡先が登録されている。そのいずれも、同じデバイス
(pc2.example.com)にルーティングされるが、対応する言語と相対的なq値が
異なる。着呼に関して、異なる機能コレクションには異なるプリファレンス
を表現したいUAには、常に複数の連絡先が必要である。
英語とスペイン語を流ちょうに話すY3電話のユーザーは、以下のような
REGISTER(抜粋)を生成する。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y3@pc3.example.com>;languages="es,en"
同じq値がすべての機能コレクションに適用されるため、必要な連絡先は1つ
のみであることに注意。
言語ベースのルーティングを発生させるには、以下のように発呼側が言語プ
リファレンスを明示的に示す必要がある。
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;languages="en";require
ここから以下のような述部が派生する。
(& (languages="en"))
これは、Y1の1つの連絡先、Y2用に登録された2つ目の連絡先、Y3の1つの連絡
先に一致する。いずれもスコアは1.0である。Y2が登録した最初の連絡先は一
致せず、「require」フラグがあるため、Y2は破棄される。残りの連絡先はq
値によって並べ替えられ、等価クラスに分類される。2つの等値クラスがあ
Rosenberg & Kyzivat Informational [Page 19]
RFC 4596 Caller Preferences Uses July 2006
る。最初のクラスにはq値が1.0のY1とY3が含まれ、2つ目のクラスにはq値が
0.2のY2-enが含まれる。最初のクラスの連絡先は、Qaによって並べ替えられ
る。ただし、すべての連絡先のQaは同じ値(1.0)なので、順序に変更はない。
そのため、Y1とY3が最初に試行され、次にY2-enが試行される。これが目的
の動作である。
「explicit」タグは使用されない。使用すると、言語について触れていない
連絡先が除外されるためである。
そのため、スペイン語のみを話す発呼側は、以下のようにプリファレンスを
指定する。
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;languages="es";require
これは、Y2電話の最初の連絡先とY3電話に一致する。これらのスコアはいず
れも1.0である。Y2の英語の連絡先であるY2-enは一致せず、「require」タグ
があるため破棄される。残りの連絡先はq値によって並べ替えられ(Y3、
Y2-es)、両方の連絡先を含む1つの等価クラスに分類される。両方の連絡先
のQaは同じ(1.0)であるため、並べ替えはない。結果として、呼はY3または
Y2-esにルーティングされる。
3.10. 音声メールの回避
3.10.1. 目的の動作
AOR Yには、電話1と音声メールサービスY2という2つの連絡先がある。XはYに
発呼し、じかに話したいと希望している。Xは、どのような状況でも音声メー
ルを送信したくない。
3.10.2. 解決策
この電話は、以下のようなContact (抜粋)で登録する。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>
;audio
;mobility="fixed"
Rosenberg & Kyzivat Informational [Page 20]
RFC 4596 Caller Preferences Uses July 2006
音声メールサーバーは、以下のようなContact (抜粋)で登録する。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc.example.com>
;msgserver
;automata
;attendant
;audio
;q=0.2
電話が鳴った後にのみ音声メールサーバーが使用されるように、音声メール
サーバーは低いq値で登録する。実際のところ、音声メールサーバーは登録す
る必要がないことに注意。代わりに、1つの設定済み連絡先とその連絡先よう
に定義されたフィーチャーセットを用意することができる。
発呼側が音声メールを回避したい場合、明示的なプリファレンスを含めて回
避することができる。発呼側は、以下のようにReject-Contactヘッダー
フィールドでこの処理を実行する。
INVITE sip:Y@example.com SIP/2.0
Reject-Contact: *;msgserver
このフィーチャーセットには、Y1の登録に含まれないフィーチャータグが含
まれるため、Y1を確認するときにこのフィーチャーセットは破棄される。た
だし、Y2の登録にはフィーチャーセットに列挙されているすべてのフィー
チャータグが含まれるため、規則が確認される。一致があるため、Y2は破棄
される。結果として、このユーザーには音声メールがルーティングされな
い。
3.11. 通話の回避
3.11.1. 目的の動作
状況はセクション3.10に似ているが、発呼側はじかに相手と話すのではな
く、単にメッセージを残したいだけ、という点が異なる。
3.11.2. 解決策
発呼側は以下のようなINVITE (抜粋)を送信する。
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;msgserver;require;explicit
この発呼側プリファレンスはY1とY2の両方に一致する。Y1は一致するが、ス
コアは0である。Y2は一致し、スコアは1である。「require」フラグと
Rosenberg & Kyzivat Informational [Page 21]
RFC 4596 Caller Preferences Uses July 2006
「explicit」フラグの両方が設定されているため、Y1は破棄される。した
がって、要望どおりに、通話はY2の音声メールサーバーにルーティングさ
れる。
「require」タグと「explicit」タグがあるため、音声メールがないユー
ザー、またはmsgserver能力を持っていることを示していないユーザーに対し
てこれらのプリファレンスが使用される場合、そのユーザーに接続するので
はなく、480 Temporarily Unavailableエラーで呼は完全に失敗する。
3.12. 音声メールの希望
3.12.1. 目的の動作
この状況は、セクション3.10と似ている。ただし、発呼側はメッセージを残
す方を好んでいる。音声メールが使用できない場合、じかに相手と話すこと
を望んでいる。
3.12.2. 解決策
このような場合、RFC 3841が解決策を提供できると期待されてきたが、実現
されていない。というのも、この処理には着呼側の連絡先を並べ替える必要
があるが、実行されていないためである。発呼側は目的の効果を達成するた
めに、以下のように2つの呼を試行することができる。
o まず、セクション3.11の説明に従って、音声メールの要求を試行する。
o それが480エラーで失敗した場合、Accept-ContactまたはReject-Contact
ヘッダーなしで招待を送信する。
3.13. 役員へのルーティング
3.13.1. 目的の動作
Yは役員のAORである。Yには3つの連絡先がある。Y1は、役員の卓上電話であ
る。Y2は、役員のアシスタントの卓上電話である。Y3は、自動受付システム
のアドレスである。このシステムには、一般的な質問に回答し、呼を他の
パーティにルーティングするなどの機能がある。
デフォルトで、Yへの呼はY2宛てに送信され、それが失敗するとY3に送信さ
れる。Y3が応答しない場合、Y1が鳴る。
3.13.2. 解決策
これは、主に着呼側の機能であり、CPL (Call Processing Language)スクリ
プト[5]を使用して達成するのが最適である。ただし、3つのデバイスに適切
なq値を設定することで、発呼側プリファレンスのみで達成することができ
る。このような調整が可能であると仮定して、以下のような設定が行われ
る。
Rosenberg & Kyzivat Informational [Page 22]
RFC 4596 Caller Preferences Uses July 2006
Y1は以下のようなREGISTER (抜粋)を生成する。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>;q=0.1
Y2は以下のようなREGISTER (抜粋)を生成する。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc2.example.com>;attendant;q=1.0
Y3は以下のようなREGISTER (抜粋)を生成する。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y3@pc3.example.com>;attendant;automata;q=0.5
実際には、自動受付がREGISTERを使用しない可能性があることに注意。自動
受付は、社内の全従業員が使用するため、恐らく社内の各ユーザーに静的な
連絡先が管理的に追加される。ただし、静的連絡先の情報は、上記の登録の
情報と同じである。
Xが役員Yに発呼し、プリファレンスを表さなかった場合、プロキシは暗黙的
プリファレンスを計算してINVITEに対応する。3つの連絡先はINVITEへの対応
を明示的に示していなかった場合でも、いずれもこのようなプリファレンス
に一致する。したがって、どの連絡先も破棄されない。各連絡先には異なる
q値があるので、発呼側プリファレンスによって並べ替えは発生しない。結
果として、呼はまずY2にルーティングされ、次にY3、その次にY1にルーティ
ングされる。これはいずれもq値の適切な設定の結果である。
3.14. 役員との通話
3.14.1. 目的の動作
このケースはセクション3.13と似ているが、今回の発呼側Xにはプリファレン
スがある。XはYに発呼するが、役員と直接話したい。Xはアシスタントや自動
受付(自動装置)には発呼したくない。
Rosenberg & Kyzivat Informational [Page 23]
RFC 4596 Caller Preferences Uses July 2006
3.14.2. 解決策
XのINVITE (抜粋)は以下のようになる。
INVITE sip:Y@example.com SIP/2.0
Reject-Contact: *;attendant
Reject-Contact: *;automata
発呼側は、2つの異なるフィーチャーパラメータが指定されたReject-Contact
ヘッダーフィールドではなく、2つの異なるReject-Contactヘッダーフィー
ルド値を使用していることに注意。この差は重要である。Xが2つのパラメー
タが指定された単一の値を使用する必要がある場合、一致するUAは、受付の
自動装置であることを宣言する必要がある。これらのいずれかであることを
宣言しただけの場合、発呼側プリファレンス仕様のマッチング規則に基づ
き、そのUAは拒否されない。
上記のリクエストによって、Y2とY3の両方が連絡先から削除される結果に
なる。そのため、要望どおり、呼はY1にルーティングされる。
このケースは、CPLスクリプト、または今後出てくる他のプログラムバー
ジョンが望ましいという理由である。発呼側は、発呼側プリファレンスを使
用して、指定された発呼シーケンスを無効にし、何らかの認可がない実行を
回避する。このサービスの正しいバージョンは、呼を強制的に役員へ直接送
信する発呼側プリファレンスを決して許可しない。
3.15. 携帯電話のみ
3.15.1. 目的の動作
この状況は、セクション3.13と似ている。ただし、役員は携帯電話も持って
いて登録済みである。発呼側Xは、Yの所有者が出張中であり、アシスタント
がオフィスへの電話を受けていることを知っている。XはYに電話をかけ、携
帯電話のみを鳴らしたいと思っている。
3.15.2. 解決策
この携帯電話は、以下のような登録(抜粋)を生成する。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y4@mobile.example.com>;mobility="mobile";q=0.1
Rosenberg & Kyzivat Informational [Page 24]
RFC 4596 Caller Preferences Uses July 2006
発呼側は、以下のようなINVITE (抜粋)を生成することで自身のプリファレ
ンスを表す。
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;mobility="mobile";require;explicit
4つの連絡先すべてが一致する。ただし、Y1～Y3はスコア0で一致する。Y4は
スコア1で一致する。「require」タグと「explicit」タグがあるため、Y1～
Y4は破棄され、目的どおり、Y4のみが使用される。
これが機能するのは、携帯電話のモビリティ機能を登録で指定した場合のみ
である。
3.16. 同時の複数言語
3.16.1. 目的の動作
AOR Yはセクション3.9のとおりである。発呼側Xは英語とスペイン語の両方に
堪能で、会社のスペイン語文書が英語文書と食い違っていることに気づき、
それぞれの違いについて話し合いたいと考えている。そのため、Xは英語と
スペイン語両方に堪能な社員の1人と話したい。
3.16.2. 解決策
発呼側は以下のようなINVITE (抜粋)を生成する。
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;language="en";require
Accept-Contact: *;language="es";require
これには、両方の制約に一致するContact URIが必要である。つまり、英語
とスペイン語に対応する必要がある。その結果、目的のプロパティが達成さ
れる。
2つの異なるAccept-Contactヘッダーフィールドが存在することに注意。発呼
側が代わりに以下のINVITEを使用した場合、
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;language="en,es";require
英語またはスペイン語を話すUAに接続することになる。これでは目的の動作
にならない。
languageタグを含まない連絡先が回避されるため、「explicit」オプション
は使用されない。
Rosenberg & Kyzivat Informational [Page 25]
RFC 4596 Caller Preferences Uses July 2006
3.17. 発信番号
3.17.1. 目的の動作
ここでも、発呼側は重役の携帯電話にのみ連絡を取りたいと考えている重役
のケース(セクション3.15)について考慮する。ただし、ひねりがある。着呼
側Yは新しいアドレスYYに移行し、着呼側向けに説明されたすべての設定は、
すべてYYにも適用された。古いアドレスYは、静的に割り当てられた連絡先の
ペアのままである。連絡先の1つはYYである。もう1つはMであり、番号が変更
されたことを報告する音声メッセージを生成する自動装置を参照する。
発呼側は移行について意識せず、Yに発呼し、セクション3.15とまったく同
じ方法で携帯電話に連絡するように要求する。
発呼は携帯電話に接続されるべきである。
3.17.2. 解決策
YYに対しては4つの登録がある。
重役のYY1は以下のようなREGISTER (抜粋)を生成する。
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY1@pc.example.com>;q=0.1
受付のYY2は以下のようなREGISTER (抜粋)を生成する。
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY2@pc2.example.com>;attendant;q=1.0
応答サービスのYY3は以下のようなREGISTER (抜粋)を生成する。
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY3@pc3.example.com>;attendant;automata;q=0.5
携帯電話のYY4は以下のようなREGISTER (抜粋)を生成する。
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY4@mobile.example.com>;mobility="mobile";q=0.5
Rosenberg & Kyzivat Informational [Page 26]
RFC 4596 Caller Preferences Uses July 2006
管理者が設定するだろうが、Yには2つの登録連絡先がある。1つ目は転送用
である。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:YY@example.com>;q=1.0
2つ目は自動応答サービス用である。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:machine@example.com>;automata;q=0.5
発呼側はYが移行したことを知らず、Yに発呼し、携帯電話への接続を要求
する。
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;mobility="mobile";require;explicit
これはexample.comプロキシに到達し、プロキシは2つの登録を検出する。
そのうち一方のみ(自動装置)がフィーチャーパラメータと関連付けられる。
もう一方にはフィーチャーパラメータがないため、発呼側プリファレンス処
理から外される。発呼側プリファレンスは自動装置の連絡先に適用される。
フィーチャーセットは一致するが、スコアはゼロである。「require」タグ
と「explicit」タグが提示されているため、自動装置の連絡先は除かれる。
もう一方の連絡先であるYY@example.comが唯一の連絡先として改めて追加さ
れる。したがって、プロキシは呼をsip:YY@example.comに送信する。ここで
は4つの登録があり、そのすべてがフィーチャーパラメータと関連付けられ
ている。発呼側プリファレンスが適用される。ただし、明示的に一致するの
はYY4のみである。「require」フラグと「explicit」フラグがあるため、そ
の他すべての連絡先は除かれる。その結果、呼はYY4に転送され、携帯電話
が鳴る。
3.18. 発信番号(その2)
3.18.1. 目的の動作
この使用例は、セクション3.17とほぼ同じである。ただし、今回の場合、発
呼側はYの個人電話に連絡を取りたいと考えている。
この希望はそれほど強くなく、他のデバイスも受け入れる。
3.18.2. 解決策
このケースで発呼側が生成するINVITEは以下のようになる。
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;class="personal"
Rosenberg & Kyzivat Informational [Page 27]
RFC 4596 Caller Preferences Uses July 2006
これはexample.comプロキシに到達する。この場合も、1つ目の登録(YYの
Addresses-of-Recordに転送される)は、発呼側プリファレンス計算の影響を
受けない。もう一方の連絡先(自動装置用)は一致するが、スコアはゼロであ
る。発呼側プリファレンスQaはゼロである。もう一方の連絡先が1.0のQaで
戻される。連絡先はq値に基づいて並べ替えられ、YY (q=1.0)、machine
(q=0.5)の順になる。これは等値クラスに分類される。クラスは2つある(各
連絡先に1つずつ)。
結果として、発呼側プリファレンスは並び順に影響がなく、呼はYYにルー
ティングされる。
YY@example.comのリクエストが処理されると、4つの連絡先すべてが一致す
る。ただし、いずれもスコアはゼロである(いずれも個人電話ではない)。し
たがって、連絡先はq値に基づいて並べ替えられる。
各連絡先のq値は異なるため、発呼側プリファレンスに基づく並び替えは不
可能である(発呼側プリファレンスによって並べ替えが発生することに注意。
すべてれの連絡先のQaは0.0である)。したがって、最もq値が高い連絡先(重
役のアシスタント)が試行される。
3.19. 同僚への転送
3.19.1. 目的の動作
Aliceは自分の電話をBobに転送したいが、Bobが応答しない場合、自分への
発呼をBobの音声メールに分岐させたくない。Aliceは、自分への発呼を自分
の音声メールに接続させたい。
3.19.2. 解決策
Aliceは3つの登録を作成する。1つ目のY1はAliceの電話である。2つ目はBob
のAORである。3つ目は音声メールサーバーである。連絡先のq値は、1が最も
高く、2、3が続く。BobのAORの登録にはReject-Contactヘッダーフィールド
が組み込まれているため、メッセージサーバーは拒否される。
REGISTER sip:example.com
To: <sip:alice@example.com>
Contact: <sip:Y1@192.0.2.150>;q=1.0
REGISTER sip:example.com
To: <sip:alice@example.com>
Contact: <sip:bob@example.com?Reject-Contact=*;msgserver>;q=0.3
Rosenberg & Kyzivat Informational [Page 28]
RFC 4596 Caller Preferences Uses July 2006
REGISTER sip:example.com
To: <sip:alice@example.com>
Contact: <sip:alice-drop@msgcenter.example.com>
;msgserver;
;automata
;attendant
;q=0.1
一方、Bobは以下のように登録されている。
REGISTER sip:example.com
To: <sip:bob@example.com>
Contact: <sip:bob3@192.0.2.212>;q=0.8
REGISTER sip:example.com
To: <sip:bob@example.com>
Contact: <sip:bob-drop@msgcenter.example.com>
;msgserver
;automata
;attendant
;q=0.2
CarolはAliceに発呼する。発呼側プリファレンスパラメータは含めていな
い。したがって、example.comプロキシはINVITEに対して暗黙的なプリファ
レンスを構築する。このプリファレンスは、3つの登録済み連絡先すべてに
一致する。これらのスコアはゼロである。各連絡先のq値は異なるため、連
絡先の並べ替えはない。したがって、プロキシは最もq値が高い連絡先であ
るAliceの卓上電話(Y1)を試行する。プロキシは(応答なしで)数秒後にキャ
ンセルする。そして次の連絡先であるBobのAORを試行する。この連絡先に対
するリクエストを構築するときに、プロキシは組み込みのReject-Contact
ヘッダーフィールドをINVITEに含める。このINVITEは、Bobの登録済み連絡
先に基づく発呼側プリファレンス処理を受ける。
Bobには2つの連絡先が登録されている。2つ目はメッセージサーバーであり、
INVITEのReject-Contactに一致する。したがって、この連絡先は破棄され
る。残っているもう1つの連絡先であるBobの電話が試行される。Bobが近く
にいないため、電話がしばらくの間鳴る。タイムアウトによって、BobのAOR
に到達できないとプロキシは判断する。そのため、Aliceを処理するプロキ
シは、最後に残った連絡先であるAliceのメッセージサーバーを試行する。
Rosenberg & Kyzivat Informational [Page 29]
RFC 4596 Caller Preferences Uses July 2006
4. 能力の使用例
着呼側能力仕様［2］を使用すると、OPTIONS応答のContactヘッダーフィール
ドとメッセージを開始するダイアログに、UAの能力を含めることができる。
UAの能力は、新しいアプリケーションを開発する場合に非常に有効な場合が
ある。以降のサブセクションでいくつかの用法を概説する。
4.1. Webリダイレクト
発呼側はINVITEを着呼側パーティに送信する。ただし、着呼側は在席してい
ない。着呼側を代理するプロキシサーバーは、発呼側をWebページにリダイレ
クトしたい。Webページでは、着呼側に到達する方法にカンする詳細情報が見
つかる。ただし、発呼側がWebページへのリダイレクトに対応しているかどう
かをプロキシは把握する必要がある。把握していない場合、プロキシはユー
ザーを対話式音声応答(interactive voice response / IVR)デバイスに接続
する。IVRデバイスは応答装置アプリケーションを実行する。
以下のように、発呼側がINVITEのContactヘッダーフィールドに「schemes」
フィーチャータグを含めた場合、プロキシはこのような決定を行う可能性が
ある。
INVITE sip:callee@example.com SIP/2.0
Contact: <sip:host22.example.com>;schemes="http,sip,sips,tel"
これは、UACをhttp URIにリダイレクトすることができることをプロキシに
知らせるリクエストである。このような能力がない通常の「黒電話」からの
INVITEは、以下のようになる。
INVITE sip:callee@example.com SIP/2.0
Contact: <sip:host22.example.com>;schemes="sip,sips,tel"
これは、IVRに連絡する必要があることを示す。
4.2. 音声メールのアイコン
回路網では、ユーザーが発呼し、応答装置が応答した場合、応答装置と話し
ていると発呼側が判断するには、一般的に数秒必要である。発呼の完了後す
ぐに、応答装置が応答したことを示すアイコンが電話に表示できれば役に立
つ。
この表示は、「msgserver」フィーチャーパラメータで実現できる。
応答装置が応答すると、以下のような200 OK (抜粋)が生成される。
SIP/2.0 200 OK
Contact: <sip:server33.example.com>;msgserver;automata;attendant
Rosenberg & Kyzivat Informational [Page 30]
RFC 4596 Caller Preferences Uses July 2006
この応答は、応答装置からのものであることを発呼側に示す。
5. フィーチャータグの用法
発呼側プリファレンス拡張は、メディアフィーチャータグの一覧を簡潔に列
挙する。これらのタグは、デバイスが登録し、リクエストのAccept-Contact
およびReject-Contactヘッダーフィールドに含めることができる。発呼側プ
リファレンスの正しい操作は、こうしたフィーチャータグを一貫性のある方
法で発呼側と着呼側が解釈するかどうかに大きく左右される。
このセクションでは、フィーチャータグの用法についてある程度の指針を提
示する。
一般的に、デバイスが登録時に提示する情報が多いほど、発呼側プリファレ
ンス拡張の効果は高くなる。
できるだけ多くのデバイス情報を登録するように着呼側能力拡張で推奨して
いるのはこのためである。この点はいくら誇張しても足りない。
デバイスが対応していない機能を明示的に登録した場合(「video="false"」
など)、RFC 3841の操作は改善される。
ただし、能力には制約がないという性質があるため、発呼側に関係があるす
べての能力について、否定値を確実に登録することは不可能である。また、
実行するにしても膨大な登録が必要になる。その代わりに、すべての「特異
な」能力を明示的に登録することが推奨される。
以降のサブセクションでは、一般的なデバイスの登録例を示す。
5.1. 伝統的な携帯電話
音声通話が可能なVoIP携帯電話は、以下のような登録(抜粋)を生成する。
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: <sip:cell-phone@example.com>
;audio
;class="business"
;duplex="full"
;+sip.extensions="100rel,path"
;mobility="mobile"
;methods="INVITE,BYE,OPTIONS,CANCEL,ACK"
;schemes="sip,sips,tel"
;uri-user="<cell-phone>"
;uri-domain="example.com"
Rosenberg & Kyzivat Informational [Page 31]
RFC 4596 Caller Preferences Uses July 2006
5.2. 伝統的なオフィス電話
伝統的な固定回線のIP PBX電話は、以下のような登録を生成する。
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: <sip:ippbx-phone@example.com>
;audio
;class="business"
;duplex="full"
;events="dialog"
;+sip.extensions="100rel,privacy"
;mobility="fixed"
;methods="INVITE,BYE,OPTIONS,CANCEL,ACK,SUBSCRIBE"
;schemes="sip,sips,tel"
;uri-user="<ippbx-phone>"
;uri-domain="example.com"
このデバイスは、ダイアログイベントパッケージと、IP PBX電話に一般的な
いくつかのSIP拡張にも対応している。
5.3. PCメッセージングアプリケーション
プレゼンスとIMのみを実行できる(音声機能はない)PCメッセンジャクライア
ントは、以下のような登録を生成する。
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: <sip:pc-msgr@example.com>
;class="personal"
;mobility="fixed"
;methods="OPTIONS,MESSAGE,NOTIFY"
;schemes="sip,sips,im,pres"
;uri-user="<pc-msgr>"
;uri-domain="example.com"
Rosenberg & Kyzivat Informational [Page 32]
RFC 4596 Caller Preferences Uses July 2006
5.4. スタンドアロン型ビデオ電話
音声機能とビデオ機能があるスタンドアロン型IP電話は、以下のような登録
(抜粋)を生成する。
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: <sip:vp@example.com>
;audio
;video
;class="business"
;duplex="full"
;mobility="fixed"
;methods="INVITE,BYE,OPTIONS,CANCEL,ACK"
;schemes="sip,sips,tel"
;uri-user="<vp>"
;uri-domain="example.com"
6. プリファレンス/能力マッチングの実装例
RFC 3841 ［3］は、RFC 2533 ［6］で定義されている定義と機能のマッチン
グアルゴリズムを利用する。このRFCは、アルゴリズムの正確な標準仕様を提
供する。ただし、この仕様は実装の指針として理想的ではない。というの
も、RFC 3841が採用する制限付き使用に必要な仕様よりも複雑なためである
(単純化の主な理由は、1つのフィーチャータグは、Contact、
Accept-Contact、Reject-Contactに1度ずつしか出現できないためである)。
このセクションでは、発呼側プリファレンスと着呼側能力のマッチングを実
装するためのアプローチ例を提供する。この例では、RFC 2533の表記法と技
術を使用する必要はない。これは規範ではないが、その定義と矛盾しないと
確信されている。また、RFC 3841のセクション7.2.3～セクション7.2.4の途
中(ページ13末尾)の部分の代替と考えることができる。
このセクションでは、RFC 3840のセクション9とRFC 3841のセクション10で
ABNFによって定義されている構文要素への参照が頻出する。
本文書では、ABNF要素は一重引用符で囲まれる(例: 'feature-param')。RFC
3261、3840、3841にしたがってSIPリクエストを解析するときに、このよう
な参照は、対応するABNF要素に一致するSIPリクエスト内のオクテット列を
識別する。
Rosenberg & Kyzivat Informational [Page 33]
RFC 4596 Caller Preferences Uses July 2006
6.1. ヘッダーからのフィーチャーセットの抽出
Contactヘッダーフィールド、Accept-Contactヘッダーフィールド、
Reject-Contactヘッダーフィールドには、それぞれゼロ個以上の
'feature-param'が含まれる。また、各'feature-param'には、1個以上の
'tag-value'または'string- value'が含まれる可能性がある。最初の手順
は、各ヘッダーフィールドから、フィーチャーセット(ここではFSと呼ぶ)と
してより有効な表現を抽出することである(フィーチャーセット表現のこの
FS表現は、RFC 2533の表現とは異なる)。この処理は、各ヘッダーの種類で
同じである。
FSは、FPが表示する1個または複数のフィーチャーパラメータ群で構成さ
れる。各FPには名前(FP.NAMEと表記)と、1つまたは複数の値範囲のセット
(VRと表記)がある。各VRは以下から構成される。
o タイプ(VR.TYPE): トークン(TOKEN-TYPE)、文字列(STRING-TYPE)、また
は数字範囲(RANGE-TYPE)のいずれか
o ネゴシエーションフラグ(VR.NEGATION): NEGATEDまたはNON-NEGATEDのい
ずれか
o 実際の値(タイプによって異なる):
* TOKEN-TYPEとSTRING-TYPEの場合、オクテット列(VR.OCTETS)
* RANGE-TYPEの場合、範囲の下限と上限(下限値と上限値を含む)を表す
符号付き実数のペア(VR.LBとVR.UB)。
1つのヘッダーのフィーチャーを表すために1個のFSが作成される(Contact、
Accept-Contact、Reject-Contact)。FS内で、ヘッダーの'feature-param'ご
とに1つのFPが作成される。FPを作成するために、以下のように
'feature-param'が検証される。
o 'feature-param'に'other-tags'のインスタンスが含まれる場合、FP.NAME
は'ftag-name'と一致する値である。
o それ以外の場合、'feature-param'に'base-tags'のインスタンスが含ま
れる。'base-tags'と一致する値が"language"または"type"の場合、
FP.NAMEは単に'base-tags'と一致する値である。それ以外の場合、
FP.NAMEは'base-tags'と一致する値であり、先頭に"sip."が付く。
o 'feature-param'がある場合、(次のセクションの規則に従って)その値は
処理され、FPと関連付けられた1つ以上のVRセットが抽出される。
Rosenberg & Kyzivat Informational [Page 34]
RFC 4596 Caller Preferences Uses July 2006
6.2. フィーチャーパラメータからの値の抽出
'feature-param'の値は、対応する機能の1つ以上の値範囲のエンコード表記
(RFC 3840で規定)である。このような値に使用できるデータ型は複数ある。
ブール、トークン、文字列、数値、または数値範囲である。
データ型は、値のエンコード形式で決定される(データ型とその表記は、そ
の実装に固有である)。
(注意: 数値は、値範囲(value range)を明示的に表現することができる。
他の型は、縮退範囲(degenerate range)という単一の値しか表現できない。
値範囲という用語は、これらすべてを網羅するために使用される。)
'feature-param'の値('string-value'、'tag-value-list'、またはなし)は、
以下のようにVR形式に変換される。
o 値がない場合、単一の新しいVR.TYPE = TOKEN-TYPE、VR.NEGATION =
NON-NEGATEDで、VR.OCTETSが"true"に設定されたVRが作成される。
o 'feature-param'に'string-value'が含まれる場合、VR.TYPE =
STRING-TYPE、VR.NEGATION = NON-NEGATEDで、VR.OCTETSが'qdtext'に一
致するオクテットに設定された、単一の新しいVRが作成され、
o その他の場合、以下のように、'feature-param'に'tag-value-list'が含
まれ、新しいVRが'tag-value-list'の各'tag-value'に作成される。
o 'tag-value'が"!"から始まる場合、VR.NEGATION = NEGATED。
その他の場合、VR.NEGATION = NON-NEGATED。
o 'tag-value'に'boolean'または'token-nobang'が含まれる場合、
VR.TYPE = TOKEN-TYPEで、VR.OCTETSは'boolean'または'token-nobang'
に一致するオクテットに設定される。
o 'tag-value'に'numeric'が含まれる場合、VR.TYPE = RANGE-TYPEであ
る。また、
* 'numeric-relation'が"<="の場合、VR.UBは'number'と一致する数値
に設定される。VR.LBはMIN-REALに設定される(表現可能な最大規模の
負の数値)。
* 'numeric-relation'が"="の場合、VR.LBとVR.UBの両方が'number'と
一致する数値に設定される。
* 'numeric-relation'が">="の場合、VR.LBは'number'と一致する数値
プラス小文字イプシロンに設定される。VR.UBはMAX-REALに設定され
る(表現可能な最大規模の正の数値)。
Rosenberg & Kyzivat Informational [Page 35]
RFC 4596 Caller Preferences Uses July 2006
* それ以外の場合、'numeric-relation'は、コロンで区切られた2つの
「数字」で構成される。この場合、VR.LBは、2つの数字のうち小さい
方の数値に設定され、VR.UBは、2つの数字のうち大きい方の数値に設
定される。
6.3. 2つの値範囲の比較
2つのVRは、範囲が重なる場合、一致する。この比較は型に従って実行され、
型のようなものの比較でのみ定義される。異なる型の2つのVRを比較すると、
重複しないと考えられる。VRのいずれかまたは両方がNEGATED (無効)になる
可能性がある。
比較は以下のように進む。
o VRの型が異なる場合、matchはfalseである。
o それ以外の場合、
* VR.TYPE = RANGE-TYPEの2つのVRは、max(VR1.LB, VR2.LB) <=
min(VR1.UB, VR2.UB)の場合に一致する。
* VR.TYPE = TOKEN-TYPEの2つのVRは、大文字と小文字を区別しない比
較方法で各VR.OCTETS値が等価と評価される場合に一致する。
* VR.TYPE = STRING-TYPEの2つのVRは、大文字と小文字を区別する比較
方法で各VR.OCTETS値が等価と評価される場合に一致する。
o VR1.NEGATION = NEGATEDの場合、結果(true/false)は無効になり、
VR2.NEGATION = NEGATEDの場合にも、無効になる。
6.4. フィーチャーセットどうしのマッチング
RFC 2533では、2つのフィーチャーセットのマッチングは交換可能だが、発呼
側プリファレンスのマッチングに適用する場合は交換可能ではない。このア
プリケーションでは、あるフィーチャーセットはAccept-Contactまたは
Reject-Contactヘッダーフィールドのもので、他のフィーチャーセットは
Contactヘッダーフィールドのものである。この説明のために、それぞれを
preferred-features (FSp)、capability-features (FSc)と呼ぶ。
非交換性(non-commutativity)は、preferred-featuresで使用されたフィー
チャーパラメータ名のcapability-paramsのうち、プレゼンスの明示的なテス
トから生じる。
preferred-featuresのフィーチャーセットFSpは、capability-featuresの
フィーチャーセットFScと一致する可能性があ。また、その結果、以下の評
価指標が導かれる。
o NPF - preferred-featuresの数
o NCF - 同じ名前のcapability-featureがあるpreferred-featuresの数。
Rosenberg & Kyzivat Informational [Page 36]
RFC 4596 Caller Preferences Uses July 2006
o NVM - 2つのフィーチャーセットの対応するフィーチャー間で一致する値
の数。
特定のFPpとFPc間のペアについて、以上の評価指標は以下のように計算され
る。
o すべてのメトリクスはゼロに設定される。
o FSpの各フィーチャーパラメータ(FPp)に以下の手順が適用される。
* NPFはインクリメントされる。
* 同じ名前と対応するFPがFSc内で検索される(比較時に大文字と小文字
は区別されない)。
* 対応するフィーチャーパラメータ(FPc)が見つかった場合、
+ NCFはインクリメントされる。
+ FPpの全VRは、FPcの全VRとマッチングされる。
+ いずれかのマッチングが成功した場合、NVMはインクリメントさ
れる。
6.5. 発呼側プリファレンスに基づく連絡先の選択と並べ替え
6.5.1. Reject-Contactの処理
RFC 3841のセクション7.4.2に規定されている拒否処理は以下のように実行す
ることができる。
o ターゲットセット内の候補となる各Contactについて、各Reject-Contact
のフィーチャーセットとマッチングする。
o (NVM == NPF) & (NCF == NPF)の場合、ターゲットセットからContact URI
を削除する。
6.5.2. Accept-Contactの処理
RFC 3841のセクション7.4.2に規定されているContactに対する
Accept-Contactのマッチングと、それに続くマッチングのスコア付けは、以
下のように実行することができる。
o セクション6.4の規定に従って、Accept-Contactのフィーチャーセット
をContactのフィーチャーセットとマッチングする。
Rosenberg & Kyzivat Informational [Page 37]
RFC 4596 Caller Preferences Uses July 2006
o (NVM < NCF)の場合、マッチングは失敗する。Accept-Contactに"require"
フラグが設定されている場合、ターゲットセットから対応するContact
URIを破棄する。
o スコアをNVM/NPFとして計算する。
o RFC 3841のテキストと図7の規定に従って、"require"フラグと"explicit"
フラグを適用する。
7. セキュリティの考慮事項
本文書は、RFC 3840と3841の使用と実装について説明と例を提供している。
これら文書のセキュリティの考慮事項セクションは、本文書で提示している
資料にも適用される。
8. 謝辞
Rohan Mahyが本仕様にくださったアドバイスについて感謝を述べたい。
9. 有益な参考文献
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
User Agent Capabilities in the Session Initiation Protocol
(SIP)", RFC 3840, August 2004.
[3] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
[4] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B.
Rosen, "Change Process for the Session Initiation Protocol
(SIP)", BCP 67, RFC 3427, December 2002.
[5] Lennox, J. and H. Schulzrinne, "Call Processing Language
Framework and Requirements", RFC 2824, May 2000.
[6] Klyne, G., "A Syntax for Describing Media Feature Sets",
RFC 2533, March 1999.
[7] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005.
Rosenberg & Kyzivat Informational [Page 38]
RFC 4596 Caller Preferences Uses July 2006
[8] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[9] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", BCP 85, RFC 3725,
April 2004.
[10] Campbell, B., "The Message Session Relay Protocol", Work in
Progress, July 2006.
著者の連絡先
Jonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Paul Kyzivat
Cisco Systems
1414 Massachusetts Avenue
Boxborough, MA 01719
US
Phone: +1 978 936-1881
EMail: pkyzivat@cisco.com
Rosenberg & Kyzivat Informational [Page 39]
RFC 4596 Caller Preferences Uses July 2006
完全な著作権表記
Copyright (C) The Internet Society (2006).
本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78
に記載されている例外に従い、著者はすべての権利を持つ。
本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄稿
者が代表となる組織、または寄稿者を後援する組織(存在する場合)、イン
ターネット協会およびIETFは、この情報がいかなる権利も侵害していないと
いう保証、商用利用および特定目的への適合性への保証を含め、また、これ
らだけに限らずすべての保証について、明示的もしくは暗黙的の保証は行わ
れない。
知的所有権
IETFは、本文書で記述される技術の実装または使用に関して要求される、知
的所有権または他の諸権利の有効性または範囲に関して、またはこのような
権利下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何
ら見解を持たない。このような権利を確認する独自の取り組みを行ったこと
も示さない。RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79
に記載されている。
IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセ
ンスの保証すべて、またはこのような所有権の使用に関して、本仕様の実装
者またはユーザーが一般的なライセンスまたは許可の取得を試みた結果につ
いては、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能
である。
IETFは、この規格を実装するために必要とされる技術の範囲にある可能性が
ある、すべての著作権、特許または特許アプリケーション、あるいは他の所
有権について、すべての関連団体に対して配慮するよう依頼している。情報
は、IETF (ietf-ipr@ietf.org)宛てに送信していただきたい。
謝辞
RFC編集職務のための資金は、IETF Administrative Support Activity
(IASA)によって提供されている。
-----------------------------------------------------------------------
本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの
です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ
し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの
ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に
再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ
せてご利用ください。
2007年
-----------------------------------------------------------------------
Rosenberg & Kyzivat Informational [Page 40]