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)
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態については、「Internet Official Protocol Standards」（STD 01）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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イベントアーキテクチャ用のダイアログイベントパッケージを定義します。ダイアログ・パッケージには、ユーザーが別のユーザーに購読すると加入-にユーザーが関与するINVITEが開始した対話用法の状態の変更の通知を受け取ることができます。
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]に定義されています。この文書では、INVITEが開始したダイアログの用途のためにイベントパッケージを定義します。ダイアログは、2つのSIPピア[2]との間に確立されたSIPの関係を指します。 INVITE方法：RFC 3261は一つだけを定義しているがダイアログは、多くの方法によって作成することができます。 RFC 3265 [1]は、新しいダイアログ用法を作成SUBSCRIBE及びNOTIFYメソッドを定義します。しかし、非セッション]ダイアログ用途に状態をモデル化するために、このパッケージを使用すると、この仕様の範囲外です。
A variety of applications are enabled through knowledge of INVITE dialog usage state. Some examples include:
様々なアプリケーションは、INVITEダイアログ使用状態の知識によって有効になっています。いくつかの例は次のとおりです。
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の電話が鳴ります。 Bでダイアログが完了したときに通知を受信するためのAが拾ったとき、それらはSIPを用いてこれを実現するためにBに接続されている間、彼らは、呼び出し音が聞こえ、機構が必要です。
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のためのコールステートフルプロキシとして機能し、したがってそれらの呼状態を知っています。これは、常にしかし、ことはできません、それは、スケーラビリティ、信頼性、および運用の複雑さを紹介します。第二の方法では、サーバーは、それらのユーザーの対話状態に加入すると、この状態が変化するよう通知を受け取ります。これは、分散方法で提供するアプリケーションを可能にします。サーバーは、ユーザーと同じドメインに存在する必要はありません。
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会議アラート：。誰かが電話が関与していることを会議に参加するたび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つの新しい呼び出し先機能[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
UAがもはや関心のあるSIPユーザエージェント（UA）は、（例えば、いくつかの発表または記録サービスで、またはいくつかのコールセンターに）セッション自体を終了することができないことを示し、○「sip.byeless」、参加中。そして
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.
ユーザエージェントは、それが受信されたメディアの任意のレンダリングされたか否かを積極的に説明○「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.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" 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つのイベントパッケージのパラメータを定義していますから、タグにタグ、IDを呼び出し、セッション記述が含まれています。特定のダイアログへのサブスクリプションが要求されている場合、これらのパラメータの最初の3つはに加入されているダイアログを識別するために、存在しなければなりません。タグからタグリモートタグと照合され、コールIDがコール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（ユーザエージェントクライアント）によって送信されたINVITE単一の結果として作成されたダイアログのセットに加入することも可能です。その場合には、コールIDとにタグが存在しなければなりません。タグローカルタグと照合され、コール-idはコール-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は以下の通りです。それは、EQUAL、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"
callid = "callid" EQUAL（トークン/ DQUOTEはDQUOTE callid）;;注：callid内の任意のDQUOTEsをエスケープしなければなりません！タグ=「からタグ」EQUALトークンにタグ=「とタグ」EQUALトークンと-sessd =「含むセッション記述」を
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.
任意のコールIDが埋め込まれた二重引用符が含まれている場合は、それらの二重引用符はバックスラッシュクォートメカニズムを使用してエスケープする必要があります。コール-idパラメータは引用符付きの文字列として表現される必要があり得ることに留意されたいです。 callidによって使用さcallid生産ワード生産のためのABNFは、（両方のRFCから3261 [1]）、許可するためである（例えば、「@」、「[」、およびAS「：」）いくつかの文字でありますトークン内で使用できません。
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.
ダイアログパッケージのSUBSCRIBEリクエストは、体を含むかもしれません。このボディは、サブスクリプションに適用するフィルタを定義します。フィルタの文書は、この文書で指定されていない、と書いている時点で、彼らは将来の標準化活動の対象となることが期待されています。
A SUBSCRIBE request for a dialog package MAY be sent without a body. This implies the default subscription filtering policy. The default policy is:
ダイアログパッケージのSUBSCRIBEリクエストは、本体なしで送信されるかもしれません。これがデフォルトのサブスクリプションのフィルタリングポリシーを意味します。デフォルトポリシーは次のとおりです。
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、通知は、SUBSCRIBEのリクエストURIで識別されたユーザのための任意のマッチングダイアログの状態に変化があるたびに生成されます。
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.
Eventヘッダーフィールドには、ダイアログ識別子がなかった場合は、O、通知は次の例外を除いてSUBSCRIBEのリクエストURIで識別されるユーザのための任意のダイアログの状態に変化があるたびに生成されます。加入者のターゲット（接触）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通知は、通常、完全な状態を含んでいません。むしろ、彼らは唯一の状態が変化したダイアログ（複数可）の状態を示しています。例外は、SUBSCRIBEに応答して送信され、それが何のダイアログ要素を含まないNOTIFY NOTIFYされています。これらのNOTIFYは、ダイアログの状態の完全なビューが含まれています。
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.
通知は、ダイアログの参加者の身元、ターゲットのURI、およびダイアログ識別子が含まれているO。明示的に要求して明示的に許可しない限り、セッション記述が含まれていません。
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つの異なるユースケースがあります。加入者が特定のダイアログまたはダイアログの状態に興味を持っている（と彼らはこれらのダイアログのちょうど状態を調べるために許可されている）ときに最初です。その場合は、ダイアログが終了したときに、そのあまりにもサブスクリプションを行います。これらのケースでは、サブスクリプション期間の値は、主に無関係です。それは、ダイアログの典型的な期間より長くする必要があります。私たちは、ほとんどのダイアログをカバーする可能性がある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メッセージは、サブスクライブリソースの状態を記述する体を含むであろう。 AcceptヘッダーフィールドはSUBSCRIBEから省略された場合には、この本体は、SUBSCRIBEのAcceptヘッダーフィールドにリストされた形式で、またはパッケージ固有のデフォルトフォーマットです。
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つのまたは複数のダイアログの状態を説明しています。すべての加入者及び届出者は、リクエストがAcceptヘッダーフィールドを含むかもしれ購読セクション4に記載された「アプリケーション/ダイアログ-情報+ xmlの」データ・フォーマットをサポートしなければなりません。もしそのようなヘッダフィールドが存在しない場合は、「アプリケーション/ダイアログ-情報+ XML」のデフォルト値を持っています。ヘッダフィールドが存在する場合、それは「アプリケーション/ダイアログ情報+ 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.
もちろん、サーバによって生成された通知は、SUBSCRIBEリクエストにAcceptヘッダーフィールドに指定された形式のいずれかでなければなりません。
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回の呼び出しであるか否かを単に表示を任意のダイアログ識別情報が含まれていません。具体的には、彼らは、INVITEを送信した場合よりも任意のより多くの情報を見つけることができないはずです。 （「仮想」ダイアログのこの概念は、セクション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>
<？xml version = "1.0"？> <ダイアログ-情報のxmlns = "壷：IETF：のparams：XML：NS：ダイアログ・インフォ" バージョン= "0" の状態= "フル" の実体= "一口例：@アリス。 comの "> <ダイアログのid =" as7d900as8" > <状態>確認</状態> </ダイアログ> </ダイアログ、インフォメーション>
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.
アドレスのレコード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の存在に入ってくる、またはときに通知をINVITEリクエストを、ダイアログのパッケージのために生成されているが、送信されたときの状態や、既存のダイアログが変化の特性。そのため、対話状態のモデルは、通知を送信する際に、正確に決定するために必要とされ、その内容はどうあるべきか。 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リクエストをすることが推奨されます。ただし、通知がSUBSCRIBEリクエストを受信した場合、加入者が参照を許可されているすべてのダイアログの状態を含むべきである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.
対話状態のモデル化は、二つの要因によって複雑になります。最初は、単一のUACで多くのダイアログを生成するために、INVITEを引き起こす可能性が、フォークれます。第二は、UAC（ユーザエージェントクライアント）とUAS（使用エージェントサーバ）での状態の異なる見解です。私たちは、1XXの領収書と2xx応答を通じてINVITEの送信と実際のダイアログの作成の間に状態を含めるために、ダイアログ有限状態機械（FSM）を拡張することにより、最初の問題を処理することを選択しました。彼らは完全にインスタンス化される前に、その結果、この仕様は、ダイアログの対話状態の概念をサポートしています。
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は、FSMは最高別途UACとUAS例を考慮することによって理解され、図3に示されています。
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.
UACは、INVITEリクエストを送信するときFSMはしよう状態で作成されます。タグ無し1XXを受信すると、FSMは、進行状態に遷移します。 SIP仕様で定義され、実際のダイアログがまだ存在しないことに注意してください。しかし、ダイアログID（呼識別子とローカルタグ）の3つの成分の両者が知られているという意味で「半ダイアログ」があります。タグ付きの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はCANCEL送信し、その後そのINVITEトランザクションに487を受信した場合、すべてのFSMは、「キャンセル」イベントで終了状態への移行INVITEから生み出されました。 UACは、現在の初期または確認ダイアログを置き換える（はReplaces [13]ヘッダ付き）新しい招待を受信した場合、すべてのトランザクションをINVITEイベント「置換」で終了状態に置き換え招待遷移から生成されました。 INVITEトランザクションは、他の理由で2xx以外の応答で終了した場合、すべてのFSMは、イベントで終了状態への移行INVITEから生み出された「拒否」。
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は、BYEを送信するか（適宜「ローカルBYE」および「リモートBYE」イベントに対応）BYEを受信した場合、中間ダイアログ要求が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.
受信されたINVITE UASの観点から、FSMは、TRYING状態で作成されています。それは、タグなしの1xxを送信する場合、FSMは、進行状態に移行します。 1xxがタグ付きで送信された場合の2xxが送信される場合は、初期の状態にFSM遷移は、そして、それが確認された状態に移行します。 UASはCANCEL要求を受信し（進み及び初期状態で起こり得る）INVITEに対する487応答し、「キャンセル」イベントで終了状態にFSM遷移が発生した場合。 UASは、INVITEリクエストに対する任意の他の非2xxの最終応答を生成した場合は、イベントで終了状態への遷移はFSM「拒否しました」。 UASは、現在の確認ダイアログを置き換える（はReplaces [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仕様が暫定応答を受信するまでCANCELの送信を禁止するので、「キャンセル」イベントで終了状態しようとしている状態からの遷移があってはいけません。しかし、この移行は、単に終端状態に、しようと進み、そして初期の状態からの遷移を統一する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.
通知は、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で何のダイアログが確認された状態ではありませんが、初期状態の少なくとも一方が存在する場合、仮想FSMは、早期または確認状態にあります。何のダイアログが確認または初期状態ではありませんが、進行状態の少なくとも一つがある場合、仮想FSMは初期の議事録、または確認済みの状態です。何のダイアログが確認さに存在しない場合は、初期の、または状態を進むが、しようとした状態の少なくとも一つがあり、仮想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の使用は最小限の情報を伝達することを可能にします。加入者は、コールが存在するだけであること、進行中、または誰とどのように多くのコールを知ることができません。これは、彼らは単に代わりに、ユーザーにINVITEを送信した場合、彼らが受け取ることになる情報と同じです。 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.
通知は、ダイアログに関連した特性の変化にNOTIFYリクエストを生成する必要があります。これら以来連絡先のURI、連絡先のパラメータ、およびセッション記述、再招き、UPDATE要求の受信[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イベントフレームワークは、パッケージがサブスクライバプロセスはパッケージ固有の方法でNOTIFYリクエストをどのように指定することを期待します。特に、パッケージには、それが加入し、リソースの状態のコヒーレントなビューを構築するためにNOTIFYリクエストをどのように使用するかを指定する必要があります。
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。すべてのダイアログの総状態のコヒーレントなビューを構築するために、ダイアログ・パッケージへの加入者は、時間をかけて受け取ったの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.
このパッケージ内の通知は、部分的な情報を伝えることができます。つまり、彼らは、サブスクリプションに関連付けられている状態のサブセットに関する情報を示すことができます。これは、明示的なアルゴリズムが首尾一貫して一貫性のある状態を構築するために定義する必要があることを意味します。このメカニズムの詳細については、特定のドキュメントタイプに固有のものです。アプリケーション/ダイアログ-情報+ 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に到達するために対話状態のためのSUBSCRIBE要求に有用です。
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.
その結果、フォーク複数のサブスクリプションをインストールすることができます対話状態のためのSUBSCRIBEリクエスト。このパッケージへの加入者は、単一の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秒よりも単一の加入者のための通知を生成しないことをお勧めします。
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は、名前空間識別子「IETF」[6]で定義され、[7]によって拡張を使用して、URN [5]です。このURNは以下のとおりです。
urn:ietf:params:xml:ns:dialog-info
URN：IETF：のparams：XML：NS：ダイアログ-情報
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>
<？xml version = "1.0"？> <ダイアログ-情報のxmlns = "壷：IETF：のparams：XML：NS：ダイアログ・インフォ" バージョン= "0" 通知状態= "フル" の実体= "一口：アリス@ example.com "> </ダイアログ、インフォメーション>
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.
INVITEリクエストが送信された場合、発信者のために、IDが作成されます。タグ、または2xx応答との1xxレスポンスを受信すると、ダイアログが正式に作成されます。 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.
既存のダイアログのINVITE外部が受信されると呼び出し先のため、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コールID：この属性は、ダイアログ識別子のコールIDコンポーネントを表す文字列です。 （Call-IDを内側に単一引用符と二重引用符を使用して＆引用エスケープする必要があることに注意してください。そして＆ "のためのAPOS; 'のため。）
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リモートタグ：この属性は、ダイアログ識別子のリモートタグコンポーネントを表す文字列です。タグとは、最終的な応答または暫定的な応答を受信していないいるINVITEの発生に起因する、唯一の「半ダイアログ」がある場合、リモートタグ属性が存在しないであろう。
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方向：この属性は、イニシエータまたは受信者のいずれかであり、観測されたユーザーがダイアログのイニシエータ、またはそれを作成したINVITEの受信者であったかどうかを示します。
<?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>
<？xml version = "1.0"？> <ダイアログ-情報のxmlns = "壷：IETF：のparams：XML：NS：ダイアログ・インフォ" バージョン= "0" の状態= "部分" 実体= "一口例：@アリス。 comの "> <ダイアログのid =" as7d900as8" コールID = "a84b4c76e66710" ローカルタグ= "1928301774" 方向= "イニシエータ"> ... </ダイアログ> </ダイアログ、インフォメーション>
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に状態のいずれかを説明する列挙型です。これは、終了状態に任意の遷移、およびINVITE元に応答によって引き起こされる任意の遷移に関連付けられた応答コードを示すオプションコード属性を引き起こしたイベントを示すために使用することができる任意のイベント属性を有します。
<state event="rejected" code="486">terminated</state>
<状態イベント= "拒否" コード= "486">終了</状態>
The "duration" element contains the amount of time, in seconds, since the FSM was created.
FSMが作成されたので、「期間」の要素は、秒単位で、時間の量が含まれています。
<duration>145</duration>
<期間> 145 </期間>
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.
「置き換え」の要素は、それがReplacesヘッダーフィールドと招待の結果として、置換された1つで新しいダイアログを相関させるために使用されています。このエレメントは、置換ダイアログ（新しいダイアログ）に存在し、置換ダイアログの呼ID、ローカルタグ、およびリモートタグと属性が含まれています。
<replaces call-id="hg287s98s89" local-tag="6762h7" remote-tag="09278hsb"/>
<コールID = "hg287s98s89" ローカルタグ置き換え= "6762h7" リモートタグ= "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.
「呼ぶバイ」要素は、それをトリガREFER [12]要求に新しいダイアログを相関させるために使用されます。要素は呼ばバイ[11]ヘッダーフィールドを含み、（オプション）表示名、属性とその値と呼ばバイURIを含むREFER要求によってトリガされたダイアログで存在します。
<referred-by display="Bob">sip:bob@example.com</referred-by>
<呼ば-によって表示= "ボブ"> SIP：bob@example.com </換算により>
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.
適宜[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.
（例えば一口：URIおよびTEL：URI）は、その複数のIDに注意してください含めることができ、それらはすべての参加者に対応する場合。各リクエストのID情報を繰り返すことを避けるために、加入者には同一の要素は、対応するローカルまたはリモートの要素内に存在しない場合の同一のURIは、前の通知と同じであると仮定することができます。任意のアイデンティティ要素は、通知のローカルまたはリモートの部分に存在している場合は、アイデンティティタグの新しいリストが完全に対応する部分には古いリストに取って代わります。
<identity display="Anonymous"> sip:anonymous@anonymous.invalid</identity>
<アイデンティティ表示= "匿名"> SIP：anonymous@anonymous.invalid </アイデンティティ>
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.
RFC 3261で定義されるように、「標的」は、「URI」属性の[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.
これは、（例えば、[10]で定義されたものなど）のparamサブ要素でContactヘッダパラメータのリストを含むことができます。 param要素は、2つの必須属性、PNAMEとPVALが含まれています。ブールパラメータが明示的には、pval値で表され、「真」と「偽」（例えば、特徴パラメータが明示的に否定されている場合）。すべての値を持たないパラメータは、「真」の明示は、pval値で表されます。 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>
<ターゲットURI = "SIP：alice@pc33.example.com">の<param pnameに= "isfocus" は、pval = "真" />の<param pnameに= "クラス" は、pval = "営業" />の<param pnameに= "説明"PVAL =" アリスのデスク＆＃038;オフィス "/>の<param pnameに=" sip.rendering」は、pval = "なし" /> </ 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.
セッション-description要素は、ダイアログの終わりのために観測されたユーザーが使用するセッション記述が含まれています。それが明示的に加入者によって要求された場合を除き、この要素は、一般的に、通知に含めるべきではありません。これは、セッション記述の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>
<？xml version = "1.0" エンコード= "UTF-8"？> <ダイアログ-情報のxmlns = "壷：IETF：のparams：XML：NS：ダイアログ・情報" のxmlns：XSI = "のhttp：//www.w3 .ORG / 2001 / XMLスキーマ・インスタンス」のxsi：schemaLocationの= "壷：IETF：のparams：XML：NS：ダイアログ・インフォ" バージョン= "1" の状態= "フル"> <ダイアログのid = "123456"> <状態>確認</状態> <期間> 274 </期間>
<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>
<ローカル> <アイデンティティ表示= "アリス"> SIP：alice@example.com </アイデンティティ> <ターゲットURI = "SIP：alice@pc33.example.com">の<param pnameの=は、pval = "true" を "isfocus" /> <PARAMのpname = "クラス" は、pval = "個人" /> </ target>を</ローカル> <リモート> <アイデンティティ表示= "ボブ"> SIP：bob@example.org </アイデンティティ> <ターゲットURI = "SIP：bobster@phone21.example.org" /> </リモート> </ダイアログ> </ダイアログ、インフォメーション>
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.
テーブルは、バージョン番号に関連付けられています。バージョン番号は、受信した最初の文書内の「dialog-info」要素から「バージョン」属性の値で初期化されなければなりません。新しいドキュメントが受信されるたびに、ローカルのバージョン番号の値は、新しい文書の「バージョン」属性と比較されます。新しい文書の値がローカルのバージョン番号より1高い場合、ローカルのバージョン番号が1つずつ増加され、ドキュメントが処理されます。文書内の値がローカルのバージョン番号より高い複数ある場合は、ローカルのバージョン番号が新しい文書内の値に設定され、ドキュメントが処理されます。文書がフルの状態が含まれていなかった場合、加入者は、完全な状態の通知をトリガするためにリフレッシュ要求（SUBSCRIBE）を生成する必要があります。文書内の値がローカルのバージョンよりも小さい場合は、文書が処理せずに廃棄されます。
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.
ダイアログ情報文書の処理は、それが完全または部分的な状態が含まれているかどうかに依存します。それは完全な状態が含まれている場合は、「dialog-info」要素の「状態」属性の値によって示され、テーブルの内容をフラッシュし、文書から再作成されます。テーブルに新しい行が各「dialog」要素のために作成されます。文書は部分的状態が含まれている場合は、「dialog-info」要素の「状態」属性の値によって示されるように、文書には、テーブルを更新するために使用されます。文書内の各「ダイアログ」要素について、加入者は、行がそのダイアログのために存在するかどうかをチェックします。このチェックは、行に関連付けられたIDを持つ「ダイアログ」要素の「ID」属性にIDとを比較します。ダイアログがテーブルに存在しない場合、行が追加され、その状態はその「ダイアログ」要素からの情報に設定されています。ダイアログが存在しない場合、その状態は、「dialog」要素の情報に更新されます。行が更新または作成されている場合は、その状態が今終了したように、そのエントリは、いつでもテーブルから除去することができます。
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"/>
<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのtargetNamespace = "壷：IETF：のparams：XML：NS：ダイアログ・情報" のxmlns：XSの=の "のhttp：//www.w3 .ORG / 2001 / XMLスキーマ」のxmlns：TNS = "壷：IETF：のparams：XML：NS：ダイアログ・インフォ" のelementFormDefault = "資格" attributeFormDefault = "非修飾"> < - このインポートは、XML言語の属性xmlにもたらします！ ：LANG - > <XS：インポート名前空間= "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：要素名= "ダイアログ・インフォ"> <XS：complexTypeの> <XS：シーケンス> <XS：要素REF = "TNS：ダイアログ" のminOccurs = "0" のmaxOccurs = "無制限" /> <XS：任意の名前空間= "##その他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：シーケンス> <XS：属性名= "バージョン" タイプ= "XS：NonNegativeIntegerの" 使用は= "必要" /> <XS：属性名= "状態" の使用は= "必要"> <XS：単純> <XS：制限ベース= "XS：文字列"> <XS：列挙値= "フル" /> <XS：列挙値= /> </ XS "部分"：制限> </ XS：単純> </ XS：属性> <XS：属性名= "実体" タイプ= "XS：anyURIの" 使用= "必須" /> </ XS ：complexTypeの> </ XS：要素>
<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：要素名= "ダイアログ"> <XS：complexTypeの> <XS：配列> <XS：要素REF = "TNS：状態" のminOccurs = "1" のmaxOccurs = "1" /> <XS：要素名=」期間」タイプ= "XS：NonNegativeIntegerの" minOccurs属性= "0" のmaxOccurs = "1" /> <XS：要素名は= "" のminOccurs = "0" のmaxOccurs = "1"> <XSを置き換える：complexTypeの> <XS：属性名前= "コールIDを" タイプ= "XS：文字列" 使用= "必須" /> <XS：属性名= "ローカルタグ" タイプ= "XS：文字列" 使用= "必須" /> <XS：属性名前= "リモートタグ" タイプ= "XS：文字列" 使用= "必要" /> </ XS：complexTypeの> </ XS：要素> <XS：要素名= "と呼ば-によって" TYPE = "TNS：NAMEADDR "のminOccurs =" 0" のmaxOccurs = "1" /> <XS：要素名= "ルート設定" のminOccurs = "0" のmaxOccurs = "1"> <XS：complexTypeの> <XS：配列> <XS：要素名=タイプを "ホップ" = "XS：文字列" のminOccurs = "1" のmaxOccurs = "無制限" /> </ XS：配列> </ XS：complexTypeの> </ XS：要素> <XS：要素名= "ローカル"タイプ= "TNS：参加者" のminOccurs = "0" のmaxOccurs = "1" /> <XS：要素名= "リモート" タイプ= "TNS：参加者" のminOccurs = "0" のmaxOccurs = "1" /> <XS：任意の名前空間= "##他" のprocessContents =」 LAX "のminOccurs = "0" のmaxOccurs = "無制限"/> </ XS：シーケンス> <XS：属性名= "ID" タイプ= "XS：必要な文字列"=使用 ""/> <XS：属性名="コールIDを "タイプ= "XS：文字列" 使用= "オプション"/> <XS：属性名= "ローカルタグ" タイプ= "XS：文字列" 使用= "オプション"/> <XS：属性名="リモートタグ」タイプ= "XS：文字列" 使用= "オプション" /> <XS：属性名= "方向" を使用= "オプション"> <XS：単純> <XS：制限ベース= "XS：文字列"> <XS：列挙値= "開始" /> <XS：列挙値= "受信者" /> </ XS：制限> </ XS：単純> </ XS：属性>
</xs:complexType> </xs:element>
</ XS：complexTypeの> </ XS：要素>
<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の名前= "参加者"> <XS：配列> <XS：要素名= "同一性" タイプ= "TNS：NAMEADDR" のminOccurs = "0" のmaxOccurs = "1" /> <XS：要素名=」標的」のminOccurs = "0" のmaxOccurs = "1"> <XS：complexTypeの> <XS：配列> <XS：要素名= "PARAM" のminOccurs = "0" のmaxOccurs = "無制限"> <XS：complexTypeの> <XS ：属性名= "PNAME" タイプ= "XS：文字列" 使用= "必須" /> <XS：属性名は= "PVAL" タイプ= "XS：文字列" 使用= "必須" /> </ XS：complexTypeの> </ XS：要素> </ XS：シーケンス> <XS：属性名= "URI" タイプ= "XS：文字列" 使用= "必須" /> </ XS：complexTypeの> </ XS：要素> <XS：要素名= "セッション記述" タイプ= "TNS：sessd" のminOccurs = "0" のmaxOccurs = "1" /> <XS：要素名= "のCSeq" タイプ= "XS：NonNegativeIntegerの" minOccurs属性= "0" のmaxOccurs = "1" /> <XS：任意の名前空間= "##その他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：配列> </ 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の名前= "NAMEADDR"> <XS：simpleContentを> <XS：増設ベース= "XS：anyURIの"> <XS：属性名= "表示名" タイプ= "XS：文字列" 使用= "オプション" /> </ XS：拡張> </ XS：simpleContentを> </ XS：complexTypeの> <XS：complexTypeの名前= "sessd"> <XS：simpleContentを> <XS：増設ベース= "XS：文字列"> <XS：属性名は= "タイプ" タイプ= "XS：文字列" 使用= "必須" /> </ XS：拡張> </ XS：simpleContentに>
</xs:complexType>
</ 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>
<XS：要素名= "状態"> <XS：complexTypeの> <XS：simpleContentを> <XS：増設ベース= "XS：文字列"> <XS：属性名= "イベント" 使用= "オプション"> <XS：単純> <XS：制限基地= "XS：文字列"> <XS：列挙値= "キャンセル" /> <XS：列挙値= "拒否" /> <XS：列挙値= "置換" /> <XS：列挙値= "ローカルBYE" /> <XS：列挙値= "リモートBYE" /> <XS：列挙値= "エラー" /> <XS：列挙値= "タイムアウト" /> </ XS：制限> </ XS：単純> </ XS：属性> <XS：属性名= "コード" を使用= "オプション"> <XS：単純> <XS：制限ベース= "XS：POSITIVEINTEGER"> <XS：のminInclusive値= "100" /> <XS：maxInclusiveを値= "699" /> </ XS：制限> </ XS：単純> </ XS：属性> </ XS：拡張> </ XS：simpleContentを> </ XS ：complexTypeの> </ XS：要素> </ XS：スキーマ>
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で説明した共有ラインの例のようなアプリケーションです。彼らは認定された第三者は、これらの特性を自覚することができますように、これらの特徴パラメータは、ダイアログパッケージとの組み合わせにおいて特に有用です。
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.byeless」メディア機能パラメータは、（例えば、BYE要求を送信することによって）パラメータを設定するユーザエージェントは、独自にセッションを終了することができないことがポジティブ指示を提供する本文書で定義された新しいブールパラメータを、あります。例えば、連続予告サービスや特定記録サービスは、セッションを終了することが望ましいであろう時期を決定することができないので、彼らはすべてのセッションを終了することはできません。彼らはセッションを終了しませんように、また、多くのヒトのコールセンターが構成されています。 （これは、偶然に、発信者を切断からコールセンターのエージェントを防ぐためです）。 （あたりなお[10]、このパラメータ名はSIPコンタクトヘッダフィールドに使用される「+」文字が先行されなければなりません。）
Contact: <sip:recording-service@host.example.net> ;automaton;+sip.byeless
連絡先：<SIP：recording-service@host.example.net>;オートマトン; + 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リクエストを使用して作成したダイアログでContactヘッダーフィールドで使用されなければなりません。
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つをレンダリングしていることを肯定的知識を示しています。値は「no」ユーザーエージェントは、それが受信しているメディアのどれをレンダリングされていないことを肯定的知識を示しています。 「未知」の値は、ユーザエージェントは（ユーザエージェントが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"
連絡先：<SIP：musak-onhold@host.example.net>;オートマトン; + sip.rendering = "なし"
For example, if a UAC sends an INVITE that looks, in part, like:
たとえば、UACはそれは次のように、部分的に見えますINVITEを送信する場合：
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
SIP / 2.0 / UDP pc33.example.com;ブランチ= z9hG4bKnashds8マックス・フォワード：bob@example.com SIP / 2.0経由：SIP INVITE〜70：ボブ<SIP：bob@example.com>から：アリス<一口： alice@example.com>;タグ= 1928301774のCall-ID：a84b4c76e66710のCSeq：<SIP：alice@pc33.example.com>のContent-Type：アプリケーション/ SDPのContent-Length：142 314159連絡先を招待
[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>
<？xml version = "1.0"？> <ダイアログ-情報のxmlns = "壷：IETF：のparams：XML：NS：ダイアログ・インフォ" バージョン= "0" の状態= "フル" の実体= "一口例：@アリス。 comの "> <ダイアログのid =" as7d900as8" コールID = "a84b4c76e66710" ローカルタグ= "1928301774" 方向= "イニシエータ"> <状態>しよう</状態> </ダイアログ> </ダイアログ、インフォメーション>
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>
SIP / 2.0 180リンギング経由：SIP / 2.0 / UDP pc33.example.com;ブランチ= z9hG4bKnashds8へ：ボブ：;：アリス<一口bob@example.com>からタグ= 456887766 <一口：alice@example.com>。タグ= 1928301774のCall-ID：a84b4c76e66710のCSeq：314159 INVITE連絡先：<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>
<？xml version = "1.0"？> <ダイアログ-情報のxmlns = "壷：IETF：のparams：XML：NS：ダイアログ・インフォ" バージョン= "1" 状態= "フル" の実体= "一口例：@アリス。 comの "> <ダイアログのid =" as7d900as8" コールID = "a84b4c76e66710" ローカルタグ= "1928301774" リモートタグ= "456887766" 方向= "イニシエータ"> <状態>早期</状態> </ダイアログ> < /ダイアログ-インフォメーション>
If it receives a second 180 with a different tag:
それは別のタグで二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>
SIP / 2.0 180リンギング経由：SIP / 2.0 / UDP pc33.example.com;ブランチ= z9hG4bKnashds8へ：ボブ<SIP：bob@example.com>;タグ= hh76aから：アリス<SIP：alice@example.com>。タグ= 1928301774のCall-ID：a84b4c76e66710のCSeq：314159 INVITE連絡先：<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>
<？xml version = "1.0"？> <ダイアログ-情報のxmlns = "壷：IETF：のparams：XML：NS：ダイアログ・インフォ" バージョン= "2" 状態= "フル" の実体= "一口例：@アリス。 comの "> <ダイアログのid =" as7d900as8" コールID = "a84b4c76e66710" ローカルタグ= "1928301774" リモートタグ= "456887766" 方向= "イニシエータ"> <状態>早期</状態> </ダイアログ> <ダイアログID = "as7d900as8" コールID = "a84b4c76e66710" ローカルタグ= "1928301774" リモートタグ= "hh76a" 方向= "イニシエータ"> <状態>早期</状態> </ダイアログ> </ダイアログ-情報>
If a 200 OK response is received on the second dialog, the dialog moves to confirmed:
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>
<？xml version = "1.0"？> <ダイアログ-情報のxmlns = "壷：IETF：のparams：XML：NS：ダイアログ・インフォ" バージョン= "3" 状態= "部分" 実体= "一口例：@アリス。 COM "> <ダイアログID =" as7d900as8" コールID = "a84b4c76e66710" ローカルタグ= "1928301774" リモートタグ= "hh76a" 方向= "開始"> <状態>確認</状態> </ダイアログ> < /ダイアログ-インフォメーション>
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:
何の2xx応答がそれを受け取っていないので、32秒後に、他の初期ダイアログが終了します。これは、それが正常にキャンセルされたことを意味し、したがって、以下の通知が送信されます。
<?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>
<？xml version = "1.0"？> <ダイアログ-情報のxmlns = "壷：IETF：のparams：XML：NS：ダイアログ・インフォ" バージョン= "4" 状態= "部分" 実体= "一口例：@アリス。 COM "> <ダイアログID =" as7d900as8" コールID = "a84b4c76e66710" ローカルタグ= "1928301774" リモートタグ= "hh76a" 方向= "開始"> <状態イベント= "終了>" キャンセル</状態> </ダイアログ> </ダイアログ、インフォメーション>
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>
<？xml version = "1.0"？> <ダイアログ-情報のxmlns = "壷：IETF：のparams：XML：NS：ダイアログ・インフォ" バージョン= "0" の状態= "フル" の実体= "一口例：@アリス。 comの "> </ダイアログ、インフォメーション>
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>
<？xml version = "1.0"？> <ダイアログ-情報のxmlns = "壷：IETF：のparams：XML：NS：ダイアログ・インフォ" バージョン= "1" の状態= "部分" 実体= "一口例：@アリス。 comの "> <ダイアログのid =" as7d900as8" > <状態>しよう</状態> </ダイアログ> </ダイアログ、インフォメーション>
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>
<？xml version = "1.0"？> <ダイアログ-情報のxmlns = "壷：IETF：のparams：XML：NS：ダイアログ・インフォ" バージョン= "2" 状態= "部分" 実体= "一口例：@アリス。 comの "> <ダイアログのid =" as7d900as8" コールID = "a84b4c76e66710" ローカルタグ= "1928301774" 方向= "イニシエータ"> <状態>しよう</状態> <ローカル> <アイデンティティ表示= "アリス・スミス"> SIP：alice@example.com </アイデンティティ> <ターゲットURI = "SIP：alice@pc33.example.com" /> </ローカル> <リモート> <アイデンティティ> SIP：bob@example.net </アイデンティティ> < /リモート> </ダイアログ> </ダイアログ、インフォメーション>
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>
<？xml version = "1.0"？> <ダイアログ-情報のxmlns = "壷：IETF：のparams：XML：NS：ダイアログ・インフォ" バージョン= "3" 状態= "部分" 実体= "一口例：@アリス。 COM "> <ダイアログID =" as7d900as8" コールID = "a84b4c76e66710" ローカルタグ= "1928301774" リモートタグ= "07346y131" 方向= "開始"> <状態コード= "180">初期</状態> <リモート> <ターゲットURI = "SIP：bobster@host2.example.net" /> </リモート> </ダイアログ> </ダイアログ、インフォメーション>
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>
<？xml version = "1.0"？> <ダイアログ-情報のxmlns = "壷：IETF：のparams：XML：NS：ダイアログ・インフォ" バージョン= "4" 状態= "部分" 実体= "一口例：@アリス。 COM "> <ダイアログID =" as7d900as8" コールID = "a84b4c76e66710" ローカルタグ= "1928301774" リモートタグ= "07346y131" 方向= "開始"> <状態理由= "終了>" キャンセル</状態> </ダイアログ> <ダイアログID = "zxcvbnm3" コールID = "a84b4c76e66710" ローカルタグ= "1928301774" リモートタグ= "8736347" 方向= "開始"> <状態コード= "200"> </状態を確認> <リモート> <ターゲットURI = "SIP：bob-is-not-here@vm.example.net">の<param pnameに= "俳優" は、pval = "MSG-係" />の<param pnameに= "オートマトン" PVAL = "真" />の<param pnameに= "+ sip.byeless" は、pval = "真" /> </ target>を</リモート> </ダイアログ> </ダイアログ、インフォメーション>
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」で）キーを押して、この設定を示します。ボブのボイスメールシステムは、キャシーのAORに[20]アリスのコールを転送することによって、このキー操作に作用します。
<?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>
<？xml version = "1.0"？> <ダイアログ-情報のxmlns = "壷：IETF：のparams：XML：NS：ダイアログ・インフォ" バージョン= "5" 状態= "部分" 実体= "一口例：@アリス。 comの "> <ダイアログのid =" zxcvbnm3" コールID = "a84b4c76e66710" ローカルタグ= "1928301774" リモートタグ= "8736347" 方向= "イニシエータ"> <状態理由= "終了>" に置き換え</状態> </ダイアログ> <ダイアログID = "sfhjsjk12は" コールID = "o34oii1" ローカルタグ= "8903j4" リモートタグ= "78cjkus" 方向= "受信機"> <状態理由は= "置換"> </状態を確認bob-is-not-here@vm.example.net </ referred-：> <コールID = "a84b4c76e66710" ローカルタグ= "1928301774" リモートタグ= "8736347" /> <呼ばごと> SIPを置き換え= />の<param pnameに= "+ sip.rendering" は、pval = "はい" /> </ローカル> <リモート> <アイデンティティ表示：> <ローカル> <ターゲットURI = "alice@pc33.example.com一口" により、 "キャシー・ジョーンズ"> SIP：cjones@example.net </アイデンティティ> <ターゲットURI = "SIP：line3@host3.example.net">の<param pnameに= "俳優" は、pval = "アテンダント" />の<param pnameに= "オートマトン" は、pval = "偽" /> </ target>を</リモート> </ダイアログ> </ダイアログ、インフォメーション>
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>
<？xml version = "1.0"？> <ダイアログ-情報のxmlns = "壷：IETF：のparams：XML：NS：ダイアログ・インフォ" バージョン= "6" 状態= "部分" 実体= "一口例：@アリス。 "ローカルタグ= "8903j4" リモートタグ= "78cjkus" 方向= "受信機"> <状態o34oii1 COM "> <ダイアログID =" sfhjsjk12" コールIDは=">確認</状態> <リモート> <ターゲットURI = "SIP：confid-34579@host3.example.net">の<param pnameに= "isfocus" は、pval = "真" /> </ target>を</リモート> </ダイアログ> </ダイアログ、インフォメーション>
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>
<？xml version = "1.0"？> <ダイアログ-情報のxmlns = "壷：IETF：のparams：XML：NS：ダイアログ・インフォ" バージョン= "7" 状態= "部分" 実体= "一口例：@アリス。 "ローカルタグ= "8903j4" リモートタグ= "78cjkus" 方向= "受信機"> <状態o34oii1 COM "> <ダイアログID =" sfhjsjk12" コールIDは=">確認</状態> <ローカル> <ターゲットURI = "SIP：alice@pc33.example.com" />の<param pnameに= "sip.rendering +" は、pval = "なし" /> </ target>を</ローカル> </ダイアログ> </ダイアログ、インフォメーション>
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>
<？xml version = "1.0"？> <ダイアログ-情報のxmlns = "壷：IETF：のparams：XML：NS：ダイアログ・インフォ" バージョン= "8" 状態= "部分" 実体= "一口例：@アリス。 o34oii1 COM "> <ダイアログID =" sfhjsjk12" コールID = "" ローカルタグ= "8903j4" リモートタグ= "78cjkus" 方向= "受信機"> <状態理由= "<">-BYE遠隔終端/状態> </ダイアログ> <ダイアログのid = "08hjh1345"> <状態> </状態> </ダイアログ> </ダイアログ-情報を試みます>
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>
<？xml version = "1.0"？> <ダイアログ-情報のxmlns = "壷：IETF：のparams：XML：NS：ダイアログ・インフォ" バージョン= "9" 状態= "フル" の実体= "一口例：@アリス。 comの "> </ダイアログ、インフォメーション>
The following example shows the same user agent providing minimal information to maintain privacy for services like automatic callback.
次の例では、自動コールバックのようなサービスのプライバシーを維持するための最小限の情報を提供し、同じユーザーエージェントを示しています。
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>
<？xml version = "1.0"？> <ダイアログ-情報のxmlns = "壷：IETF：のparams：XML：NS：ダイアログ・インフォ" バージョン= "0" の状態= "フル" の実体= "一口例：@アリス。 comの "> </ダイアログ、インフォメーション>
Offhook: (implementation/policy choice for Alice to transition to this "state" when "seized", when Trying, when Proceeding, or when Confirmed.)
オフフック：（実装/アリスは「押収」は、この「状態」に移行するための政策の選択肢、しようとすると、進むとき、または確認する場合）
<?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>
<？xml version = "1.0"？> <ダイアログ-情報のxmlns = "壷：IETF：のparams：XML：NS：ダイアログ・インフォ" バージョン= "1" 状態= "フル" の実体= "一口例：@アリス。 comの "> <ダイアログのid =" 1" > <状態>確認</状態> </ダイアログ> </ダイアログ、インフォメーション>
Onhook: (implementation/policy choice for Alice to transition to this "state" when terminated, or when no longer "seized")
オンフック：（アリスは、この「状態」に移行するための実装/方針の選択時に終了していない、またはもはや「押収」の場合）
<?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>
<？xml version = "1.0"？> <ダイアログ-情報のxmlns = "壷：IETF：のparams：XML：NS：ダイアログ・インフォ" バージョン= "2" 状態= "フル" の実体= "一口例：@アリス。 comの "> </ダイアログ、インフォメーション>
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]と一口上で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名前空間。 2つの新しいメディアがSIPツリー内のパラメータを備えています。
MIME media type name: application
MIMEメディアタイプ名：application
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].
オプションのパラメータ：[8] RFC 3023で指定され、application / xmlのcharsetパラメータと同じです。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [8].
符号化の考慮事項：アプリケーション/ XMLの符号化の考慮と同じRFC 3023に指定されている[8]。
Security considerations: See Section 10 of RFC 3023 [8] and Section 7 of this specification.
セキュリティの考慮事項：RFC 3023のセクション10 [8]、この仕様のセクション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のマッキントッシュファイルタイプコード：「TEXT」
Personal and email address for further information: Jonathan Rosenberg, <jdrosen@jdrosen.net>
詳しくは、個人やメールアドレス：ジョナサン・ローゼンバーグ、<jdrosen@jdrosen.net>
Intended usage: COMMON
意図している用法：COMMON
Author/Change controller: The IETF.
著者/変更コントローラ：IETF。
8.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:dialog-info
8.2. 骨壷のためのURNサブ名前空間の登録：IETF：のparams：XML：NS：ダイアログ-情報
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：IETF：：のparams：XML：NS：ダイアログ-情報この名前空間のURIはURNです。
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
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-当量=" コンテンツタイプ "コンテンツ=" text / htmlの;のcharset =イソ8859-1" /> <タイトル>ダイアログ情報名前空間</ TITLE> </ HEAD> <BODY> <H1>ダイアログ情報のための名前空間</ H1> <H2> URN：IETF：のparams：XML：NS：ダイアログ-情報</ H2> <P> <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
URI：URN：IETF：のparams：XML：スキーマ：ダイアログ-情報
Registrant Contact: The IESG, <iesg@ietf.org>
登録者連絡先：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]で定義された手順に従って、二つの新しいメディア特徴タグを登録します。タグは[10]で定義されているSIPツリーに配置されています。
8.4.1. Media Feature Tag sip.byeless Media feature tag name sip.byeless
8.4.1. メディア特徴タグsip.byelessメディア機能タグ名sip.byeless
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.
ブール：この機能タグで使用するための適切な値。
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").
このタグで示されるメディア機能の概要：このフィーチャータグは、デバイスは、現在のセッション（「YES」）、現在のセッションからのメディアのいずれも（「NO」）から任意のメディアをレンダリングしているかどうかを示す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]ローチ、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[3]ローゼンバーグ、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]パオリ、J.、Sperberg-マックィーン、C.、ブレイ、T.、およびE. MALER、 "拡張マークアップ言語（XML）1.0（第二版）"、W3C FirstEdition REC-XML-20001006、2000年10月。
[5] Moats, R., "URN Syntax", RFC 2141, May 1997.
[5]堀、R.、 "URN構文"、RFC 2141、1997年5月を。
[6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[6]堀、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]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[10] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[10]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェントの能力を示します"。
[11] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004.
[11]スパークス、R.、 "セッション開始プロトコル（SIP）と呼ばバイメカニズム"、RFC 3892、2004年9月。
[12] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[12]スパークス、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]マーイ、R.、ビッグス、B.、およびR.ディーン、 "ザ・セッション開始プロトコル（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.ハーディ、 "メディア特徴タグの登録手順"、BCP 31、RFC 2506、1999年3月。
[15] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[15]ダークス、T.とC.アレン、 "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]ローゼンバーグ、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]ローゼンバーグ、J.、RFC 3857、2004年8月 "セッション開始プロトコル（SIP）のためのウォッチャー情報イベントテンプレート・パッケージ"。
[18] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.
[18]マーイ、R.、RFC 3842、2004年8月「セッション開始プロトコル（SIP）のためのメッセージサマリとメッセージ待機表示イベントパッケージ」。
[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]ローゼンバーグ、J.、ピーターソン、J.、Schulzrinneと、H.、およびG.カマリロを、BCP 85、RFC 3725 "セッション開始プロトコル（SIP）における第三者呼制御（3PCC）のベスト・プラクティスの現在" 、2004年4月。
[20] Sparks, R., "Session Initiation Protocol Call Control - Transfer", Work in Progress, July 2005.
[20]スパークス、R.、「セッション開始プロトコル呼制御 - 転送」、進歩、2005年7月での作業。
Authors' Addresses
著者のアドレス
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサン・ローゼンバーグシスコシステムズ600 Lanidexプラザパーシッパニー、NJ 07054米国
Phone: +1 973 952-5000 EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
電話：+1 973 952-5000 Eメール：jdrosen@cisco.com URI：http://www.jdrosen.net
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US
ヘニングSchulzrinneとコロンビア大学のM / S 0401 1214アムステルダムアベニュー。ニューヨーク、NY 10027米国
EMail: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs
電子メール：schulzrinne@cs.columbia.edu URI：http://www.cs.columbia.edu/~hgs
Rohan Mahy (editor) SIP Edge LLC
ローハンマーイ（エディタ）SIPエッジLLC
EMail: rohan@ekabal.com
メールアドレス：rohan@ekabal.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。