Network Working Group J. Rosenberg
Request for Comments: 4538 Cisco Systems
Category: Standards Track June 2006
Request Authorization through Dialog Identification
in 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 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This specification defines the Target-Dialog header field for the Session Initiation Protocol (SIP), and the corresponding option tag, tdialog. This header field is used in requests that create SIP dialogs. It indicates to the recipient that the sender is aware of an existing dialog with the recipient, either because the sender is on the other side of that dialog, or because it has access to the dialog identifiers. The recipient can then authorize the request based on this awareness.
この仕様は、セッション開始プロトコル（SIP）、および対応するオプションタグ、tdialogためのターゲット対話ヘッダフィールドを定義します。このヘッダーフィールドは、SIPダイアログを作成するリクエストに使用されています。それはどちらか、送信者が受信者との既存のダイアログを認識していることを受信者に示し、送信者は、そのダイアログの反対側にあるので、またはそれは、ダイアログ識別子へのアクセス権を持っているので。受信者は、このような認識に基づいて要求を許可することができます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Overview of Operation ...........................................4
3. User Agent Client (UAC) Behavior ................................5
4. User Agent Server Behavior ......................................7
5. Proxy Behavior ..................................................8
6. Extensibility Considerations ....................................8
7. Header Field Definition .........................................9
8. Security Considerations .........................................9
9. Relationship with In-Reply-To ..................................10
10. Example Call Flow .............................................10
11. IANA Considerations ...........................................13
11.1. Header Field .............................................13
11.2. Header Field Parameters ..................................13
11.2.1. local-tag .........................................13
11.2.2. remote-tag ........................................13
11.3. SIP Option Tag ...........................................14
12. Acknowledgements ..............................................14
13. References ....................................................14
13.1. Normative References .....................................14
13.2. Informative References ...................................15
The Session Initiation Protocol (SIP) [2] defines the concept of a dialog as a persistent relationship between a pair of user agents. Dialogs provide context, including sequence numbers, proxy routes, and dialog identifiers. Dialogs are established through the transmission of SIP requests with particular methods. Specifically, the INVITE, REFER [8], and SUBSCRIBE [3] requests all create dialogs.
セッション開始プロトコル（SIP）は、[2]ユーザーエージェントの対の間の永続的な関係としてダイアログの概念を定義します。ダイアログは、シーケンス番号、プロキシルート、ダイアログ識別子を含めて、コンテキストを提供します。ダイアログは、特定の方法とSIPリクエストの送信を介して確立されます。具体的には、[8]を参照し、[3]すべてのダイアログを作成する要求SUBSCRIBE INVITE。
When a user agent receives a request that creates a dialog, it needs to decide whether to authorize that request. For some requests, authorization is a function of the identity of the sender, the request method, and so on. However, many situations have been identified in which a user agent's authorization decision depends on whether the sender of the request is currently in a dialog with that user agent, or whether the sender of the request is aware of a dialog the user agent has with another entity.
ユーザーエージェントは、ダイアログを作成するリクエストを受信すると、その要求を承認するかどうかを決定する必要があります。いくつかの要求の場合、許可はように、送信者の身元の機能、リクエストメソッド、およびです。しかし、多くの場合は、ユーザエージェントの認可決定が要求の送信者がそのユーザエージェントとのダイアログに現在あるかどうかに依存するで同定されている、またはリクエストの送信者は、ユーザエージェントが他に持っているのダイアログを認識しているかどうかエンティティ。
One such example is call transfer, accomplished through REFER. If user agents A and B are in an INVITE dialog, and user agent A wishes to transfer user agent B to user agent C, user agent A needs to send a REFER request to user agent B, asking user agent B to send an INVITE request to user agent C. User agent B needs to authorize this REFER. The proper authorization decision is that user agent B should accept the request if it came from a user with whom B currently has an INVITE dialog relationship. Current implementations deal with this by sending the REFER on the same dialog as the one in place between user agents A and B. However, this approach has numerous problems [12]. These problems include difficulties in determining the lifecycle of the dialog and its usages and in determining which messages are associated with each application usage. Instead, a better approach is for user agent A to send the REFER request to user agent B outside of the dialog. In that case, a means is needed for user agent B to authorize the REFER.
その一例は、貫通REFER実現、通話転送です。ユーザエージェントAとBは、INVITEダイアログであり、ユーザエージェントAは、ユーザエージェントCにユーザエージェントBを転送することを望む場合、ユーザエージェントAは、INVITE要求を送信するユーザエージェントBを求め、ユーザエージェントBを参照して要求を送信する必要がありますユーザエージェントC.ユーザーエージェントにBが、これはREFER認可する必要があります。適切な承認の決定は、Bは現在、INVITEダイアログ関係を持っている人と、ユーザから来た場合、ユーザエージェントBが要求を受け入れるべきであるということです。現在の実装では、しかし、ユーザエージェントAとBとの間の場所にものと同じダイアログでREFER送信することによって、これに対処、このアプローチは、[12]多くの問題を有しています。これらの問題は、メッセージは、各アプリケーションの使用状況に関連付けられている対話のライフサイクルとその使用法を決定すると決定する上での困難があります。代わりに、より良いアプローチは、ユーザエージェントAは、ダイアログの外でユーザエージェントBを参照してリクエストを送信するためのものです。その場合には、手段は、REFERを許可するユーザエージェントBのために必要とされます。
Another example is the application interaction framework [14]. In that framework, proxy servers on the path of a SIP INVITE request can place user interface components on the user agent that generated or received the request. To do this, the proxy server needs to send a REFER request to the user agent, targeted to its Globally Routable User Agent URI (GRUU) [13], asking the user agent to fetch an HTTP resource containing the user interface component. In such a case, a means is needed for the user agent to authorize the REFER. The application interaction framework recommends that the request be authorized if it was sent from an entity on the path of the original dialog. This can be done by including the dialog identifiers in the
別の例では、アプリケーション対話フレームワーク[14]です。そのフレームワークでは、SIPの経路上のプロキシサーバーは、要求が生成または要求を受信したユーザエージェントのユーザインターフェースコンポーネントを配置することができINVITE。これを行うには、プロキシサーバは、ユーザ・インターフェース・コンポーネントを含むHTTPリソースを取得するためにユーザーエージェントを求めて、そのグローバルにルーティング可能なユーザエージェントURI（GRUU）[13]を対象とユーザーエージェントを参照する要求を、送信する必要があります。このような場合、手段は、REFERを許可するユーザーエージェントのために必要とされます。アプリケーション・インタラクション・フレームワークは、それが元のダイアログのパス上のエンティティから送信された場合、要求を許可することをお勧めします。これは、中にダイアログの識別子を含めることによって行うことができます
REFER, which prove that the user agent that sent the REFER is aware of those dialog identifiers (this needs to be secured against eavesdroppers through the sips mechanism, of course).
REFER送信されたユーザエージェントは、これらのダイアログ識別子（これはもちろん、一口機構を介して盗聴者から保護する必要があります）を認識していることを証明する際に、参照してください。
Another example is if two user agents share an INVITE dialog, and an element on the path of the INVITE request wishes to track the state of the INVITE. In such a case, it sends a SUBSCRIBE request to the GRUU of the user agent, asking for a subscription to the dialog event package. If the SUBSCRIBE request came from an element on the INVITE request path, it should be authorized.
2つのユーザエージェントは、INVITEダイアログを共有している場合、別の例であり、INVITEリクエストのパス上の要素は、INVITEの状態を追跡することを望みます。このような場合には、ダイアログイベントパッケージへの加入を求めて、ユーザーエージェントのGRUUにSUBSCRIBEリクエストを送信します。 SUBSCRIBEリクエストがINVITE要求パス上の要素から来た場合、それが認可されなければなりません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。
+--------+ +--------+
| | INVITE | |
| Server |----------->| Server |
| A | | B |
| |...........>| |
+--------+ +--------+
^ REFER . \
/ . \
/ . \
/ . \
/ . \
/ V V
+--------+ +--------+
| | | |
| User | | User |
| Agent | | Agent |
| A | | B |
+--------+ +--------+
Figure 1
図1
Figure 1 shows the basic model of operation. User agent A sends an INVITE to user agent B, traversing two servers, server A and server B. Both servers act as proxies for this transaction. User B sends a 200 OK response to the INVITE. This 200 OK includes a Supported header field indicating support for this specification (through the presence of the tdialog option tag). The 200 OK response establishes a dialog between the two user agents.
図1は、動作の基本的なモデルを示します。ユーザーエージェントAは、ユーザエージェントB、二つのサーバを横断、サーバーAとサーバーBにINVITE両方のサーバーは、このトランザクションのためのプロキシとして動作し送信します。ユーザBは、INVITEへの200 OK応答を送信します。この200 OKは、（tdialogオプションタグの存在を介して）この仕様のサポートを示すサポートされているヘッダフィールドを含みます。 200 OK応答は、2つのユーザーエージェント間の対話を確立します。
Next, an entity that was present along the request path (server A, for example) wishes to send a dialog-forming request (such as REFER) to user agent A or B (user B for example). So, the entity acts as a user agent and sends the request to user agent B. This request is addressed to the URI of user agent B, which server A learned from inspecting the Contact header field in the 200 OK of the INVITE request. If this URI has the GRUU [11] property (it can be used by any element on the Internet, such as server A, to reach the specific user agent instance that generated that 200 OK to the INVITE), then the mechanism will work across NAT boundaries.
次に、（例えば、サーバA）要求経路に沿って存在していたエンティティは、ユーザエージェントAまたはB（例えばユーザB）に（例えばREFERなど）ダイアログ形成要求を送信することを望みます。したがって、エンティティはユーザーエージェントとして機能し、この要求は、Aは、INVITEリクエストの200 OKにContactヘッダーフィールドの検査から学習サーバユーザエージェントBのURIにアドレス指定されるユーザエージェントBに要求を送信します。このURIは、GRUU [11]プロパティがある場合、機構は全体動作する（INVITEに対する200 OKこと生成された特定のユーザエージェントインスタンスに到達するために、そのようなサーバAとして、インターネット上の任意の要素で使用することができます） NAT境界。
The request generated by server A will contain a Target-Dialog header field. This header field contains the dialog identifiers for the INVITE dialog between user agents A and B, composed of the Call-ID, local tag, and remote tag. Server A knew to include the Target-Dialog header field in the REFER request because it knows that user agent B supports it.
サーバAによって生成された要求は、ターゲット対話ヘッダフィールドを含むであろう。このヘッダーフィールドは、Call-ID、ローカルタグ、およびリモートタグからなるユーザエージェントAとBとの間のINVITEダイアログのダイアログ識別子を含んでいます。それは、ユーザエージェントBがそれをサポートしていることを知っているため、サーバーAは、REFERリクエストにターゲット対話ヘッダフィールドを含めるように知っていました。
When the request arrives at user agent B, it needs to make an authorization decision. Because the INVITE dialog was established using a sips URI, and because the dialog identifiers are cryptographically random [2], no entity except for user agent A or the proxies on the path of the initial INVITE request can know the dialog identifiers. Thus, because the request contains those dialog identifiers, user agent B can be certain that the request came from user agent A, the two proxies, or an entity to whom the user agent or proxies gave the dialog identifiers. As such, it authorizes the request and performs the requested actions.
要求は、ユーザエージェントBに到達すると、それが承認決定を行う必要があります。 INVITEダイアログは、SIPS URIを使用して確立し、そしてダイアログ識別子は暗号的にランダムであるため、[2]、ユーザエージェントA以外のいかなるエンティティまたは初期INVITE要求の経路上のプロキシがダイアログ識別子を知ることができないからです。要求は、これらのダイアログ識別子が含まれているため、このように、ユーザエージェントBは、要求がユーザエージェントAから来たことを確信することができ、2つのプロキシ、またはエンティティ誰にユーザーエージェントやプロキシは、ダイアログの識別子を与えました。このように、それは要求を承認し、要求されたアクションを実行します。
A UAC SHOULD include a Target-Dialog header field in a request if the following conditions are all true:
次の条件がすべて真である場合、UACは、リクエストにターゲット対話ヘッダフィールドを含める必要があります。
2. The user agent client believes that the request may not be authorized by the user agent server unless the user agent client can prove that it is aware of the dialog identifiers for some other dialog. Call this dialog the target dialog.
2.ユーザー・エージェント・クライアントは、ユーザエージェントクライアントは、それが他のいくつかのダイアログのダイアログ識別子を認識していることを証明できない限り、要求は、ユーザエージェントサーバによって許可されないかもしれないと考えています。このダイアログにターゲットダイアログを呼び出します。
3. The request does not otherwise contain information that indicates that the UAC is aware of those dialog identifiers.
3.リクエストは、そうでない場合UACは、これらのダイアログ識別子を認識していることを示す情報が含まれていません。
4. The user agent client knows that the user agent server supports the Target-Dialog header field. It can know this if it has seen a request or response from the user agent server within the target dialog that contained a Supported header field that included the tdialog option tag.
4.ユーザー・エージェント・クライアントは、ユーザエージェントサーバは、ターゲット対話ヘッダフィールドをサポートしていることを知っています。それはtdialogオプションタグを含むサポートされているヘッダフィールドを含まターゲットダイアログ内のユーザエージェントサーバからの要求または応答を見ている場合は、これを知ることができます。
If the fourth condition is not met, the UAC SHOULD NOT use this specification. Instead, if it is currently within a dialog with the User Agent Server (UAS), it SHOULD attempt to send the request within the existing target dialog.
第4の条件が満たされない場合、UACは、この仕様を使用しないでください。それはユーザエージェントサーバ（UAS）との対話の中に、現在であれば代わりに、それは既存のターゲットダイアログ内でリクエストを送信しようとすべきです。
The following are examples of use cases in which these conditions are met:
これらの条件が満たされているユースケースの例は次の通りであります：
o A REFER request is sent according to the principles of [14]. These REFER are sent outside of a dialog and do not contain any other information that indicates awareness of the target dialog. [14] also mandates that the REFER be sent only if the UA indicates support for the target dialog specification.
O REFER要求は、[14]の原理に従って送信されます。これらは、ダイアログの外に送信されている参照して、ターゲットダイアログの認識を示し、他の情報が含まれていません。 [14]また、UAは、ターゲットダイアログ仕様のサポートを示している場合にのみ送信される参照することを義務付け。
o User A is in separate calls with users B and C. User A decides to start a three way call, and so morphs into a focus [17]. User B would like to learn the other participants in the conference. So, it sends a SUBSCRIBE request to user A (who is now acting as the focus) for the conference event package [16]. It is sent outside of the existing dialog between user B and the focus, and it would be authorized by A if user B could prove that it knows the dialog identifiers for its existing dialog with the focus. Thus, the Target-Dialog header field would be included in the SUBSCRIBE.
ユーザーBおよびCユーザーAは三方通話を開始することを決定し、そうフォーカス[17]にモーフとOユーザAは、別の呼び出しです。ユーザBは、会議の他の参加者を学びたいです。だから、それは会議イベントパッケージ[16]のために（今の焦点として機能している）、ユーザAにSUBSCRIBEリクエストを送信します。これは、ユーザBと焦点の間の既存の対話の外に送信され、ユーザBは、それが焦点との既存のダイアログのダイアログ識別子を知っていることを証明することができれば、それはAによって許可されるだろう。したがって、ターゲット対話ヘッダフィールドはSUBSCRIBEに含まれるであろう。
The following are examples of use cases in which these conditions are not met:
これらの条件が満たされていないされているユースケースの例は次の通りであります：
o A server acting as a proxy is a participant in an INVITE dialog that establishes a session. The server would like to use the Keypad Markup Language (KPML) event package [18] to find out about keypresses from the originating user agent. To do this, it sends a SUBSCRIBE request. However, the Event header field of this SUBSCRIBE contains event parameters that indicate the target dialog of the subscription. As such, the request can be authorized without additional information.
Oプロキシとして動作するサーバーは、セッションを確立し、INVITEダイアログに参加しています。サーバーは、発信ユーザエージェントからのキー入力を知るためにキーパッドのマークアップ言語（KPML）イベントパッケージ[18]を使用したいと思います。これを行うには、それはSUBSCRIBEリクエストを送信します。しかし、このSUBSCRIBEのEventヘッダーフィールドは、サブスクリプションのターゲットダイアログを示すイベントパラメータが含まれています。そのため、要求は、追加情報なしで許可することができます。
o A server acting as a proxy is a participant in an INVITE dialog that establishes a session. The server would like to use the dialog event package [15] to find out about dialogs at the originating user agent. To do this, it sends a SUBSCRIBE request. However, the Event header field of this SUBSCRIBE contains event parameters that indicate the target dialog of the subscription.
Oプロキシとして動作するサーバーは、セッションを確立し、INVITEダイアログに参加しています。サーバーは、発信ユーザエージェントでダイアログを知るために、ダイアログイベントパッケージ[15]を使用したいと思います。これを行うには、それはSUBSCRIBEリクエストを送信します。しかし、このSUBSCRIBEのEventヘッダーフィールドは、サブスクリプションのターゲットダイアログを示すイベントパラメータが含まれています。
As such, the request can be authorized without additional information.
そのため、要求は、追加情報なしで許可することができます。
Specifications that intend to make use of the Target-Dialog header field SHOULD discuss specific conditions in which it is to be included.
ターゲット対話ヘッダフィールドの使用をするつもりな仕様は、それが含まれるようになっている特定の条件を議論する必要があります。
Assuming it is to be included, the value of the callid production in the Target-Dialog header field MUST be equal to the Call-ID of the target dialog. The "remote-tag" header field parameter MUST be present and MUST contain the tag that would be viewed as the remote tag from the perspective of the recipient of the new request. The "local-tag" header field parameter MUST be present and MUST contain the tag that would be viewed as the local tag from the perspective of the recipient of the new request.
それは含まれるべきであると仮定すると、ターゲット対話ヘッダフィールド内callid生産の値は、ターゲットダイアログのコールIDに等しくなければなりません。 「リモートタグ」ヘッダフィールドパラメータが存在しなければならなくて、新しいリクエストの受信者の観点から遠隔タグとして見られるであろうタグを含まなければなりません。 「ローカルタグ」ヘッダフィールドパラメータが存在しなければならなくて、新しいリクエストの受信者の観点からローカルタグとして見られるであろうタグを含まなければなりません。
The request sent by the UAC SHOULD include a Require header field that includes the tdialog option tag. This request should, in principle, never fail with a 420 (Bad Extension) response, because the UAC would not have sent the request unless it believed the UAS supported the extension. If a Require header field was not included, and the UAS didn't support the extension, it would normally reject the request because it was unauthorized, probably with a 403. However, without the Require header field, the UAC would not be able to differentiate between the following:
UACによって送信された要求はtdialogオプションタグを含む要求ヘッダフィールドを含むべきです。それはUASは、拡張子をサポートすると信じられない限り、UACが要求を送信していないため、この要求は、原則的には、420（悪い拡張）応答で失敗することはありません。 Requireヘッダーフィールドが含まれていなかった、そしてUASが拡張をサポートしていない場合は、それが不正だったので、それはヘッダフィールドを必要とせずに、UACがすることができないであろう、おそらくしかし403で、要求を拒否し、通常ます以下の区別：
o a 403 that arrived because the UAS didn't actually understand the Target-Dialog header field (in which case the client should send the request within the target dialog if it can)
UASは、実際にターゲット対話ヘッダフィールドを理解していなかったので、到着した403 O（それができるならば、クライアントがターゲットダイアログ内のリクエストを送信する必要があり、その場合には）
o a 403 that arrived because the UAS understood the Target-Dialog header field, but elected not to authorize the request despite the fact that the UAC proved its awareness of the target dialog (in which case the client should not resend the request within the target dialog, even if it could).
UASは、UACは、クライアントがターゲットダイアログ内のリクエストを再送信してはならない。その場合にはターゲットダイアログ（のその意識を証明しているという事実にもかかわらず、ターゲット対話ヘッダフィールドを理解したが、要求を承認しないことを選択ので、到着したOA 403 、でも）それができれば。
If a user agent server receives a dialog-creating request and wishes to authorize the request, and if that authorization depends on whether or not the sender has knowledge of an existing dialog with the UAS, and information outside of the Target-Dialog header field does not provide proof of this knowledge, the UAS SHOULD check the request for the existence of the Target-Dialog header field. If this header field is not present, the UAS MAY still authorize the request by other means.
ユーザエージェントサーバは、ダイアログ作成要求を受信し、要求を承認することを望む、その許可は、送信者がUASとの既存のダイアログの知識を有し、ターゲット対話ヘッダフィールドの外部情報がないかどうかに依存している場合場合この知識の証明を提供しない、UASは、ターゲット対話ヘッダフィールドの存在のために要求を確認してください。このヘッダーフィールドが存在しない場合、UASは、依然として他の手段によって要求を許可することができます。
If the header field is present, and the value of the callid production, the "remote-tag", and "local-tag" values match the Call-ID, remote tag, and local tag of an existing dialog, and the dialog that they match was established using a sips URI, the UAS SHOULD authorize the request if it would authorize any entity on the path of the request that created that dialog, or any entity trusted by an entity on the path of the request that created that dialog.
ヘッダフィールドが存在し、callid生産、「リモートタグ」の値、および「ローカルタグ」の値は、Call-ID、リモートタグ、および既存のダイアログのローカルタグ、およびダイアログと一致した場合それらが一致するSIPS URIを使用して確立されたそれは、ダイアログ、または任意のエンティティは、そのダイアログを作成した要求の経路上に実体が信頼することを作成したリクエストのパス上の任意のエンティティを承認するかどう、UASはリクエストを承認すべきです。
If the dialog identifiers match, but they match a dialog not created with a sips URI, the UAS MAY authorize the request if it would authorize any entity on the path of the request that created that dialog, or any entity trusted by an entity on the path of the request that created that dialog. However, in this case, any eavesdropper on the original dialog path would have access to the dialog identifiers, and thus the authorization is optional.
それは、そのダイアログ、または上のエンティティによって信頼される任意のエンティティを作成したリクエストのパス上の任意のエンティティを認可するかどうダイアログ識別子が一致した場合、彼らはSIPS URIで作成されていないダイアログを一致させる、UASは要求を許可することができますそのダイアログを作成した要求のパス。しかし、この場合には、元のダイアログパス上の任意の盗聴者は、ダイアログ識別子へのアクセスを持つことになり、ひいては認証は任意です。
If the dialog identifiers don't match, or if they don't contain both a "remote-tag" and "local-tag" parameter, the header field MUST be ignored, and authorization MAY be determined by other means.
ダイアログ識別子が一致しない場合、彼らは、「リモートタグ」と「ローカルタグ」パラメータの両方が含まれていない場合、または、ヘッダフィールドは無視しなければなりませんし、許可は、他の手段によって決定することができます。
Proxy behavior is unaffected by this specification.
プロキシの動作は、この仕様書による影響を受けません。
This specification depends on a user agent client knowing, ahead of sending a request to a user agent server, whether or not that user agent server supports the Target-Dialog header field. As discussed in Section 3, the UAC can know this because it saw a request or response sent by that UAS within the target dialog that contained the Supported header field whose value included the tdialog option tag.
この仕様は、ユーザエージェントサーバは、ターゲット対話ヘッダフィールドをサポートしているかどうかにかかわらず、先にユーザエージェントサーバに要求を送信する、知っているユーザエージェントクライアントに依存します。第3節で説明したように、値tdialogオプションタグを含めSupportedヘッダーフィールドを含んでいたターゲットダイアログ内でそのUASによって送信された要求または応答を見たので、UACはこれを知ることができます。
Because of this requirement, it is especially important that user agents compliant to this specification include a Supported header field in all dialog forming requests and responses. Inclusion of the Supported header fields in requests is at SHOULD strength per RFC 3261. This specification does not alter that requirement. However, implementers should realize that, unless the tdialog option tag is placed in the Supported header field of requests and responses, this extension is not likely to be used, and instead, the request is likely to be re-sent within the existing target dialog (assuming the sender is the UA on the other side of the target dialog). As such, the conditions in which the SHOULD would not be followed would be those rare cases in which the UA does not want to enable usage of this extension.
この要件のため、この仕様に準拠ユーザエージェントは要求と応答を形成するすべてのダイアログでサポートされているヘッダフィールドを含むことが特に重要です。リクエストでサポートされているヘッダフィールドを含めることは、その要件を変更していないRFC 3261あたりSHOULD強度でこの仕様です。しかし、実装者はtdialogオプションタグが要求と応答のSupportedヘッダーフィールドに配置されていない限り、この拡張が使用される可能性はなく、代わりに、要求は既存のターゲットダイアログ内に再送信される可能性がある、ということを理解すべきです（送信者と仮定すると、UAは、ターゲットダイアログの反対側にあります）。そのため、SHOULDが続くことはないだろうする条件は、UAは、この拡張機能の使用を有効にしないでそれらのまれなケースでしょう。
The grammar for the Target-Dialog header field is defined as follows:
次のようにターゲット対話ヘッダフィールドの文法に定義されます。
Target-Dialog = "Target-Dialog" HCOLON callid *(SEMI td-param) ;callid from RFC 3261 td-param = remote-param / local-param / generic-param remote-param = "remote-tag" EQUAL token local-param = "local-tag" EQUAL token ;token and generic-param from RFC 3261
ターゲットダイアログ*（SEMI TD-PARAM）callid = "ターゲット・ダイアログ" HCOLON; RFC 3261 TD-PARAM =リモートPARAM /ローカルPARAM /ジェネリック-PARAMリモートPARAM = "リモートタグ" からcallid EQUALトークンローカルRFC 3261からトークンと総称-PARAM; -param =「ローカルタグ」に等しいトークン
Figures 3 and 4 are an extension of Tables 2 and 3 in RFC 3261 [2] for the Target-Dialog header field. The column "INF" is for the INFO method [4], "PRA" is for the PRACK method [5], "UPD" is for the UPDATE method [6], "SUB" is for the SUBSCRIBE method [3], "NOT" is for the NOTIFY method [3], "MSG" is for the MESSAGE method [7], "REF" is for the REFER method [8], and "PUB" is for the PUBLISH method [9].
図3及び図4は、ターゲット対話ヘッダフィールドのRFC 3261で、表2および3の拡張[2]です。カラム "INF" はINFO方式のためのものである[4]、 "PRA" はPRACK方法のためのものである[5]、 "UPD" は、UPDATEメソッドのためのものである[6]、 "SUB" は、SUBSCRIBEメソッドのためのものである[3] NOTIFYメソッドのためのものである "NOT" [3]、 "MSG" はMESSAGEメソッドのためのものである[7]、 "REF" は、REFERメソッドのためのものである[8]、及び "PUB" はPUBLISH方法[9]のためのものです。
Header field where proxy ACK BYE CAN INV OPT REG PUB
ヘッダフィールドプロキシACK BYE CAN INV OPT REGのPUB
Target-Dialog R - - - - o - - -
ターゲットダイアログR - - - - ○ - - -
Figure 3: Allowed Methods for Target-Dialog
図3：ターゲット対話のために許可されているメソッド
Header field where proxy PRA UPD SUB NOT INF MSG REF
プロキシPRA UPDのSUBはMSG REFをINFませヘッダフィールド
Target-Dialog R - - - o - - - o
ターゲットダイアログR - - - ○ - - - ○
Figure 4: Allowed Methods for Target-Dialog
図4：ターゲット対話のために許可されているメソッド
The Target-Dialog header field is used to authorize requests based on the fact that the sender of the request has access to information that only certain entities have access to. In order for such an authorization decision to be secure, two conditions have to be met. Firstly, no eavesdroppers can have access to this information. That requires the original SIP dialog to be established using a sips URI, which provides TLS on each hop. With a sips URI, only the user agents and proxies on the request path will be able to know the dialog identifiers. The second condition is that the dialog identifiers be sufficiently cryptographically random that they cannot be guessed. RFC 3261 requires global uniqueness for the Call-ID and 32 bits of cryptographic randomness for each tag (there are two tags for a dialog). Given the short duration of a typical dialog (perhaps as long as a day), this amount of randomness appears adequate for preventing guessing attacks. However, it's important to note that this specification requires true cryptographic randomness as set forth in RFC 4086 [11]. Weaker pseudorandom identifiers reduce the probability of collision, but because they are guessable, they are not sufficient to prevent an attacker from observing a sequence of identifiers, guessing the next one, and then using this specification to launch an attack.
ターゲット対話ヘッダフィールドは、リクエストの送信者が唯一の特定のエンティティがアクセス権を持っている情報へのアクセスを持っているという事実に基づいて要求を許可するために使用されます。安全であるためにそのような認可判断のためのためには、2つの条件が満たされなければなりません。まず、何の盗聴者は、この情報にアクセスすることができません。すなわち、各ホップにTLSを提供SIPS URIを使用して確立されるべき元のSIPダイアログを必要とします。 SIPS URIを使用すると、要求パス上の唯一のユーザエージェントとプロキシは、ダイアログ識別子を知ることができるようになります。第2の条件は、ダイアログ識別子が、彼らは推測できないことを十分に暗号的にランダムであることです。 RFC 3261は、Call-ID、および各タグの暗号化乱数の32ビット（ダイアログのための2つのタグがある）のためのグローバル一意性を必要とします。 （おそらく限り、日など）の典型的な対話の短い期間を考えると、ランダム性のこの量は推測攻撃を防止するための適切な表示されます。しかし、それはRFC 4086 [11]に記載のこの仕様は真の暗号ランダム性を必要とすることに注意することが重要です。弱い擬似ランダム識別子は、衝突の確率を減らすことが、彼らは推測可能であるため、彼らは、識別子のシーケンスを観察し、次のいずれかを推測して、攻撃を起動するには、この仕様を使用してから、攻撃者を防ぐのに十分ではありません。
RFC 3261 defines the In-Reply-To header field. It provides a list of Call-IDs for calls that the current request references or returns. It was meant to serve a similar purpose as the Reply-To in email: to facilitate the construction of "threads" of conversations in a user interface. Target-Dialog is similar, in that it also references a previous session. Due to their similarities, it is important to understand the differences, as these two header fields are not substitutes for each other.
RFC 3261は、In-返信先ヘッダーフィールドを定義します。これは、コールの現在のリクエストの参照または復帰するためのCall-IDのリストを提供します。ユーザーインターフェイスの会話の「スレッド」の建設を促進するために：それは、電子メールでの返信先と同様の目的を果たすために意図されました。ターゲット対話は、それはまた、前のセッションを参照することで、類似しています。これら2つのヘッダフィールドはお互いの代替ではないとして、それらの類似点に、違いを理解することが重要です。
Firstly, In-Reply-To is meant for consumption by a human or a user interface widget, for providing the user with a context that allows them to decide what a call is about and whether they should take it. Target-Dialog, on the other hand, is meant for consumption by the user agent itself, to facilitate authorization of session requests in specific cases where authorization is not a function of the user, but rather the underlying protocols. A UA will authorize a call containing Target-Dialog based on a correct value of the Target-Dialog header field.
まず、イン返信するためには、それらを呼び出し、約、彼らはそれを取るべきかどうかであるかを決定することを可能にするコンテキストをユーザに提供するために、ヒトまたはユーザ・インタフェース・ウィジェットによる消費のためのものです。ターゲット対話は、他の一方で、認証は、ユーザーの機能ではなく、基本的なプロトコルではありません特定の場合にセッション要求の承認を容易にするため、ユーザエージェント自身による消費のためのものです。 UAは、ターゲット対話ヘッダフィールドの正しい値に基づいてターゲット・ダイアログを含むコールを許可します。
Secondly, Target-Dialog references a specific dialog that must be currently in progress. In-Reply-To references a previous call attempt, most likely one that did not result in a dialog. This is why In-Reply-To uses a Call-ID, and Target-Dialog uses a set of dialog identifiers.
第二に、ターゲット対話は、現在進行中である必要があり、特定のダイアログを参照します。イン返信するためには、前の呼び出しの試み、ダイアログには至らなかった可能性が高いものを参照します。イン返信するためには、コールIDを使用し、ターゲット対話ダイアログ識別子のセットを使用する理由はここにあります。
Finally, In-Reply-To implies cause and effect. When In-Reply-To is present, it means that the request is being sent because of the previous request that was delivered. Target-Dialog does not imply cause and effect, merely awareness for the purposes of authorization.
最後に、イン返信するためには、原因と結果を意味します。イン返信には、存在する場合、それは要求が原因で配信された以前の要求を送信されていることを意味します。ターゲット対話は、原因と結果、承認の目的のために、単に意識を意味するものではありません。
In this example, user agent A and user agent B establish an INVITE-initiated dialog through Server-A and Server-B, each of which acts as a proxy for the INVITE. Server B would then like to use the application interaction framework [14] to request that user agent A fetch an HTML user interface component. To do that, it sends a REFER request to A's URI. The flow for this is shown in Figure 5. The conventions of [19] are used to describe representation of long message lines.
この例では、ユーザエージェントAとユーザエージェントBは、INVITEのプロキシとして働く各々が、サーバAとサーバBを介してINVITEが開始ダイアログを確立します。サーバBは、ユーザエージェントAは、HTMLユーザ・インターフェース・コンポーネントを取得することを要求するアプリケーションの対話の枠組み[14]を使用したいです。これを行うには、それはAのURIを参照する要求を送信します。このため流れは[19]の規則は、長いメッセージ行の表現を記述するために使用される図5に示されています。
A Server-A Server-B B
|(1) INVITE | | |
|----------->| | |
| |(2) INVITE | |
| |----------->| |
| | |(3) INVITE |
| | |----------->|
| | |(4) 200 OK |
| | |<-----------|
| |(5) 200 OK | |
| |<-----------| |
|(6) 200 OK | | |
|<-----------| | |
|(7) ACK | | |
|------------------------------------->|
| |(8) REFER | |
| |<-----------| |
|(9) REFER | | |
|<-----------| | |
|(10) 200 OK | | |
|----------->| | |
| |(11) 200 OK | |
| |----------->| |
Figure 5
図5
First, the caller sends an INVITE, as shown in message 1.
まず、発信者はメッセージ1に示すように、INVITEを送信します。
INVITE sips:B@example.com SIP/2.0 Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8 From: Caller <sip:A@example.com>;tag=kkaz-To: Callee <sip:B@example.org> Call-ID: fa77as7dad8-sd98ajzz@host.example.com CSeq: 1 INVITE Max-Forwards: 70 Supported: tdialog Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER Accept: application/sdp, text/html <allOneLine> Contact: <sips:A@example.com;gruu;opaque=urn:uuid:f81d4f ae-7dec-11d0-a765-00a0c91e6bf6;grid=99a>;schemes="http,sip,sips" </allOneLine> Content-Length: ... Content-Type: application/sdp
一口にINVITE：B@example.com SIP / 2.0経由：SIP / 2.0 / TLS host.example.com;ブランチ= z9hG4bK9zz8から：発信者<SIP：A@example.com>;タグ= kkaz-TO：呼び出し先<SIP： B@example.org>コール-IDを：fa77as7dad8-sd98ajzz@host.example.comのCSeq：マックス・フォワードを1 INVITE：70がサポートされている：tdialogは許可：受け入れ、INVITE OPTIONS、BYE、CANCEL、ACK、REFER：アプリケーション/ SDPを、 text / htmlの<allOneLine>連絡先：<一口：A@example.com; GRUU;不透明= URN：UUID：f81d4fのAE-7dec-11D0-a765-00a0c91e6bf6;グリッド= 99A>;スキーム= "HTTP、SIP、すすります" </ allOneLine>のContent-Length：...のContent-Type：アプリケーション/ SDP
--SDP not shown--
shown--ない--SDP
The INVITE indicates that the caller supports GRUU (note its presence in the Contact header field of the INVITE) and the Target-Dialog header field. This INVITE is forwarded to the callee (messages 2-3), which generates a 200 OK response that is forwarded back to the caller (message 4-5). Message 5 might look like:
INVITE発信者がGRUU（INVITEのContactヘッダーフィールドにおけるその存在に注意）とターゲット対話ヘッダフィールドをサポートしていることを示しています。このINVITEは、発呼者（メッセージ4-5）にバック転送され200 OK応答を生成する呼び出し先（メッセージ2-3）に転送されます。メッセージ5は次のようになります。
SIP/2.0 200 OK Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8 From: Caller <sip:A@example.com>;tag=kkaz-To: Callee <sip:B@example.org>;tag=6544 Call-ID: fa77as7dad8-sd98ajzz@host.example.com CSeq: 1 INVITE Contact: <sips:B@pc.example.org> Content-Length: ... Content-Type: application/sdp
SIP / 2.0 200 OK経由：SIP / 2.0 / TLS host.example.com;ブランチ= z9hG4bK9zz8から：発信者<SIP：A@example.com>;タグ= kkaz-TO：呼び出し先<SIP：B@example.org> ; = 6544のCall-IDタグ：fa77as7dad8-sd98ajzz@host.example.comのCSeq：1連絡先をINVITE：<一口：B@pc.example.org>のContent-Length：...のContent-Type：アプリケーション/ SDP
--SDP not shown--
shown--ない--SDP
In this case, the called party does not support GRUU or the Target-Dialog header field. The caller generates an ACK (message 7). Server B then decides to send a REFER to user A:
この場合、被呼者はGRUUまたはターゲット対話ヘッダフィールドをサポートしていません。呼び出し側はACK（メッセージ7）を生成します。サーバBは、ユーザAにREFERを送信することを決定します。
<allOneLine> REFER sips:A@example.com;gruu;opaque=urn:uuid:f81d4f ae-7dec-11d0-a765-00a0c91e6bf6;grid=99a SIP/2.0 </allOneLine> Via: SIP/2.0/TLS serverB.example.org;branch=z9hG4bK9zz10 From: Server B <sip:serverB.example.org>;tag=mreysh <allOneLine> To: Caller <sips:A@example.com;gruu;opaque=urn:uuid:f81d4f ae-7dec-11d0-a765-00a0c91e6bf6;grid=99a> </allOneLine> Target-Dialog: fa77as7dad8-sd98ajzz@host.example.com ;local-tag=kkaz-;remote-tag=6544 Refer-To: http://serverB.example.org/ui-component.html Call-ID: 86d65asfklzll8f7asdr@host.example.com CSeq: 1 REFER Max-Forwards: 70 Require: tdialog Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, NOTIFY Contact: <sips:serverB.example.org> Content-Length: 0
<allOneLine> REFER一口：A@example.com、GRUU、不透明= URN：UUID：f81d4f AE-7dec-11D0-a765-00a0c91e6bf6;グリッド= 99AのSIP / 2.0 </ allOneLine>のVia：SIP / 2.0 / TLSサーバB。 example.org;枝は= z9hG4bK9zz10から：サーバーB <SIP：serverB.example.org>;タグ= mreysh <allOneLine>宛先：発信者<一口：A@example.com; GRUU;不透明= URN：UUID：f81d4f AE- 7dec-11D0-a765-00a0c91e6bf6;グリッド= 99A> </ allOneLine>ターゲットダイアログ：fa77as7dad8-sd98ajzz@host.example.comと、ローカルタグ= kkaz-;リモートタグ= 6544参照の-TO：のhttp：//コールIDをserverB.example.org/ui-component.html：86d65asfklzll8f7asdr@host.example.comのCSeq：マックス・フォワードを1参照：70は必要：tdialogは許可：連絡先をNOTIFY、ACK、CANCEL、BYE、OPTIONSをINVITE：<一口：serverB.example.org>のContent-Length：0
This REFER will be delivered to server A because it was sent to the GRUU. From there, it is forwarded to user agent A (message 9) and authorized because of the presence of the Target-Dialog header field.
これは、それがGRUUに送られたため、サーバーAに配信されます参照してください。そこから、それは、ユーザエージェントA（メッセージ9）に転送され、なぜならターゲット対話ヘッダフィールドの存在を承認しました。
This specification registers a new SIP header field, a new option tag according to the processes of RFC 3261 [2], and two new header field parameters according to the processes of RFC 3968 [10].
この仕様は、RFC 3968の方法に従って[10] [2]新しいSIPヘッダフィールド、RFC 3261の方法に従って新しいオプションタグを登録し、2つの新しいヘッダフィールドパラメータ。
RFC Number: RFC 4538
RFC番号：RFC 4538
Header Field Name: Target-Dialog
ヘッダーフィールド名：ターゲット対話
Compact Form: none
コンパクトなフォーム：なし
This section registers two header field parameters according to the processes of RFC 3968 [10].
このセクションでは、RFC 3968 [10]の方法に従って2つのヘッダフィールドパラメータを登録します。
Header Field: Target-Dialog
ヘッダーフィールド：ターゲット対話
Header Field Parameter: local-tag
ヘッダーフィールドパラメータ：ローカルタグ
Predefined Values: None
事前定義された値：なし
RFC: RFC 4538
RFC：RFC 4538
Header Field: Target-Dialog
ヘッダーフィールド：ターゲット対話
Header Field Parameter: remote-tag
ヘッダーフィールドパラメータ：リモートタグ
Predefined Values: None
事前定義された値：なし
RFC: RFC 4538
RFC：RFC 4538
This specification registers a new SIP option tag per the guidelines in Section 27.1 of RFC 3261.
この仕様はRFC 3261のセクション27.1のガイドラインあたりの新しいSIPオプションタグを登録します。
Name: tdialog
名前：tdialog
Description: This option tag is used to identify the target dialog header field extension. When used in a Require header field, it implies that the recipient needs to support the Target-Dialog header field. When used in a Supported header field, it implies that the sender of the message supports it.
説明：このオプションタグは、ターゲットダイアログヘッダフィールド拡張を識別するために使用されます。 Requireヘッダーフィールドで使用される場合、それは、受信者がターゲット対話ヘッダフィールドをサポートする必要があることを意味します。 Supportedヘッダーフィールドで使用される場合は、メッセージの送信者がそれをサポートしていることを意味します。
This specification is based on a header field first proposed by Robert Sparks in the dialog usage draft [12]. John Elwell provided helpful comments.
この仕様は、最初のダイアログ使用ドラフト[12]にロバートスパークスによって提案されたヘッダフィールドに基づいています。ジョンエルウェルは役に立つコメントを提供しました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[3]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[4] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[4]ドノヴァン、S.、 "SIP INFO方法"、RFC 2976、2000年10月。
[5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[5]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3262、2002年6月 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[6] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[6]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）更新方法"、RFC 3311、2002年10月。
[7] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[7]キャンベル、B.、ローゼンバーグ、J.、Schulzrinneと、H.、のHuitema、C.、およびD. Gurle、 "インスタントメッセージングのためのセッション開始プロトコル（SIP）拡張子"、RFC 3428、2002年12月。
[8] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[8] R.、 "セッション開始プロトコル（SIP）メソッドを参照してください"、RFC 3515、2003年4月、火花。
[9] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[9]ニエミ、A.、 "イベント状態の出版のためのセッション開始プロトコル（SIP）の拡張"、RFC 3903、2004年10月。
[10] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[10]キャマリロ、G.、BCP 98、RFC 3968、2004年12月 "セッション開始プロトコル（SIP）の番号機関（IANA）ヘッダーフィールドパラメータレジストリ割り当てインターネット"。
[11] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[11]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[12] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", Work in Progress, March 2006.
[12]スパークス、R.、「セッション開始プロトコルの複数の対話用法」、進歩、2006年3月での作業。
[13] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, May 2006.
[13]ローゼンバーグ、J.、進歩、2006年5月における作業 "セッション開始プロトコル（SIP）におけるグローバルにルーティング可能なユーザエージェント（UA）のURI（GRUU）の取得と使用" を参照してください。
[14] Rosenberg, J., "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", Work in Progress, July 2005.
[14]ローゼンバーグ、J.、進歩、2005年7月ワーク「セッション開始プロトコル（SIP）でのアプリケーションの対話のためのフレームワーク」。
[15] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[15] RFC 4235 "セッション開始プロトコル（SIP）のためのINVITEが開始ダイアログイベントパッケージ" ローゼンバーグ、J.、Schulzrinneと、H.、およびR.マーイ、2005年11月。
[16] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Conference State", Work in Progress, July 2005.
[16]ローゼンバーグ、J.、 "Aセッション開始プロトコル（SIP）の会議の状態のためのイベントパッケージ"、進歩、2005年7月での作業。
[17] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[17]ローゼンバーグ、J.、RFC 4353、2006年2月 "セッション開始プロトコル（SIP）との会議のためのフレームワーク"。
[18] Burger, E., "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", Work in Progress, December 2004.
[18]バーガー、E.、 "Aセッション開始プロトコル（SIP）キーを押して刺激（KPML）のためのイベントパッケージ"、進歩、2004年12月に作業。
[19] Sparks, R., Ed., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.
[19]スパークス、R.、編、Hawrylyshen、A.、ジョンストン、A.、ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）調教テストメッセージ"、RFC 4475、2006年5月。
Author's Address
著者のアドレス
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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。