Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 6228 Ericsson
Category: Standards Track May 2011
ISSN: 2070-1721
Session Initiation Protocol (SIP) Response Code for
Indication of Terminated Dialog
Abstract
抽象
This specification defines a new Session Initiation Protocol (SIP) response code, 199 Early Dialog Terminated, that a SIP forking proxy and a User Agent Server (UAS) can use to indicate to upstream SIP entities (including the User Agent Client (UAC)) that an early dialog has been terminated, before a final response is sent towards the SIP entities.
この仕様は、SIPフォークプロキシとユーザエージェントサーバ（UAS）は（ユーザエージェントクライアント（UAC）を含む）、SIPエンティティを上流側に示すために使用することができ、新しいセッション開始プロトコル（SIP）応答コード、199初期のダイアログが終了を定義します初期のダイアログが終了したことを、最終的な応答がSIPエンティティに向けて送信される前に。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6228.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6228で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Applicability and Limitation ....................................4
4. User Agent Client Behavior ......................................4
5. User Agent Server Behavior ......................................6
6. Proxy Behavior ..................................................7
7. Backward Compatibility ..........................................9
8. Usage with SDP Offer/Answer .....................................9
9. Message Flow Examples ...........................................9
9.1. Example with a Forking Proxy that Generates 199 ............9
9.2. Example with a Forking Proxy that Receives 200 OK .........10
9.3. Example with Two Forking Proxies, of which One
Generates 199 .............................................11
10. Security Considerations .......................................12
11. IANA Considerations ...........................................13
11.1. IANA Registration of the 199 Response Code ...............13
11.2. IANA Registration of the 199 Option-Tag ..................13
12. Acknowledgements ..............................................13
13. References ....................................................14
13.1. Normative References .....................................14
13.2. Informative References ...................................14
As defined in RFC 3261 [RFC3261], a Session Initiation Protocol (SIP) early dialog is created when a non-100 provisional response is sent to the initial dialog initiation request (e.g., INVITE, outside an existing dialog). The dialog is considered to be in early state until a final response is sent.
[RFC3261] RFC 3261で定義されるような非100暫定応答は、最初のダイアログ開始要求（例えば、既存のダイアログ外、INVITE）に送信されたときに、セッション開始プロトコル（SIP）初期ダイアログが作成されます。ダイアログが最終応答が送信されるまで初期の状態にあると考えられています。
When a proxy receives an initial dialog initiation request, it can forward the request towards multiple remote destinations. When the proxy does that, it performs forking [RFC3261].
プロキシが最初のダイアログ開始要求を受信すると、複数のリモートの宛先への要求を転送することができます。プロキシがそれを行う際には、[RFC3261]をフォーク行います。
When a forking proxy receives a non-100 provisional response, or a 2xx final response, it forwards the response upstream towards the sender of the associated request. After a forking proxy has forwarded a 2xx final response, it normally generates and sends CANCEL requests downstream towards all remote destinations where it previously forked the request associated with the 2xx final response and from which it has still not received a final response. The CANCEL requests are sent in order to terminate any outstanding early dialogs associated with the request.
フォークプロキシが非100暫定応答、または2XX最終的な応答を受信すると、関連する要求の送信元に向けてアップストリーム応答を転送します。フォークプロキシが2XX最終応答を転送した後、それは通常発生し、それが以前の2xx最終応答と、それはまだ最終的な応答を受信しなかったから関連リクエストをフォークし、すべてのリモートの宛先に向けて下流要求をキャンセル送信します。 CANCELリクエストは、リクエストに関連付けられた未処理の早期ダイアログを終了させるために送信されます。
Upstream SIP entities might receive multiple 2xx final responses. When a SIP entity receives the first 2xx final response, and it does not intend to accept any subsequent 2xx final responses, it will automatically terminate any other outstanding early dialog associated with the request. If the SIP entity receives a subsequent 2xx final response, it will normally generate and send an ACK request, followed with a BYE request, using the dialog identifier retrieved from the 2xx final response.
上流のSIPエンティティは、複数の2xx最終応答を受け取ることがあります。 SIPエンティティが最初の2xx最終応答を受け取ると、それはそれ以降の2xx最終応答を受け入れることを意図していない場合は、自動的にリクエストに関連付けられている任意の他の優れた初期のダイアログを終了します。 SIPエンティティは、後続の2xx最終応答を受信した場合、それが通常生成し、ACKリクエストを送信する、2xxの最終的な応答から取得ダイアログ識別子を使用して、BYE要求が続きます。
NOTE: A User Agent Client (UAC) can use the Request-Disposition header field [RFC3841] to request that proxies do not generate and send CANCEL requests downstream once they have received the first 2xx final response.
注：ユーザエージェントクライアント（UAC）は、プロキシが生成し、彼らが最初の2xx最終応答を受け取った後、下流CANCELリクエストを送信しないことを要求するために、[RFC3841]のRequest-Dispositionヘッダーフィールドを使用することができます。
When a forking proxy receives a non-2xx final response, it does not always immediately forward the response upstream towards the sender of the associated request. Instead, the proxy "stores" the response and waits for subsequent final responses from other remote destinations where the associated request was forked. At some point, the proxy uses a specified mechanism to determine the "best" final response code, and forwards a final response using that response code upstream towards the sender of the associated request. When an upstream SIP entity receives the non-2xx final response, it will release resources associated with the session. The UAC will terminate, or retry, the session setup.
フォークプロキシが非2xxの最終的な応答を受信すると、それは常にすぐに関連付けられている要求の送信者に向けて上流の応答を転送しません。その代わりに、プロキシ「格納」関連したリクエストをフォークした他のリモート宛先からの後続の最終的な応答の応答を待ちます。ある時点で、プロキシは、「最良の」最終応答コードを決定するために、指定されたメカニズムを使用し、関連する要求の送信元に向けてアップストリームその応答コードを使用して、最終的な応答を転送します。上流のSIPエンティティが非2xxの最終的な応答を受信すると、セッションに関連付けられたリソースを解放します。 UACは、セッションセットアップを終了、または再試行します。
Since the forking proxy does not always immediately forward non-2xx final responses, upstream SIP entities (including the UAC that initiated the request) are not immediately informed that an early dialog has been terminated, and will therefore maintain resources associated with the early dialog reserved until a final response is sent by the proxy, even if the early dialog has already been terminated. A SIP entity could use the resources for other things, e.g., to accept subsequent early dialogs that it otherwise would reject.
フォークプロキシが必ずしもすぐに前方2xx以外の最終応答、（要求を開始UAC含む）上流のSIPエンティティを行いますので、すぐに初期のダイアログが終了したことを知らされていないので、予約の早期ダイアログに関連付けられたリソースを維持します最終応答するまで、初期のダイアログが既に終了している場合でも、プロキシによって送信されます。 SIPエンティティは、それはそれ以外拒否し、その後の早期ダイアログを受け入れるために、例えば、他のもののためのリソースを使用することができます。
This specification defines a new SIP response code, 199 Early Dialog Terminated. A forking proxy can send a 199 provisional response to inform upstream SIP entities that an early dialog has been terminated. A UAS can send a 199 response code, prior to sending a non-2xx final response, for the same purpose. SIP entities that receive the 199 response can use it to trigger the release of resources associated with the terminated early dialog. In addition, SIP entities might also use the 199 response to make policy decisions related to early dialogs. For example, a media gate controlling a SIP entity might use the 199 response when deciding for which early dialogs media will be passed.
この仕様は新しいSIP応答コードを定義し、199初期のダイアログが終了しました。フォークプロキシは、早期ダイアログが終了した上流のSIPエンティティに通知するために199暫定応答を送信することができます。 UASは、同じ目的のために、前の非2xxの最終的な応答を送信するために、199応答コードを送信することができます。 199応答を受信SIPエンティティは終了し、早期ダイアログに関連付けられたリソースの解放をトリガするためにそれを使用することができます。また、SIPエンティティはまた、早期ダイアログに関連した政策決定を行うために199応答を使用する場合があります。早期ダイアログのメディアが通過されるために決定するとき例えば、SIPエンティティを制御するメディアゲートは199応答を使用する場合があります。
Section 9 contains signalling examples that show when and how a forking proxy generates 199 responses in different situations.
第9章は、いつ、どのようにフォークプロキシが異なる状況で199応答を生成し、表示し、シグナリングの例が含まれています。
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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
The 199 response code is an optimization, and it only optimizes how quickly recipients might be informed about terminated early dialogs. The achieved optimization is limited. Since the response is normally not sent reliably by a UAS, and cannot be sent reliably when generated and sent by a proxy, it is possible that some or all of the 199 responses will get lost before they reach the recipients. In such cases, recipients will behave the same as if the 199 response code were not used at all.
199応答コードが最適化され、それは受信者のみが終了し、早期のダイアログについて通知される可能性がありますどのように迅速に最適化します。達成最適化が制限されています。応答は、通常、UASで確実に送信されず、生成されたプロキシによって送信されたときに確実に送信することができないので、彼らが受信者に到達する前に199の応答の一部または全部が迷子になる可能性があります。 199応答コードは全く使用されなかったかのようなケースでは、受信者が同じように動作します。
One example for which a UAC could use the 199 response is that when it receives a 199 response, it releases resources associated with the terminated early dialog. The UAC could also use the 199 response to make policy decisions related to early dialogs. For example, if a UAC is playing media associated with an early dialog, and it then receives a 199 response indicating the early dialog has been terminated, it could start playing media associated with a different early dialog.
UACは199応答を使用することができますのための一例としては、それは199応答を受信したとき、それが終了し、早期ダイアログに関連付けられたリソースを解放することです。 UACはまた、早期ダイアログに関連した政策決定を行うために199応答を使用することができます。 UACは、初期のダイアログに関連付けられたメディアを再生している、そしてそれは、その後、早期ダイアログが終了したことを示す199応答を受信した場合、それは別の初期のダイアログに関連付けられたメディアの再生を開始することができます。
Application designers utilizing the 199 response code MUST ensure that the application's user experience is acceptable if all 199 responses are lost and not delivered to the recipients.
199応答コードを利用したアプリケーションの設計者は、すべての199個の応答が失われたと受信者に配信されていない場合は、アプリケーションのユーザーエクスペリエンスが許容可能であることを確認しなければなりません。
When a UAC sends an initial dialog initiation request, and if it is willing to receive 199 responses, it MUST insert a "199" option-tag in the Supported header field [RFC3261] of the request. The option-tag indicates that the UAC supports, and is willing to receive, 199 responses. A UAC SHOULD NOT insert a "199" option-tag in the Require or the Proxy-Require header field [RFC3261] of the request, since in many cases it would result in unnecessary session establishment failures.
UACは最初のダイアログ開始要求を送信すると、199の応答を受信する意思がある場合、それはリクエストのSupportedヘッダーフィールド[RFC3261]で「199」オプションタグを挿入しなければなりません。オプションタグは、UACがサポートしていることを示し、そして、199の応答を受信していく所存です。 UACは、必要とするか、または多くの場合は不要セッション確立の失敗をもたらすので、リクエストのヘッダフィールド[RFC3261]をプロキシは、要求中の「199」オプションタグを挿入すべきではありません。
NOTE: The UAC always needs to insert a "199" option-tag in the Supported header field, in order to indicate that it supports, and is willing to receive, 199 responses, even if it also inserts the option-tag in the Require or Proxy-Require header field.
注：UACは、常にそれがまた必要でオプションタグを挿入しても、それがサポートしていることを示すために、サポートされているヘッダーフィールドに「199」オプションタグを挿入する必要があり、受信する意思がある、199の応答またはヘッダフィールドをプロキシ要求。
It is RECOMMENDED that a UAC not insert a "100rel" option-tag [RFC3262] in the Require header field when it also indicates support for 199 responses, unless the UAC also uses some other SIP extension or procedure that mandates it to do so. The reason is that proxies are not allowed to generate and send 199 responses when the UAC has required provisional responses to be sent reliably.
UACはまた、それがそうすることを義務付けていくつかの他のSIP拡張またはプロシージャを使用しない限り、それはまた、199の応答に対するサポートを示す場合UAC必要なヘッダフィールドに「100rel」オプションタグ[RFC3262]を挿入しないことが推奨されます。その理由は、UACが確実に送信される暫定応答を必要としたときにプロキシが199の応答を生成して送信することを許可されていないということです。
When a UAC receives a 199 response, it might release resources associated with the terminated early dialog. A UAC might also use the 199 response to make policy decisions related to early dialogs.
UACは199応答を受信すると、それが終了し、早期ダイアログに関連付けられたリソースを解放することがあります。 UACはまた、早期ダイアログに関連した政策決定を行うために199応答を使用する場合があります。
NOTE: The 199 response indicates that the early dialog has been terminated, so there is no need for the UAC to send a BYE request in order to terminate the early dialog when it receives the 199 response.
注：199レスポンスが早く、ダイアログが終了したことを示し、それは199応答を受信した場合に早期にダイアログを終了するためにBYE要求を送信するためにUACのための必要はありません。
NOTE: The 199 response does not affect other early dialogs associated with the session establishment. For those dialogs, the normal SIP rules regarding transaction timeout, etc., still apply.
注：199応答は、セッション確立に関連する他のearlyダイアログには影響を与えません。これらのダイアログの場合は、トランザクションタイムアウトなどに関する通常のSIPルールは、まだ適用されます。
Once a UAC has received and accepted a 199 response, it MUST NOT send any media associated with the early dialog. In addition, if the UAC is able to associate received media with early dialogs, it MUST NOT process any received media associated with the early dialog that was terminated.
UACは、受信した199応答を受け入れたら、それは初期のダイアログに関連付けられている任意のメディアを送ってはいけません。また、UACはearlyダイアログで受信したメディアを関連付けることができれば、それが終了した早期の対話に関連するすべての受信されたメディアを処理してはいけません。
If multiple usages [RFC5057] are used within an early dialog, and it is not clear which dialog usage the 199 response terminates, SIP entities that keep dialog state SHALL NOT release resources associated with the early dialog when they receive the 199 response.
複数の用法[RFC5057]は初期のダイアログ内で使用されており、199応答が終了ダイアログた使い方明確でない場合は、初期のダイアログに関連付けられたリソースを解放しないものと対話状態を維持するSIPエンティティは、彼らが199応答を受信したとき。
If a UAC receives an unreliably sent 199 response on a dialog that has not previously been established (this can happen if a 199 response reaches the client before the 18x response that would establish the early dialog) it SHALL discard the 199 response. If a UAC receives a reliably sent 199 response on a dialog that has not previously been created, it MUST acknowledge the 199 response, as described in RFC 3262 [RFC3262].
UACは、以前に確立されていないダイアログ上の不確実送られた199応答を受信した場合、それは199応答を廃棄する（199レスポンスが早く、ダイアログを確立する18X応答する前に、クライアントに到達した場合に発生することができます）。 UACは確実に以前に作成されていないダイアログに199応答を送信し受信した場合、RFC 3262 [RFC3262]で説明したように、それは、199の応答を確認する必要があります。
If a UAC has received a 199 response for all early dialogs, and no early dialogs associated with the session establishment remain, it maintains the "Proceeding" state [RFC3261] and waits for possible subsequent early dialogs to be established, and eventually for a final response to be received.
最終のために最終的にUACは、すべての初期ダイアログの199応答を受信し、セッションの確立に関連する初期ダイアログが残っていない場合、それは「Proceeding」ステート[RFC3261]を維持し、可能な後続の初期ダイアログが確立されるのを待ち、そして応答が受信されます。
If a UAS receives an initial dialog initiation request with a Supported header field that contains a "199" option-tag, it SHOULD NOT send a 199 response on an early dialog associated with the request before it sends a non-2xx final response. Cases where a UAS might send a 199 response are if it has been configured to do so due to lack of support for the 199 response code by forking proxies or other intermediate SIP entities, or if it is used in an environment that specifies that it shall send a 199 response before sending a non-2xx response.
UASは、「199」オプションタグが含まれているサポートされているヘッダフィールドとの最初の対話開始要求を受信した場合、それは非2xxの最終応答を送信する前に、その要求に関連した初期のダイアログで199応答を送るべきではありません。 UASは199応答を送信することがありますケースは、プロキシまたは他の中間のSIPエンティティをフォークで起因する199応答コードのためのサポートの欠如にそうするように設定されているされている場合、またはそれはべきことを指定した環境で使用されている場合2xx以外の応答を送信する前に199応答を送信します。
NOTE: If a UAS has created multiple early dialogs associated with an initial dialog initiation request (the UAS is acting similarly to a forking proxy), it does not always intend to send a final response on all of those early dialogs.
注：UASは最初のダイアログ開始要求に関連付けられた複数の早期ダイアログを作成している場合（UASは、フォーキングプロキシと同様に機能している）、それは常にこれらの初期のダイアログのすべての最終応答を送信する予定はありません。
NOTE: If the Require header field of an initial dialog initiation request contains a "100rel" option-tag, proxies will not be able to generate and send 199 responses. In such cases, the UAS might choose to send a 199 response on an early dialog before it sends a non-2xx final response, even if it would not do so in other cases.
注：最初のダイアログ開始要求のRequireヘッダーフィールドは「100rel」オプションタグが含まれている場合、プロキシは199の応答を生成して送信することができません。このような場合には、UASは、それが他のケースではそういないだろうしても、非2xxの最終応答を送信する前に、早期ダイアログに199応答を送信することを選択するかもしれません。
If the Supported header field of an initial dialog initiation request does not contain a "199" option-tag, the UAC MUST NOT send a 199 response on any early dialog associated with the request.
最初のダイアログ開始要求のSupportedヘッダーフィールドが「199」オプションタグが含まれていない場合、UACは、リクエストに関連付けられている任意の早期ダイアログの199応答を送ってはいけません。
When a UAS generates a 199 response, the response MUST contain a To header field tag parameter [RFC3261], in order for other entities to identify the early dialog that has been terminated. The UAS MUST also insert a Reason header field [RFC3326] that contains a response code describing the reason why the early dialog was terminated. The UAS MUST NOT insert a "199" option-tag in the Supported, Require, or Proxy-Require header field of the 199 response.
UASは199応答を生成する場合、応答は、他のエンティティが終了した初期のダイアログを識別するために、フィールドタグパラメータ[RFC3261]をToヘッダを含まなければなりません。 UASはまた、初期のダイアログが終了した理由を記述した応答コードが含まれている理由ヘッダーフィールド[RFC3326]を挿入する必要があります。 UASはサポートされている中で、「199」オプションタグを挿入してはならない、要求、または199レスポンスのヘッダフィールドをプロキシ要求。
If a UAS intends to send 199 responses, and if it supports the procedures defined in RFC 3840 [RFC3840], it MAY during the registration procedure use the sip.extensions feature tag [RFC3840] to indicate support for the 199 response code.
UASは199の応答を送信しようと、それはRFC 3840 [RFC3840]で定義された手順をサポートしている場合、それは登録手続きの際に使用する可能性がある場合sip.extensionsは199応答コードのサポートを示すために、タグ[RFC3840]を備えています。
A 199 response SHOULD NOT contain a Session Description Protocol (SDP) offer/answer message body, unless required by the rules in RFC 3264 [RFC3264].
RFC 3264 [RFC3264]の規則によって必要とされない限り199応答は、セッション記述プロトコル（SDP）オファー/アンサーメッセージ本体を含んではなりません。
According to RFC 3264, if an INVITE request does not contain an SDP offer, and the 199 response is the a first reliably sent response associated with the request, the 199 response is required to contain an SDP offer. In this case, the UAS SHOULD send the 199 response unreliably, or send the 199 response reliably and include an SDP offer with no "m=" lines in the response.
RFC 3264によれば、INVITE要求場合、SDPオファーを含まず、第確実要求に関連する応答を送信した199応答は、199応答はSDPオファーを含むために必要とされます。この場合、UASは、信頼できない199応答を送信、または確実に199応答を送信し、応答しない「M =」行を有するSDPオファーを含むべきです。
Since a 199 response is only used for information purposes, the UAS SHOULD send it unreliably, unless the "100rel" option-tag is present in the Require header field of the associated request.
199応答は、情報のみの目的のために使用されるので、「100rel」オプションタグは、関連する要求の要求ヘッダーフィールドに存在しない限り、UASは、信頼できないことを送信すべきです。
When a proxy receives a 199 response to an initial dialog initiation request, it MUST process the response as any other non-100 provisional response. The proxy will forward the response upstream towards the sender of the associated request. The proxy MAY release resources it has reserved associated with the early dialog that is terminated. If a proxy receives a 199 response out of dialog, it MUST process it as other non-100 provisional responses received out of dialog.
プロキシは最初のダイアログ開始要求に対する199応答を受信すると、それは他の非100暫定応答としての応答を処理しなければなりません。プロキシは、関連する要求の送信者に向けて上流の応答を転送します。プロキシは、それが終了し、早期ダイアログに関連した予約していたリソースを解放することができます。プロキシは、ダイアログのうち、199応答を受信した場合、それは、ダイアログのうち、受信した他の非100暫定応答として、それを処理しなければなりません。
When a forking proxy receives a non-2xx final response to an initial dialog initiation request that it recognizes as terminating one or more early dialogs associated with the request, it MUST generate and send a 199 response upstream for each of the terminated early dialogs that satisfy each of the following conditions:
フォーキングプロキシは、要求に関連する1つまたは複数の初期ダイアログを終了として認識最初のダイアログ開始要求に対する非2xxの最終的な応答を受信すると、それが生成して満たす終了初期ダイアログのそれぞれに対して上流の199応答を送信しなければなりません以下の条件の各：
- The forking proxy does not intend to forward the final response immediately (in accordance with rules for a forking proxy).
- フォーキングプロキシは（フォーキングプロキシの規則に従って）直ちに最終的な応答を転送することを意図していません。
- The UAC has indicated support (by inserting the "199" option-tag in a Supported header field) for the 199 response code in the associated request.
- UACは、関連する要求199レスポンスコードを（Supportedヘッダーフィールドに「199」オプションタグを挿入することによって）サポートを示しています。
- The UAC has not required provisional responses to be sent reliably (i.e., has not inserted the "100rel" option-tag in a Require or Proxy-Require header field) in the associated request.
- UACを確実に送信される暫定的な応答を必要としていない関連要求で（すなわち、「100rel」オプションタグ要求またはプロキシ要求ヘッダーフィールドに挿入していません）。
- The forking proxy has not already received and forwarded a 199 response for the early dialog.
- フォークプロキシは、既に受信し、早期ダイアログの199応答を転送していません。
- The forking proxy has not already sent a final response for any of the early dialogs.
- フォークプロキシは、すでにearlyダイアログのいずれかの最終的な応答を送信していません。
As a consequence, once a final response to an initial dialog initiation request has been issued by the proxy, no further 199 responses associated with the request will be generated or forwarded by the proxy.
その結果、初期の対話開始要求に一度最終的な応答には、さらに、要求に関連した199個の応答がプロキシによって生成または転送されます、プロキシによって発行されていません。
When a forking proxy forks an initial dialog initiation request, it generates a unique Via header branch parameter value for each forked leg. A proxy can determine whether additional forking has occurred downstream of the proxy by storing the top Via branch value from each response that creates an early dialog. If the same top Via branch value is received for multiple early dialogs, the proxy knows that additional forking has occurred downstream of the proxy. A non-2xx final response received for a specific early dialog also terminates all other early dialogs for which the same top Via branch value was received in the responses that created those early dialogs.
フォークプロキシフォーク最初のダイアログ開始要求は、それが各フォークレッグのヘッダ分岐パラメータ値経由ユニークを生成するとき。プロキシは、追加のフォークが早期にダイアログを作成し、各応答から分岐値経由トップを格納することで、プロキシの下流発生したか否かを判断することができます。枝値経由同じトップが複数の早期ダイアログのために受信された場合、プロキシは追加のフォークは、プロキシの下流に発生していることを知っています。特定の早期ダイアログのために受信2xx以外の最終応答はまた、分岐値経由同じトップは、これらの初期のダイアログを作成した応答で受信した他のすべてのearlyダイアログを終了します。
Based on implementation policy, a forking proxy MAY wait before sending the 199 response, e.g., if it expects to receive a 2xx final response on another dialog shortly after it received the non-2xx final response that triggered the 199 response.
それは199応答を引き起こした非2xxの最終的な応答を受け取った直後に別のダイアログ上の2xx最終応答を受信することを期待場合は、実装の方針に基づき、フォークプロキシは、例えば、199応答を送信する前に待つことができます。
When a forking proxy generates a 199 response, the response MUST contain a To header field tag parameter that identifies the terminated early dialog. A proxy MUST also insert a Reason header field that contains the SIP response code of the response that triggered the 199 response. The SIP response code in the Reason header field informs the receiver of the 199 response about the SIP response code that was used by the UAS to terminate the early dialog, and the receiver might use that information for triggering different types of actions and procedures. The proxy MUST NOT insert a "199" option-tag in the Supported, Require, or Proxy-Require header field of the 199 response.
フォークプロキシは199応答を生成するとき、応答が終了し、早期ダイアログを特定Toヘッダーフィールドのtagパラメータを含まなければなりません。プロキシは、199応答を誘発し、応答のSIP応答コードを含むReasonヘッダフィールドを挿入する必要があります。 Reasonヘッダフィールドに、SIP応答コードは、初期ダイアログを終了するためにUASによって使用されたSIP応答コード約199応答の受信を通知し、受信機は、アクションおよび手順の異なるタイプをトリガするためにその情報を使用するかもしれません。プロキシがサポートされている中で、「199」オプションタグを挿入してはならない、要求、または199レスポンスのヘッダフィールドをプロキシ要求。
A forking proxy that supports the generation of 199 responses MUST keep track of early dialogs, in order to determine whether to generate a 199 response when the proxy receives a non-2xx final response. In addition, a proxy MUST keep track on which early dialogs it has received and forwarded 199 responses, in order to not generate additional 199 responses for those early dialogs.
199の応答の生成をサポートしているフォークプロキシはプロキシが非2xxの最終的な応答を受信したときに199応答を生成するかどうかを決定するために、早期のダイアログを追跡する必要があります。また、プロキシは、これらの初期のダイアログの追加の199の応答を生成しないためには、早期のダイアログは、それが受信され、199の応答を転送した上で追跡する必要があります。
If a forking proxy receives a reliably sent 199 response for a dialog for which it has previously generated and sent a 199 response, it MUST forward the 199 response. If a proxy receives an unreliably sent 199 response for which it has previously generated and sent a 199 response, it MAY forward the response, or it MAY discard it.
フォークプロキシは、それが以前に生成され、199応答を送信しているため、ダイアログのため確実に送信199応答を受信した場合、それは199応答を転送する必要があります。プロキシは、それが以前に生成され、199応答を送信しているため信頼できない送信された199応答を受信した場合、それは応答を転送することができる、またはそれを捨てるかもしれ。
When a forking proxy generates and sends a 199 response, the response SHOULD NOT contain a Contact header field or a Record-Route header field [RFC3261].
フォーキングプロキシは199応答を生成して送信すると、応答は、Contactヘッダフィールド又はRecord-Routeヘッダフィールド[RFC3261]を含むべきではありません。
If the Require header field of an initial dialog initiation request contains a "100rel" option-tag, a proxy MUST NOT generate and send 199 responses associated with that request. The reason is that a proxy is not allowed to generate and send 199 responses reliably.
最初のダイアログ開始要求のRequireヘッダーフィールドは「100rel」オプションタグが含まれている場合、プロキシはその要求に関連した199の応答を生成して送ってはいけません。その理由は、プロキシが確実に199の応答を生成して送信することが許可されていないということです。
Since all SIP entities involved in a session setup do not necessarily support the specific meaning of the 199 Early Dialog Terminated provisional response, the sender of the response MUST be prepared to receive SIP requests and responses associated with the dialog for which the 199 response was sent (a proxy can receive SIP messages from either direction). If such a request is received by a UA, it MUST act in the same way as if it had received the request after sending the final non-2xx response to the INVITE request, as specified in RFC 3261. A UAC that receives a 199 response for an early dialog MUST NOT send any further requests on that dialog, except for requests that acknowledge reliable responses. A proxy MUST forward requests according to RFC 3261, even if the proxy has knowledge that the early dialog has been terminated.
セッションセットアップに関与するすべてのSIPエンティティは、必ずしも199早期ダイアログ終端暫定応答の特定の意味をサポートしていないので、レスポンスの送信者が199応答が送信されたためのダイアログに関連付けられているSIPの要求と応答を受け取るために準備しなければなりません（プロキシがどちらの方向からSIPメッセージを受信することができます）。そのような要求は、UAによって受信された場合、それは199応答を受信したRFC 3261 A UACで指定されるように、INVITE要求に対する最終非2XX応答を送信した後、要求を受信したかのように、それは同じように作用しなければなりません早期ダイアログのための信頼性の高いレスポンスを確認要求を除いて、そのダイアログ上の任意の更なる要求を送ってはいけません。プロキシはプロキシが早くダイアログが終了したことを知っている場合でも、RFC 3261に従って要求を転送しなければなりません。
A 199 response does not "replace" a final response. RFC 3261 specifies when a final response is sent.
199応答は最終応答を「置き換え」はありません。 RFC 3261は、最終応答が送信されたときに指定します。
A 199 response SHOULD NOT contain an SDP offer/answer [RFC3264] message body, unless required by the rules in RFC 3264.
RFC 3264の規則により要求される場合を除き199応答は、SDPオファー/アンサー[RFC3264]メッセージボディを含めることはできません。
If an INVITE request does not contain an SDP offer, and the 199 response is the first reliably sent response, the 199 response is required to contain an SDP offer. In this case, the UAS SHOULD send the 199 response unreliably, or include an SDP offer with no "m=" lines in a reliable 199 response.
SDPオファーが含まれていないINVITEリクエストを、199応答が確実にレスポンスを送信される最初の場合は、199応答はSDPオファーを含有することが要求されます。この場合、UASは、信頼できない199応答を送信し、または信頼できる199応答しない「M =」行を有するSDPオファーを含むべきです。
Figure 1 shows an example where a proxy (P1) forks an INVITE received from a UAC. The forked INVITE reaches UAS_2, UAS_3, and UAS_4, which send 18x provisional responses in order to establish early dialogs between themselves and the UAC. UAS_2 and UAS_3 each reject the INVITE by sending a 4xx error response. When P1 receives the 4xx responses, it immediately sends 199 responses towards the UAC, to indicate that the early dialogs for which it received the 4xx responses have been terminated. The early dialog leg is shown in parentheses.
図1は、プロキシ（P1）フォークUACから受信したINVITE例を示しています。 INVITEフォーク自身とUACの間で早期のダイアログを確立するために、18xの暫定応答を送信UAS_2、UAS_3、およびUAS_4に達します。 UAS_2とUAS_3それぞれの4xxエラー応答を送信することにより、INVITEを拒否します。 P1はの4xx応答を受信すると、それはすぐにそれがの4xx応答を受信したため、早期のダイアログが終了したことを示すために、UACに向けて199の応答を送信します。初期のダイアログ足はカッコ内に示されています。
UAC P1 UAS_2 UAS_3 UAS_4
| | | | |
|-- INVITE -->| | | |
| |--- INVITE (2) ->| | |
| |--- INVITE (3) --------->| |
| |--- INVITE (4) ----------------->|
| |<-- 18x (2) -----| | |
|<- 18x (2) --| | | |
| |<-- 18x (3) -------------| |
|<- 18x (3) --| | | |
| |<-- 18x (4) ---------------------|
|<- 18x (4) --| | | |
| |<-- 4xx (2) -----| | |
| |--- ACK (2) ---->| | |
|<- 199 (2) --| | | |
| |<-- 4xx (3) -------------| |
| |--- ACK (3) ------------>| |
|<- 199 (3) --| | | |
| |<-- 200 (4) ---------------------|
|<- 200 (4) --| | | |
|-- ACK (4) ->| | | |
| |--- ACK (4) -------------------->|
| | | | |
Figure 1: Example Call Flow
図1：例コールフロー
Figure 2 shows an example where a proxy (P1) forks an INVITE request received from a UAC. The forked request reaches UAS_2, UAS_3, and UAS_4, all of which send 18x provisional responses in order to establish early dialogs between themselves and the UAC. Later, UAS_4 accepts the session and sends a 200 OK final response. When P1 receives the 200 OK response, it immediately forwards it towards the UAC. P1 does not send 199 responses for the early dialogs from UAS_2 and UAS_3, since P1 has still not received any final responses on those early dialogs (even if P1 sends CANCEL requests to UAS_2 and UAS_3, P1 may still receive a 200 OK final response from UAS_2 or UAS_3, which P1 would have to forward towards the UAC. The early dialog leg is shown in parentheses.
図2は、INVITEリクエストがUACから受信したプロキシ（P1）フォーク例を示しています。フォーク要求自体とUACの間で早期のダイアログを確立するために、18xの暫定応答を送信するすべてがUAS_2、UAS_3、およびUAS_4に達します。その後、UAS_4はセッションを受け入れ、200 OK最終応答を送信します。 P1は、200 OK応答を受信すると、それはすぐにUACに向けて転送します。 P1は、まだこれらの初期のダイアログ上の任意の最終応答を受け取っていないので、P1は、UAS_2とUAS_3からの早期ダイアログの199の応答を送信しません（P1がUAS_2とUAS_3にCANCELリクエストを送信した場合でも、P1は、まだから200 OK最終応答を受け取ることができますP1はUACに向けて転送する必要がありますUAS_2またはUAS_3は、早期ダイアログ足はカッコ内に示されています。
UAC P1 UAS_2 UAS_3 UAS_4
| | | | |
|-- INVITE -->| | | |
| |--- INVITE (2) ->| | |
| |--- INVITE (3) --------->| |
| |--- INVITE (4) ----------------->|
| |<-- 18x (2) -----| | |
|<- 18x (2) --| | | |
| |<-- 18x (3) -------------| |
|<- 18x (3) --| | | |
| |<-- 18x (4) ---------------------|
|<- 18x (4) --| | | |
| |<-- 200 (4) ---------------------|
|<- 200 (4) --| | | |
|-- ACK (4) ->| | | |
| |--- ACK (4) -------------------->|
| | | | |
Figure 2: Example Call Flow
図2：例コールフロー
Figure 3 shows an example where a proxy (P1) forks an INVITE request received from a UAC. One of the forked requests reaches UAS_2. The other requests reach another proxy (P2), which forks the request to UAS_3 and UAS_4. UAS_3 and UAS_4 send 18x provisional responses in order to establish early dialogs between themselves and the UAC. Later, UAS_3 and UAS_4 each reject the INVITE request by sending a 4xx error response. P2 does not support the 199 response code and forwards a single 4xx response. P1 supports the 199 response code, and when it receives the 4xx response from P2, it also manages to associate the early dialogs from both UAS_3 and UAS_4 with the response. Therefore, P1 generates and sends two 199 responses to indicate that the early dialogs from UAS_3 and UAS_4 have been terminated. The early dialog leg is shown in parentheses.
図3は、INVITEリクエストがUACから受信したプロキシ（P1）フォーク例を示しています。フォーク要求の一つは、UAS_2に達します。他の要求はUAS_3とUAS_4にリクエストをフォーク別のプロキシ（P2）に達します。 UAS_3とUAS_4は自分自身とUACの間で早期のダイアログを確立するために、18xの暫定応答を送信します。その後、UAS_3とUAS_4それぞれの4xxエラー応答を送信することにより、INVITEリクエストを拒否します。 P2は199応答コードをサポートし、単一4XX応答を転送しません。 P1は、199応答コードをサポートし、それがP2からの4xx応答を受信したとき、それはまた、応答でUAS_3とUAS_4の両方からの早期のダイアログを関連付けるために管理しています。したがって、P1はUAS_3とUAS_4からの早期のダイアログが終了したことを示すために2つの199の応答を生成して送信します。初期のダイアログ足はカッコ内に示されています。
UAC P1 P2 UAS_2 UAS_3 UAS_4
| | | | | |
|-- INVITE -->| | | | |
| |-- INVITE (2) ------------------>| | |
| |-- INVITE ---->| | | |
| | |--- INVITE (3) --------->| |
| | |--- INVITE (4) ----------------->|
| | |<-- 18x (3) -------------| |
| |<- 18x (3) ----| | | |
|<- 18x (3) --| | | | |
| | |<-- 18x (4) ---------------------|
| |<- 18x (4) ----| | | |
|<- 18x (4) --| | | | |
| | |<-- 4xx (3) -------------| |
| | |--- ACK (3) ------------>| |
| | |<-- 4xx (4) ---------------------|
| | |--- ACK (4) -------------------->|
| |<- 4xx (3) ----| | | |
| |-- ACK (3) --->| | | |
|<- 199 (3) --| | | | |
|<- 199 (4) --| | | | |
| |<- 200 (2) ----------------------| | |
|<- 200 (2) --| | | | |
|-- ACK (2) ->| | | | |
| |-- ACK (2) --------------------->| | |
| | | | | |
Figure 3: Example Call Flow
図3：例コールフロー
General security issues related to SIP responses are described in RFC 3261. Due to the nature of the 199 response, it may be attractive to use it for launching attacks in order to terminate specific early dialogs (other early dialogs will not be affected). In addition, if a man-in-the-middle generates and sends towards the UAC a 199 response that terminates a specific dialog, it can take a while until the UAS finds out that the UAC, and possible stateful intermediates, have terminated the dialog. SIP security mechanisms (e.g., hop-to-hop Transport Layer Security (TLS)) can be used to minimize, or eliminate, the risk of such attacks.
応答をSIPに関連する一般的なセキュリティ上の問題が原因199応答の性質のためにRFC 3261に記述されている、（他の初期ダイアログが影響されることはありません）特定の早期ダイアログを終了させるために攻撃を起動するためにそれを使用して魅力的かもしれません。 man-in-the-middleが生成し、UAC特定のダイアログを終了199応答に向けて送信した場合、UASはUAC、可能なステートフル中間体は、ダイアログを終了していることを発見するまで加えて、それはしばらく時間がかかることができます。 SIPセキュリティメカニズム（例えば、ホップ・ツー・ホップトランスポート層セキュリティ（TLS））は、そのような攻撃のリスクを最小限に抑える、または排除するために使用することができます。
This section registers a new SIP response code and a new option-tag, according to the procedures of RFC 3261.
このセクションでは、RFC 3261の手順に従って、新しいSIP応答コードと新しいオプションタグを登録します。
This section registers a new SIP response code, 199. The required information for this registration, as specified in RFC 3261, is:
このセクションはこの登録のための新しいSIP応答コード、199必要な情報を登録し、RFC 3261で指定されるように、です。
RFC Number: RFC 6228
RFC番号：RFC 6228
Response Code Number: 199
応答コード番号：199
Default Reason Phrase: Early Dialog Terminated
デフォルトの理由フレーズ：初期のダイアログが終了
This section registers a new SIP option-tag, 199. The required information for this registration, as specified in RFC 3261, is:
このセクションでは、新しいSIPオプションタグ、この登録のために199必要な情報を登録し、RFC 3261で指定され、次のとおりです。
Name: 199
名前：199
Description: This option-tag is for indicating support of the 199 Early Dialog Terminated provisional response code. When present in a Supported header of a request, it indicates that the UAC supports the 199 response code. When present in a Require or Proxy-Require header field of a request, it indicates that the UAS, or proxies, MUST support the 199 response code. It does not require the UAS, or proxies, to actually send 199 responses.
説明：このオプションタグ199アーリーダイアログ終端暫定応答コードのサポートを示すためのものです。存在する場合、要求のSupportedヘッダには、UAC 199応答コードをサポートしていることを示しています。場合リクエストの要求またはプロキシ要求ヘッダーフィールド内に存在する、それはUAS、またはプロキシは、199応答コードをサポートしなければならないことを示しています。これは、実際に199の応答を送信するために、UAS、またはプロキシを必要としません。
Thanks to Paul Kyzivat, Dale Worley, Gilad Shaham, Francois Audet, Attila Sipos, Robert Sparks, Brett Tate, Ian Elz, Hadriel Kaplan, Timothy Dwight, Dean Willis, Serhad Doken, John Elwell, Gonzalo Camarillo, Adam Roach, Bob Penfield, Tom Taylor, Ya Ching Tan, Keith Drage, Hans Erik van Elburg, and Cullen Jennings for their feedback and suggestions.
ポール・Kyzivat、デイル・ウォーリー、ギラッドシャハム、フランソワAudet、アッティラSIPOS、ロバート・スパークス、ブレット・テイト、イアン・エルツ、Hadrielカプラン、ティモシードワイト、ディーンウィリス、Serhad Doken、ジョンエルウェル、ゴンサロ・カマリロ、アダムローチ、ボブペンフィールドのおかげで、彼らのフィードバックや提案のためのトム・テイラー、雅チンタン、キース糖剤、ハンス・エリック・バンElburg、そしてカレンジェニングス。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3261] 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.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3262、2002年6月 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002.
[RFC3326] Schulzrinneと、H.、オラン、D.、およびG.カマリロ、RFC 3326 "セッション開始プロトコル（SIP）理由ヘッダーフィールド" 2002年12月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェントの能力を示します"。
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC3841]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、 "セッション開始プロトコル（SIP）のための発信者が設定"、RFC 3841、2004年8月。
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", RFC 5057, November 2007.
[RFC5057]スパークス、R.、 "セッション開始プロトコルの複数の対話用法"、RFC 5057、2007年11月。
Author's Address
著者のアドレス
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
クリステルHolmbergのエリクソンHirsalantie 11 02420 Jorvasフィンランド
EMail: christer.holmberg@ericsson.com
メールアドレス：christer.holmberg@ericsson.com