[要約] RFC 4235は、SIPにおけるINVITEによるダイアログイベントパッケージを定義しています。このRFCの目的は、SIPセッションの状態変化を通知するための標準化されたメカニズムを提供することです。
Network Working Group J. Rosenberg
Request for Comments: 4235 Cisco Systems
Category: Standards Track H. Schulzrinne
Columbia University
R. Mahy, Ed.
SIP Edge LLC
November 2005
An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)
セッション開始プロトコル（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 01) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 01）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document defines a dialog event package for the SIP Events architecture, along with a data format used in notifications for this package. The dialog package allows users to subscribe to another user and to receive notification of the changes in state of INVITE-initiated dialog usages in which the subscribed-to user is involved.
このドキュメントでは、SIPイベントアーキテクチャ用のダイアログイベントパッケージと、このパッケージの通知で使用されるデータ形式を定義します。ダイアログパッケージを使用すると、ユーザーは別のユーザーを購読し、招待されたダイアログ使用の状態の変更の通知を受け取ることができます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Dialog Event Package ............................................4
3.1. Event Package Name .........................................4
3.2. Event Package Parameters ...................................4
3.3. SUBSCRIBE Bodies ...........................................5
3.4. Subscription Duration ......................................6
3.5. NOTIFY Bodies ..............................................6
3.6. Notifier Processing of SUBSCRIBE Requests ..................7
3.7. Notifier Generation of NOTIFY Requests .....................8
3.7.1. The Dialog State Machine ............................8
3.7.2. Applying the State Machine .........................11
3.8. Subscriber Processing of NOTIFY Requests ..................12
3.9. Handling of Forked Requests ...............................12
3.10. Rate of Notifications ....................................13
3.11. State Agents .............................................13
4. Dialog Information Format ......................................13
4.1. Structure of Dialog Information ...........................13
4.1.1. Dialog Element .....................................14
4.1.2. State Element ......................................15
4.1.3. Duration Element ...................................15
4.1.4. Replaces Element ...................................15
4.1.5. Referred-By Element ................................16
4.1.6. Local and Remote Elements ..........................16
4.2. Sample Notification Body ..................................17
4.3. Constructing Coherent State ...............................18
4.4. Schema ....................................................19
5. Definition of New Media Feature Parameters .....................22
5.1. The "sip.byeless" Parameter ...............................22
5.2. The "sip.rendering" parameter .............................23
6. Examples .......................................................24
6.1. Basic Example .............................................24
6.2. Emulating a Shared-Line Phone System ......................26
6.3. Minimal Dialog Information with Privacy ...................31
7. Security Considerations ........................................32
8. IANA Considerations ............................................32
8.1. application/dialog-info+xml MIME Registration .............33
8.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:dialog-info ........................34
8.3. Schema Registration .......................................34
8.4. Media Feature Parameter Registration ......................34
8.4.1. sip.byeless ........................................35
8.4.2. sip.rendering ......................................35
9. Acknowledgements ...............................................36
10. References ....................................................36
10.1. Normative References .....................................36
10.2. Informative References ...................................37
The SIP Events framework [1] defines general mechanisms for subscription to, and notification of, events within SIP networks. It introduces the notion of a package, which is a specific "instantiation" of the events mechanism for a well-defined set of events. Packages have been defined for user presence [16], watcher information [17], and message waiting indicators [18], amongst others. This document defines an event package for INVITE-initiated dialog usages. Dialogs refer to the SIP relationship established between two SIP peers [2]. Dialogs can be created by many methods, although RFC 3261 defines only one: the INVITE method. RFC 3265 [1] defines the SUBSCRIBE and NOTIFY methods, which also create new dialog usages. However, using this package to model state for non-session dialog usages is out of the scope of this specification.
SIPイベントフレームワーク[1]は、SIPネットワーク内のイベントへのサブスクリプションおよび通知の一般的なメカニズムを定義します。これは、明確に定義された一連のイベントのイベントメカニズムの特定の「インスタンス化」であるパッケージの概念を紹介します。パッケージは、ユーザーの存在[16]、ウォッチャー情報[17]、およびメッセージ待機指標[18]などのために定義されています。このドキュメントでは、招待されたダイアログ使用のためのイベントパッケージを定義します。ダイアログは、2つのSIPピア間で確立されたSIP関係を指します[2]。ダイアログは多くの方法で作成できますが、RFC 3261は1つのみを定義します。Inviteメソッド。RFC 3265 [1]は、サブスクライブおよび通知メソッドを定義し、新しいダイアログ使用も作成します。ただし、このパッケージを使用して、セッション以外のダイアログ使用のために状態をモデル化することは、この仕様の範囲外です。
A variety of applications are enabled through knowledge of INVITE dialog usage state. Some examples include:
招待されたダイアログ使用状態の知識を通じて、さまざまなアプリケーションが有効になっています。いくつかの例は次のとおりです。
Automatic Callback: In this basic Public Switched Telephone Network (PSTN) application, user A calls user B but User B is busy. User A would like to get a callback when user B hangs up. When B hangs up, user A's phone rings. When A picks up, they hear ringing, while they are being connected to B. To implement this with SIP, a mechanism is required for A to receive a notification when the dialogs at B are complete.
自動コールバック：この基本的なパブリックスイッチ付き電話ネットワーク（PSTN）アプリケーションでは、ユーザーAはユーザーBを呼び出しますが、ユーザーBはビジーです。ユーザーAは、ユーザーBがハングアップしたときにコールバックを取得したいと考えています。Bが電話を切ると、ユーザーAの電話が鳴ります。AがBに接続されている間、Aが鳴り響くと、SIPでこれを実装するために、Bでのダイアログが完了したときにAが通知を受信するにはメカニズムが必要です。
Presence-Enabled Conferencing: In this application, user A wishes to set up a conference call with users B and C. Rather than being scheduled, the call is created automatically when A, B and C are all available. To do this, the server providing the application would like to know whether A, B, and C are "online", not idle, and not in a phone call. Determining whether or not A, B, and C are in calls can be done in two ways. In the first, the server acts as a call-stateful proxy for users A, B, and C, and therefore knows their call state. This won't always be possible, however, and it introduces scalability, reliability, and operational complexities. In the second way, the server subscribes to the dialog state of those users and receives notifications as this state changes. This enables the application to be provided in a distributed way; the server need not reside in the same domain as the users.
存在対応会議：このアプリケーションでは、ユーザーAは、ユーザーBとCとの電話会議を設定したいと考えています。スケジュールされるのではなく、A、B、Cがすべて利用可能になったときに自動的に作成されます。これを行うために、アプリケーションを提供するサーバーは、A、B、およびCがオンラインではなく「オンライン」であり、電話では「オンライン」であるかどうかを知りたいと考えています。a、b、およびcが呼び出しであるかどうかを判断することは、2つの方法で実行できます。最初に、サーバーはユーザーA、B、およびCのコールステートフルプロキシとして機能するため、コール状態を知っています。ただし、これは常に可能であるとは限らず、スケーラビリティ、信頼性、および運用上の複雑さをもたらします。2番目の方法では、サーバーはこれらのユーザーのダイアログ状態にサブスクライブし、この状態が変更されると通知を受信します。これにより、アプリケーションを分散方法で提供できます。サーバーは、ユーザーと同じドメインに存在する必要はありません。
IM Conference Alerts: In this application, a user can receive an Instant Message (IM) on their phone whenever someone joins a conference that the phone is involved in. The IM alerts are generated by an application separate from the conference server.
IM Conference Alerts：このアプリケーションでは、ユーザーは電話が関与する会議に参加するたびに、電話でインスタントメッセージ（IM）を受信できます。IMアラートは、会議サーバーとは別のアプリケーションによって生成されます。
In general, the dialog package allows for construction of distributed applications, where the application requires information on dialog state but is not co-resident with the end user on which that state resides.
一般に、ダイアログパッケージでは分散アプリケーションの構築が可能になります。このアプリケーションでは、アプリケーションではダイアログ状態に関する情報が必要ですが、その状態が存在するエンドユーザーとの共同住宅ではありません。
This document also defines two new callee capability [10] feature parameters:
このドキュメントは、2つの新しいCallee機能[10]機能パラメーターも定義しています。
o "sip.byeless", which indicates that a SIP user agent (UA) is not capable of terminating a session itself (for example, in some announcement or recording services, or in some call centers) in which the UA is no longer interested in participating; and
o 「sip.byless」は、SIPユーザーエージェント（UA）がセッション自体（たとえば、いくつかの発表や録音サービス、またはいくつかのコールセンターで）を終了することができないことを示しています。と
o "sip.rendering", which positively describes whether the user agent is rendering any of the media it is receiving. These feature parameters are useful in many of the same applications that motivated the dialog package, such as conferencing, presence, and the shared-line example described in Section 6.2.
o 「sip.rendering」は、ユーザーエージェントが受け取っているメディアのいずれかをレンダリングしているかどうかを積極的に説明しています。これらの機能パラメーターは、会議、存在感、セクション6.2で説明した共有ラインの例など、ダイアログパッケージを動機付けた同じアプリケーションの多くで役立ちます。
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 RFC 2119 [9] and indicate requirement levels for compliant implementations.
このドキュメントでは、キーワードは「必須」、「必須」、「必須」、「「しなければ」」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [9]に記載されているように解釈され、準拠した実装の要件レベルを示すものです。
This section provides the details for defining a SIP Events package, as specified in [1].
このセクションでは、[1]で指定されているように、SIPイベントパッケージを定義するための詳細を説明します。
The name of this event package is "dialog". This package name is carried in the Event and Allow-Events header fields, as defined in [1].
このイベントパッケージの名前は「ダイアログ」です。このパッケージ名は、[1]で定義されているように、イベントと許容イベントヘッダーフィールドに掲載されています。
This package defines four Event Package parameters: call-id, to-tag, from-tag, and include-session-description. If a subscription to a specific dialog is requested, the first three of these parameters MUST be present, to identify the dialog that is being subscribed to. The to-tag is matched against the local tag, the from-tag is matched against the remote tag, and the call-id is matched against the Call-ID. The include-session-description parameter indicates whether the subscriber would like to receive the session descriptions associated with the subscribed dialog usage or usages.
このパッケージでは、4つのイベントパッケージパラメーターを定義します：call-id、to-tag、from-tag、include-session-description。特定のダイアログのサブスクリプションが要求された場合、サブスクライブされているダイアログを特定するために、これらのパラメーターの最初の3つが存在する必要があります。To-Tagはローカルタグと一致し、From-Tagはリモートタグと一致し、Call-IDはCall-IDと一致します。含まれるセッションと説明パラメーターは、サブスクライバーがサブスクライブされたダイアログの使用または使用に関連するセッションの説明を受け取りたいかどうかを示します。
It is also possible to subscribe to the set of dialogs created as a result of a single INVITE sent by a UAC (user agent client). In that case, the call-id and to-tag MUST be present. The to-tag is matched against the local tag and the call-id is matched against the Call-ID.
また、UAC（ユーザーエージェントクライアント）から送信された単一の招待の結果として作成されたダイアログのセットを購読することもできます。その場合、Call-IDとTo-Tagが存在する必要があります。To-Tagはローカルタグと一致し、Call-IDはCall-IDと一致します。
The ABNF for these parameters is shown below. It refers to many constructions from the ABNF of RFC3261, such as EQUAL, DQUOTE, and token.
これらのパラメーターのABNFを以下に示します。等しい、dquote、トークンなど、RFC3261のABNFからの多くの構造を指します。
call-id = "call-id" EQUAL ( token / DQUOTE callid DQUOTE )
;; NOTE: any DQUOTEs inside callid MUST be escaped!
from-tag = "from-tag" EQUAL token
to-tag = "to-tag" EQUAL token
with-sessd = "include-session-description"
If any call-ids contain embedded double-quotes, those double-quotes MUST be escaped using the backslash-quoting mechanism. Note that the call-id parameter may need to be expressed as a quoted string. This is because the ABNF for the callid production and the word production, which is used by callid (both from RFC 3261 [1]), allow some characters (such as "@", "[", and ":") that are not allowed within a token.
Call-IDに埋め込まれたダブルクォートが含まれている場合、バックスラッシュ引用メカニズムを使用して、これらの二重引用符を脱出する必要があります。call-idパラメーターは、引用された文字列として表現する必要がある場合があることに注意してください。これは、Callidの生産とCallid（両方ともRFC 3261 [1]から）が使用する単語生産のABNFが、トークン内で許可されていない一部の文字（「@」、」["、"： "など）を許可するためです。
A SUBSCRIBE request for a dialog package MAY contain a body. This body defines a filter to be applied to the subscription. Filter documents are not specified in this document, and at the time of writing, they are expected to be the subject of future standardization activity.
ダイアログパッケージの購読要求にはボディが含まれる場合があります。この本体は、サブスクリプションに適用されるフィルターを定義します。フィルタードキュメントはこのドキュメントでは指定されておらず、執筆時点では、将来の標準化アクティビティの対象となることが期待されています。
A SUBSCRIBE request for a dialog package MAY be sent without a body. This implies the default subscription filtering policy. The default policy is:
ダイアログパッケージの購読リクエストは、ボディなしで送信される場合があります。これは、デフォルトのサブスクリプションフィルタリングポリシーを意味します。デフォルトのポリシーは次のとおりです。
o If the Event header field contained dialog identifiers, a notification is generated every time there is a change in the state of any matching dialogs for the user identified in the request URI of the SUBSCRIBE.
o イベントヘッダーフィールドにダイアログ識別子が含まれていた場合、購読のリクエストで識別されたユーザーの一致するダイアログの状態に変更があるたびに通知が生成されます。
o If there were no dialog identifiers in the Event header field, a notification is generated every time there is any change in the state of any dialogs for the user identified in the request URI of the SUBSCRIBE with the following exceptions. If the target (Contact) URI of a subscriber is equivalent to the remote target URI of a specific dialog, then the dialog element for that dialog is suppressed for that subscriber. (The subscriber is already a party in the dialog directly, so these notifications are superfluous.) If no dialogs remain after suppressing dialogs, the entire notification to that subscriber is suppressed and the version number in the dialog-info element is not incremented for that subscriber. Implicit filtering for one subscriber does not affect notifications to other subscribers.
o イベントヘッダーフィールドにダイアログ識別子がなかった場合、次の例外を除いて、サブスクライブのリクエストで識別されたユーザーのダイアログの状態に変更があるたびに通知が生成されます。サブスクライバーのターゲット（連絡先）URIが特定のダイアログのリモートターゲットURIと同等である場合、そのダイアログのダイアログ要素はそのサブスクライバーに対して抑制されます。（サブスクライバーはすでにダイアログ内の当事者であるため、これらの通知は不要です。）ダイアログを抑制した後にダイアログが残っていない場合、そのサブスクライバーへの通知全体が抑制され、ダイアログINFO要素のバージョン番号はそのサブスクライバーでは増加しません。1つのサブスクライバーの暗黙のフィルタリングは、他のサブスクライバーへの通知に影響しません。
o Notifications do not normally contain full state; rather, they only indicate the state of the dialog(s) whose state has changed. The exceptions are a NOTIFY sent in response to a SUBSCRIBE, and a NOTIFY that contains no dialog elements. These NOTIFYs contain the complete view of dialog state.
o 通知には通常、完全な状態が含まれていません。むしろ、状態が変化したダイアログの状態のみを示しています。例外は、購読に応じて送信された通知と、ダイアログ要素が含まれていない通知です。これらの通知には、ダイアログ状態の完全なビューが含まれています。
o The notifications contain the identities of the participants in the dialog, the target URIs, and the dialog identifiers. Session descriptions are not included unless explicitly requested and explicitly authorized.
o 通知には、ダイアログ、ターゲットURIS、およびダイアログ識別子の参加者の同一性が含まれています。明示的に要求され、明示的に許可されない限り、セッションの説明は含まれません。
Dialog state changes fairly quickly. Once established, a typical phone call lasts a few minutes (this is different for other session types, of course). However, the interval between new calls is typically long. Clients SHOULD specify an explicit duration.
ダイアログ状態はかなり迅速に変更されます。確立されると、典型的な電話は数分続きます（もちろん、これは他のセッションタイプで異なります）。ただし、新しい呼び出し間の間隔は通常長いです。クライアントは、明示的な期間を指定する必要があります。
There are two distinct use cases for dialog state. The first is when a subscriber is interested in the state of a specific dialog or dialogs (and they are authorized to find out just the state of those dialogs). In that case, when the dialogs terminate, so too does the subscription. In these cases, the value of the subscription duration is largely irrelevant; it SHOULD be longer than the typical duration of a dialog. We recommend a default duration of two hours, which is likely to cover most dialogs.
ダイアログ状態には2つの異なるユースケースがあります。1つ目は、サブスクライバーが特定のダイアログまたはダイアログの状態に関心がある場合です（そして、それらのダイアログの状態のみを見つけることが許可されています）。その場合、ダイアログが終了すると、サブスクリプションも終了します。これらの場合、サブスクリプション期間の値はほとんど無関係です。ダイアログの典型的な期間よりも長くなるはずです。2時間のデフォルトの期間を推奨します。これは、ほとんどのダイアログをカバーする可能性があります。
In another case, a subscriber is interested in the state of all dialogs for a specific user. In these cases, a shorter interval makes more sense. The default is one hour for these subscriptions.
別のケースでは、サブスクライバーは特定のユーザーのすべてのダイアログの状態に関心があります。これらの場合、より短い間隔がより理にかなっています。これらのサブスクリプションのデフォルトは1時間です。
As described in RFC 3265 [1], the NOTIFY message will contain bodies that describe the state of the subscribed resource. This body is in a format listed in the Accept header field of the SUBSCRIBE, or in a package-specific default format if the Accept header field was omitted from the SUBSCRIBE.
RFC 3265 [1]で説明されているように、Notifyメッセージには、購読されたリソースの状態を記述するボディが含まれます。この本体は、サブスクライブの承認ヘッダーフィールドにリストされている形式、またはサブスクライブから承認ヘッダーフィールドが省略された場合はパッケージ固有のデフォルト形式です。
In this event package, the body of the notification contains a dialog information document. This document describes the state of one or more dialogs associated with the subscribed resource. All subscribers and notifiers MUST support the "application/ dialog-info+xml" data format described in Section 4. The subscribe request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/dialog-info+xml". If the header field is present, it MUST include "application/ dialog-info+xml", and it MAY include any other types capable of representing dialog state.
このイベントパッケージでは、通知の本文にはダイアログ情報ドキュメントが含まれています。このドキュメントでは、購読されたリソースに関連付けられた1つ以上のダイアログの状態について説明します。すべてのサブスクライバーと通知者は、セクション4で説明した「アプリケーション/ダイアログINFO XML」データ形式をサポートする必要があります。購読要求には、受け入れヘッダーフィールドを含めることができます。そのようなヘッダーフィールドが存在しない場合、「Application/Dialog-INFO XML」のデフォルト値があります。ヘッダーフィールドが存在する場合、「Application/ Dialog-info 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 dialog information for a user contains sensitive information. Therefore, all subscriptions SHOULD be authenticated and then authorized before approval. All implementors of this package MUST support the digest authentication mechanism as a baseline. The authorization policy is at the discretion of the administrator, as always. However, a few recommendations can be made.
ユーザーのダイアログ情報には、機密情報が含まれています。したがって、すべてのサブスクリプションは認証され、承認前に承認される必要があります。このパッケージのすべての実装者は、ベースラインとしてのダイジェスト認証メカニズムをサポートする必要があります。許可ポリシーは、いつものように、管理者の裁量にあります。ただし、いくつかの推奨事項を作成できます。
It is RECOMMENDED that, if the policy of user B is that user A is allowed to call them, dialog subscriptions from user A be allowed. However, the information provided in the notifications does not contain any dialog identification information, merely an indication of whether the user is in at least one call. Specifically, they should not be able to find out any more information than if they sent an INVITE. (This concept of a "virtual" dialog is discussed more in Section 3.7.2, and an example of such a notification body is shown below).
ユーザーBのポリシーがユーザーAがそれらを呼び出すことを許可されている場合、ユーザーAからのサブスクリプションをダイアログすることを許可することをお勧めします。ただし、通知で提供される情報には、ダイアログ識別情報が含まれていません。これは、ユーザーが少なくとも1つの呼び出しであるかどうかを示すだけです。具体的には、招待状を送信した場合よりも多くの情報を見つけることができないはずです。（「仮想」ダイアログのこの概念については、セクション3.7.2で詳しく説明しており、そのような通知本体の例を以下に示します）。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="full"
entity="sip:alice@example.com">
<dialog id="as7d900as8">
<state>confirmed</state>
</dialog>
</dialog-info>
A user agent that registers with the address-of-record X SHOULD authorize subscriptions that come from any entity that can authenticate itself as X. Complete information on the dialog state SHOULD be sent in this case. This authorization behavior allows a group of devices representing a single user to become aware of each other's state. This is useful for applications such as single-line-extension, also known as shared lines.
Resord-of-Record Xで登録するユーザーエージェントは、Xとして認証できるエンティティから生じるサブスクリプションを承認する必要があります。この場合、ダイアログ状態の情報を完成させる必要があります。この承認行動により、単一のユーザーを表すデバイスのグループがお互いの状態を認識することができます。これは、共有行とも呼ばれるシングルラインエクステンションなどのアプリケーションに役立ちます。
Note that many implementations of "shared-lines" have a feature that allows details of calls on a shared address-of-record to be made private. This is a completely reasonable authorization policy that could result in notifications that contain only the id attribute of the dialog element and the state element when shared-line privacy is requested, and notifications with more complete information when shared-line privacy is not requested.
「共有ライン」の多くの実装には、共有された住所の通話の詳細がプライベートになる機能があることに注意してください。これは、共有ラインプライバシーが要求された場合にダイアログ要素のID属性と状態要素のみを含む通知を、共有ラインプライバシーが要求されない場合はより完全な情報を含む通知をもたらす可能性のある完全に合理的な承認ポリシーです。
Notifications are generated for the dialog package when an INVITE request is sent, when a new dialog comes into existence at a UA, or when the state or characteristics of an existing dialog changes. Therefore, a model of dialog state is needed in order to determine precisely when to send notifications, and what their content should be. The SIP specification has a reasonably well defined lifecycle for dialogs. However, it is not explicitly modelled. This specification provides an explicit model of dialog state through a finite state machine.
招待リクエストが送信されたとき、UAで新しいダイアログが存在するとき、または既存のダイアログの状態または特性が変更されたときに、ダイアログパッケージに対して通知が生成されます。したがって、通知をいつ送信するか、およびそのコンテンツがどうあるべきかを正確に決定するために、ダイアログ状態のモデルが必要です。SIP仕様には、ダイアログ用の合理的に定義されたライフサイクルがあります。ただし、明示的にモデル化されていません。この仕様は、有限状態マシンを介したダイアログ状態の明示的なモデルを提供します。
It is RECOMMENDED that NOTIFY requests only contain information on the dialogs whose state or participation information has changed. However, if a notifier receives a SUBSCRIBE request, the triggered NOTIFY SHOULD contain the state of all dialogs that the subscriber is authorized to see.
Notifyリクエストには、状態または参加情報が変更されたダイアログに関する情報のみを含めることをお勧めします。ただし、通知者がサブスクライブリクエストを受信した場合、トリガーされたNotifyには、サブスクライバーが確認することが許可されているすべてのダイアログの状態を含める必要があります。
Modelling of dialog state is complicated by two factors. The first is forking, which can cause a single INVITE to generate many dialogs at a UAC. The second is the differing views of state at the UAC (user agent client) and UAS (usage agent server). We have chosen to handle the first issue by extending the dialog finite state machine (FSM) to include the states between transmission of the INVITE and the creation of actual dialogs through receipt of 1xx and 2xx responses. As a result, this specification supports the notion of dialog state for dialogs before they are fully instantiated.
ダイアログ状態のモデリングは、2つの要因によって複雑になります。1つ目はフォーキングです。これにより、1つの招待状がUACで多くのダイアログを生成する可能性があります。2つ目は、UAC（ユーザーエージェントクライアント）とUAS（使用エージェントサーバー）の状態の異なるビューです。ダイアログの有限状態マシン（FSM）を拡張して、招待の送信と実際のダイアログの作成と1xxと2xxの応答の作成との間に状態を含めることにより、最初の問題を処理することを選択しました。その結果、この仕様は、ダイアログが完全にインスタンス化される前のダイアログの概念をサポートします。
We have also chosen to use a single FSM for both UAC and UAS.
また、UACとUASの両方に単一のFSMを使用することも選択しました。
+----------+ +----------+
| | 1xx-notag | |
| |----------->| |
| Trying | |Proceeding|-----+
| |---+ +-----| | |
| | | | | | |
+----------+ | | +----------+ |
| | | | | |
| | | | | |
+<--C-----C--+ |1xx-tag |
| | | | |
cancelled| | | V |
rejected| | |1xx-tag +----------+ |
| | +------->| | |2xx
| | | | |
+<--C--------------| Early |-----C---+ 1xx-tag
| | replaced | | | | w/new tag
| | | |<----C---+ (new FSM
| | +----------+ | instance
| | 2xx | | created)
| +----------------+ | |
| | |2xx |
| | | |
V V V |
+----------+ +----------+ |
| | | | |
| | | | |
|Terminated|<-----------| Confirmed|<----+
| | error | |
| | timeout | |
+----------+ replaced +----------+
local-bye | ^
remote-bye | |
| |
+------+
2xx w. new tag
(new FSM instance
created)
Figure 3
図3
The FSM for dialog state is shown in Figure 3. The FSM is best understood by considering the UAC and UAS cases separately.
ダイアログ状態のFSMを図3に示します。FSMは、UACとUASのケースを個別に考慮することで最もよく理解されています。
The FSM is created in the Trying state when the UAC sends an INVITE request. Upon receipt of a 1xx without a tag, the FSM transitions to the Proceeding state. Note that there is no actual dialog yet, as defined by the SIP specification. However, there is a "half-dialog", in the sense that two of the three components of the dialog ID (the call identifier and local tag) are known. If a 1xx with a tag is received, the FSM transitions to the Early state. The full dialog identifier is now defined. Had a 2xx been received, the FSM would have transitioned to the Confirmed state.
FSMは、UACが招待リクエストを送信するときに試行状態で作成されます。タグなしで1xxを受け取ると、FSMは議事録状態に移行します。SIP仕様で定義されているように、実際のダイアログはまだありません。ただし、ダイアログIDの3つのコンポーネントのうち2つ（コール識別子とローカルタグ）が既知であるという意味で、「ハーフダイアログ」があります。タグを含む1XXが受信された場合、FSMは初期状態に移行します。完全なダイアログ識別子が定義されました。2xxが受け取られていれば、FSMは確認された状態に移行していました。
If, after transitioning to the Early or Confirmed states, the UAC receives another 1xx or 2xx respectively with a different tag, another instance of the FSM is created, initialized into the Early or Confirmed state, respectively. The benefit of this approach is that there will be a single FSM representing the entire state of the invitation and resulting dialog when dealing in the common case of no forking.
初期または確認された状態に移行した後、UACが別のタグでそれぞれ別の1xxまたは2xxを受信した場合、FSMの別のインスタンスが作成され、それぞれ初期または確認された状態に初期化されます。このアプローチの利点は、ノーフォークの一般的なケースを扱う際に、招待状の完全な状態と結果の対話を表す単一のFSMがあることです。
If the UAC sends a CANCEL and then subsequently receives a 487 to its INVITE transaction, all FSMs spawned from that INVITE transition to the Terminated state with the event "cancelled". If the UAC receives a new invitation (with a Replaces [13] header) that replaces the current Early or Confirmed dialog, all INVITE transactions spawned from the replaced invitation transition to the Terminated state with the event "replaced". If the INVITE transaction terminates with a non-2xx response for any other reason, all FSMs spawned from that INVITE transition to the Terminated state with the event "rejected".
UACがキャンセルを送信し、その後487を招待トランザクションに受信した場合、すべてのFSMがイベント「キャンセル」で終了状態への招待状の移行から生まれました。UACが現在の早期または確認されたダイアログを置き換える新しい招待状（交換[13]ヘッダーを使用して）を受け取った場合、すべての招待状のトランザクションは、イベント「交換」で終了した状態への交換された招待状の移行から生まれました。Inviteトランザクションが他の理由で非2XX応答で終了した場合、すべてのFSMは、イベント「拒否」で終了した状態への招待から生まれました。
Once in the Confirmed state, the call is active. It can transition to the Terminated state if the UAC sends a BYE or receives a BYE (corresponding to the "local-bye" and "remote-bye" events as appropriate), if a mid-dialog request generates a 481 or 408 response (corresponding to the "error" event), or a mid-dialog request generates no response (corresponding to the "timeout" event).
確認された状態に入ると、呼び出しはアクティブになります。UACがさようならを送信したり、さようなら（必要に応じて「ローカル」および「リモートバイ」イベントに対応する場合）を受信した場合、終了状態に移行できます。中ダイアログリクエストが481または408の応答（「エラー」イベントに対応）を生成する場合、またはミッドダイアログリクエストは「イベント」に対応していません。
From the perspective of the UAS, when an INVITE is received, the FSM is created in the Trying state. If it sends a 1xx without a tag, the FSM transitions to the Proceeding state. If a 1xx is sent with a tag, the FSM transitions to the Early state, and if a 2xx is sent, it transitions to the Confirmed state. If the UAS receives a CANCEL request and then generates a 487 response to the INVITE (which can occur in the Proceeding and Early states), the FSM transitions to the Terminated state with the event "cancelled". If the UAS generates any other non-2xx final response to the INVITE request, the FSM transitions to the Terminated state with the event "rejected". If the UAS receives a new invitation (with a Replaces [13] header field) that replaces the current Confirmed dialog, the replaced invitation transitions to the Terminated state with the event "replaced". Once in the Confirmed state, the other transitions to the Terminated state occur for the same reasons they do in the case of UAC.
UASの観点から、招待状を受け取ったとき、FSMは試行状態で作成されます。タグなしで1xxを送信する場合、FSMは議事録に移行します。1xxがタグで送信されると、FSMは初期状態に移行し、2xxが送信されると、確認された状態に移行します。UASがキャンセル要求を受信し、招待に対する487の応答（議事録および初期状態で発生する可能性がある）の場合、FSMはイベント「キャンセル」で終了状態に移行します。UASが招待要求に対する他の非2XX最終応答を生成する場合、FSMはイベント「拒否」で終了状態に移行します。UASが現在の確認されたダイアログを置き換える新しい招待状（交換[13]ヘッダーフィールド）を受け取った場合、イベント「交換」に招待された招待状の移行を終了した状態に置き換えます。確認された状態に入ると、UACの場合に行うのと同じ理由で、終了状態への他の遷移が発生します。
There should never be a transition from the Trying state to the Terminated state with the event "cancelled", since the SIP specification prohibits transmission of CANCEL until a provisional response is received. However, this transition is defined in the FSM just to unify the transitions from Trying, Proceeding, and Early states to the Terminated state.
SIP仕様は暫定的な応答が受信されるまでキャンセルの送信を禁止するため、イベント「キャンセル」で試行状態から終了状態への移行は決してありません。ただし、この遷移は、試行、進行、および初期状態から終了状態への移行を統一するためだけにFSMで定義されています。
The notifier MAY generate a NOTIFY request on any event transition of the FSM. Whether it does or not is policy dependent. However, some general guidelines are provided.
Notifierは、FSMの任意のイベントトランジションでNotifyリクエストを生成する場合があります。それがそうであるかどうかは政策依存です。ただし、いくつかの一般的なガイドラインが提供されています。
When the subscriber is unauthenticated, or it is authenticated but represents a third party with no specific authorization policies, it is RECOMMENDED that subscriptions to an individual dialog or to a specific set of dialogs be forbidden. Only subscriptions to all dialogs (i.e., there are no dialog identifiers in the Event header field) are permitted. In that case, actual dialog states across all dialogs will not be reported. Rather, a single "virtual" dialog FSM will be used, and event transitions on that FSM will be reported.
サブスクライバーが認証されていないが、認証されているが、特定の認可ポリシーがない第三者を表す場合、個々のダイアログまたは特定のダイアログセットへのサブスクリプションを禁止することをお勧めします。すべてのダイアログ（つまり、イベントヘッダーフィールドにダイアログ識別子はありません）へのサブスクリプションのみが許可されます。その場合、すべてのダイアログの実際のダイアログ状態は報告されません。むしろ、単一の「仮想」ダイアログFSMが使用され、そのFSMのイベント遷移が報告されます。
If there is any dialog at the UA whose state is Confirmed, the virtual FSM is in the Confirmed state. If there are no dialogs at the UA in the Confirmed state but there is at least one in the Early state, the virtual FSM is in the Early or Confirmed state. If there are no dialogs in the Confirmed or Early states but there is at least one in the Proceeding state, the virtual FSM is in the Proceeding, Early, or Confirmed state. If there are no dialogs in the Confirmed, Early, or Proceeding states but there is at least one in the Trying state, the virtual FSM is in the Trying, Proceeding, Early or Confirmed state. The choice of state to use depends on whether the UA wishes to let unknown users know that their phone is ringing, as opposed to being in an active call.
状態が確認されているUAにダイアログがある場合、仮想FSMは確認された状態にあります。確認された状態のUAにダイアログがないが、初期状態に少なくとも1つある場合、仮想FSMは初期または確認された状態にあります。確認された状態または初期状態に対話がないが、手続き状態に少なくとも1つある場合、仮想FSMは議事録、早期、または確認された状態にあります。確認された状態、早期、または手続きの状態にダイアログがないが、試練状態に少なくとも1つがある場合、仮想FSMは試行、進行、早期、または確認された状態にあります。使用する状態の選択は、UAがアクティブな電話をかけるのではなく、不明なユーザーに電話が鳴っていることを知らせたいかどうかによって異なります。
It is RECOMMENDED that, in the absence of any preference, Confirmed is used in all cases as shown in the example in Section 3.6. Furthermore, it is RECOMMENDED that the notifications of changes in the virtual FSM machine not convey any information except the state of the FSM and its event transitions - no dialog identifiers (which are ill-defined in this model in any case). The use of this virtual FSM allows minimal information to be conveyed. A subscriber cannot know how many calls are in progress, or with whom, just that there exists a call. This is the same information they would receive if they simply sent an INVITE to the user instead; a 486 (Busy Here) response would indicate that they are on a call.
セクション3.6の例に示すように、すべての場合に、好みがない場合、確認されたことを確認することをお勧めします。さらに、仮想FSMマシンの変更の通知は、FSMの状態とそのイベントトランジションを除く情報を伝えないことをお勧めします - ダイアログ識別子（いずれにしてもこのモデルでは不明確です）。この仮想FSMを使用すると、最小限の情報を伝えることができます。サブスクライバーは、コールが何回進行しているか、または誰と一緒に電話が存在するかを知ることができません。これは、代わりにユーザーに招待を送信した場合に受け取る情報と同じです。486（ここでは忙しい）応答は、それらが電話中であることを示します。
When the subscriber is authenticated and has authenticated itself with the same address-of-record that the UA itself uses, if no explicit authorization policy is defined, it is RECOMMENDED that all state transitions on dialogs that have been subscribed to be reported, along with complete dialog IDs. This means either all of the dialogs, if no dialog identifiers were present in the Event header field, or the specific set of dialogs identified by the Event header field parameters.
サブスクライバーが認証され、UA自体が使用するのと同じ記録アドレスで認証された場合、明示的な承認ポリシーが定義されていない場合、報告されているダイアログのすべての状態遷移と完全なダイアログIDとともに推奨することをお勧めします。これは、イベントヘッダーフィールドにダイアログ識別子が存在しなかった場合、すべてのダイアログのいずれか、またはイベントヘッダーフィールドパラメーターによって識別される特定のダイアログセットのいずれかを意味します。
The notifier SHOULD generate a NOTIFY request on any change in the characteristics associated with the dialog. Since these include Contact URIs, Contact parameters, and session descriptions, receipt of re-INVITEs and UPDATE requests [3] that modify this information MAY trigger notifications.
Notifierは、ダイアログに関連付けられた特性の変更に関するNotifyリクエストを生成する必要があります。これらには、連絡先のURI、連絡先パラメーター、セッションの説明、再インバイトの受信、およびこの情報を変更する[3]の更新要求が含まれるため、通知がトリガーされる場合があります。
The SIP Events framework expects packages to specify how a subscriber processes NOTIFY requests in package-specific ways. In particular, a package should specify how it uses the NOTIFY requests to construct a coherent view of the state of the subscribed resource.
SIPイベントフレームワークでは、パッケージがパッケージ固有の方法でサブスクライバープロセスがリクエストに通知する方法を指定することを期待しています。特に、パッケージは、通知要求を使用して、購読されたリソースの状態の一貫したビューを作成する方法を指定する必要があります。
Typically, the NOTIFY for the dialog package will contain information about only those dialogs whose state has changed. To construct a coherent view of the total state of all dialogs, a subscriber to the dialog package will need to combine NOTIFYs received over time.
通常、ダイアログパッケージのNotifyには、状態が変更されたダイアログのみに関する情報が含まれます。すべてのダイアログの合計状態の一貫したビューを作成するには、ダイアログパッケージのサブスクライバーを時間とともに受け取った通知を組み合わせる必要があります。
Notifications within this package can convey partial information; that is, they can indicate information about a subset of the state associated with the subscription. This means that an explicit algorithm needs to be defined in order to construct coherent and consistent state. The details of this mechanism are specific to the particular document type. See Section 4.3 for information on constructing coherent information from an application/dialog-info+xml document.
このパッケージ内の通知は、部分的な情報を伝えることができます。つまり、サブスクリプションに関連する状態のサブセットに関する情報を示すことができます。これは、コヒーレントで一貫した状態を構築するために、明示的なアルゴリズムを定義する必要があることを意味します。このメカニズムの詳細は、特定のドキュメントタイプに固有です。アプリケーション/ダイアログINFO XMLドキュメントからコヒーレント情報の作成については、セクション4.3を参照してください。
Since dialog state is distributed across the UA for a particular user, it is reasonable and useful for a SUBSCRIBE request for dialog state to fork and to reach multiple UAs.
ダイアログ状態は特定のユーザーに対してUA全体に配布されるため、ダイアログ状態のフォークおよび複数のUAに到達するためのサブスクライブリクエストに合理的かつ便利です。
As a result, a forked SUBSCRIBE request for dialog state can install multiple subscriptions. Subscribers to this package MUST be prepared to install subscription state for each NOTIFY generated as a result of a single SUBSCRIBE.
その結果、ダイアログ状態のフォークサブスクライブリクエストは、複数のサブスクリプションをインストールできます。このパッケージの購読者は、単一のサブスクライブの結果として生成された各notifyのサブスクリプション状態をインストールする準備をする必要があります。
For reasons of congestion control, it is important that the rate of notifications not be excessive. It is RECOMMENDED that the server not generate notifications for a single subscriber faster than once every 1 second.
混雑制御の理由により、通知率が過度にないことが重要です。サーバーは、1秒ごとに1回よりも速く単一のサブスクライバーの通知を生成しないことをお勧めします。
Dialog state is ideally maintained in the user agents in which the dialog resides. Therefore, the elements that maintain the dialog are the ones best suited to handle subscriptions to it. However, in some cases, a network agent may also know the state of the dialogs held by a user. Such state agents MAY be used with this package.
ダイアログ状態は、ダイアログが存在するユーザーエージェントで理想的に維持されます。したがって、ダイアログを維持する要素は、サブスクリプションを処理するのに最適な要素です。ただし、場合によっては、ネットワークエージェントは、ユーザーが保持しているダイアログの状態も知っている場合があります。このような状態エージェントは、このパッケージで使用できます。
Dialog information is an XML document [4] that MUST be well-formed and SHOULD be valid. Dialog 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 dialog 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:dialog-info
A dialog information document begins with the root element tag "dialog-info".
ダイアログ情報ドキュメントは、ルート要素タグ「ダイアログインフォ」から始まります。
A dialog information document starts with a dialog-info element. This element has three mandatory attributes:
ダイアログ情報ドキュメントは、ダイアログINFO要素から始まります。この要素には3つの必須属性があります。
o version: This attribute allows the recipient of dialog 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 non-negative 32 bit integer.
o バージョン：この属性により、ダイアログ情報ドキュメントの受信者が適切に注文できるようになります。バージョンは0から始まり、サブスクライバーに送信される新しいドキュメントごとに1つずつ増加します。バージョンはサブスクリプション内でスコープされます。バージョンは、非陰性の32ビット整数を使用して表現できる必要があります。
o state: This attribute indicates whether the document contains the full dialog information, or whether it contains only information on those dialogs that have changed since the previous document (partial).
o 状態：この属性は、ドキュメントに完全なダイアログ情報が含まれているかどうか、または以前のドキュメント以降に変更されたダイアログに関する情報のみを含むかどうかを示します（部分）。
o entity: This attribute contains a URI that identifies the user whose dialog information is reported in the remainder of the document. This user is referred to as the "observed user".
o エンティティ：この属性には、ドキュメントの残りの部分でダイアログ情報が報告されているユーザーを識別するURIが含まれています。このユーザーは「観測されたユーザー」と呼ばれます。
The dialog-info element has a series of zero or more dialog sub-elements. Each of those represents a specific dialog. An example:
ダイアログINFO要素には、一連のゼロ以上のダイアログサブエレメントがあります。それらはそれぞれ特定のダイアログを表します。例：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" notify-state="full"
entity="sip:alice@example.com">
</dialog-info>
The dialog element reports information about a specific dialog or "half-dialog". It has a single mandatory attribute: id. The id attribute provides a single string that can be used as an identifier for this dialog or "half-dialog". This is a different identifier than the dialog ID defined in RFC 3261 [2], but related to it.
ダイアログ要素は、特定のダイアログまたは「ハーフダイアログ」に関する情報を報告します。単一の必須属性があります：id。ID属性は、このダイアログまたは「ハーフダイアログ」の識別子として使用できる単一の文字列を提供します。これは、RFC 3261 [2]で定義されているダイアログIDとは異なる識別子ですが、それに関連しています。
For a caller, the id is created when an INVITE request is sent. When a 1xx response with a tag, or a 2xx response is received, the dialog is formally created. The id remains unchanged. However, if an additional 1xx or 2xx is received, resulting in the creation of another dialog (and resulting FSM), that dialog is allocated a new id.
発信者の場合、IDは招待リクエストが送信されるときに作成されます。タグを使用した1xx応答、または2xx応答が受信されると、ダイアログが正式に作成されます。IDは変更されていません。ただし、追加の1xxまたは2xxが受信され、別のダイアログ（および結果として生じるFSM）が作成された場合、そのダイアログに新しいIDが割り当てられます。
For a callee, the id is created when an INVITE outside of an existing dialog is received. When a 2xx or a 1xx with a tag is sent, creating the dialog, the id remains unchanged.
Calleeの場合、IDは既存のダイアログの外側の招待状が受信されたときに作成されます。2xxまたはタグを使用した1xxが送信されると、ダイアログを作成すると、IDは変更されません。
The id MUST be unique amongst all current dialogs at a UA.
IDは、UAの現在のすべてのダイアログの中で一意でなければなりません。
There are a number of optional attributes that provide identification information about the dialog:
ダイアログに関する識別情報を提供する多くのオプションの属性があります。
o call-id: This attribute is a string that represents the call-id component of the dialog identifier. (Note that single and double quotes inside a call-id must be escaped using "e; for " and ' for ' .)
o call-id：この属性は、ダイアログ識別子のcall-idコンポーネントを表す文字列です。（call-id内の単一の引用符と二重引用符は、 "and＆apos; for 'for' for 'for"を使用して逃げなければならないことに注意してください。）
o local-tag: This attribute is a string that represents the local-tag component of the dialog identifier.
o ローカルタグ：この属性は、ダイアログ識別子のローカルタグコンポーネントを表す文字列です。
o remote-tag: This attribute is a string that represents the remote-tag component of the dialog identifier. The remote tag attribute won't be present if there is only a "half-dialog", resulting from the generation of an INVITE for which no final responses or provisional responses with tags has been received.
o リモートタグ：この属性は、ダイアログ識別子のリモートタグコンポーネントを表す文字列です。「ハーフダイアログ」のみがある場合、リモートタグ属性は存在しません。これは、タグを含む最終的な応答や暫定的な応答が受信されていない招待状の生成に起因します。
o direction: This attribute is either initiator or recipient, and indicates whether the observed user was the initiator of the dialog, or the recipient of the INVITE that created it.
o 方向：この属性はイニシエーターまたは受信者のいずれかであり、観察されたユーザーがダイアログのイニシエーターであるか、それを作成した招待の受信者であるかを示します。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" direction="initiator">
...
</dialog>
</dialog-info>
The sub-elements of the dialog element provide additional information about the dialog. Some of these sub-elements provide more detail about the dialog itself, while the local and remote sub-elements describe characteristics of the participants involved in the dialog. The only mandatory sub-element is the state element.
ダイアログ要素のサブ要素は、ダイアログに関する追加情報を提供します。これらのサブエレメントの一部は、ダイアログ自体についてより詳細な詳細を提供しますが、ローカルおよびリモートサブエレメントは、ダイアログに関与する参加者の特性を説明しています。唯一の必須サブ要素は状態要素です。
The "state" element indicates the state of the dialog. Its value is an enumerated type describing one of the states in the FSM above. It has an optional event attribute that can be used to indicate the event that caused any transition into the terminated state, and an optional code attribute that indicates the response code associated with any transition caused by a response to the original INVITE.
「状態」要素は、ダイアログの状態を示します。その値は、上記のFSMの州の1つを説明する列挙型です。オプションのイベント属性を使用して、終了状態への移行を引き起こすイベントを示すために使用できるオプションのイベント属性と、元の招待への応答に起因する遷移に関連する応答コードを示すオプションのコード属性があります。
<state event="rejected" code="486">terminated</state>
The "duration" element contains the amount of time, in seconds, since the FSM was created.
「持続時間」要素には、FSMが作成されてから数秒で時間が含まれています。
<duration>145</duration>
The "replaces" element is used to correlate a new dialog with one it replaced as a result of an invitation with a Replaces header field. This element is present in the replacement dialog only (the newer dialog) and contains attributes with the call-id, local-tag, and remote-tag of the replaced dialog.
「交換」要素は、新しいダイアログと交換された新しいダイアログと、交換ヘッダーフィールドを交換するために使用されます。この要素は、交換ダイアログのみ（新しいダイアログ）に存在し、交換されたダイアログのコールID、ローカルタグ、およびリモートタグの属性が含まれています。
<replaces call-id="hg287s98s89"
local-tag="6762h7" remote-tag="09278hsb"/>
The "referred-by" element is used to correlate a new dialog with a REFER [12] request that triggered it. The element is present in a dialog that was triggered by a REFER request that contained a Referred-By [11] header field and contains the (optional) display name attribute and the Referred-By URI as its value.
「参照」要素は、新しいダイアログを参照[12]リクエストをトリガーしたリクエストと相関させるために使用されます。この要素は、参照[11]ヘッダーフィールドを含み、（オプションの）表示名属性を含む紹介要求とその値として紹介されたURIを含むダイアログに存在します。
<referred-by display="Bob">sip:bob@example.com</referred-by>
The "local" and "remote" elements are sub-elements of the dialog element that contain information about the local and remote participants, respectively. They both have a number of optional sub-elements that indicate the identity conveyed by the participant, the target URI, the feature-tags of the target, and the session-description of the participant.
「ローカル」および「リモート」要素は、それぞれローカルおよびリモートの参加者に関する情報を含むダイアログ要素のサブエレメントです。どちらにも、参加者、ターゲットURI、ターゲットの機能タグ、および参加者のセッションデスプトリーによって伝えられるアイデンティティを示す多くのオプションのサブエレメントがあります。
The "identity" element indicates a local or remote URI, as defined in [2] as appropriate. It has an optional attribute, display, that contains the display name from the appropriate URI.
「ID」要素は、必要に応じて[2]で定義されているように、ローカルまたはリモートのURIを示します。適切なURIのディスプレイ名を含むオプションの属性、ディスプレイがあります。
Note that multiple identities (for example a sip: URI and a tel: URI) could be included if they all correspond to the participant. To avoid repeating identity information in each request, the subscriber can assume that the identity URIs are the same as in previous notifications if no identity elements are present in the corresponding local or remote element. If any identity elements are present in the local or remote part of a notification, the new list of identity tags completely supersedes the old list in the corresponding part.
複数のアイデンティティ（たとえば、SIP：URIとTEL：URI）がすべて参加者に対応する場合は含めることができることに注意してください。各リクエストでID情報の繰り返しを避けるために、サブスクライバーは、対応するローカルまたはリモート要素にID要素が存在しない場合、ID urisが以前の通知と同じであると想定できます。通知のローカルまたはリモート部分にID要素が存在する場合、IDタグの新しいリストは、対応する部分の古いリストに完全に置き換えられます。
<identity display="Anonymous">
sip:anonymous@anonymous.invalid</identity>
The "target" contains the local or remote target URI constructed by the user agent for this dialog, as defined in RFC 3261 [2] in a "uri" attribute.
「ターゲット」には、「URI」属性のRFC 3261 [2]で定義されているように、このダイアログのユーザーエージェントによって構築されたローカルまたはリモートのターゲットURIが含まれます。
It can contain a list of Contact header parameters in param sub-elements (such as those defined in [10]). The param element contains two required attributes, pname and pval. Boolean parameters are represented by the explicit pval values, "true" and "false" (for example, when a feature parameter is explicitly negated). Parameters that have no value at all are represented by the explicit pval value "true". The param element itself has no contents. To avoid repeating Contact information in each request, the subscriber can assume that the target URI and parameters are the same as in previous notifications if no target element is present in the corresponding local or remote element. If a target element is present in the local or remote part of a notification, the new target tag and list of parameter tags completely supersedes the old target and parameter list in the corresponding part. Note that any quoting (including extra angle-bracket quoting used to quote string values in [10]) or backslash escaping MUST be removed before being placed in a pval attribute. Any remaining single quotes, double quotes, and ampersands MUST be properly XML escaped.
PARAMサブエレメント（[10]で定義されているものなど）のコンタクトヘッダーパラメーターのリストを含めることができます。PARAM要素には、必要な2つの属性、PNAMEとPVALが含まれます。ブールパラメーターは、明示的なPVal値「true」および「false」（たとえば、特徴パラメーターが明示的に無効にされる場合）で表されます。値がまったくないパラメーターは、明示的なpval値「true」で表されます。PARAM要素自体には内容がありません。各要求で連絡先情報を繰り返すことを避けるために、サブスクライバーは、対応するローカルまたはリモート要素にターゲット要素が存在しない場合、ターゲットURIとパラメーターが以前の通知と同じであると仮定できます。通知のローカルまたはリモート部分にターゲット要素が存在する場合、パラメータータグの新しいターゲットタグとリストは、対応する部分の古いターゲットとパラメーターリストに完全に置き換えられます。[10]で文字列値を引用するために使用される角度ブラケットの引用を含む引用符を含む）またはバックスラッシュエスケープは、pval属性に配置する前に削除する必要があることに注意してください。残りの単一の引用、二重引用符、およびアンパサンドは、XMLを適切に逃がす必要があります。
<target uri="sip:alice@pc33.example.com">
<param pname="isfocus" pval="true"/>
<param pname="class" pval="business"/>
<param pname="description" pval="Alice's desk & office"/>
<param pname="sip.rendering" pval="no"/>
</target>
The session-description element contains the session description used by the observed user for its end of the dialog. This element should generally NOT be included in the notifications, unless it was explicitly requested by the subscriber. It has a single attribute, "type", which indicates the MIME media type of the session description. To avoid repeating session description information in each request, the subscriber can assume that the session description is the same as in previous notifications if no session description element is present in the corresponding local or remote element.
セッションと説明要素には、ダイアログの終わりに観察されたユーザーが使用するセッションの説明が含まれています。この要素は、サブスクライバーによって明示的に要求されていない限り、一般に通知に含めるべきではありません。セッションの説明のmimeメディアタイプを示す単一の属性「タイプ」があります。各リクエストでセッションの説明情報を繰り返すことを避けるために、サブスクライバーは、セッションの説明が対応するローカルまたはリモート要素に存在しない場合、以前の通知と同じであると仮定できます。
<?xml version="1.0" encoding="UTF-8"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:dialog-info"
version="1" state="full">
<dialog id="123456">
<state>confirmed</state>
<duration>274</duration>
<local>
<identity display="Alice">sip:alice@example.com</identity>
<target uri="sip:alice@pc33.example.com">
<param pname="isfocus" pval="true"/>
<param pname="class" pval="personal"/>
</target>
</local>
<remote>
<identity display="Bob">sip:bob@example.org</identity>
<target uri="sip:bobster@phone21.example.org"/>
</remote>
</dialog>
</dialog-info>
The dialog information subscriber maintains a table listing the dialogs, with a row for each dialog. Each row is indexed by an ID that is present in the "id" attribute of the "dialog" element. Each row contains the state of that dialog, as conveyed in the document.
ダイアログ情報サブスクライバーは、ダイアログをリストするテーブルを維持し、各ダイアログの行を行います。各行は、「ダイアログ」要素の「ID」属性に存在するIDによってインデックス付けされます。各行には、ドキュメントで伝えられているように、そのダイアログの状態が含まれています。
The table is also associated with a version number. The version number MUST be initialized with the value of the "version" attribute from the "dialog-info" element in the first document received. Each time a new document is received, the value of the local version number is compared to the "version" attribute in the new document. 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 and the document is processed. If the document did not contain full state, the subscriber SHOULD generate a refresh request (SUBSCRIBE) to trigger a full state notification. If the value in the document is less than the local version, the document is discarded without processing.
テーブルはバージョン番号にも関連付けられています。バージョン番号は、受信した最初のドキュメントの「ダイアログINFO」要素の「バージョン」属性の値で初期化する必要があります。新しいドキュメントを受信するたびに、ローカルバージョン番号の値は、新しいドキュメントの「バージョン」属性と比較されます。新しいドキュメントの値がローカルバージョン番号よりも1つ高い場合、ローカルバージョン番号は1つずつ増加し、ドキュメントが処理されます。ドキュメントの値がローカルバージョン番号よりも複数高い場合、ローカルバージョン番号は新しいドキュメントの値に設定され、ドキュメントが処理されます。ドキュメントに完全な状態が含まれていなかった場合、サブスクライバーは完全な状態通知をトリガーするために更新要求（サブスクライブ）を生成する必要があります。ドキュメントの値がローカルバージョンよりも少ない場合、ドキュメントは処理せずに破棄されます。
The processing of the dialog information 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 "dialog-info" element, the contents of the table are flushed and then repopulated from the document. A new row in the table is created for each "dialog" element. If the document contains partial state, as indicated by the value of the "state" attribute in the "dialog-info" element, the document is used to update the table. For each "dialog" element in the document, the subscriber checks to see whether a row exists for that dialog. This check compares the ID in the "id" attribute of the "dialog" element with the ID associated with the row. If the dialog does not exist in the table, a row is added and its state is set to the information from that "dialog" element. If the dialog does exist, its state is updated to be the information from that "dialog" 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.
ダイアログ情報ドキュメントの処理は、完全な状態か部分状態が含まれているかによって異なります。「ダイアログINFO」要素の「状態」属性の値によって示される完全な状態が含まれている場合、テーブルの内容がフラッシュされ、ドキュメントから再貯蔵されます。テーブル内の新しい行は、各「ダイアログ」要素に対して作成されます。「ダイアログINFO」要素の「状態」属性の値で示されるように、ドキュメントに部分的な状態が含まれている場合、ドキュメントはテーブルの更新に使用されます。ドキュメント内の各「ダイアログ」要素について、サブスクライバーはそのダイアログの行が存在するかどうかを確認します。このチェックは、「ダイアログ」要素の「ID」属性のIDを行に関連付けられたIDと比較します。ダイアログがテーブルに存在しない場合、行が追加され、その状態はその「ダイアログ」要素からの情報に設定されます。ダイアログが存在する場合、その状態はその「ダイアログ」要素からの情報に更新されます。行が更新または作成されている場合、その状態が現在終了するように、そのエントリはいつでもテーブルから削除される場合があります。
The following is the schema for the application/dialog-info+xml type:
以下は、アプリケーション/ダイアログ-INFO XMLタイプのスキーマです。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:dialog-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:dialog-info"
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="dialog-info">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:dialog" 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:attribute name="entity" type="xs:anyURI"
use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="dialog">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:state" minOccurs="1" maxOccurs="1"/>
<xs:element name="duration" type="xs:nonNegativeInteger"
minOccurs="0" maxOccurs="1"/>
<xs:element name="replaces" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:attribute name="call-id" type="xs:string"
use="required"/>
<xs:attribute name="local-tag" type="xs:string"
use="required"/>
<xs:attribute name="remote-tag" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="referred-by" type="tns:nameaddr"
minOccurs="0" maxOccurs="1"/>
<xs:element name="route-set" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="hop" type="xs:string"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="local" type="tns:participant"
minOccurs="0" maxOccurs="1"/>
<xs:element name="remote" type="tns:participant"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="call-id" type="xs:string"
use="optional"/>
<xs:attribute name="local-tag" type="xs:string"
use="optional"/>
<xs:attribute name="remote-tag" type="xs:string"
use="optional"/>
<xs:attribute name="direction" use="optional">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="initiator"/>
<xs:enumeration value="recipient"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:complexType name="participant">
<xs:sequence>
<xs:element name="identity" type="tns:nameaddr"
minOccurs="0" maxOccurs="1"/>
<xs:element name="target" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="param" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="pname" type="xs:string"
use="required"/>
<xs:attribute name="pval" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="uri" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="session-description" type="tns:sessd"
minOccurs="0" maxOccurs="1"/>
<xs:element name="cseq" type="xs:nonNegativeInteger"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="nameaddr">
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="display-name" type="xs:string"
use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="sessd">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="type" type="xs:string"
use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="state">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="event" use="optional">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="cancelled"/>
<xs:enumeration value="rejected"/>
<xs:enumeration value="replaced"/>
<xs:enumeration value="local-bye"/>
<xs:enumeration value="remote-bye"/>
<xs:enumeration value="error"/>
<xs:enumeration value="timeout"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="code" use="optional">
<xs:simpleType>
<xs:restriction base="xs:positiveInteger">
<xs:minInclusive value="100"/>
<xs:maxInclusive value="699"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema>
This section defines two new media feature parameters that are useful as input to user presence, in conferencing applications, and in applications like the shared-line example described in Section 6.2. These feature parameters are especially useful in combination with the dialog package, as they allow an authorized third party to become aware of these characteristics.
このセクションでは、ユーザーの存在への入力、会議アプリケーション、およびセクション6.2で説明した共有ラインの例のようなアプリケーションで有用な2つの新しいメディア機能パラメーターを定義します。これらの機能パラメーターは、ダイアログパッケージと組み合わせて特に役立ちます。これは、認定された第三者がこれらの特性を認識できるようにするためです。
The "sip.byeless" media feature parameter is a new boolean parameter, defined in this document, that provides a positive indication that the user agent setting the parameter is unable to terminate sessions on its own (for example, by sending a BYE request). For example, continuous announcement services and certain recording services are unable to determine when it would be desirable to terminate a session, and therefore they do not have the ability to terminate sessions at all. Also, many human call centers are configured so that they never terminate sessions. (This is to prevent call center agents from accidentally disconnecting the caller). (Note that per [10], this parameter name must be preceded by a "+" character when used in a SIP Contact header field.)
「sip.byless」メディア機能パラメーターは、このドキュメントで定義されている新しいブールパラメーターであり、パラメーターを設定するユーザーエージェントが独自のセッションを終了できないという肯定的な兆候を提供します（たとえば、Byeリクエストを送信することで）。たとえば、継続的な発表サービスと特定の録音サービスは、セッションを終了することがいつ望ましいかを判断できないため、セッションをまったく終了する能力がありません。また、多くの人間のコールセンターが設定されているため、セッションを終了しないようにしています。（これは、コールセンターのエージェントが誤って発信者を切断しないようにするためです）。（[10]によると、このパラメーター名の前には、SIP連絡先ヘッダーフィールドで使用された場合は「」文字が先行する必要があります。）
Contact: <sip:recording-service@host.example.net>
;automaton;+sip.byeless
The "sip.rendering" media feature parameter is a new string parameter, defined in this document, that can provide a positive indication whether the user agent setting the parameter is currently rendering any of the media it is receiving in the context of a specific session. It MUST only be used in a Contact header field in a dialog created using the INVITE request.
「SIP.RENDERING」メディア機能パラメーターは、このドキュメントで定義されている新しい文字列パラメーターであり、ユーザーエージェントがパラメーターを設定している場合、特定のセッションのコンテキストで受信しているメディアのいずれかを現在設定しているかどうかを提供できます。Inviteリクエストを使用して作成されたダイアログのコンタクトヘッダーフィールドでのみ使用する必要があります。
This parameter has three legal values: "yes", "no", and "unknown". The value "yes" indicates positive knowledge that the user agent is rendering at least one of the streams of media that it is receiving. The value "no" indicates positive knowledge that the user agent is rendering none of the media that it is receiving. The value "unknown" indicates that the user agent does not know whether the media associated with the session is being rendered (which may be the case if the user agent is acting as a 3pcc (Third Party Call Control) [19] controller).
このパラメーターには、「はい」、「いいえ」、「不明」の3つの法的価値があります。値「はい」は、ユーザーエージェントが受け取っているメディアのストリームの少なくとも1つをレンダリングしているという肯定的な知識を示しています。値「いいえ」は、ユーザーエージェントが受け取っているメディアのいずれもレンダリングしていないという肯定的な知識を示しています。値「不明」は、ユーザーエージェントがセッションに関連付けられたメディアがレンダリングされているかどうかを知らないことを示しています（ユーザーエージェントが3PCC（サードパーティコールコントロール）[19]コントローラーとして機能している場合はそうです）。
The "sip.rendering" parameter is useful in applications such as shared appearances, conference status monitoring, or as an input to user presence.
「SIP.RENDERING」パラメーターは、共有外観、会議のステータス監視、またはユーザーの存在への入力などのアプリケーションで役立ちます。
Contact: <sip:musak-onhold@host.example.net>
;automaton;+sip.rendering="no"
For example, if a UAC sends an INVITE that looks, in part, like:
たとえば、UACが次のように見える招待状を送信した場合：
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.example.com>
Content-Type: application/sdp
Content-Length: 142
[SDP not shown]
[SDPが表示されていない]
The XML document in a notification from Alice might look like:
アリスからの通知のXMLドキュメントは、次のように見えるかもしれません。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0"
state="full"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" direction="initiator">
<state>trying</state>
</dialog>
</dialog-info>
If the following 180 response is received:
次の180回の回答が受信された場合：
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.com>;tag=456887766
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:bob@host.example.com>
The XML document in a notification might look like:
通知のXMLドキュメントは次のように見える場合があります。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="1"
state="full"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="456887766"
direction="initiator">
<state>early</state>
</dialog>
</dialog-info>
If it receives a second 180 with a different tag:
別のタグで2番目の180を受信した場合：
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.com>;tag=hh76a
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:jack@host.example.com>
This results in the creation of a second dialog:
これにより、2番目のダイアログが作成されます。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="2"
state="full"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="456887766"
direction="initiator">
<state>early</state>
</dialog>
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a"
direction="initiator">
<state>early</state>
</dialog>
</dialog-info>
If a 200 OK response is received on the second dialog, the dialog moves to confirmed:
2番目のダイアログで200のOK応答が受信された場合、ダイアログは確認されました。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="3"
state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a"
direction="initiator">
<state>confirmed</state>
</dialog>
</dialog-info>
32 seconds later, the other early dialog terminates because no 2xx response has been received for it. This implies that it was successfully cancelled, and therefore the following notification is sent:
32秒後、2xxの応答が受信されていないため、他の初期のダイアログが終了します。これは、それが正常にキャンセルされたことを意味するため、次の通知が送信されます。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="4"
state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a"
direction="initiator">
<state event="cancelled">terminated</state>
</dialog>
</dialog-info>
The following example shows how a SIP telephone user agent can provide detailed state information and also emulate a shared-line telephone system (the phone "lies" about having a dialog while it is merely offhook).
次の例は、SIP電話ユーザーエージェントが詳細な状態情報を提供し、共有線の電話システムをエミュレートする方法を示しています（電話は、単にオフフックである間にダイアログを持つことについて「嘘をついている」）。
Idle:
アイドル：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="full"
entity="sip:alice@example.com">
</dialog-info>
Seized:
押収：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="1" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8">
<state>trying</state>
</dialog>
</dialog-info>
Dialing:
ダイヤル：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="2" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" direction="initiator">
<state>trying</state>
<local>
<identity display="Alice Smith">
sip:alice@example.com
</identity>
<target uri="sip:alice@pc33.example.com"/>
</local>
<remote>
<identity>sip:bob@example.net</identity>
</remote>
</dialog>
</dialog-info>
Ringing:
鳴る：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="3" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="07346y131" direction="initiator">
<state code="180">early</state>
<remote>
<target uri="sip:bobster@host2.example.net"/>
</remote>
</dialog>
</dialog-info>
Answered (by voicemail):
回答（ボイスメールによる）：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="4" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="07346y131" direction="initiator">
<state reason="cancelled">terminated</state>
</dialog>
<dialog id="zxcvbnm3" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="8736347" direction="initiator">
<state code="200">confirmed</state>
<remote>
<target uri="sip:bob-is-not-here@vm.example.net">
<param pname="actor" pval="msg-taker"/>
<param pname="automaton" pval="true"/>
<param pname="+sip.byeless" pval="true"/>
</target>
</remote>
</dialog>
</dialog-info>
Alice would rather talk to Bob's assistant (Cathy Jones) than to Bob's voicemail. She indicates this preference by pressing a key (perhaps "0" in North America or "9" in Europe). Bob's voicemail system then acts on this keypress by transferring [20] Alice's call to Cathy's AOR.
アリスは、ボブのボイスメールよりもボブのアシスタント（キャシー・ジョーンズ）と話すことを望んでいます。彼女は、キー（おそらく北米では「0」またはヨーロッパでは「9」）を押すことでこの好みを示しています。その後、ボブのボイスメールシステムは、[20]アリスのキャシーのAORへの呼び出しを転送することにより、このキープレスに作用します。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="5" state="partial"
entity="sip:alice@example.com">
<dialog id="zxcvbnm3" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="8736347" direction="initiator">
<state reason="replaced">terminated</state>
</dialog>
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state reason="replaced">confirmed</state>
<replaces call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="8736347"/>
<referred-by>
sip:bob-is-not-here@vm.example.net
</referred-by>
<local>
<target uri="sip:alice@pc33.example.com"/>
<param pname="+sip.rendering" pval="yes"/>
</local>
<remote>
<identity display="Cathy Jones">
sip:cjones@example.net
</identity>
<target uri="sip:line3@host3.example.net">
<param pname="actor" pval="attendant"/>
<param pname="automaton" pval="false"/>
</target>
</remote>
</dialog>
</dialog-info>
Alice and Cathy talk, Cathy adds Alice to a local conference:
アリスとキャシーの話、キャシーはアリスを地元の会議に追加します：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="6" state="partial"
entity="sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state>confirmed</state>
<remote>
<target uri="sip:confid-34579@host3.example.net">
<param pname="isfocus" pval="true"/>
</target>
</remote>
</dialog>
</dialog-info>
Alice puts Cathy on hold:
アリスはキャシーを保留にします：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="7" state="partial"
entity="sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state>confirmed</state>
<local>
<target uri="sip:alice@pc33.example.com"/>
<param pname="+sip.rendering" pval="no"/>
</target>
</local>
</dialog>
</dialog-info>
Cathy hangs up:
キャシーが切れる：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="8" state="partial"
entity="sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state reason="remote-bye">terminated</state>
</dialog>
<dialog id="08hjh1345">
<state>trying</state>
</dialog>
</dialog-info>
Alice hangs up:
アリスが電話を切る：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="9" state="full"
entity="sip:alice@example.com">
</dialog-info>
The following example shows the same user agent providing minimal information to maintain privacy for services like automatic callback.
次の例は、自動コールバックなどのサービスのプライバシーを維持するための最小限の情報を提供する同じユーザーエージェントを示しています。
Onhook:
Onhook：
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="full"
entity="sip:alice@example.com">
</dialog-info>
Offhook: (implementation/policy choice for Alice to transition to this "state" when "seized", when Trying, when Proceeding, or when Confirmed.)
Offhook ：（アリスがこの「状態」に移行するための実装/ポリシーの選択、「押収された」、試行時、手続き、または確認時に。）
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="1" state="full"
entity="sip:alice@example.com">
<dialog id="1">
<state>confirmed</state>
</dialog>
</dialog-info>
Onhook: (implementation/policy choice for Alice to transition to this "state" when terminated, or when no longer "seized")
Onhook ：（アリスが終了したとき、または「押収されなくなったときにこの「状態」に移行するための実装/ポリシーの選択）
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="2" state="full"
entity="sip:alice@example.com">
</dialog-info>
Subscriptions to dialog state can reveal sensitive information. For this reason, Section 3.6 discusses authentication and authorization of subscriptions, and provides guidelines on sensible authorization policies. All implementations of this package MUST support the digest authentication mechanism.
ダイアログ状態へのサブスクリプションは、機密情報を明らかにすることができます。このため、セクション3.6では、サブスクリプションの認証と承認について説明し、賢明な承認ポリシーに関するガイドラインを提供します。このパッケージのすべての実装は、ダイジェスト認証メカニズムをサポートする必要があります。
Since the data in notifications is sensitive as well, end-to-end SIP encryption mechanisms using S/MIME MAY be used to protect it. User agents that implement the dialog package SHOULD also implement SIP over TLS [15] and the sips: scheme.
通知のデータも敏感であるため、S/MIMEを使用したエンドツーエンドのSIP暗号化メカニズムを使用して保護することができます。ダイアログパッケージを実装するユーザーエージェントは、TLS [15]およびSIPS：スキームを介してSIPを実装する必要があります。
This document registers a new MIME type, application/dialog-info+xml; a new XML namespace; and two new media feature parameters in the SIP tree.
このドキュメントは、新しいMIMEタイプ、アプリケーション/ダイアログインフォXMLを登録します。新しいXMLネームスペース。SIPツリーの2つの新しいメディア機能パラメーター。
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: dialog-info+xml
MIMEサブタイプ名：Dialog-info 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 that use this media type: This document type has been used to support SIP applications such as call return and auto-conference.
このメディアタイプを使用するアプリケーション：このドキュメントタイプは、コールリターンや自動会議などのSIPアプリケーションをサポートするために使用されています。
Additional Information:
追加情報：
Magic Number: None File Extension: .xml Macintosh file type code: "TEXT"
マジック番号：なしファイル拡張子：.xml 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, per the guidelines in [7].
このセクションでは、[7]のガイドラインに従って、新しいXML名前空間を登録します。
URI: The URI for this namespace is urn:ietf:params:xml:ns:dialog-info.
URI：この名前空間のURIはurn：ietf：params：xml：ns：dialog-infoです。
Registrant Contact: The IESG, <iesg@ietf.org> XML:
登録者の連絡先：IESG、<iesg@ietf.org> 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>Dialog Information Namespace</title>
</head>
<body>
<h1>Namespace for Dialog Information</h1>
<h2>urn:ietf:params:xml:ns:dialog-info</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4235.txt">
RFC4235</a>.</p>
</body>
</html>
END
This specification registers a schema, per the guidelines in [7].
この仕様は、[7]のガイドラインに従って、スキーマを登録します。
URI: urn:ietf:params:xml:schema:dialog-info
Registrant Contact: The IESG, <iesg@ietf.org>
XML: The XML can be found as the sole content of Section 4.4.
XML：XMLは、セクション4.4の唯一の内容として見つけることができます。
This section registers two new media feature tags, per the procedures defined in RFC 2506 [14]. The tags are placed into the sip tree, which is defined in [10].
このセクションでは、RFC 2506 [14]で定義されている手順に従って、2つの新しいメディア機能タグを登録します。タグは、[10]で定義されているSIPツリーに配置されます。
ASN.1 Identifier 19
ASN.1識別子19
Summary of the media feature indicated by this tag: This feature tag is a boolean flag. When set it indicates that the device is incapable of terminating a session autonomously.
このタグで示されるメディア機能の概要：この機能タグはブールフラグです。設定すると、デバイスがセッションを自律的に終了できないことを示します。
Values appropriate for use with this feature tag: Boolean.
この機能タグで使用するのに適した値：boolean。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of an application, such as an announcement service, recording service, conference, or call center.
機能タグは、主に以下のアプリケーション、プロトコル、サービス、またはネゴシエーションメカニズムで使用するためのものです。この機能タグは、アナウンスサービス、レコーディングサービス、会議、コールセンターなど、アプリケーションの機能を説明するための通信アプリケーションで最も役立ちます。
Examples of typical use: Call centers and media services.
典型的な使用の例：コールセンターとメディアサービス。
Related standards or documents: RFC 4235 Security Considerations: This media feature tag can be used in ways that affect application behaviors or may reveal private information. For example, a conferencing or other application may decide to terminate a call prematurely if this media feature tag is set. Therefore, if an attacker can modify the values of this tag, they may be able to affect the behavior of applications. As a result of this, applications that utilize this media feature tag SHOULD provide a means for ensuring its integrity. Similarly, this feature tag should only be trusted as valid when it comes from the user or user agent described by the tag. As a result, protocols for conveying this feature tag SHOULD provide a mechanism for guaranteeing authenticity.
関連標準またはドキュメント：RFC 4235セキュリティに関する考慮事項：このメディア機能タグは、アプリケーションの動作に影響を与える方法で使用できます。たとえば、このメディア機能タグが設定されている場合、会議またはその他のアプリケーションは、通話を時期尚早に終了することを決定する場合があります。したがって、攻撃者がこのタグの値を変更できる場合、アプリケーションの動作に影響を与える可能性があります。この結果、このメディア機能タグを利用するアプリケーションは、その完全性を確保するための手段を提供するはずです。同様に、この機能タグは、タグで説明されているユーザーまたはユーザーエージェントからの場合にのみ有効であると信頼する必要があります。その結果、この機能タグを伝えるためのプロトコルは、信頼性を保証するメカニズムを提供するはずです。
Media feature tag name: sip.rendering
メディア機能タグ名：sip.Rendering
ASN.1 Identifier: 20
ASN.1識別子：20
Summary of the media feature indicated by this tag: This feature tag contains one of three string values indicating if the device is rendering any media from the current session ("yes"), none of the media from the current session ("no"), or if this status is not known to the device ("unknown").
このタグで示されるメディア機能の概要：この機能タグには、現在のセッション（「はい」）のメディアをデバイスがレンダリングしているかどうかを示す3つの文字列値のいずれかが含まれています。
Values appropriate for use with this feature tag: String.
この機能タグで使用するのに適した値：文字列。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application, for describing the state of a device (such as a phone or PDA) during a multimedia session.
機能タグは、主に以下のアプリケーション、プロトコル、サービス、またはネゴシエーションメカニズムで使用するためのものです。この機能タグは、マルチメディアセッション中のデバイス（電話やPDAなど）の状態を説明するために、通信アプリケーションで最も役立ちます。
Examples of typical use: Conferencing, telephone shared-line emulation, and presence applications.
典型的な使用の例：会議、電話共有線のエミュレーション、および存在アプリケーション。
Related standards or documents: RFC 4235
関連標準または文書：RFC 4235
Security Considerations: This media feature tag can be used in ways that affect application behaviors or may reveal private information. For example, a conferencing or other application may decide to terminate a call prematurely if this media feature tag is set to "no". Therefore, if an attacker can modify the values of this tag, they may be able to affect the behavior of applications. As a result of this, applications that utilize this media feature tag SHOULD provide a means for ensuring its integrity. Similarly, this feature tag should only be trusted as valid when it comes from the user or user agent described by the tag. As a result, protocols for conveying this feature tag SHOULD provide a mechanism for guaranteeing authenticity.
セキュリティ上の考慮事項：このメディア機能タグは、アプリケーションの動作に影響を与える方法や個人情報を明らかにする方法で使用できます。たとえば、このメディア機能タグが「いいえ」に設定されている場合、会議またはその他のアプリケーションは、コールを時期尚早に終了することを決定する場合があります。したがって、攻撃者がこのタグの値を変更できる場合、アプリケーションの動作に影響を与える可能性があります。この結果、このメディア機能タグを利用するアプリケーションは、その完全性を確保するための手段を提供するはずです。同様に、この機能タグは、タグで説明されているユーザーまたはユーザーエージェントからの場合にのみ有効であると信頼する必要があります。その結果、この機能タグを伝えるためのプロトコルは、信頼性を保証するメカニズムを提供するはずです。
The authors would like to thank Sean Olson for his comments.
著者は、ショーン・オルソンのコメントに感謝したいと思います。
[1] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[1] Roach、A.B。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INIATION PROTOCOL "、RFC 3261、2002年6月。
[3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[3] Rosenberg、J。、「セッション開始プロトコル（SIP）更新方法」、RFC 3311、2002年10月。
[4] Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C FirstEdition REC-xml-20001006, October 2000.
[4] Paoli、J.、Sperberg-Mcqueen、C.、Bray、T。、およびE. Maler、「拡張可能なマークアップ言語（XML）1.0（第2版）」、W3C Firstedition Rec-XML-20001006、2000年10月。
[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] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[10] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[10] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[11] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004.
[11] Sparks、R。、「セッション開始プロトコル（SIP）がメカニズムを参照」、RFC 3892、2004年9月。
[12] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[12] Sparks、R。、「セッション開始プロトコル（SIP）参照メソッド」、RFC 3515、2003年4月。
[13] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[13] Mahy、R.、Biggs、B。、およびR. Dean、「セッション開始プロトコル（SIP）」「ヘッダー」、RFC 3891、2004年9月に置き換えられます。
[14] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999.
[14] Holtman、K.、Mutz、A。、およびT. Hardie、「メディア機能タグ登録手順」、BCP 31、RFC 2506、1999年3月。
[15] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[15] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[16] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[16] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、2004年8月。
[17] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004.
[17] Rosenberg、J。、「セッション開始プロトコル（SIP）のウォッチャー情報イベントテンプレートパッケージ」、RFC 3857、2004年8月。
[18] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.
[18] Mahy、R。、「セッション開始プロトコル（SIP）のメッセージの概要とメッセージ待機表示イベントパッケージ」、RFC 3842、2004年8月。
[19] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[19] Rosenberg、J.、Peterson、J.、Schulzrinne、H。、およびG. Camarillo、「セッション開始プロトコル（SIP）における第三者コールコントロール（3PCC）の最良の現在のプラクティス」、2004年4月、BCP 85、RFC 3725。
[20] Sparks, R., "Session Initiation Protocol Call Control - Transfer", Work in Progress, July 2005.
[20] Sparks、R。、「セッション開始プロトコルコールコントロール - 転送」、2005年7月、進行中の作業。
Authors' Addresses
著者のアドレス
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサンローゼンバーグシスコシステム600ラニデックスプラザパルシッパニー、ニュージャージー07054米国
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US
ヘニングシュルツリンコロンビア大学M/S 0401 1214 AMSTERDAM AVE. NEW YORK、NY 10027 US
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Rohan Mahy (editor) SIP Edge LLC
Rohan Mahy（編集者）SIP Edge LLC
EMail: rohan@ekabal.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供され、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する、または後援する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
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://ww.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エディター機能の資金は現在、インターネット協会によって提供されています。