[要約] RFC 5627は、SIPでグローバルにルーティング可能なユーザーエージェントURI（GRUU）を取得および使用するためのガイドラインです。その目的は、ユーザーエージェントの一意の識別子を提供し、SIPセッションの確立と管理を向上させることです。
Network Working Group J. Rosenberg
Request for Comments: 5627 Cisco Systems
Category: Standards Track October 2009
Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザーエージェントURIS（Gruus）を取得して使用する
Abstract
概要
Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. A URI that routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a registrar and for communicating a GRUU to a peer within a dialog.
セッション開始プロトコル（SIP）のいくつかのアプリケーションでは、ユーザーエージェント（UA）がインターネット上の誰でも使用できるURIを構築および配布して、その特定のUAインスタンスへの呼び出しをルーティングする必要があります。特定のUAインスタンスにルーティングするURIは、グローバルにルーティング可能なUA URI（Gruu）と呼ばれます。このドキュメントでは、レジストラからグルーを取得し、ダイアログ内のピアにグルーを伝えるためのSIPの拡張機能について説明します。
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、BSDライセンスに記載されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
3.1. Structure of GRUUs . . . . . . . . . . . . . . . . . . . . 5
3.1.1. GRUUs That Expose the Underlying AOR . . . . . . . . . 6
3.1.2. GRUUs That Hide the Underlying AOR . . . . . . . . . . 6
3.2. Obtaining a GRUU . . . . . . . . . . . . . . . . . . . . . 7
3.3. Using a GRUU . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Dereferencing a GRUU . . . . . . . . . . . . . . . . . . . 8
4. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 9
4.1. Generating a REGISTER Request . . . . . . . . . . . . . . 9
4.2. Learning GRUUs from REGISTER Responses . . . . . . . . . . 10
4.3. Constructing a Self-Made GRUU . . . . . . . . . . . . . . 11
4.4. Using One's Own GRUUs . . . . . . . . . . . . . . . . . . 12
4.4.1. Considerations for Multiple AORs . . . . . . . . . . . 13
4.5. Dereferencing a GRUU . . . . . . . . . . . . . . . . . . . 14
4.6. Rendering GRUUs on a User Interface . . . . . . . . . . . 14
5. Registrar Behavior . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Processing a REGISTER Request . . . . . . . . . . . . . . 14
5.2. Generating a REGISTER Response . . . . . . . . . . . . . . 16
5.3. Timing Out a Registration . . . . . . . . . . . . . . . . 16
5.4. Creation of a GRUU . . . . . . . . . . . . . . . . . . . . 17
5.5. Registration Event Support . . . . . . . . . . . . . . . . 19
6. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Request Targeting . . . . . . . . . . . . . . . . . . . . 19
6.2. Record-Routing . . . . . . . . . . . . . . . . . . . . . . 21
7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Example Call Flow . . . . . . . . . . . . . . . . . . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10.1. Outside Attacks . . . . . . . . . . . . . . . . . . . . . 29
10.2. Inside Attacks . . . . . . . . . . . . . . . . . . . . . . 30
10.3. Privacy Considerations . . . . . . . . . . . . . . . . . . 31
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
11.1. Header Field Parameter . . . . . . . . . . . . . . . . . . 33
11.2. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 33
11.3. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 33
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
13.1. Normative References . . . . . . . . . . . . . . . . . . . 34
13.2. Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. Example GRUU Construction Algorithms . . . . . . . . 37
A.1. Public GRUU . . . . . . . . . . . . . . . . . . . . . . . 37
A.2. Temporary GRUU . . . . . . . . . . . . . . . . . . . . . . 37
Appendix B. Network Design Considerations . . . . . . . . . . . . 39
In the Session Initiation Protocol (SIP), RFC 3261 [1], the basic unit of reference is the Address of Record (AOR). However, in SIP systems a single user can have a number of user agents (handsets, softphones, voicemail accounts, etc.) that are all referenced by the same AOR. There are a number of contexts in which it is desirable to have an identifier that addresses a single user agent rather than the group of user agents indicated by an AOR.
セッション開始プロトコル（SIP）、RFC 3261 [1]では、基本的な参照単位はレコードアドレス（AOR）です。ただし、SIPシステムでは、単一のユーザーには、すべて同じAORによって参照される多くのユーザーエージェント（携帯電話、ソフトフォン、ボイスメールアカウントなど）を持つことができます。AORで示されるユーザーエージェントのグループではなく、単一のユーザーエージェントに対処する識別子を持つことが望ましいコンテキストがいくつかあります。
As an example, consider a blind transfer application (see RFC 5589 [19]). User A is talking to user B. User A wants to transfer the call to user C. So, user A sends a REFER to user C. That REFER looks like, in part:
例として、ブラインド転送アプリケーションを検討してください（RFC 5589 [19]を参照）。ユーザーAはユーザーBと話しているB.ユーザーAはユーザーCに通話を転送したいので、ユーザーAはユーザーCを送信します。
REFER sip:C@example.com SIP/2.0
From: sip:A@example.com;tag=99asd
To: sip:C@example.com
Refer-To: (URI that identifies B's UA)
The Refer-To header field needs to contain a URI that can be used by user C to place a call to user B. However, this call needs to route to the specific UA instance that user B is using to talk to user A. If it doesn't, the transfer service will not execute properly. For example, if A provides C with B's AOR, the call might be routed to B's voicemail rather than B's current handset.
参照ヘッダーフィールドには、ユーザーCがユーザーBに通話するために使用できるURIを含める必要があります。ただし、この呼び出しは、ユーザーBがユーザーAと通信するために使用している特定のUAインスタンスにルーティングする必要があります。それはそうではありません、転送サービスは適切に実行されません。たとえば、AがBのAORでCを提供する場合、呼び出しはBの現在の携帯電話ではなくBのボイスメールにルーティングされる可能性があります。
In order to enable this functionality, user B provides an instance-specific URI to user A in the Contact header of their SIP exchange. This URI refers to the user agent B is currently using, and it can be dereferenced by C's user agent. Because user B doesn't know in advance who user A will transfer the call to, the URI has to be usable by anyone.
この機能を有効にするために、ユーザーBは、SIP Exchangeの連絡先ヘッダーでユーザーAにインスタンス固有のURIを提供します。このURIは、現在使用しているユーザーエージェントBを指し、Cのユーザーエージェントによって参照される可能性があります。ユーザーBが事前にユーザーAが通話を転送するかを事前に知らないため、URIは誰でも使用できる必要があります。
Many current clients attempt to meet the need for an instance-specific identifier by using explicit IP addresses in the values they provide in the Contact header field. However, this interacts poorly with NATs and firewalls, and as a practical matter, these URIs cannot be used by arbitrary external clients. Usage of hostnames has proven problematic for similar reasons. In addition, many SIP clients do not have or cannot obtain a hostname for themselves at all.
多くの現在のクライアントは、コンタクトヘッダーフィールドで提供する値に明示的なIPアドレスを使用することにより、インスタンス固有の識別子の必要性を満たそうとします。ただし、これはNATやファイアウォールとの相互作用が不十分であり、実用的な問題として、これらのURIは任意の外部クライアントでは使用できません。ホスト名の使用は、同様の理由で問題があることが証明されています。さらに、多くのSIPクライアントは、ホスト名をまったく持っていないか、まったく取得できません。
This specification describes a mechanism for providing a unique user-agent identifier which is still globally routable. This identifier is called a Globally Routable User Agent (UA) URI (GRUU).
この仕様は、グローバルにルーティング可能な一意のユーザーエージェント識別子を提供するためのメカニズムについて説明しています。この識別子は、グローバルにルーティング可能なユーザーエージェント（UA）URI（GRUU）と呼ばれます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [4]に記載されているように解釈される。
This specification defines the following additional terms:
この仕様では、次の追加用語を定義します。
contact: The term "contact", when used in all lowercase, refers to a URI that is bound to an AOR and GRUU by means of a registration. A contact is usually a SIP URI, and is bound to the AOR and GRUU through a REGISTER request by appearing as a value of the Contact header field. The contact URI identifies a specific UA.
連絡先：「連絡先」という用語は、すべての小文字で使用される場合、登録によってAORとGruuに結合しているURIを指します。通常、連絡先はSIP URIであり、コンタクトヘッダーフィールドの値として表示されることにより、レジスタリクエストを介してAORとGruuにバインドされます。接触URIは特定のUAを識別します。
remote target: The term "remote target" refers to a URI that a user agent uses to identify itself for receipt of both mid-dialog and out-of-dialog requests. A remote target is established by placing a URI in the Contact header field of a dialog-forming request or response and is updated by target refresh requests or responses.
リモートターゲット：「リモートターゲット」という用語とは、ユーザーエージェントがミッドダイアログと外部の両方のリクエストを受信するために自分自身を識別するために使用するURIを指します。ダイアログ形成リクエストまたは応答のコンタクトヘッダーフィールドにURIを配置することにより、リモートターゲットが確立され、ターゲット更新リクエストまたは応答によって更新されます。
Contact header field: The term "Contact header field", with a capitalized C, refers to the header field that can appear in REGISTER requests and responses, redirects, or dialog-creating requests and responses. Depending on the semantics, the Contact header field sometimes conveys a contact, and sometimes conveys a remote target.
連絡先ヘッダーフィールド：大文字のCを持つ「連絡先ヘッダーフィールド」という用語は、レジスタリクエストと応答、リダイレクト、またはダイアログ作成リクエストと応答に表示できるヘッダーフィールドを指します。セマンティクスに応じて、コンタクトヘッダーフィールドは連絡先を伝え、リモートターゲットを伝えることがあります。
The basic idea behind a GRUU is simple. GRUUs are issued by SIP domains and always route back to a proxy in that domain. In turn, the domain maintains the binding between the GRUU and the particular UA instance. When a GRUU is dereferenced while sending a SIP request, that request arrives at the proxy. It maps the GRUU to the contact for the particular UA instance, and sends the request there.
グルーの背後にある基本的なアイデアは簡単です。GruusはSIPドメインによって発行され、常にそのドメインのプロキシに戻ります。次に、ドメインはGruuと特定のUAインスタンスの間の結合を維持します。SIPリクエストの送信中にGruuが参照されると、そのリクエストはプロキシに到着します。Gruuを特定のUAインスタンスの連絡先にマッピングし、そこにリクエストを送信します。
A GRUU is a SIP URI that has two properties:
Gruuは、2つのプロパティを備えたSIP URIです。
o It routes to a specific UA instance.
o 特定のUAインスタンスにルーティングします。
o It can be successfully dereferenced by any user agent on the Internet, not just ones in the same domain or IP network as the UA instance to which the GRUU points.
o インターネット上のユーザーエージェントによって、GRUUが指すUAインスタンスと同じドメインまたはIPネットワークのユーザーエージェントだけでなく、正常に参照される可能性があります。
In principle, a GRUU can be constructed in any way the domain chooses, as long as it meets the criteria above. However, all GRUUs contain the "gr" URI parameter (either with or without a value), so that a recipient of a GRUU can tell that it has these two properties.
原則として、上記の基準を満たしている限り、ドメインが選択するあらゆる方法でGruuを構築できます。ただし、すべてのGruusには「GR」URIパラメーター（値の有無にかかわらず）が含まれているため、Gruuの受信者はこれら2つのプロパティがあることを知ることができます。
In practice, there are two different types of GRUUs:
実際には、2つの異なるタイプのグルーがあります。
1. GRUUs that expose the underlying AOR
1. 基礎となるAORを暴露するグルー
2. GRUUs that hide the underlying AOR
2. 下にあるaorを隠すグルー
In many cases, it is desirable to construct the GRUU in such a way that the mapping to the AOR is apparent. For example, many user agents retain call logs, which keep track of incoming and outgoing call attempts. If the UA had made a call to a GRUU (perhaps as a consequence of a transfer request), the call log will contain the GRUU. Since the call log is rendered to the user, it would be useful to be able to present the user with the AOR instead, since the AOR is meaningful to users as an identifier.
多くの場合、AORへのマッピングが明らかになるようにGruuを構築することが望ましいです。たとえば、多くのユーザーエージェントは、着信および発信コールの試行を追跡するコールログを保持しています。UAがGruuに電話をかけた場合（おそらく転送要求の結果として）、コールログにはGruuが含まれます。通話ログはユーザーにレンダリングされるため、AORは識別子としてユーザーにとって意味のあるため、代わりにユーザーにAORを提示できると便利です。
This type of GRUU is called a public GRUU. It is constructed by taking the AOR, and adding the "gr" URI parameter with a value chosen by the registrar in the domain. The value of the "gr" URI parameter contains a representation of the UA instance. For instance, if the AOR was "sip:alice@example.com", the GRUU might be:
このタイプのグルーは、パブリックグルーと呼ばれています。AORを取得し、ドメイン内のレジストラが選択した値で「GR」URIパラメーターを追加することによって構築されます。「GR」URIパラメーターの値には、UAインスタンスの表現が含まれています。たとえば、AORが「sip：alice@example.com」だった場合、Gruuは次のとおりです。
sip:alice@example.com;gr=kjh29x97us97d
If a UA removes the "gr" URI parameter, the result is the AOR. Since many systems ignore unknown parameters anyway, a public GRUU will "look" like the AOR to those systems.
UAが「GR」URIパラメーターを削除すると、結果はAORです。とにかく多くのシステムが未知のパラメーターを無視しているため、パブリックグルーはそれらのシステムのAORのように「見える」でしょう。
In other cases, it is desirable to construct a GRUU that obfuscates the AOR such that it cannot be extracted by a recipient of the GRUU. Such a GRUU is called a temporary GRUU. The most obvious reason to do this is to protect the user's privacy. In such cases, the GRUU can have any content, provided that it meets the requirements in Sections 3.1 and 5.4, and the AOR cannot be readily determined from the GRUU. The GRUU will have the "gr" URI parameter, either with or without a value. In order to avoid creating excessive state in the registrar, it is often desirable to construct cryptographically protected "stateless" GRUUs using an algorithm like that described in Appendix A.
それ以外の場合は、AORを難読化するGruuを構築することが望ましいので、Gruuの受信者が抽出できないようにします。そのようなグルーは一時的なグルーと呼ばれます。これを行う最も明白な理由は、ユーザーのプライバシーを保護することです。そのような場合、Gruuはセクション3.1および5.4の要件を満たしていれば、任意のコンテンツを持つことができ、AORはGruuから容易に決定できません。Gruuには、値の有無にかかわらず、「GR」URIパラメーターがあります。レジストラに過度の状態の作成を避けるために、付録Aに記載されているようなアルゴリズムを使用して、暗号化された「ステートレス」グルーを構築することが望ましいことがよくあります。
An example of a temporary GRUU constructed using a stateful algorithm would be:
ステートフルアルゴリズムを使用して構築された一時的なグルーの例は次のとおりです。
sip:asd887f9dfkk76690@example.com;gr
A user agent can obtain a GRUU in one of several ways:
ユーザーエージェントは、いくつかの方法のいずれかでgruuを取得できます。
o As part of its REGISTER transaction.
o 登録トランザクションの一環として。
o By constructing one locally, using the IP address or hostname of the user agent instance as the domain part of the URI. These are called self-made GRUUs, and are only really GRUUs when constructed by UAs that know they are globally reachable using their IP address or hostname.
o URIのドメイン部分としてユーザーエージェントインスタンスのIPアドレスまたはホスト名を使用して、ローカルで1つを構築することにより。これらは自作のグルーと呼ばれ、IPアドレスまたはホスト名を使用してグローバルに到達可能であることを知っているUASによって構築された場合にのみ、実際にGruusです。
o Via some locally specified administrative mechanism.
o いくつかのローカルで指定された管理メカニズムを介して。
A UA that wants to obtain a GRUU via its REGISTER request does so by providing an instance ID in the "+sip.instance" Contact header field parameter, defined in RFC 5626 [14]. For example:
レジスタリクエストを介してGruuを取得したいUAは、RFC 5626 [14]で定義されている「sip.instance」に接触ヘッダーフィールドパラメーターにインスタンスIDを提供することにより、gruuを取得したいと考えています。例えば：
Contact: <sip:callee@192.0.2.2>
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
The registrar detects this header field parameter and provides two GRUUs in the REGISTER response. One of these is a temporary GRUU, and the other is the public GRUU. These two GRUUs are returned in the "temp-gruu" and "pub-gruu" Contact header field parameters in the response, respectively. For example:
レジストラは、このヘッダーフィールドパラメーターを検出し、レジスタ応答で2つのグルーを提供します。これらの1つは一時的なグルーであり、もう1つは公共のグルーです。これらの2つのグルーは、それぞれ応答の「Temp-Gruu」および「Pub-Gruu」コンタクトヘッダーフィールドパラメーターで返されます。例えば：
<allOneLine>
Contact: <sip:callee@192.0.2.2>
;pub-gruu="sip:callee@example.com;gr=urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
;temp-gruu="sip:tgruu.7hs==
jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr"
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;expires=3600
</allOneLine>
Note that the <allOneLine> tag is used as defined in [17].
<alloneline>タグは[17]で定義されているように使用されていることに注意してください。
When a user agent refreshes this registration prior to its expiration, the registrar will return back the same public GRUU, but will create a new temporary GRUU. Despite the fact that each refresh provides the UA with a new temporary GRUU, all of the temporary GRUUs learned from previous REGISTER responses during the lifetime of a contact remain valid as long as (1) a contact with that instance ID remains registered, and (2) the UA doesn't change the Call-ID in its REGISTER request compared to previous ones for the same reg-id [14]. When the last contact for the instance expires, either through explicit de-registration or timeout, all of the temporary GRUUs become invalidated. Similarly, if a register refresh for a contact (or, if RFC 5626 is being used, for a reg-id) changes the Call-ID compared to previous register refreshes, all of the previous temporary GRUUs are invalidated. When the user agent later creates a new registration with the same instance ID, the public GRUU is the same. The temporary GRUU will be new (as it is with refreshes), and it will be the only valid temporary GRUU for the instance until the next refresh, at which point a second one becomes valid too. Consequently, temporary GRUUs "accumulate" during the lifetime of a registration.
ユーザーエージェントが有効期限の前にこの登録を更新すると、レジストラは同じパブリックグルーを返しますが、新しい一時的なグルーを作成します。各リフレッシュはUAに新しい一時的なグルーを提供しているという事実にもかかわらず、（1）そのインスタンスIDとの接触が登録されたままである限り、連絡先の寿命の間に以前のレジスタ応答から学んだ一時的なグルーはすべて有効なままです。2）UAは、同じreg-id [14]の以前の要求と比較して、レジスタリクエストでcall-idを変更しません。インスタンスの最後の連絡先が有効になると、明示的な登録またはタイムアウトのいずれかを通じて、一時的なグルーがすべて無効になります。同様に、連絡先のレジスタリフレッシュ（または、REG-IDでRFC 5626が使用されている場合）の場合、以前のレジスタリフレシと比較してコールIDを変更すると、以前の一時的なグルーはすべて無効になります。ユーザーエージェントが後で同じインスタンスIDで新しい登録を作成すると、パブリックグルーは同じです。一時的なグルーは新しいものになり（リフレッシュと同様）、次の更新までインスタンスの唯一の有効な一時的なグルーになります。その結果、登録の生涯に一時的なグルーが「蓄積」されます。
Once a user agent obtains GRUUs from the registrar, it uses them in several ways. First, it uses them as the contents of the Contact header field in non-REGISTER requests and responses that it emits (for example, an INVITE request and 200 OK response). According to RFC 3261 [1], the Contact header field is supposed to contain a URI that routes to that user agent. Prior to this specification, there hasn't been a way to really meet that requirement. The user agent would use one of its temporary GRUUs for anonymous calls, and use its public GRUU otherwise.
ユーザーエージェントがレジストラからGruusを取得すると、いくつかの方法でそれらを使用します。まず、それらを放射する非登録要求と応答で、それらを連絡先ヘッダーフィールドの内容として使用します（たとえば、招待リクエストや200 OK応答）。RFC 3261 [1]によると、コンタクトヘッダーフィールドには、そのユーザーエージェントにルートするURIが含まれることになっています。この仕様に先立ち、その要件を実際に満たす方法はありませんでした。ユーザーエージェントは、匿名の呼び出しに一時的なグルーの1つを使用し、それ以外の場合はパブリックグルーを使用します。
Second, the UA can use the GRUU in any other place it needs to use a URI that resolves to itself, such as a webpage.
第二に、UAは、Webページなど、それ自体に解決するURIを使用するために必要な他の場所でGruuを使用できます。
Because a GRUU is simply a URI, a UA dereferences it in exactly the same way as it would any other URI. However, once the request has been routed to the appropriate proxy, the behavior is slightly different. The proxy will map the GRUU to the AOR and determine the set of contacts that the particular UA instance has registered. The GRUU is then mapped to those contacts, and the request is routed towards the UA.
Gruuは単なるURIであるため、UAは他のURIとまったく同じ方法でそれを参照します。ただし、リクエストが適切なプロキシにルーティングされると、動作はわずかに異なります。プロキシは、GruuをAORにマッピングし、特定のUAインスタンスが登録した連絡先のセットを決定します。Gruuはそれらの連絡先にマッピングされ、リクエストはUAに向かってルーティングされます。
This section defines the normative behavior for user agents.
このセクションでは、ユーザーエージェントの規範的な動作を定義します。
When a UA compliant to this specification generates a REGISTER request (initial or refresh), it MUST include the Supported header field in the request. The value of that header field MUST include "gruu" as one of the option tags. This alerts the registrar for the domain that the UA supports the GRUU mechanism.
この仕様に準拠したUAがレジスタリクエスト（初期または更新）を生成する場合、リクエストにサポートされているヘッダーフィールドを含める必要があります。そのヘッダーフィールドの値には、オプションタグの1つとして「Gruu」を含める必要があります。これは、UAがGruuメカニズムをサポートしていることをドメインのレジストラに警告します。
Furthermore, for each contact for which the UA desires to obtain a GRUU, the UA MUST include a "sip.instance" media feature tag (see RFC 5626 [14]) as a UA characteristic (see [7]), whose value MUST be the instance ID that identifies the UA instance being registered. Each such Contact header field SHOULD NOT contain a "pub-gruu" or "temp-gruu" header field. The contact URI MUST NOT be equivalent, based on the URI equality rules in RFC 3261 [1], to the AOR in the To header field. If the contact URI is a GRUU, it MUST NOT be a GRUU for the AOR in the To header field.
さらに、UAがGruuを取得したいと望んでいる各連絡先について、UAはUA特性（[7]を参照）として「sip.instance」メディア機能タグ（RFC 5626 [14]を参照）を含める必要があります。登録されているUAインスタンスを識別するインスタンスIDになります。このようなコンタクトヘッダーフィールドには、「パブグルー」または「温度」ヘッダーフィールドを含めるべきではありません。コンタクトURIは、RFC 3261 [1]のURI等式規則に基づいて、ヘッダーフィールドのAORに相当してはなりません。接触URIがグルーである場合、ヘッダーフィールドのAORのGruuであってはなりません。
As in RFC 3261 [1], the Call-ID in a REGISTER refresh SHOULD be identical to the Call-ID used to previously register a contact. With GRUU, an additional consideration applies. If the Call-ID changes in a register refresh, the server will invalidate all temporary GRUUs associated with that UA instance; the only valid one will be the new one returned in that REGISTER response. When RFC 5626 is in use, this rule applies to the reg-ids: If the Call-ID changes for the registration refresh for a particular reg-id, the server will invalidate all temporary GRUUs associated with that UA instance as a whole. Consequently, if a UA wishes its previously obtained temporary GRUUs to remain valid, it MUST utilize the same Call-ID in REGISTER refreshes. However, it MAY change the Call-ID in a refresh if invalidation is the desired objective.
RFC 3261 [1]と同様に、レジスタリフレッシュのコールIDは、以前に連絡先を登録するために使用されるコールIDと同一である必要があります。Gruuでは、追加の考慮事項が適用されます。Call-IDがレジスタの更新で変更された場合、サーバーはそのUAインスタンスに関連付けられているすべての一時グルーを無効にします。唯一の有効なものは、そのレジスタ応答で返された新しいものです。RFC 5626が使用されている場合、このルールはreg-IDに適用されます。特定のreg-IDの登録更新のコールIDが変更された場合、サーバーはそのUAインスタンス全体に関連付けられているすべての一時グルーを無効にします。その結果、UAが以前に入手した一時的なグルーが有効であることを望んでいる場合、レジスタリフレッシュで同じコールIDを利用する必要があります。ただし、無効化が目的である場合、更新でCall-IDを変更する場合があります。
Note that, if any dialogs are in progress that utilize a temporary GRUU as a remote target, and a UA performs a registration refresh with a change in Call-ID, those temporary GRUUs become invalid, and the UA will not be reachable for subsequent mid-dialog messages.
一時的なGruuをリモートターゲットとして利用するダイアログが進行中であり、UAがCall-IDの変更で登録更新を実行する場合、それらの一時的なグルーは無効になり、UAは後続のMIDで到達できないことに注意してください。-dialogメッセージ。
If a UA instance is trying to register multiple contacts for the same instance for the purposes of redundancy, it MUST use the procedures defined in RFC 5626 [14].
UAインスタンスが冗長性の目的で同じインスタンスに対して複数の連絡先を登録しようとしている場合、RFC 5626で定義されている手順を使用する必要があります[14]。
A UA utilizing GRUUs can still perform third-party registrations and can include contacts that omit the "+sip.instance" Contact header field parameter.
Gruusを使用するUAは、まだサードパーティの登録を実行でき、「sip.instance」の連絡先ヘッダーフィールドパラメーターを省略する連絡先を含めることができます。
If a UA wishes to guarantee that the REGISTER request is not processed unless the domain supports and uses this extension, it MAY include a Require header field in the request with a value that contains the "gruu" option tag. This is in addition to the presence of the Supported header field, also containing the "gruu" option tag. The use of Proxy-Require is not necessary and is NOT RECOMMENDED.
UAが、ドメインがこの拡張子をサポートおよび使用しない限り、レジスタリクエストが処理されないことを保証したい場合、「Gruu」オプションタグを含む値を持つ要求に必要なヘッダーフィールドを含めることができます。これは、サポートされているヘッダーフィールドの存在に加えて、「Gruu」オプションタグも含まれています。プロキシリクイアの使用は必要ではなく、推奨されません。
If the REGISTER response is a 2xx, each Contact header field that contains the "+sip.instance" Contact header field parameter can also contain a "pub-gruu" and "temp-gruu" Contact header field parameter. These header field parameters convey the public and a temporary GRUU for the UA instance, respectively. A UA MUST be prepared for a Contact header field to contain just a "pub-gruu", just a "temp-gruu", neither, or both. The temporary GRUU will be valid for the duration of the registration (that is, through refreshes), while the public GRUU persists across registrations. The UA will receive a new temporary GRUU in each successful REGISTER response, while the public GRUU will typically be the same. However, a UA MUST be prepared for the public GRUU to change from a previous one, since the persistence property is not guaranteed with complete certainty. If a UA changed its Call-ID in this REGISTER request compared to a previous REGISTER request for the same contact or reg-id, the UA MUST discard all temporary GRUUs learned through prior REGISTER responses. A UA MAY retain zero, one, some, or all of the temporary GRUUs that it is provided during the time over which at least one contact or reg-id remains continuously registered. If a UA stores any temporary GRUUs for use during its registration, it needs to be certain that the registration does not accidentally lapse due to clock skew between the UA and registrar. Consequently, the UA MUST refresh its registration such that the REGISTER refresh transaction will either complete or timeout prior to the expiration of the registration. For default transaction timers, this would be at least 32 seconds prior to expiration, assuming the registration expiration is larger than 64 seconds. If the registration expiration is less than 64 seconds, the UA SHOULD refresh its registration halfway prior to expiration.
レジスタ応答が2xxの場合、「sip.instance」コンタクトヘッダーフィールドパラメーターを含む各連絡先ヘッダーフィールドには、「Pub-gruu」および「Temp-gruu」コンタクトヘッダーフィールドパラメーターを含めることもできます。これらのヘッダーフィールドパラメーターは、それぞれUAインスタンスの一般と一時的なグルーを伝えます。UAは、「Pub-gruu」だけ、「Temp-gruu」だけでなく、その両方を含むように、コンタクトヘッダーフィールドの準備をする必要があります。一時的なグルーは、登録期間中（つまり、リフレッシュを介して）有効になりますが、登録全体でパブリックグルーは持続します。UAは、成功したレジスタ応答のたびに新しい一時的なグルーを受け取りますが、一般的なGruuは通常同じです。ただし、Persipenceプロパティは完全な確実性が保証されていないため、UAは以前のGruuから変更するために準備する必要があります。UAが同じ連絡先またはreg-IDの以前のレジスタリクエストと比較してこのレジスタリクエストでCall-IDを変更した場合、UAは以前のレジスタ応答を通じて学習したすべての一時的なグルーを破棄する必要があります。UAは、少なくとも1つの接触またはreg-IDが継続的に登録されたままである間に提供されるゼロ、1つ、一部、またはすべての一時的なグルーを保持する場合があります。UAが登録中に使用するために一時的なグルーを保存する場合、UAとレジストラの間の時計歪みのために登録が誤って失効しないことを確認する必要があります。したがって、UAは登録の満了前にレジスタリフレッシュトランザクションが完了またはタイムアウトするように登録を更新する必要があります。デフォルトのトランザクションタイマーの場合、登録の有効期限が64秒を超えると仮定すると、これは有効期限が切れる前に少なくとも32秒になります。登録の有効期限が64秒未満の場合、UAは有効期限の途中で登録を更新する必要があります。
Note that, when [14] is in use, and the UA is utilizing multiple flows for purposes of redundancy, the temporary GRUUs remain valid as long as at least one flow is registered. Thus, even if the registration of one flow expires, the temporary GRUUs learned previously remain valid.
[14]が使用されており、UAが冗長性の目的で複数のフローを利用している場合、少なくとも1つのフローが登録されている限り、一時的なグルーは有効なままであることに注意してください。したがって、たとえ1つのフローの登録が期限切れになったとしても、以前に学んだ一時的なグルーは有効なままです。
In cases where registrars forcefully shorten registration intervals, the registration event package, RFC 3680 [24], is used by user agents to learn of these changes. A user agent implementing both RFC 3680 [24] and GRUU MUST also implement the extensions to RFC 3680 [24] for conveying information on GRUU, as defined in RFC 5628 [28], as these are necessary to keep the set of temporary GRUUs synchronized between the UA and the registrar. More generally, the utility of temporary GRUUs depends on the UA and registrar being in sync on the set of valid temporary GRUUs at any time. Without support of RFC 3680 [24] and its extension for GRUU, the client will remain in sync only as long as it always re-registers well before the registration expiration. Besides forceful de-registrations, other events (such as network outages, connection failures, and short refresh intervals) can lead to potential inconsistencies in the set of valid temporary GRUUs. For this reason, it is RECOMMENDED that a UA that utilizes temporary GRUUs implement RFC 3680 [24] and RFC 5628 [28].
レジストラが登録間隔を強制的に短縮する場合、登録イベントパッケージ、RFC 3680 [24]は、ユーザーエージェントがこれらの変更を知るために使用されます。RFC 3680 [24]とGruuの両方を実装するユーザーエージェントは、RFC 5628 [28]で定義されているように、Gruuに関する情報を伝えるためにRFC 3680 [24]に拡張機能を実装する必要があります。UAとレジストラの間。より一般的には、一時的なグルーの有用性は、UAとレジストラがいつでも有効な一時的なグルーのセットと同期していることに依存します。RFC 3680 [24]とGruuの拡張のサポートがなければ、クライアントは登録の満了のかなり前に常に再登録されている限り、同期し続けます。強制的な登録以外に、他のイベント（ネットワークの停止、接続障害、短い更新間隔など）は、有効な一時的なグルーのセットで潜在的な矛盾につながる可能性があります。このため、一時的なGruus実装RFC 3680 [24]およびRFC 5628 [28]を実装するUAを使用することをお勧めします。
A non-2xx response to the REGISTER request has no impact on any existing GRUUs previously provided to the UA. Specifically, if a previously successful REGISTER request provided the UA with a GRUU, a subsequent failed request does not remove, delete, or otherwise invalidate the GRUU.
レジスタリクエストに対する非2XX応答は、以前にUAに提供されていた既存のGruusに影響を与えません。具体的には、以前に成功したレジスタリクエストがUAにGruuを提供した場合、その後の失敗したリクエストはGruuを削除、削除、または無効にしません。
The user and host parts of the GRUU learned by the UA in the REGISTER response MUST be treated opaquely by the UA. That is, the UA MUST NOT modify them in any way. A UA MUST NOT modify or remove URI parameters it does not recognize. Furthermore, the UA MUST NOT add, remove, or modify URI parameters relevant for receipt and processing of request at the proxy, including the transport, lr, maddr, ttl, user, and comp (see RFC 3486 [25]) URI parameters. The other URI parameter defined in RFC 3261 [1], method, would not typically be present in a GRUU delivered from a registrar, and a UA MAY add a method URI parameter to the GRUU before handing it out to another entity. Similarly, the URI parameters defined in RFC 4240 [26] and RFC 4458 [27] are meant for consumption by the UA. These would not be included in the GRUU returned by a registrar and MAY be added by a UA wishing to provide services associated with those URI parameters.
Registerの応答でUAによって学習したGruuのユーザーとホストの部分は、UAによって不透明に扱わなければなりません。つまり、UAはそれらを決して変更してはなりません。UAは、認識していないURIパラメーターを変更または削除してはなりません。さらに、UAは、トランスポート、LR、MADDR、TTL、ユーザー、コンプなど、プロキシでのリクエストの受領と処理に関連するURIパラメーターを追加、削除、または変更してはなりません（RFC 3486 [25]を参照）URIパラメーター。RFC 3261 [1]で定義されている他のURIパラメーター、方法は、通常、レジストラから配信されたGruuには存在せず、UAは別のエンティティに渡す前にGruuにMethod URIパラメーターを追加する場合があります。同様に、RFC 4240 [26]およびRFC 4458 [27]で定義されているURIパラメーターは、UAによる消費を目的としています。これらはレジストラによって返されたGruuには含まれておらず、URIパラメーターに関連するサービスを提供することを希望するUAによって追加される場合があります。
Note, however, that should another UA dereference the GRUU, the parameters will be lost at the proxy when the Request-URI is translated into the registered contact, unless some other means is provided for the attributes to be delivered to the UA. Mechanisms for such delivery are currently the subject of future standardization activity (see "Delivery of Request-URI Targets to User Agents" [29]).
ただし、別のua recreferenceがgruuを行使した場合、Request-uriが登録された連絡先に変換されると、プロキシでパラメーターが失われます。このような配信のメカニズムは現在、将来の標準化アクティビティの対象です（「ユーザーエージェントへのリクエスト-URIターゲットの配信」[29]を参照）。
Many user agents (such as gateways to the Public Switched Telephone Network (PSTN), conferencing servers, and media servers) do not perform registrations, and cannot obtain GRUUs through that mechanism. These types of user agents can be publicly reachable. This would mean that the policy of the domain is that requests can come from anywhere on the public Internet and be delivered to the user agent without requiring processing by intervening proxies within the domain. Furthermore, firewall and NAT policies administered by the domain would allow such requests into the network. When a user agent is certain that these conditions are met, a UA MAY construct a self-made GRUU. Of course, a user agent that does REGISTER, but for whom these conditions are met regardless, MAY also construct a self-made GRUU. However, usage of GRUUs obtained by the registrar is RECOMMENDED instead.
多くのユーザーエージェント（公共の切り替え電話ネットワーク（PSTN）へのゲートウェイ、会議サーバー、メディアサーバーなど）は登録を実行せず、そのメカニズムを介してGruusを取得できません。これらのタイプのユーザーエージェントは、公開可能になります。これは、ドメインのポリシーが、パブリックインターネット上のどこからでもリクエストが届き、ドメイン内のプロキシに介入することで処理を必要とせずにユーザーエージェントに配信できることを意味します。さらに、ドメインによって管理されるファイアウォールとNATポリシーは、そのような要求をネットワークに許可します。ユーザーエージェントがこれらの条件が満たされていることを確信している場合、UAは自作のグルーを構築する場合があります。もちろん、登録するが、これらの条件が満たされているユーザーエージェントは、自作のグルーを構築することもできます。ただし、代わりにレジストラが取得したGruusの使用をお勧めします。
A self-made GRUU is one whose domain part equals the IP address or hostname of the user agent. The user part of the SIP URI is chosen arbitrarily by the user agent. Like all other GRUUs, the URI MUST contain the "gr" URI parameter, with or without a value, indicating it is a GRUU.
セルフメイドのGruuは、ドメイン部分がユーザーエージェントのIPアドレスまたはホスト名に等しいものです。SIP URIのユーザー部分は、ユーザーエージェントによって任意に選択されます。他のすべてのGruusと同様に、URIには、値がある場合またはない場合の「Gr」URIパラメーターを含める必要があり、Gruuであることを示しています。
If a user agent does not register, but is not publicly reachable, it would need to obtain a GRUU through some other means. Typically, the UA would be configured with a GRUU, the GRUU would be configured into the proxy, and the proxy will be configured with a mapping from the GRUU to the IP address (or hostname) and port of the UA.
ユーザーエージェントが登録されていないが、公開されない場合は、他の手段を通じてGruuを取得する必要があります。通常、UAはGruuで構成され、Gruuはプロキシに構成され、プロキシはGruuからIPアドレス（またはホスト名）およびUAのポートへのマッピングで構成されます。
A UA SHOULD use a GRUU when populating the Contact header field of dialog-forming and target refresh requests and responses. In other words, a UA compliant to this specification SHOULD use one of its GRUUs as its remote target. This includes:
UAは、ダイアログ形成のコンタクトヘッダーフィールドとターゲットの更新リクエストと応答を埋めるときにGruuを使用する必要があります。言い換えれば、この仕様に準拠したUAでは、そのGruusの1つをリモートターゲットとして使用する必要があります。これも：
o the INVITE request
o 招待リクエスト
o a 2xx or 18x response to an INVITE which contains a To tag
o タグを含む招待への2xxまたは18xの応答
o the SUBSCRIBE request (see [5])
o 購読リクエスト（[5]を参照）
o a 2xx response to a SUBSCRIBE which contains a To tag
o タグを含む購読に対する2xx応答
o the NOTIFY request
o Notifyリクエスト
o the REFER request (see [6])
o 参照要求（[6]を参照）
o a 2xx response to NOTIFY
o 通知への2XX応答
o the UPDATE request
o 更新リクエスト
o a 2xx response to NOTIFY The only reason not to use a GRUU would be privacy considerations; see Section 10.3.
o Gruuを使用しない唯一の理由を通知する2xx応答は、プライバシーに関する考慮事項です。セクション10.3を参照してください。
When using a GRUU obtained through registrations, a UA MUST have an active registration prior to using a GRUU, and MUST use a GRUU learned through that registration. It MUST NOT reuse a GRUU learned through a previous registration that has lapsed (in other words, one obtained when registering a contact that has expired). The UA MAY use either the public or one of its temporary GRUUs provided by its registrar. A UA MUST NOT use a temporary GRUU learned in a REGISTER response whose Call-ID differs from the one in the most recent REGISTER request generated by the UA for the same AOR and instance ID (and, if RFC 5626 [14] is in use, reg-id). When a UA wishes to construct an anonymous request as described in RFC 3323 [15], it SHOULD use a temporary GRUU. See Section 10.3 for a more complete discussion on the level of privacy afforded by temporary GRUUs.
登録を通じて取得したGruuを使用する場合、UAはGruuを使用する前にアクティブな登録を行う必要があり、その登録を通じて学んだGruuを使用する必要があります。失効した以前の登録を通じて学んだグルーを再利用してはなりません（つまり、有効期限が切れた連絡先を登録するときに得られたものです）。UAは、レジストラが提供する一般の人々またはその一時的なグルーのいずれかを使用する場合があります。UAは、同じAORおよびインスタンスIDに対してUAによって生成された最新のレジスタリクエストのコールIDとは異なるレジスタ応答で学習した一時的なGruuを使用してはなりません（そして、RFC 5626 [14]が使用されている場合、reg-id）。RFC 3323 [15]に記載されているように、UAが匿名リクエストを作成したい場合、一時的なグルーを使用する必要があります。一時的なGruusが提供するプライバシーのレベルに関するより完全な議論については、セクション10.3を参照してください。
As per RFC 3261 [1], a UA SHOULD include a Supported header with the option tag "gruu" in requests and responses it generates.
RFC 3261 [1]によると、UAには、生成するリクエストと応答にオプションタグ「Gruu」を備えたサポートされたヘッダーを含める必要があります。
In some SIP networks, a user agent can have a multiplicity of AORs, either in different domains or within the same domain. In such cases, additional considerations apply.
一部のSIPネットワークでは、ユーザーエージェントは、異なるドメインまたは同じドメイン内のAORの多様性を持つことができます。そのような場合、追加の考慮事項が適用されます。
When a UA sends a request, the request will be sent 'using' one of its AORs. This AOR will typically show up in the From header field of the request, and credentials unique to that AOR will be used to authenticate the request. The GRUU placed into the Contact header field of such a request SHOULD be one that is associated with the AOR used to send the request. In cases where the UA uses a tel URI (as defined in [11]) to populate the From header field, the UA typically has a SIP AOR that is treated as an alias for the tel URI. The GRUU associated with that SIP AOR SHOULD be used in the Contact header field.
UAがリクエストを送信すると、リクエストはAORの1つを使用して「使用」されます。このAORは通常、リクエストのヘッダーフィールドに表示され、そのAORに固有の資格情報は、リクエストを認証するために使用されます。このようなリクエストのコンタクトヘッダーフィールドに配置されたGruuは、リクエストの送信に使用されるAORに関連するものでなければなりません。UAがTel URI（[11]で定義されているように）を使用してFrom Headerフィールドに入力する場合、UAには通常、Tel URIのエイリアスとして扱われるSIP AORがあります。そのSIP AORに関連付けられたGruuは、コンタクトヘッダーフィールドで使用する必要があります。
When a UA receives a request, the GRUU placed into the Contact header field of a 2xx response SHOULD be the one associated with the AOR or GRUU to which the request was most recently targeted. There are several ways to determine the AOR or GRUU to which a request was sent. For example, if a UA registered a different contact to each AOR (by using a different user part of the URI), the Request-URI (which contains that contact) will indicate the AOR.
UAがリクエストを受信すると、2XX応答のコンタクトヘッダーフィールドに配置されたGruuは、リクエストが最近ターゲットにされたAORまたはGruuに関連するものでなければなりません。リクエストが送信されたAORまたはGruuを決定する方法はいくつかあります。たとえば、UAが各AORに異なる連絡先を登録した場合（URIの異なるユーザー部分を使用して）、リクエスト-URI（その連絡先を含む）はAORを示します。
A GRUU is identified by the presence of the "gr" URI parameter, and this URI parameter might or might not have a value. A UA that wishes to send a request to a URI that contains a GRUU knows that the request will be delivered to a specific UA instance without further action on the part of the requestor.
Gruuは、「GR」URIパラメーターの存在によって識別され、このURIパラメーターには値がある場合とない場合があります。Gruuを含むURIにリクエストを送信したいUAは、要求者側のさらなるアクションなしでリクエストが特定のUAインスタンスに配信されることを知っています。
Some UAs implement non-standard URI-handling mechanisms that compensate for the fact that heretofore many contact URIs have not been globally routable. Since any URI containing the "gr" URI parameter is known to be globally routable, a UA SHOULD NOT apply such mechanisms when a contact URI contains the "gr" URI parameter.
一部のUAは、これまでに多くの接触URIがグローバルにルーティングできていないという事実を補う非標準のURIハンドリングメカニズムを実装しています。「GR」URIパラメーターを含むURIは、グローバルにルーティング可能であることが知られているため、接触URIに「GR」URIパラメーターが含まれている場合、UAはそのようなメカニズムを適用しないでください。
Because the instance ID is a callee capabilities parameter, a UA might be tempted to send a request to the AOR of a user, and include an Accept-Contact header field (defined in [12]) that indicates a preference for routing the request to a UA with a specific instance ID. Although this would appear to have the same effect as sending a request to the GRUU, it does not. The caller preferences expressed in the Accept-Contact header field are just preferences. Their efficacy depends on a UA constructing an Accept-Contact header field that interacts with domain-processing logic for an AOR, to cause a request to route to a particular instance. Given the variability in routing logic in a domain (for example, time-based routing to only selected contacts), this doesn't work for many domain-routing policies. However, this specification does not forbid a client from attempting such a request, as there can be cases where the desired operation truly is a preferential routing request.
インスタンスIDはCallee機能パラメーターであるため、UAはユーザーのAORにリクエストを送信し、リクエストをにルーティングすることの好みを示すAccept-Tontactヘッダーフィールド（[12]で定義）を含めることができます。特定のインスタンスIDを持つUA。これはGruuにリクエストを送信するのと同じ効果があるように思われますが、そうではありません。Accept-Contactヘッダーフィールドで表現された発信者の好みは、単なる設定です。それらの有効性は、特定のインスタンスへのルーティングを要求するために、AORのドメイン処理ロジックと相互作用するAcceptontactヘッダーフィールドを構築するUAに依存します。ドメイン内のルーティングロジックの変動性（たとえば、選択された連絡先のみへの時間ベースのルーティング）の変動を考えると、これは多くのドメインルーティングポリシーでは機能しません。ただし、この仕様は、目的の操作が本当に優先ルーティングリクエストである場合があるため、クライアントがそのような要求を試みることを禁止するものではありません。
When rendering a GRUU to a user through a user interface, it is RECOMMENDED that the "gr" URI parameter be removed. For public GRUUs, this will produce the AOR, as desired. For temporary GRUUs, the resulting URI will be seemingly random. Future work might provide improved mechanisms that would allow an automaton to know that a URI is anonymized, and therefore inappropriate to render.
ユーザーインターフェイスを介してGruuをユーザーにレンダリングする場合、「GR」URIパラメーターを削除することをお勧めします。パブリックグルーの場合、これは必要に応じてAORを生成します。一時的なグルーの場合、結果のURIは一見ランダムになります。将来の作業は、オートマトンがURIが匿名化されていることを知ることができ、したがってレンダリングするのに不適切であることを知ることができる改善されたメカニズムを提供するかもしれません。
A REGISTER request might contain a Require header field with the "gruu" option tag; this indicates that the registrar has to understand this extension in order to process the request. It does not require the registrar to create GRUUs, however.
レジスタリクエストには、「gruu」オプションタグを備えた要求ヘッダーフィールドが含まれる場合があります。これは、リクエストを処理するためにレジストラがこの拡張機能を理解する必要があることを示しています。ただし、レジストラにGruusを作成する必要はありません。
As the registrar is processing the contacts in the REGISTER request according to the procedures of step 7 in Section 10.3 of RFC 3261 [1], the registrar checks whether each Contact header field in the REGISTER message contains a "+sip.instance" header field parameter. If present with a non-zero expiration, the contact is processed further based on the rules in the remainder of this section. Otherwise, the contact is processed based on normal RFC 3261 [1] rules.
レジストラがRFC 3261 [1]のセクション10.3のステップ7の手順に従ってレジスタリクエストの連絡先を処理しているため、レジスタメッセージの各連絡先ヘッダーフィールドに「sip.instance」ヘッダーフィールドパラメーターが含まれているかどうかをレジストラがチェックします。。ゼロ以外の有効期限が存在する場合、このセクションの残りのルールに基づいて連絡先がさらに処理されます。それ以外の場合、連絡先は通常のRFC 3261 [1]ルールに基づいて処理されます。
Note that handling of a REGISTER request containing a Contact header field with value "*" and an expiration of zero still retains the meaning defined in RFC 3261 [1] -- all contacts, not just those with a specific instance ID, are deleted. As described in Section 5.4, this removes the binding of each contact to the AOR and the binding of each contact to its GRUUs.
値「*」とゼロの有効期限を持つ連絡先ヘッダーフィールドを含むレジスタリクエストの処理は、RFC 3261 [1]で定義されている意味を保持することに注意してください。特定のインスタンスIDを持つものだけでなく、すべての連絡先が削除されます。セクション5.4で説明されているように、これにより、各接触がAORへの結合とそのgruusへの結合の結合が削除されます。
If the contact URI is equivalent (based on URI equivalence in RFC 3261 [1]) to the AOR, the registrar MUST reject the request with a 403, since this would cause a routing loop. If the contact URI is a GRUU for the AOR in the To header field of the REGISTER request, the registrar MUST reject the request with a 403, for the same reason. If the contact is not a SIP URI, the REGISTER request MUST be rejected with a 403.
接触URIがAORに相当する（RFC 3261 [1]のURI等価に基づいて）同等である場合、レジストラはルーティングループを引き起こすため、403でリクエストを拒否する必要があります。連絡先URIがレジスタリクエストのヘッダーフィールドのAORのGruuである場合、レジストラは同じ理由で403でリクエストを拒否する必要があります。連絡先がSIP URIでない場合、レジスタリクエストは403で拒否する必要があります。
Next, the registrar checks if there is already a valid public GRUU for the AOR (present in the To header field of the REGISTER request) and the instance ID (present as the content of the "+sip.instance" Contact header field parameter). If there is no valid public GRUU, the registrar SHOULD construct a public GRUU at this time according to the procedures of Section 5.4. The public GRUU MUST be constructed by adding the "gr" URI parameter, with a value, to the AOR. If the contact contained a "pub-gruu" Contact header field parameter, the header field parameter MUST be ignored by the registrar. A UA cannot suggest or otherwise provide a public GRUU to the registrar.
次に、レジストラは、AOR（レジスタリクエストのヘッダーフィールドに存在する）とインスタンスID（「sip.instance」のコンテンツとして存在するヘッダーフィールドパラメーターのコンテンツとして存在する）に既に有効な公開gruuがあるかどうかを確認します。有効な公開Gruuがない場合、レジストラは、セクション5.4の手順に従って、現時点で公開Gruuを構築する必要があります。Public Gruuは、「GR」URIパラメーターを値でAORに追加することにより構築する必要があります。連絡先に「Pub-Gruu」連絡先ヘッダーフィールドパラメーターが含まれている場合、ヘッダーフィールドパラメーターはレジストラによって無視する必要があります。UAは、レジストラに公開Gruuを提案または提供することはできません。
Next, the registrar checks for any existing contacts registered to the same AOR, instance ID, and if the contact in the REGISTER request is registering a flow [14], reg-id. If there is at least one, the registrar finds the one that was most recently registered, and examines the Call-ID value associated with that registered contact. If it differs from the one in the REGISTER request, the registrar MUST invalidate all previously generated temporary GRUUs for the AOR and instance ID. A consequence of this invalidation is that requests addressed to those GRUUs will be rejected by the domain with a 404 from this point forward.
次に、レジストラは、同じAOR、インスタンスIDに登録された既存の連絡先をチェックし、レジスタリクエストの連絡先がフロー[14]、reg-idを登録している場合。少なくとも1つがある場合、レジストラは最近登録されたものを見つけ、その登録された連絡先に関連付けられたコールID値を調べます。レジスタリクエストのものとは異なる場合、レジストラは、AORおよびインスタンスIDに対して以前に生成されたすべての一時グルーを無効にする必要があります。この無効化の結果、これらのGruusに宛てられたリクエストは、この時点から404でドメインによって拒否されることです。
Next, the registrar SHOULD create a new temporary GRUU for the AOR and instance ID with the characteristics described in Section 5.4. The temporary GRUU construction algorithm MUST have the following two properties:
次に、レジストラは、セクション5.4で説明されている特性を備えたAORおよびインスタンスIDの新しい一時Gruuを作成する必要があります。一時的なGruu構造アルゴリズムには、次の2つのプロパティが必要です。
1. The likelihood that the temporary GRUU is equal to another GRUU that the registrar has created MUST be vanishingly small.
1. 一時的なグルーがレジストラが作成した別のグルーに等しい可能性は、消えてしまう必要があります。
2. Given a pair of GRUUs, it MUST be computationally infeasible to determine whether they were issued for the same AOR or instance ID or for different AORs and instance IDs.
2. Gruusのペアを考えると、同じAORまたはInstance IDまたは異なるAORおよびインスタンスIDに対して発行されたかどうかを判断することは、計算的に実行不可能でなければなりません。
If the contact contained a "temp-gruu" Contact header field parameter, the header field parameter MUST be ignored by the registrar. A UA cannot suggest or otherwise provide a temporary GRUU to the registrar.
連絡先に「temp-gruu」の連絡先ヘッダーフィールドパラメーターが含まれている場合、ヘッダーフィールドパラメーターはレジストラによって無視する必要があります。UAは、レジストラに一時的なグルーを提案したり、提供したりすることはできません。
When generating the 200 (OK) response to the REGISTER request, the procedures of step 8 of Section 10.3 of RFC 3261 [1] are followed. Furthermore, for each Contact header field value placed in the response, if the registrar has stored an instance ID associated with that contact, that instance ID is returned as a Contact header field parameter. If the REGISTER request contained a Supported header field that included the "gruu" option tag, and the registrar has at least one temporary GRUU assigned to the instance ID and AOR, the registrar MUST add a "temp-gruu" Contact header field parameter to that Contact header field. The value of the "temp-gruu" parameter is a quoted string, and MUST contain the most recently created temporary GRUU for that AOR and instance ID. In addition, if the registrar has a public GRUU assigned to the instance ID and AOR (and the client supports GRUUs), the registrar MUST add a "pub-gruu" Contact header field parameter to that Contact header field. The value of the "pub-gruu" Contact header field parameter is the public GRUU.
レジスタリクエストに対する200（OK）応答を生成する場合、RFC 3261 [1]のセクション10.3のステップ8の手順が続きます。さらに、応答に配置された連絡先ヘッダーフィールド値ごとに、レジストラがその連絡先に関連付けられたインスタンスIDを保存した場合、そのインスタンスIDは連絡先ヘッダーフィールドパラメーターとして返されます。レジスタリクエストに「Gruu」オプションタグを含むサポートされているヘッダーフィールドが含まれており、レジストラにはインスタンスIDとAORに割り当てられた一時的なGruuが少なくとも1つある場合、レジストラは「Temp-Gruu」に連絡しているヘッダーフィールドパラメーターを追加する必要があります。その連絡先ヘッダーフィールド。「temp-gruu」パラメーターの値は引用された文字列であり、そのaorおよびインスタンスIDのために最近作成された一時的なGruuを含める必要があります。さらに、レジストラがインスタンスIDとAORに割り当てられたパブリックGruuを持っている場合（およびクライアントはGruusをサポートしています）、レジストラはそのコンタクトヘッダーフィールドに「Pub-Gruu」コンタクトヘッダーフィールドパラメーターを追加する必要があります。「Pub-Gruu」連絡先ヘッダーフィールドパラメーターの値は、Public Gruuです。
The registrar SHOULD NOT include the "gruu" option tag in the Require or Supported header field of the response.
レジストラは、応答の要求またはサポートされているヘッダーフィールドに「Gruu」オプションタグを含めるべきではありません。
When a registered contact expires (either due to timeout or explicit de-registration), its binding to the AOR is removed as usual. In addition, its binding to its GRUUs are removed at the same time, as a consequence of the relationships described in Section 5.4 If, as a consequence of the expiration of the contact, a particular GRUU no longer has any registered contacts bound to it, and the GRUU is a temporary GRUU, the GRUU MUST be invalidated. This means that all of the accumulated temporary GRUUs get invalidated once the last contact for a given instance ID expires.
登録された連絡先が（タイムアウトまたは明示的な登録による）有効期限が切れると、AORへの拘束が通常どおり削除されます。さらに、セクション5.4で説明されている関係の結果として、そのgruusへの拘束力は同時に削除されます。接触の有効期限の結果として、特定のグルーには登録された接点が拘束されなくなった場合、そして、グルーは一時的なグルーであり、グルーは無効にする必要があります。これは、特定のインスタンスIDの最後の接点が期限切れになると、蓄積された一時的なグルーがすべて無効になることを意味します。
If, however, the GRUU was a public GRUU, the registrar SHOULD continue to treat the GRUU as valid. Consequently, subsequent requests targeted to the GRUU, prior to re-registration of a contact to the GRUU, SHOULD return a 480 (Temporarily Unavailable) response. In addition, since the GRUU remains valid, the rules in Section 5.1 will cause it to be retained when a contact with that instance ID is once again registered to the AOR.
ただし、Gruuが公共のGruuであった場合、レジストラはGruuを有効なものとして扱い続ける必要があります。その結果、Gruuへの接触の再登録の前に、Gruuを対象とした後続の要求は、480（一時的に利用できない）応答を返す必要があります。さらに、Gruuは有効であるため、セクション5.1のルールは、そのインスタンスIDとの接触がAORに再び登録されたときに保持されます。
These rules give a public GRUU a semi-permanent property. The intent is that the registrar make every attempt to retain validity of the GRUU for as long as the AOR itself is known within the domain. The requirements for doing so are at SHOULD strength and not MUST strength because of the difficulty in meeting a MUST strength requirement; registrar failures could cause the set of valid GRUUs to be lost, and this specification requires the UA to be robust against such cases. That said, it is possible for a public GRUU to be constructed such that a registrar does not need to retain any additional state for it, yet the GRUU still meets the requirements described here.
これらのルールは、公共のグルーに半多数の財産を与えます。意図は、レジストラがAOR自体がドメイン内で知られている限り、Gruuの妥当性を保持しようとするあらゆる試みを行うことです。そうするための要件は、必須の強度要件を満たすのが難しいため、強度であり、強さは必要ありません。レジストラの障害により、有効なGruusのセットが失われる可能性があり、この仕様ではUAがそのような場合に対して堅牢であることが必要です。とはいえ、レジストラが追加の状態を保持する必要がないように、公共のグルーを建設する可能性がありますが、Gruuはまだここで説明する要件を満たしています。
This section defines additional behaviors associated with the construction and maintenance of a GRUU that are specific to a registrar. These rules do not apply to self-made GRUUs or GRUUs not obtained through registrations.
このセクションでは、レジストラに固有のグルーの建設とメンテナンスに関連する追加の動作を定義します。これらのルールは、登録を通じて取得されていない自作のグルーまたはグルーには適用されません。
When a registrar creates a GRUU, it is required to maintain certain information associated with the GRUU, regardless of whether it is a public or temporary GRUU. Every GRUU is associated with a single AOR and a single instance ID. A registrar MUST be able to determine the instance ID and AOR when presented with a GRUU. In addition, the GRUU, like an AOR, resolves to zero or more contacts. While the AOR resolves to all registered contacts for an AOR, a GRUU resolves only to those contacts whose instance ID matches the one associated with the GRUU. For this reason, a contact with an instance ID is always bound to both a GRUU and its AOR, never just an AOR or just a GRUU. This is shown pictorially in Figure 1. The figure shows three contacts registered to a single AOR. One of the contacts has an instance ID of 1, and the other two have an instance ID of 2. There are two GRUUs for this AOR. One is associated with instance ID 1, and the other with instance ID 2. The first GRUU resolves only to contacts whose instance ID is 1, and the second resolves only to contacts whose instance ID is 2. There will typically be multiple contacts for a given instance ID if a UA has crashed, rebooted, and re-registered with the same instance ID, or is using the mechanisms of RFC 5626 [14] to have multiple registrations for redundancy. If the contact for instance ID 1 expires, the AOR would resolve to two contacts, but the GRUU associated with instance ID 1 would resolve to zero.
レジストラがGruuを作成する場合、Gruuに関連する特定の情報を公開または一時的なGruuであるかどうかにかかわらず、特定の情報を維持する必要があります。すべてのGruuは、単一のAORと単一のインスタンスIDに関連付けられています。レジストラは、Gruuを提示したときにインスタンスIDとAORを決定できる必要があります。さらに、GruuはAORのように、ゼロ以上の連絡先に解決します。AORはAORの登録されたすべての連絡先に解決しますが、GruuはインスタンスIDがGruuに関連付けられたものと一致する連絡先のみを解決します。このため、インスタンスIDとの接触は、常にgruuとそのaorの両方に結合されます。これを図1に描写しています。図は、単一のAORに登録された3つの連絡先を示しています。連絡先の1つには1のインスタンスIDがあり、他の2つは2のインスタンスIDがあります。このAORには2つのグルーがあります。1つはインスタンスID 1に関連付けられ、もう1つはインスタンスID 2に関連付けられています。最初のgruuは、インスタンスIDが1である連絡先のみを解決し、2番目はインスタンスIDが2である連絡先のみを解決します。UAがクラッシュ、再起動、同じインスタンスIDで再登録された場合、インスタンスIDが与えられた場合、またはRFC 5626 [14]のメカニズムを使用して、冗長性のために複数の登録を持つことができます。たとえば、ID 1の連絡先が期限切れになった場合、AORは2つの連絡先に解決しますが、インスタンスID 1に関連付けられたGruuはゼロに解決します。
+----------+ +----------+ +----------+
| GRUU | | | | GRUU |
| | | AOR | | |
|Instance:1| | | |Instance:2|
+----------+ +----------+ +----------+
| / | \ / |
| / | \ / |
| / | \ / |
| / | \ / |
| / | \ / |
| / | \ / |
| / | X |
| / | / \ |
| / | / \ |
| / | / \ |
V V V V V V
+----------+ +----------+ +----------+
| Contact | | Contact | | Contact |
| | | | | |
|Instance:1| |Instance:2| |Instance:2|
+----------+ +----------+ +----------+
Figure 1
図1
There can be multiple GRUUs with the same instance ID and AOR. Indeed, this specification requires registrars to maintain many -- one that is public, and several that are temporary. However, if two GRUUs are associated with different AORs or different instance IDs or both, the GRUUs MUST be different based on URI equality comparison. A GRUU in a domain MUST NOT be equivalent, based on URI comparison, to any AOR in a domain except for the one associated with the GRUU.
同じインスタンスIDとAORを持つ複数のグルーがあります。実際、この仕様では、レジストラが多くを維持する必要があります。これは、公開されているものと一時的なものです。ただし、2つのGruusが異なるAORまたは異なるインスタンスIDまたはその両方に関連付けられている場合、GruusはURI平等比較に基づいて異なる必要があります。ドメイン内のgruuは、Gruuに関連付けられたものを除くドメイン内の任意のAORと、URIの比較に基づいて同等であってはなりません。
A public GRUU will always be equivalent to the AOR based on URI equality rules. The reason is that the rules in RFC 3261 [1] cause URI parameters that are in one URI, but not in the other, to be ignored for equality purposes. Since a public GRUU differs from an AOR only by the presence of the "gr" URI parameter, the two URIs are equivalent based on those rules.
パブリックグルーは、URI平等規則に基づいて常にAORに相当します。その理由は、RFC 3261 [1]のルールは、1つのURIにあるが、他方にはないURIパラメーターを、平等目的で無視されるためです。パブリックグルーは「GR」URIパラメーターの存在によってのみAORとは異なるため、2つのURIはこれらのルールに基づいて同等です。
Once a temporary GRUU is constructed, it MUST be considered valid by the registrar until invalidated based on the rules described previously. Once a public GRUU is constructed, it MUST be considered valid for the duration that the AOR itself is valid. Once an AOR is no longer valid within a domain, all of its GRUUs MUST be considered invalid as well.
一時的なGruuが構築されると、前述のルールに基づいて無効になるまで、レジストラによって有効と見なされる必要があります。パブリックグルーが構築されると、AOR自体が有効である期間、有効と見なされる必要があります。AORがドメイン内で有効になったら、そのすべてのグルーも無効と見なされる必要があります。
This specification does not mandate a particular mechanism for construction of the GRUU. Example algorithms for public and temporary GRUUs that work well are given in Appendix A. However, in addition to the properties described in Section 3.1, a GRUU constructed by a registrar MUST exhibit the following properties:
この仕様は、グルーの構築のための特定のメカニズムを義務付けるものではありません。適切に機能する公共および一時的なグルーの例については、付録Aに記載されています。ただし、セクション3.1で説明されているプロパティに加えて、レジストラによって構築されたGruuは次のプロパティを表示する必要があります。
o The domain part of the URI is an IP address present on the public Internet, or, if it is a hostname, the resolution procedures of RFC 3263 [2], once applied, result in an IP address on the public Internet.
o URIのドメイン部分は、パブリックインターネットに存在するIPアドレスです。または、ホスト名の場合、RFC 3263 [2]の解決手順が適用されると、パブリックインターネット上のIPアドレスになります。
o When a request is sent to the GRUU, it routes to a proxy that can access the registration data generated by the registrar. Such a proxy is called an authoritative proxy, defined in RFC 5626 [14].
o リクエストがGruuに送信されると、レジストラが生成した登録データにアクセスできるプロキシにルーティングします。このようなプロキシは、RFC 5626 [14]で定義されている権威あるプロキシと呼ばれます。
RFC 3680 [24] defines an event package that allows a client to learn about registration events at the registrar. This package allows registrars to alter registrations forcefully (for example, shortening them to force a re-registration). If a registrar is supporting RFC 3680 [24] and GRUU, it MUST also support RFC 5628 [28].
RFC 3680 [24]は、クライアントがレジストラでの登録イベントについて学習できるイベントパッケージを定義しています。このパッケージにより、レジストラは登録を強制的に変更できます（たとえば、それらを短くして再登録を強制することができます）。レジストラがRFC 3680 [24]とGruuをサポートしている場合、RFC 5628 [28]もサポートする必要があります。
Proxy behavior is fully defined in Section 16 of RFC 3261 [1]. GRUU processing impacts that processing in two places -- request targeting at the authoritative proxy and record-routing.
プロキシの動作は、RFC 3261 [1]のセクション16で完全に定義されています。Gruu処理は、2つの場所での処理に影響を与えます - 権威あるプロキシでのターゲティングとレコードルーティングをリクエストします。
When a proxy receives a request, owns the domain in the Request-URI, and is supposed to access a location service in order to compute request targets (as specified in Section 16.5 of RFC 3261 [1]), the proxy examines the Request-URI. If it contains the "gr" URI parameter but is not equivalent, based on URI comparison, to a currently valid GRUU within the domain, it SHOULD be rejected with a 404 (Not Found) response; this is the same behavior a proxy would exhibit for any other URI within the domain that is not valid.
プロキシがリクエストを受信し、リクエスト-URIのドメインを所有し、リクエストターゲット（RFC 3261 [1]のセクション16.5で指定されているように）を計算するためにロケーションサービスにアクセスすることになっている場合、プロキシはリクエストを調べます - uri。「GR」URIパラメーターが含まれているが、URIの比較に基づいて、ドメイン内の現在有効なGRUUと同等ではない場合、404（見つからない）応答で拒否する必要があります。これは、プロキシが有効でないドメイン内の他のURIに対して示す同じ動作です。
If the Request-URI contains the "gr" URI parameter and is equivalent, based on URI comparison, to a GRUU which is currently valid within the domain, processing proceeds as it would for any other URI present in the location service, as defined in Section 16.5 of RFC 3261 [1], except that the "gr" URI parameter is not removed as part of the canonicalization process. This is the case for both out-of-dialog requests targeted to the GRUU, and mid-dialog requests targeted to the GRUU (in which case the incoming request would have a Route header field value containing the URI that the proxy used for record-routing.).
リクエスト-URIに「GR」URIパラメーターが含まれており、URIの比較に基づいてドメイン内で現在有効なGRUUと同等である場合、で定義されているように、ロケーションサービスに存在する他のURIの処理が進行します。RFC 3261 [1]のセクション16.5 [1]。ただし、「GR」URIパラメーターが標準化プロセスの一部として削除されないことを除きます。これは、Gruuを対象としたダイアログ外のリクエストと、Gruuを対象としたMid-Dialogリクエストの両方の場合です（この場合、受信リクエストには、記録に使用されるURIを含むルートヘッダーフィールド値があります。ルーティング。）。
Note that the "gr" URI parameter is retained just for the purposes of finding the GRUU in the location service; if a match is found, the Request-URI will be rewritten with the registered contacts, replacing the GRUU and its "gr" URI parameter. The "gr" URI parameter is not carried forward into the rewritten Request-URI.
「GR」URIパラメーターは、ロケーションサービスでGRUUを見つける目的のためだけに保持されることに注意してください。一致が見つかった場合、Request-URIは登録された連絡先と書き直され、Gruuとその「GR」URIパラメーターを置き換えます。「GR」URIパラメーターは、書き直されたリクエストURIに繰り越されません。
If there are no registered contacts bound to the GRUU, the server MUST return a 480 (Temporarily Unavailable) response. If there are more than one, there are two cases:
gruuにバインドされた登録された連絡先がない場合、サーバーは480（一時的に利用できない）応答を返す必要があります。複数の場合、2つのケースがあります。
1. The client is using RFC 5626 [14] and registering multiple contacts for redundancy. In that case, these contacts contain "reg-id" Contact header field parameters, and the rules described in Section 7 of RFC 5626 [14] for selecting a single registered contact apply.
1. クライアントはRFC 5626 [14]を使用しており、冗長性のために複数の連絡先を登録しています。その場合、これらの連絡先には「reg-id」連絡先ヘッダーフィールドパラメーターが含まれており、登録された単一の連絡先を選択するためのRFC 5626 [14]のセクション7で説明されているルールが含まれています。
2. The client was not using RFC 5626 [14], in which case there would only be multiple contacts with the same instance ID if the client had rebooted, restarted, and re-registered. In this case, these contacts would not contain the "reg-id" Contact header field parameter. The proxy MUST select the most recently refreshed contact. As with RFC 5626, if a request to this target fails with a 408 (Request Timeout) or 430 (Flow Failed) response, the proxy SHOULD retry with the next most recently refreshed contact. Furthermore, if the request fails with any other response, the proxy MUST NOT retry on any other contacts for this instance.
2. クライアントはRFC 5626 [14]を使用していませんでした。その場合、クライアントが再起動、再起動、再登録された場合、同じインスタンスIDに複数の連絡先のみがあります。この場合、これらの連絡先には「reg-id」コンタクトヘッダーフィールドパラメーターは含まれていません。プロキシは、最近更新された連絡先を選択する必要があります。RFC 5626と同様に、このターゲットへのリクエストが408（リクエストタイムアウト）または430（フローの失敗）応答で失敗した場合、プロキシは次の最近更新された連絡先で再試行する必要があります。さらに、リクエストが他の応答で失敗した場合、このインスタンスのためにプロキシは他の連絡先を再試行してはなりません。
Any caller preferences in the request (as defined in RFC 3841 [12]) SHOULD be processed against the contacts bound to the GRUU.
リクエスト内の発信者の設定（RFC 3841 [12]で定義されている）は、Gruuにバインドされた連絡先に対して処理する必要があります。
In essence, to select a registered contact, the GRUU is processed just like it was the AOR, but with only a subset of the contacts bound to the AOR.
本質的に、登録された連絡先を選択するために、GruuはAORのように処理されますが、AORに結合した接点のサブセットのみがあります。
Special considerations apply to the processing of any Path headers stored in the registration (see RFC 3327 [3]). If the received request has Route header field values beyond the one pointing to the authoritative proxy itself (this will happen when the request is a mid-dialog request), the Path URI MUST be discarded. This is permitted by RFC 3327 [3] as a matter of local policy; usage of GRUUs will require this policy in order to avoid call spirals and likely call failures.
登録に保存されているパスヘッダーの処理には特別な考慮事項が適用されます（RFC 3327 [3]を参照）。受信した要求に、権威あるプロキシ自体を指しているルートヘッダーフィールド値がある場合（これは、リクエストがミッドダイアログリクエストである場合に発生します）、パスURIを破棄する必要があります。これは、ローカルポリシーの問題としてRFC 3327 [3]によって許可されています。Gruusの使用には、コールスパイラルを回避し、呼び出された障害を発生させるために、このポリシーが必要になります。
A proxy MAY apply other processing to the request, such as execution of called party features, as it might do for requests targeted to an AOR. For requests that are outside of a dialog, it is RECOMMENDED to apply screening types of functions, both automated (such as blacklist and whitelist screening) and interactive (such as interactive voice response (IVR) applications that confer with the user to determine whether to accept a call). In many cases, the new request is related to an existing dialog, and might be an attempt to join it (using the Join header field defined in RFC 3911 [21]) or replace it (using the Replaces header field defined in RFC 3891 [22]). When the new request is related to an existing dialog, the UA will typically make its own authorization decisions; bypassing screening services at the authoritative proxy might make sense, but needs to be carefully considered by network designers, as the ability to do so depends on the specific type of screening service.
プロキシは、AORを対象としたリクエストに対して行う可能性があるように、呼び出した当事者機能の実行など、他の処理を要求に適用する場合があります。ダイアログ外のリクエストの場合、自動化された（ブラックリストやホワイトリストのスクリーニングなど）とインタラクティブ（インタラクティブな音声応答（IVR）アプリケーションなど、ユーザーに付与して、電話を受け入れます）。多くの場合、新しいリクエストは既存のダイアログに関連しており、参加する試みである可能性があります（RFC 3911 [21]で定義されたJoin Headerフィールドを使用）または置換（RFC 3891で定義された交換ヘッダーフィールド[22]）。新しいリクエストが既存のダイアログに関連している場合、UAは通常、独自の許可決定を下します。権威あるプロキシでスクリーニングサービスをバイパスすることは理にかなっているかもしれませんが、ネットワーク設計者は慎重に検討する必要があります。これは、特定のタイプのスクリーニングサービスに依存するためです。
However, forwarding services, such as call forwarding, SHOULD NOT be provided for requests sent to a GRUU. The intent of the GRUU is to target a specific UA instance, and this is incompatible with forwarding operations.
ただし、コール転送などの転送サービスは、Gruuに送信されたリクエストに対して提供されるべきではありません。Gruuの意図は、特定のUAインスタンスをターゲットにすることであり、これは転送操作と互換性がありません。
If the request is a mid-dialog request, a proxy SHOULD only apply services that are meaningful for mid-dialog requests, generally speaking. This excludes screening and forwarding functions.
リクエストがミッドダイアログリクエストである場合、プロキシは、一般的に言えば、ミッドダイアログリクエストに意味のあるサービスのみを適用する必要があります。これは、スクリーニングおよび転送機能を除外します。
In addition, a request sent to a GRUU SHOULD NOT be redirected. In many instances, a GRUU is used by a UA in order to assist in the traversal of NATs and firewalls, and a redirection might prevent such a case from working.
さらに、グルーに送信されたリクエストをリダイレクトすべきではありません。多くの場合、NATとファイアウォールのトラバーサルを支援するためにGruuがUAによって使用され、リダイレクトによりそのようなケースが機能するのを妨げる可能性があります。
There are two distinct requirements for record-routing -- in the originating domain and in the terminating domain. These requirements avoid unnecessary, and possibly problematic, spirals of requests.
発信ドメインと終端ドメインには、レコードルーティングには2つの異なる要件があります。これらの要件は、要求の不必要な、そしておそらく問題のあるスパイラルを回避します。
If:
もしも：
o an originating authoritative proxy receives a dialog-forming request,
o 発生する権威あるプロキシは、ダイアログ形成リクエストを受信します。
o AND the Contact header field contains a GRUU in the domain of the proxy,
o また、コンタクトヘッダーフィールドには、プロキシのドメインにグルーが含まれています。
o AND that GRUU is a valid one in the domain of the proxy,
o そして、そのグルーはプロキシの領域で有効なものです。
o AND that GRUU is associated with the AOR matching the authenticated identity of the requestor (assuming such authentication has been performed),
o そして、そのgruuは、要求者の認証されたアイデンティティに一致するAORに関連付けられています（そのような認証が実行されていると仮定します）、
o AND the request contains Record-Route header fields,
o リクエストにはレコードルートヘッダーフィールドが含まれています。
then the authoritative proxy MUST record-route. If all of these conditions are true, except that the GRUU is associated with an AOR that did not match the authenticated identity of the requestor, it is RECOMMENDED that the proxy reject the request with a 403 (Forbidden) response.
その後、権威あるプロキシはレコードルートする必要があります。これらの条件のすべてが真である場合、Gruuが要求者の認証されたアイデンティティと一致しなかったAORに関連付けられていることを除いて、プロキシは403（禁止）応答でリクエストを拒否することをお勧めします。
If:
もしも：
o a terminating authoritative proxy receives a dialog-forming request,
o 終了権限のあるプロキシは、ダイアログ形成リクエストを受け取ります。
o AND the Request-URI contains a URI in the location service (either a GRUU or an AOR),
o リクエスト-URIには、ロケーションサービス（GruuまたはAORのいずれか）にURIが含まれています。
o AND the contact selected for sending the request has an instance ID and is bound to a GRUU,
o リクエストを送信するために選択された連絡先にはインスタンスIDがあり、グルーにバインドされています。
o AND the registration contain Path URI,
o 登録にはパスURIが含まれています。
then the authoritative proxy MUST record-route.
その後、権威あるプロキシはレコードルートする必要があります。
If a proxy is in either the originating or terminating domains but is not an authoritative proxy, the proxy MAY record-route.
プロキシが発信ドメインまたは終端ドメインのいずれかにあるが、権威あるプロキシではない場合、プロキシは記録的なルーティングを行う場合があります。
If a proxy in the terminating domain requires mid-dialog requests to pass through it for whatever reason (firewall traversal, accounting, etc.), the proxy MUST still record-route, and MUST NOT assume that a UA will utilize its GRUU in the Contact header field of its response (which would cause mid-dialog requests to pass through the proxy without record-routing).
終了ドメインのプロキシが、何らかの理由で（ファイアウォールトラバーサル、アカウンティングなど）、それを通過するためにミッドダイアログリクエストを必要とする場合、プロキシはまだ記録的なことをしなければならず、UAがGruuを利用していると想定してはなりません。その応答のヘッダーフィールドに連絡します（これにより、ミッドダイアログリクエストはレコードルーティングなしでプロキシを通過させます）。
Implementors should note that, if a UA uses a GRUU in its contact, and a proxy inserted itself into the Path header field of a registration, that proxy will be receiving mid-dialog requests regardless of whether it record-routes or not. The only distinction is what URI the proxy will see in the topmost Route header field of mid-dialog requests. If the proxy record-routes, it will see that URI. If it does not, it will see the Path URI it inserted.
実装者は、UAがその連絡先でGruuを使用し、プロキシが登録のパスヘッダーフィールドに挿入された場合、そのプロキシは、記録的なルーティングかどうかに関係なく、Mid-Dialogリクエストを受信することに注意する必要があります。唯一の違いは、URIがミッドダイアログリクエストの最上部のルートヘッダーフィールドに表示されるものです。プロキシレコードルートの場合、そのURIがわかります。そうでない場合、挿入されたパスURIが表示されます。
This specification defines two new Contact header field parameters ("temp-gruu" and "pub-gruu") by extending the grammar for "contact-params" as defined in RFC 3261 [1]. It also defines a new SIP URI parameter ("gr") by extending the grammar for "uri-parameter" as defined in RFC 3261 [1]. The ABNF [13] is as follows:
この仕様では、RFC 3261 [1]で定義されている「コンタクトパラム」の文法を拡張することにより、2つの新しいコンタクトヘッダーフィールドパラメーター（「Temp-Gruu」と「Pub-Gruu」）を定義します。また、RFC 3261 [1]で定義されている「URI-Parameter」の文法を拡張することにより、新しいSIP URIパラメーター（「GR」）を定義します。ABNF [13]は次のとおりです。
contact-params =/ temp-gruu / pub-gruu temp-gruu = "temp-gruu" EQUAL quoted-string pub-gruu = "pub-gruu" EQUAL quoted-string
contact-params = / temp-gruu / pub-gruu temp-gruu = "temp-gruu"等しい引用されたstring pub-gruu = "pub-gruu" equied quoted-string
uri-parameter =/ gr-param
gr-param = "gr" ["=" pvalue] ; defined in RFC 3261
The quoted strings for temp-gruu and pub-gruu MUST contain a SIP URI. However, they are encoded like all other quoted strings and can therefore contain quoted-pair escapes when represented this way.
Temp-GruuとPub-Gruuの引用された文字列には、SIP URIが含まれている必要があります。ただし、他のすべての引用された文字列のようにエンコードされているため、このように表現された場合、引用されたペアエスケープを含めることができます。
This specification was created in order to meet the following requirements:
この仕様は、次の要件を満たすために作成されました。
REQ 1: When a UA invokes a GRUU, it must cause the request to be routed to the specific UA instance to which the GRUU refers.
Req 1：UAがGruuを呼び出すとき、Gruuが参照する特定のUAインスタンスにリクエストをルーティングする必要があります。
REQ 2: It must be possible for a GRUU to be invoked from anywhere on the Internet, and still cause the request to be routed appropriately. That is, a GRUU must not be restricted to use within a specific addressing realm.
Req 2：インターネット上のどこからでもGruuを呼び出すことができ、それでもリクエストを適切にルーティングすることができなければなりません。つまり、Gruuは特定のアドレス指定領域内での使用に制限されてはなりません。
REQ 3: It must be possible for a GRUU to be constructed without requiring the network to store additional state.
Req 3：ネットワークに追加の状態を保存する必要なく、Gruuを構築できる必要があります。
REQ 4: It must be possible for a UA to obtain a multiplicity of GRUUs that each route to that UA instance. For example, this is needed to support ad hoc conferencing where a UA instance needs a different URI for each conference it is hosting. NOTE: This requirement is not met by this specification, and is being addressed in a separate specification (currently, "Delivery of Request-URI Targets to User Agents" [29]).
Req 4：UAがそのUAインスタンスへの各ルートを多数のGruusを取得することが可能である必要があります。たとえば、これは、UAインスタンスが開催されている各会議に異なるURIが必要なアドホック会議をサポートするために必要です。注：この要件はこの仕様では満たされず、別の仕様（現在、「ユーザーエージェントへのリクエスト-URIターゲットの配信」[29]）で対処されています。
REQ 5: When a UA receives a request sent to a GRUU, it must be possible for the UA to know the GRUU that was used to invoke the request. This is necessary as a consequence of REQ 4. NOTE: This requirement is not met by this specification, and is being addressed in a separate specification (currently, "Delivery of Request-URI Targets to User Agents" [29]).
Req 5：UAがGruuに送信されたリクエストを受信した場合、UAがリクエストを呼び出すために使用されたGruuを知ることができなければなりません。これは、Req 4の結果として必要です。注：この要件はこの仕様では満たされず、別の仕様（現在、「ユーザーエージェントへのリクエストURIターゲットの配信」[29]）で対処されています。
REQ 6: It must be possible for a UA to add opaque content to a GRUU. This content is not interpreted or altered by the network, and is used only by the UA instance to whom the GRUU refers. This provides a basic cookie type of functionality, allowing a UA to build a GRUU with the state embedded. NOTE: This requirement is not met by this specification, and is being addressed in a separate specification (currently, "Delivery of Request-URI Targets to User Agents" [29]).
Req 6：UAが不透明なコンテンツをグルーに追加することが可能である必要があります。このコンテンツは、ネットワークによって解釈または変更されるのではなく、Gruuが参照するUAインスタンスによってのみ使用されます。これにより、基本的なCookieタイプの機能が提供され、UAが埋め込まれた状態でGruuを構築できます。注：この要件はこの仕様では満たされず、別の仕様（現在、「ユーザーエージェントへのリクエスト-URIターゲットの配信」[29]）で対処されています。
REQ 7: It must be possible for a proxy to execute services and features on behalf of a UA instance represented by a GRUU. As an example, if a user has call-blocking features, a proxy might want to apply those call-blocking features to calls made to the GRUU, in addition to calls made to the user's AOR.
Req 7：Gruuが表すUAインスタンスに代わって、プロキシがサービスと機能を実行することが可能である必要があります。例として、ユーザーがコールブロッキング機能を持っている場合、プロキシは、ユーザーのAORに行われた呼び出しに加えて、これらのコールブロッキング機能をGruuにコールに適用することをお勧めします。
REQ 8: It must be possible for a UA in a dialog to inform its peer of its GRUU, and for the peer to know that the URI represents a GRUU. This is needed for the conferencing and dialog reuse applications of GRUUs, where the URIs are transferred within a dialog.
Req 8：ダイアログ内のUAが仲間にGruuを通知することが可能である必要があります。これは、URIがダイアログ内で転送されるGruusの会議とダイアログの再利用アプリケーションに必要です。
REQ 9: When transferring a GRUU per REQ 8, it must be possible for the UA receiving the GRUU to be assured of its integrity and authenticity.
Req 9：Req 8ごとにGruuを転送する場合、UAがGruuを受け取っていることは、その完全性と信ity性を保証することが可能である必要があります。
REQ 10: It must be possible for a server that is authoritative for a domain to construct a GRUU that routes to a UA instance bound to an AOR in that domain. In other words, the proxy can construct a GRUU, too. This is needed for the presence application.
Req 10：ドメインが権威あるサーバーが、そのドメインのAORにバインドされたUAインスタンスにルーティングするGruuを構築することが可能である必要があります。言い換えれば、プロキシはグルーを構築することもできます。これは、プレゼンスアプリケーションに必要です。
The following call flow, shown in Figure 2, shows a basic registration and call setup, followed by a subscription directed to the GRUU. It then shows a failure of the callee, followed by a re-registration. The conventions of RFC 4475 [17] are used to describe the representation of long message lines.
図2に示す次のコールフローは、基本的な登録とコールのセットアップを示し、その後にGruuに向けられたサブスクリプションが続きます。次に、Calleeの障害を示し、その後に再登録が続きます。RFC 4475 [17]の規則は、長いメッセージ行の表現を説明するために使用されます。
Caller Proxy Callee
| |(1) REGISTER |
| |<--------------------|
| |(2) 200 OK |
| |-------------------->|
|(3) INVITE | |
|-------------------->| |
| |(4) INVITE |
| |-------------------->|
| |(5) 200 OK |
| |<--------------------|
|(6) 200 OK | |
|<--------------------| |
|(7) ACK | |
|-------------------->| |
| |(8) ACK |
| |-------------------->|
|(9) SUBSCRIBE | |
|-------------------->| |
| |(10) SUBSCRIBE |
| |-------------------->|
| |(11) 200 OK |
| |<--------------------|
|(12) 200 OK | |
|<--------------------| |
| |(13) NOTIFY |
| |<--------------------|
|(14) NOTIFY | |
|<--------------------| |
|(15) 200 OK | |
|-------------------->| |
| |(16) 200 OK |
| |-------------------->|
| | |Crashes,
| |(17) REGISTER | Reboots
| |<--------------------|
| |(18) 200 OK |
| |-------------------->|
Figure 2
図2
The callee supports the GRUU extension. As such, its REGISTER (1) looks like:
CalleeはGruu拡張機能をサポートしています。そのため、登録（1）は次のように見えます。
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Callee <sip:callee@example.com>;tag=a73kszlfl
Supported: gruu
To: Callee <sip:callee@example.com>
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
CSeq: 1 REGISTER
Contact: <sip:callee@192.0.2.1>
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
Content-Length: 0
The registrar assigns a temporary and a public GRUU. The REGISTER response (message 2) would look like:
レジストラは、一時的なグルーとパブリックグルーを割り当てます。登録応答（メッセージ2）は次のようになります。
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
From: Callee <sip:callee@example.com>;tag=a73kszlfl
To: Callee <sip:callee@example.com> ;tag=b88sn
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
CSeq: 1 REGISTER
<allOneLine>
Contact: <sip:callee@192.0.2.1>
;pub-gruu="sip:callee@example.com
;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
;temp-gruu="sip:tgruu.7hs==
jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr"
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;expires=3600
</allOneLine>
Content-Length: 0
The Contact header field in the REGISTER response contains the "pub-gruu" Contact header field parameter with the public GRUU sip:callee@ example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6, and the "temp-gruu" header field parameter with the temporary GRUU sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr. Both are valid GRUUs for the AOR and instance ID, and both translate to the contact sip:callee@192.0.2.1.
レジスタ応答のコンタクトヘッダーフィールドには、「Pub-Gruu」コンタクトヘッダーフィールドパラメーターが含まれています。Temp-Gruu "Headerフィールドパラメーター一時Gruu SIP：tgruu.7HS==Jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com; gr。どちらもAORおよびインスタンスIDの有効なGruusであり、どちらも連絡先SIP：callee@192.0.2.1に変換されます。
The INVITE from the caller (message 3) is a normal SIP INVITE. However, the 200 OK generated by the callee (message 5) now contains a GRUU as the remote target. The UA has chosen to use its public GRUU.
発信者からの招待（メッセージ3）は、通常のSIPの招待状です。ただし、Callee（メッセージ5）によって生成された200 OKには、リモートターゲットとしてGruuが含まれています。UAは、公共のグルーを使用することを選択しました。
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKnaa8
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK99a
From: Caller <sip:caller@example.com>;tag=n88ah
To: Callee <sip:callee@example.com> ;tag=a0z8
Call-ID: 1j9FpLxk3uxtma7@host.example.com
CSeq: 1 INVITE
Supported: gruu
Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, SUBSCRIBE
<allOneLine>
Contact:
<sip:callee@example.com
;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>
</allOneLine>
Content-Length: --
Content-Type: application/sdp
[SDP Not shown]
[SDPが表示されていない]
At some point later in the call, the caller decides to subscribe to the dialog event package (defined in [16]) at that specific UA. To do that, it generates a SUBSCRIBE request (message 9), but directs it towards the remote target, which is a GRUU:
コールの後半のある時点で、発信者は、その特定のUAでダイアログイベントパッケージ（[16]で定義されている）を購読することを決定します。そのためには、購読要求（メッセージ9）を生成しますが、それをリモートターゲットに指示します。これはGruuです。
<allOneLine>
SUBSCRIBE sip:callee@example.com;gr=urn:uuid:f8
1d4fae-7dec-11d0-a765-00a0c91e6bf6
SIP/2.0
</allOneLine>
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8
From: Caller <sip:caller@example.com>;tag=kkaz-
<allOneLine>
To: <sip:callee@example.com;gr=urn:uuid:f8
1d4fae-7dec-11d0-a765-00a0c91e6bf6>
</allOneLine>
Call-ID: faif9a@host.example.com
CSeq: 2 SUBSCRIBE
Supported: gruu
Event: dialog
Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, NOTIFY
Contact: <sip:caller@example.com;gr=hdg7777ad7aflzig8sf7>
Content-Length: 0
In this example, the caller itself supports the GRUU extension and is using its own GRUU to populate its remote target.
この例では、発信者自体がGruu拡張機能をサポートしており、独自のGruuを使用してリモートターゲットを設定しています。
This request is routed to the proxy, which proceeds to perform a location lookup on the Request-URI. It is translated into the contact for that instance, and then proxied to that contact.
このリクエストはプロキシにルーティングされ、リクエスト-URIでロケーションルックアップを実行するようになります。そのインスタンスの接触に翻訳され、その接触に賛成します。
SUBSCRIBE sip:callee@192.0.2.1 SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK9555
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8
From: Caller <sip:caller@example.com>;tag=kkaz-
<allOneLine>
To: <sip:callee@example.com;gr=urn:uuid:f8
1d4fae-7dec-11d0-a765-00a0c91e6bf6>
</allOneLine>
Call-ID: faif9a@host.example.com
CSeq: 2 SUBSCRIBE
Supported: gruu
Event: dialog
Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, NOTIFY
Contact: <sip:caller@example.com;gr=hdg7777ad7aflzig8sf7>
Content-Length: 0
The SUBSCRIBE generates a 200 response (message 11), which is followed by a NOTIFY (message 13 and 14) and its response (message 15 and 16). At some point after message 16 is received, the callee's machine crashes and recovers. It obtains a new IP address, 192.0.2.2. Unaware that it had previously had an active registration, it creates a new one (message 17 below). Notice how the instance ID remains the same, as it persists across reboot cycles:
購読は200の応答（メッセージ11）を生成し、その後に通知（メッセージ13および14）とその応答（メッセージ15および16）が続きます。メッセージ16が受信された後のある時点で、Calleeのマシンがクラッシュして回復します。新しいIPアドレス、192.0.2.2を取得します。以前にアクティブな登録があったことに気づかず、新しいものを作成します（以下のメッセージ17）。インスタンスIDが再起動サイクル全体で持続しているため、どのように同じままであるかに注意してください。
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbba
Max-Forwards: 70
From: Callee <sip:callee@example.com>;tag=ha8d777f0
Supported: gruu
To: Callee <sip:callee@example.com>
Call-ID: hf8asxzff8s7f@192.0.2.2
CSeq: 1 REGISTER
<allOneLine>
Contact: <sip:callee@192.0.2.2>
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
</allOneLine>
Content-Length: 0
The registrar notices that a different contact, sip:callee@192.0.2.1, is already associated with the same instance ID. It registers the new one too and returns both in the REGISTER response. Both have the same public GRUUs, but the registrar has generated a second temporary GRUU for this AOR and instance ID combination. Both contacts are included in the REGISTER response, and the temporary GRUU for each is the same -- the most recently created one for the instance ID and AOR. The registrar then generates the following response:
レジストラは、別の連絡先、sip：callee@192.0.2.1がすでに同じインスタンスIDに関連付けられていることに気付きます。新しいものも登録し、レジスタ応答の両方を返します。どちらも同じパブリックグルーを持っていますが、レジストラはこのAORとインスタンスIDの組み合わせに2番目の一時的なグルーを生成しました。どちらの連絡先もレジスタ応答に含まれており、それぞれの一時的なグルーは同じです。最近作成されたインスタンスIDとAOR用に作成されたものです。次に、レジストラが次の回答を生成します。
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbba
From: Callee <sip:callee@example.com>;tag=ha8d777f0
To: Callee <sip:callee@example.com>;tag=99f8f7
Call-ID: hf8asxzff8s7f@192.0.2.2
CSeq: 1 REGISTER
<allOneLine>
Contact: <sip:callee@192.0.2.2>
;pub-gruu="sip:callee@example.com;gr=urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
;temp-gruu="sip:tgruu.7hatz6cn-098shfyq193=
ajfux8fyg7ajqqe7@example.com;gr"
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;expires=3600
</allOneLine>
<allOneLine>
Contact: <sip:callee@192.0.2.1>
;pub-gruu="sip:callee@example.com;gr=urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
;temp-gruu="sip:tgruu.7hatz6cn-098shfyq193=
ajfux8fyg7ajqqe7@example.com;gr"
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;expires=400
</allOneLine>
Content-Length: 0
There is no need for the UA to remove the stale registered contact; the request targeting rules in Section 6.1 will cause the request to be delivered to the most recent one.
UAが古くなった登録済みの連絡先を削除する必要はありません。セクション6.1のリクエストターゲティングルールにより、リクエストは最新のものに配信されます。
Attacks in SIP networks using GRUUs can be divided into outside attacks (where a third party is trying to attack the system) and inside attacks (where the attacker is a valid participant in the system but is malicious). In addition, there are privacy considerations with using GRUUs.
Gruusを使用したSIPネットワークの攻撃は、外部攻撃（サードパーティがシステムを攻撃しようとしている場合）および内部攻撃（攻撃者がシステムの有効な参加者であるが悪意があります）に分割できます。さらに、Gruusを使用することにはプライバシーに関する考慮事項があります。
It is important for a UA to be assured of the integrity of a GRUU given in a REGISTER response. If the GRUU is tampered with by an attacker, the result could be denial of service (DoS) to the UA. As a result, it is RECOMMENDED that a UA use the SIPS URI scheme in the Request-URI when registering. Proxies and registrars MUST support the SIPS URI and MUST support TLS. This does not represent a change from the requirements in RFC 3261 [1].
UAがレジスタ応答で与えられたグルーの完全性を保証することが重要です。Gruuが攻撃者によって改ざんされている場合、結果はUAのサービス拒否（DOS）になる可能性があります。その結果、登録時にUAがリクエスト-URIでSIPS URIスキームを使用することをお勧めします。プロキシとレジストラは、SIPS URIをサポートする必要があり、TLSをサポートする必要があります。これは、RFC 3261 [1]の要件からの変更を表すものではありません。
The example GRUU construction algorithm in Appendix A.1 makes no attempt to create a GRUU that hides the AOR and instance ID associated with the GRUU. In general, determination of the AOR associated with a GRUU is considered a good property, since it allows for easy tracking of the target of a particular call. Learning the instance ID provides little benefit to an attacker. To register or otherwise impact registrations for the user, an attacker would need to obtain the credentials for the user. Knowing the instance ID is insufficient.
付録A.1のGruu構造アルゴリズムの例は、Gruuに関連付けられたAORとインスタンスIDを隠すGruuを作成しようとはしません。一般に、Gruuに関連付けられたAORの決定は、特定の呼び出しのターゲットを簡単に追跡できるため、優れた特性と見なされます。インスタンスIDを学習すると、攻撃者にほとんど利点がありません。ユーザーの登録を登録または影響を与えるには、攻撃者がユーザーの資格情報を取得する必要があります。インスタンスIDを知ることは不十分です。
The example GRUU construction algorithm in Appendix A.1 makes no attempt to create a GRUU that prevents users from guessing a GRUU based on knowledge of the AOR and instance ID. A user that is able to do that will be able to direct a new request at a particular instance. However, this specification recommends that service treatment (in particular, screening features) be given to requests that are sent to a GRUU. That treatment will make sure that the GRUU does not provide a back door for attackers to contact a user that has tried to block the attacker.
付録A.1のGruu構造アルゴリズムの例は、AORおよびインスタンスIDの知識に基づいてユーザーがGruuを推測することを防ぐGruuを作成しようとはしません。それができるユーザーは、特定のインスタンスで新しいリクエストを指示することができます。ただし、この仕様では、サービス処理（特に、スクリーニング機能）をGruuに送信するリクエストに与えることを推奨しています。その治療は、Gruuが攻撃者が攻撃者をブロックしようとしたユーザーに連絡するための裏口を提供しないことを確認します。
As a consequence of this specification, a UA will begin using GRUUs in the dialog forming and target refresh requests and responses it emits. These GRUUs will be passed to another UA (called the correspondent), which then uses them in requests that they emit.
この仕様の結果として、UAはダイアログ形成でGruusの使用を開始し、ターゲットの更新リクエストと応答を発します。これらのGruusは別のUA（特派員と呼ばれる）に渡され、それはそれらが発するという要求でそれらを使用します。
If a malicious correspondent removes the "gr" URI parameter, the request will be routed to the authoritative proxy. If the GRUU had been temporary, removal of the "gr" URI parameter produces a URI that is not recognized as a GRUU and is not equal to any AOR. The request will be rejected. If the GRUU had been public, removing the "gr" URI parameter would have produced the AOR. Therefore, the request is treated like a call to the AOR. Since it is a desired goal to allow users to extract the AOR from the GRUU, this is not an attack, and the call will be handled normally.
悪意のある特派員が「GR」URIパラメーターを削除すると、リクエストは権威あるプロキシにルーティングされます。Gruuが一時的なものであった場合、「GR」URIパラメーターの除去は、Gruuとして認識されず、AORと等しくないURIを生成します。リクエストは拒否されます。Gruuが公開されていた場合、「GR」URIパラメーターを削除するとAORが生成されます。したがって、リクエストはAORへの呼び出しのように扱われます。ユーザーがGruuからAORを抽出できるようにすることが望ましい目標であるため、これは攻撃ではなく、コールは正常に処理されます。
A malicious user in the system might try to use a GRUU for launching a DoS attack against another SIP UA. To do that, it would wait for a call from that UA, and from it, observe their GRUU. Once the GRUU is obtained, the UA would launch a SIP request to an entity, such as a presence server, which will generate many requests back towards the UA. However, the attacker will use the target's GRUU in the Contact header field of that SUBSCRIBE request. This will cause the traffic to be directed towards the target instead. Since the GRUU is globally routable, such traffic is more likely to be delivered to the target than traffic sent to its IP address. This specification helps mitigate this attack by requiring proxies to validate that the GRUU in the Contact of a request matches the authenticated identity of the sender of the request. This check requires the use of an outbound proxy. SIP does not require outbound proxies, and this does leave a potential area of vulnerability. However, in practice, nearly all deployments of SIP utilize an outbound proxy, and therefore this vulnerability is not likely to be a concern.
システム内の悪意のあるユーザーは、別のSIP UAに対するDOS攻撃を開始するためにGruuを使用しようとする場合があります。それを行うために、それはそのuaからの電話を待つでしょう、そしてそれから、彼らのグルーを観察します。Gruuが取得されると、UAはプレゼンスサーバーなどのエンティティにSIPリクエストを起動し、UAに向けて多くのリクエストを生成します。ただし、攻撃者は、その購読要求のコンタクトヘッダーフィールドでターゲットのGruuを使用します。これにより、代わりにトラフィックがターゲットに向けられます。Gruuは世界的にルーティング可能であるため、そのようなトラフィックは、IPアドレスに送信されるトラフィックよりもターゲットに配信される可能性が高くなります。この仕様は、リクエストの連絡先のGruuがリクエストの送信者の認証されたIDと一致することをプロキシに検証することを要求することにより、この攻撃を軽減するのに役立ちます。このチェックには、アウトバウンドプロキシの使用が必要です。SIPはアウトバウンドプロキシを必要としません。これは脆弱性の潜在的な領域を残します。ただし、実際には、SIPのほぼすべての展開がアウトバウンドプロキシを利用しているため、この脆弱性は懸念事項ではありません。
RFC 3323 [15] defines mechanisms for privacy. It distinguishes between network-provided privacy and user-provided privacy. In the former, the user requests privacy services from the network by including a Privacy header field in the request. In the latter, the UA follows a basic set of guidelines for construction of its request, so a certain level of privacy is afforded.
RFC 3323 [15]は、プライバシーのメカニズムを定義しています。ネットワークが提供するプライバシーとユーザーが提供するプライバシーを区別します。前者では、ユーザーはリクエストにプライバシーヘッダーフィールドを含めることにより、ネットワークからプライバシーサービスを要求します。後者では、UAはその要求の構築に関する基本的な一連のガイドラインに従っているため、一定レベルのプライバシーが提供されます。
The guidelines in Section 4.1 of RFC 3323 [15] for user-provided privacy request that a UA construct its Contact header field with a URI that omits a user part, and utilizes the IP address or hostname of the UA. Such recommendations are in conflict with the rules defined in this specification, which require the usage of a GRUU in the Contact header field.
ユーザーが提供するプライバシー要求のRFC 3323 [15]のセクション4.1のガイドラインは、UAがユーザーパーツを省略し、UAのIPアドレスまたはホスト名を使用するURIでそのコンタクトヘッダーフィールドを構築することを要求します。このような推奨事項は、この仕様で定義されているルールと矛盾しており、コンタクトヘッダーフィールドでGruuを使用する必要があります。
However, the temporary GRUUs provided by the registrar can be used in place of the Contact URI format described in RFC 3323 [15]. A user agent would gather the temporary GRUU returned in each REGISTER response, and keep a small number of them cached. When it makes or receives a call, a temporary GRUU is used to populate the Contact header field.
ただし、レジストラが提供する一時的なグルーは、RFC 3323 [15]に記載されている接触URI形式の代わりに使用できます。ユーザーエージェントは、各レジスタの応答で返された一時的なGruuを収集し、それらの少数をキャッシュしたままにします。電話をかけたり受信したりすると、一時的なGruuが使用され、コンタクトヘッダーフィールドが入力されます。
A UA can either elect to use the same temporary GRUU in each call, or it can use a different temporary GRUU in each call. The choice depends on the level of privacy desired:
UAは、各コールで同じ一時的なGruuを使用することを選択するか、各呼び出しで異なる一時的なGruuを使用することができます。選択は、望ましいプライバシーのレベルに依存します。
o A UA utilizing the same temporary GRUU for each call will allow a correspondent, based solely on investigation of the Contact header field, to correlate calls as coming from the same UA. This is also true for the user-provided privacy procedures in RFC 3323 [15], since the IP address or hostname in the Contact URI provides a similar correlator.
o 各呼び出しに同じ一時的なGruuを使用するUAは、連絡先ヘッダーフィールドの調査のみに基づいて、同じUAからの呼び出しを相関させることを可能にします。これは、RFC 3323 [15]のユーザーが提供するプライバシー手順にも当てはまります。これは、ContactのIPアドレスまたはホスト名が同様の相関器を提供するためです。
o A UA utilizing a different temporary GRUU for each call will not allow a correspondent, based solely on investigation of the Contact header field, to correlate calls as coming from the same UA.
o 各呼び出しに異なる一時的なGruuを使用するUAは、コンタクトヘッダーフィールドの調査のみに基づいて、同じUAからの呼び出しを相関させることを許可しません。
o In both cases, absent network-provided privacy, IP address and port information in the Session Description Protocol (SDP) (defined in [10]) will allow a correspondent to correlate calls as coming from the same UA.
o どちらの場合も、セッション説明プロトコル（SDP）（[10]で定義されている）にネットワークが提供するプライバシーがない場合、IPアドレスとポート情報は、特派員が同じUAから来ると呼び出しを相関させることができます。
o In both cases, if a user makes a call, the correspondent will be able to call back by directing requests towards the GRUU in the Contact header field. Similarly, features such as transfer and digit collection by network application servers (see RFC 4730 [20]), which depend on a Contact with the GRUU property, will also be possible. These kinds of inbound requests will be possible until the registration for that UA lapses. A UA that wishes to invalidate its previous temporary GRUU in order to limit reachability MAY do so by generating a REGISTER refresh with a Call-ID that differs from ones used previously. A UA SHOULD NOT forcefully expire its registration and then re-register in order to invalidate a temporary GRUU; this results in a brief period of unreachability and will often produce excess load on the network. Refreshing with a new Call-ID is more efficient and is meant as the technique for coarse-grained control over the validity of temporary GRUUs. A UA wishing to not be disturbed by a specific call back will need to implement manual or automated call-handling procedures to reject it. This specification does not provide the UA the ability to manually invalidate individual temporary GRUUs. If a UA insists on not receiving any such inbound requests (including ones generated by network applications, such as those used for collecting digits), the UA can place a non-GRUU into the Contact header field. However, this is NOT RECOMMENDED. Usage of a GRUU coupled with automated call rejection features is far superior.
o どちらの場合も、ユーザーが電話をかけた場合、特派員はコンタクトヘッダーフィールドのGruuにリクエストを指示することでコールバックすることができます。同様に、Gruuプロパティとの接触に依存するネットワークアプリケーションサーバーによる転送や桁の収集などの機能も可能です。これらの種類のインバウンドリクエストは、そのUAが失効するまで可能になります。到達可能性を制限するために以前の一時的なグルーを無効にしたいUAは、以前に使用されたものとは異なるコールIDでレジスタリフレッシュを生成することにより、そうすることができます。UAは、登録を強制的に期限切れにしてから、一時的なグルーを無効にするために再登録するべきではありません。これにより、到達不能の短い期間が生じ、多くの場合、ネットワーク上に過剰な負荷が発生します。新しいCall-IDでリフレッシュすることはより効率的であり、一時的なグルーの妥当性を粗く粒度の制御の手法として意図しています。特定のコールバックに邪魔されないようにしたいUAは、それを拒否するために手動または自動化されたコール処理手順を実装する必要があります。この仕様は、個々の一時的なグルーを手動で無効にする能力をUAに提供するものではありません。UAがそのようなインバウンド要求（数字の収集に使用されるものなど、ネットワークアプリケーションによって生成されたものを含む）を受信しないことを主張する場合、UAは非gruuをコンタクトヘッダーフィールドに配置できます。ただし、これは推奨されません。自動化されたコール拒否機能と組み合わせたGruuの使用ははるかに優れています。
o As long as a temporary GRUU is used to populate the Contact header field, a correspondent will not be able to ascertain any information about the AOR or instance ID of the UA by inspection of the Contact header field. However, absent a network-provided privacy service, the IP address in the SDP can be used to determine information about the UA, such as its geographic location and ISP.
o 一時的なGruuがコンタクトヘッダーフィールドの登録に使用されている限り、特派員はコンタクトヘッダーフィールドの検査によりUAのAORまたはインスタンスIDに関する情報を確認することはできません。ただし、ネットワークが提供するプライバシーサービスがなければ、SDPのIPアドレスを使用して、その地理的位置やISPなどのUAに関する情報を決定できます。
o In all cases, regardless of whether the UA uses a temporary or public GRUU in the Contact, regardless of whether it utilizes GRUU at all, and regardless of whether it invokes a network-provided privacy service, a correspondent will be able to determine the SIP service provider of the UA.
o すべての場合において、UAがGruuを使用しているかどうかに関係なく、接触で一時的なGruuまたはPublic Gruuを使用するかどうか、およびネットワークが提供するプライバシーサービスを呼び出すかどうかに関係なく、特派員はSIPを決定することができますUAのサービスプロバイダー。
This specification defines two new Contact header field parameters, one SIP URI parameter, and a SIP option tag.
この仕様では、2つの新しいコンタクトヘッダーフィールドパラメーター、1つのSIP URIパラメーター、およびSIPオプションタグを定義します。
This specification defines two new header field parameters, as per the registry created by RFC 3968 [8]. The required information is as follows:
この仕様では、RFC 3968 [8]によって作成されたレジストリに従って、2つの新しいヘッダーフィールドパラメーターを定義します。必要な情報は次のとおりです。
Header field in which the parameter can appear: Contact Name of the Parameter: pub-gruu Predefined Values: none RFC Reference: RFC 5627
パラメーターが表示できるヘッダーフィールド：パラメーターの連絡先名：pub-gruu事前定義値：なしRFCリファレンス：RFC 5627
Header field in which the parameter can appear: Contact Name of the Parameter: temp-gruu Predefined Values: none RFC Reference: RFC 5627
パラメーターが表示できるヘッダーフィールド：パラメーターの連絡先名：Temp-Gruu事前定義値：なしRFCリファレンス：RFC 5627
This specification defines one new SIP URI parameter, as per the registry created by RFC 3969 [9].
この仕様では、RFC 3969 [9]によって作成されたレジストリに従って、1つの新しいSIP URIパラメーターを定義します。
Name of the Parameter: gr Predefined Values: none RFC Reference: RFC 5627
パラメーターの名前：GR事前定義値：なしRFCリファレンス：RFC 5627
This specification registers a new SIP option tag, as per the guidelines in Section 27.1 of RFC 3261 [1].
この仕様は、RFC 3261 [1]のセクション27.1のガイドラインに従って、新しいSIPオプションタグを登録します。
Name: gruu
名前：グルー
Description: This option tag is used to identify the Globally Routable User Agent URI (GRUU) extension. When used in a Supported header, it indicates that a User Agent understands the extension. When used in a Require header field of a REGISTER request, it indicates that the registrar is not expected to process the registration unless it supports the GRUU extension.
説明：このオプションタグは、グローバルにルーティング可能なユーザーエージェントURI（GRUU）拡張機能を識別するために使用されます。サポートされているヘッダーで使用すると、ユーザーエージェントが拡張機能を理解していることを示します。レジスタリクエストの必要なヘッダーフィールドで使用する場合、Gruu拡張機能をサポートしない限り、レジストラが登録を処理することが期待されていないことを示します。
The author would like to thank Eric Rescorla, Robert Sparks, Rohan Mahy, Paul Kyzivat, Alan Johnston, Ya-Ching Tan, Dale Worley, Jeroen van Bemmel, Vijay Gurbani, Andrew Allen, Alan Hawrylyshen, Francois Audet, Fredrik Thulin, Dean Willis, David Hancock, Keith Drage, and Cullen Jennings for their comments and contributions to this work. Eric Rescorla provided the text for the introduction and the GRUU construction algorithm in the appendix.
著者は、エリック・レスコルラ、ロバート・スパークス、ロハン・マヒー、ポール・キジバット、アラン・ジョンストン、ヤ・チング・タン、デール・ウォーリー、ジェロエン・ヴァン・ベメル、ヴィジェイ・ガーバニ、アンドリュー・アレン、アラン・ハウリー・シェン、フランコイス・オーデット、フリードリク・ティーリン・ウィル・ウィル・、デビッド・ハンコック、キース・ドレイジ、カレン・ジェニングスのコメントとこの仕事への貢献について。Eric Rescorlaは、付録の紹介とGruu Constructionアルゴリズムのテキストを提供しました。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INITIATION Protocol」、RFC 3261、2002年6月。
[2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[2] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）：SIPサーバーの位置」、RFC 3263、2002年6月。
[3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[3] Willis、D。およびB. Hoeneisen、「非隣接接点を登録するためのセッション開始プロトコル（SIP）拡張ヘッダーフィールド」、RFC 3327、2002年12月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[5] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[6] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[6] Sparks、R。、「セッション開始プロトコル（SIP）参照メソッド」、RFC 3515、2003年4月。
[7] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[7] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[8] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[8] Camarillo、G。、「インターネットは、セッション開始プロトコル（SIP）のための数字権機関（IANA）ヘッダーフィールドパラメーターレジストリ」、BCP 98、RFC 3968、2004年12月。
[9] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004.
[9] Camarillo、G。、「インターネットは、セッション開始プロトコル（SIP）のための数字の権限（IANA）ユニフォームリソース識別子（URI）パラメーターレジストリ」、BCP 99、RFC 3969、2004年12月。
[10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[10] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[11] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[11] Schulzrinne、H。、「電話番号のためのTel URI」、RFC 3966、2004年12月。
[12] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[12] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）に対する発信者の好み」、RFC 3841、2004年8月。
[13] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[13] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。
[14] Jennings, C., Ed. and R. Mahy, Ed., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[14] ジェニングス、C。、編and R. Mahy、ed。、「セッション開始プロトコル（SIP）でのクライアント開始接続の管理」、RFC 5626、2009年10月。
[15] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[15] ピーターソン、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、2002年11月。
[16] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[16] Rosenberg、J.、Schulzrinne、H。、およびR. Mahy、「セッション開始プロトコル（SIP）の招待状のダイアログイベントパッケージ」、RFC 4235、2005年11月。
[17] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.
[17] Sparks、R.、Hawrylyshen、A.、Johnston、A.、Rosenberg、J。、およびH. Schulzrinne、「セッション開始プロトコル（SIP）拷問テストメッセージ」、RFC 4475、2006年5月。
[18] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers", RFC 3361, August 2002.
[18] Schulzrinne、H。、「セッション開始プロトコル（SIP）サーバーの動的ホスト構成プロトコル（DHCP-For-IPV4）オプション」、RFC 3361、2002年8月。
[19] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation Protocol (SIP) Call Control - Transfer", BCP 149, RFC 5589, June 2009.
[19] Sparks、R.、Johnston、A。、およびD. Petrie、「セッション開始プロトコル（SIP）コールコントロール - 転送」、BCP 149、RFC 5589、2009年6月。
[20] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730, November 2006.
[20] Burger、E。and M. Dolly、「キープレス刺激用のセッション開始プロトコル（SIP）イベントパッケージ（KPML）」、RFC 4730、2006年11月。
[21] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004.
[21] Mahy、R。and D. Petrie、「セッション開始プロトコル（SIP）「Header」に参加、RFC 3911、2004年10月。
[22] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[22] Mahy、R.、Biggs、B。、およびR. Dean、「セッション開始プロトコル（SIP）」「ヘッダー」、RFC 3891、2004年9月。
[23] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, October 2003.
[23] Willis、D。およびB. Hoeneisen、「登録中のサービスルート発見のためのセッション開始プロトコル（SIP）拡張ヘッダーフィールド」、RFC 3608、2003年10月。
[24] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[24] Rosenberg、J。、「登録のためのセッション開始プロトコル（SIP）イベントパッケージ」、RFC 3680、2004年3月。
[25] Camarillo, G., "Compressing the Session Initiation Protocol (SIP)", RFC 3486, February 2003.
[25] Camarillo、G。、「セッション開始プロトコル（SIP）の圧縮」、RFC 3486、2003年2月。
[26] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[26] Burger、E.、van Dyke、J。、およびA. Spitzer、「SIP付きベーシックネットワークメディアサービス」、RFC 4240、2005年12月。
[27] Jennings, C., Audet, F., and J. Elwell, "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)", RFC 4458, April 2006.
[27] Jennings、C.、Audet、F。、およびJ. Elwell、「VoicemailやInteractive Voice Response（IVR）などのアプリケーション用のセッション開始プロトコル（SIP）URI」、RFC 4458、2006年4月。
[28] Kyzivat, P., "Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs)", RFC 5628, October 2009.
[28] Kyzivat、P。、「セッション開始プロトコル（SIP）グローバルにルータブルユーザーエージェントURIS（Gruus）の登録イベントパッケージ拡張機能」、RFC 5628、2009年10月。
[29] Rosenberg, J., van Elburg, J., Holmberg, C., Audet, F., and S. Schubert, Ed., "Delivery of Request-URI Targets to User Agents", Work in Progress, June 2009.
[29] Rosenberg、J.、Van Elburg、J.、Holmberg、C.、Audet、F。、およびS. Schubert、ed。、「リクエストURIターゲットのユーザーエージェントへの配信」、2009年6月の進行中。
The mechanism for constructing a GRUU is not subject to specification. This appendix provides an example that can be used by a registrar to construct a public and a temporary GRUU. Of course, others are permitted, as long as they meet the constraints defined for a GRUU.
グルーを構築するためのメカニズムは、仕様の対象ではありません。この付録には、レジストラが使用して一般と一時的なグルーを構築できる例を示します。もちろん、グルーに対して定義された制約を満たしている限り、他の人は許可されています。
The most basic approach for constructing a public GRUU is to take the AOR and place the actual value of the instance ID into the contents of the "gr" URI parameter.
パブリックグルーを構築するための最も基本的なアプローチは、AORを取得し、インスタンスIDの実際の値を「GR」URIパラメーターの内容に配置することです。
This specification requires a registrar to create a new temporary GRUU on each registration refresh. If a registration is very long lived, this can quickly result in hundreds or even thousands of temporary GRUUs being created and allocated to a UA. Consequently, it is important to have an algorithm for constructing temporary GRUUs that does not require additional storage that grows in size with the number of temporary GRUUs. The following algorithm meets this goal.
この仕様では、レジストラが各登録更新で新しい一時Gruuを作成する必要があります。登録が非常に長い場合、これはすぐに数百または数千の一時的なグルーが作成され、UAに割り当てられる可能性があります。その結果、一時的なグルーの数とともにサイズが大きくなる追加のストレージを必要としない一時的なグルーを構築するためのアルゴリズムを持つことが重要です。次のアルゴリズムがこの目標を達成しています。
The registrar maintains a counter, I. This counter is 48 bits and is initialized to zero. The counter is persistently stored, using a backend database or other similar technique. When the registrar creates the first temporary GRUU for a particular AOR and instance ID, the registrar notes the current value of the counter, I_i, and increments the counter in the database. The registrar then maps I_i to the AOR and instance ID using the database, a persistent hashmap or similar technology. If the registration expires such that there are no longer any contacts with that particular instance ID bound to the GRUU, the registrar removes the mapping. Similarly, if the temporary GRUUs are invalidated due to a change in Call-ID, the registrar removes the current mapping from I_i to the AOR and instance ID, notes the current value of the counter I_j, and stores a mapping from I_j to the AOR and instance ID. Based on these rules, the hashmap will contain a single mapping for each AOR and instance ID for which there is a currently valid registration.
レジストラはカウンターを維持します。このカウンターは48ビットで、初期化されています。カウンターは、バックエンドデータベースまたは他の同様の手法を使用して、しつこく保存されています。レジストラが特定のAORおよびインスタンスIDの最初の一時GRUUを作成すると、レジストラはカウンターの現在の値I_Iに注意し、データベース内のカウンターを増分します。レジストラは、データベース、永続的なハッシュマップまたは同様のテクノロジーを使用して、I_IをAORおよびインスタンスIDにマッピングします。登録が期限切れになって、Gruuにバインドされた特定のインスタンスIDとの連絡先がなくなると、レジストラがマッピングを削除します。同様に、Call-IDの変更により一時のグルーが無効になっている場合、レジストラはi_iからAORおよびインスタンスIDへの現在のマッピングを削除し、カウンターI_Jの現在の値に注意し、i_JからAORへのマッピングを保存しますおよびインスタンスID。これらのルールに基づいて、ハッシュマップには、現在有効な登録がある各AORおよびインスタンスIDの単一のマッピングが含まれます。
The usage of a counter in a 48-bit space with sequential assignment allows for a compact representation of the hashmap key, which is important for generating GRUUs of reasonable size. The counter starts at zero when the system is initialized. Persistent and reliable storage of the counter is required to avoid misrouting of a GRUU to the wrong AOR and instance ID. Similarly, persistent storage of the hashmap is required, even through proxy and registrar restarts. If the hashmap is reset, all previous temporary GRUUs become invalidated. This might cause dialogs in progress to fail, or future requests towards a temporary GRUU to fail when they normally would not. The same hashmap needs to be accessible by all proxies and registrars that can field requests for a particular AOR and instance ID.
シーケンシャル割り当てを備えた48ビットスペースでのカウンターの使用により、ハッシュマップキーをコンパクトに表現できます。これは、合理的なサイズのグルーを生成するために重要です。システムが初期化されると、カウンターはゼロから始まります。間違ったAORおよびインスタンスIDへのGruuの誤ったものを避けるために、カウンターの永続的で信頼できるストレージが必要です。同様に、プロキシおよびレジストラの再起動を介して、ハッシュマップの永続的なストレージが必要です。ハッシュマップがリセットされている場合、以前のすべての一時的なグルーは無効になります。これにより、進行中のダイアログが失敗する可能性があります。または、通常はそうでない場合に一時的なグルーに対する将来の要求が失敗する可能性があります。同じハッシュマップには、特定のAORおよびインスタンスIDのリクエストをフィールドに表示できるすべてのプロキシおよびレジストラがアクセスできる必要があります。
The registrar maintains a pair of local symmetric keys K_e and K_a. These are regenerated every time the counter is reset. When the counter rolls over or is reset, the registrar remembers the old values of K_e and K_a for a time. Like the hashmap itself, these keys need to be shared across all proxy and registrars that can service requests for a particular AOR and instance ID.
レジストラは、ローカル対称キーK_EとK_Aのペアを維持しています。これらは、カウンターがリセットされるたびに再生されます。カウンターがロールオーバーまたはリセットされると、レジストラはしばらくの間K_EとK_Aの古い値を覚えています。ハッシュマップ自体と同様に、これらのキーは、特定のAORおよびインスタンスIDのリクエストをサービスできるすべてのプロキシおよびレジストラで共有する必要があります。
To generate a new temporary GRUU, the registrar generates a random 80-bit distinguisher value D. It then computes:
新しい一時的なGruuを生成するために、レジストラはランダムな80ビットの違いを生成します。次に計算します。
M = D || I_i
E = AES-ECB-Encrypt(K_e, M)
A = HMAC-SHA256-80(K_a, E)
Temp-Gruu-userpart = "tgruu." || base64(E) || base64(A)
where || denotes concatenation, and AES-ECB-Encrypt represents AES encryption in electronic codebook mode. M will be 128 bits long, producing a value of E that is 128 bits and A that is 80 bits. This produces a user part which has 42 characters.
ここで||連結を示し、AES-ECB-Encryptは電子コードブックモードのAES暗号化を表します。Mは長さ128ビットで、128ビット、Aが80ビットの値を生成します。これにより、42文字のユーザー部品が生成されます。
When a proxy receives a request whose user part begins with "tgruu.", it extracts the remaining portion, and splits it into 22 characters (E') and the remaining 14 characters (A'). It then computes A and E by performing a base64 decode of A' and E' respectively. Next, it computes:
プロキシが「Tgruu」から始まるユーザーパーツのリクエストを受信すると、残りの部分を抽出し、22文字（e '）と残りの14文字（a'）に分割します。次に、aとeをそれぞれaとeを計算します。それぞれ 'and e'のbase64デコードを実行します。次に、それは計算します：
Ac = HMAC-SHA256-80(K_a, E)
AC = HMAC-SHA256-80（k_a、e）
If the counter has rolled over or reset, this computation is performed with the current and previous K_a. If the Ac value(s) that are computed do not match the value of A extracted from the GRUU, the GRUU is rejected as invalid. Next, the proxy computes:
カウンターがロールオーバーまたはリセットされた場合、この計算は現在および以前のK_Aで実行されます。計算されたAC値がGruuから抽出された値と一致しない場合、Gruuは無効として拒否されます。次に、プロキシは計算します。
M = AES-ECB-Decrypt(K_e, E)
m = aes-ecb-decrypt（k_e、e）
If the counter has rolled over, this computation is done using the value of K_e that goes with the value of K_a, which produced a valid Ac in the previous HMAC validation. The leading 80 bits (the distinguisher D) are discarded, leaving an index I_i in the hashmap. This index is looked up. If it exists, the proxy now has the AOR and instance ID corresponding to this temporary GRUU. If there is nothing in the hashmap for the key I_i, the GRUU is no longer valid and the request is rejected.
カウンターがロールオーバーした場合、この計算は、以前のHMAC検証で有効なACを生成したK_Aの値に合うK_Eの値を使用して行われます。主要な80ビット（distiutisuiseer D）が破棄され、ハッシュマップにインデックスI_Iが残ります。このインデックスは調べられます。存在する場合、プロキシには、この一時的なグルーに対応するAORおよびインスタンスIDがあります。キーI_Iのハッシュマップに何もない場合、グルーはもはや有効ではなく、リクエストは拒否されます。
The usage of a 48-bit counter allows for the registrar to have as many as a billion AORs, with 10 instances per AOR, and cycle through 10,000 Call-ID changes for each instance through the duration of a single registration. These numbers reflect the average; the system works fine if a particular AOR has more than 10 instances or a particular instance cycles through more than 10,000 Call-IDs in its registration, as long as the average meets these constraints.
48ビットカウンターの使用により、レジストラは10億AORを持ち、AORあたり10インスタンスを備えており、1回の登録期間中、各インスタンスの10,000個のコールIDの変更をサイクリングできます。これらの数値は平均を反映しています。特定のAORに10を超えるインスタンスまたは特定のインスタンスが登録が10,000を超えるコールIDを循環する場合、システムは正常に機能します。
The GRUU specification works properly based on logic implemented at the user agents and in the authoritative proxies on both sides of a call. Consequently, it is possible to construct network deployments in which GRUUs will not work properly.
Gruu仕様は、ユーザーエージェントに実装されたロジックと、コールの両側の権威あるプロキシに基づいて適切に機能します。その結果、Gruusが適切に機能しないネットワーク展開を構築することが可能です。
One important assumption made by the GRUU mechanism is that, if a request passes through any proxies in the originating domain prior to visiting the terminating domain, one of those proxies will be the authoritative proxy for the User Agent Client (UAC). Administrators of SIP networks will need to make sure that this property is retained. There are several ways it can be accomplished:
Gruuメカニズムによってなされた重要な仮定の1つは、終了ドメインにアクセスする前にリクエストが発生ドメインのプロキシを通過する場合、それらのプロキシの1つがユーザーエージェントクライアント（UAC）の権威あるプロキシになるということです。SIPネットワークの管理者は、このプロパティが保持されることを確認する必要があります。達成する方法はいくつかあります：
1. If the user agents support the service-route mechanism [23], the registrar can implement it and return a service route that points to the authoritative proxy. This will cause requests originated by the user agent to pass through the authoritative proxy.
1. ユーザーエージェントがサービスルートメカニズム[23]をサポートする場合、レジストラはそれを実装し、権威あるプロキシを指すサービスルートを返すことができます。これにより、ユーザーエージェントが発信するリクエストが権威あるプロキシを通過するようになります。
2. The user agents can be configured to never use an outbound proxy, and send requests directly to the domain of the terminating party. This configuration is not practical in many use cases, but it is a solution to this requirement.
2. ユーザーエージェントは、アウトバウンドプロキシを使用しないように構成し、要求を終了した当事者のドメインに直接送信できます。この構成は多くのユースケースでは実用的ではありませんが、この要件の解決策です。
3. The user agents can be configured with an outbound proxy in the same domain as the authoritative proxy, and this outbound proxy forwards requests to the authoritative proxy by default. This works very well in cases where the clients are not roaming; in such cases, the outbound proxy in a visited network may be discovered dynamically through DHCP [18].
3. ユーザーエージェントは、権威あるプロキシと同じドメインのアウトバウンドプロキシで構成でき、このアウトバウンドプロキシはデフォルトで権威あるプロキシにリクエストを転送します。これは、クライアントが歩き回っていない場合に非常にうまく機能します。そのような場合、訪問されたネットワークのアウトバウンドプロキシは、DHCPを通じて動的に発見される場合があります[18]。
4. In cases where the client discovers a local outbound proxy via a mechanism such as DHCP, and is not implementing the service route mechanism, the UA can be configured to automatically add an additional Route header field after the outbound proxy, which points to a proxy in the home network. This has the same net effect of the service route mechanism, but is accomplished through static configuration.
4. クライアントがDHCPなどのメカニズムを介してローカルアウトバウンドプロキシを発見し、サービスルートメカニズムを実装していない場合、UAはアウトバウンドプロキシ後に追加のルートヘッダーフィールドを自動的に追加するように構成できます。ホームネットワーク。これは、サービスルートメカニズムと同じ正味効果を持っていますが、静的構成によって達成されます。
Author's Address
著者の連絡先
Jonathan Rosenberg Cisco Systems Edison, NJ US
ジョナサンローゼンバーグシスコシステムエジソン、ニュージャージー州
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net