[要約] RFC 3680は、SIPイベントパッケージの1つであるRegistrationsに関する仕様を提供しています。このRFCの目的は、SIPサーバーが登録情報の変更を通知するための効果的なメカニズムを提供することです。
Network Working Group J. Rosenberg
Request for Comments: 3680 dynamicsoft
Category: Standards Track March 2004
A Session Initiation Protocol (SIP) Event Package for Registrations
登録用のセッション開始プロトコル（SIP）イベントパッケージ
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
Abstract
概要
This document defines a Session Initiation Protocol (SIP) event package for registrations. Through its REGISTER method, SIP allows a user agent to create, modify, and delete registrations. Registrations can also be altered by administrators in order to enforce policy. As a result, these registrations represent a piece of state in the network that can change dynamically. There are many cases where a user agent would like to be notified of changes in this state. This event package defines a mechanism by which those user agents can request and obtain such notifications.
このドキュメントでは、登録用のセッション開始プロトコル（SIP）イベントパッケージを定義します。登録方法を使用すると、SIPを使用すると、ユーザーエージェントが登録を作成、変更、削除できます。ポリシーを実施するために、登録を管理者によって変更することもできます。その結果、これらの登録は、動的に変化する可能性のあるネットワーク内の状態を表しています。ユーザーエージェントがこの状態の変更を通知したい場合がたくさんあります。このイベントパッケージは、それらのユーザーエージェントがそのような通知を要求して取得できるメカニズムを定義します。
Table of Contents
目次
1. Introduction ................................................. 2
2. Terminology .................................................. 3
3. Usage Scenarios .............................................. 3
3.1. Forcing Re-Authentication .............................. 3
3.2. Composing Presence ..................................... 3
3.3. Welcome Notices ........................................ 4
4. Package Definition ........................................... 4
4.1. Event Package Name ..................................... 4
4.2. Event Package Parameters ............................... 5
4.3. SUBSCRIBE Bodies ....................................... 5
4.4. Subscription Duration .................................. 5
4.5. NOTIFY Bodies .......................................... 6
4.6. Notifier Processing of SUBSCRIBE Requests .............. 6
4.7. Notifier Generation of NOTIFY Requests ................. 7
4.7.1. The Registration State Machine ................. 7
4.7.2. Applying the state machine ..................... 9
4.8. Subscriber Processing of NOTIFY Requests ............... 9
4.9. Handling of Forked Requests ............................ 9
4.10. Rate of Notifications .................................. 10
4.11. State Agents ........................................... 10
5. Registration Information ..................................... 10
5.1. Structure of Registration Information .................. 10
5.2. Computing Registrations from the Document .............. 14
5.3. Example ................................................ 15
5.4. XML Schema ............................................. 16
6. Example Call Flow ............................................ 18
7. Security Considerations ...................................... 21
8. IANA Considerations .......................................... 21
8.1. SIP Event Package Registration ......................... 21
8.2. application/reginfo+xml MIME Registration .............. 22
8.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:reginfo ......................... 23
9. References ................................................... 23
9.1. Normative References ................................... 23
9.2. Informative References ................................. 24
10. Contributors ................................................. 25
11. Acknowledgements ............................................. 25
12. Author's Address ............................................. 25
13. Full Copyright Statement ..................................... 26
The Session Initiation Protocol (SIP) [1] provides all of the functions needed for the establishment and maintenance of communications sessions between users. One of the functions it provides is a registration operation. A registration is a binding between a SIP URI, called an address-of-record, and one or more contact URIs. These contact URIs represent additional resources that can be contacted in order to reach the user identified by the address-of-record. When a proxy receives a request within its domain of administration, it uses the Request-URI as an address-of-record, and uses the contacts bound to the address-of-record to forward (or redirect) the request.
セッション開始プロトコル（SIP）[1]は、ユーザー間の通信セッションの確立とメンテナンスに必要なすべての機能を提供します。それが提供する機能の1つは、登録操作です。登録とは、録音住所と呼ばれるSIP URIと1つ以上の連絡先URIの間の拘束力があります。これらの連絡先は、録音アドレスによって識別されたユーザーに到達するために連絡できる追加のリソースを表します。プロキシが管理領域内でリクエストを受信すると、リクエスト-URIを記録アドレスとして使用し、要求を転送（またはリダイレクト）するためにレコードアドレスにバインドされた連絡先を使用します。
The SIP REGISTER method provides a way for a user agent to manipulate registrations. Contacts can be added or removed, and the current set of contacts can be queried. Registrations can also change as a result of administrator policy. For example, if a user is suspected of fraud, their registration can be deleted so that they cannot receive any requests. Registrations also expire after some time if not refreshed.
SIPレジスタメソッドは、ユーザーエージェントが登録を操作する方法を提供します。連絡先を追加または削除することができ、現在の連絡先のセットを照会できます。登録は、管理者ポリシーの結果としても変更される可能性があります。たとえば、ユーザーが詐欺の疑いがある場合、リクエストを受け取ることができないように登録を削除できます。登録は、更新されないとしばらくすると期限切れになります。
Registrations represent a dynamic piece of state maintained by the network. There are many cases in which user agents would like to know about changes to the state of registrations. The SIP Events Framework [2] defines a generic framework for subscription to, and notification of, events related to SIP systems. The framework defines the methods SUBSCRIBE and NOTIFY, and introduces the notion of a package. A package is a concrete application of the event framework to a particular class of events. Packages have been defined for user presence [9], for example. This specification defines a package for registration state.
登録は、ネットワークによって維持される動的な状態を表しています。ユーザーエージェントが登録状態の変更について知りたいと思う多くのケースがあります。SIPイベントフレームワーク[2]は、SIPシステムに関連するイベントへのサブスクリプションおよび通知の一般的なフレームワークを定義します。フレームワークは、サブスクライブと通知のメソッドを定義し、パッケージの概念を導入します。パッケージは、特定のクラスのイベントへのイベントフレームワークの具体的なアプリケーションです。たとえば、ユーザーの存在[9]のパッケージは定義されています。この仕様は、登録状態のパッケージを定義します。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [3] and indicate requirement levels for compliant implementations.
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"BCP 14、RFC 2119 [3]で説明されているように解釈され、準拠の実装の要件レベルを示します。
There are many applications of this event package. A few are documented here for illustrative purposes.
このイベントパッケージには多くのアプリケーションがあります。いくつかは、説明のためにここに文書化されています。
It is anticipated that many SIP devices will be wireless devices that will be always-on, and therefore, continually registered to the network. Unfortunately, history has shown that these devices can be compromised. To deal with this, an administrator will want to terminate or shorten a registration, and ask the device to re-register so it can be re-authenticated. To do this, the device subscribes to the registration event package for the address-of-record that it is registering contacts against. When the administrator shortens registration (for example, when fraud is suspected) the registration server sends a notification to the device. It can then re-register and re-authenticate itself. If it cannot re-authenticate, the expiration will terminate shortly thereafter.
多くのSIPデバイスは、常にオンになるワイヤレスデバイスであるため、ネットワークに継続的に登録されることが予想されます。残念ながら、履歴は、これらのデバイスが妥協できることを示しています。これに対処するために、管理者は登録を終了または短縮し、デバイスに再登録するように依頼する必要があります。これを行うために、デバイスは、連絡先を登録しているレコードアドレスの登録イベントパッケージを購読します。管理者が登録を短くすると（たとえば、詐欺が疑われるとき）、登録サーバーはデバイスに通知を送信します。その後、自体を再登録して再認可できます。再認識できない場合、その後すぐに有効期限が終了します。
An important concept to understand is the relationship between this event package and the event package for user presence [9]. User presence represents the willingness and ability of a user to communicate with other users on the network. It is composed of a set of contact addresses that represent the various means for contacting the user. Those contact addresses might represent the contact address for voice, for example. Typically, the contact address listed for voice will be an address-of-record. The status of that contact (whether its open or closed) may depend on any number of factors, including the state of any registrations against that address-of-record. As a result, registration state can be viewed as an input to the process which determines the presence state of a user. Effectively, registration state is "raw" data, which is combined with other information about a user to generate a document that describes the user's presence.
理解すべき重要な概念は、このイベントパッケージとユーザープレゼンスのためのイベントパッケージとの関係です[9]。ユーザーの存在は、ネットワーク上の他のユーザーと通信するユーザーの意欲と能力を表します。これは、ユーザーに連絡するためのさまざまな手段を表す一連の連絡先アドレスで構成されています。これらの連絡先アドレスは、たとえば音声の連絡先アドレスを表す場合があります。通常、音声用にリストされている連絡先アドレスは、住所になります。その連絡先のステータス（オープンであろうと閉じているかどうか）は、その記録アドレスに対する登録の状態を含む、任意の数の要因に依存する場合があります。その結果、登録状態は、ユーザーの存在状態を決定するプロセスへの入力と見なすことができます。事実上、登録状態は「生」データであり、ユーザーの存在を説明するドキュメントを生成するためにユーザーに関する他の情報と組み合わされています。
In fact, this event package allows for a presence server to be separated from a SIP registration server, yet still use registration information to construct a presence document. When a presence server receives a presence subscription for some user, the presence server itself would generate a subscription to the registration server for the registration event package. As a result, the presence server would learn about the registration state for that user, and it could use that information to generate presence documents.
実際、このイベントパッケージを使用すると、SIP登録サーバーから存在感サーバーを分離できますが、登録情報を使用してプレゼンスドキュメントを作成できます。プレゼンスサーバーが一部のユーザーのプレゼンスサブスクリプションを受信すると、プレゼンスサーバー自体は登録イベントパッケージの登録サーバーのサブスクリプションを生成します。その結果、プレゼンスサーバーはそのユーザーの登録状態について学習し、その情報を使用してプレゼンスドキュメントを生成することができます。
A common service in current mobile networks are "welcome notices". When the user turns on their phone in a foreign country, they receive a message that welcomes them to the country, and provides information on transportation services, for example.
現在のモバイルネットワークの一般的なサービスは「歓迎の通知」です。ユーザーが外国の電話をオンにすると、たとえば国に歓迎するメッセージを受け取り、たとえば輸送サービスに関する情報を提供します。
In order to implement this service in a SIP system, an application server can subscribe to the registration state of the user. When the user turns on their phone, the phone will generate a registration. This will result in a notification being sent to the application that the user has registered. The application can then send a SIP MESSAGE request [10] to the device, welcoming the user and providing any necessary information.
このサービスをSIPシステムに実装するために、アプリケーションサーバーはユーザーの登録状態を購読できます。ユーザーが電話をオンにすると、電話は登録を生成します。これにより、ユーザーが登録したアプリケーションに通知が送信されます。アプリケーションは、SIPメッセージリクエスト[10]をデバイスに送信し、ユーザーを歓迎し、必要な情報を提供できます。
This section fills in the details needed to specify an event package as defined in Section 4.4 of [2].
このセクションでは、[2]のセクション4.4で定義されているイベントパッケージを指定するために必要な詳細を記入します。
The SIP Events specification requires package definitions to specify the name of their package or template-package.
SIPイベントの仕様では、パッケージまたはテンプレートパッケージの名前を指定するためのパッケージ定義が必要です。
The name of this package is "reg". As specified in [2], this value appears in the Event header present in SUBSCRIBE and NOTIFY requests.
このパッケージの名前は「reg」です。[2]で指定されているように、この値は、購読および通知リクエストに存在するイベントヘッダーに表示されます。
Example:
例：
Event: reg
イベント：reg
The SIP Events specification requires package and template-package definitions to specify any package specific parameters of the Event header that are used by it.
SIPイベント仕様には、使用されるイベントヘッダーのパッケージ固有のパラメーターを指定するためのパッケージとテンプレートパッケージ定義が必要です。
No package specific Event header parameters are defined for this event package.
このイベントパッケージには、パッケージ固有のイベントヘッダーパラメーターは定義されていません。
The SIP Events specification requires package or template-package definitions to define the usage, if any, of bodies in SUBSCRIBE requests.
SIPイベントの仕様では、サブスクライブリクエストのボディの使用法を定義するために、パッケージまたはテンプレートパッケージ定義が必要です。
A SUBSCRIBE for registration events MAY contain a body. This body would serve the purpose of filtering the subscription. The definition of such a body is outside the scope of this specification.
登録イベントの購読にはボディが含まれている場合があります。この本体は、サブスクリプションをフィルタリングする目的に役立ちます。そのような身体の定義は、この仕様の範囲外です。
A SUBSCRIBE for the registration package MAY be sent without a body. This implies that the default registration filtering policy has been requested. The default policy is:
登録パッケージの購読は、ボディなしで送信される場合があります。これは、デフォルトの登録フィルタリングポリシーが要求されたことを意味します。デフォルトのポリシーは次のとおりです。
o Notifications are generated every time there is any change in the state of any of the registered contacts for the resource being subscribed to. Those notifications only contain information on the contacts whose state has changed.
o サブスクライブされているリソースの登録された連絡先の状態に変更があるたびに通知が生成されます。これらの通知には、状態が変更された連絡先に関する情報のみが含まれています。
o Notifications triggered from a SUBSCRIBE contain full state (the list of all contacts bound to the address-of-record).
o サブスクライブからトリガーされた通知には、完全な状態が含まれています（記録アドレスにバインドされたすべての連絡先のリスト）。
Of course, the server can apply any policy it likes to the subscription.
もちろん、サーバーはサブスクリプションに好きなポリシーを適用できます。
The SIP Events specification requires package definitions to define a default value for subscription durations, and to discuss reasonable choices for durations when they are explicitly specified.
SIPイベントの仕様では、サブスクリプション期間のデフォルト値を定義し、明示的に指定された期間の合理的な選択肢を議論するために、パッケージ定義が必要です。
Registration state changes as contacts are created through REGISTER requests, and then time out due to lack of refresh. Their rate of change is therefore related to the typical registration expiration. Since the default expiration for registrations is 3600 seconds, the default duration of subscriptions to registration state is slightly longer, 3761 seconds. This helps avoid any potential problems with coupling of subscription and registration refreshes. Of course, clients MAY include an Expires header in the SUBSCRIBE request asking for a different duration.
登録状態は、連絡先がレジスタリクエストを通じて作成され、更新がないためにタイムアウトします。したがって、それらの変化率は、典型的な登録の有効期限に関連しています。登録のデフォルトの有効期限は3600秒であるため、登録状態へのサブスクリプションのデフォルトの期間はわずかに長く、3761秒です。これにより、サブスクリプションと登録リフレッシュの結合に関する潜在的な問題を回避できます。もちろん、クライアントには、別の期間を尋ねるサブスクライブリクエストに有効期限のヘッダーを含めることができます。
The SIP Events specification requires package definitions to describe the allowed set of body types in NOTIFY requests, and to specify the default value to be used when there is no Accept header in the SUBSCRIBE request.
SIPイベントの仕様では、通知リクエストで許可されたボディタイプのセットを記述し、サブスクライブリクエストに受け入れヘッダーがない場合に使用されるデフォルト値を指定するためのパッケージ定義が必要です。
The body of a notification of a change in registration state contains a registration information document. This document describes some or all of the contacts associated with a particular address-of-record. All subscribers and notifiers MUST support the "application/reginfo+xml" format described in Section 5. The subscribe request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/reginfo+xml". If the header field is present, it MUST include "application/reginfo+xml", and MAY include any other types capable of representing registration information.
登録状態の変更の通知の本文には、登録情報文書が含まれています。このドキュメントでは、特定の録音アドレスに関連付けられた連絡先の一部またはすべてについて説明します。すべてのサブスクライバーと通知者は、セクション5で説明した「アプリケーション/RegINFO XML」形式をサポートする必要があります。購読要求には、受け入れヘッダーフィールドが含まれる場合があります。そのようなヘッダーフィールドが存在しない場合、「Application/RegInfo XML」のデフォルト値があります。ヘッダーフィールドが存在する場合、「アプリケーション/reginfo XML」を含める必要があり、登録情報を表すことができる他のタイプを含めることができます。
Of course, the notifications generated by the server MUST be in one of the formats specified in the Accept header field in the SUBSCRIBE request.
もちろん、サーバーによって生成された通知は、サブスクライブリクエストのAccept Headerフィールドで指定された形式の1つでなければなりません。
The SIP Events framework specifies that packages should define any package-specific processing of SUBSCRIBE requests at a notifier, specifically with regards to authentication and authorization.
SIPイベントフレームワークでは、パッケージは、特に認証と承認に関して、特に通知者でサブスクライブリクエストのパッケージ固有の処理を定義する必要があることを指定します。
Registration state can be sensitive information. Therefore, all subscriptions to it SHOULD be authenticated and authorized before approval. Authentication MAY be performed using any of the techniques available through SIP, including digest, S/MIME, TLS or other transport specific mechanisms [1]. Authorization policy is at the discretion of the administrator, as always. However, a few recommendations can be made.
登録状態は機密情報になる可能性があります。したがって、それに対するすべてのサブスクリプションは、承認前に認証および承認される必要があります。SIPを通じて利用可能な手法のいずれかを使用して、Digest、S/MIME、TLS、またはその他の輸送固有のメカニズムを使用して、認証を実行できます[1]。許可ポリシーは、いつものように、管理者の裁量にあります。ただし、いくつかの推奨事項を作成できます。
It is RECOMMENDED that a user be allowed to subscribe to their own registration state. Such subscriptions are useful when there are many devices that represent a user, each of which needs to learn the registration state of the other devices. We also anticipate that applications and automata will frequently be subscribers to the registration state. In those cases, authorization policy will typically be provided ahead of time.
ユーザーが自分の登録状態を購読することを許可することをお勧めします。このようなサブスクリプションは、他のデバイスの登録状態を学習する必要があるユーザーを表す多くのデバイスがある場合に役立ちます。また、アプリケーションとオートマトンが登録状態のサブスクライバーに頻繁になると予想しています。そのような場合、通常、承認ポリシーが事前に提供されます。
The SIP Event framework requests that packages specify the conditions under which notifications are sent for that package, and how such notifications are constructed.
SIPイベントフレームワークでは、パッケージがそのパッケージに通知が送信される条件と、そのような通知の構築方法を指定することを要求します。
To determine when a notifier should send notifications of changes in registration state, we define a finite state machine (FSM) that represents the state of a contact for a particular address-of-record. Transitions in this state machine MAY result in the generation of notifications. These notifications will carry information on the new state and the event which triggered the state change. It is important to note that this FSM is just a model of the registration state machinery maintained by a server. An implementation would map its own state machines to this one in an implementation-specific manner.
通知者が登録状態の変更の通知を送信する時期を判断するために、特定の録音住所の連絡先の状態を表す有限状態マシン（FSM）を定義します。この状態マシンの遷移により、通知の生成が生じる可能性があります。これらの通知には、新しい州と州の変更を引き起こしたイベントに関する情報が含まれます。このFSMは、サーバーが維持する登録状態機械の単なるモデルであることに注意することが重要です。実装は、実装固有の方法で独自の状態マシンをこれにマッピングします。
The underlying state machine for a registration is shown in Figure 1. The machine is very simple. An instance of this machine is associated with each address-of-record. When there are no contacts registered to the address-of-record, the state machine is in the init state. It is important to note that this state machine exists, and is well-defined, for each address-of-record in the domain, even if there are no contacts registered to it. This allows a user agent to subscribe to an address-of-record, and learn that there are no contacts registered to it. When the first contact is registered to that address-of-record, the state machine moves from init to active.
登録の基礎となる状態マシンを図1に示します。マシンは非常に簡単です。このマシンのインスタンスは、各録音アドレスに関連付けられています。録音住所に登録された連絡先がない場合、状態マシンはinit状態にあります。この状態マシンが存在し、ドメインのレコードアドレスごとに、連絡先が登録されていなくても、明確に定義されていることに注意することが重要です。これにより、ユーザーエージェントはレコードアドレスを購読し、登録されている連絡先がないことを知ることができます。最初の連絡先がその記録アドレスに登録されると、状態マシンはinitからアクティブに移動します。
+------------+
| |
| Init |
| |
+------------+
|
V
+------------+
| |
| Active |
| |
+------------+
|
V
+------------+
| |
| Terminated |
| |
+------------+
Figure 1: Registration State Machine
図1：登録状態マシン
As long as there is at least one contact bound to the address-of-record, the state machine remains in the active state. When the last contact expires or is removed, the registration transitions to terminated. From there, it immediately transitions back to the init state. This transition is invisible, in that it MUST NOT ever be reported to a subscriber in a NOTIFY request.
録音住所に拘束されている少なくとも1つの接触がある限り、状態マシンはアクティブ状態にとどまります。最後の連絡先が期限切れになったり削除されたりすると、登録は終了します。そこから、すぐにinit状態に戻ります。この移行は、Notifyリクエストでサブスクライバーに報告する必要はないという点で見えません。
This allows for an implementation optimization whereby the registrar can destroy the objects associated with the registration state machine once it enters the terminated state and a NOTIFY has been sent. Instead, the registrar can assume that, if the objects for that state machine no longer exist, the state machine is in the init state.
これにより、登録状態に関連するオブジェクトを終了した状態に入り、通知が送信されると、レジストラが登録状態に関連付けられたオブジェクトを破壊できる実装最適化が可能になります。代わりに、レジストラは、その状態マシンのオブジェクトが存在しなくなった場合、状態マシンがinit状態にあると想定できます。
In addition to this state machine, each registration is associated with a set of contacts, each of which is modeled with its own state machine. Unlike the FSM for the address-of-record, which exists even when no contacts are registered, the per-contact FSM is instantiated when the contact is registered, and deleted when it is removed. The diagram for the per-contact state machine is shown in Figure 2. This FSM is identical to the registration state machine in terms of its states, but has many more transition events.
この状態マシンに加えて、各登録は連絡先のセットに関連付けられており、それぞれが独自の状態マシンでモデル化されています。連絡先が登録されていない場合でも存在するレコードアドレスのFSMとは異なり、接触ごとのFSMは、連絡先が登録されたときにインスタンス化され、削除されたときに削除されます。接触ごとの状態マシンの図を図2に示します。このFSMは、その状態の観点から登録状態マシンと同一ですが、さらに多くの移行イベントがあります。
When a new contact is added, the FSM for it is instantiated, and it moves into the active state. Because of that, the init state here is transient. There are two ways in which it can become active. One is through an actual SIP REGISTER request (corresponding to the registered event), and the other is when the contact is created administratively, or through some non-SIP means (the created event).
新しい連絡先が追加されると、FSMのFSMがインスタンス化され、アクティブな状態に移動します。そのため、ここでの初期状態は一時的です。アクティブになる方法は2つあります。1つは、実際のSIPレジスタリクエスト（登録イベントに対応）を使用し、もう1つは連絡先が管理上、またはSIP以外の手段（作成されたイベント）を使用する場合です。
+------+
| | refreshed
| | shortened
V |
+------------+ +------------+ +------------+
| | | | | |
| Init |----------->| Active |----------->| Terminated |
| | | | | |
+------------+ registered +------------+ expired +------------+
created deactivated
probation
unregistered
rejected
Figure 2: Contact State Machine
図2：ステートマシンに連絡します
The FSM remains in the active state so long as the contact is bound to the address-of-record. When a contact is refreshed through a REGISTER request, the FSM stays in the same state, but a refreshed event is generated. Likewise, when an administrator modifies the expiration time of a binding (without deleting the binding) to trigger the contact to re-register and possibly re-authenticate, the FSM stays in the active state, but a shortened event is generated.
FSMは、連絡先が記録アドレスに縛られている限り、アクティブ状態にとどまります。レジスタリクエストで連絡先が更新されると、FSMは同じ状態にとどまりますが、更新されたイベントが生成されます。同様に、管理者がバインディングの有効期限を変更して（バインディングを削除せずに）接触をトリガーして再登録し、場合によっては再認証する場合、FSMはアクティブな状態にとどまりますが、短縮イベントが生成されます。
When the contact is no longer bound to the address-of-record, the FSM moves to the terminated state, and once a NOTIFY is sent, the state machine is destroyed. As a result, the terminated state is effectively transient. There are several reasons this can happen. The first is an expiration, which occurs when the contact was not refreshed by a REGISTER request. The second reason is deactivated. This occurs when the administrator has removed the contact as a valid binding, but still wishes the client to attempt to re-register the contact. In contrast, the rejected event occurs when an active contact is removed by the administrator, but re-registrations will not help to re-establish it. This might occur if a user does not pay their bills, for example. The probation event occurs when an active contact is removed by the administrator, and the administrator wants the client to re-register, but to do so at a later time. The unregistered event occurs when a REGISTER request sets the expiration time of that contact to zero.
連絡先が録音アドレスに結合しなくなった場合、FSMは終了状態に移動し、通知が送信されると、状態マシンが破壊されます。その結果、終了した状態は事実上一時的です。これが起こる可能性のあるいくつかの理由があります。1つ目は有効期限です。これは、レジスタリクエストによって連絡先が更新されなかったときに発生します。2番目の理由は非アクティブ化されます。これは、管理者が有効なバインディングとして連絡先を削除したときに発生しますが、それでもクライアントが連絡先の再登録を試みることを望んでいます。対照的に、拒否されたイベントは、管理者によってアクティブな接触が削除されたときに発生しますが、再登録はそれを再確立するのに役立ちません。これは、たとえば、ユーザーが請求書を支払わない場合に発生する可能性があります。保護観察イベントは、アクティブな連絡先が管理者によって削除されたときに発生し、管理者はクライアントに再登録を望んでいますが、後で行うことを望みます。未登録のイベントは、レジスタリクエストがその連絡先の有効期限をゼロに設定すると発生します。
The server MAY generate a notification to subscribers when any event occurs in either the address-of-record or per-contact state machines, except for the transition from terminated to init in the address-of-record state machine. As noted above, a notification MUST NOT be sent in this case. For other transitions, whether the server sends a notification or not is policy dependent. However, several guidelines are defined.
サーバーは、記録アドレスまたはコンタクトごとのマシンのいずれかでイベントが発生した場合、サブスクライバーに通知を生成する場合がありますが、録音住所マシンで終了からinitへの移行を除きます。上記のように、この場合は通知を送信してはなりません。他の移行の場合、サーバーが通知を送信するかどうかはポリシーに依存します。ただし、いくつかのガイドラインが定義されています。
As a general rule, when a subscriber is authorized to receive notifications about a set of registrations, it is RECOMMENDED that notifications contain information about those contacts which have changed state (and thus triggered a notification), instead of delivering the current state of every contact in all registrations. However, notifications triggered as a result of a fetch operation (a SUBSCRIBE with Expires of 0) SHOULD result in the full state of all contacts for all registrations to be present in the NOTIFY.
原則として、サブスクライバーが一連の登録に関する通知を受信することを許可されている場合、通知には、すべての連絡先の現在の状態を提供する代わりに、状態を変更した（したがって通知をトリガーした）連絡先に関する情報を含めることをお勧めします。すべての登録で。ただし、フェッチ操作の結果としてトリガーされた通知（0の有効期限が切れるサブスクライブ）は、すべての登録が通知に存在するようにすべての連絡先の完全な状態になるはずです。
The SIP Events framework expects packages to specify how a subscriber processes NOTIFY requests in any package specific ways, and in particular, how it uses the NOTIFY requests to construct a coherent view of the state of the subscribed resource. Typically, the NOTIFY will only contain information for contacts whose state has changed. To construct a coherent view of the total state of all registrations, the subscriber will need to combine NOTIFYs received over time. The details of this process depend on the document format used to convey registration state. Section 5 outlines the process for the application/reginfo+xml format.
SIPイベントフレームワークでは、パッケージがパッケージに固有の方法でサブスクライバープロセスがリクエストを通知する方法、特に通知要求を使用してサブスクライブリソースの状態のコヒーレントビューを構築する方法を指定することを期待しています。通常、Notifyには、状態が変更された連絡先の情報のみが含まれます。すべての登録の合計状態の一貫したビューを構築するには、サブスクライバーは、受け取った通知を時間の経過とともに組み合わせる必要があります。このプロセスの詳細は、登録状態を伝えるために使用されるドキュメント形式に依存します。セクション5では、アプリケーション/RegINFO XML形式のプロセスの概要を説明します。
The SIP Events framework mandates that packages indicate whether or not forked SUBSCRIBE requests can install multiple subscriptions.
SIPイベントフレームワークは、パッケージがフォークされたサブスクライブリクエストが複数のサブスクリプションをインストールできるかどうかを示すことを義務付けています。
Registration state is normally stored in some repository (whether it be co-located with a proxy/registrar or in a separate database). As such, there is usually a single place where the contact information for a particular address-of-record is resident. This implies that a subscription for this information is readily handled by a single element with access to this repository. There is, therefore, no compelling need for a subscription to registration information to fork. As a result, a subscriber MUST NOT create multiple dialogs as a result of a single subscription request. The required processing to guarantee that only a single dialog is established is described in Section 4.4.9 of the SIP Events framework [2].
登録状態は通常、一部のリポジトリに保存されます（プロキシ/レジストラと共同で、または別のデータベースに共同住宅されています）。そのため、通常、特定の録音住所の連絡先情報が居住している場所があります。これは、この情報のサブスクリプションが、このリポジトリにアクセスできる単一の要素によって容易に処理されることを意味します。したがって、フォークへの登録情報のサブスクリプションの説得力のある必要はありません。その結果、サブスクライバーは、単一のサブスクリプションリクエストの結果として複数のダイアログを作成してはなりません。単一のダイアログのみが確立されていることを保証するために必要な処理は、SIPイベントフレームワークのセクション4.4.9で説明されています[2]。
The SIP Events framework mandates that packages define a maximum rate of notifications for their package.
SIPイベントフレームワークは、パッケージがパッケージの最大通知率を定義することを義務付けています。
For reasons of congestion control, it is important that the rate of notifications not become excessive. As a result, it is RECOMMENDED that the server not generate notifications for a single subscriber at a rate faster than once every 5 seconds.
混雑制御の理由により、通知率が過剰にならないことが重要です。その結果、サーバーは、5秒ごとに1回よりも速いレートで単一のサブスクライバーの通知を生成しないことをお勧めします。
The SIP Events framework asks packages to consider the role of state agents in their design.
SIPイベントフレームワークは、パッケージに、デザインにおける州のエージェントの役割を検討するように求めています。
State agents have no role in the handling of this package.
州のエージェントは、このパッケージの取り扱いには役割もありません。
Registration information is an XML document [4] that MUST be well-formed and SHOULD be valid. Registration information documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying registration information documents and document fragments. The namespace URI for elements defined by this specification is a URN [5], using the namespace identifier 'ietf' defined by [6] and extended by [7]. This URN is:
登録情報はXMLドキュメント[4]であり、適切に形成されている必要があり、有効でなければなりません。登録情報文書はXML 1.0に基づいている必要があり、UTF-8を使用してエンコードする必要があります。この仕様では、登録情報ドキュメントを識別し、断片を文書化するためにXML名空間を使用します。この仕様で定義された要素の名前空間URIは、[6]で定義され、[7]で拡張された名前空間識別子「IETF」を使用して、uRN [5]です。このurnは次のとおりです。
urn:ietf:params:xml:ns:reginfo
A registration information document begins with the root element tag "reginfo". It consists of any number of "registration" sub-elements, each of which contains the registration state for a particular address-of-record. The registration information for a particular address-of-record MUST be contained within a single "registration" element; it cannot be spread across multiple "registration" elements within a document. Other elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. There are two attributes associated with the "reginfo" element, both of which MUST be present:
登録情報ドキュメントは、ルート要素タグ「reginfo」から始まります。これは、任意の数の「登録」サブエレメントで構成されており、それぞれに特定の録音住所の登録状態が含まれています。特定の録音住所の登録情報は、単一の「登録」要素に含める必要があります。ドキュメント内の複数の「登録」要素に分類することはできません。拡張性の目的のために、異なる名前空間からの他の要素が存在する場合があります。不明な名前空間からの要素または属性は無視する必要があります。「reginfo」要素に関連付けられた2つの属性があり、どちらも存在する必要があります。
version: This attribute allows the recipient of registration information documents to properly order them. Versions start at 0, and increment by one for each new document sent to a subscriber. Versions are scoped within a subscription. Versions MUST be representable using a 32 bit integer.
バージョン：この属性により、登録情報ドキュメントの受信者が適切に注文できるようになります。バージョンは0から始まり、サブスクライバーに送信される新しいドキュメントごとに1つずつ増加します。バージョンはサブスクリプション内でスコープされます。バージョンは、32ビット整数を使用して表現できる必要があります。
state: This attribute indicates whether the document contains the full registration state, or whether it contains only information on those registrations which have changed since the previous document (partial).
状態：この属性は、ドキュメントに完全な登録状態が含まれているかどうか、または以前のドキュメント以降に変更された登録に関する情報のみが含まれているかどうかを示します（部分）。
Note that the document format explicitly allows for conveying information on multiple addresses-of-record. This enables subscriptions to groups of registrations, where such a group is identified by some kind of URI. For example, a domain might define sip:allusers@example.com as a subscribable resource that generates notifications when the state of any address-of-record in the domain changes.
ドキュメント形式では、複数の録音アドレスに関する情報を明示的に伝えることができることに注意してください。これにより、登録グループへのサブスクリプションが可能になります。このグループは、ある種のURIによって識別されます。たとえば、ドメインは、sip：allusers@example.comを、ドメイン内の録音アドレスの状態が変更されたときに通知を生成する購読可能なリソースとして定義する場合があります。
The "registration" element has a list of any number of "contact" sub-elements, each of which contains information on a single contact. Other elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. There are three attributes associated with the "registration" element, all of which MUST be present:
「登録」要素には、任意の数の「連絡先」のサブエレメントのリストがあり、それぞれに単一の連絡先に関する情報が含まれています。拡張性の目的のために、異なる名前空間からの他の要素が存在する場合があります。不明な名前空間からの要素または属性は無視する必要があります。「登録」要素に関連付けられた3つの属性があり、それらはすべて存在する必要があります。
aor: The aor attribute contains a URI which is the address-of-record this registration refers to.
AOR：AOR属性には、この登録が参照する録音アドレスであるURIが含まれています。
id: The id attribute identifies this registration. It MUST be unique amongst all other id attributes present in other registration elements conveyed to the subscriber within the scope of their subscription. In particular, if two URI identifying an address-of-record differ after their canonicalization according to the procedures in step 5 of Section 10.3 of RFC 3261 [1], the id attributes in the "registration" elements for those addresses-of-record MUST differ. Furthermore, the id attribute for a "registration" element for a particular address-of-record MUST be the same across all notifications sent within the subscription.
ID：ID属性はこの登録を識別します。これは、サブスクリプションの範囲内でサブスクライバーに伝えられる他の登録要素に存在する他のすべてのID属性の中で一意でなければなりません。特に、RFC 3261 [1]のセクション10.3のステップ5の手順に従って、recordの住所を識別する2つのURIが標準化後に異なる場合、それらの住所の「登録」要素のID属性は違う必要があります。さらに、特定の記録アドレスの「登録」要素のID属性は、サブスクリプション内で送信されるすべての通知で同じでなければなりません。
state: The state attribute indicates the state of the registration. The valid values are "init", "active" and "terminated".
州：状態属性は、登録の状態を示します。有効な値は、「init」、「アクティブ」、「終了」です。
The "contact" element contains a "uri" element, an optional "display-name" element, and an optional "unknown-param" element. Other elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. There are several attributes associated with the "contact" element which MUST be present:
「連絡先」要素には、「URI」要素、オプションの「ディスプレイ」要素、およびオプションの「不明 - パラム」要素が含まれています。拡張性の目的のために、異なる名前空間からの他の要素が存在する場合があります。不明な名前空間からの要素または属性は無視する必要があります。存在する必要がある「接触」要素に関連付けられたいくつかの属性があります。
id: The id attribute identifies this contact. It MUST be unique amongst all other id attributes present in other contact elements conveyed to the subscriber within the scope of their subscription. In particular, if the URI for two contacts differ (based on the URI comparison rules in RFC 3261 [1]), the id attributes for those contacts MUST differ. However, unlike the id attribute for an address-of-record, if the URI for two contacts are the same, their id attributes SHOULD be the same across notifications. This requirement is at SHOULD strength, and not MUST strength, since it is difficult to compute such an id as a function of the URI without retaining additional state. No hash function applied to the URI can, in fact, meet a MUST requirement. This is because equality of the SIP URI is not transitive. However, a hash function which includes unknown URI parameters (that is, any not defined in RFC 3261), will always result in a value that is the different if two URI are different, and usually the same if the URI are equal.
ID：ID属性はこの連絡先を識別します。これは、サブスクリプションの範囲内でサブスクライバーに伝えられる他の接触要素に存在する他のすべてのID属性の中で一意でなければなりません。特に、2つの連絡先のURIが異なる場合（RFC 3261 [1]のURI比較ルールに基づいて）、それらの連絡先のID属性は異なる必要があります。ただし、録音アドレスのID属性とは異なり、2つの連絡先のURIが同じ場合、ID属性は通知間で同じでなければなりません。この要件は強度であり、強度は必要ありません。強度は必要ありません。なぜなら、追加の状態を保持せずにURIの関数としてそのようなIDを計算することは困難であるからです。実際、URIに適用されるハッシュ関数は、必須要件を満たすことはできません。これは、SIP URIの平等が推移的ではないためです。ただし、不明なURIパラメーター（つまり、RFC 3261で定義されていない）を含むハッシュ関数は、2つのURIが異なる場合に異なる値を常に生じ、通常はURIが等しい場合は同じです。
state: The state attribute indicates the state of the contact. The valid values are "active" and "terminated".
状態：状態属性は、接触の状態を示します。有効な値は「アクティブ」および「終了」です。
event: The event attribute indicates the event which caused the contact state machine to go into its current state. Valid values are registered, created, refreshed, shortened, expired, deactivated, probation, unregistered and rejected.
イベント：イベント属性は、コンタクトステートマシンが現在の状態に入る原因となったイベントを示します。有効な値は、登録、作成、更新、短縮、期限切れ、無効、保護観察、未登録、拒否されます。
If the event attribute has a value of shortened, the "expires" attribute MUST be present. It contains an unsigned long integer which indicates the number of seconds remaining until the binding is due to expire. This attribute MAY be included with any event attribute value for which the state of the contact is active.
イベント属性の短縮値がある場合、「有効期限」属性が存在する必要があります。これには、バインディングが期限切れになるまで残っている秒数を示す署名されていない長い整数が含まれています。この属性は、連絡先の状態がアクティブなイベント属性値に含めることができます。
If the event attribute has a value of probation, the "retry-after" attribute MUST be present. It contains an unsigned long integer which indicates the amount of seconds after which the owner of the contact is expected to retry its registration.
イベント属性に保護観察の値がある場合、「再試行後の」属性が存在する必要があります。これには、連絡先の所有者が登録を再試行すると予想される秒数を示す署名のない長い整数が含まれています。
The optional "duration-registered" attribute conveys the amount of time that the contact has been bound to the address-of-record, in seconds. The optional "q" attribute conveys the relative priority of this contact compared to other registered contacts. The optional "callid" attribute contains the current Call-ID carried in the REGISTER that was last used to update this contact, and the optional "cseq" attribute contains the last CSeq value present in a REGISTER request that updated this contact value.
オプションの「持続時間登録」属性は、連絡先が数秒で記録アドレスにバインドされている時間を伝えます。オプションの「Q」属性は、他の登録された連絡先と比較して、この連絡先の相対的な優先度を伝えます。オプションの「CallID」属性には、この連絡先を更新するために最後に使用された現在のCall-IDがレジスタに含まれています。オプションの「CSEQ」属性には、この連絡先値を更新するレジスタリクエストに存在する最後のCSEQ値が含まれます。
The "uri" element contains the URI associated with that contact. The "display-name" element contains the display name for the contact. The "display-name" element MAY contain the xml:lang attribute to indicate the language of the display name.
「URI」要素には、その接触に関連付けられたURIが含まれています。「ディスプレイ名」要素には、連絡先のディスプレイ名が含まれています。「ディスプレイ名」要素には、XML：Lang属性が含まれている場合があり、表示名の言語を示します。
The "unknown-param" element is used to convey contact header field parameters that are not specified in RFC 3261. One example are the user agent capability parameters specified in [11]. Each "unknown-param" element describes a single contact header field parameter. The name of the parameter is contained in the mandatory name attribute of the "unknown-param" element, and the value of the parameter is the content of the "unknown-param" element. For contact header field parameters that have no value, the content of the "unknown-param" element is empty.
「未知のパラム」要素は、RFC 3261で指定されていないコンタクトヘッダーフィールドパラメーターを伝達するために使用されます。1つの例は、[11]で指定されたユーザーエージェント機能パラメーターです。各「未知のパラム」要素は、単一の連絡先ヘッダーフィールドパラメーターを記述します。パラメーターの名前は、「未知のパラム」要素の必須名属性に含まれており、パラメーターの値は「未知のパラム」要素のコンテンツです。値のない接触ヘッダーフィールドパラメーターの場合、「不明なパラム」要素のコンテンツは空です。
Typically, the NOTIFY for registration information will only contain information about those contacts whose state has changed. To construct a coherent view of the total state of all registrations, a subscriber will need to combine NOTIFYs received over time. The subscriber maintains a table for each registration it receives information for. Each registration is uniquely identified by the "id" attribute in the "registration" element. Each table contains a row for each contact in that registration. Each row is indexed by the unique ID for that contact. It is conveyed in the "id" attribute of the "contact" element. The contents of each row contain the state of that contact as conveyed in the "contact" element. The tables are also associated with a version number. The version number MUST be initialized with the value of the "version" attribute from the "reginfo" element in the first document received. Each time a new document is received, the value of the local version number, and the "version" attribute in the new document, are compared. If the value in the new document is one higher than the local version number, the local version number is increased by one, and the document is processed. If the value in the document is more than one higher than the local version number, the local version number is set to the value in the new document, the document is processed, and the subscriber SHOULD generate a refresh request to trigger a full state notification. If the value in the document is less than the local version, the document is discarded without processing.
通常、登録情報の通知には、状態が変更された連絡先に関する情報のみが含まれます。すべての登録の合計状態の一貫したビューを構築するには、サブスクライバーは、受け取った通知を時間の経過とともに組み合わせる必要があります。サブスクライバーは、情報を受け取る各登録ごとにテーブルを維持します。各登録は、「登録」要素の「ID」属性によって一意に識別されます。各テーブルには、その登録の各連絡先の行が含まれています。各行は、その連絡先の一意のIDによってインデックス付けされます。「連絡先」要素の「ID」属性で伝えられます。各行の内容には、「連絡先」要素に伝えられる接触の状態が含まれています。テーブルはバージョン番号にも関連付けられています。バージョン番号は、最初に受信したドキュメントの「RegINFO」要素の「バージョン」属性の値で初期化する必要があります。新しいドキュメントが受信されるたびに、ローカルバージョン番号の値と新しいドキュメントの「バージョン」属性が比較されます。新しいドキュメントの値がローカルバージョン番号よりも1つ高い場合、ローカルバージョン番号は1つ増加し、ドキュメントは処理されます。ドキュメント内の値がローカルバージョン番号よりも複数高い場合、ローカルバージョン番号が新しいドキュメントの値に設定され、ドキュメントが処理され、サブスクライバーが完全な状態通知をトリガーするための更新リクエストを生成する必要があります。ドキュメントの値がローカルバージョンよりも少ない場合、ドキュメントは処理せずに破棄されます。
The processing of the document depends on whether it contains full or partial state. If it contains full state, indicated by the value of the "state" attribute in the "reginfo" element, the contents of all tables associated with this subscription are flushed. They are re-populated from the document. A new table is created for each "registration" element, and a new row in each table is created for each "contact" element. If the reginfo contains partial state, as indicated by the value of the "state" attribute in the "reginfo" element, the document is used to update the existing tables. For each "registration" element, the subscriber checks to see if a table exists for that registration. This check is done by comparing the value in the "id" attribute of the "registration" element with the ID associated with the table. If a table doesn't exist for that registration, one is created. For each "contact" element in the registration, the subscriber checks to see whether a row exists for that contact. This check is done by comparing the ID in the "id" attribute of the "contact" element with the ID associated with the row. If the contact doesn't exist in the table, a row is added, and its state is set to the information from that "contact" element. If the contact does exist, its state is updated to be the information from that "contact" element. If a row is updated or created, such that its state is now terminated, that entry MAY be removed from the table at any time.
ドキュメントの処理は、完全な状態か部分状態が含まれているかによって異なります。「reginfo」要素の「状態」属性の値で示される完全な状態が含まれている場合、このサブスクリプションに関連付けられたすべてのテーブルの内容がフラッシュされます。それらはドキュメントから再入力されています。各「登録」要素に対して新しいテーブルが作成され、各テーブルの新しい行が各「連絡先」要素に対して作成されます。RegINFOに「RegInfo」要素の「状態」属性の値で示されるように、部分的な状態が含まれている場合、ドキュメントは既存のテーブルの更新に使用されます。各「登録」要素について、サブスクライバーはその登録のためにテーブルが存在するかどうかを確認します。このチェックは、「登録」要素の「ID」属性の値をテーブルに関連付けられたIDと比較することによって行われます。その登録のためにテーブルが存在しない場合、1つが作成されます。登録の各「連絡先」要素について、サブスクライバーはその連絡先の行が存在するかどうかを確認します。このチェックは、「連絡先」要素の「ID」属性のIDを行に関連付けられたIDと比較することによって行われます。テーブルに連絡先が存在しない場合、行が追加され、その状態はその「連絡先」要素からの情報に設定されます。連絡先が存在する場合、その状態はその「連絡先」要素からの情報に更新されます。行が更新または作成されている場合、その状態が現在終了するように、そのエントリはいつでもテーブルから削除される場合があります。
The following is an example registration information document:
以下は、登録情報ドキュメントの例です。
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
version="0" state="full">
<registration aor="sip:user@example.com" id="as9"
state="active">
<contact id="76" state="active" event="registered"
duration-registered="7322"
q="0.8">
<uri>sip:user@pc887.example.com</uri>
</contact>
<contact id="77" state="terminated" event="expired"
duration-registered="3600"
q="0.5">
<uri>sip:user@university.edu</uri>
</contact>
</registration>
</reginfo>
The following is the schema definition of the reginfo format:
以下は、reginfo形式のスキーマ定義です。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:reginfo"
xmlns:tns="urn:ietf:params:xml:ns:reginfo"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
<xs:element name="reginfo">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:registration" minOccurs="0"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="version" type="xs:nonNegativeInteger"
use="required"/>
<xs:attribute name="state" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="full"/>
<xs:enumeration value="partial"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="registration">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:contact" minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="aor" type="xs:anyURI" use="required"/>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="state" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="init"/>
<xs:enumeration value="active"/>
<xs:enumeration value="terminated"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="contact">
<xs:complexType>
<xs:sequence>
<xs:element name="uri" type="xs:anyURI"/>
<xs:element name="display-name" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="unknown-param" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="name" type="xs:string" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="state" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="active"/>
<xs:enumeration value="terminated"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="event" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="registered"/>
<xs:enumeration value="created"/>
<xs:enumeration value="refreshed"/>
<xs:enumeration value="shortened"/>
<xs:enumeration value="expired"/>
<xs:enumeration value="deactivated"/>
<xs:enumeration value="probation"/>
<xs:enumeration value="unregistered"/>
<xs:enumeration value="rejected"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="duration-registered" type="xs:unsignedLong"/>
<xs:attribute name="expires" type="xs:unsignedLong"/>
<xs:attribute name="retry-after" type="xs:unsignedLong"/>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="q" type="xs:string"/>
<xs:attribute name="callid" type="xs:string"/>
<xs:attribute name="cseq" type="xs:unsignedLong"/>
</xs:complexType>
</xs:element>
</xs:schema>
User Registrar Application
| |(1) SUBSCRIBE |
| |Event:reg |
| |<------------------|
| |(2) 200 OK |
| |------------------>|
| |(3) NOTIFY |
| |------------------>|
| |(4) 200 OK |
| |<------------------|
|(5) REGISTER | |
|------------------>| |
|(6) 200 OK | |
|<------------------| |
| |(7) NOTIFY |
| |------------------>|
| |(8) 200 OK |
| |<------------------|
|(9) MESSAGE | |
|<--------------------------------------|
Figure 3: Example Call Flow
図3：コールフローの例
This section provides an example call flow, shown in Figure 3. It shows an implementation of the welcome notice application described in Section 3.3. First, the application SUBSCRIBEs to the registration event package for the desired user (1):
このセクションでは、図3に示すコールフローの例を示します。これは、セクション3.3で説明されている歓迎通知アプリケーションの実装を示しています。まず、アプリケーションは、目的のユーザーの登録イベントパッケージを購読します（1）：
SUBSCRIBE sip:joe@example.com SIP/2.0
Via: SIP/2.0/UDP app.example.com;branch=z9hG4bKnashds7
From: sip:app.example.com;tag=123aa9
To: sip:joe@example.com
Call-ID: 9987@app.example.com
CSeq: 9887 SUBSCRIBE
Contact: sip:app.example.com
Event: reg
Max-Forwards: 70
Accept: application/reginfo+xml
The registrar (which is acting as the notifier for the registration event package) generates a 200 OK to the SUBSCRIBE:
レジストラ（登録イベントパッケージの通知者として機能している）は、サブスクライブに200 OKを生成します。
SIP/2.0 200 OK
Via: SIP/2.0/UDP app.example.com;branch=z9hG4bKnashds7
;received=192.0.2.1
From: sip:app.example.com;tag=123aa9
To: sip:joe@example.com;tag=xyzygg
Call-ID: 9987@app.example.com
CSeq: 9987 SUBSCRIBE
Contact: sip:server19.example.com
Expires: 3600
The registrar then generates a notification (3) with the current state. Since there is no active registration, the state of the registration is "init":
次に、レジストラは、現在の状態で通知（3）を生成します。アクティブな登録がないため、登録の状態は「init」です。
NOTIFY sip:app.example.com SIP/2.0
Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii
From: sip:joe@example.com;tag=xyzygg
To: sip:app.example.com;tag=123aa9
Call-ID: 9987@app.example.com
CSeq: 1288 NOTIFY
Contact: sip:server19.example.com
Event: reg
Max-Forwards: 70
Content-Type: application/reginfo+xml
Content-Length: ...
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
version="0" state="full">
<registration aor="sip:joe@example.com" id="a7" state="init" />
</reginfo>
Later on, the user registers (5):
後で、ユーザーがレジスタ（5）を登録します。
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnaaff
From: sip:joe@example.com;tag=99a8s
To: sip:joe@example.com
Call-ID: 88askjda9@pc34.example.com
CSeq: 9976 REGISTER
Contact: sip:joe@pc34.example.com
This results in a NOTIFY being generated to the application (7):
これにより、通知がアプリケーションに生成されます（7）：
NOTIFY sip:app.example.com SIP/2.0
Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij
From: sip:joe@example.com;tag=xyzygg
To: sip:app.example.com;tag=123aa9
Call-ID: 9987@app.example.com
CSeq: 1289 NOTIFY
Contact: sip:server19.example.com
Event: reg
Max-Forwards: 70
Content-Type: application/reginfo+xml
Content-Length: ...
<?xml version="1.0"?> <reginfo xmlns="urn:ietf:params:xml:ns:reginfo" version="1" state="partial"> <registration aor="sip:joe@example.com" id="a7" state="active"> <contact id="76" state="active" event="registered" duration-registered="0"> <uri>sip:joe@pc34.example.com</uri> </contact> </registration> </reginfo> The application can then send its instant message to the device (9):
<？xml version = "1.0"？> <reginfo xmlns = "urn：ietf：params：xml：ns：reginfo" version = "1" state = "partial"> <登録aor = "sip：joe@example.com"id =" a7 "state =" active "> <連絡先id =" 76 "state =" active "event ="登録 "duration-registered =" 0 "> <uri> sip：joe@pc34.example.com </uri> </連絡先> </登録> </reginfo>アプリケーションは、インスタントメッセージをデバイスに送信できます（9）：
MESSAGE sip:joe@pc34.example.com SIP/2.0
Via: SIP/2.0/UDP app.example.com;branch=z9hG4bKnashds8
From: sip:app.example.com;tag=123aa10
To: sip:joe@example.com
Call-ID: 9988@app.example.com
CSeq: 82779 MESSAGE
Max-Forwards: 70
Content-Type: text/plain
Content-Length: ...
Welcome to the example.com service!
Example.comサービスへようこそ！
Security considerations for SIP event packages are discussed in RFC 3265 [2], and those considerations apply here.
SIPイベントパッケージのセキュリティに関する考慮事項は、RFC 3265 [2]で説明されており、これらの考慮事項はここで適用されます。
Registration information is sensitive, potentially private, information. Subscriptions to this event package SHOULD be authenticated and authorized according to local policy. Some policy guidelines are suggested in Section 4.6. In addition, notifications SHOULD be sent in such a way to ensure confidentiality, message integrity and verification of subscriber identity, such as sending subscriptions and notifications using a SIPS URL or protecting the notification bodies with S/MIME.
登録情報は、敏感で、潜在的にプライベートな情報です。このイベントパッケージのサブスクリプションは、ローカルポリシーに従って認証および承認される必要があります。セクション4.6には、いくつかのポリシーガイドラインが提案されています。さらに、SIPS URLを使用してサブスクリプションを送信したり通知を送信したり、S/MIMEで通知機関を保護するなど、サブスクライバーIDの機密性、メッセージの整合性、検証を確保するために、通知をそのような方法で送信する必要があります。
This document registers a new SIP Event Package, a new MIME type (application/reginfo+xml), and a new XML namespace.
このドキュメントは、新しいSIPイベントパッケージ、新しいMIMEタイプ（アプリケーション/RegINFO XML）、および新しいXMLネームスペースを登録します。
Package name: reg
パッケージ名：reg
Type: package
タイプ：パッケージ
Contact: Jonathan Rosenberg, <jdrosen@jdrosen.net>
Published Specification: RFC 3680.
公開された仕様：RFC 3680。
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: reginfo+xml
MIMEサブタイプ名：reginfo XML
Mandatory parameters: none
必須パラメーター：なし
Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [8].
オプションのパラメーター：RFC 3023 [8]で指定されているCharsetパラメーターアプリケーション/XMLと同じ。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [8].
考慮事項のエンコーディング：RFC 3023で指定されているアプリケーション/XMLの考慮事項のエンコードと同じ[8]。
Security considerations: See Section 10 of RFC 3023 [8] and Section 7 of this specification.
セキュリティ上の考慮事項：RFC 3023 [8]のセクション10およびこの仕様のセクション7を参照してください。
Interoperability considerations: none.
相互運用性の考慮事項：なし。
Published specification: This document.
公開された仕様：このドキュメント。
Applications which use this media type: This document type is being used in notifications to alert SIP user agents that their registrations have expired and must be redone.
このメディアタイプを使用するアプリケーション：このドキュメントタイプは、通知で使用されており、SIPユーザーエージェントが登録の有効期限が切れ、やり直さなければならないことを警告しています。
Additional Information:
追加情報：
Magic Number: None
マジックナンバー：なし
File Extension: .rif or .xml
ファイル拡張子：.rifまたは.xml
Macintosh file type code: "TEXT"
Macintoshファイルタイプコード：「テキスト」
Personal and email address for further information: Jonathan
Rosenberg, <jdrosen@jdrosen.net>
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: The IETF.
著者/変更コントローラー：IETF。
This section registers a new XML namespace, as per the guidelines in [7].
このセクションでは、[7]のガイドラインに従って、新しいXML名前空間を登録します。
URI: The URI for this namespace is urn:ietf:params:xml:ns:reginfo.
URI：この名前空間のURIはurn：ietf：params：xml：ns：reginfoです。
Registrant Contact: IETF, SIMPLE working group, <simple@ietf.org>, Jonathan Rosenberg <jdrosen@jdrosen.net>.
登録者の連絡先：IETF、Simple Working Group、<simher@ietf.org>、Jonathan Rosenberg <jdrosen@jdrosen.net>。
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>Registration Information Namespace</title>
</head>
<body>
<h1>Namespace for Registration Information</h1>
<h2>urn:ietf:params:xml:ns:reginfo</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc3680.txt">
RFC3680</a>.</p>
</body>
</html>
END
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[2] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[3] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] W. W. W. C. (W3C), "Extensible markup language (xml) 1.0." The XML 1.0 spec can be found at http://www.w3.org/TR/1998/REC-xml-19980210.
[4] W. W. W. C.（W3C）、「拡張可能なマークアップ言語（XML）1.0。」XML 1.0仕様は、http：//www.w3.org/tr/1998/rec-xml-19980210にあります。
[5] Moats, R., "URN Syntax", RFC 2141, May 1997.
[5] Moats、R。、「urn構文」、RFC 2141、1997年5月。
[6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[6] Moats、R。、「IETFドキュメント用のurnネームスペース」、RFC 2648、1999年8月。
[7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[7] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[8] Murata, M., St. Laurent, S. and D. Kohn, "XML media types", RFC 3023, January 2001.
[8] Murata、M.、St。Laurent、S。およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[9] Rosenberg, J., "Session initiation protocol (SIP) extensions for presence", Work In Progress.
[9] Rosenberg、J。、「存在のためのセッション開始プロトコル（SIP）拡張機能」、進行中の作業。
[10] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[10] Campbell、B.、Rosenberg、J.、Schulzrinne、H.、Huitema、C。and D. Gurle、「インスタントメッセージングのセッション開始プロトコル（SIP）拡張」、RFC 3428、2002年12月。
[11] Schulzrinne, H. and J. Rosenberg, "Session initiation protocol (SIP) caller preferences and callee capabilities", Work In Progress.
[11] Schulzrinne、H。およびJ. Rosenberg、「セッション開始プロトコル（SIP）発信者の好みとCallee機能」、進行中の作業。
[12] Mayer, G. and M. Beckmann, "Registration event package", Work In Progress.
[12] Mayer、G。およびM. Beckmann、「登録イベントパッケージ」、進行中の作業。
This document is based heavily on the registration event package originally proposed by Beckmann and Mayer in [12]. They can be contacted at:
このドキュメントは、[12]でBeckmannとMayerが元々提案した登録イベントパッケージに大きく基づいています。に連絡することができます：
Georg Mayer Siemens AG Hoffmannstr. 51 Munich 81359 Germany
Georg Mayer Siemens AG Hoffmannstr。51ミュンヘン81359ドイツ
EMail: Georg.Mayer@icn.siemens.de
Mark Beckmann Siemens AG P.O. Box 100702 Salzgitter 38207 Germany
マーク・ベックマン・シーメンスAG P.O.Box 100702 Salzgitter 38207ドイツ
EMail: Mark.Beckmann@siemens.com
Rohan Mahy provided editorial work in order to progress this specification. His contact address is:
Rohan Mahyは、この仕様を進めるために編集作業を提供しました。彼の連絡先住所は次のとおりです。
Rohan Mahy Cisco Systems 170 West Tasman Dr, MS: SJC-21/3/3
Rohan Mahy Cisco Systems 170 West Tasman DR、MS：SJC-21/3/3
Phone: +1 408 526 8570
EMail: rohan@cisco.com
We would like to thank Dean Willis for his support.
ディーン・ウィリスの支援に感謝したいと思います。
Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054
Jonathan Rosenberg Dynamicsoft 600 Lanidex Plaza Parsippany、NJ 07054
EMail: jdrosen@dynamicsoft.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となりますが、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。