[要約] RFC 5628は、SIPのグローバルにルーティング可能なユーザーエージェントURI（GRUU）のための登録イベントパッケージ拡張に関するものです。このRFCの目的は、GRUUを使用してSIPセッションを確立するための登録イベントの拡張を提供することです。
Network Working Group P. Kyzivat
Request for Comments: 5628 Cisco Systems, Inc.
Category: Standards Track October 2009
Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs)
セッション開始プロトコル（SIP）の登録イベントパッケージ拡張機能ルーティング可能なユーザーエージェントURIS（Gruus）
Abstract
概要
RFC 3680 defines a Session Initiation Protocol (SIP) event package for registration state. This package allows a watcher to learn about information stored by a SIP registrar, including its registered contact.
RFC 3680は、登録状態のセッション開始プロトコル（SIP）イベントパッケージを定義します。このパッケージにより、ウォッチャーは、登録された連絡先を含むSIPレジストラが保存している情報について学ぶことができます。
However, the registered contact is frequently unreachable and thus not useful for watchers. The Globally Routable User Agent URI (GRUU), defined in RFC 5627, is a URI that is capable of reaching a particular contact. However this URI is not included in the document format defined in RFC 3680. This specification defines an extension to the registration event package to include GRUUs assigned by the registrar.
ただし、登録された連絡先は頻繁に到達できないため、ウォッチャーには役に立ちません。RFC 5627で定義されているグローバルにルーティング可能なユーザーエージェントURI（GRUU）は、特定の連絡先に到達できるURIです。ただし、このURIはRFC 3680で定義されているドキュメント形式には含まれていません。この仕様は、登録イベントパッケージへの拡張機能を定義し、レジストラが割り当てたGruusを含む。
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、BSDライセンスに記載されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Notifier Processing of SUBSCRIBE Requests . . . . . . . . . . 4
5. Notifier Generation of NOTIFY Requests . . . . . . . . . . . . 4
6. Subscriber Processing of NOTIFY Requests . . . . . . . . . . . 5
6.1. Managing Temporary GRUU Lifetime . . . . . . . . . . . . . 5
7. Sample reginfo Document . . . . . . . . . . . . . . . . . . . 7
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Example: Welcome Notice . . . . . . . . . . . . . . . . . 8
8.2. Example: Implicit Registration . . . . . . . . . . . . . . 8
9. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 12
10.2. XML Schema Registration . . . . . . . . . . . . . . . . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . . 14
RFC 3680 [2] defines a Session Initiation Protocol (SIP) [5] event package for registration state. This package allows a watcher to learn about information stored by a SIP registrar, including the registered contacts.
RFC 3680 [2]は、登録状態のセッション開始プロトコル（SIP）[5]イベントパッケージを定義します。このパッケージにより、ウォッチャーは、登録された連絡先を含むSIPレジストラが保存している情報について学ぶことができます。
However, a registered contact is frequently unreachable from hosts outside of the domain of the User Agent (UA). It is commonly a private address, or, when it is a public address, access to it may be blocked by firewalls.
ただし、登録された連絡先は、ユーザーエージェント（UA）のドメインの外側のホストから到達できないことがよくあります。通常、プライベートアドレスであるか、公開住所の場合、ファイアウォールによってアクセスがブロックされる場合があります。
The Globally Routable User Agent URI (GRUU), defined in RFC 5627 [3], is a URI that reaches a particular UA instance, but is reachable by any host on the Internet. GRUUs assigned by the registrar represent additional registration state. However, GRUUs assigned by the registrar are not included in the notifications provided by RFC 3680. For many applications of the registration event package, a GRUU is needed, and not the registered contact.
RFC 5627 [3]で定義されているグローバルなルーティング可能なユーザーエージェントURI（GRUU）は、特定のUAインスタンスに到達するが、インターネット上のどのホストが到達できるURIです。レジストラによって割り当てられたGruusは、追加の登録状態を表します。ただし、レジストラによって割り当てられたGruusは、RFC 3680が提供する通知には含まれていません。登録イベントパッケージの多くのアプリケーションには、登録された連絡先ではなくGruuが必要です。
For example, the Welcome Notices example in [2] will only operate correctly if the contact address in the registration event notification is reachable by the sender of the welcome notice. When the registering device is using the GRUU extension, it is likely that the registered contact address will not be globally addressable, and a GRUU should be used as the target address for the MESSAGE.
たとえば、[2]の歓迎通知の例は、登録イベント通知の連絡先住所が歓迎通知の送信者が到達できる場合にのみ正しく動作します。登録デバイスがGruu拡張機能を使用している場合、登録された連絡先アドレスがグローバルにアドレス指定できない可能性があり、Gruuはメッセージのターゲットアドレスとして使用する必要があります。
Another case where this feature may be helpful is within the Third Generation Partnership Project (3GPP) IP Multimedia Subsystem (IMS). IMS employs a technique where a REGISTER of a contact address to one Address of Record (AOR) causes the implicit registration of the same contact to other associated AORs. If GRUUs are requested and obtained as part of the registration request, then additional GRUUs will also be needed for the implicit registrations. While assigning the additional GRUUs is straightforward, informing the registering UA of them is not. In IMS, UAs typically subscribe to the registration event, and subscriptions to the registration event for an AOR result in notifications, each containing the registration state of all the associated AORs. The proposed extension provides a way to easily deliver the GRUUs for the associated AORs.
この機能が役立つ可能性のある別のケースは、第3世代パートナーシッププロジェクト（3GPP）IPマルチメディアサブシステム（IMS）内にあります。IMSは、連絡先アドレスのレジスタが1つのレコードアドレス（AOR）へのレジスタが他の関連するAORに同じ連絡先を暗黙的に登録することを採用しています。Gruusが登録要求の一部として要求され、取得された場合、暗黙の登録には追加のGruusも必要になります。追加のGruusを割り当てるのは簡単ですが、それらの登録UAに通知することはそうではありません。IMSでは、UASは通常、登録イベントを購読し、AORの結果の登録イベントへの購読は、それぞれが関連するすべてのAORの登録状態を含みます。提案された拡張機能は、関連するAORのグルーを簡単に配信する方法を提供します。
As specified in RFC 5627 [3], temporary GRUUs are invalidated when contact address bindings for the corresponding AOR and instance ID are not refreshed, or when a registration to the AOR and instance ID is performed with a new Call-ID. A UA cannot always determine with certainty which temporary GRUUs are valid based solely on the response to the REGISTER requests it has issued, or from notifications according to RFC 3680 [2]. The extension defined in this document provides sufficient information for a UA to determine which temporary GRUUs are valid.
RFC 5627 [3]で指定されているように、対応するAORおよびインスタンスIDの連絡先アドレスバインディングが更新されない場合、またはAORへの登録とインスタンスIDへの登録が新しいCall-IDで実行される場合、一時的なグルーが無効になります。UAは、一時的なグルーが発行したレジスタリクエストへの応答のみに基づいて、またはRFC 3680 [2]に従って通知からのみに基づいて有効であるかを常に確実に決定することは常にできません。このドキュメントで定義されている拡張機能は、UAに十分な情報を提供して、どの一時的なグルーが有効であるかを判断します。
The registration event package has provisions for including extension elements within the <contact> element. This document defines new elements that may be used in that context to deliver the public and temporary GRUUs corresponding to the contact.
登録イベントパッケージには、<contact>要素に拡張要素を含めるための規定があります。このドキュメントでは、連絡先に対応する一般および一時的なグルーを提供するために、そのコンテキストで使用できる新しい要素を定義します。
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. [1]
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC2119で説明されているように解釈される。[1]
Two new elements (<pub-gruu> and <temp-gruu>) are defined, each of which contains a GRUU. The <temp-gruu> element also identifies the oldest temporary GRUU that is currently valid.
2つの新しい要素（<pub-gruu>および<temp-gruu>）が定義されており、それぞれにグルーが含まれています。<temp-gruu>要素は、現在有効な最も古い一時的なグルーも識別します。
These optional elements may be included within the body of a NOTIFY for the registration event package when GRUUs are associated with the contact. The contact URI and the GRUUs are then all available to the watcher.
これらのオプションの要素は、Gruusが連絡先に関連付けられている場合、登録イベントパッケージの通知の本文に含まれる場合があります。連絡先URIとGruusはすべてウォッチャーが利用できます。
Unchanged from RFC 3680 [2].
RFC 3680から変更されていません[2]。
A notifier for the registration event package [2] SHOULD include the <pub-gruu> element when a contact has an instance ID and a public GRUU is associated with the combination of the AOR and the instance ID. When present, the <pub-gruu> element MUST be positioned as a child of the <contact> element.
登録イベントパッケージ[2]の通知者には、連絡先にインスタンスIDがあり、パブリックGruuがAORとインスタンスIDの組み合わせに関連付けられている場合、<Pub-Gruu>要素を含める必要があります。存在する場合、<pub-gruu>要素は<contact>要素の子として配置する必要があります。
A notifier for the registration event package [2] MAY include the <temp-gruu> element when a contact has an instance ID and a temporary GRUU is associated with the combination of the AOR and the instance ID. This element SHOULD be included if the subscriber is also authorized to register to the AOR. This element SHOULD NOT be included if the subscriber is not authorized to register to the AOR, unless there is an explicitly configured policy directing that it be included. When present, the <temp-gruu> element MUST be positioned as a child of the <contact> element.
登録イベントパッケージ[2]の紹介者には、連絡先にインスタンスIDがあり、一時的なGruuがAORとインスタンスIDの組み合わせに関連付けられている場合、<Temp-Gruu>要素が含まれます。サブスクライバーがAORに登録することが許可されている場合は、この要素を含める必要があります。サブスクライバーがAORに登録する権限がない場合は、この要素を含めてはなりません。存在する場合、<temp-gruu>要素は<contact>要素の子として配置する必要があります。
Note that it is possible for multiple registered contacts to share the same instance ID. In such a case, each <contact> element will have child <pub-gruu> and <temp-gruu> elements, which are identical to the corresponding child elements in those other <contact> elements that share the same instance ID. Since a particular contact cannot be associated with more than one instance ID, a <contact> element will never have more than one <pub-gruu> and one <temp-gruu> child element.
複数の登録された連絡先が同じインスタンスIDを共有できることに注意してください。そのような場合、各<コンタクト>要素には、同じインスタンスIDを共有する他の<コンタクト>要素の対応する子要素と同一の子<pub-gruu>および<temp-gruu>要素があります。特定の連絡先を複数のインスタンスIDに関連付けることはできないため、<contact>要素は<pub-gruu>と1つの<temp-gruu>要素を1つ以上持つことはありません。
If the notifier includes the <pub-gruu> element, it MUST populate the element with the public GRUU that is associated with the instance ID and AOR of the registered contact.
Notifierに<Pub-Gruu>要素が含まれている場合、登録された連絡先のインスタンスIDとAORに関連付けられているパブリックグルーに要素を入力する必要があります。
If the notifier includes the <temp-gruu> element, it MUST populate the element with the most recently assigned temporary GRUU that is associated with the instance ID and AOR of the registered contact. It MUST also populate the element with a "cseq" attribute corresponding to the first (oldest) currently active temporary GRUU that is associated with the instance ID and AOR of the registered contact. The value of the "cseq" attribute is set to the value of the CSeq header field of the REGISTER request that caused that first temporary GRUU to be assigned.
通知者に<temp-gruu>要素が含まれている場合、登録された連絡先のインスタンスIDとAORに関連付けられている最近割り当てられた一時的なGruuに要素を入力する必要があります。また、登録された連絡先のインスタンスIDとAORに関連付けられている、現在アクティブな最初の（最古の）一時的なGruuに対応する「CSEQ」属性を要素に入力する必要があります。「CSEQ」属性の値は、最初の一時的なグルーが割り当てられたレジスタリクエストのCSEQヘッダーフィールドの値に設定されます。
When a subscriber receives a registration event notification with a <contact> containing a <pub-gruu>, it MAY associate the public GRUU with the corresponding AOR and instance ID. Any previously received public GRUU for the same AOR and instance ID MUST be discarded. (It will no longer function.)
サブスクライバーが<pub-gruu>を含むa <contact>を使用して登録イベント通知を受信すると、Public Gruuを対応するAORおよびインスタンスIDに関連付けることができます。同じAORおよびインスタンスIDについて以前に受け取った公開Gruuを破棄する必要があります。（機能しなくなります。）
When a subscriber receives a registration event notification with a <contact> containing a <temp-gruu>, it MAY associate the temporary GRUU, together with the "callid" and "cseq" attributes, with the corresponding AOR and instance ID.
サブスクライバーが<temp-gruu>を含むa <contact>を使用して登録イベント通知を受信すると、「CallID」および「CSEQ」属性と、対応するAORおよびインスタンスIDとともに、一時的なグルーを関連付けることができます。
Subscribers that are unaware of this extension will, as required by [2], ignore the <pub-gruu> and <temp-gruu> elements.
この拡張機能に気付いていない加入者は、[2]で要求されているように、<pub-gruu>および<temp-gruu>要素を無視します。
Section 4.2 of RFC 5627 [3] gives guidance for developers of UAs on how to ensure that only valid temporary GRUUs are retained and used by the UA. A UA cannot always determine with certainty which temporary GRUUs are valid based solely on the information contained in responses to the REGISTER requests it has issued or from the information contained in notifications that conform solely to RFC 3680 [2]. The extension defined in this document provides sufficient added information for a UA to determine which temporary GRUUs are valid. The extension to RFC 3680 defined in this document provides added information to help with that process. The following are steps that the UA MAY take to ensure it only retains valid GRUUs:
RFC 5627 [3]のセクション4.2 [3]は、UAの開発者に、有効な一時的なグルーのみが保持され、UAによって使用されることを確認する方法についてのガイダンスを提供します。UAは、発行したレジスタリクエストへの応答に含まれる情報のみに基づいて、またはRFC 3680のみに適合する通知に含まれる情報からのみに基づいて、一時的なグルーが有効であるかを常に確実に決定することは常に確実ではありません[2]。このドキュメントで定義されている拡張機能は、UAに十分な追加情報を提供して、どの一時的なグルーが有効であるかを判断します。このドキュメントで定義されているRFC 3680の拡張機能は、そのプロセスを支援するための追加情報を提供します。以下は、UAが有効なグルーのみを保持するために取ることができる手順です。
o The UA should subscribe to the registration event package for the AOR it is registering.
o UAは、登録しているAORの登録イベントパッケージを購読する必要があります。
o When a UA receives a 2xx response to a REGISTER request, it may extract and retain temporary GRUUs from the response for future use, as long as they remain valid. Appropriate GRUUs to retain are those corresponding to the contact address and instance ID it has registered. (Typically, the UA will register only one contact address, and so receive at most one temporary GRUU.)
o UAがレジスタリクエストに対する2xx応答を受信すると、有効なままである限り、将来の使用のために一時的なグルーを抽出して保持することができます。保持する適切なgruusは、登録した連絡先アドレスとインスタンスIDに対応するものです。（通常、UAは1つの連絡先アドレスのみを登録するため、最大で一時的なGruuを受け取ります。）
o The UA may add the temporary GRUU to the set of valid temporary GRUUs associated with the AOR. (Note, in this case AOR is the To-address of the REGISTER request.) To aid in tracking validity, the UA should also associate a "callid" attribute and "cseq" attribute with the temporary GRUU, with values obtained respectively from the Call-ID and CSeq values of the REGISTER response containing the temporary GRUU.
o UAは、AORに関連付けられた有効な一時的なグルーのセットに一時的なグルーを追加する場合があります。（この場合、AORはレジスタリクエストのアドレスです。）有効性の追跡を支援するために、UAは「CallID」属性と「CSEQ」属性を一時的なGruuに関連付け、それぞれから取得した値と関連する必要があります。一時的なグルーを含むレジスタ応答のコールIDおよびCSEQ値。
o If the UA receives a registration event notification with an AOR (that it supports) and a <contact>, for a contact address and instance ID (that it has registered and that contains a <temp-gruu>), it may update its set of valid temporary GRUUs associated with the AOR, as follows:
o UAが、連絡先アドレスとインスタンスID（登録されており、<temp-gruu>を含む）のAOR（サポート）と<連絡先>を使用して登録イベント通知を受け取った場合、セットを更新する場合があります次のように、AORに関連付けられた有効な一時的なグルーの：
* It may add the temporary GRUU to the set. To aid in tracking validity, the UA should associate the "callid" and "cseq" attributes of the <contact> with the GRUU in the set.
* 一時的なグルーをセットに追加する場合があります。妥当性の追跡を支援するために、UAはセットの「CallID」および「CSEQ」属性を<contact>のgruuに関連付ける必要があります。
* It should remove any temporary GRUUs with a "callid" attribute value different from that in the value of the "callid" attribute of the <contact>, or with a "cseq" attribute with value less than the value of the "first-cseq" attribute of the <temp-gruu>.
* <contact>の「callid」属性の値とは異なる「callid」属性値で一時的なグルーを削除する必要があります。「<temp-gruu>の属性。
o If the UA receives a registration event notification with an AOR that it supports, and there are no <contact> entries for its instance ID, then it should discard all the temporary GRUUs it has saved for that AOR.
o UAがサポートするAORを使用して登録イベント通知を受け取り、インスタンスIDに<contact>エントリがない場合、そのaorのために保存したすべての一時的なグルーを破棄する必要があります。
Note: This example and others in the following section are indented for readability by the addition of a fixed amount of whitespace to the beginning of each line. This whitespace is not part of the example. The conventions of [7] are used to describe representation of long message lines.
注：次のセクションのこの例やその他は、各ラインの開始に固定量の白人を追加することにより、読みやすさのためにインデントされます。このホワイトスペースは例の一部ではありません。[7]の規則は、長いメッセージ行の表現を説明するために使用されます。
The following is an example registration information document that includes the new element:
以下は、新しい要素を含む登録情報ドキュメントの例です。
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
xmlns:gr="urn:ietf:params:xml:ns:gruuinfo"
version="0" state="full">
<registration aor="sip:user@example.com" id="as9"
state="active">
<contact id="76" state="active" event="registered"
duration-registered="36001" expires="3599"
callid="1j9FpLxk3uxtm8tn@192.0.2.1" cseq="54321"
q="0.8">
<uri>sip:user@192.0.2.1</uri>
<allOneLine>
<unknown-param name="+sip.instance">
"<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
</unknown-param>
</allOneLine>
<allOneLine>
<gr:pub-gruu uri="sip:user@example.com
;gr=hha9s8d-999a"/>
</allOneLine>
<allOneLine>
<gr:temp-gruu uri="sip:8ffkas08af7fasklzi9@example.com
;gr" first-cseq="54301"/>
</allOneLine>
</contact>
</registration>
</reginfo>
Note: In the following examples, the SIP messages have been simplified, removing headers that are not pertinent to the example.
注：次の例では、SIPメッセージが簡素化されており、例には関係のないヘッダーが削除されています。
When the value of the Content-Length header field is "...", this means that the value should be the computed length of the body.
コンテンツ長ヘッダーフィールドの値が「...」の場合、これは値がボディの計算された長さであることを意味します。
Consider the Welcome Notices example in [2]. When the application server receives a notification of a new registration containing the reginfo shown in Section 7, it should address messages using the contained public GRUU as follows:
[2]の歓迎通知の例を考えてみましょう。アプリケーションサーバーがセクション7に示されているRegINFOを含む新しい登録の通知を受信する場合、次のように含まれるパブリックGruuを使用してメッセージに対応する必要があります。
MESSAGE sip:user@example.com;gr=hha9s8d-999a SIP/2.0
To: <sip:user@example.com>
From: "SIPland Notifier" <sip:notifier@example.com>;tag=7xy8
Content-Type: text/plain
Content-Length: ...
Welcome to SIPland! Blah, blah, blah.
Siplandへようこそ！何とか何とか何とか。
In a 3GPP IMS setting, a UA may send a single register message, requesting assignment of GRUUs, as follows:
3GPP IMS設定では、UAは単一のレジスタメッセージを送信し、次のようにGruusの割り当てを要求する場合があります。
REGISTER sip:example.net SIP/2.0
From: <sip:user_aor_1@example.net>;tag=5ab4
To: <sip:user_aor_1@example.net>
Call-ID: faif9a@ua.example.com
CSeq: 23001 REGISTER
Contact: <sip:ua.example.com>
;expires=3600
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
Supported: path, gruu
Content-Length: 0
The response reports success of the registration and returns the GRUUs assigned for the combination of AOR, instance ID, and Contact. It also indicates (via the P-Associated-URI header [6]) that there are two other associated AORs that may have been implicitly registered using the same contact. Each of those implicitly registered AORs will have unique GRUUs assigned. The REGISTER response will not include those GRUUs; it will only include the GRUUs for the AOR and instance ID explicitly included in the registration.
応答は、登録の成功を報告し、AOR、インスタンスID、および連絡先の組み合わせに割り当てられたグルーを返します。また、同じ接触を使用して暗黙的に登録されている可能性のある他の2つの関連するAORがあることを（p関連型Header [6]を介して）示しています。これらの暗黙的に登録されたAORのそれぞれには、一意のGruusが割り当てられます。レジスタの応答には、これらのグルーが含まれません。登録に明示的に含まれるAORおよびインスタンスIDのGruusのみが含まれます。
SIP/2.0 200 OK
From: <sip:user_aor_1@example.net>;tag=5ab4
To: <sip:user_aor_1@example.net>;tag=373392
Call-ID: faif9a@ua.example.com
CSeq: 23001 REGISTER
Path: <sip:proxy.example.net;lr>
Service-Route: <sip:proxy.example.net;lr>
Contact: <sip:ua.example.com>
;expires=3600
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;pub-gruu="sip:user_aor_1@example.net;gr=hha9s8d-999a"
;temp-gruu="sip:8ffkas08af7fasklzi9@example.net;gr"
P-Associated-URI: <sip:user_aor_2@example.net>,
<sip:+358504821437@example.net;user=phone>
Content-Length: 0
The UA then subscribes to the registration event package as follows:
UAは次のように登録イベントパッケージを購読します。
SUBSCRIBE sip:user_aor_1@example.net SIP/2.0
From: <sip:user_aor_1@example.net>;tag=27182
To: <sip:user_aor_1@example.net>
Call-ID: gbjg0b@ua.example.com
CSeq: 45001 SUBSCRIBE
Route: <sip:proxy.example.net;lr>
Event: reg
Expires: 3600
Accept: application/reginfo+xml
Contact: <sip:user_aor_1@example.net;gr=hha9s8d-999a>
Content-Length: 0
(The successful response to the subscription is not shown.) Once the subscription is established, an initial notification is sent giving registration status. In IMS deployments, the response includes, in addition to the status for the requested URI, the status for the other associated URIs.
（サブスクリプションに対する成功した応答は表示されません。）サブスクリプションが確立されると、登録ステータスを与える最初の通知が送信されます。IMSの展開では、応答には、要求されたURIのステータスに加えて、他の関連するURIのステータスが含まれます。
NOTIFY sip:user_aor_1@example.net;gr=hha9s8d-999a SIP/2.0
From: <sip:user_aor_1@example.net>;tag=27182
To: <sip:user_aor_1@example.net>;tag=262281
Call-ID: gbjg0b@ua.example.com
CSeq: 633 NOTIFY
Subscription-State: active;expires=3600
Event: reg
Content-Type: application/reginfo+xml
Contact: <sip:registrar.example.net>
Content-Length: ...
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
xmlns:gr="urn:ietf:params:xml:ns:gruuinfo"
version="1" state="full">
<registration aor="sip:user_aor_1@example.net" id="a7"
state="active">
<contact id="92" state="active" event="registered"
duration-registered="1" expires="3599"
callid="faif9a@ua.example.com" cseq="23001">
<uri>
sip:ua.example.com
</uri>
<allOneLine>
<unknown-param name="+sip.instance">
"<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
</unknown-param>
</allOneLine>
<allOneLine>
<gr:pub-gruu uri="sip:user_aor_1@example.net
;gr=hha9s8d-999a"/>
</allOneLine>
<allOneLine>
<gr:temp-gruu uri="sip:8ffkas08af7fasklzi9@example.net
;gr" first-cseq="54301"/>
</allOneLine>
</contact>
</registration>
<registration aor="sip:user_aor_2@example.net" id="a8"
state="active">
<contact id="93" state="active" event="created"
duration-registered="1" expires="3599"
callid="faif9a@ua.example.com" cseq="23001">
<uri>
sip:ua.example.com
</uri>
<allOneLine>
<unknown-param name="+sip.instance">
"<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
</unknown-param>
</allOneLine>
<allOneLine>
<gr:pub-gruu uri="sip:user_aor_2@example.net
;gr=hha9s8d-999b"/>
</allOneLine>
<allOneLine>
<gr:temp-gruu uri="sip:07hcovy36vp6vngvbia@example.net
;gr" first-cseq="54301"/>
</allOneLine>
</contact>
</registration>
<registration
aor="sip:+358504821437@example.net;user=phone"
id="a9"
state="active">
<contact id="94" state="active" event="created"
duration-registered="1" expires="3599"
callid="faif9a@ua.example.com" cseq="23001">
<uri>
sip:ua.example.com
</uri>
<allOneLine>
<unknown-param name="+sip.instance">
"<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
</unknown-param>
</allOneLine>
<allOneLine>
<gr:pub-gruu uri="sip:+358504821437@example.net
;user=phone;gr=hha9s8d-999c"/>
</allOneLine>
<allOneLine>
<gr:temp-gruu uri="sip:h99egjbv17fe8ibvlka@example.net
;gr" first-cseq="54301"/>
</allOneLine>
</contact>
</registration>
</reginfo>
The status indicates that the associated URIs all have the same contact registered. It also includes the unique GRUUs that have been assigned to each. The UA may then retain those GRUUs for use when establishing dialogs using the corresponding AORs.
ステータスは、関連するURIがすべて同じ連絡先が登録されていることを示します。また、それぞれに割り当てられたユニークなグルーも含まれています。UAは、対応するAORを使用してダイアログを確立するときに使用するためにこれらのグルーを保持する場合があります。
The <pub-gruu> and <temp-gruu> elements are defined within a new XML namespace URI. This namespace is "urn:ietf:params:xml:ns:gruuinfo". The schema for these elements is:
<pub-gruu>および<temp-gruu>要素は、新しいXMLネームスペースURI内で定義されています。この名前空間は「urn：ietf：params：xml：ns：gruuinfo」です。これらの要素のスキーマは次のとおりです。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:gruuinfo"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:gruuinfo">
<xs:complexType name="pubGruu">
<xs:attribute name="uri" type="xs:anyURI"
use="required"/>
</xs:complexType>
<xs:complexType name="tempGruu">
<xs:complexContent>
<xs:extension base="tns:pubGruu">
<xs:attribute name="first-cseq"
type="xs:unsignedLong"
use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="pub-gruu" type="tns:pubGruu"/>
<xs:element name="temp-gruu" type="tns:tempGruu"/>
</xs:schema>
There are two IANA considerations associated with this specification.
この仕様に関連する2つのIANAの考慮事項があります。
This section registers a new XML namespace, per the guidelines in [4].
このセクションでは、[4]のガイドラインに従って、新しいXML名前空間を登録します。
URI: The URI for this namespace is urn:ietf:params:xml:ns:gruuinfo
Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>,
Paul Kyzivat <pkyzivat@cisco.com>
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Reg Information GRUU Extension Namespace</title>
</head>
<body>
<h1>Namespace for Reg Information GRUU Extension</h1>
<h2>urn:ietf:params:xml:ns:gruuinfo</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc5628.txt">
RFC5628</a>.</p>
</body>
</html>
END
This section registers an XML schema per the procedures in [4].
このセクションでは、[4]の手順ごとにXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:gruuinfo.
uri：urn：ietf：params：xml：schema：gruuinfo。
Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>,
Paul Kyzivat <pkyzivat@cisco.com>
The XML for this schema can be found in Section 9.
このスキーマのXMLは、セクション9にあります。
Security considerations for the registration event package are discussed in RFC 3680 [2], and those considerations apply here.
登録イベントパッケージのセキュリティ上の考慮事項は、RFC 3680 [2]で説明されており、これらの考慮事項はここで適用されます。
If a contact address obtained via subscription to the registration event package is not reachable by the subscriber, then its disclosure may arguably be considered a minimal security risk. In that case, the inclusion of a GRUU may be considered to increase the risk by providing a reachable address. On the other hand, requests addressed to a GRUU are always first processed by the servicing proxy before they reach the intended User Agent. The proxy may control access as desired, just as it may for the AOR. For instance, the proxy servicing a GRUU may accept requests from senders whose identity appears on a white list, and reject other requests. In this respect, disclosing a GRUU presents no more risk than disclosing the AOR.
登録イベントパッケージへのサブスクリプションを介して取得された連絡先アドレスがサブスクライバーが到達できない場合、その開示は間違いなく最小限のセキュリティリスクと見なされる可能性があります。その場合、Gruuを含めることは、到達可能な住所を提供することにより、リスクを増加させると考えるかもしれません。一方、Gruuに宛てられたリクエストは、意図したユーザーエージェントに到達する前に、常にサービスプロキシによって最初に処理されます。プロキシは、AORの場合と同じように、必要に応じてアクセスを制御できます。たとえば、Gruuにサービスを提供するプロキシは、白いリストにIDが表示されている送信者からのリクエストを受け入れ、他のリクエストを拒否する場合があります。この点で、Gruuを開示することは、AORを開示するよりもリスクをもたらさない。
Temporary GRUUs have an additional security consideration. The intent of the temporary GRUU is to provide a contact address that cannot be correlated to the identity of the calling party. The recipient of a call using a temporary GRUU may guess the identity of the calling party and then attempt to obtain the temporary GRUUs assigned to that caller to confirm the conjecture. Two possible approaches to obtaining the temporary GRUUs are:
一時的なGruusには追加のセキュリティ検討があります。一時的なグルーの意図は、呼び出し当事者の身元と相関することができない連絡先アドレスを提供することです。一時的なグルーを使用したコールの受信者は、呼び出し当事者の身元を推測し、その発信者に割り当てられた一時的なグルーを取得して推測を確認することを試みることができます。一時的なグルーを取得するための2つの可能なアプローチは次のとおりです。
o Send a REGISTER request to a conjectured caller.
o 推測された発信者にレジスタリクエストを送信します。
o Send a SUBSCRIBE request for the registration event package to the conjectured caller.
o 登録イベントパッケージの購読リクエストを推測した発信者に送信します。
Typically, REGISTER is restricted to devices or users that are authorized to originate and receive calls with the AOR. Anonymity among users of the same AOR is hard to achieve and typically unnecessary. It is recommended (see Section 5) that the authorization policy for the registration event package permit only those subscribers who are authorized to register to the AOR to receive temporary GRUUs. With this policy, the confidentiality of the temporary GRUU will be the same with and without the registration event package. User Agents that use a temporary GRUU should note that confidentiality does not extend to parties that are permitted to register to the AOR or to obtain the temporary GRUU when subscribing to the registration event package.
通常、レジスタは、AORで発信および通話を受信することが許可されているデバイスまたはユーザーに制限されています。同じAORのユーザー間の匿名性は達成が難しく、通常は不要です。登録イベントパッケージの承認ポリシーは、AORに登録することを許可されている加入者のみが一時的なグルーを受け取ることを許可することを推奨されます（セクション5を参照）。このポリシーでは、一時的なグルーの機密性は、登録イベントパッケージの有無にかかわらず同じになります。一時的なGruuを使用するユーザーエージェントは、登録イベントパッケージを購読する際にAORに登録することを許可されているか、一時的なGruuを取得することが許可されている当事者に守備力が拡大しないことに注意する必要があります。
The author would like to thank Jonathan Rosenberg for help with this document, and Jari Urpalainen for assistance with the XML.
著者は、この文書の支援についてJonathan RosenbergとXMLの支援についてJari Urpalainenに感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[2] Rosenberg、J。、「登録のためのセッション開始プロトコル（SIP）イベントパッケージ」、RFC 3680、2004年3月。
[3] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[3] Rosenberg、J。、「セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザーエージェント（UA）URIS（GRUU）を取得および使用する」、RFC 5627、2009年10月。
[4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[4] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[5] 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.
[5] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INITIATION Protocol」、RFC 3261、2002年6月。
[6] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", RFC 3455, January 2003.
[6] Garcia-Martin、M.、Henrikson、E。、およびD. Mills、「第3世代パートナーシッププロジェクト（3GPP）のセッション開始プロトコル（SIP）へのプライベートヘッダー（P-Header）拡張」、RFC 3455、1月2003年。
[7] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.
[7] Sparks、R.、Hawrylyshen、A.、Johnston、A.、Rosenberg、J。、およびH. Schulzrinne、「セッション開始プロトコル（SIP）拷問テストメッセージ」、RFC 4475、2006年5月。
Author's Address
著者の連絡先
Paul H. Kyzivat Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA
Paul H. Kyzivat Cisco Systems、Inc。1414 Massachusetts Avenue Boxborough、MA 01719 USA
EMail: pkyzivat@cisco.com