[要約] RFC 5627は、SIPにおいて、特定のユーザーではなく特定の「端末（インスタンス）」を直接指し示すための一意なアドレス「GRUU（Globally Routable User Agent URI）」の取得と利用方法を定義しています。通話の転送やメディアの切り替えなどにおいて、意図した特定のデバイスへリクエストを正確にルーティングすることを可能にし、高度な呼制御を実現します。
Network Working Group J. Rosenberg
Request for Comments: 5627 Cisco Systems
Category: Standards Track October 2009
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.
Session Initiation Protocol（SIP）の複数の用途では、特定のユーザーエージェント（UA）インスタンスへインターネット上の誰もが呼をルーティングできるよう、UAがURIを作成して配布する必要があります。特定のUAインスタンスへルーティングするURIを、Globally Routable UA URI（GRUU）と呼びます。この文書では、レジストラーからGRUUを取得し、ダイアログ内でピアへGRUUを伝えるためのSIP拡張を説明します。
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.
この文書は、インターネットコミュニティ向けのインターネット標準化過程のプロトコルを規定し、改善のための議論や提案を求めます。このプロトコルの標準化段階と状態については、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。このメモは無制限に配布できます。
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
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文書に関するIETF Trustの法的規定（http://trustee.ietf.org/license-info）が適用されます。これらの文書には本書に関する権利と制限が記載されているため、注意深く確認してください。本書から抜粋したコードコンポーネントには、Trustの法的規定のセクション4.eに記載されたSimplified BSD Licenseの文面を含める必要があります。また、BSD Licenseに記載されたとおり、保証なしで提供されます。
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 Standards Processの外で変更を許可する権利をIETF Trustに与えていない場合があります。著作権を管理する者から適切なライセンスを得ない限り、この文書をIETF Standards Processの外で変更したり、派生著作物を作成したりしてはなりません。ただし、RFCとして発行するための形式調整、または英語以外への翻訳は例外です。
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.
Session Initiation Protocol（SIP、RFC 3261 [1]）では、基本的な参照単位はAddress of Record（AOR）です。ただし、SIPシステムでは1人のユーザーが複数のユーザーエージェント（端末、ソフトフォン、ボイスメールアカウントなど）を持つ場合があり、それらはすべて同じ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と通話しており、ユーザーCへ通話を転送したいとします。そこで、ユーザーAはユーザーCへREFERリクエストを送信します。このREFERリクエストの一部は次のようになります。
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.
Refer-Toヘッダーフィールドには、ユーザーCがユーザーBへ通話するために使用するURIを含める必要があります。ただし、この通話はユーザーBがユーザーAとの通話に使っている特定のUAインスタンスへルーティングされなければなりません。そうでないと転送サービスは正しく動作しません。例えば、AがBのAORをCに渡すと、通話が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のやり取りでContactヘッダーフィールドにインスタンス固有のURIを指定し、ユーザーAに渡します。このURIはBが現在使用しているUAを示し、CのUAが参照解決できます。ユーザー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.
現在の多くのクライアントは、Contactヘッダーフィールドに指定する値に明示的な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).
この仕様では、グローバルにルーティング可能な一意のユーザーエージェント識別子を提供する機構を説明します。この識別子をGlobally Routable User Agent（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].
この文書で使う「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」は、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.
contact：小文字で表記する「contact」は、登録によってAORとGRUUに関連付けられたURIを指します。通常はSIP URIであり、REGISTERリクエストのContactヘッダーフィールド値として指定することでAORとGRUUに関連付けられます。contact 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.
remote target：「remote target」は、ユーザーエージェントがダイアログ内外のリクエストを受信する際に、自身を識別するために使うURIを指します。ダイアログを確立するリクエストまたは応答のContactヘッダーフィールドにURIを指定するとremote targetが設定され、その後はtarget refreshリクエストまたは応答によって更新されます。
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.
Contactヘッダーフィールド：先頭のCを大文字にした「Contact header field」は、REGISTERリクエストと応答、リダイレクト、またはダイアログを作成するリクエストと応答に現れるヘッダーフィールドを指します。その意味に応じて、Contactヘッダーフィールドはcontactを表す場合とremote targetを表す場合があります。
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.
GRUUの基本的な考え方は単純です。GRUUはSIPドメインが発行し、常にそのドメイン内のプロキシへルーティングされます。ドメインはGRUUと特定のUAインスタンスとの対応付けを維持します。SIPリクエストの送信時にGRUUを参照解決すると、リクエストはプロキシに届きます。プロキシはGRUUを該当するUAインスタンスのcontactに対応付け、そのcontactへリクエストを送信します。
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ネットワーク内のUAに限らず、インターネット上のあらゆるUAが参照解決できます。
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を構築できます。ただし、すべてのGRUUには値の有無を問わず「gr」URIパラメーターが含まれるため、GRUUを受け取った側はこの2つの性質を判別できます。
In practice, there are two different types of GRUUs:
実際には、GRUUには次の2種類があります。
1. GRUUs that expose the underlying AOR
1. 基礎となるAORを明らかにするGRUU
2. GRUUs that hide the underlying AOR
2. 基礎となるAORを隠すGRUU
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は発着信を記録する通話履歴を保持します。UAがGRUUに発信した場合（例えば転送要求による発信）、履歴にはGRUUが記録されます。通話履歴はユーザーに表示されるため、識別子としてユーザーに意味のある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:
この種類のGRUUをpublic GRUUと呼びます。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になります。多くのシステムは未知のパラメーターを無視するため、そうしたシステムからはpublic GRUUが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.
別の場合には、GRUUの受信者がAORを取り出せないよう、AORを難読化したGRUUを構築すると望ましいことがあります。このGRUUをtemporary GRUUと呼びます。最も明白な理由はユーザーのプライバシーを守ることです。セクション3.1と5.4の要件を満たし、GRUUからAORを容易に特定できない限り、temporary GRUUの内容は任意です。temporary GRUUには、値の有無を問わず「gr」URIパラメーターが含まれます。レジストラーに過剰な状態を保持させないため、付録Aのようなアルゴリズムを使い、暗号学的に保護された「ステートレス」GRUUを構築することが望ましい場合がよくあります。
An example of a temporary GRUU constructed using a stateful algorithm would be:
状態を保持するアルゴリズムで構築したtemporary GRUUの例を次に示します。
sip:asd887f9dfkk76690@example.com;gr
A user agent can obtain a GRUU in one of several ways:
UAは、次のいずれかの方法でGRUUを取得できます。
o As part of its REGISTER transaction.
o REGISTERトランザクションの一部として取得します。
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 UAインスタンスのIPアドレスまたはホスト名をURIのドメイン部分に使い、ローカルで構築します。これをself-made GRUUと呼びます。IPアドレスまたはホスト名でグローバルに到達可能だと認識しているUAが構築した場合に限り、実際にGRUUとして機能します。
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:
REGISTERリクエストでGRUUを取得するUAは、RFC 5626 [14]で定義される「+sip.instance」ContactヘッダーフィールドパラメーターにインスタンスIDを指定します。例えば、次のようになります。
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:
レジストラーはこのヘッダーフィールドパラメーターを検出し、REGISTER応答で2つのGRUUを返します。一方はtemporary GRUU、もう一方はpublic GRUUです。応答のContactヘッダーフィールドパラメーター「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が有効期限前に登録を更新すると、レジストラーは同じpublic GRUUを返し、新しいtemporary GRUUを作成します。更新のたびに新しいtemporary GRUUがUAへ返されますが、同じcontactの有効期間中に以前のREGISTER応答から得たtemporary GRUUも、次の2条件を満たす限り有効です。(1) そのinstance IDを持つcontactが登録されたままであること、(2) UAが同じreg-idについて、REGISTERリクエストのCall-IDを以前の値から変更しないことです。そのインスタンスの最後のcontactが、明示的な登録解除またはタイムアウトによって失効すると、すべてのtemporary GRUUが無効になります。同様に、contact（RFC 5626を使用する場合はreg-id）の登録更新でCall-IDが以前の更新時と異なる場合も、以前のtemporary GRUUはすべて無効になります。その後、UAが同じinstance IDで新たに登録すると、public GRUUは前回と同じですが、新しいtemporary GRUUが発行されます。そのtemporary GRUUは次の更新まで唯一有効な値であり、次の更新で2つ目の値も有効になります。このように、temporary GRUUは登録期間中に蓄積されます。
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.
UAはレジストラーからGRUUを取得すると、いくつかの方法で使用します。まず、UAが送信するREGISTER以外のリクエストと応答では、Contactヘッダーフィールドの値としてGRUUを使用します（例えば、INVITEリクエストや200 OK応答）。RFC 3261 [1]によると、Contactヘッダーフィールドには、そのUAへルーティングされるURIを含めることになっています。この仕様より前には、その要件を実際に満たす方法がありませんでした。UAは匿名通話にはtemporary GRUUを使い、それ以外の場合はpublic GRUUを使います。
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インスタンスが登録したContactの集合を特定します。次にGRUUをそれらのContactに対応付け、リクエストを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がREGISTERリクエスト（初回または更新）を生成するときは、リクエストにSupportedヘッダーフィールドを含めなければなりません (MUST)。そのヘッダーフィールドの値には、オプションタグの1つとして「gruu」を含めなければなりません (MUST)。これにより、ドメインのレジストラーに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.
さらに、GRUUの取得を希望する各Contactについて、UAはUAの特性（[7]を参照）として「sip.instance」メディア機能タグ（RFC 5626 [14]を参照）を含めなければなりません (MUST)。その値は、登録対象のUAインスタンスを識別するインスタンスIDでなければなりません (MUST)。各Contactヘッダーフィールドには「pub-gruu」または「temp-gruu」ヘッダーフィールドを含めるべきではありません (SHOULD NOT)。RFC 3261 [1]のURI等価性規則に基づき、Contact URIはToヘッダーフィールドのAORと等価であってはなりません (MUST NOT)。Contact URIがGRUUの場合、ToヘッダーフィールドのAORに対するGRUUであってはなりません (MUST NOT)。
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]と同様に、REGISTER更新時のCall-IDは、そのContactの以前の登録に使ったCall-IDと同じであるべきです (SHOULD)。GRUUでは、さらに考慮すべき点があります。REGISTER更新時にCall-IDが変わると、サーバーはそのUAインスタンスに関連付けられたすべてのtemporary GRUUを無効にし、そのREGISTER応答で返された新しいGRUUだけが有効になります。RFC 5626を使用している場合、この規則はreg-idごとに適用されます。特定のreg-idの登録更新でCall-IDが変わると、サーバーはUAインスタンス全体に関連付けられたすべてのtemporary GRUUを無効にします。そのため、以前に取得したtemporary GRUUを引き続き有効にしたいUAは、REGISTER更新で同じCall-IDを使用しなければなりません (MUST)。ただし、無効化を意図する場合は、更新時にCall-IDを変更してもかまいません (MAY)。
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.
temporary GRUUをremote targetとして使うダイアログが進行中に、UAがCall-IDを変更して登録を更新すると、それらのtemporary GRUUは無効になります。その結果、ダイアログ内の後続メッセージではUAに到達できなくなることに注意してください。
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インスタンスが冗長化のために同じインスタンスについて複数のContactを登録する場合、RFC 5626 [14]で定義される手順を使用しなければなりません (MUST)。
A UA utilizing GRUUs can still perform third-party registrations and can include contacts that omit the "+sip.instance" Contact header field parameter.
GRUUを使用するUAも、サードパーティ登録を実行でき、「+sip.instance」Contactヘッダーフィールドパラメーターを省略したContactを含めることができます。
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.
ドメインがこの拡張をサポートして使用していない場合にREGISTERリクエストが処理されないことを保証したいUAは、「gruu」オプションタグを含む値を指定したRequireヘッダーフィールドをリクエストに含めてもかまいません (MAY)。この場合も、「gruu」オプションタグを含むSupportedヘッダーフィールドは必要です。Proxy-Requireの使用は必要ではなく、推奨されません (SHOULD NOT)。
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.
REGISTER応答が2xxの場合、「+sip.instance」Contactヘッダーフィールドパラメーターを含む各Contactヘッダーフィールドには、「pub-gruu」および「temp-gruu」Contactヘッダーフィールドパラメーターが含まれることがあります。これらのパラメーターは、それぞれUAインスタンスのpublic GRUUとtemporary GRUUを伝えます。UAはContactヘッダーフィールドに「pub-gruu」のみ、「temp-gruu」のみ、どちらも含まれない場合、または両方が含まれる場合を想定しなければなりません (MUST)。temporary GRUUは登録期間中（更新後も含む）有効ですが、public GRUUは登録をまたいで維持されます。UAはREGISTERが成功するたびに新しいtemporary GRUUを受け取り、public GRUUは通常同じ値です。ただし、この維持特性は完全には保証されないため、public GRUUが以前の値から変わる場合も想定しなければなりません (MUST)。同じContactまたはreg-idについて、今回のREGISTERリクエストのCall-IDを前回から変更した場合、UAは以前のREGISTER応答から取得したtemporary GRUUをすべて破棄しなければなりません (MUST)。少なくとも1つのContactまたはreg-idが継続して登録されている期間に取得したtemporary GRUUは、0個、1個、一部、またはすべてを保持してもかまいません (MAY)。登録中に使用するtemporary GRUUを保存するUAは、UAとレジストラーの時計のずれによって登録が意図せず失効しないことを確認する必要があります。そのため、UAは登録の有効期限前にREGISTER更新トランザクションが完了するかタイムアウトするよう登録を更新しなければなりません (MUST)。既定のトランザクションタイマーを使い、登録有効期間が64秒を超える場合、有効期限の少なくとも32秒前に更新します。登録有効期間が64秒未満の場合、UAは有効期限の半分が経過した時点で登録を更新すべきです (SHOULD)。
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つのフローが登録されている限りtemporary GRUUは有効です。したがって、1つのフローの登録が期限切れになっても、以前に取得したtemporary GRUUは有効なままです。
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].
レジストラーが登録間隔を強制的に短縮する場合、UAは登録イベントパッケージRFC 3680 [24]を使って変更を把握します。RFC 3680 [24]とGRUUの両方を実装するUAは、GRUUに関する情報を伝えるRFC 3680 [24]の拡張（RFC 5628 [28]で定義）も実装しなければなりません (MUST)。この拡張は、UAとレジストラーの間で有効なtemporary GRUUの集合を同期させるために必要です。一般に、temporary GRUUが有用であるためには、UAとレジストラーが有効なtemporary GRUUの集合について常に同期している必要があります。RFC 3680 [24]とそのGRUU拡張をサポートしない場合、クライアントが同期を保てるのは、登録の有効期限より十分前に毎回再登録するときに限られます。強制的な登録解除のほか、ネットワーク障害、接続障害、更新間隔の短さなども、有効なtemporary GRUUの集合に不整合を生じさせる可能性があります。このため、temporary GRUUを使用するUAにはRFC 3680 [24]とRFC 5628 [28]の実装が推奨されます (SHOULD)。
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.
REGISTERリクエストに対する非2xx応答は、UAに以前提供されたGRUUに影響しません。具体的には、以前に成功したREGISTERリクエストで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応答で取得したGRUUのユーザー部とホスト部は、UAが不透明な値として扱わなければなりません (MUST)。つまり、UAはそれらを変更してはなりません (MUST NOT)。UAは、認識していないURIパラメーターを変更または削除してはなりません (MUST NOT)。さらに、UAはプロキシでのリクエストの受信と処理に関係するURIパラメーター（transport、lr、maddr、ttl、user、comp。RFC 3486 [25]を参照）を追加、削除、または変更してはなりません (MUST NOT)。RFC 3261 [1]で定義される他のURIパラメーターであるmethodは、通常レジストラーが返すGRUUには含まれません。UAは、そのGRUUを別のエンティティに渡す前にmethod URIパラメーターを追加してもかまいません (MAY)。同様に、RFC 4240 [26]およびRFC 4458 [27]で定義されるURIパラメーターはUAが使用するためのものです。これらはレジストラーが返すGRUUには含まれませんが、それらのURIパラメーターに関連するサービスを提供するUAは追加してもかまいません (MAY)。
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がGRUUを参照解決するとき、属性をUAに届ける別の手段がなければ、Request-URIが登録済みContactに変換された時点でプロキシによりパラメーターが失われます。そのような情報伝達の仕組みは、現在、今後の標準化作業の対象です（「Delivery of Request-URI Targets to User Agents」[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.
Public Switched Telephone Network (PSTN)へのゲートウェイ、会議サーバー、メディアサーバーなど、多くのUAは登録を行わないため、その方法ではGRUUを取得できません。こうしたUAは、インターネットから到達可能な場合があります。これは、パブリックインターネット上のどこから送られたリクエストでも、ドメイン内の中継プロキシによる処理を経ずにUAへ配信できるというドメインポリシーを意味します。また、ドメインが管理するファイアウォールやNATのポリシーも、そのようなリクエストのネットワークへの到達を許可します。これらの条件が満たされるとUAが確信できる場合、自作GRUUを構築してもかまいません (MAY)。REGISTERを行うUAも、これらの条件が満たされるなら自作GRUUを構築してもかまいません (MAY)。ただし、レジストラーから取得したGRUUの使用が推奨されます (SHOULD)。
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では、ドメイン部にUAのIPアドレスまたはホスト名を使います。SIP URIのユーザー部はUAが任意に選びます。他のGRUUと同じく、URIには値の有無を問わず「gr」URIパラメーターを含め、GRUUであることを示さなければなりません (MUST)。
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は、ダイアログを確立するリクエストとターゲットを更新するリクエスト、およびそれらへの応答でContactヘッダーフィールドを設定するとき、GRUUを使用すべきです (SHOULD)。言い換えると、この仕様に準拠するUAは、自身のGRUUのいずれかをremote targetとして使用すべきです (SHOULD)。対象は次のとおりです。
o the INVITE request
o INVITEリクエスト
o a 2xx or 18x response to an INVITE which contains a To tag
o Toタグを含むINVITEへの2xxまたは18x応答
o the SUBSCRIBE request (see [5])
o SUBSCRIBEリクエスト（[5]を参照）
o a 2xx response to a SUBSCRIBE which contains a To tag
o Toタグを含むSUBSCRIBEへの2xx応答
o the NOTIFY request
o NOTIFYリクエスト
o the REFER request (see [6])
o REFERリクエスト（[6]を参照）
o a 2xx response to NOTIFY
o NOTIFYへの2xx応答
o the UPDATE request
o UPDATEリクエスト
o a 2xx response to NOTIFY The only reason not to use a GRUU would be privacy considerations; see Section 10.3.
o NOTIFYへの2xx応答。GRUUを使用しない唯一の理由はプライバシー上の考慮事項です。セクション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は使用前に有効な登録を持たなければならず (MUST)、その登録を通じて取得したGRUUを使用しなければなりません (MUST)。期限切れになった以前の登録（つまり、登録が失効したContactから取得したGRUU）を通じて取得したGRUUを再利用してはなりません (MUST NOT)。UAは、レジストラーから提供されたpublic GRUUまたはtemporary GRUUのいずれかを使用してもかまいません (MAY)。UAは、同じAORおよびインスタンスID（RFC 5626 [14]を使用している場合はreg-idも同じ）について、自身が生成した最新のREGISTERリクエストのCall-IDと異なるCall-IDを持つREGISTER応答から取得したtemporary GRUUを使用してはなりません (MUST NOT)。RFC 3323 [15]に記載された匿名リクエストを作成する場合、UAはtemporary GRUUを使用すべきです (SHOULD)。temporary GRUUが提供するプライバシーの程度については、セクション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」オプションタグを含むSupportedヘッダーを含めるべきです (SHOULD)。
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ネットワークによっては、UAが異なるドメインまたは同じドメイン内に複数の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は通常リクエストのFromヘッダーフィールドに現れ、そのAOR固有の認証情報を使ってリクエストを認証します。そのリクエストのContactヘッダーフィールドに設定するGRUUは、リクエスト送信に使ったAORに対応するものとすべきです (SHOULD)。UAがFromヘッダーフィールドにtel URI（[11]で定義）を設定する場合、通常、そのtel URIの別名として扱われるSIP AORも持っています。そのSIP AORに対応するGRUUをContactヘッダーフィールドで使用すべきです (SHOULD)。
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応答のContactヘッダーフィールドに設定するGRUUは、そのリクエストが直近に宛てられていたAORまたはGRUUに対応するものとすべきです (SHOULD)。リクエストの送信先となったAORまたはGRUUを特定する方法はいくつかあります。例えば、UAがAORごとに異なるContact（URIのユーザー部を変える方法）を登録していれば、そのContactを含むRequest-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.
これまで多くのContact URIがグローバルにルーティング可能でなかったことを補うため、非標準のURI処理機構を実装しているUAがあります。「gr」URIパラメーターを含むURIはグローバルにルーティング可能だと分かっているため、Contact URIに「gr」URIパラメーターが含まれている場合、UAはそのような機構を適用すべきではありません (SHOULD NOT)。
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宛てにリクエストを送信し、特定のインスタンスIDを持つUAへのルーティングを希望することを示すAccept-Contactヘッダーフィールド（[12]で定義）を含めたくなるかもしれません。これはGRUU宛てにリクエストを送る場合と同じ効果に見えますが、そうではありません。Accept-Contactヘッダーフィールドで示す発信側の希望は、あくまで希望にすぎません。実際に機能するには、UAが、AORに対するドメインの処理ロジックと連携し、特定のインスタンスへリクエストをルーティングさせるAccept-Contactヘッダーフィールドを構築する必要があります。選択したContactだけに時間帯でルーティングする場合など、ドメイン内のルーティングロジックには幅があるため、この方法は多くのドメインルーティングポリシーでは機能しません。ただし、希望する動作が実際に優先ルーティングリクエストである場合もあるため、この仕様はクライアントがそのようなリクエストを試みることを禁じていません。
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パラメーターを削除することが推奨されます (SHOULD)。public GRUUでは、これにより意図どおりAORになります。temporary GRUUでは、結果の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.
REGISTERリクエストに「gruu」オプションタグを指定したRequireヘッダーフィールドが含まれる場合があります。これは、リクエストを処理するにはレジストラーがこの拡張を理解していなければならないことを示します。ただし、レジストラーにGRUUの作成を要求するものではありません。
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に従ってREGISTERリクエスト内のContactを処理するとき、REGISTERメッセージの各Contactヘッダーフィールドに「+sip.instance」ヘッダーフィールドパラメーターが含まれているか確認します。このパラメーターがあり、有効期限がゼロでない場合は、本セクションの残りの規則に従ってContactをさらに処理します。それ以外の場合は、RFC 3261 [1]の通常の規則に従ってContactを処理します。
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.
Contactヘッダーフィールドの値が「*」で、有効期限がゼロのREGISTERリクエストを処理する場合も、RFC 3261 [1]で定義された意味は変わらないことに注意してください。特定のインスタンスIDを持つContactだけでなく、すべてのContactが削除されます。セクション5.4で説明するように、各ContactとAORとのバインディング、および各ContactとそのGRUUとのバインディングが削除されます。
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.
Contact URIがAORと等価である場合（RFC 3261 [1]のURI等価性に基づく）、ルーティングループが生じるため、レジストラーは403でリクエストを拒否しなければなりません (MUST)。Contact URIがREGISTERリクエストのToヘッダーフィールドにあるAORに対するGRUUの場合も、同じ理由でレジストラーは403でリクエストを拒否しなければなりません (MUST)。ContactがSIP URIでない場合、REGISTERリクエストを403で拒否しなければなりません (MUST)。
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.
次にレジストラーは、REGISTERリクエストのToヘッダーフィールドにあるAORと、「+sip.instance」Contactヘッダーフィールドパラメーターの値であるインスタンスIDに対して、有効なpublic GRUUがすでにあるか確認します。有効なpublic GRUUがない場合、レジストラーはこの時点でセクション5.4の手順に従ってpublic GRUUを構築すべきです (SHOULD)。public GRUUは、値を持つ「gr」URIパラメーターをAORに追加して構築しなければなりません (MUST)。Contactに「pub-gruu」Contactヘッダーフィールドパラメーターが含まれていても、レジストラーはそのパラメーターを無視しなければなりません (MUST)。UAがレジストラーにpublic 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に登録済みのContactを調べます。REGISTERリクエスト内のContactがフロー[14]を登録している場合は、reg-idも調べます。該当するContactが1つ以上あれば、レジストラーは最も最近登録されたものを選び、それに関連付けられたCall-IDを確認します。そのCall-IDがREGISTERリクエストのCall-IDと異なる場合、レジストラーはAORとインスタンスIDについて以前に生成したtemporary GRUUをすべて無効にしなければなりません (MUST)。この無効化により、以後、該当するGRUU宛てのリクエストはドメインから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用の新しいtemporary GRUUを作成すべきです (SHOULD)。temporary GRUUの構築アルゴリズムは、次の2つの性質を持たなければなりません (MUST)。
1. The likelihood that the temporary GRUU is equal to another GRUU that the registrar has created MUST be vanishingly small.
1. temporary GRUUが、レジストラーの作成した別のGRUUと等しくなる可能性は、極めて小さくなければなりません (MUST)。
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. 2つのGRUUが与えられたとき、それらが同じAORまたはインスタンスIDに対して発行されたのか、それとも異なるAORおよびインスタンスIDに対して発行されたのかを判定することは、計算上実行不可能でなければなりません (MUST)。
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.
Contactに「temp-gruu」Contactヘッダーフィールドパラメーターが含まれていても、レジストラーはそのパラメーターを無視しなければなりません (MUST)。UAがレジストラーにtemporary GRUUを提案または提供することはできません。
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.
REGISTERリクエストに対する200 (OK)応答を生成するときは、RFC 3261 [1]のセクション10.3の手順8に従います。さらに、応答に含める各Contactヘッダーフィールド値について、レジストラーがそのContactに関連付けられたインスタンスIDを保存していれば、そのインスタンスIDをContactヘッダーフィールドパラメーターとして返します。REGISTERリクエストのSupportedヘッダーフィールドに「gruu」オプションタグが含まれ、レジストラーがそのインスタンスIDとAORに割り当てたtemporary GRUUを1つ以上持つ場合、レジストラーはそのContactヘッダーフィールドに「temp-gruu」Contactヘッダーフィールドパラメーターを追加しなければなりません (MUST)。 「temp-gruu」パラメーターの値は引用符で囲んだ文字列とし、そのAORとインスタンスIDについて最も最近作成されたtemporary GRUUを含めなければなりません (MUST)。さらに、レジストラーがそのインスタンスIDとAORにpublic GRUUを割り当てており、クライアントがGRUUをサポートしている場合、レジストラーはそのContactヘッダーフィールドに「pub-gruu」Contactヘッダーフィールドパラメーターを追加しなければなりません (MUST)。このパラメーターの値はpublic GRUUです。
The registrar SHOULD NOT include the "gruu" option tag in the Require or Supported header field of the response.
レジストラーは、応答のRequireまたはSupportedヘッダーフィールドに「gruu」オプションタグを含めるべきではありません (SHOULD NOT)。
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.
登録済みContactが（タイムアウトまたは明示的な登録解除によって）失効すると、通常どおり、そのAORへのバインディングが削除されます。さらに、セクション5.4で説明する関係に基づき、そのContactのGRUUへのバインディングも同時に削除されます。Contactの失効によって、特定のGRUUにバインドされた登録済みContactがなくなり、そのGRUUがtemporary GRUUである場合、そのGRUUを無効にしなければなりません (MUST)。つまり、特定のインスタンスIDに対する最後のContactが失効すると、蓄積されたすべてのtemporary GRUUが無効になります。
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がpublic GRUUである場合、レジストラーは引き続き有効なものとして扱うべきです (SHOULD)。したがって、そのGRUUへのContactの再登録前にGRUU宛てに届いたリクエストには、480 (Temporarily Unavailable)応答を返すべきです (SHOULD)。また、GRUUは有効なままなので、セクション5.1の規則により、同じインスタンスIDを持つContactが再びAORに登録されたときに、そのGRUUは維持されます。
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.
これらの規則により、public GRUUは半永続的な性質を持ちます。意図としては、ドメイン内でAOR自体が認識されている限り、レジストラーがGRUUの有効性を保つためにあらゆる努力をすることです。必須 (MUST) 強度ではなく推奨 (SHOULD) 強度の要件としたのは、必須強度 (MUST) の要件を満たすことが難しいためです。レジストラーの障害によって有効なGRUUの集合が失われる可能性があり、この仕様ではそのような場合にもUAが堅牢に動作することを求めています。一方で、レジストラーが追加状態を保持しなくても、ここで説明した要件を満たすpublic 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.
このセクションでは、レジストラーに固有の、GRUUの構築と維持に関する追加の動作を定義します。これらの規則は、自作GRUUや登録を通じて取得していないGRUUには適用されません。
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を作成するときは、それがpublic GRUUかtemporary GRUUかにかかわらず、GRUUに関連する特定の情報を維持する必要があります。各GRUUは単一のAORと単一のインスタンスIDに関連付けられます。レジストラーはGRUUを提示されたときにインスタンスIDとAORを特定できなければなりません (MUST)。また、GRUUはAORと同様に、0個以上のContactに解決されます。AORはそのAORに登録されたすべてのContactに解決されますが、GRUUはGRUUに関連付けられたものとインスタンスIDが一致するContactだけに解決されます。このため、インスタンスIDを持つContactは、常にGRUUとそのAORの両方にバインドされ、AORだけまたはGRUUだけにバインドされることはありません。この関係を図1に示します。図には、1つのAORに登録された3つのContactがあります。1つのContactのインスタンスIDは1で、残る2つのContactのインスタンスIDは2です。このAORには2つのGRUUがあり、一方はインスタンスID 1、もう一方はインスタンスID 2に関連付けられています。最初のGRUUはインスタンスIDが1のContactだけに解決され、2番目のGRUUはインスタンスIDが2のContactだけに解決されます。UAがクラッシュ後に再起動して同じインスタンスIDで再登録した場合や、冗長化のためにRFC 5626 [14]の機構で複数の登録を行う場合、通常は同じインスタンスIDに対して複数のContactが存在します。インスタンスID 1のContactが失効すると、AORは2つのContactに解決されますが、インスタンスID 1に関連付けられたGRUUは0個のContactに解決されます。
+----------+ +----------+ +----------+
| 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に関連付けられたGRUUは複数存在することがあります。実際、この仕様ではレジストラーが多数のGRUU（public GRUUを1つとtemporary GRUUを複数）を維持することを求めています。ただし、異なるAOR、異なるインスタンスID、またはその両方に関連付けられた2つのGRUUは、URI等価性の比較で異なるものでなければなりません (MUST)。ドメイン内のGRUUは、そのGRUUに関連付けられたAORを除き、ドメイン内のいかなるAORともURI比較で等価であってはなりません (MUST NOT)。
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.
public GRUUは、URI等価性規則に基づいて常にAORと等価になります。RFC 3261 [1]の規則では、一方のURIに存在し、もう一方には存在しないURIパラメーターは、等価性の判定で無視されるためです。public GRUUとAORの違いは「gr」URIパラメーターの有無だけなので、この規則に基づいて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.
temporary GRUUを構築した後は、前述の規則に基づいて無効化されるまで、レジストラーはそれを有効と見なさなければなりません (MUST)。public GRUUを構築した後は、AOR自体が有効である期間、レジストラーはそれを有効と見なさなければなりません (MUST)。ドメイン内でAORが無効になった場合、そのAORのすべてのGRUUも無効と見なさなければなりません (MUST)。
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:
この仕様は、GRUUの構築に特定の方式を義務付けません。適切に機能するpublic GRUUとtemporary GRUUのアルゴリズム例を付録Aに示します。ただし、セクション3.1で説明した性質に加え、レジストラーが構築するGRUUは次の性質を持たなければなりません (MUST)。
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]もサポートしなければなりません (MUST)。
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の処理は、権威プロキシでのリクエストの宛先決定とRecord-Route処理という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.
プロキシがリクエストを受信し、Request-URIのドメインを担当していて、リクエストの宛先を計算するためにロケーションサービスへアクセスすることになっている場合（RFC 3261 [1]のセクション16.5で規定）、Request-URIを調べます。「gr」URIパラメーターを含むものの、URI比較でドメイン内の現在有効なGRUUと等価でない場合、そのリクエストは404 (Not Found)応答で拒否すべきです (SHOULD)。これは、ドメイン内の他の無効な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.).
Request-URIに「gr」URIパラメーターが含まれ、URI比較でドメイン内の現在有効なGRUUと等価である場合、RFC 3261 [1]のセクション16.5に定義されるロケーションサービス内の他のURIと同様に処理を進めます。ただし、正規化の際に「gr」URIパラメーターを削除しません。この処理は、GRUU宛てのダイアログ外リクエストとダイアログ内リクエストの両方に適用されます。後者では、受信リクエストのRouteヘッダーフィールド値に、Record-Route処理でプロキシが使用した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は登録済みContactに書き換えられ、GRUUとその「gr」URIパラメーターは置き換えられます。書き換え後のRequest-URIに「gr」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にバインドされた登録済みContactがない場合、サーバーは480 (Temporarily Unavailable)応答を返さなければなりません (MUST)。複数ある場合は、次の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]を使用し、冗長化のために複数のContactを登録している場合です。この場合、各Contactには「reg-id」Contactヘッダーフィールドパラメーターが含まれ、登録済みContactを1つ選択するには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で再登録した場合に限り、同じインスタンスIDを持つContactが複数存在します。これらのContactには「reg-id」Contactヘッダーフィールドパラメーターが含まれません。プロキシは、最も最近更新されたContactを選択しなければなりません (MUST)。RFC 5626の場合と同様に、この宛先へのリクエストが408 (Request Timeout)または430 (Flow Failed)応答で失敗した場合、プロキシは次に最近更新されたContactを使って再試行すべきです (SHOULD)。それ以外の応答でリクエストが失敗した場合、プロキシはこのインスタンスの他のContactを使って再試行してはなりません (MUST NOT)。
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にバインドされたContactに対して処理すべきです (SHOULD)。
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.
要するに、登録済みContactを選ぶ際、GRUUはAORと同様に処理しますが、AORにバインドされたContactの一部だけを対象にします。
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.
登録情報に保存されたPathヘッダーの処理には、特別な考慮が必要です（RFC 3327 [3]を参照）。受信リクエストに権威プロキシ自身を指すRouteヘッダーフィールド値以外の値も含まれる場合（ダイアログ内リクエストではこの状態になります）、Path URIを破棄しなければなりません (MUST)。RFC 3327 [3]ではローカルポリシーとしてこれが許可されています。GRUUを使用するには、呼のループや呼の失敗を避けるため、このポリシーが必要です。
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宛てリクエストの場合と同様に、着信側機能の実行など、他の処理をリクエストに適用してもかまいません (MAY)。ダイアログ外のリクエストには、自動処理（ブラックリストやホワイトリストによるスクリーニングなど）と対話処理（ユーザーに通話を受け入れるか尋ねるIVRアプリケーションなど）の両方を含むスクリーニング機能を適用することが推奨されます (SHOULD)。新しいリクエストが既存のダイアログに関係し、そのダイアログへの参加（RFC 3911 [21]で定義されたJoinヘッダーフィールドを使用）または置換（RFC 3891 [22]で定義されたReplacesヘッダーフィールドを使用）を試みる場合も多くあります。新しいリクエストが既存のダイアログに関係する場合、通常、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宛てのリクエストには、呼転送などの転送サービスを提供すべきではありません (SHOULD NOT)。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.
一般に、ダイアログ内リクエストには、その種のリクエストに意味のあるサービスだけをプロキシが適用すべきです (SHOULD)。スクリーニング機能と転送機能はこれに含まれません。
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.
さらに、GRUU宛てのリクエストはリダイレクトすべきではありません (SHOULD NOT)。UAはNATやファイアウォールを通過するためにGRUUを使うことが多く、リダイレクトによって機能しなくなる可能性があります。
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.
Record-Route処理には、発信側ドメインと着信側ドメインでそれぞれ異なる要件があります。これらの要件は、不要で問題を招く可能性のあるリクエストのループを防ぎます。
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 かつContactヘッダーフィールドに、そのプロキシのドメイン内のGRUUが含まれる場合。
o AND that GRUU is a valid one in the domain of the proxy,
o かつ、そのGRUUがプロキシのドメイン内で有効であり、
o AND that GRUU is associated with the AOR matching the authenticated identity of the requestor (assuming such authentication has been performed),
o かつ、そのGRUUが、要求側が認証済みであれば、その認証済みIDと一致するAORに関連付けられており、
o AND the request contains Record-Route header fields,
o かつ、リクエストにRecord-Routeヘッダーフィールドが含まれる場合、
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.
権威プロキシはRecord-Routeを実行しなければなりません (MUST)。これらの条件がすべて満たされるものの、GRUUが要求側の認証済みIDと一致しないAORに関連付けられている場合、プロキシは403 (Forbidden)応答でリクエストを拒否することが推奨されます (SHOULD)。
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 かつRequest-URIに、ロケーションサービス内のURI（GRUUまたはAOR）が含まれ、
o AND the contact selected for sending the request has an instance ID and is bound to a GRUU,
o かつ、リクエスト送信先として選ばれたContactがインスタンスIDを持ち、GRUUにバインドされており、
o AND the registration contain Path URI,
o かつ、登録にPath URIが含まれる場合、
then the authoritative proxy MUST record-route.
権威プロキシはRecord-Routeを実行しなければなりません (MUST)。
If a proxy is in either the originating or terminating domains but is not an authoritative proxy, the proxy MAY record-route.
発信側または着信側ドメイン内にあるプロキシが権威プロキシでない場合、そのプロキシはRecord-Routeを実行してもかまいません (MAY)。
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).
何らかの理由（ファイアウォール通過、課金など）で、着信側ドメインのプロキシがダイアログ内リクエストを必ず経由させる必要がある場合、そのプロキシは引き続きRecord-Routeを実行しなければなりません (MUST)。また、UAが応答のContactヘッダーフィールドでGRUUを使うと想定してはなりません (MUST NOT)。そのように想定すると、Record-Routeを行わずにダイアログ内リクエストをプロキシ経由で通すことになるためです。
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がContactにGRUUを使用し、プロキシが登録時にPathヘッダーフィールドへ自身を挿入している場合、そのプロキシはRecord-Routeを実行するかどうかにかかわらず、ダイアログ内リクエストを受信することに注意してください。違いは、ダイアログ内リクエストの最上位のRouteヘッダーフィールドで、プロキシがどのURIを見るかだけです。Record-Routeを実行していればそのURIを見ます。実行していなければ、自身が挿入したPath 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]で定義されている「contact-params」の文法を拡張し、2つの新しいContactヘッダーフィールドパラメーター（「temp-gruu」と「pub-gruu」）を定義します。また、同RFCの「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
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を含めなければなりません (MUST)。ただし、他の引用文字列と同じ方法でエンコードされるため、この形式で表現する場合は引用符付きペアのエスケープを含めることができます。
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は、自身の同じインスタンスへそれぞれルーティングされる複数のGRUUを取得できる必要があります。例えば、UAインスタンスが主催する会議ごとに異なるURIを必要とするアドホック会議をサポートするために必要です。注：この仕様はこの要件を満たしていません。別の仕様（現時点では「Delivery of Request-URI Targets to User Agents」[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宛てのリクエストを受信したとき、そのリクエストを呼び出すために使用されたGRUUをUAが知ることができる必要があります。これはREQ 4から派生する要件です。注：この仕様はこの要件を満たしていません。別の仕様（現時点では「Delivery of Request-URI Targets to User Agents」[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に追加できる必要があります。この内容はネットワークによって解釈も変更もされず、GRUUが指すUAインスタンスだけが使用します。これにより、状態を埋め込んだGRUUをUAが構築できる、基本的なCookie型の機能が得られます。注：この仕様はこの要件を満たしていません。別の仕様（現時点では「Delivery of Request-URI Targets to User Agents」[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がGRUUを表すと認識できる必要があります。これは、ダイアログ内でURIが転送されるGRUUの会議用途およびダイアログ再利用用途に必要です。
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を転送する場合、GRUUを受信するUAがその完全性と真正性を確認できる必要があります。
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を構築できる必要があります。言い換えると、プロキシも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宛てのサブスクリプションを示します。その後、着信側UAの障害と再登録を示します。長いメッセージ行の表記には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
The callee supports the GRUU extension. As such, its REGISTER (1) looks like:
着信側UAはGRUU拡張をサポートしています。そのため、REGISTER（メッセージ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:
レジストラーはtemporary GRUUとpublic GRUUを割り当てます。REGISTER応答（メッセージ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.
REGISTER応答のContactヘッダーフィールドには、public GRUU「sip:callee@example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6」を値とする「pub-gruu」Contactヘッダーフィールドパラメーターと、temporary GRUU「sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr」を値とする「temp-gruu」パラメーターが含まれます。どちらもこのAORとインスタンスIDに対する有効なGRUUであり、いずれもContact「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.
発信側からのINVITE（メッセージ3）は通常のSIP INVITEです。一方、着信側UAが生成する200 OK（メッセージ5）には、remote targetとしてGRUUが含まれています。このUAはpublic GRUUを使うことを選んでいます。
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]
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は特定のUAに対してダイアログイベントパッケージ（[16]で定義）をサブスクライブすることにします。そのためSUBSCRIBEリクエスト（メッセージ9）を生成し、remote targetである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.
この例では、発信側UAもGRUU拡張をサポートしており、自身のremote targetを設定するために自身の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.
このリクエストはプロキシへルーティングされ、プロキシはRequest-URIを使ってロケーション検索を行います。Request-URIはそのインスタンスのContactに変換され、リクエストはそのContactへプロキシされます。
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:
SUBSCRIBEに対する200応答（メッセージ11）が生成され、続いてNOTIFY（メッセージ13、14）とその応答（メッセージ15、16）が送信されます。メッセージ16の受信後、ある時点で着信側のマシンがクラッシュし、復旧します。マシンは新しい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:
レジストラーは、別のContact「sip:callee@192.0.2.1」がすでに同じインスタンスIDに関連付けられていることを検出します。レジストラーは新しいContactも登録し、REGISTER応答に両方を返します。両方のContactに同じpublic GRUUが対応しますが、レジストラーはこのAORとインスタンスIDの組み合わせに対して2つ目のtemporary GRUUを生成しています。両方のContactはREGISTER応答に含まれ、それぞれに示されるtemporary GRUUは同一です。これは、そのインスタンス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が古くなった登録済みContactを削除する必要はありません。セクション6.1のリクエスト宛先決定規則により、リクエストは最も新しいContactへ配信されます。
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.
GRUUを使用するSIPネットワークへの攻撃は、外部攻撃（第三者がシステムを攻撃しようとするもの）と内部攻撃（攻撃者はシステムの正規参加者だが、悪意を持つもの）に分けられます。また、GRUUの使用にはプライバシー上の考慮事項もあります。
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].
REGISTER応答で与えられたGRUUの完全性をUAが確認できることは重要です。攻撃者がGRUUを改ざんすると、UAに対するサービス拒否（DoS）につながる可能性があります。このため、UAは登録時にRequest-URIでSIPS URIスキームを使用することが推奨されます (SHOULD)。プロキシとレジストラーはSIPS URIをサポートしなければならず (MUST)、TLSもサポートしなければなりません (MUST)。これは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に対応する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が使われないようにします。
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は自身が送信するダイアログ確立リクエストとターゲット更新リクエスト、およびそれらへの応答でGRUUを使うようになります。これらのGRUUは別の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がtemporary GRUUだった場合、「gr」URIパラメーターを削除した結果、GRUUとして認識されず、どのAORとも等価でないURIになるため、リクエストは拒否されます。GRUUがpublic 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を知ります。GRUUを得ると、攻撃者はプレゼンスサーバーなど、多数のリクエストをUAへ送り返すエンティティにSIPリクエストを送信します。ただし、そのSUBSCRIBEリクエストのContactヘッダーフィールドには対象のGRUUを指定します。すると、応答トラフィックは攻撃者ではなく対象へ向かいます。GRUUはグローバルに到達可能なため、対象のIPアドレス宛てのトラフィックよりも届きやすくなります。本仕様は、リクエストのContactに含まれる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]はプライバシーの仕組みを定義し、ネットワークが提供するプライバシーとユーザーが提供するプライバシーを区別しています。前者では、ユーザーはリクエストにPrivacyヘッダーフィールドを含め、ネットワークにプライバシーサービスを要求します。後者では、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でContactヘッダーフィールドを構成するよう求めています。この推奨は、Contactヘッダーフィールドで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.
ただし、レジストラーが提供するtemporary GRUUは、RFC 3323 [15]に記載されたContact URI形式の代わりに使用できます。UAは各REGISTER応答で返されたtemporary GRUUを取得し、そのうち少数をキャッシュします。発信または着信の際には、temporary GRUUをContactヘッダーフィールドに設定します。
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は、すべての通話で同じtemporary GRUUを使用することも、通話ごとに異なるtemporary 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 通話ごとに同じtemporary GRUUを使用すると、通信相手はContactヘッダーフィールドを見るだけで、同じUAからの通話を関連付けられます。RFC 3323 [15]のユーザーが提供するプライバシー手順でも同様です。Contact URIに含まれる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 通話ごとに異なるtemporary GRUUを使用すると、通信相手はContactヘッダーフィールドを見るだけでは、同じ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 どちらの場合も、ネットワーク提供のプライバシーがなければ、Session Description Protocol (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 どちらの場合も、ユーザーが発信すると、通信相手はContactヘッダーフィールド内のGRUU宛てにリクエストを送って折り返し連絡できます。同様に、GRUUの性質を持つContactに依存する、ネットワークアプリケーションサーバーによる転送や数字収集などの機能（RFC 4730 [20]を参照）も利用できます。このような着信リクエストは、UAの登録が失効するまで可能です。到達可能性を制限するために以前のtemporary GRUUを無効にしたいUAは、以前使ったものとは異なるCall-IDを指定してREGISTER更新を行ってもかまいません (MAY)。temporary GRUUを無効にするために登録を強制的に失効させてから再登録すべきではありません (SHOULD NOT)。その方法では短時間到達不能になり、多くの場合ネットワークに過剰な負荷がかかるためです。新しいCall-IDによる更新のほうが効率的であり、temporary GRUUの有効性を大まかに制御する方法として意図されています。特定の折り返し連絡を受けたくないUAは、それを拒否する手動または自動の呼処理を実装する必要があります。本仕様は、個々のtemporary GRUUを手動で無効にする機能をUAに提供しません。このような着信リクエスト（数字収集などのネットワークアプリケーションが生成するものを含む）を一切受け取りたくないUAは、ContactヘッダーフィールドにGRUU以外の値を設定できます。ただし、これは推奨されません (SHOULD NOT)。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 Contactヘッダーフィールドにtemporary GRUUを設定している限り、通信相手はそのフィールドを見るだけではUAのAORやインスタンスIDに関する情報を特定できません。ただし、ネットワーク提供のプライバシーサービスがなければ、SDP内のIPアドレスからUAの地理的位置やISPなどの情報を特定できる可能性があります。
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がContactでtemporary GRUUとpublic GRUUのどちらを使うか、GRUU自体を使うかどうか、またネットワーク提供のプライバシーサービスを利用するかどうかにかかわらず、通信相手は常にUAのSIPサービスプロバイダーを特定できます。
This specification defines two new Contact header field parameters, one SIP URI parameter, and a SIP option tag.
この仕様では、新しいContactヘッダーフィールドパラメーターを2つ、新しいSIP URIパラメーターを1つ、新しいSIPオプションタグを1つ定義します。
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
パラメーターを含められるヘッダーフィールド: Contact。パラメーター名: 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
パラメーターを含められるヘッダーフィールド: Contact。パラメーター名: 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]で作成されたレジストリーに従って、新しいSIP URIパラメーターを1つ定義します。
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
名前: 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.
説明: このオプションタグは、Globally Routable User Agent URI (GRUU)拡張を識別するために使用します。Supportedヘッダーフィールドで使用すると、UAがこの拡張を理解していることを示します。REGISTERリクエストのRequireヘッダーフィールドで使用すると、レジストラーが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、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、Cullen Jenningsに、本作業へのコメントと貢献について感謝します。Eric Rescorlaは、序論と付録のGRUU構築アルゴリズムの文面を提供しました。
[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., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[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. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[6] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[6] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[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., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[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., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[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., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004.
[10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[11] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[11] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[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., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[13] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[13] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[14] Jennings, C., Ed. and R. Mahy, Ed., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[14] Jennings, C., Ed. and R. Mahy, Ed., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[15] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[15] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[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., and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[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., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.
[18] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers", RFC 3361, August 2002.
[18] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers", RFC 3361, August 2002.
[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., and D. Petrie, "Session Initiation Protocol (SIP) Call Control - Transfer", BCP 149, RFC 5589, June 2009.
[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, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730, November 2006.
[21] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004.
[21] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004.
[22] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[22] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[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. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, October 2003.
[24] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[24] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[25] Camarillo, G., "Compressing the Session Initiation Protocol (SIP)", RFC 3486, February 2003.
[25] Camarillo, G., "Compressing the Session Initiation Protocol (SIP)", RFC 3486, February 2003.
[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., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[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., and J. Elwell, "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)", RFC 4458, April 2006.
[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., "Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs)", RFC 5628, October 2009.
[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., and S. Schubert, Ed., "Delivery of Request-URI Targets to User Agents", Work in Progress, June 2009.
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.
GRUUの構築方法は本仕様の規定対象ではありません。この付録では、レジストラーがpublic GRUUとtemporary GRUUを構築する際に使える例を示します。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.
public GRUUを構築する最も基本的な方法は、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.
この仕様では、登録を更新するたびにレジストラーが新しいtemporary GRUUを作成することを求めています。登録期間が非常に長いと、数百、場合によっては数千のtemporary GRUUが作成され、UAに割り当てられることがあります。そのため、temporary GRUUの数に応じて増大する追加ストレージを必要とせずにtemporary GRUUを構築できるアルゴリズムが重要です。次のアルゴリズムはこの要件を満たします。
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.
レジストラーはカウンターIを維持します。このカウンターは48ビットで、初期値は0です。カウンター値は、バックエンドデータベースなどの仕組みを使って永続的に保存します。特定のAORとインスタンスIDに対する最初のtemporary GRUUを作成するとき、レジストラーはカウンターの現在値I_iを記録し、データベース内のカウンターをインクリメントします。続いてデータベース、永続的なハッシュマップ、または同様の技術を使い、I_iをAORとインスタンスIDに対応付けます。登録が失効し、そのGRUUにバインドされた該当インスタンスIDのContactがなくなると、レジストラーはこの対応付けを削除します。同様に、Call-IDの変更によってtemporary GRUUが無効になった場合、レジストラーはI_iからAORとインスタンスIDへの現在の対応付けを削除し、カウンターの現在値I_jを記録して、I_jをAORとインスタンスIDに対応付けます。この規則により、ハッシュマップには、現在有効な登録がある各AORとインスタンスIDについて、1つの対応付けが格納されます。
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ビット空間でカウンターを順次割り当てると、ハッシュマップのキーを短く表現できます。これは、適切な長さのGRUUを生成するうえで重要です。システムの初期化時にカウンターは0から始まります。GRUUが誤ったAORとインスタンスIDにルーティングされないよう、カウンター値を永続的かつ信頼できる形で保存する必要があります。同様に、プロキシやレジストラーの再起動後もハッシュマップを永続的に保存する必要があります。ハッシュマップがリセットされると、それまでのtemporary GRUUはすべて無効になります。その結果、進行中のダイアログや、通常なら成功するtemporary 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:
新しいtemporary GRUUを生成するため、レジストラーはランダムな80ビットの識別値Dを生成します。次に、次の値を計算します。
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ビットです。その結果、Eは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'をそれぞれBase64デコードし、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と以前のK_aを使います。計算したAcの値が、GRUUから抽出したAの値と一致しなければ、そのGRUUを無効として拒否します。続いて、プロキシは次の値を計算します。
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ビット（識別値D）を破棄すると、ハッシュマップのインデックスI_iが残ります。このインデックスを検索します。エントリーがあれば、プロキシはこのtemporary GRUUに対応するAORとインスタンスIDを取得します。キーI_iに対応するエントリーがハッシュマップにない場合、GRUUはすでに無効なのでリクエストを拒否します。
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回のCall-ID変更を扱うことができます。これらの数値は平均値です。平均がこの条件を満たす限り、特定のAORが10個を超えるインスタンスを持つ場合や、特定のインスタンスが登録期間中に10,000回を超えてCall-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仕様は、UAと通話の両側にある権威プロキシに実装されたロジックに基づいて正しく機能します。そのため、ネットワーク構成によってはGRUUが正常に機能しない場合があります。
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つがUser Agent Client (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. UAがサービスルート機構[23]をサポートしている場合、レジストラーはこれを実装し、権威プロキシを指すサービスルートを返せます。これにより、UAが発信するリクエストは権威プロキシを経由します。
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. UAがアウトバウンドプロキシを決して使わず、着信側のドメインへリクエストを直接送信するよう構成できます。この構成は多くのユースケースで実用的ではありませんが、この要件を満たす方法です。
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. UAは、権威プロキシと同じドメインにあるアウトバウンドプロキシを使うよう構成できます。このアウトバウンドプロキシは、既定で権威プロキシへリクエストを転送します。クライアントがローミングしていない場合に有効です。クライアントが訪問先ネットワークにいる場合、そのネットワークのアウトバウンドプロキシは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を静的に構成し、アウトバウンドプロキシの後ろにホームネットワーク内のプロキシを指すRouteヘッダーフィールドを追加できます。これはサービスルート機構と同じ効果を静的構成で実現します。
Jonathan Rosenberg Cisco Systems Edison, NJ US
Jonathan Rosenberg Cisco Systems Edison, NJ US
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net