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
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).
著作権（C）インターネット協会（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）[2]呼び出し先機能の[1]拡張は、UA（ユーザエージェント）は、REGISTERリクエストでその機能を登録することを可能にするメカニズムを説明しています。呼び出し側は、その要求がどのように処理されるかについては、明示的または暗示的に、好みを表現することができます。これは、セッション開始プロトコル[3]の発信者プリファレンスに記載され、連絡先を受け入れ拒否-Contactヘッダフィールドを用いて達成されます。
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.
注：この文書は、それらの文書を読み込むための代替として機能するように意図されていないのRFC 3840と3841.の理解を助けるためのものです。この文書の例は、完全のRFC 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節では、呼び出し先の機能仕様のアプリケーションについて説明します。セクション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は、ユーザのランデブーを容易にするプロトコルです。呼び出し元と呼び出し先は、彼らが通信することができるように、セッション情報を交換するために会う必要があります。ランデブープロセスは、ユーザがネットワークへの接続の複数のポイントを有するという事実によって複雑になります。ユーザー（呼び出し先）は、携帯電話、PDA、職場の電話、自宅の電話、およびいくつかのPCベースの通信アプリケーションのいずれかを持つことができます。誰かがそのユーザは、これらのデバイスのどれにコールがルーティングさを呼び出すと？
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.
確かに、コールは、同時にそれらのすべてに並列フォークとして知られているプロセスをルーティングすることができます。しかし、それは常に必要な動作ではありません。ユーザーは、登録されたデバイスは、特定の順序で試されることを好むかもしれません。例として、ユーザは、最初に彼の携帯電話リングすることを好む、と誰も答えであれば、彼の職場の電話リングの次のものがあります。誰もコールがボイスメールに転送すること、それらのいずれかを回答していない場合は、別のユーザーが、その後、最初にその彼女の携帯電話のリングを好む、その後、彼女の自宅と職場の電話リングを同時に、かつ可能性があります。これらの変動はすべて見つけ、私に/フォローミーが特徴と呼ばれています。
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がサポート見つける-私に/フォローミーは、多くの方法でいただけます。最も基本的には、SIP登録プロセスを介して行われます。ユーザがネットワークに登録を接触させることが可能な各装置。この登録は、ユーザの正規名とデバイスを関連付ける、アドレス・オブ・レコード（AOR）、SIP URIであると呼ばれます。各登録は、他のデバイスに比べて、そのデバイスにコールを受信するための相対的な嗜好を示す嗜好値を含むことができます。誰かが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登録のPreference値は、基本的な検索を-私を提供することができます/フォローミーが備わっています。より複雑な機能をサポートするために、呼処理言語（CPL）は、[5]に指定されています。これは、特定のコールルーティング命令を提供するXMLスクリプトです。ユーザーが通話をルーティングする方法をサーバに指示する、ネットワークにこれらのスクリプトをアップロードすることができます。呼び出しは家族の一員からでない限り、その場合には、時間後にして、携帯電話に - 例として、CPLスクリプトは、ルートに勤務時間中に勤務先の電話番号へのコール（午後5時午前9時）のプロキシを指示することができますそれは、常に携帯電話に行きます。
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発信者の好みの拡張は、そのコールが処理される方法のために、これらの選好を表現する発信者を可能にします。これらの設定は、所望のデバイスの特性の観点で表現されます。これらのプロパティは、デバイスに関する情報のいくつかの種類を伝える名前と値のペアです。一例としては、「モバイル」または「固定」の値を持つことができますプロパティ「モビリティ」、です。呼び出し側が携帯電話に到達しようとするとき、彼らは、コールが「モバイル」に設定されたプロパティ「モビリティ」を持つデバイスにルーティングする必要があることを示し、その呼設定要求（INVITEメソッド）の情報が含まれています。デバイスがネットワークに登録すると、彼らは登録の一部として（また、呼び出し先機能として知られている）、そのプロパティが含まれています。このように、プロキシは、コール適切にユーザーおよびルートに登録された様々なデバイスの能力に対して、発信者の好みに合わせることができます。
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つの特に重要な例は、「ワンナンバー」と「ダイレクト・ツー・ボイスメール」です。
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.
今日の回線交換テレフォニーネットワークでは、ユーザーが複数のデバイスを持って、各デバイスは、自身の電話番号に関連付けられています。ユーザは、典型的には、名刺にこれらの番号のすべてが一覧表示されます：ように、携帯電話、職場の電話、ホームオフィスの電話、およびを。他のユーザーがこれらの番号のすべてを保存し、管理する必要があります。完全かつ最新のこれらの番号を維持することは困難です。あなたが誰かを呼び出したいときは、さらに悪いことに、あなたがしようとする番号を選択する必要があります。時には、あなたは、特定のデバイス（携帯電話）をしたいです。およびその他の時間は、あなただけのどこにいても、それらに到達したいです。後者の場合、ユーザは、一度に各番号、いずれかを試すことを余儀なくされます。これは非効率的であり、例えば、運転中に行うことは難しいです。
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".
このワンナンバーサービスは、発信者の嗜好を利用します。携帯電話のための好みを表現するために、発呼者の装置は、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.
しばしば、道路上の多忙なエグゼクティブはすぐに音声で同僚にメッセージを渡したいと考えています。例として、上司が特定の顧客を呼び出し、保留中の問題を解決するために、従業員に指示する場合があります。このような場合、ユーザは、実際に人に話をしたくはありません。彼らは音声メッセージを残したいです。音声メッセージは、迅速かつポイントにすることができ、一方、電話での会話を持つことは、あまりにも多くの時間を必要とするかもしれません。つかの間の音声会話を忘れたり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.
代わりに、携帯電話のアドレス帳は、アドレス帳の各エントリに利用可能な「休暇の音声メッセージ」、というオプションを持つことができます。このオプションを選択すると、呼び出しはすぐにピックアップし、メッセージの入力を要求し、そのユーザのためのボイスメールに直接行われます。呼び出し側が記録手順に直接行くことができるように、実際には、迅速な挨拶は、再生されます。
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.
この機能は、発信者の好みの拡張子を使用して可能です。ユーザが「音声メッセージを残す」オプションを選択すると、携帯電話は、SIP INVITE要求を送信し、発信者の嗜好が「は、msgserver」属性が「真」の値を有するデバイスのための優先度を示すフィールドをヘッダ含みます。これは、登録されたボイスメールサービスへの直接コールをルーティングするプロキシの原因となります。さらに、ボイスメールサーバは、発信者がボイスメールに直接アクセスするように求めていることがわかりますので、明示的にこのような場合のために設計された省略挨拶を再生することができます。
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.
レコード（AOR）Yのアドレスは二つの接点、Y1とY2を持っています。 Y1は、携帯電話ですと、標準的な操作がINVITE ACKをサポートし、OPTIONS、BYE、およびCANCELしかし、Y2がページャであり、唯一のオプションとMESSAGEをサポートし、一方、MESSAGEをサポートしていません。発信者Xは多くのトラフィックは、コールとページの両方のネットワークであり、そうではないそれらをサポートすることができないデバイスを不必要にフォークメッセージをする目的があるYにページを送信したいです。だから、これはYへのメッセージのみがY2に配信されている一方、YののINVITEは、唯一Y1に配信されることを確実にすることによって行われます。
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"
SIP REGISTER：example.comをSIP / 2.0：SIP：Y@example.com問い合わせ：<SIP：Y1@pc.example.com>;方法は= "INVITE、ACKは、OPTIONSは、BYE、CANCEL"; URIユーザーを= "<Y1>"; URI-ドメイン= "example.com";オーディオ;スキーム= "一口";モビリティ= "モバイル"
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"
REGISTER SIP：example.com SIP / 2.0：SIP：Y@example.com連絡先：<SIP：Y2@pc.example.com>;メソッド= "OPTIONS、MESSAGE"; URI-ユーザー= "<Y2>"; URIのドメイン= "example.com"; + sip.message;スキーム= "一口、イム";モビリティ= "モバイル"
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（ユーザエージェントクライアント）がINVITEを送信するときに、example.comのプロキシに到着します。要求には、発信者の好みがありません。しかし、セクションごとの7.2.2 [3]、のように見える暗黙の必要船籍のAccept-連絡先の嗜好を構築するプロキシ：
(& (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.
この機能セットとY1及びY2により登録され、Y1単独マッチの機能セットに[6] RFC 2533のマッチングアルゴリズムを適用します。 Accept-コンタクト述語が必要フラグがセットされているので、Y2は破棄され、INVITE Y1にルーティングされます。
If the request was MESSAGE, the proxy constructs an implicit Accept-Contact preference with its require flag set (require-flagged) that looks like:
リクエストがMESSAGEた場合、プロキシは次のようになりますこと（必要船籍）が必要とフラグが設定された暗黙の受け入れ-接触好みを構築します。
(& (sip.methods="MESSAGE"))
（＆（sip.methods = "MESSAGE"））
which matches the feature set of Y2, but not Y1. Thus, Y1 is discarded, and the request is routed to Y2.
これY1 Y2の機能セットと一致しますが、ありません。このように、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、単一接点を持っています。それは携帯電話だし、そのための標準的な操作は、INVITEをサポートし、ACK、OPTIONS、BYE、およびCANCELが、メッセージをサポートしていません。発信者XはMESSAGEリクエストを送信します。希望の動作は、それが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"
SIP REGISTER：example.comをSIP / 2.0：SIP：Y@example.com問い合わせ：<SIP：Y1@pc.example.com>;方法は= "INVITE、ACKは、OPTIONSは、BYE、CANCEL"; URIユーザーを= "<Y1>"; URI-ドメイン= "example.com";オーディオ;スキーム= "一口";移動度は "固定" =;クラス= "個人"
X sends a MESSAGE request. There are no explicit caller preferences. This results in an implicit require-flagged Accept-Contact preference:
Xは、MESSAGE要求を送信します。明示的な呼び出し側の好みはありません。これは、暗黙の必要船籍のAccept-コンタクト優先しての結果：
(& (sip.methods="MESSAGE"))
（＆（sip.methods = "MESSAGE"））
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-コンタクト述語が船籍必要であるので、それが破棄されます。一致するターゲットが存在しない場合は、RFC 3841のセクション7.2.4によれば、元のターゲットセットが使用されます。所望に応じてこのように、要求は、Y1、1つのオリジナルのターゲットに送信されます。 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.
そこに複数の連絡先があって、それらのどれも受け入れ、連絡先を述語に一致しない場合は、連絡先のすべてを含む元のターゲットセットが復元されます。そして、すべての連絡先は、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の、それぞれの標準操作をサポートすることができます多くのBYE、OPTIONS、ACKをINVITE、およびCANCELも "対話" イベントパッケージのSUBSCRIBEサポートすることができました[7] 。 Yはまた別の連絡先、Ypと、それが存在剤である（PA）を持っている[8]：それは唯一の「プレゼンス」イベントパッケージのSUBSCRIBE要求受け入れることができます。ダイアログパッケージのためのINVITEおよびサブスクライブは、Y1 ... Ynのにフォークされながら存在がYpとにルーティングするためにSUBSCRIBE要求のための目標です。
Y1..Yn will generate REGISTER requests that look like, in part:
Y1..Ynは、部分的に、のように見えるREGISTERリクエストを生成します。
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Yi@pc.example.com> ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE" ;events="dialog" ;uri-user="<Yi>" ;uri-domain="example.com" ;audio ;schemes="sip" ;mobility="fixed" ;class="personal"
SIP REGISTER：example.comをSIP / 2.0：SIP：Y@example.com問い合わせ：<SIP：Yi@pc.example.com>;メソッド= "INVITE、BYE、OPTIONSは、ACKは、SUBSCRIBE、CANCEL";イベント= "ダイアログ"; URI-ユーザー= "<李>"; URI-ドメイン= "example.com";オーディオ;スキーム= "一口";移動度は "固定" =;クラス= "個人"
and Yp will generate a REGISTER request that looks like, in part:
そして、Ypとは、部分的に、のように見えるREGISTERリクエストを生成します。
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Yp@pc.example.com>;methods="SUBSCRIBE" ;events="presence" ;uri-user="<Yp>" ;uri-domain="example.com" ;schemes="sip,pres" ;mobility="fixed" ;class="business"
SIP REGISTER：example.comをSIP / 2.0：SIP：Y@example.com問い合わせ：<SIP：Yp@pc.example.com>;方法は= "SUBSCRIBE";イベント= "存在"; URI-ユーザ= "< YP>」; URI-ドメイン= "example.com";スキーム= "一口、PRES";モビリティ= "固定";クラス= "ビジネス"
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:
プレゼンスのためのSUBSCRIBEリクエストはexample.comのプロキシに到着します。明示的な設定が存在しないので、それはリクエストから暗黙的に必要とフラグ付きのAccept-接触好みを構築します。
(& (sip.methods="SUBSCRIBE") (sip.events="presence"))
（＆（sip.methods = "SUBSCRIBE"）（sip.eventsの= "存在"））
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..Ynは破棄されます。要求は、PAを表す、残りの接触、Ypとに送られます。
An INVITE request without explicit preferences results in an implicit require-flagged Accept-Contact preference:
暗黙の必要船籍のAccept-連絡先を優先して、明示的な好み結果なしでINVITEリクエストを：
(& (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..Ynに一致しますが、Ypと一致していません。 RFC 3841のセクション7.2.4からスコアリングアルゴリズムを使用して、この述語に対するY1..Ynのためのスコアは1.0です。その結果、各コンタクトの発信者嗜好Qaが1.0です。登録は、q値が含まれていなかったので、1.0のデフォルトのq値は、各連絡先URIに適用されます。呼び出し元と呼び出し先のプリファレンスが同じで1.0に全て同じであるので、コンタクトのない並べ替えがありません。その結果、プロキシが要求のために均等に良好な標的としてY1..Ynそれぞれを考慮し、おそらくそれぞれにリクエストをフォークするということです。
A SUBSCRIBE request for the dialog event package without explicit preferences will result in an implicit require-flagged Accept-Contact preference:
明示的に設定せずにダイアログイベントパッケージのSUBSCRIBEリクエストは暗黙の必要船籍のAccept-連絡先の好みになります：
(& (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.
Ypとは破棄され、要求がINVITEだっただけで、残りの連絡先にルーティングされるように、これは、Y1..Ynと一致します。
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..Ynは彼らの登録から「イベント」機能タグを省略します。 YPは、3.3節のように登録します。 Ypとする必要があり、まだ優先ルートプレゼンスイベントパッケージに加入。
The registration from Y1..Yn will look like:
Y1..Ynからの登録は、次のようになります。
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Yi@pc.example.com> ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE" ;uri-user="<Yi>" ;uri-domain="example.com" ;audio ;schemes="sip" ;mobility="fixed" ;class="personal"
example.com SIP / 2.0：SIP登録SIP：Y@example.com問い合わせ：<SIP：Yi@pc.example.com>;方法は= "INVITE、BYE、OPTIONSは、ACKは、SUBSCRIBE、CANCEL"; uri-をユーザー= "<李>"; URI-ドメイン= "example.com";オーディオ;スキーム= "一口";移動度は= "固定";クラス= "個人"
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の= "存在"））
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..YnとYpと一致します。しかし、この述語に対してY1..Ynのスコアは0.5であり、Ypとのスコアは1.0です。結果はY1..Yn 0.5の発信者の嗜好のQa、及びYpと1.0の発信者嗜好のQaです。呼び出し先が何のQ値を提供しないため、プロキシは、1.0のデフォルトを想定します。このように、すべての連絡先は、同じ等価クラスです。 Ypとは、まず、Ynを経由Y1が続いているように、彼らはその後、Qaの順にソートされています。 Y1..Ynへ、したがって、ルートリクエスト最初Ypとになり、それが失敗した場合。
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がm =オーディオおよびm = SDPにおけるビデオラインの両方を含む、オーディオ/ビデオコールを開始するYへの招待を送信します。 AOR Yには二つの接点、Y1とY2を持っています。 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"
example.com SIP / 2.0：SIP：Y@example.com問い合わせ：SIPレジスタ; Q = 1.0;方法は= "INVITE、BYE、OPTIONSは、ACKは、CANCEL" を<SIP Y1@pc.example.com>。 URI-ユーザー= "<Y1>";オーディオ;スキーム= "一口、TEL"; = "example.com" URIドメインのモビリティは、 "固定" =;クラス= "ビジネス"
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"
example.com SIP / 2.0：SIP：Y@example.com問い合わせ：SIPレジスタ; Q = 0.6;方法は= "INVITE、BYE、OPTIONSは、ACKは、CANCEL" を<SIP Y2@pc.example.com>。 URI-ユーザー= "<Y2>"; URI-ドメイン= "example.com";オーディオ;ビデオ;スキーム= "一口、TEL";移動度は= "固定";クラス= "ビジネス"
Note the different q-values, allowing Y2 to be selected as a device of "last resort".
Y2は「最後」のデバイスとして選択できるように、異なるQ値を留意されたいです。
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を送信します。
INVITE sip:Y@example.com SIP/2.0 Accept-Contact: * ;methods="INVITE" ;video
SIPのINVITE：Y@example.com SIP / 2.0は受け入れ-接触：*;方法は= "INVITE";ビデオ
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です。二つの接点は、q値で注文し、等価クラスに分割されています。 2つの等価クラス、一方の接点を持つそれぞれがあります。その結果、呼び出し側のプリファレンス値は順序に影響を与えません。呼び出しは、最初の呼び出しに応答し、ビデオストリームを拒否します優先度の高い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で行われるように、「明示的な」とは、INVITE内の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節と同様です。しかし、受け入れ-Contactヘッダーフィールドになりまし呼び出しが明示的にビデオのサポートを示していない任意のUAに確立されないことを保証し、「明示的」と「必要」のタグが含まれています。
INVITE sip:Y@example.com SIP/2.0 Accept-Contact: *;video;require;explicit
SIPのINVITE：Y@example.com SIP / 2.0は受け入れ-接触：*;ビデオ;必要とします。明示的な
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は、サードパーティ呼制御コントローラ（3PCC）[9] Y. XにXからオーディオ/ビデオ通話を確立しようとすると、接点X1及びX2を有しており、Yは、接点Y1及びY2を有しています。 X1およびX2は、それぞれ、Y1とY2と同じ能力を持っています。 Zは、Xに招待し、XにINVITE offerlessを送信する場合Yに招待を送信するためにXによって提案されたプランを使用offerlessを送信する必要がある、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"
example.com SIP / 2.0：SIP：X@example.com問い合わせ：SIPレジスタ; Q = 1.0;方法は= "INVITE、BYE、OPTIONSは、ACKは、CANCEL" を<SIP X1@pc.example.com>。 URI-ユーザー= "<X1>";オーディオ;スキーム= "一口、TEL"; = "example.com" URIドメインのモビリティは、 "固定" =;クラス= "ビジネス"
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"
example.com SIP / 2.0：SIP：X@example.com問い合わせ：SIPレジスタ; Q = 0.6;方法は= "INVITE、BYE、OPTIONSは、ACKは、CANCEL" を<SIP X2@pc.example.com>。 URI-ユーザー= "<X2>"; URI-ドメイン= "example.com";オーディオ;ビデオ;スキーム= "一口、TEL";モビリティは、 "固定" =;クラス= "ビジネス"
Z would include, in its INVITE, an Accept-Contact header field:
ZはそのINVITE、のAccept-Contactヘッダーフィールドに、含まれます：
INVITE sip:X@example.com SIP/2.0 Accept-Contact: *;audio;video;require;explicit
SIPのINVITE：X@example.com SIP / 2.0は受け入れ-接触：*;オーディオ;ビデオ;必要とします。明示的な
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の両方にマッチします。しかし、それがあるため、「必要」と「明示的」タグの1のスコアが0.5のスコアとX2とX1と一致し、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.
オーディオおよびセッション指向IM [10]の両方をサポートできるPCで通常のオーディオ電話、およびY2、Y1である、：AOR Yには、二つの接点を持っています。 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"
SIP REGISTER：example.comをSIP / 2.0：SIP：Y@example.com問い合わせ：<SIP：Y1@phone.example.com>;方法は= "INVITE、BYE、OPTIONSは、ACKは、CANCEL"; URIユーザーを= "<Y1>"; URI-ドメイン= "example.com";オーディオ;スキーム= "一口、TEL";モビリティ= "固定";クラス= "ビジネス"
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"
example.com SIP / 2.0：SIP登録SIP：Y@example.com問い合わせ：<SIP：Y2@pc.example.com>;方法は= "INVITE、BYE、OPTIONSは、ACKは、メッセージをキャンセル"; uri-をユーザー= "<Y2>"; URI-ドメイン= "example.com";オーディオ; + sip.message;スキーム= "一口、TEL";移動度は= "固定";クラス= "ビジネス"
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:
解決策は、発信者の好みをサポートするために、呼び出し元が必要です。呼び出し側は、彼らの中には、INVITEそれらがサポートするすべてのメディアタイプを示していますのAccept-Contactヘッダーフィールドが含まれるでしょう。この場合：
INVITE sip:Y@example.com SIP/2.0 Accept-Contact: *;audio;video;+sip.message
SIPのINVITE：Y@example.com SIP / 2.0は受け入れ-接触：*;オーディオ;ビデオ; + 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-コンタクト述語があるため、各連絡先のQaがスコアに等しいです。登録された連絡先は、q値によってソートし、同値クラスに分割されています。 1.0のq値を持つ単一の等価クラスがあります。そのクラスに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.ために登録電話を持っている、といくつかは、両方の英語とスペイン語を流暢に話します。英語だけを話す発信者からの通話は、流暢な英語を話すすべてのオフィスワーカーにフォーク平行にする必要があります。コールがピックアップされていない場合は、わずかに英語を話す労働者の電話が鳴らされなければなりません。唯一のスペイン語を話す発信者からの通話は、スペイン語のみを話す労働者にフォークする必要があります。
A user at phone Y1 that speaks English only would generate a REGISTER that looks like, in part:
英語は一部だけで、のように見えるREGISTERを生成する話す電話Y1のユーザ：
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Y1@pc.example.com>;languages="en"
example.com SIP / 2.0：SIP：SIPを登録Y@example.com連絡先：<SIP：Y1@pc.example.com>;言語= "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:
スペイン語を話すと英語の少しの部分では、のように見えるREGISTERを生成する電話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
言語= "ES" 連絡先：<SIP：Y2エン@ PC2、example.com SIP / 2.0：SIP：Y@example.com連絡先：：<Y2-es@pc2.example.com一口>一口を登録します。 example.com>;言語は= "エン"; 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は、二つの接点を登録しています。それらの両方が同じデバイス（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:
一部では、のように見えるREGISTERを生成する流暢に英語とスペイン語を話し、電話Y3でユーザー：
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Y3@pc3.example.com>;languages="es,en"
SIP REGISTER：example.comをSIP / 2.0に：SIP：Y@example.com連絡先：<SIP：Y3@pc3.example.com>;言語= "ES、EN"
Notice that only a single contact is needed because the same q-value is applied across all feature collections.
同じq値は、すべての機能のコレクション全体に適用されるため、単一の接触が必要とされていることに注意してください。
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
SIPのINVITE：Y@example.com SIP / 2.0は受け入れ-接触：*;言語は= "EN";必要
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.
これは、すべての1.0のスコアで、Y1のための1つの接触、Y2に登録され第二のコンタクト、及びY3のための一つの接点と一致します。 Y2によって登録最初の接触が一致しないと、「必要」フラグのため、廃棄されます。残りの接点は、q値によってソートされ、等価クラスに分けられます。 2つの同値クラスがあります。最初は1.0のq値とY1及びY3を含み、第二は、0.2のq値とY2-ENが含ま。ファーストクラスの連絡先は、Qaとによって順序付けられます。すべての連絡先は、Qaの（1.0）の同じ値を持っているので、順序の変更はありません。したがって、Y1及びY3は、Y2エン続いて、最初に試されます。これは、所望の動作です。
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:
スペイン語を話す呼び出し側はthusly自分の好みを指定します：
INVITE sip:Y@example.com SIP/2.0 Accept-Contact: *;languages="es";require
SIPのINVITE：Y@example.com SIPを/ 2.0を受け入れ、お問い合わせ：*;言語= "ES";必要
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.
これは、すべての1.0のスコアで、Y2電話、およびY3の携帯電話の最初の接点と一致します。 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を持っています。 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"
REGISTER SIP：SIP：：へexample.com SIP / 2.0 Y@example.com連絡先：<SIP：Y1@pc.example.com>;オーディオ;モビリティ= "固定"
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
example.com SIP / 2.0：SIP：Y@example.com問い合わせ：SIPレジスタとは、msgserver;オートマトン; <SIP Y2@pc.example.com>を付随;オーディオ; 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:
ボイスメールを避けたい呼び出し側はそれを避けるために、明示的な好みを含めることができます。呼び出し側は、Reject-Contactヘッダーフィールドでこれを行うだろう。
INVITE sip:Y@example.com SIP/2.0 Reject-Contact: *;msgserver
SIPのINVITE：Y@example.com SIP / 2.0は拒否-接触：*;は、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送信し、発信者は、部分的に、次のようになります。
INVITE sip:Y@example.com SIP/2.0 Accept-Contact: *;msgserver;require;explicit
SIPのINVITE：Y@example.com SIP / 2.0には、連絡先を受け入れる：*;は、msgserver;必要とします。明示的な
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には、このケースのためのソリューションを提供できることが望まれていたが、それはしていません。呼び出し側は、2回のコールの試行を行うことによって、目的の効果を達成することができます。
o First, make an attempt requiring voicemail, as described in Section 3.11.
3.11項で説明したように、Oまず、ボイスメールを必要とする試みを、作ります。
o If that fails with a 480 error, send an invitation with no Accept-Contact or Reject-Contact headers.
それが480エラーで失敗した場合は、O、ノーのAccept-接触して招待状を送信したり、ヘッダー・コンタクト拒否。
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に呼び出すことが失敗した場合Y3に、Y2に向けて、しなければなりません。 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:
これは主に、着信側の機能であり、最高のCPLを用いて達成される（処理言語を呼び出す）スクリプト[5]。しかし、それは適切に3つのデバイス間でのq値を設定することでのみ、発信者の嗜好を用いて達成することができます。この調整が可能であると仮定すると、ここで行ったことになる設定は次のとおりです。
Y1 would generate a REGISTER that looks like, in part:
Y1は、部分的に、のように見えるREGISTERが生成されます。
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Y1@pc.example.com>;q=0.1
REGISTER SIP：example.com SIP / 2.0：SIP：Y@example.com問い合わせ：<SIP：Y1@pc.example.com>; Q = 0.1
Y2 would generate a REGISTER that looks like, in part:
Y2は、部分的に、のように見えるREGISTERが生成されます。
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Y2@pc2.example.com>;attendant;q=1.0
付随; Q = 1.0 <Y2@pc2.example.com SIP：> example.com SIP / 2.0：SIP：Y@example.com接触SIPレジスタ
Y3 would generate a REGISTER that looks like, in part:
Y3は、部分的に、のように見えるREGISTERが生成されます。
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Y3@pc3.example.com>;attendant;automata;q=0.5
REGISTER SIP：example.com SIP / 2.0：SIP：Y@example.com問い合わせ：<SIP：Y3@pc3.example.com>;付随;オートマトン; 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.
なお、現実には、自動応答は、おそらくREGISTERを使用することはありません。アテンダントは、会社内のすべての従業員のために使用されるので、静的な接触はおそらく、企業内のユーザーごとに管理上追加されます。しかし、その静的接触の情報は、上記登録の情報と同じであろう。
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への呼び出しを行い、そして何の好みを表現していない場合、プロキシは、INVITEをサポートするための暗黙の優先順位を計算します。すべての3つの接点は、彼らがINVITEのための明示的な支持を表明していないにもかかわらず、このよう嗜好に一致します。このように、何の連絡先は破棄されません。各コンタクトは異なる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：
INVITE sip:Y@example.com SIP/2.0 Reject-Contact: *;attendant Reject-Contact: *;automata
SIPのINVITE：Y@example.com SIP / 2.0は拒否-接触：*;アテンダントは拒否-接触：*;オートマトン
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つの別々のReject-Contactヘッダーフィールド値ではなく、二つの別個の特徴パラメータを持つ単一のものを使用することに注意してください。区別は重要です。 Xは、2つのパラメータを使用して単一の値を使用していた場合は、一致するUAは、それがアテンダントとオートマトンでもあったことを宣言する必要があります。それだけで、それは、発信者の好みの仕様では、一致するルールに基づいて、これらの一つであったことを宣言した場合は、拒否されることはありません。
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
モビリティ= "モバイル"; Q = 0.1 <Y4@mobile.example.com SIP：> example.com SIP / 2.0：SIP：Y@example.com接触SIPレジスタ
The caller would express their preference by generating an INVITE that looks like, in part:
呼び出し側は、部分的に、それがどのように見えるのINVITE生成することで、自分の好みを表現します。
INVITE sip:Y@example.com SIP/2.0 Accept-Contact: *;mobility="mobile";require;explicit
SIPのINVITE：Y@example.com SIP / 2.0は受け入れ-接触：*;モビリティ= "モバイル";必要とします。明示的な
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つの接点が一致します。しかし、ゼロのスコアとY3の試合を通じてY1。 Y4があるため、「必要」と「明示的な」タグの1のスコアと一致し、Y3を介してY1は破棄され、そして所望に応じてのみ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が、英語とスペイン語の両方に堪能、同社のスペイン語の文書が英語のドキュメントと矛盾していると両者の違いを議論したいことを発見しました。そこで、Xは、英語とスペイン語の両方に堪能である労働者の一つで話すことを望んでいます。
The caller would generate an INVITE that looks like, in part:
それをINVITE生成する呼び出し側は部分的には、次のようになります。
INVITE sip:Y@example.com SIP/2.0 Accept-Contact: *;language="en";require Accept-Contact: *;language="es";require
SIPのINVITE：Y@example.com SIPを/ 2.0を受け入れ、接触：*;言語= "エン";必要のAccept-接触：*;言語= "ES";必要
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:
二つの別々のAccept-Contactヘッダーフィールドがあることに注意してください。呼び出し側が代わりに使用していた場合、これはINVITE：
INVITE sip:Y@example.com SIP/2.0 Accept-Contact: *;language="en,es";require
SIPのINVITE：Y@example.com SIP / 2.0は受け入れ-接触：*;言語= "EN、ES";必要
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.
それは言語タグが含まれていない連絡先をバイパスしてしまうため、「明示的な」オプションは、使用されていません。
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）に到達したいエグゼクティブの場合を考えてみましょう。しかし、ねじれがあります。呼び出し先Yは、新しいアドレスYYに移動した、と呼び出し先のために記載されているすべての構成についてYYに適用されます。古いアドレスYは、静的に割り当てられた一対の接点に残ります。一つの接触はYYです。他の番号が変更されたことを報告した音声メッセージを生成するオートマトンを参照する、Mです。呼び出し側は、動きを認識しないと、彼らは3.15節で行ったと全く同じ方法で、携帯電話に到達するために要求し、Yを呼び出します。コールは、携帯電話に接続する必要があります。
There would be four registrations against YY:
YYに対して4人の登録があるでしょう：
YY1, the executive, would generate a REGISTER that looks like, in part:
YY1、幹部は、一部には、のように見えるREGISTERが生成されます。
REGISTER sip:example.com SIP/2.0 To: sip:YY@example.com Contact: <sip:YY1@pc.example.com>;q=0.1
REGISTER SIP：example.com SIP / 2.0：SIP：YY@example.com問い合わせ：<SIP：YY1@pc.example.com>; Q = 0.1
YY2, the attendant, would generate a REGISTER that looks like, in part:
YY2、係員は、部分的には、のように見えるREGISTERが生成されます。
REGISTER sip:example.com SIP/2.0 To: sip:YY@example.com Contact: <sip:YY2@pc2.example.com>;attendant;q=1.0
付随; Q = 1.0 <YY2@pc2.example.com SIP：> example.com SIP / 2.0：SIP：YY@example.com接触SIPレジスタ
YY3, the answering service, would generate a REGISTER that looks like, in part:
YY3、応答サービスは、一部には、のように見えるREGISTERが生成されます。
REGISTER sip:example.com SIP/2.0 To: sip:YY@example.com Contact: <sip:YY3@pc3.example.com>;attendant;automata;q=0.5
REGISTER SIP：example.com SIP / 2.0：SIP：YY@example.com問い合わせ：<SIP：YY3@pc3.example.com>;付随;オートマトン; Q = 0.5
YY4, the mobile, would generate a REGISTER that looks like, in part:
YY4、モバイルは、部分的には、のように見えるREGISTERが生成されます。
REGISTER sip:example.com SIP/2.0 To: sip:YY@example.com Contact: <sip:YY4@mobile.example.com>;mobility="mobile";q=0.5
モビリティ= "モバイル"; Q = 0.5 <YY4@mobile.example.com SIP：> example.com SIP / 2.0：SIP：YY@example.com接触SIPレジスタ
Although it would be configured administratively, there are two registered contacts for Y. The first is for the forwarding:
それは管理上設定されることになるが、最初の転送のためのものであるY.ための2人の登録された連絡先があります。
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:YY@example.com>;q=1.0
REGISTER SIP：example.com SIP / 2.0：SIP：Y@example.com問い合わせ：<SIP：YY@example.com>; Q = 1.0
and the second for the automated answering service:
および自動応答サービスのための第二：
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:machine@example.com>;automata;q=0.5
オートマトン; Q = 0.5 <machine@example.com SIP：> example.com SIP / 2.0：SIP：Y@example.com接触SIPレジスタ
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
SIPのINVITE：Y@example.com SIP / 2.0は受け入れ-接触：*;モビリティ= "モバイル";必要とします。明示的な
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.
これは、二つの登録を見つけexample.comのプロキシに達します。唯一のこれらの（オートマトン）のが特徴パラメータに関連付けられています。他には何の特徴パラメータを持っていないので、呼び出し側の好み処理に免疫があります。呼び出し側の好みは、オートマトンの連絡先に適用されます。機能セットは一致しますが、ゼロのスコアを持っています。 「必要」と「明示的」タグが存在するので、オートマトンのための連絡先は削除されます。他の接触、YY@example.comは、その後、唯一の接点としてに戻って追加されます。 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のようになります。
INVITE sip:Y@example.com SIP/2.0 Accept-Contact: *;class="personal"
SIPのINVITE：Y@example.com SIP / 2.0は受け入れ-接触：*;クラス= "個人"
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のためのアドレス・オブ・レコードを転送する）最初の登録は、発信者の嗜好計算によって影響を受けません。他の接点は、オートマトンのために、マッチされ、そのスコアはゼロです。呼び出し元の好みQaがゼロに等しいです。他の接触は1.0のQaを持つに戻って追加されます。コンタクトは、機械（Q = 0.5）、続いてYY（Q = 1.0）が得られ、q値に基づいてソートされます。これらは、等価クラスに分割されています。二つのクラス、各連絡先に1つがあります。その結果、発信者の好みは、順序に影響を与えない、とコールは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値を有しているので、発信者の嗜好に基づいた並べ替えが可能ではない（発信者の嗜好は、並べ替えを引き起こすしないこと、すべての連絡先が0.0のQaとを有しています）。したがって、最も高い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は、アリスの電話を表します。第二は、BobのAORです。第三は、ボイスメールサーバです。 3つの接点は、Q値が減少しています。 BobのAORのための登録は、メッセージサーバを拒否埋め込ま拒否-連絡先をヘッダフィールドが含まれています。
REGISTER sip:example.com To: <sip:alice@example.com> Contact: <sip:Y1@192.0.2.150>;q=1.0
example.comへ：一口を登録<一口：alice@example.com>連絡先：<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
example.comへ：一口を登録<一口：alice@example.com>連絡先：<SIP：？bob@example.com拒否-連絡先= *;は、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
example.comへ：一口を登録<一口：alice@example.com>連絡先：<SIP：alice-drop@msgcenter.example.com>;は、msgserver; ;オートマトン;付随; 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
example.comへ：一口を登録<一口：bob@example.com>連絡先：<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
msgserver;オートマトン;付随; Q = 0.2 <bob-drop@msgcenter.example.com SIP：> <SIP：bob@example.com>連絡するexample.com：SIPレジスタ
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プロキシは、INVITEに対する暗黙の嗜好を構築します。この設定はゼロのスコアを持つ3人のすべての登録済みの連絡先を、一致しました。各コンタクトは、異なるq値を有するので、接点のない並べ替えがありません。だから、プロキシは最高のq値の連絡先、アリスのデスクフォン（Y1）をしようとします。プロキシは、数秒（応答なし）後にキャンセルされます。プロキシは、その後、BobのAORである次の連絡先を、しようとします。この問い合わせ要求を構築する場合、プロキシは、INVITEに埋め込まReject-Contactヘッダーフィールドを含んでいます。これは、ボブの登録連絡先に基づいて受ける、発信者の好み処理をINVITE。
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人の登録の連絡先があります。第二は、メッセージサーバであり、それは、INVITEで拒否-連絡先と一致します。したがって、この接触が破棄されます。他の残りの連絡先、ボブの電話が、試されています。ボブは周りではないので、しばらくの間、彼の電話が鳴ります。タイムアウト時には、プロキシはボブの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.
呼び出し先機能仕様[2]はOPTIONS応答とUAの機能が含まれているために、メッセージを開始するダイアログでContactヘッダーフィールドが可能になります。これらの機能は、新しいアプリケーションを開発するために非常に役立ちます。以下のサブセクションでは、いくつかの用法が概説されています。
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.
発信者は着信側にINVITEを送信します。しかし、被呼者が存在しません。呼ばれるパーティを表すプロキシサーバは、彼らが呼ばれるパーティーに到達する方法についての詳細な情報を検索できる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のContactヘッダーフィールドにおける特徴タグが含まれている場合、プロキシは、このような決意を作ることができます
INVITE sip:callee@example.com SIP/2.0 Contact: <sip:host22.example.com>;schemes="http,sip,sips,tel"
INVITE SIP：callee@example.com SIP / 2.0連絡先：<SIP：host22.example.com>;スキームは= "HTTP、一口、一口、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：
INVITE sip:callee@example.com SIP/2.0 Contact: <sip:host22.example.com>;schemes="sip,sips,tel"
SIPのINVITE：callee@example.com SIP / 2.0連絡先：<SIP：host22.example.com>;スキーム= "一口、一口、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
SIP / 2.0 200 OK連絡先：<SIP：server33.example.com>;は、msgserver;オートマトン;アテンダント
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.
それが登録するとき、一般的に言えば、装置が提供するより多くの情報は、より効果的な発信者の好みの拡張です。呼び出し先の機能拡張は、それができるように、デバイスは、できるだけ多くの情報を登録することをお勧めします理由です。この点は誇張することはできません。
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"
REGISTER SIP：example.comへのSIP / 2.0：SIP：user@example.com連絡先：<SIP：cell-phone@example.com>;オーディオ;クラス= "ビジネス";二重= "フル"; + sip.extensions = "100rel、パス";モビリティ= "モバイル";方法は= "BYE、OPTIONSは、CANCEL INVITE、ACK";スキーム= "SIP、SIPS、TEL"; URIユーザ= "<携帯電話>"; 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"
example.com SIP / 2.0：SIP：SIPを登録user@example.com連絡先：<SIP：ippbx-phone@example.com>;オーディオ;クラス= "ビジネス";二重= "フル";イベント= "ダイアログ"; + sip.extensions =" 100rel、プライバシー ";移動度は= "固定"、メソッド= "SUBSCRIBE、ACK、CANCEL、BYE、OPTIONSをINVITE";スキーム= "SIPをすする、TEL"; URIユーザ=" <IPPBX電話>」; URI-ドメイン= "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"
REGISTER SIP：example.com SIP / 2.0：SIP：user@example.com連絡先：<SIP：pc-msgr@example.com>;クラス= "個人";モビリティ= "固定";メソッド= "OPTIONS、MESSAGE 、NOTIFY」;スキーム= "一口、すする、イム、PRES"; URI-ユーザー= "<PC-モンシニョール>"; URI-ドメイン= "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"
オーディオ;ビデオ;クラス= "ビジネス";二重= "フル";モビリティ=「固定：<vp@example.com SIP：> example.com SIP / 2.0：SIP：user@example.com連絡先SIPを登録";メソッド="、CANCEL、BYE、ACKをOPTIONSをINVITE」;スキームは= "SIPは、TELをすする"; URI-ユーザ= "<VP>"; URIのドメイン= "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]。これは、アルゴリズムの正確な規範的仕様を提供します。特定の機能タグのみ各連絡先、なAccept-に一度現れることがあるので（単純化が主であるRFC 3841.で採用使用制限のために必要とされるよりも、より複雑であるため、しかし、その仕様は、実装のためのガイドラインとして理想的ではありません連絡、または拒否-Contactヘッダを。）
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.
このセクションでは、呼び出し先機能に発呼者の嗜好のマッチングを実装するサンプルのアプローチを提供します。それはそれは規範的ではなく、その定義と一致すると考えられている表記法とRFC 2533の技術の使用を必要としません。これは、RFC 3841のその部分のための別のセクション7.2.3で始まり、セクション7.2.4の途中でページ13の端部に延びると考えることができます。
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.
例えば、「機能-PARAM」 - このセクションでは、RFC 3840にABNFによって定義される構文要素を頻繁に参照がある、第9、およびRFC 3841、ここでセクション10、ABNF要素は、単一引用符に囲まれています。そのような基準は、SIP要求がRFCの3261、3840、および3841に従って解析され、対応する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.
Contactヘッダーフィールド、のAccept-Contactヘッダーフィールド、および拒否-Contactヘッダーフィールドは、各タグ値の、または 『文字列値』「順番にそれぞれが1つまたは複数を含むことができ、機能-PARAMの」ゼロ個以上含まれています。最初のステップは、本明細書FSと呼ばれる機能セット、各ヘッダフィールドからより有用な表現を抽出することです。このプロセスは、ヘッダの種類ごとに同じである（これは、機能セット表現の表現は、RFC 2533のものと異なるFS）。
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つの以上の特徴のparamsのセットで構成されます。各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）：トークン（TOKEN-TYPE）のいずれか、文字列（文字列型）の、又は数範囲（RANGE-TYPE）
o A negation flag (VR.NEGATION): either NEGATED, or NON-NEGATED
否定、または非否定のいずれか：否定フラグ（VR.NEGATION）O
o The actual value, differing by type:
実際の値O、タイプによって異なります。
* For TOKEN-TYPE and STRING-TYPE, a sequence of octets (VR.OCTETS)
*のトークン-TYPEとSTRING-TYPE、オクテット配列（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.
* RANGE-TYPE、包括的範囲に上限と下限を表す符号付き実数（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は、一つのヘッダの特徴を表すために作成されます。 （連絡先は、連絡先-を受け入れ、-接触を拒否します。）FS内で、FPは、ヘッダー内の各「特徴PARAM」のために作成されます。次のようにFPを作成するには、「機能-paramが」検討しています：
o If the 'feature-param' contains an instance of 'other-tags', then FP.NAME is the value matched by 'ftag-name'.
「機能-paramは」「他のタグ」のインスタンスが含まれている場合は、O、そしてFP.NAMEは「FTAG-名」にマッチした値です。
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それ以外の場合は、「機能-paramが」「ベースタグ」のインスタンスが含まれています。 「ベース・タグ」で一致した値が「言語」または「タイプ」の場合は、FP.NAMEは、「ベース・タグ」で一致した値だけです。そうでない場合は、その後、FP.NAMEは、値「ベースタグ」でマッチし、接頭辞である「一口。」。
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.
「特徴PARAM」の値O、もしあれば、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.)
対応する特徴の一つ以上の値の範囲の（RFC 3840で指定されるように）「特徴PARAM」の値は、符号化された表現です。ブール、トークン、文字列、数値、または数値の範囲：これらの値はを取ることができるいくつかのデータタイプがあります。型は、値の符号化された形で決定されます。 （これらのタイプとその表現は、この実装に固有のものです。）
(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:
次のように「特徴PARAM」（「文字列値」、「タグ値リスト」、またはなし）の値を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はVR.TYPE = TOKEN-TYPE、VR.NEGATION = NON-否定して作成され、「真」に設定VR.OCTETS。
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'.
「機能-paramは」「文字列値」が含まれている場合、O、その後、単一の新しいVRはVR.TYPE = STRING-TYPE、VR.NEGATION = NON-否定して作成され、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それ以外の場合は「機能-paramが」「タグ値リスト」を含んでおり、次のように新しいVRは、「タグ値リスト」内の各「タグ値」のために作成されます。
o If the 'tag-value' begins with "!", VR.NEGATION = NEGATED; otherwise, VR.NEGATION = NON-NEGATED.
O「タグ値が」で始まる場合、VR.NEGATION =否定「！」;それ以外の場合は、VR.NEGATION = NON-否定。
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 'タグ値が「ブール」または「トークンnobang」、次いでVR.TYPE = TOKEN-TYPE、及びVR.OCTETSが「ブール」または「トークン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は、MIN-REALに設定されている（最大発現強度と負の数）。
* 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は、MAX-REAL（最大発現の大きさの正の数）に設定されています。
* 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.
VRSは異なるタイプである場合は、O、試合はfalseです。
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型マッチを持つ2つのVRもしMAX（VR1.LB、VR2.LB）<=分（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型マッチを持つ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型の一致を持つ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 =否定場合否定、および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つの特徴セットには、連絡先を受け入れるか拒否-Contactヘッダから来て、もう一方はContactヘッダから来ています。この説明の目的のために、これらは、それぞれ、好ましく-機能（FSP）及び機能・特徴（FSC）と呼ばれます。非可換性が好ましい-機能で使用される機能のparamの名前の機能-のparamsの中で存在の明示的なテストから生じます。
A preferred-features feature set FSp may be matched to one capability-features feature set FSc, and this yields the following metrics:
好適-機能は、FSPは、FSCの機能セット1の能力・機能に一致させることができる機能セット、およびこれには、以下の指標を得られます。
o NPF - The number of preferred-features.
好ましい-特徴の数 - NPF O。
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.
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.
*同じ名前の対応するFPは、FSCに（大文字小文字を区別しない比較を使用して）求められています。
* 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.
6.4節で指定されているOコンタクトとのAccept-連絡先の機能セットと一致します。
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（NVM <NCF）は、その後、マッチが失敗した場合。受け入れ-連絡先が「必要」フラグが設定されていた場合は、ターゲットセットから対応する連絡先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.
この文書では、それらの文書の3840と3841.セキュリティの考慮事項のセクションでは、ここに提示された資料に適用されます説明と使用例およびRFCの実装を提供します。
The authors would like to thank Rohan Mahy for his input in this specification.
著者は、この仕様で彼の入力のためのロハンマーイに感謝したいと思います。
[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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、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]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivatを、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェントの能力を示します"。
[3] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[3]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、RFC 3841、2004年8月 "セッション開始プロトコル（SIP）のための発信者の環境設定"。
[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]マンキン、A.、ブラドナー、S.、マーイ、R.、ウィリス、D.、オット、J.、およびB.ローゼン、 "セッション開始プロトコル（SIP）のための変更処理"、BCP 67、RFC 3427、2002年12月。
[5] Lennox, J. and H. Schulzrinne, "Call Processing Language Framework and Requirements", RFC 2824, May 2000.
[5]レノックス、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]ローゼンバーグ、J.、Schulzrinneと、H.、およびR.マーイ、RFC 4235、2005年11月 "セッション開始プロトコル（SIP）のためのINVITEが開始ダイアログイベントパッケージ"。
[8] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[8]ローゼンバーグ、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]ローゼンバーグ、J.、ピーターソン、J.、Schulzrinneと、H.、およびG.カマリロを、BCP 85、RFC 3725 "セッション開始プロトコル（SIP）における第三者呼制御（3PCC）のベスト・プラクティスの現在" 、2004年4月。
[10] Campbell, B., "The Message Session Relay Protocol", Work in Progress, July 2006.
[10]キャンベル、B.、「メッセージセッションリレープロトコル」、進歩、2006年7月での作業。
Authors' Addresses
著者のアドレス
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサン・ローゼンバーグシスコシステムズ600 Lanidexプラザパーシッパニー、NJ 07054米国
Phone: +1 973 952-5000 EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
電話：+1 973 952-5000 Eメール：jdrosen@cisco.com URI：http://www.jdrosen.net
Paul Kyzivat Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 US
ポールKyzivatシスコシステムズ1414年マサチューセッツアベニューボックスボロー、MA 01719米国
Phone: +1 978 936-1881 EMail: pkyzivat@cisco.com
電話：+1 978 936-1881 Eメール：pkyzivat@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。