[要約] RFC 4596は、SIP Caller Preferences拡張機能の使用に関するガイドラインです。このRFCの目的は、SIPセッションの発信者の好みを伝えるための拡張機能の適切な使用方法を提供することです。
Network Working Group J. Rosenberg
Request for Comments: 4596 P. Kyzivat
Category: Informational Cisco Systems
July 2006
Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension
セッション開始プロトコル（SIP）発信者設定拡張機能の使用に関するガイドライン
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document contains guidelines for usage of the Caller Preferences Extension to the Session Initiation Protocol (SIP). It demonstrates the benefits of caller preferences with specific example applications, provides use cases to show proper operation, provides guidance on the applicability of the registered feature tags, and describes a straightforward implementation of the preference and capability matching algorithm specified in Section 7.2 of RFC 3841.
このドキュメントには、セッション開始プロトコル（SIP）に対する発信者設定の拡張機能を使用するためのガイドラインが含まれています。特定のサンプルアプリケーションで発信者の好みの利点を実証し、適切な操作を示すためのユースケースを提供し、登録機能タグの適用性に関するガイダンスを提供し、RFC 3841のセクション7.2で指定された選好と能力の一致するアルゴリズムの簡単な実装を説明します。。
Table of Contents
目次
1. Introduction ....................................................4
2. Motivations for Caller Preferences ..............................5
2.1. One-Number .................................................7
2.2. Direct-to-Voicemail ........................................7
3. Caller Preference Use Cases .....................................8
3.1. Routing of INVITE and MESSAGE to Different UA ..............8
3.1.1. Desired Behavior ....................................8
3.1.2. Solution ............................................9
3.2. Single Contact Not Matching Implicit Preferences ..........10
3.2.1. Desired Behavior ...................................10
3.2.2. Solution ...........................................10
3.3. Package-Based Routing .....................................11
3.3.1. Desired Behavior ...................................11
3.3.2. Solution ...........................................11
3.4. Package Routing II ........................................12
3.4.1. Desired Behavior ...................................12
3.4.2. Solution ...........................................13
3.5. Audio/Video vs. Audio Only ................................13
3.5.1. Desired Behavior ...................................13
3.5.2. Solution ...........................................14
3.6. Forcing Audio/Video .......................................15
3.6.1. Desired Behavior ...................................15
3.6.2. Solution ...........................................15
3.7. Third-Party Call Control: Forcing Media ...................16
3.7.1. Desired Behavior ...................................16
3.7.2. Solution ...........................................16
3.8. Maximizing Media Overlaps .................................17
3.8.1. Desired Behavior ...................................17
3.8.2. Solution ...........................................17
3.9. Multilingual Lines ........................................18
3.9.1. Desired Behavior ...................................18
3.9.2. Solution ...........................................19
3.10. I Hate Voicemail! ........................................20
3.10.1. Desired Behavior ..................................20
3.10.2. Solution ..........................................20
3.11. I Hate People! ...........................................21
3.11.1. Desired Behavior ..................................21
3.11.2. Solution ..........................................21
3.12. Prefer Voicemail .........................................22
3.12.1. Desired Behavior ..................................22
3.12.2. Solution ..........................................22
3.13. Routing to an Executive ..................................22
3.13.1. Desired Behavior ..................................22
3.13.2. Solution ..........................................22
3.14. Speak to the Executive ...................................23
3.14.1. Desired Behavior ..................................23
3.14.2. Solution ..........................................24
3.15. Mobile Phone Only ........................................24
3.15.1. Desired Behavior ..................................24
3.15.2. Solution ..........................................24
3.16. Simultaneous Languages ...................................25
3.16.1. Desired Behavior ..................................25
3.16.2. Solution ..........................................25
3.17. The Number You Have Called... ............................26
3.17.1. Desired Behavior ..................................26
3.17.2. Solution ..........................................26
3.18. The Number You Have Called, Take Two .....................27
3.18.1. Desired Behavior ..................................27
3.18.2. Solution ..........................................27
3.19. Forwarding to a Colleague ................................28
3.19.1. Desired Behavior ..................................28
3.19.2. Solution ..........................................28
4. Capability Use Cases ...........................................30
4.1. Web Redirect ..............................................30
4.2. Voicemail Icon ............................................30
5. Usage of the Feature Tags ......................................31
5.1. Traditional Cell Phone ....................................31
5.2. Traditional Work Phone ....................................32
5.3. PC Messaging Application ..................................32
5.4. Standalone Videophone .....................................33
6. Example of Implementation of Preference and Capability
Matching .......................................................33
6.1. Extracting a Feature Set from a Header ....................34
6.2. Extracting Values from a Feature Parameter ................35
6.3. Comparing Two Value-Ranges ................................36
6.4. Feature Set to Feature Set Matching .......................36
6.5. Selecting and Ordering Contacts Based on Caller
Preferences ...............................................37
6.5.1. Reject-Contact Processing ..........................37
6.5.2. Accept-Contact Processing ..........................37
7. Security Considerations ........................................38
8. Acknowledgements ...............................................38
9. Informative References .........................................38
The Session Initiation Protocol (SIP) [1] extension for Callee Capabilities [2] describes mechanisms that allow a UA (User Agent) to register its capabilities in a REGISTER request. A caller can express preferences, either explicitly or implicitly, about how that request is to be handled. This is accomplished with the Accept-Contact and Reject-Contact header fields described in Caller Preferences for the Session Initiation Protocol[3].
セッション開始プロトコル（SIP）[1] Callee機能の拡張[2]は、UA（ユーザーエージェント）がレジスタリクエストにその機能を登録できるメカニズムを説明しています。発信者は、その要求をどのように処理するかについて、明示的または暗黙的に好みを表現できます。これは、セッション開始プロトコルの発信者設定に記載されているAccept-contactおよび拒否コンタクトヘッダーフィールドで達成されます[3]。
The caller preferences extension can serve as a useful tool for supporting many applications. However, its generality makes it difficult to use correctly and effectively in any one situation. To remedy that, this document serves as a compendium of examples of the usage of the caller preferences extension.
発信者設定拡張機能は、多くのアプリケーションをサポートするための便利なツールとして機能します。ただし、その一般性は、いずれかの状況で正しく効果的に使用することを困難にしています。それを改善するために、このドキュメントは、発信者の設定拡張機能の使用例の大要として機能します。
NOTE: This document is intended to assist the reader in understanding RFCs 3840 and 3841. It is not intended to serve as a substitute for reading those documents. The examples presented in this document cannot be fully understood without awareness of the mechanisms defined in RFCs 3840 and 3841.
注：このドキュメントは、読者がRFCS 3840および3841を理解するのを支援することを目的としています。これらのドキュメントを読むための代替品として機能することは意図されていません。このドキュメントで提示された例は、RFCS 3840および3841で定義されているメカニズムを認識せずに完全に理解することはできません。
First, Section 2 demonstrates the benefits of using caller preferences by describing several concrete applications that are enabled by the extension. Section 3 describes a set of detailed use cases for expressing caller preferences. Each use case presents a situation, describes how caller preferences can be used to handle the requirements for the situation, and verifies that the desired behavior occurs by showing the results of the matching operation. These use cases validate that the caller preferences specification is complete and capable of meeting a specific set of requirements. Since the caller preferences specification predates the SIP change process [4], no requirements document was ever published for it. To some degree, this document "backfills" requirements. However, this is not an academic exercise only, since the use cases described here did result in changes in the caller preferences document as it evolved. These use cases also help implementors figure out how to use caller preferences in their own applications.
まず、セクション2では、拡張機能によって有効になっているいくつかの具体的なアプリケーションを説明することにより、発信者の設定を使用する利点を示しています。セクション3では、発信者の好みを表現するための詳細なユースケースのセットについて説明します。各ユースケースは状況を提示し、発信者の好みを使用して状況の要件を処理する方法を説明し、一致する操作の結果を表示することで目的の動作が発生することを確認します。これらのユースケースは、発信者の設定仕様が完全であり、特定の一連の要件を満たすことができることを検証します。発信者の設定仕様はSIP変更プロセス[4]に先行するため、要件文書は公開されていません。ある程度、このドキュメント「埋め戻し」要件。ただし、これは学術演習ではありません。ここで説明したユースケースは、発展途上のドキュメントが進化するにつれて変化をもたらしたためです。これらのユースケースは、実装者が独自のアプリケーションで発信者の好みを使用する方法を把握するのにも役立ちます。
Section 4 discusses applications for the callee capabilities specification. Section 5 discusses the example registrations of the feature tags described in [2]. Proper usage of the caller preferences extension depends on proper interpretation of the semantics of these tags. More detail is provided on the tags, and example registrations are included that show typical usage.
セクション4では、Callee機能の仕様のアプリケーションについて説明します。セクション5では、[2]で説明されている機能タグの登録例について説明します。発信者設定の適切な使用は、これらのタグのセマンティクスの適切な解釈に依存します。タグには詳細が記載されており、典型的な使用法を示す登録の例が含まれています。
Section 6 outlines an implementation approach to the matching algorithm that doesn't require RFC 2533 [6] to be implemented in all its generality.
セクション6では、RFC 2533 [6]がそのすべての一般性において実装される必要のない一致するアルゴリズムへの実装アプローチの概要を説明します。
At its core, SIP is a protocol that facilitates rendezvous of users. The caller and callee need to meet up in order to exchange session information, so that they may communicate. The rendezvous process is complicated by the fact that a user has multiple points of attachment to the network. A called user (callee) can have a cell phone, a PDA, a work phone, a home phone, and one of several PC-based communications applications. When someone calls that user, to which of these devices is the call routed?
その中心にあるSIPは、ユーザーのランデブーを促進するプロトコルです。発信者とCalleeは、セッション情報を交換するために会う必要があります。ランデブープロセスは、ユーザーがネットワークへの複数の添付ポイントを持っているという事実によって複雑になります。呼び出されたユーザー（Callee）は、携帯電話、PDA、職場電話、自宅の電話、およびいくつかのPCベースの通信アプリケーションの1つを持つことができます。誰かがそのユーザーを呼び出すとき、これらのデバイスのどれに通話がルーティングされますか？
Certainly, the call can be routed to all of them at the same time, a process known as parallel forking. However, that is not always the desired behavior. Users may prefer that their registered devices be tried in a particular order. As an example, a user might prefer that his cell phone ring first, and if no one answers, that his work phone ring next. Another user might prefer that her cell phone ring first, and then her home and work phones ring at the same time, and then, if no one answers either of those, that the call be forwarded to voicemail. These variations are all referred to as find-me/ follow-me features.
確かに、コールは、パラレルフォーキングと呼ばれるプロセスである同時に、すべての人にルーティングできます。ただし、それは必ずしも望ましい動作ではありません。ユーザーは、登録されたデバイスを特定の順序で試してみることを好む場合があります。例として、ユーザーは自分の携帯電話が最初に鳴り、誰も答えなければ、彼の作業電話が次に鳴ることを好むかもしれません。別のユーザーは、彼女の携帯電話が最初に鳴ることを好むかもしれません。次に彼女の自宅と仕事の携帯電話が同時に鳴り、そのいずれも誰も答えなければ、コールがボイスメールに転送されることを好むかもしれません。これらのバリエーションはすべて、Find-Me/ Follow-ME機能と呼ばれます。
SIP supports find-me/follow-me features in many ways. The most basic is through the SIP registration process. Each device at which a user can be contacted registers to the network. This registration associates the device with the canonical name of the user, called the address-of-record (AOR), which is a SIP URI. Each registration can include a preference value, indicating the relative preference for receiving calls at that device, compared to other devices. When someone makes a call to the AOR, proxies compliant to RFC 3261 will try the registered devices in order of preference, unless administrative policy overrides user preferences.
SIPは、多くの点でFind-Me/Follow-Me機能をサポートしています。最も基本的なのは、SIP登録プロセスを使用することです。ユーザーに連絡できる各デバイスは、ネットワークに登録します。この登録は、デバイスをユーザーの正規名と関連付けます。各登録には、他のデバイスと比較して、そのデバイスで通話を受信することに対する相対的な優先順位を示す優先値を含めることができます。誰かがAORに電話をかけると、RFC 3261に準拠したプロキシは、管理ポリシーがユーザーの好みを上書きしない限り、登録デバイスを優先順に試します。
Preference values in SIP registrations can only provide basic find-me/follow-me features. To support more complex features, the Call Processing Language (CPL) [5] has been specified. It is an XML script that provides specific call routing instructions. Users can upload these scripts to the network, instructing the servers how calls should be routed. As an example, a CPL script can instruct a proxy to route a call to the work phone during work hours (9 am - 5 pm) and then to the cell phone after hours, unless the call is from a family member, in which case it always goes to the cell phone.
SIP登録の優先値は、基本的なFind-ME/Follow-ME機能のみを提供できます。より複雑な機能をサポートするために、コール処理言語（CPL）[5]が指定されています。これは、特定の呼び出しルーティング手順を提供するXMLスクリプトです。ユーザーはこれらのスクリプトをネットワークにアップロードして、通話のルーティング方法をサーバーに指示できます。例として、CPLスクリプトは、勤務時間（午前9時から午後5時）に仕事の電話に電話をかけるようにプロキシに指示し、その場合は営業時間外に携帯電話に電話をかけます。それは常に携帯電話に行きます。
It is important to note that both CPL scripts and preference values in registrations describe operation of a service from the perspective of the called party. That is, they describe how a call made to the called party should be routed by the network. However, the called party is not the only one with preferences. A caller will also have preferences for how they want their call to be routed. As an example, a caller will often want to reach a user on their cell phone. In the current telephone network, this is accomplished by requiring a user to have a separate number for each device. This way, when a caller wishes to reach the cell phone, they dial the number for the cell phone. This requires users to maintain lists of potential reach numbers for a user, and then select the appropriate one. A far better approach is for a user to maintain a single address-of-record. When someone wishes to reach them on their cell phone, they call the AOR, but indicate a preference for the call to be routed to the cell phone.
登録のCPLスクリプトと優先値の両方が、呼び出された当事者の観点からサービスの運用を説明していることに注意することが重要です。つまり、彼らは、呼び出された当事者に行われたコールがネットワークによってどのようにルーティングされるべきかを説明しています。ただし、好みのあるパーティーだけではありません。発信者は、呼び出しをどのようにルーティングしたいかについても好みを持っています。例として、発信者は携帯電話でユーザーに連絡したいと思うことがよくあります。現在の電話ネットワークでは、これはユーザーが各デバイスに個別の番号を持つように要求することによって達成されます。このようにして、発信者が携帯電話に到達したいとき、彼らは携帯電話の番号をダイヤルします。これには、ユーザーがユーザーの潜在的なリーチ番号のリストを維持し、適切な数字を選択する必要があります。はるかに優れたアプローチは、ユーザーが単一のレコードを維持することです。誰かが携帯電話でそれらに到達したいとき、彼らはAORに電話しますが、携帯電話にルーティングされるコールの好みを示します。
A caller may actually have a wide variety of preferences for how a call should be routed. They may prefer to go right to voicemail. They may prefer never to reach voicemail. The may prefer to reach the user on a device that supports video (because a video-conference is desired). They may wish to reach a device that has an attendant who can answer if the user is not there.
発信者は、実際には、通話のルーティング方法についてさまざまな好みを持っている場合があります。彼らはボイスメールに行くことを好むかもしれません。彼らはボイスメールに到達しないことを好むかもしれません。ビデオをサポートするデバイスでユーザーにアクセスすることを好むかもしれません（ビデオ会議が望ましいため）。彼らは、ユーザーがそこにいない場合に答えることができるアテンダントがいるデバイスに到達したいと思うかもしれません。
The SIP caller preferences extension allows a caller to express these preferences for the way in which their calls are handled. These preferences are expressed in terms of properties of the desired device. These properties are name-value pairs that convey some kind of information about a device. One example is the property "mobility", which can have the values "mobile" or "fixed". When a caller wishes to reach a cell phone, they include information in their call setup request (the INVITE method) which indicates that the call should be routed to a device that has the property "mobility" set to "mobile". When devices register to the network, they include their properties (also known as callee capabilities) as part of the registration. In this way, a proxy can match the caller's preferences against the capabilities of the various devices registered to the user and route the call appropriately.
SIP発信者の設定拡張機能により、発信者は、呼び出しの処理方法についてこれらの設定を表現できます。これらの好みは、目的のデバイスのプロパティの観点から表されます。これらのプロパティは、デバイスに関する何らかの情報を伝える名前と価値のペアです。1つの例は、「モバイル」または「固定」値を持つことができるプロパティ「モビリティ」です。発信者が携帯電話に到達したい場合、通話が「モバイル」に設定されたプロパティ「モビリティ」が設定されたデバイスにルーティングする必要があることを示すコールセットアップリクエスト（招待方法）に情報を含めます。デバイスがネットワークに登録する場合、登録の一部としてプロパティ（Callee機能としても知られています）が含まれます。このようにして、プロキシは、ユーザーに登録されたさまざまなデバイスの機能に対して発信者の設定と一致し、コールを適切にルーティングできます。
While this document addresses the preferences of a caller, it does so from the perspective of a SIP User Agent representing the caller. Caller preferences are herein represented via syntactic elements placed in a SIP request. This document does not attempt to address how preferences might be conveyed by a human user to the User Agent. Thus this document is likely to be of most value to the developer of a User Agent.
このドキュメントでは、発信者の好みに対応していますが、発信者を表すSIPユーザーエージェントの観点からはそうします。発信者の好みは、SIPリクエストに配置された構文要素を介して表されます。このドキュメントは、人間のユーザーがユーザーエージェントにどのように好みを伝えるかについては対処しようとはしていません。したがって、このドキュメントは、ユーザーエージェントの開発者にとって最も価値がある可能性があります。
The caller preferences extension can support a wide variety of call routing applications and features. Two particularly important examples are "one-number" and "direct-to-voicemail".
発信者設定拡張機能は、さまざまな通話ルーティングアプリケーションと機能をサポートできます。2つの特に重要な例は、「1つの1つの数」と「直接的なボイスメール」です。
In today's circuit-switched telephony networks, users have multiple devices, and each device is associated with its own phone number. A user will typically list all of these numbers on a business card: cell phone, work phone, home office phone, and so on. Other users need to store and manage all of these numbers. It is difficult to keep these numbers complete and up-to-date. Worse, when you want to call someone, you need to pick a number to try. Sometimes, you want a specific device (the cell phone); and other times, you just want to reach them wherever they are. In the latter case, a user is forced to try each number, one at a time. This is inefficient, and difficult to do while driving, for example.
今日のサーキットが切り替えるテレフォニーネットワークでは、ユーザーは複数のデバイスを持ち、各デバイスは独自の電話番号に関連付けられています。ユーザーは通常、これらのすべての番号を名刺、携帯電話、職場電話、ホームオフィス電話などにリストします。他のユーザーは、これらすべての番号を保存および管理する必要があります。これらの数値を完成させ、最新の状態に保つことは困難です。さらに悪いことに、誰かに電話したいときは、試してみる番号を選ぶ必要があります。特定のデバイス（携帯電話）が必要な場合があります。また、どこにいても到達したいだけです。後者の場合、ユーザーは各番号を一度に1つずつ試すことを余儀なくされます。これは非効率的であり、たとえば運転中に行うのは困難です。
As an alternative, a user can have a single address. This is the one and only address they give out to other users on their business cards. If a caller wishes to reach that user on their cell phone, they select that one address, and then access a pull-down menu of device types. This menu would include home phone, work phone, and cell phone. The caller can select cell-phone, and then the call is placed to the cell phone. There is no need to manage or maintain more than one number for the user -- a single number will suffice.
別の方法として、ユーザーは単一のアドレスを持つことができます。これは、名刺で他のユーザーに配る唯一の住所です。発信者が携帯電話でそのユーザーに到達したい場合、彼らはその1つのアドレスを選択し、デバイスタイプのプルダウンメニューにアクセスします。このメニューには、自宅の電話、職場電話、携帯電話が含まれます。発信者は携帯電話を選択でき、その後、携帯電話に通話が配置されます。ユーザーに複数の数値を管理または維持する必要はありません。単一の数字で十分です。
If, on the other hand, the caller wishes to reach the user wherever they are, they make a call to that one number without a selection of a preferred device. The network will ring all devices at the same time, and therefore reach the user as fast as possible.
一方、発信者がどこにいてもユーザーにリーチしたい場合、優先デバイスを選択せずにその1つの番号に電話をかけます。ネットワークはすべてのデバイスを同時に鳴らし、できるだけ早くユーザーにリーチします。
This one-number service makes use of caller preferences. To express a preference for the cell phone, the caller's device would include a header in the SIP INVITE request, indicating a desire to reach a device with "mobility" equal to "mobile".
この1つのサービスは、発信者の好みを利用しています。携帯電話の好みを表現するために、発信者のデバイスには、SIP Inviteリクエストにヘッダーが含まれており、「モバイル」に等しい「モビリティ」のデバイスに到達したいという欲求を示します。
Frequently, a busy executive on the road wants to quickly pass a message to a colleague by voice. As an example, a boss might want to instruct an employee to call a specific customer and resolve a pending issue. In such a case, the user doesn't actually want to talk to the person; they just want to leave a voice message. Having a phone conversation may require too much time, whereas a voice message can be quick and to the point. The voice message can also serve as a record of exactly what is desired, whereas a fleeting voice conversation can be forgotten or misremembered.
多くの場合、道路上の忙しい幹部は、声で同僚にメッセージをすばやく渡したいと考えています。例として、上司は従業員に特定の顧客に電話して、保留中の問題を解決するように指示することをお勧めします。そのような場合、ユーザーは実際にその人と話をしたくありません。彼らはただ音声メッセージを残したいだけです。電話での会話をするには時間がかかりすぎる場合がありますが、音声メッセージは迅速かつポイントになります。音声メッセージは、まさに望ましいもののレコードとしても機能しますが、つかの間の音声会話は忘れたり、誤ったりしていることがあります。
In today's circuit-switched telephone networks, there is often no way to go directly to someone's voicemail and leave a message. Sometimes, you can dial the main number for the voicemail system, enter in the extension of the desired party, and leave a message by entering a specific prompt. This is time consuming, and requires the caller to know the main voicemail number.
今日のサーキットが切り替えられた電話ネットワークでは、誰かのボイスメールに直接行き、メッセージを残す方法はしばしばありません。時には、ボイスメールシステムのメイン番号をダイヤルし、目的のパーティの延長に入力し、特定のプロンプトを入力してメッセージを残すことができます。これには時間がかかり、発信者がメインボイスメール番号を知る必要があります。
Instead, an address book in a cell phone can have an option called "leave voice message", available for each entry in the address book. When this option is selected, a call is made directly to the voicemail for that user, which immediately picks up and prompts for a message. In fact, a rapid greeting is played, so that the caller can go directly to the recording procedure.
代わりに、携帯電話のアドレス帳には、アドレス帳の各エントリで利用可能な「Leave Voiceメッセージ」と呼ばれるオプションがあります。このオプションが選択されると、そのユーザーのボイスメールに直接通話が行われ、すぐにピックアップしてメッセージが表示されます。実際、発信者が録音手順に直接移動できるように、迅速な挨拶が行われます。
This saves time for the caller, making it very easy to quickly leave recorded messages for a large number of people.
これにより、発信者の時間を節約できるため、多くの人のために録音されたメッセージをすばやく残すことができます。
This feature is possible using the caller preferences extension. When the user selects the "leave voice message" option, the phone sends a SIP INVITE request, and includes a caller preferences header field that indicates a preference for devices whose "msgserver" attribute has a value of "true". This will cause the proxy to route the call directly to a registered voicemail service. Furthermore, the voicemail server will see that the caller asked to go directly to voicemail, and can therefore play an abbreviated greeting explicitly designed for this case.
この機能は、発信者設定拡張機能を使用して可能です。ユーザーが「Velive Voiceメッセージ」オプションを選択すると、電話はSIP Inviteリクエストを送信し、「msgserver」属性が「true」の値を持っているデバイスの優先度を示す発信者設定ヘッダーフィールドを含みます。これにより、プロキシはコールを登録済みボイスメールサービスに直接ルーティングします。さらに、ボイスメールサーバーは、発信者がボイスメールに直接行くように求められたため、このケースのために明示的に設計された短縮された挨拶を再生できることがわかります。
Each use case is described as a situation along with a desired behavior. Then, it demonstrates how the various caller preferences headers and the proxy processing logic would result in the appropriate decision.
各ユースケースは、望ましい動作とともに状況として説明されます。次に、さまざまな発信者の好みのヘッダーとプロキシ処理ロジックが適切な決定をもたらす方法を示します。
Address of Record (AOR) Y has two contacts, Y1 and Y2. Y1 is a phone and supports the standard operations INVITE, ACK, OPTIONS, BYE, and CANCEL but does not support MESSAGE, whereas Y2 is a pager and supports only OPTIONS and MESSAGE. Caller X wants to send pages to Y. There is a lot of traffic in the network of both calls and pages, so there is a goal not to unnecessarily fork messages to devices that can't support them. So, this is done by ensuring that INVITEs of Y are delivered only to Y1, while MESSAGEs to Y are delivered only to Y2.
Resdress of Record（AOR）Yには、Y1とY2の2つの連絡先があります。Y1は電話であり、標準の操作招待、ACK、オプション、Bye、およびキャンセルをサポートしますが、メッセージはサポートしませんが、Y2はポケットベルであり、オプションとメッセージのみをサポートしています。Caller XはYにページを送信したいと考えています。通話とページの両方のネットワークには多くのトラフィックがあります。そのため、サポートできないデバイスにメッセージを不必要にフォークしないという目標があります。したがって、これはYの招待がY1にのみ配信されるようにすることによって行われ、YへのメッセージはY2にのみ配信されます。
Y1 will create a registration that looks like, in part:
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 will create a registration that looks like, in part:
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"
When a UAC (User Agent Client) sends an INVITE, it will arrive at the proxy for example.com. There are no caller preferences in the request. However, per Section 7.2.2 of [3], the proxy will construct an implicit require-flagged Accept-Contact preference that looks like:
UAC（ユーザーエージェントクライアント）が招待状を送信すると、例えばproxyに到着します。リクエストには発信者の好みはありません。ただし、[3]のセクション7.2.2に従って、プロキシは、次のように見える暗黙の要求flagged Accept-contactの選好を構築します。
(& (sip.methods="INVITE"))
（＆（sip.methods = "Invite"））
Applying the matching algorithm of RFC 2533 [6] to this feature set and those registered by Y1 and Y2, the feature set of Y1 alone matches. Because the Accept-Contact predicate has its require flag set, Y2 is discarded, and the INVITE is routed to Y1.
RFC 2533 [6]の一致するアルゴリズムをこの機能セットに適用し、Y1とY2が登録したアルゴリズムを適用し、Y1のみの機能セットが一致します。Accept-Contact Predicateには必要なフラグセットがあるため、Y2は破棄され、招待はY1にルーティングされます。
If the request was MESSAGE, the proxy constructs an implicit Accept-Contact preference with its require flag set (require-flagged) that looks like:
リクエストがメッセージである場合、プロキシは、次のように見える必要のフラグセット（require-flagged）を使用して、暗黙の受け入れ接触選好を構築します。
(& (sip.methods="MESSAGE"))
（＆（sip.methods = "メッセージ"））
which matches the feature set of Y2, but not Y1. Thus, Y1 is discarded, and the request is routed to Y2.
Y2の機能セットと一致しますが、Y1は一致しません。したがって、Y1は破棄され、リクエストはY2にルーティングされます。
AOR Y has a single contact, Y1. It's a phone, and therefore supports the standard operations INVITE, ACK, OPTIONS, BYE, and CANCEL but does not support MESSAGE. A caller X sends a MESSAGE request. The desired behavior is that the request is still routed to the solitary contact so that it can generate a 405 response.
Aor Yには単一の接触Y1があります。これは電話であるため、標準の操作、ACK、オプション、Bye、およびキャンセルをサポートしますが、メッセージはサポートしていません。発信者xがメッセージリクエストを送信します。望ましい動作は、リクエストが405の応答を生成できるように、孤独な接触にまだルーティングされていることです。
The single contact Y1 will generate a registration that looks like, in part:
単一の連絡先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 sends a MESSAGE request. There are no explicit caller preferences. This results in an implicit require-flagged Accept-Contact preference:
xメッセージリクエストを送信します。明示的な発信者の好みはありません。これにより、暗黙の要求フラグの承認コンタクトの好みが得られます。
(& (sip.methods="MESSAGE"))
（＆（sip.methods = "メッセージ"））
Since Y1 doesn't match and the Accept-Contact predicate is require-flagged, it is discarded. However, according to section 7.2.4 of RFC 3841, if there are no matching targets, the original target set is used. Thus, the request is sent to the one original target, Y1, as desired. Y1 then responds with a 405.
Y1は一致せず、Accept-Tontactの述語は要求されているため、破棄されます。ただし、RFC 3841のセクション7.2.4によると、一致するターゲットがない場合、元のターゲットセットが使用されます。したがって、リクエストは、必要に応じて、1つの元のターゲットY1に送信されます。Y1は405で応答します。
If there were multiple contacts, and none of them matched the Accept-Contact predicate, then the original target set including all of the contacts would be restored. Then all the contacts would be processed according to Section 16.6 of RFC 3261.
複数の連絡先があり、それらのいずれもAccept-Tontact述語と一致していない場合、すべての連絡先を含む元のターゲットセットが復元されます。次に、すべての接点は、RFC 3261のセクション16.6に従って処理されます。
AOR Y has a number of contacts, Y1, Y2, ..., Yn, that can each support the standard operations INVITE, ACK, OPTIONS, BYE, and CANCEL and can also support SUBSCRIBE for the "dialog" event package [7]. Y also has another contact, Yp, that is a presence agent (PA) [8]: it can accept only SUBSCRIBE requests for the "presence" event package. The goal is for SUBSCRIBE requests for presence to be routed to Yp while INVITEs and SUBSCRIBEs for the dialog package are forked to Y1...Yn.
AOR Yには、Y1、Y2、...、YNの多くの連絡先があり、それぞれ標準操作の招待、ACK、オプション、Bye、およびキャンセルをサポートでき、「ダイアログ」イベントパッケージ[7]の購読をサポートできます。。Yには別の連絡先、YPがあります。これは、プレゼンスエージェント（PA）[8]です。「プレゼンス」イベントパッケージのサブスクライブリクエストのみを受け入れることができます。目標は、ダイアログパッケージへの招待とサブスクライブがY1 ... YNにフォークされている間、存在の存在をYPにルーティングするためのサブスクライブのリクエストです。
Y1..Yn will generate REGISTER requests that look like, in part:
y1..inは、部分的には次のように見えるレジスタリクエストを生成します。
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"
and Yp will generate a REGISTER request that looks like, in part:
YPは、部分的には次のように見えるレジスタリクエストを生成します。
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"
A SUBSCRIBE request for presence will arrive at the proxy for example.com. Since there are no explicit preferences, it constructs an implicit require-flagged Accept-Contact preference from the request:
存在感のサブスクライブリクエストは、たとえばProxyに到着します。明示的な設定はないため、リクエストからの暗黙の要求flagged受け入れの承認嗜好を構築します。
(& (sip.methods="SUBSCRIBE") (sip.events="presence"))
（＆（sip.methods = "subscribe"）（sip.events = "expencion"））
Following Section 7.2.4 of RFC 3841, this feature set only matches the one registered by Yp. Because the require flag is set, the contacts which do not match are removed from the target set. Therefore, Y1..Yn are discarded. The request is sent to the remaining contact, Yp, representing the PA.
RFC 3841のセクション7.2.4に従って、この機能セットは、YPが登録したものとのみ一致します。要求フラグが設定されているため、一致しない連絡先がターゲットセットから削除されます。したがって、y1..inは破棄されます。リクエストは、PAを表す残りの連絡先YPに送信されます。
An INVITE request without explicit preferences results in an implicit require-flagged Accept-Contact preference:
明示的な設定なしの招待リクエストは、暗黙の要求に包まれた受け入れコンタクトの好みをもたらします。
(& (sip.methods="INVITE"))
（＆（sip.methods = "Invite"））
The implicit Accept-Contact feature set matches Y1..Yn, but does not match Yp. Using the scoring algorithm from Section 7.2.4 of RFC 3841, the score for Y1..Yn against this predicate is 1.0. As a result, the caller preference Qa for each contact is 1.0. The registrations did not contain q-values, so the default q-value of 1.0 is applied to each Contact URI. Since the caller and callee preferences are the same and all equal to 1.0, there is no reordering of contacts. The result is that the proxy will consider Y1..Yn each as equally good targets for the request and possibly fork the request to each.
暗黙的な受け入れコンタクト機能セットはY1..inと一致しますが、YPと一致しません。RFC 3841のセクション7.2.4のスコアリングアルゴリズムを使用して、この述語に対するY1..inのスコアは1.0です。その結果、各連絡先の発信者優先QAは1.0です。登録にはQ値が含まれていなかったため、デフォルトのQ値1.0が各コンタクトURIに適用されます。発信者とCalleeの好みは同じであり、すべて1.0に等しいため、連絡先の並べ替えはありません。その結果、プロキシはY1..inを要求の等しく良いターゲットと見なし、場合によってはそれぞれへの要求を分岐します。
A SUBSCRIBE request for the dialog event package without explicit preferences will result in an implicit require-flagged Accept-Contact preference:
明示的な設定なしのダイアログイベントパッケージの購読リクエストは、暗黙の要求に包まれた受け入れコンタクト選好をもたらします。
(& (sip.methods="SUBSCRIBE") (sip.events="dialog"))
（＆（sip.methods = "subscribe"）（sip.events = "ダイアログ"））
This only matches Y1..Yn, so Yp is discarded, and the request is routed to the remaining contacts just as the INVITE was.
これはY1..Nyのみに一致するため、YPは破棄され、リクエストは招待状と同じように残りの連絡先にルーティングされます。
This case is nearly identical to that of Section 3.3. However, Y1..Yn omit the "events" feature tag from their registration. Yp registers as in Section 3.3. A SUBSCRIBE for the presence event package should still preferentially route to Yp.
このケースは、セクション3.3のケースとほぼ同じです。ただし、Y1..inは登録から「イベント」機能タグを省略します。YPはセクション3.3のように登録します。プレゼンスイベントパッケージの購読は、YPに優先的にルーティングする必要があります。
The registration from Y1..Yn will look like:
Y1..inからの登録は次のようになります：
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"
When the caller sends a SUBSCRIBE for the presence event package (without explicit preferences), the proxy computes an implicit preference:
発信者がプレゼンスイベントパッケージのサブスクライブ（明示的な設定なし）を送信すると、プロキシは暗黙の好みを計算します。
(& (sip.methods="SUBSCRIBE") (sip.events="presence"))
（＆（sip.methods = "subscribe"）（sip.events = "expencion"））
This predicate matches Y1..Yn and Yp. However, the score for Y1..Yn against this predicate is 0.5, and the score of Yp is 1.0. The result is a caller preference Qa of 0.5 for Y1..Yn, and a caller preference Qa of 1.0 for Yp. Since the callee provided no q-values, the proxy will assume a default of 1.0. Thus, all contacts are in the same equivalence class. They are then sorted by Qa, so that Yp is first, followed by Y1 through Yn. It will therefore route the request first to Yp, and if that should fail, to Y1..Yn.
この述語は、Y1..inとYPと一致します。ただし、この述語に対するY1..inのスコアは0.5で、YPのスコアは1.0です。その結果、Y1..inの場合は0.5の発信者優先QAと、YPの場合は1.0の発信者優先QAが得られます。CalleeはQ値を提供しなかったため、プロキシはデフォルト1.0を想定します。したがって、すべての連絡先は同じ等価クラスにあります。その後、それらはQAによってソートされるため、YPが最初に、次にY1からYnが続きます。したがって、最初にリクエストをYPにルーティングし、それが失敗した場合、Y1..inにルーティングします。
X sends an invitation to Y to initiate an audio/video call, including both m=audio and m=video lines in the SDP. AOR Y has two contacts, Y1 and Y2. Y1 represents a normal audio phone, where Y prefers to receive their calls. It will answer an audio/video call, refusing the video. Y2 represents an audio/video phone that should only used when needed. The caller really wants the call answered by a device that supports video, but will accept an audio-only call as a second choice.
X Yに招待状を送信して、SDPのM = AudioとM =ビデオラインの両方を含むオーディオ/ビデオ通話を開始します。AOR Yには、Y1とY2の2つの連絡先があります。Y1は通常のオーディオ電話を表し、Yは通話を受信することを好みます。音声/ビデオ通話に応答し、ビデオを拒否します。Y2は、必要なときにのみ使用するオーディオ/ビデオ電話を表します。発信者は、ビデオをサポートするデバイスによって応答されたコールを本当に望んでいますが、2番目の選択肢としてオーディオのみの呼び出しを受け入れます。
Y1 will generate a registration that looks like, in part:
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 will generate a registration that looks like, in part:
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"
Note the different q-values, allowing Y2 to be selected as a device of "last resort".
異なるQ値に注意して、Y2を「最後のリゾート」のデバイスとして選択できるようにします。
To have the call preferentially routed to a device that supports video, the caller X sends an INVITE that looks like, in part:
ビデオをサポートするデバイスに通話を優先的にルーティングするために、発信者Xは、部分的には次のような招待状を送信します。
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *
;methods="INVITE"
;video
The proxy will convert this to a feature set. This feature set matches Y2 and Y1. However, the score for Y2 is 1.0, and 0.5 for Y1. The two contacts are then ordered by q-value and broken into equivalence classes. There are two equivalence classes, each with one contact. As a result, the caller preference values have no impact on the ordering. The call will first try the higher priority Y1, which will answer the call and reject the video stream. Thus, the desired behavior is not achieved.
プロキシはこれを機能セットに変換します。この機能セットは、Y2とY1と一致します。ただし、Y2のスコアは1.0、Y1の場合は0.5です。2つの連絡先はQ値によって注文され、同等のクラスに分割されます。2つの等価クラスがあり、それぞれに1つの連絡先があります。その結果、発信者の選好値は注文に影響を与えません。コールは、最初により高い優先Y1を試し、コールに応答し、ビデオストリームを拒否します。したがって、望ましい動作は達成されません。
The desired behavior could be achieved by adding the "explicit" and "require" tags to the Accept-Contact header field in the INVITE, as is done in Section 3.6. However, doing so may result in calls failing when they could occur, but without video. As discussed in [3], both the "require" and "explicit" tags are generally used only when the request cannot be serviced in any way unless the preferences are met. That is not the case here.
目的の動作は、セクション3.6で行われるように、招待状のaccept-contactヘッダーフィールドに「明示的」と「要求」タグを追加することで実現できます。ただし、そうすることで、ビデオが発生する可能性がありますが、ビデオがない場合に障害が発生する可能性があります。[3]で説明したように、「要求」タグと「明示的」タグの両方は、好みが満たされない限り、要求を何らかの方法でサービスを提供できない場合にのみ使用されます。ここではそうではありません。
This case is similar to that of Section 3.5. However, X requires an audio/video call and would like the call to fail if this is not possible, rather than succeed with audio only.
このケースは、セクション3.5のケースに似ています。ただし、Xにはオーディオ/ビデオ通話が必要であり、これが不可能な場合は、オーディオのみで成功するのではなく、コールが失敗することを希望します。
The solution is similar to that of Section 3.5; however, the Accept-Contact header field now includes the "explicit" and "require" tags, guaranteeing that the call is never established to any UA that had not explicitly indicated support for video:
この解決策は、セクション3.5の解と似ています。ただし、Accept-Contactヘッダーフィールドには「明示的」および「要求」タグが含まれるようになりました。ビデオのサポートを明示的に示していないUAにコールが確立されないことを保証します。
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;video;require;explicit
This arrives at the example.com proxy. This explicit feature set matches the feature set for Y2 and Y1. However, the match for Y1 did not have a score of 1. Since the "explicit" and "require" tags are present, the contact is discarded. That leaves Y2 only. The call will therefore get routed to the videophone, and if the user is not there, the audio phone will never ring.
これは、example.comプロキシに到着します。この明示的な機能セットは、Y2とY1の機能セットと一致します。ただし、Y1の一致は1のスコアを持っていませんでした。「明示的」と「要求」タグが存在するため、連絡先は破棄されます。それはY2のみを残します。したがって、コールはビデオフォンにルーティングされ、ユーザーがそこにいない場合、オーディオ電話は鳴りません。
Because both the "require" and "explicit" flags are present, a contact will also be discarded if it does not include a feature tag indicating support for video. Thus, a UA that can do video, but neglected to indicate it, would not be reached in this case. This is why it is important for a UA to indicate all of its capabilities. Note that this is only true for a contact that indicated some capabilities but not the video capability. Contacts that don't indicate any capabilities are "immune" from caller preferences filtering and would not be discarded.
「必要」と「明示的な」フラグの両方が存在するため、ビデオのサポートを示す機能タグが含まれていない場合、連絡先も破棄されます。したがって、ビデオを実行できるが、それを示すことを怠ったUAは、この場合には到達しません。これが、UAがそのすべての機能を示すことが重要である理由です。これは、ビデオ機能ではなく、いくつかの機能を示した連絡先にのみ当てはまることに注意してください。能力を示していない連絡先は、発信者の好みのフィルタリングから「免疫」であり、破棄されません。
Z is a third-party call control controller (3pcc) [9] trying to establish an audio/video call from X to Y. X has contacts X1 and X2, and Y has contacts Y1 and Y2. X1 and X2 have capabilities identical to Y1 and Y2, respectively. Z needs to send an offerless invite to X and use the offer proposed by X to send an invite to Y. When sending the offerless invite to X, the 3pcc controller must ensure that an audio/video contact (X2) is chosen over an audio only contact (X1).
Zは、XからYへのオーディオ/ビデオコールを確立しようとするサードパーティコールコントロールコントローラー（3PCC）[9]です。XにはX1およびX2が接触しており、YにはY1とY2が連絡しています。X1とX2には、それぞれY1とY2と同一の機能があります。ZはXに提供されない招待を送信し、Xが提案したオファーを使用してYに招待を送信する必要があります。Xに提供される招待を送信するとき、3PCCコントローラーはオーディオ/ビデオの連絡先（x2）がオーディオよりも選択されることを確認する必要があります。（x1）のみの連絡先。
X1 will generate a registration that looks like, in part:
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 will generate a registration that looks like, in part:
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 would include, in its INVITE, an Accept-Contact header field:
zには、招待状に、受け入れコンタクトヘッダーフィールドが含まれます。
INVITE sip:X@example.com SIP/2.0
Accept-Contact: *;audio;video;require;explicit
This caller preference matches both X1 and X2. However, it matches X1 with a score of .5 and X2 with a score of 1. Because of the "require" and "explicit" tags, X1 is discarded despite X's preference for it. Thus, the call is routed to X2.
この発信者の好みは、X1とX2の両方と一致します。ただし、スコアが.5とX2のスコアを1のスコアと一致させます。「必要」と「明示的」タグのため、X1はXの好みにもかかわらず破棄されます。したがって、コールはx2にルーティングされます。
The same caveats apply here as do in Section 3.6. Generally, it is not advisable to mandate support for features (such as video) that are not strictly necessary for the request to proceed.
セクション3.6の場合と同じ警告がここに適用されます。一般に、リクエストを続行するために厳密に必要ではない機能（ビデオなど）のサポートを義務付けることはお勧めできません。
AOR Y has two contacts: Y1, which is a regular audio phone, and Y2, which is a PC capable of supporting both audio and session-oriented IM [10]. X is a PC with capability to support audio, video, and session-oriented IM. X calls Y for the purpose of establishing a voice call. However, X wishes to connect to the device that has the maximal overlap with its media capabilities, in order to maximize the functionality available to the caller.
AOR Yには、通常のオーディオ電話であるY1とY2の2つの連絡先があります。これは、オーディオとセッション指向のIMの両方をサポートできるPCです[10]。Xは、オーディオ、ビデオ、セッション指向のIMをサポートする機能を備えたPCです。x音声呼び出しを確立する目的でyを呼び出します。ただし、Xは、発信者が利用できる機能を最大化するために、メディア機能と最大の重複を持つデバイスに接続したいと考えています。
Y1 will generate a registration that looks like, in part:
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"
Y2 will generate a registration that looks like, in part:
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"
The solution requires the caller to support caller preferences. The caller would include, in their INVITE, an Accept-Contact header field that lists all the media types they support. In this case:
ソリューションでは、発信者が発信者の好みをサポートする必要があります。発信者は、招待状に、サポートするすべてのメディアタイプをリストするAccept-Tontactヘッダーフィールドを含めます。この場合：
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;audio;video;+sip.message
Both Y1 and Y2 match the predicate. Y1 matches with a score of 0.33, and Y2 matches with a score of 0.66. Since there is only one Accept-Contact predicate, the Qa for each contact is equal to the score. The registered contacts are then sorted by q-value and broken into equivalence classes. There is a single equivalence class with q-value of 1.0. The two contacts in that class are then re-ordered based on the values of Qa. Y2 has a higher Qa, so it is used first, followed by Y1. The result is that the call is routed to the device with the maximum overlap in media capabilities, as desired.
Y1とY2の両方が述語に一致します。Y1は0.33のスコアで一致し、Y2は0.66のスコアで一致します。Accept-Contact述語は1つしかないため、各接触のQAはスコアに等しくなります。登録された連絡先は、Q値によってソートされ、同等のクラスに分割されます。Q値が1.0の単一の等価クラスがあります。そのクラスの2つの連絡先は、QAの値に基づいて再注文されます。Y2のQAが高いため、最初に使用され、次にY1が使用されます。その結果、呼び出しは、必要に応じて、メディア機能の最大重複を持つデバイスにルーティングされます。
Note that neither "require" nor "explicit" tags are used because there is no intent to exclude contacts, only to order them.
連絡先を除外するつもりはなく、注文するだけであるため、「要求」も「明示的な」タグも使用されないことに注意してください。
AOR Y represents a shared line in an office. Several employees in the office have phones registered for Y. Some of the employees speak only English, some speak Spanish fluently and have some limited capability for English, and some speak both English and Spanish fluently. Calls from callers that speak only English should be parallel forked to all office workers that speak fluent English. If the call isn't picked up, then the phones of workers that speak English marginally should be rung. Calls from callers that speak only Spanish should be forked only to workers that speak Spanish.
aor yは、オフィスの共有ラインを表しています。オフィスの数人の従業員はYに登録されている電話をかけています。従業員の一部は英語のみを話し、一部はスペイン語を流fluentに話し、英語の能力が限られている人もいれば、英語とスペイン語の両方を流fluentに話します。英語のみを話す発信者からの電話は、流fluent英語を話すすべてのオフィスワーカーに並行して分岐する必要があります。コールがピックアップされていない場合、英語をわずかに話す労働者の携帯電話は鳴り響くべきです。スペイン語だけを話す発信者からの電話は、スペイン語を話す労働者にのみ分岐する必要があります。
A user at phone Y1 that speaks English only would generate a REGISTER that looks like, in part:
英語を話す電話Y1のユーザーは、部分的には次のようなレジスタを生成します。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>;languages="en"
A user at a phone Y2 that speaks Spanish and a little bit of English would generate a REGISTER that looks like, in part:
スペイン語と少し英語を話す電話Y2のユーザーは、部分的には次のようなレジスタを生成します。
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 has registered two contacts. Both of them route to the same device (pc2.example.com), but they differ in their language support and relative q-values. Multiple contacts are needed whenever a UA wishes to express differing preferences for being reached for different feature collections.
Y2は2つの連絡先を登録しています。どちらも同じデバイス（PC2.example.com）にルーティングしますが、言語サポートと相対Q値が異なります。UAがさまざまな機能コレクションに到達するために異なる好みを表現したい場合はいつでも、複数の連絡先が必要です。
A user at phone Y3 that speaks English and Spanish fluently would generate a REGISTER that looks like, in part:
英語とスペイン語を流fluentに話す電話Y3のユーザーは、部分的には次のようなレジスタを生成します。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y3@pc3.example.com>;languages="es,en"
Notice that only a single contact is needed because the same q-value is applied across all feature collections.
For the language-based routing to occur, the caller must indicate its language preferences explicitly:
言語ベースのルーティングが発生するためには、発信者はその言語の好みを明示的に示す必要があります。
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;languages="en";require
The predicate derived from this looks like:
これから導き出された述語は次のように見えます：
(& (languages="en"))
（＆（言語= "en"））
This matches the one contact for Y1, the second contact registered for Y2, and the one contact for Y3, all with a score of 1.0. The first contact registered by Y2 does not match, and because of the "require" flag, is discarded. The remaining contacts are sorted by q-value and divided into equivalence classes. There are two equivalence classes. The first contains Y1 and Y3 with a q-value of 1.0, and the second contains Y2-en with a q-value of 0.2. The contacts in the first class are ordered by Qa. However, since all contacts have the same value of Qa (1.0), there is no change in ordering. Thus, Y1 and Y3 are tried first, followed by Y2-en. This is the desired behavior.
これは、Y1の1つの連絡先、Y2に登録された2番目の連絡先、Y3の1つの連絡先と一致し、すべて1.0のスコアです。Y2によって登録された最初の連絡先は一致せず、「必要」フラグのために廃棄されます。残りの連絡先はQ値でソートされ、等価クラスに分割されます。2つの等価クラスがあります。1つ目には、Q値が1.0のY1とY3が含まれ、2番目のY2が0.2のQ値を持つY2-ENが含まれます。ファーストクラスの連絡先はQAによって注文されます。ただし、すべての連絡先はQA（1.0）と同じ値を持っているため、注文に変更はありません。したがって、Y1とY3が最初に試行され、次にY2-ENが続きます。これが望ましい動作です。
An "explicit" tag is not used because that would cause the exclusion of a contact that does not mention language.
「明示的な」タグは、言語に言及していない連絡先の除外を引き起こすため、使用されません。
A caller that speaks Spanish only would specify their preference thusly:
スペイン語を話す発信者は、そのように彼らの好みを指定するだけです：
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;languages="es";require
This matches the first contact of Y2 phones, and Y3 phones, all with a score of 1.0. The English contact of Y2, Y2-en, doesn't match and is discarded because of the "require" flag. The remaining contacts are sorted by q-values (Y3, Y2-es) and broken into a single equivalence class containing both contacts. Since the Qa for both contacts is the same (1.0) there is no reordering. The result is that the call is routed to either Y3 or Y2-es.
これは、Y2電話とY3電話の最初の連絡先と一致し、すべてスコアが1.0です。Y2、Y2-enの英語の接触は、「必要」フラグのために一致せず、廃棄されます。残りの接点はQ値（Y3、Y2-ES）でソートされ、両方の接点を含む単一の等価クラスに分類されます。両方の連絡先のQAは同じであるため（1.0）、並べ替えはありません。その結果、コールはY3またはY2-ESにルーティングされます。
AOR Y has two contacts, a phone Y1 and a voicemail service Y2. X wishes to call Y and talk in person. X does not want to be sent to voicemail under any circumstances.
AOR Yには、電話Y1とボイスメールサービスY2の2つの連絡先があります。XはYに電話して直接話したい。Xは、いかなる状況でもボイスメールに送られたくありません。
The phone would register with a Contact that looks like, in part:
電話は、部分的には次のように見える連絡先で登録されます。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>
;audio
;mobility="fixed"
and the voicemail server would register with a Contact that looks like, in part:
そして、ボイスメールサーバーは、部分的には次のように見える連絡先に登録します。
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
The voicemail server registers with a lower q-value so that it is used only after the phone itself is rung. Note that the voicemail server need not actually register. There can be a configured contact and feature set defined for it instead.
ボイスメールサーバーは、Q値が低いために登録されているため、電話自体が鳴ってからのみ使用されます。ボイスメールサーバーは実際に登録する必要はないことに注意してください。代わりに、設定された連絡先と機能セットが定義されています。
A caller that wishes to avoid voicemail can include an explicit preference to avoid it. A caller would do this with the Reject-Contact header field:
ボイスメールを避けたい発信者は、それを回避するための明示的な好みを含めることができます。発信者は、拒否コンタクトヘッダーフィールドでこれを行います。
INVITE sip:Y@example.com SIP/2.0
Reject-Contact: *;msgserver
Since this feature set contains a feature tag that is not contained in the registration for Y1, the feature set is discarded when examining Y1. However, the registration for Y2 contains all feature tags listed in the feature set, and so the rule is considered. There is a match, and therefore, Y2 is discarded. The result is that the user is never routed to voicemail.
この機能セットには、Y1の登録に含まれていない機能タグが含まれているため、Y1を調べるときに機能セットが破棄されます。ただし、Y2の登録には、機能セットにリストされているすべての機能タグが含まれているため、ルールが考慮されます。試合があるため、Y2は破棄されます。その結果、ユーザーがボイスメールにルーティングされることはありません。
The situation is similar to Section 3.10, except the caller wishes only to leave a message, not actually speak to the person.
状況はセクション3.10に似ています。ただし、発信者が実際に人と話すのではなく、メッセージを残すことだけを望んでいます。
The caller would send an INVITE that looks like, in part:
発信者は、部分的には次のような招待状を送信します。
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;msgserver;require;explicit
This caller preference matches both Y1 and Y2. Y1 matches, but with a score of zero. Y2 matches with a score of 1. Since both the
この発信者の好みは、Y1とY2の両方と一致します。Y1は一致しますが、スコアはゼロです。Y2は1のスコアと一致します。両方のため
"require" and "explicit" flags are set, Y1 is discarded. Therefore, the call is routed to Y2, the voicemail server, as desired.
「要求」と「明示的な」フラグが設定され、Y1が破棄されます。したがって、コールは必要に応じてボイスメールサーバーであるY2にルーティングされます。
Because of the presence of the "require" and "explicit" tags, if these preferences are used with a user that doesn't have voicemail or that fails to indicate it with a msgserver capability, the call will fail completely with a 480 Temporarily Unavailable error, rather than connect to the user.
「必要」と「明示的」タグが存在するため、これらの設定がボイスメールを持たないユーザーで使用されている場合、またはMSGServer機能でそれを示していない場合、480が一時的に利用できない場合、コールは完全に失敗しますユーザーに接続するのではなく、エラー。
The situation is similar to that of Section 3.10. However, the caller prefers to leave a message. If voicemail is not available, they are willing to talk to a person.
状況は、セクション3.10の状況に似ています。ただし、発信者はメッセージを残すことを好みます。ボイスメールが利用できない場合、彼らは喜んで人と話をします。
It had been hoped that RFC 3841 could provide a solution for this case, but it does not, because doing so would require a re-ordering of the callee contacts, which is not done. The caller may achieve the intended effect by making two call attempts:
RFC 3841がこのケースの解決策を提供できることが期待されていましたが、そうすることは、Callee接点の再注文が必要であるため、そうではありません。発信者は、2つのコール試行を行うことにより、意図した効果を達成できます。
o First, make an attempt requiring voicemail, as described in Section 3.11.
o まず、セクション3.11で説明されているように、ボイスメールを必要とします。
o If that fails with a 480 error, send an invitation with no Accept-Contact or Reject-Contact headers.
o 480エラーで失敗した場合は、受け入れコンタクトまたは拒否コンタクトヘッダーのない招待状を送信します。
Y is the AOR of an executive. It has three contacts. Y1 is the phone on the executive's desk. Y2 is the phone on the desk of the executive's assistant. Y3 is the address of an auto-attendant system that can answer general questions, route calls to other parties, etc. By default, calls to Y should be directed to Y2, and if that fails, to Y3. If Y3 doesn't answer, then Y1 should ring.
yはエグゼクティブのaorです。3つの連絡先があります。Y1は幹部の机の上の電話です。Y2は、エグゼクティブのアシスタントの机の上の電話です。Y3は、一般的な質問に答える、他の関係者へのルーティングなどに答えることができる自動アテナントシステムのアドレスです。デフォルトでは、Yへの呼び出しはY2に向けられ、それが失敗した場合はY3に向けられる必要があります。Y3が答えない場合、Y1は鳴る必要があります。
This is primarily a called party feature and is best accomplished with a CPL (Call Processing Language) script [5]. However, it can be accomplished with caller preferences alone by properly setting the q-values across the three devices. Assuming this coordination is possible, here are the settings that would be made: Y1 would generate a REGISTER that looks like, in part:
これは主にパーティー機能と呼ばれ、CPL（コール処理言語）スクリプト[5]で最もよく達成されます。ただし、3つのデバイスにQ値を適切に設定することにより、発信者の好みだけで実現できます。この調整が可能であると仮定すると、ここに行われる設定があります。Y1は、部分的には次のようなレジスタを生成します。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>;q=0.1
Y2 would generate a REGISTER that looks like, in part:
Y2は、部分的には次のようなレジスタを生成します。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc2.example.com>;attendant;q=1.0
Y3 would generate a REGISTER that looks like, in part:
Y3は、部分的には次のようなレジスタを生成します。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y3@pc3.example.com>;attendant;automata;q=0.5
Note that, in reality, the automated attendant would probably not use REGISTER. Since the attendant would be used for every employee in the company, a static contact would probably be added administratively for each user in the enterprise. However, the information in that static contact would be identical to the information in the registration above.
実際には、自動化されたアテンダントはおそらくレジスタを使用しないことに注意してください。アテンダントは会社のすべての従業員に使用されるため、おそらくエンタープライズの各ユーザーに静的接触が管理上追加されます。ただし、その静的接触の情報は、上記の登録の情報と同じです。
When X makes a call to the executive, Y, and expresses no preference, the proxy computes an implicit preference to support INVITE. All three contacts match such a preference, even though they have not indicated explicit support for INVITE. Thus, no contacts are discarded. Since each contact has a different q-value, the caller preferences do not cause any reordering. The result is that the call is first routed to Y2, then Y3, then Y1, all as a result of the proper setting of the q-values.
XがエグゼクティブYに電話をかけ、好みを表していない場合、プロキシは招待状をサポートするための暗黙の好みを計算します。3つの連絡先はすべて、招待に対する明示的なサポートを示していないにもかかわらず、そのような好みに一致します。したがって、連絡先は破棄されません。各連絡先には異なるQ値があるため、発信者の好みは並べ替えを引き起こしません。その結果、Q値の適切な設定の結果として、コールは最初にY2、次にY3、次にY1にルーティングされます。
This case is similar to that of Section 3.13, but this time the caller, X, has a preference. X calls Y, but wants to speak directly to the executive. X doesn't want the call to ring either the assistant or the auto attendant (automaton).
このケースはセクション3.13のケースに似ていますが、今回は発信者Xには好みがあります。XはYを呼び出しますが、エグゼクティブと直接話したいと思っています。Xは、コールがアシスタントまたはオートアテンダント（オートマトン）のいずれかを鳴らすことを望んでいません。
X's INVITE would look like, in part:
Xの招待状は、部分的には次のようになります。
INVITE sip:Y@example.com SIP/2.0
Reject-Contact: *;attendant
Reject-Contact: *;automata
Note that the caller uses two separate Reject-Contact header field values, rather than a single one with two separate feature parameters. The distinction is important. If X had to use a single value with two parameters, a matching UA would need to declare that it was BOTH an attendant and an automaton. If it only declared that it was one of these, based on the matching rules in the caller preferences specification, it would not be rejected.
発信者は、2つの個別の機能パラメーターを持つ単一のものではなく、2つの個別の拒否接触ヘッダーフィールド値を使用することに注意してください。区別は重要です。xが2つのパラメーターを使用して単一の値を使用する必要がある場合、一致するUAは、それがアテンダントとオートマトンの両方であることを宣言する必要があります。発信者の設定仕様の一致するルールに基づいて、これらの1つであると宣言した場合、拒否されません。
The above request would result in the elimination of both Y2 and Y3 as contacts. The call would then be routed to Y1, as desired.
上記の要求により、Y2とY3の両方がコンタクトとして排除されます。必要に応じて、コールはY1にルーティングされます。
This case indicates why a CPL script, or some other programmed version of the feature, is preferable. With caller preferences, a caller can override the desired ring sequence and disturb the executive without any kind of authorization. A proper version of this service would simply not permit caller preferences to force the call to go directly to the executive.
このケースは、CPLスクリプト、または機能の他のプログラムバージョンが望ましい理由を示しています。発信者の好みを使用すると、発信者は目的のリングシーケンスをオーバーライドし、いかなる種類の承認なしにエグゼクティブを乱します。このサービスの適切なバージョンでは、発信者の好みがコールを強制的にエグゼクティブに直接送信することを許可しません。
The situation is similar to that in Section 3.13. However, the executive also has a mobile phone that they have registered. Caller X knows that the owner of Y is traveling, and that an assistant is covering the office phone. X wants to call Y and ring only the mobile phone.
状況は、セクション3.13の状況に似ています。ただし、エグゼクティブは登録した携帯電話も持っています。発信者Xは、Yの所有者が旅行していること、およびアシスタントがオフィスの電話をカバーしていることを知っています。XはYに電話し、携帯電話のみを鳴らしたいと考えています。
The mobile phone would generate a registration that looks like, in part:
携帯電話は、部分的には次のような登録を生成します。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y4@mobile.example.com>;mobility="mobile";q=0.1
The caller would express their preference by generating an INVITE that looks like, in part:
発信者は、部分的には次のように見える招待を生成することで、好みを表明します。
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;mobility="mobile";require;explicit
All four contacts match. However, Y1 through Y3 match with a score of zero. Y4 matches with a score of 1. Because of the "require" and "explicit" tags, Y1 through Y3 are discarded, and only Y4 is used, as desired.
4つの連絡先すべてが一致します。ただし、Y1〜Y3はゼロのスコアで一致します。Y4は1のスコアと一致します。「要求」と「明示的」タグのため、Y1〜Y3が破棄され、必要に応じてY4のみが使用されます。
Note that this only works if the mobile phone specifies the mobility feature in its registration.
これは、携帯電話が登録でモビリティ機能を指定している場合にのみ機能することに注意してください。
AOR Y is as in Section 3.9. Caller X, fluent in both English and Spanish, has discovered that the company's Spanish language documentation is inconsistent with the English language documentation and wants to discuss the differences between the two. So X wants to speak with one of the workers that is fluent in both English and Spanish.
aor yはセクション3.9のようです。英語とスペイン語の両方に堪能な発信者Xは、同社のスペイン語の文書が英語の文書と矛盾していることを発見し、2つの違いについて議論したいと考えています。したがって、Xは英語とスペイン語の両方に堪能な労働者の一人と話したいと思っています。
The caller would generate an INVITE that looks like, in part:
発信者は、部分的には次のように見える招待状を生成します。
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;language="en";require
Accept-Contact: *;language="es";require
This will require a Contact URI to match both constraints. That means it needs to support English and Spanish. This will achieve the desired property.
これには、両方の制約に合わせてURIが連絡先が必要です。つまり、英語とスペイン語をサポートする必要があることを意味します。これにより、目的のプロパティが達成されます。
Note that there are two separate Accept-Contact header fields. If the caller had instead used this INVITE:
2つの個別のAccept-Contactヘッダーフィールドがあることに注意してください。発信者が代わりにこの招待を使用していた場合：
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;language="en,es";require
It would have connected them to a UA that speaks either English or Spanish, which is not what is desired here.
英語またはスペイン語のいずれかを話すUAに接続していたでしょうが、これはここで望まれているものではありません。
An "explicit" option is not used, because it would bypass contacts that do not include a language tag.
「明示的な」オプションは使用されません。これは、言語タグを含まない連絡先をバイパスするためです。
3.17. The Number You Have Called...
3.17. あなたが呼んだ番号...
Consider once more the case of the executive, where the caller wishes to reach only their mobile phone (Section 3.15). However, there is a twist. The callee Y has moved to new address YY, and all the configuration described for the callee now applies to YY. The old address Y remains with a pair of statically assigned contacts. One contact is YY. The other is M, referencing an automaton that generates a voice message reporting that the number has been changed. The caller is unaware of the move and calls Y, requesting to reach the mobile phone in exactly the same way they did in Section 3.15. The call should connect to the mobile.
発信者が携帯電話のみに到達することを望んでいるエグゼクティブの場合をもう一度考えてみましょう（セクション3.15）。しかし、ひねりがあります。Callee Yは新しいアドレスYYに移動し、Calleeについて説明されているすべての構成がYYに適用されるようになりました。古いアドレスyは、静的に割り当てられた連絡先のペアが残っています。1つの連絡先はYYです。もう1つはmで、数が変更されたことを報告する音声メッセージを生成するオートマトンを参照します。発信者は動きを知らず、Yに電話をかけ、セクション3.15で行ったのとまったく同じように携帯電話に到達することを要求します。呼び出しはモバイルに接続する必要があります。
There would be four registrations against YY:
YYに対する4つの登録があります。
YY1, the executive, would generate a REGISTER that looks like, in part:
エグゼクティブのYY1は、部分的には次のようなレジスタを生成します。
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY1@pc.example.com>;q=0.1
YY2, the attendant, would generate a REGISTER that looks like, in part:
アテンダントのYY2は、部分的には次のようなレジスタを生成します。
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY2@pc2.example.com>;attendant;q=1.0
YY3, the answering service, would generate a REGISTER that looks like, in part:
応答サービスであるYY3は、部分的には次のようなレジスタを生成します。
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY3@pc3.example.com>;attendant;automata;q=0.5
YY4, the mobile, would generate a REGISTER that looks like, in part:
モバイルであるYY4は、部分的には次のようなレジスタを生成します。
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY4@mobile.example.com>;mobility="mobile";q=0.5
Although it would be configured administratively, there are two registered contacts for Y. The first is for the forwarding:
管理上構成されますが、Yには2つの登録接点があります。1つ目は転送用です。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:YY@example.com>;q=1.0
and the second for the automated answering service:
自動留守サービスの2番目：
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:machine@example.com>;automata;q=0.5
The caller, not knowing that Y has moved, calls Y and asks for their mobile phone:
発信者は、Yが移動したことを知らずに、Yに電話して携帯電話を求めます。
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;mobility="mobile";require;explicit
This reaches the example.com proxy, which finds two registrations. Only one of these (the automaton) is associated with feature parameters. The other has no feature parameters and is therefore immune to caller preferences processing. The caller preferences are applied to the automaton's contact. The feature sets match, but have a score of zero. Since the "require" and "explicit" tags are present, the contact for the automaton is dropped. The other contact, YY@example.com, is then added back in as the sole contact. The proxy therefore sends the call to sip:YY@example.com. There, there are four registrations, all of which are associated with feature parameters. The caller preferences are applied. Only YY4 matches explicitly, however. Because of the presence of the "require" and "explicit" flags, all other contacts are dropped. As such, the call is forwarded to YY4, and the mobile phone rings.
これにより、2つの登録が見つかります。これらのうちの1つ（オートマトン）のみが機能パラメーターに関連付けられています。もう1つには特徴パラメーターがないため、発信者の好みの処理の影響を受けません。発信者の設定は、オートマトンの連絡先に適用されます。機能は一致しますが、スコアはゼロです。「必要」と「明示的」タグが存在するため、オートマトンの連絡先が削除されます。もう1つの連絡先、yy@example.comは、唯一の連絡先として再び追加されます。したがって、プロキシはsipへの呼び出しを送信します：yy@example.com。そこには、4つの登録があり、そのすべてが機能パラメーターに関連付けられています。発信者の設定が適用されます。ただし、YY4のみが明示的に一致します。「必要」と「明示的な」フラグが存在するため、他のすべての連絡先が削除されます。そのため、通話はYY4に転送され、携帯電話が鳴ります。
This use case is nearly identical to that of Section 3.17. However, this time, the caller wishes to contact the personal phone of Y. They don't feel strongly about it, and will accept other devices.
このユースケースは、セクション3.17のユースケースとほぼ同じです。しかし、今回は、発信者はYの個人的な電話に連絡することを希望します。彼らはそれについて強く感じず、他のデバイスを受け入れます。
The INVITE generated by the caller in this case will look like:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;class="personal"
This reaches the example.com proxy. Once more, the first registration (which forwards to the address-of-record for YY) is unaffected by the caller preferences computation. The other contact, for the automaton, is a match, but its score is zero. Its caller preference Qa equals zero. The other contact is added back in with a Qa of 1.0. The contacts are sorted based on q-value, resulting in YY (q=1.0) followed by machine (q=0.5). These are broken into equivalence classes. There are two classes, one for each contact. As a result, the caller's preferences have no impact on the ordering, and the call is routed to YY.
これにより、example.comプロキシに到達します。もう一度、最初の登録（YYの記録アドレスへの転送）は、発信者設定の計算の影響を受けません。オートマトンのもう1つのコンタクトは一致ですが、そのスコアはゼロです。その発信者の好みQAはゼロに等しくなります。もう1つの連絡先は、1.0のQAに戻って追加されます。接点はQ値に基づいてソートされ、YY（Q = 1.0）に続いて機械（Q = 0.5）が続きます。これらは同等のクラスに分割されます。連絡先ごとに1つ、2つのクラスがあります。その結果、発信者の好みは注文に影響を与えず、電話はYYにルーティングされます。
When the request for YY@example.com is processed, all four contacts match. However, the score for all of them is zero (none are the personal phone). As such, the contacts are ordered based on q-value. Each contact has a different q-value, so no reordering based on caller preference is possible (not that the caller preference would cause a reordering; all contacts have a Qa of 0.0). Thus, the highest q-value contact is tried, which is the executive assistant.
yy@example.comのリクエストが処理されると、4つの連絡先すべてが一致します。ただし、それらすべてのスコアはゼロです（個人の電話はありません）。そのため、連絡先はQ値に基づいて注文されます。各連絡先には異なるQ値があるため、発信者の好みに基づいて並べ替えは不可能です（発信者の好みが再注文を引き起こすというわけではありません。すべての連絡先のQAは0.0です）。したがって、最高のQ値接点が試行されます。これはエグゼクティブアシスタントです。
Alice wants to forward her phone to Bob, but doesn't want folks calling her to get Bob's voicemail if he doesn't answer. She wants her callers to get her voicemail.
アリスは自分の電話をボブに転送したいと思っていますが、彼が答えなければボブのボイスメールを手に入れるように彼女に電話することを望んでいません。彼女は発信者にボイスメールを手に入れてほしい。
Alice would create three registrations. The first, Y1, represents Alice's phone. The second is Bob's AOR. The third is a voicemail server. The three contacts have decreasing q-values. The registration for Bob's AOR contains an embedded Reject-Contact header field, which rejects message servers.
アリスは3つの登録を作成します。最初のY1は、アリスの電話を表しています。2つ目はボブのAORです。3番目はボイスメールサーバーです。3つの連絡先はQ値が減少しています。Bob's AORの登録には、メッセージサーバーを拒否する埋め込まれた拒否コンタクトヘッダーフィールドが含まれています。
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
REGISTER sip:example.com
To: <sip:alice@example.com>
Contact: <sip:alice-drop@msgcenter.example.com>
;msgserver;
;automata
;attendant
;q=0.1
Meanwhile, Bob is registered as follows:
一方、ボブは次のように登録されています。
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 calls Alice and doesn't include any caller preference parameters. As such, the example.com proxy constructs an implicit preference for INVITE. This preference matches all three registered contacts, with a score of zero. Because each contact has a different q-value, there is no reordering of contacts. So, the proxy tries the highest q-value Contact, Alice's desk phone (Y1). The proxy cancels after a few seconds (no answer). The proxy then tries the next Contact, which is Bob's AOR. When constructing the request for this Contact, the proxy includes the embedded Reject-Contact header field in the INVITE. This INVITE undergoes caller preferences processing based on Bob's registered Contacts.
キャロルはアリスに電話し、発信者の好みのパラメーターは含まれていません。そのため、example.comプロキシは、招待に対する暗黙の好みを構築します。この設定は、登録された3つの連絡先すべてとゼロのスコアと一致します。各連絡先には異なるQ値があるため、連絡先の並べ替えはありません。したがって、プロキシは、最高のQ値コンタクトであるAlice's Desk Phone（Y1）を試みます。プロキシは数秒後にキャンセルします（答えなし）。次に、プロキシは次の連絡先、つまりボブのAORです。この連絡先のリクエストを作成するとき、プロキシには招待状に埋め込まれた拒否コンタクトヘッダーフィールドが含まれます。この招待状は、ボブの登録された連絡先に基づいて発信者の選好処理を受けます。
Bob has two registered Contacts. The second is a message server, and it matches the Reject-Contact in the INVITE. Thus, this contact is discarded. The other remaining Contact, Bob's phone, is tried. Bob is not around, so his phone rings for a while. Upon timeout, the proxy determines it is unable to reach Bob's AOR. So, the proxy handling Alice tries the final remaining contact, which is Alice's message server.
ボブには2つの登録連絡先があります。2番目はメッセージサーバーであり、招待状の拒否コンタクトと一致します。したがって、この接触は破棄されます。残りの連絡先、ボブの電話は試されます。ボブは周りにいないので、彼の電話はしばらく鳴ります。タイムアウト時に、プロキシはボブのAORに到達できないと判断します。したがって、アリスの処理プロキシは、アリスのメッセージサーバーである最終的な残りの連絡先を試みます。
The callee capabilities spec [2] allows the Contact header field in OPTIONS responses and dialog initiating messages to contain capabilities of the UA. These capabilities can be very useful for developing new applications. In the subsections below, several usages are outlined.
Callee機能仕様[2]を使用すると、Options Responsesとダイアログのコンタクトヘッダーフィールドが、UAの機能を含むメッセージを開始するダイアログを許可します。これらの機能は、新しいアプリケーションの開発に非常に役立ちます。以下のサブセクションでは、いくつかの使用法が概説されています。
A caller sends an INVITE to the called party. However, the called party is not present. The proxy server representing the called party would like to redirect the caller to a web page, where they can find out more information on how to reach the called party. However, the proxy needs to know whether or not the caller supports redirects to web pages. If it doesn't, the proxy would connect the user to an interactive voice response (IVR) device, which would execute an answering machine application.
発信者は、呼び出されたパーティーに招待状を送ります。ただし、呼び出されたパーティーは存在しません。呼び出された当事者を表すプロキシサーバーは、呼び出し元をWebページにリダイレクトしたいと考えています。そこでは、呼び出されたパーティーに到達する方法に関する詳細情報を知ることができます。ただし、プロキシは、発信者がWebページへのリダイレクトをサポートするかどうかを知る必要があります。そうでない場合、プロキシはユーザーをインタラクティブな音声応答（IVR）デバイスに接続し、留守番電話アプリケーションを実行します。
The proxy could make such a determination if the caller included the "schemes" feature tag in the Contact header field of its INVITE:
プロキシは、発信者が招待の接触ヘッダーフィールドに「スキーム」機能タグを含めた場合、そのような決定を下す可能性があります。
INVITE sip:callee@example.com SIP/2.0
Contact: <sip:host22.example.com>;schemes="http,sip,sips,tel"
This tells the proxy that the UAC can be redirected to an http URI. The INVITE from a normal "black phone" that lacked this capability would look like:
これは、UACをHTTP URIにリダイレクトできることをプロキシに伝えます。この機能が欠けていた通常の「黒い電話」からの招待は次のようになります。
INVITE sip:callee@example.com SIP/2.0
Contact: <sip:host22.example.com>;schemes="sip,sips,tel"
This indicates that it needs to be connected to the IVR.
これは、IVRに接続する必要があることを示しています。
On the circuit network, when a user makes a call, and an answering machine picks up, the caller usually requires several seconds to determine that they are speaking to an answering machine. It would be helpful if a phone could display an icon immediately on call completion that indicated that an answering machine was reached.
回路ネットワークでは、ユーザーが電話をかけ、留守番電話が回復すると、発信者は通常、留守番電話に話しかけていると判断するために数秒が必要です。留守番電話の完了時に電話がすぐにアイコンを表示できる場合は、留守番電話に到達したことを示した場合に役立ちます。
This indication can be provided by the "msgserver" feature parameter. When the answering machine picks up, its 200 OK looks like, in part:
この表示は、「MSGServer」機能パラメーターによって提供できます。留守番電話が取り上げられると、その200 OKは、部分的には次のように見えます。
SIP/2.0 200 OK
Contact: <sip:server33.example.com>;msgserver;automata;attendant
This tells the caller that it's an answering machine.
これは、留守番電話であることを発信者に伝えます。
The caller preferences extension briefly enumerates a list of media feature tags that can be registered by a device and included in the Accept-Contact and Reject-Contact header fields in a request. Proper operation of caller preferences depends strongly on consistent interpretation of these feature tags by the caller and the callee. In this section, we provide some guidelines on the usage of these feature tags.
発信者の設定拡張機能は、デバイスによって登録され、受け入れられた接触および拒否ヘッダーフィールドにリクエストに含まれるメディア機能タグのリストを簡単に列挙します。発信者の好みの適切な操作は、発信者とカリーによるこれらの機能タグの一貫した解釈に強く依存します。このセクションでは、これらの機能タグの使用に関するいくつかのガイドラインを提供します。
Generally speaking, the more information a device provides when it registers, the more effective the caller preferences extension is. This is why the callee capabilities extension recommends that a device register as much information as it can. This point cannot be overstated.
一般的に、デバイスが登録時に提供する情報が多いほど、発信者の好みが拡張されるようになります。これが、Callee機能拡張機能がデバイスができるだけ多くの情報を登録することを推奨する理由です。この点を誇張することはできません。
If devices explicitly registered features that they don't support, such as 'video="false"', the operation of RFC 3841 would be improved. However, given the open-ended nature of capabilities, it will never be possible to ensure the registration of negative values for all capabilities of interest to a caller. Furthermore, attempting to do so would significantly bloat registrations. Instead, it is recommended that all "unusual" capabilities be explicitly registered.
「ビデオ= "false」など、サポートしていないデバイスが明示的に登録されている場合、RFC 3841の操作が改善されます。ただし、能力のオープンエンドの性質を考えると、関心のあるすべての能力の負の値の登録を発信者に確保することは決してできません。さらに、そうしようとすると、登録が大幅に膨れます。代わりに、すべての「珍しい」機能を明示的に登録することをお勧めします。
The subsections below show example registrations from typical devices.
以下のサブセクションは、典型的なデバイスからの登録の例を示しています。
A VoIP cell phone capable of making voice calls would generate a registration that looks like, in part:
音声通話を行うことができる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"
A traditional landline IP PBX phone would generate a registration that looks like:
従来の固定電話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"
This device also supports the dialog event package and several SIP extensions that would be typical in an IP PBX phone.
このデバイスは、ダイアログイベントパッケージと、IP PBX電話で典型的ないくつかのSIP拡張機能もサポートしています。
A PC messenger client, capable of just doing presence and IM (no voice) would generate a registration that looks like:
PCメッセンジャークライアントは、存在感を実行することができ、IM（音声なし）が次のように見える登録を生成します。
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"
A standalone IP videophone, capable of audio and video, would generate a registration that looks like, in part
オーディオとビデオが可能なスタンドアロンの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"
RFC 3841 [3] utilizes the definitions and feature matching algorithm defined in RFC 2533 [6]. This provides a precise normative specification of the algorithm. However, that specification isn't ideal as a guideline for implementation because it is more complex than is required for the restricted use employed by RFC 3841. (The simplification is primarily because a particular feature tag may only appear once in each Contact, Accept-Contact, or Reject-Contact header.)
RFC 3841 [3]は、RFC 2533 [6]で定義された定義と特徴の一致するアルゴリズムを利用します。これにより、アルゴリズムの正確な規範的仕様が提供されます。ただし、その仕様は、RFC 3841が採用している制限付き使用に必要な場合よりも複雑であるため、実装のガイドラインとして理想的ではありません。連絡、または拒否ヘッダー。）
This section provides a sample approach to implementing the matching of caller preferences to callee capabilities; it does not require the use of the notation and techniques of RFC 2533. It is not normative, but is believed to be consistent with that definition. It may be considered an alternative for that portion of RFC 3841 beginning with Section 7.2.3 and extending to the end of page 13 in the middle of Section 7.2.4.
このセクションでは、Callee機能への発信者設定のマッチングを実装するためのサンプルアプローチを提供します。RFC 2533の表記と手法の使用は必要ありません。それは規範的ではありませんが、その定義と一致していると考えられています。セクション7.2.3から始まり、セクション7.2.4の途中で13ページの終わりまで延長されるRFC 3841のその部分の代替案と見なされる場合があります。
In this section, there are frequent references to syntactic elements defined by ABNF in RFC 3840, Section 9, and RFC 3841, Section 10. Here, ABNF elements are enclosed to single quotes -- for example, 'feature-param'. Such a reference identifies a sequence of octets within a SIP request that match the corresponding ABNF element when the sip request is parsed according to RFCs 3261, 3840, and 3841.
このセクションでは、RFC 3840、セクション9、およびRFC 3841、セクション10のABNFによって定義された構文要素について頻繁に参照しています。ここでは、ABNF要素は単一の引用符、たとえば「機能パラム」に囲まれています。このような参照は、RFCS 3261、3840、および3841に従ってSIPリクエストが解析されたときに、対応するABNF要素と一致するSIPリクエスト内のオクテットのシーケンスを識別します。
Contact header fields, Accept-Contact header fields, and Reject-Contact header fields each contain zero or more 'feature-param's, each in turn may contain one or more 'tag-value's, or a 'string-value'. The first step is to extract from each header field a more useful representation as a feature set, herein called an FS. (This FS representation of a feature set representation differs from that in RFC 2533.) This process is the same for each type of header.
ヘッダーフィールドに連絡し、接触ヘッダーフィールドを受け入れ、拒否ヘッダーフィールドにそれぞれゼロ以上の「機能パラム」が含まれ、それぞれに1つ以上の「タグ値」、または「文字列値」が含まれます。最初のステップは、各ヘッダーフィールドから、FSと呼ばれる機能セットとしてより有用な表現を抽出することです。（機能セット表現のこのFS表現は、RFC 2533の表現とは異なります。）このプロセスは、ヘッダーのタイプごとに同じです。
An FS consists of a set of one or more feature params denoted by FP. Each FP has a name, denoted FP.NAME, and a set of one or more value ranges denoted by VR. Each VR consists of:
FSは、FPで示される1つ以上の特徴パラメーションのセットで構成されています。各FPには、FP.NAMEと記載されている名前と、VRで示される1つ以上の値範囲のセットがあります。各VRは次のとおりです。
o A type (VR.TYPE): either token (TOKEN-TYPE), string (STRING-TYPE), or number-range (RANGE-TYPE)
o タイプ（vr.type）：トークン（トークンタイプ）、string（string-type）、またはnumber-range（range-type）のいずれか
o A negation flag (VR.NEGATION): either NEGATED, or NON-NEGATED
o 否定フラグ（Vr.Negation）：否定された、または関連していない
o The actual value, differing by type:
o タイプによって異なる実際の値：
* For TOKEN-TYPE and STRING-TYPE, a sequence of octets (VR.OCTETS)
* トークンタイプとストリングタイプの場合、オクテットのシーケンス（vr.octets）
* For RANGE-TYPE, a pair of signed real numbers (VR.LB and VR.UB) representing the lower and upper bounds on the range, inclusive.
* 範囲タイプの場合、範囲の下限と上限を表す署名された実数（VR.LBおよびVR.UB）のペア。
A single FS is created to represent the features of one header. (Contact, Accept-Contact, Reject-Contact.) Within the FS, an FP is created for each 'feature-param' in the header. To create an FP, a 'feature-param' is examined as follows:
単一のFSが作成され、1つのヘッダーの機能を表します。（連絡先、受け入れ、拒否、拒否。）FS内で、ヘッダー内の各「機能パラム」に対してFPが作成されます。FPを作成するには、「機能パラム」を次のように調べます。
o If the 'feature-param' contains an instance of 'other-tags', then FP.NAME is the value matched by 'ftag-name'.
o 「feature-param」に「他のタグ」のインスタンスが含まれている場合、fp.nameは「ftag-name」と一致する値です。
o Otherwise, the 'feature-param' contains an instance of 'base-tags'. If the value matched by 'base-tags' is "language" or "type", then FP.NAME is just the value matched by 'base-tags'. If not, then FP.NAME is the value matched by 'base-tags' and prefixed with "sip.".
o それ以外の場合、「feature-param」には「ベースタグ」のインスタンスが含まれています。「ベースタグ」と一致する値が「言語」または「タイプ」である場合、FP.Nameは「ベースタグ」と一致する値だけです。そうでない場合は、FP.Nameは「ベースタグ」と「SIP」が付いた値です。
o The value of the 'feature-param', if any, is processed (according to the rules in the next section) to extract a set of one or more VRs that are associated with the FP.
o 「feature-param」の値は、ある場合は（次のセクションのルールに従って）処理され、FPに関連付けられている1つ以上のVRのセットを抽出します。
The value of a 'feature-param' is an encoded representation (as specified in RFC 3840) of one or more value ranges of the corresponding feature. There are several data types that these values may take on: boolean, token, string, number, or numeric range. The type is determined by the encoded form of the value. (These types and their representations are specific to this implementation.)
「Feature-Param」の値は、対応する機能の1つ以上の値範囲のエンコードされた表現（RFC 3840で指定）です。これらの値が取る可能性のあるデータ型はいくつかあります：ブール、トークン、文字列、数値、または数値範囲。このタイプは、値のエンコードされた形式によって決定されます。（これらのタイプとその表現は、この実装に固有です。）
(Note: numeric values can explicitly represent a range of values. The other types only represent single value: a degenerate range. The term value range is used to encompass all of these.)
（注：数値値は値の範囲を明示的に表すことができます。他のタイプは単一の値のみを表します。縮退範囲。これらすべてを含むために項値範囲は使用されます。）
The value of the 'feature-param' ('string-value', 'tag-value-list', or none) is converted to VR form as follows:
「feature-param」（「string-value」、「tag-value-list」、またはnone）の値は、次のようにVR形式に変換されます。
o If there is no value, then a single new VR is created with VR.TYPE = TOKEN-TYPE, VR.NEGATION = NON-NEGATED, and VR.OCTETS set to "true".
o 値がない場合、vr.type = token-type、vr.negation = non-negated、およびvr.octetsを「true」に設定して1つの新しいVRが作成されます。
o If the 'feature-param' contains a 'string-value', then a single new VR is created with VR.TYPE = STRING-TYPE, VR.NEGATION = NON-NEGATED, and VR.OCTETS is set to the octets matching 'qdtext'.
o 「feature-param」に「string-value」が含まれている場合、vr.type = string-type、vr.negation = non-negated、vr.octetsを使用して1つの新しいVRが作成され、vr.octetsが一致するオクテットに設定されます。qdtext '。
o Otherwise the 'feature-param' contains a 'tag-value-list', and a new VR is created for each 'tag-value' in the 'tag-value-list', as follows:
o それ以外の場合は、「feature-param」には「タグ値リスト」が含まれており、次のように、「タグ値」の「タグ値」ごとに新しいVRが作成されます。
o If the 'tag-value' begins with "!", VR.NEGATION = NEGATED; otherwise, VR.NEGATION = NON-NEGATED.
o 「タグ値」が「！」で始まる場合、vr.negation =否定。それ以外の場合、vr.Negation = negated。
o If the 'tag-value' contains a 'boolean' or 'token-nobang', then VR.TYPE = TOKEN-TYPE, and VR.OCTETS is set to the octets matched by 'boolean' or 'token-nobang'.
o 「タグ値」に「ブール」または「トークン・ノバン」が含まれている場合、vr.type = token-type、vr.octetsは「boolean」または「token-nobang」と一致するオクテットに設定されます。
o If the 'tag-value' contains a 'numeric', VR.TYPE = RANGE-TYPE and:
o 「タグ値」に「数値」が含まれている場合、vr.type = range-typeおよび：
* If 'numeric-relation' is "<=", VR.UB is set to the numeric value matching 'number'. VR.LB is set to MIN-REAL (a negative number with the largest expressible magnitude.)
* 「数値関係」が「<=」の場合、vr.ubは「番号」に一致する数値に設定されます。VR.LBは、最小リアルに設定されています（最大の表現性の大きさの負の数値）。
* If 'numeric-relation' is "=", both VR.LB and VR.UB are set to the numeric value matching 'number'.
* 「数値関係」が「=」の場合、Vr.LBとVr.ubの両方が「番号」に一致する数値に設定されます。
* If 'numeric-relation' is ">=", VR.LB is set to the numeric value matching 'number' plus a small epsilon. VR.UB is set to MAX-REAL (a positive number with the largest expressible magnitude).
* 「数値関係」が「> =」の場合、vr.lbは「数字」と小さなイプシロンに一致する数値に設定されます。VR.UBは、最大環に設定されています（表現可能な大きさが最大の正の数値）。
* Else the 'numeric-relation' consists of two 'number's separated by a colon. In this case, VR.LB is set to the numeric value of the smaller of the two numbers, and VR.UB is set to the numeric value of the larger of the two numbers.
* それ以外の場合、「数値関係」は、コロンで区切られた2つの「数値」で構成されています。この場合、Vr.LBは2つの数値のうち小さい数の数値に設定され、Vr.ubは2つの数値のうち大きいものの数値に設定されます。
Two VRs match if their ranges overlap. The comparison is done according to type, and only comparisons between like types are defined. When two VRs of differing types are compared, they are considered not to overlap. Either or both of the VRs may be NEGATED. Comparison proceeds as follows:
範囲が重複する場合、2つのVRが一致します。比較はタイプに従って行われ、同種のタイプ間の比較のみが定義されます。異なるタイプの2つのVRを比較すると、それらは重複しないと見なされます。VRのいずれかまたは両方が否定される場合があります。比較は次のように進みます：
o If the VRs are of different types, the match is false.
o VRSが異なるタイプの場合、一致は偽です。
o Otherwise:
o さもないと：
* Two VRs with VR.TYPE = RANGE-TYPE match if max(VR1.LB, VR2.LB) <= min(VR1.UB, VR2.UB).
* vr.type = range-type一致の2つのVR（vr1.lb、vr2.lb）<= min（vr1.ub、vr2.ub）の場合。
* Two VRs with VR.TYPE = TOKEN-TYPE match if their respective VR.OCTETS values compare equal by case-insensitive comparison.
* Vr.Type = Token-Typeの2つのVRは、それぞれのVR.OCTETS値がケース非感受性比較によって等しいと比較された場合に一致します。
* Two VRs with VR.TYPE = STRING-TYPE match if their respective VR.OCTETS values compare equal by case-sensitive comparison.
* Vr.Type = String-Typeの2つのVRは、それぞれのVR.OCTETS値がケースに敏感な比較によって等しいと比較されます。
o The result (true/false) is then negated if VR1.NEGATION = NEGATED, and negated again if VR2.NEGATION = NEGATED.
o Vr1.Negation =否定された場合、結果（true/false）が否定され、vr2.negation =否定された場合に再び否定されます。
In RFC 2533, the matching of two feature sets is commutative, but as applied to caller preferences matching it is not. In this application, one feature set comes from an Accept-Contact or Reject-Contact header, and the other comes from a Contact header. For purposes of this description, these will be termed the preferred-features (FSp) and the capability-features (FSc), respectively. Non-commutativity arises from explicit tests for the presence among capability-params of feature param names used in preferred-features.
RFC 2533では、2つの機能セットのマッチングは通勤ですが、発信者の好みに適用されるように、そうではありません。このアプリケーションでは、1つの機能セットはAccept-contactまたは拒否コンタクトヘッダーからのもので、もう1つはコンタクトヘッダーに由来します。この説明の目的のために、これらはそれぞれ優先フィーチャー（FSP）と機能（FSC）と呼ばれます。非在来性は、優先フィーチャーで使用されている機能パラマネームの能力パラーム間の存在の明示的なテストから生じます。
A preferred-features feature set FSp may be matched to one capability-features feature set FSc, and this yields the following metrics:
優先フィーチュア機能セットFSPは、1つの機能フィーチャー機能セットFSCに一致する場合があり、これにより次のメトリックが得られます。
o NPF - The number of preferred-features.
o NPF-優先フィーチャーの数。
o NCF - The number of preferred-features for which there is a capability-feature of the same name.
o NCF-同じ名前の機能能力がある優先フィーチャーの数。
o NVM - The number of value matches between corresponding features of the two feature sets.
o NVM -2つの機能セットの対応する機能間の値の数の数。
For a particular pair of FPp and FPc, these metrics are computed as follows:
FPPとFPCの特定のペアの場合、これらのメトリックは次のように計算されます。
o All the metrics are set to zero.
o すべてのメトリックはゼロに設定されています。
o The following steps are applied for each feature param (FPp) of the FSp:
o FSPの各機能Param（FPP）に次の手順が適用されます。
* NPF is incremented.
* NPFが増加します。
* A corresponding FP with the same name is sought (using case-insensitive comparison) in the FSc.
* FSCでは、同じ名前の対応するFPが（ケース非感受性比較を使用）求められます。
* If a corresponding feature param (FPc) is found:
* 対応する機能PARAM（FPC）が見つかった場合：
+ NCF is incremented.
+ NCFが増加します。
+ Every VR of FPp is matched to every VR of FPc.
+ FPPのすべてのVRは、FPCのすべてのVRと一致します。
+ If any of those matches succeed, NVM is incremented.
+ これらの試合のいずれかが成功した場合、NVMは増加します。
The reject processing specified in Section 7.4.2 of RFC 3841 may be performed as follows:
RFC 3841のセクション7.4.2で指定された拒否処理は、次のように実行できます。
o For each candidate Contact in the target set, match the feature set of each Reject-Contact to it.
o ターゲットセットの各候補の連絡先について、それぞれの拒否接触の機能セットを一致させます。
o If (NVM == NPF) & (NCF == NPF), remove the contact URI from the target set.
o （nvm == npf）＆（ncf == npf）の場合、ターゲットセットからuriを削除します。
The matching of an Accept-Contact against a Contact and subsequent scoring of the match specified in Section 7.4.2 of RFC 3841 may be performed as follows:
RFC 3841のセクション7.4.2で指定された連絡先に対する受け入れコンタクトのマッチングとその後の試合のスコアリングは、次のように実行できます。
o Match the feature set of the Accept-Contact to that of the Contact as specified in Section 6.4.
o セクション6.4で指定されているように、Accept-Contactの機能セットを連絡先の機能セットに一致させます。
o If (NVM < NCF), then the match failed. If the Accept-Contact had its "require" flag set, then discard the corresponding contact URI from the target set.
o if（nvm <ncf）、試合は失敗しました。Accept-Contactに「要求」フラグセットがある場合は、対応する連絡先URIをターゲットセットから破棄します。
o Compute the score as NVM/NPF.
o スコアをNVM/NPFとして計算します。
o Apply the "require" and "explicit" flags as specified in the text and Figure 7 of RFC 3841.
o RFC 3841のテキストと図7で指定されている「要求」および「明示的な」フラグを適用します。
This document provides explanation and examples of the use and implementation of RFCs 3840 and 3841. The security considerations sections of those documents apply to the material presented here.
このドキュメントは、RFCS 3840および3841の使用と実装の説明と例を提供します。これらのドキュメントのセキュリティに関する考慮事項セクションは、ここに示されている資料に適用されます。
The authors would like to thank Rohan Mahy for his input in this specification.
著者は、この仕様での意見についてRohan Mahyに感謝したいと思います。
[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.
[1] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[2] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[2] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[3] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[3] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）に対する発信者の好み」、RFC 3841、2004年8月。
[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.
[4]
[5] Lennox, J. and H. Schulzrinne, "Call Processing Language Framework and Requirements", RFC 2824, May 2000.
[5] Lennox、J。およびH. Schulzrinne、「コール処理言語のフレームワークと要件」、RFC 2824、2000年5月。
[6] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
[6] Klyne、G。、「メディア機能セットを説明するための構文」、RFC 2533、1999年3月。
[7] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[7] Rosenberg、J.、Schulzrinne、H。、およびR. Mahy、「セッション開始プロトコル（SIP）の招待状のダイアログイベントパッケージ」、RFC 4235、2005年11月。
[8] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[8] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、2004年8月。
[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.
[9] Rosenberg、J.、Peterson、J.、Schulzrinne、H。、およびG. Camarillo、「セッション開始プロトコル（SIP）の第三者コールコントロール（3PCC）の最良の現在のプラクティス」、2004年4月、RFC 3725、RFC 3725。
[10] Campbell, B., "The Message Session Relay Protocol", Work in Progress, July 2006.
[10] Campbell、B。、「メッセージセッションリレープロトコル」、2006年7月、進行中の作業。
Authors' Addresses
著者のアドレス
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサンローゼンバーグシスコシステム600ラニデックスプラザパルシッパニー、ニュージャージー07054米国
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
Paul Kyzivat Cisco Systems 1414 Massachusetts Avenue Boxborough、MA 01719 US
Phone: +1 978 936-1881
EMail: pkyzivat@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。