[要約] RFC 6228は、SIPの応答コードを使用して終了したダイアログを示すための仕様です。目的は、ダイアログの終了を明示的に通知することで、通信の効率性と信頼性を向上させることです。
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
セッション開始プロトコル（SIP）終了ダイアログの表示のための応答コード
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）が上流のSIPエンティティ（ユーザーエージェントクライアント（UAC）を含む）を示すために使用できる、SIPフォーキングプロキシとユーザーエージェントサーバー（UAS）が終了する新しいセッション開始プロトコル（SIP）応答コードを定義します。最終的な応答が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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
RFC 3261 [RFC3261]で定義されているように、セッション開始プロトコル（SIP）の早期ダイアログは、初期ダイアログ開始要求（既存のダイアログ外の招待など）に100以外の暫定応答が送信されると作成されます。ダイアログは、最終的な応答が送信されるまで早期状態にあると見なされます。
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最終応答に関連するリクエストを以前に分岐し、そこから最終的な応答を受け取っていません。キャンセル要求は、リクエストに関連付けられた未解決の早期ダイアログを終了するために送信されます。
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最終応答から取得したダイアログ識別子を使用して、さようならリクエストを送信します。
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）は、リクエスト閉じ込めヘッダーフィールド[RFC3841]を使用して、プロキシが最初の2XX最終応答を受け取った後、下流の要求を生成および送信することを要求できます。
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以外の最終応答をすぐに転送するとは限らないため、上流のSIPエンティティ（リクエストを開始したUACを含む）は、早期ダイアログが終了したことをすぐに通知されないため、早期ダイアログに関連するリソースを維持します。初期のダイアログがすでに終了していても、最終的な応答がプロキシによって送信されるまで。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の早期ダイアログが終了しました。フォーキングプロキシは、199の暫定的な対応を送信して、上流のSIPエンティティに初期のダイアログが終了したことを通知できます。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の応答を使用できる例の1つは、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の回答を受け取る意思がある場合、リクエストのサポートされているヘッダーフィールド[RFC3261]に「199」オプションタグを挿入する必要があります。オプションタグは、UACが199の回答をサポートし、喜んで受け取ることを示しています。UACは、要求の「199」オプションタグまたはリクエストのプロキシリクイアヘッダーフィールド[RFC3261]を挿入しないでください。
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」オプションタグを常に挿入する必要があります。またはプロキシリクイアヘッダーフィールド。
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が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の応答を受信したときに初期のダイアログを終了するために、UACがBYEリクエストを送信する必要はありません。
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の応答は、セッションの確立に関連する他の早期ダイアログには影響しません。これらのダイアログには、トランザクションタイムアウトなどに関する通常の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が受信メディアを早期ダイアログに関連付けることができる場合、終了した初期のダイアログに関連付けられた受信メディアを処理してはなりません。
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の応答が早期ダイアログを確立する18x応答の前にクライアントに到達した場合に発生する可能性があります）、199の応答を破棄します。RFC 3262 [RFC3262]に記載されているように、UACが以前に作成されたことのないダイアログで199の応答を受信した場合、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の応答を受け取っており、セッションの確立に関連する初期の対話が残っていない場合、「議事録」状態[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」のオプションタグを含むサポートされているヘッダーフィールドを使用して初期ダイアログ開始要求を受信した場合、リクエストに関連付けられた早期ダイアログに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.
注：最初のダイアログ開始要求の要求ヘッダーフィールドに「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.
最初のダイアログ開始要求のサポートされているヘッダーフィールドに「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]を含める必要があります。また、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機能タグ[RFC3840]を使用して、199の回答コードのサポートを示すことがあります。
A 199 response SHOULD NOT contain a Session Description Protocol (SDP) offer/answer message body, unless required by the rules in RFC 3264 [RFC3264].
199の応答には、RFC 3264 [RFC3264]のルールで要求されない限り、セッション説明プロトコル（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によると、招待リクエストに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の応答は情報目的でのみ使用されるため、UASは、関連するリクエストの要求ヘッダーフィールドに「100Rel」オプションタグが存在しない限り、それを不当に送信する必要があります。
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」オプションタグを挿入することにより）サポートを示しています。
- 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.
- フォーキングプロキシは、初期のダイアログのいずれに対しても最終的な応答をまだ送信していません。
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最終応答は、それらの初期ダイアログを作成した応答でブランチ値を介して受信した他のすべての初期ダイアログも終了します。
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の応答を生成する場合、応答には、終了した早期ダイアログを識別するヘッダーフィールドタグパラメーターを含める必要があります。プロキシは、199の応答をトリガーした応答のSIP応答コードを含む理由ヘッダーフィールドも挿入する必要があります。理由ヘッダーフィールドの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の応答を生成して送信する場合、応答にはコンタクトヘッダーフィールドまたはレコードルートヘッダーフィールド[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.
最初のダイアログ開始要求の要求ヘッダーフィールドに「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の早期ダイアログの特定の意味を必ずしもサポートしているわけではないため、応答の送信者は、199回の応答が送信されたダイアログに関連付けられたSIPリクエストと応答を受信するために準備する必要があります。（プロキシはどちらの方向からもSIPメッセージを受信できます）。そのような要求がUAによって受信された場合、RFC 3261で指定されているように、招待リクエストに最終的な非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.
199の応答には、RFC 3264のルールで要求されない限り、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オファーが含まれていない場合、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から受け取った招待状を分岐する例を示しています。Forked Inviteは、UAS_2、UAS_3、およびUAS_4に到達します。これは、自分自身とUACの間に早期の対話を確立するために18倍の暫定的な応答を送信します。UAS_2とUAS_3はそれぞれ、4xxエラー応答を送信することにより招待を拒否します。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は、プロキシ（P1）がUACから受け取った招待リクエストを分岐する例を示しています。Forked RequestはUAS_2、UAS_3、およびUAS_4に到達します。これらはすべて、18倍の暫定的な応答を送信して、自分自身とUACの間に早期の対話を確立します。その後、UAS_4はセッションを受け入れ、200のOK最終応答を送信します。P1が200 OK応答を受信すると、すぐにUACに転送します。P1は、UAS_2およびUAS_3からの初期のダイアログに対して199の回答を送信しません。P1はそれらの初期ダイアログの最終的な応答をまだ受け取っていないためです（P1がUAS_2およびUAS_3にキャンセル要求を送信した場合でも、P1はまだ200 OK最終応答を受け取る可能性がありますUAS_2またはUAS_3は、P1がUACに向かって転送する必要があります。初期のダイアログレッグは括弧内に表示されます。
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は、プロキシ（P1）がUACから受け取った招待リクエストを分岐する例を示しています。フォークリクエストの1つはUAS_2に到達します。他のリクエストは別のプロキシ（P2）に到達し、UAS_3およびUAS_4への要求が分岐します。UAS_3とUAS_4は、自分自身とUACの間に早期の対話を確立するために、18倍の暫定応答を送信します。その後、UAS_3とUAS_4はそれぞれ、4XXエラー応答を送信することにより、招待リクエストを拒否します。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応答に関連する一般的なセキュリティの問題は、RFC 3261で説明されています。199の応答の性質上、特定の初期ダイアログを終了するために攻撃を開始するために使用するのが魅力的かもしれません（他の初期ダイアログは影響を受けません）。さらに、中間者が特定のダイアログを終了する199の応答を生成してUACに送信した場合、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:
このセクションでは、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:
このセクションでは、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の早期ダイアログの暫定応答コードの終了のサポートを示すためのものです。リクエストのサポートされているヘッダーに存在する場合、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.
ポール・キジバット、デール・ウォーリー、ギラッド・シャハム、フランソワ・オーデット、アッティラ・シポス、ロバート・スパークス、ブレット・テイト、イアン・エルツ、ハドリエル・カプラン、ティモシー・ドワイト、ディーン・ウィリス、セルハド・ドークン、ジョン・エルウェル、ゴンザロ・カマリロ、アダム・ローチ、ボブ・ペンフィールドトム・テイラー、ヤ・チン・タン、キース・ドレイジ、ハンス・エリック・ヴァン・エルブルグ、カレン・ジェニングスのフィードバックと提案。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定応答の信頼性」、RFC 3262、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[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.、Oran、D。、およびG. Camarillo、「セッション開始プロトコルの理由ヘッダーフィールド（SIP）」、RFC 3326、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] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC3841] Rosenberg、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] Sparks、R。、「セッション開始プロトコルでの複数のダイアログ使用」、RFC 5057、2007年11月。
Author's Address
著者の連絡先
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: christer.holmberg@ericsson.com