Network Working Group J. Rosenberg
Request for Comments: 3262 dynamicsoft
Category: Standards Track H. Schulzrinne
Columbia U.
June 2002
Reliability of Provisional Responses
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 (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. This extension uses the option tag 100rel and defines the Provisional Response ACKnowledgement (PRACK) method.
この文書では、信頼性のある暫定応答メッセージを提供するセッション開始プロトコル（SIP）に拡張子を指定します。この拡張は、オプションタグ100relを使用し、暫定応答確認（PRACK）メソッドを定義します。
Table of Contents
目次
1 Introduction ........................................ 2
2 Terminology ......................................... 3
3 UAS Behavior ........................................ 3
4 UAC Behavior ........................................ 6
5 The Offer/Answer Model and PRACK .................... 9
6 Definition of the PRACK Method ...................... 10
7 Header Field Definitions ............................ 10
7.1 RSeq ................................................ 10
7.2 RAck ................................................ 11
8 IANA Considerations ................................. 11
8.1 IANA Registration of the 100rel Option Tag .......... 11
8.2 IANA Registration of RSeq and RAck Headers .......... 12
9 Security Considerations ............................. 12
10 Collected BNF ....................................... 12
11 Acknowledgements .................................... 12
12 Normative References ................................ 13
13 Informative References .............................. 13
14 Authors' Addresses .................................. 13
15. Full Copyright Statement............................. 14
1 Introduction
1はじめに
The Session Initiation Protocol (SIP) (RFC 3261 [1]) is a request-response protocol for initiating and managing communications sessions. SIP defines two types of responses, provisional and final. Final responses convey the result of the request processing, and are sent reliably. Provisional responses provide information on the progress of the request processing, but are not sent reliably in RFC 3261.
セッション開始プロトコル（SIP）（RFC 3261 [1]）を開始し、通信セッションを管理するための要求 - 応答プロトコルです。 SIP暫定、最終応答の2種類を規定します。最終的な応答が要求処理の結果を伝え、かつ確実に送信されます。暫定応答は要求処理の進捗状況についての情報を提供しますが、RFC 3261に確実に送信されません。
It was later observed that reliability was important in several cases, including interoperability scenarios with the PSTN. Therefore, an optional capability was needed to support reliable transmission of provisional responses. That capability is provided in this specification.
それは、後に信頼性がPSTNとの相互運用性のシナリオを含め、いくつかのケースでは重要であることが観察されました。そのため、オプションの機能は暫定応答の信頼性の高い伝送をサポートするために必要とされました。その機能は、本明細書で提供されます。
The reliability mechanism works by mirroring the current reliability mechanisms for 2xx final responses to INVITE. Those requests are transmitted periodically by the Transaction User (TU) until a separate transaction, ACK, is received that indicates reception of the 2xx by the UAC. The reliability for the 2xx responses to INVITE and ACK messages are end-to-end. In order to achieve reliability for provisional responses, we do nearly the same thing. Reliable provisional responses are retransmitted by the TU with an exponential backoff. Those retransmissions cease when a PRACK message is received. The PRACK request plays the same role as ACK, but for provisional responses. There is an important difference, however. PRACK is a normal SIP message, like BYE. As such, its own reliability is ensured hop-by-hop through each stateful proxy. Also like BYE, but unlike ACK, PRACK has its own response. If this were not the case, the PRACK message could not traverse proxy servers compliant to RFC 2543 [4].
信頼メカニズムは、INVITEする2xxの最終的な応答のための現在の信頼性メカニズムをミラーリングすることによって機能します。これらの要求を別個のトランザクションまでトランザクションユーザー（TU）によって定期的に送信され、ACKは、UACによって2XXの受信を示していると受け取られます。 2xx応答のための信頼性が招待すると、ACKメッセージは、エンドツーエンドです。暫定応答のための信頼性を達成するために、我々は、ほぼ同じことを行います。信頼性のある暫定応答は指数バックオフでTUが再送されています。 PRACKメッセージを受信したときに、これらの再送は停止します。 PRACKリクエストはACKと同じ役割を果たしているが、暫定応答のために。重要な違いは、しかし、があります。 PRACKはBYEような通常のSIPメッセージです。このように、それ自身の信頼性は、各ステートフルプロキシを介してホップバイホップを確保しています。またBYE等が挙げられるが、ACKとは異なり、PRACKは独自の応答を有します。これがそうでないならば、PRACKメッセージは、[4] RFC 2543に準拠するプロキシサーバを通過することができませんでした。
Each provisional response is given a sequence number, carried in the RSeq header field in the response. The PRACK messages contain an RAck header field, which indicates the sequence number of the provisional response that is being acknowledged. The acknowledgments are not cumulative, and the specifications recommend a single outstanding provisional response at a time, for purposes of congestion control.
各暫定的な応答は、応答にRSEQヘッダフィールド内で運ばシーケンス番号を、与えられています。 PRACKメッセージは確認応答されている暫定応答のシーケンス番号を示しているラックヘッダフィールドを含みます。確認応答が累積されません、および仕様は、輻輳制御の目的のために、一度に一つの優れた暫定的な応答をお勧めします。
2 Terminology
2用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and indicate requirement levels for compliant SIP implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" RFC 2119に記載されるように解釈されるべきである[2]及び対応SIP実装の要求レベルを示します。
3 UAS Behavior
3 WHO行動
A UAS MAY send any non-100 provisional response to INVITE reliably, so long as the initial INVITE request (the request whose provisional response is being sent reliably) contained a Supported header field with the option tag 100rel. While this specification does not allow reliable provisional responses for any method but INVITE, extensions that define new methods that can establish dialogs may make use of the mechanism.
UASは限り初期要求オプションタグ100relとSupportedヘッダーフィールドを含んでいた（その暫定的な応答を確実に送信されている要求）をINVITEのように、確実にINVITEする任意の非100暫定応答を送信することができます。この仕様は、任意の方法のための信頼性のある暫定応答を可能にするが、INVITEはありませんが、ダイアログを確立することができる新しい方法を定義する拡張機構を利用することができます。
The UAS MUST send any non-100 provisional response reliably if the initial request contained a Require header field with the option tag 100rel. If the UAS is unwilling to do so, it MUST reject the initial request with a 420 (Bad Extension) and include an Unsupported header field containing the option tag 100rel.
UASは、最初の要求は、オプションタグ100relとRequireヘッダーフィールドが含まれている場合、確実任意の非100暫定応答を送信しなければなりません。 UASは、そうすること不本意である場合、それは420（悪い拡張）との最初の要求を拒否し、オプションタグ100relを含むサポートされていないヘッダフィールドを含まなければなりません。
A UAS MUST NOT attempt to send a 100 (Trying) response reliably. Only provisional responses numbered 101 to 199 may be sent reliably. If the request did not include either a Supported or Require header field indicating this feature, the UAS MUST NOT send the provisional response reliably.
UASは確実に100（しよう）応答を送信することを試みてはいけません。唯一の暫定応答は、199から101が確実に送信することができるの番号。要求は、この特徴を示すサポートされているか、Requireヘッダーフィールドのいずれかが含まれていない場合、UASは確実に暫定的な応答を送ってはいけません。
100 (Trying) responses are hop-by-hop only. For this reason, the reliability mechanisms described here, which are end-to-end, cannot be used.
100（試行）応答は、ホップバイホップのみです。このため、エンド・ツー・エンドであり、ここで説明した信頼性のメカニズムは、使用することができません。
An element that can act as a proxy can also send reliable provisional responses. In this case, it acts as a UAS for purposes of that transaction. However, it MUST NOT attempt to do so for any request that contains a tag in the To field. That is, a proxy cannot generate reliable provisional responses to requests sent within the context of a dialog. Of course, unlike a UAS, when the proxy element receives a PRACK that does not match any outstanding reliable provisional response, the PRACK MUST be proxied.
プロキシとして動作することができる要素は、信頼性のある暫定応答を送信することができます。この場合、そのトランザクションの目的のためにUASとして動作します。しかし、それは、Toフィールドにタグを含むすべての要求のためにそうすることを試みてはいけません。つまり、プロキシは、ダイアログのコンテキスト内で送信された要求への信頼性のある暫定応答を生成することはできません。もちろん、プロキシ要素は未処理の信頼性のある暫定応答と一致しないPRACKを受け取るUASとは異なり、PRACKはプロキシされなければなりません。
There are several reasons why a UAS might want to send a reliable provisional response. One reason is if the INVITE transaction will take some time to generate a final response. As discussed in Section 13.3.1.1 of RFC 3261, the UAS will need to send periodic provisional responses to request an "extension" of the transaction at proxies. The requirement is that a proxy receive them every three minutes, but the UAS needs to send them more frequently (once a minute is recommended) because of the possibility of packet loss. As a more efficient alternative, the UAS can send the response reliably, in which case the UAS SHOULD send provisional responses once every two and a half minutes. Use of reliable provisional responses for extending transactions is RECOMMENDED.
UASは信頼性のある暫定応答を送信する場合がありますいくつかの理由があります。 INVITEトランザクションが最終的な応答を生成するのには時間がかかります場合は、1つの理由はあります。 RFC 3261のセクション13.3.1.1で述べたように、UASはプロキシでの取引の「拡張子」を要求するために定期的に暫定応答を送信する必要があります。要件は、プロキシがそれらを3分ごとに受け取ることですが、UASは（分が推奨されると）ので、パケット損失の可能性をより頻繁にそれらを送信する必要があります。より効率的な代替手段として、UASは、確実にレスポンスを送信することができ、その場合、UASは、暫定応答回2分半を送るべきです。トランザクションを拡張するための信頼性のある暫定応答の使用を推奨します。
The rest of this discussion assumes that the initial request contained a Supported or Require header field listing 100rel, and that there is a provisional response to be sent reliably.
この説明の残りの部分は、最初のリクエストが100relをリスト担持またはRequireヘッダーフィールドが含まれていることを前提とし、かつ確実に送信される暫定応答があること。
The provisional response to be sent reliably is constructed by the UAS core according to the procedures of Section 8.2.6 of RFC 3261. In addition, it MUST contain a Require header field containing the option tag 100rel, and MUST include an RSeq header field. The value of the header field for the first reliable provisional response in a transaction MUST be between 1 and 2**31 - 1. It is RECOMMENDED that it be chosen uniformly in this range. The RSeq numbering space is within a single transaction. This means that provisional responses for different requests MAY use the same values for the RSeq number.
確実に送信される暫定的な応答はまたRFC 3261のセクション8.2.6の手順に従って、それがオプションタグ100relを含むRequireヘッダーフィールドを含まなければならない、とRSEQヘッダーフィールドを含まなければならないUASコアで構成されています。それがこの範囲内に一様に選択することを推奨された1 - トランザクションの最初の信頼できる暫定的な応答のためのヘッダーフィールドの値は1と2 ** 31の間でなければなりません。 RSEQ番号スペースは、単一のトランザクション内です。これは、異なる要求のための暫定応答がRSEQ番号に同じ値を使用してもよいことを意味します。
The reliable provisional response MAY contain a body. The usage of session descriptions is described in Section 5.
信頼性のある暫定応答は、本体を含むかもしれません。セッション記述の用法はセクション5に記載されています。
The reliable provisional response is passed to the transaction layer periodically with an interval that starts at T1 seconds and doubles for each retransmission (T1 is defined in Section 17 of RFC 3261). Once passed to the server transaction, it is added to an internal list of unacknowledged reliable provisional responses. The transaction layer will forward each retransmission passed from the UAS core.
信頼できる暫定的な応答は、（T1は、RFC 3261のセクション17で定義されている）T1秒で開始し、各再送信のため倍の間隔で周期的にトランザクション層に渡されます。サーバートランザクションに渡されると、それは未確認の信頼性のある暫定応答の内部リストに追加されます。トランザクション層は、UASコアから渡された各再送を転送します。
This differs from retransmissions of 2xx responses, whose intervals cap at T2 seconds. This is because retransmissions of ACK are triggered on receipt of a 2xx, but retransmissions of PRACK take place independently of reception of 1xx.
これは、間隔T2秒でキャップの2xx応答の再送信とは異なります。 ACKの再送が2XXの受信時にトリガされるので、これはですが、PRACKの再送信は、独立の1xxの受信の場所を取ります。
Retransmissions of the reliable provisional response cease when a matching PRACK is received by the UA core. PRACK is like any other request within a dialog, and the UAS core processes it according to the procedures of Sections 8.2 and 12.2.2 of RFC 3261. A matching PRACK is defined as one within the same dialog as the response, and whose method, CSeq-num, and response-num in the RAck header field match, respectively, the method from the CSeq, the sequence number from the CSeq, and the sequence number from the RSeq of the reliable provisional response.
マッチングPRACKはUAコアによって受信されたときに信頼できる暫定応答の再送は中止します。 、PRACKはダイアログ内の他の要求と同様であり、UASコアは、マッチングPRACKが応答と同じダイアログ内の一つとして定義され、セクション8.2およびRFC 3261の12.2.2の手順に従ってそれを処理し、その方法ラックヘッダフィールドの試合でのCSeq-NUM、および応答NUM、それぞれのCSeq、のCSeqからシーケンス番号、および信頼性のある暫定応答のRSEQからシーケンス番号から方法。
If a PRACK request is received by the UA core that does not match any unacknowledged reliable provisional response, the UAS MUST respond to the PRACK with a 481 response. If the PRACK does match an unacknowledged reliable provisional response, it MUST be responded to with a 2xx response. The UAS can be certain at this point that the provisional response has been received in order. It SHOULD cease retransmissions of the reliable provisional response, and MUST remove it from the list of unacknowledged provisional responses.
PRACK要求が未確認信頼性のある暫定応答と一致していないUAコアで受信された場合、UASは481応答でPRACKに反応しなければなりません。 PRACKは未確認の信頼性のある暫定応答と一致しない場合、それは2xx応答で応答しなければなりません。 UASは、暫定的な応答は、順番に受信されたこの時点で特定することができます。それは信頼性のある暫定応答の再送を中止すべきである、との未確認暫定応答のリストから削除する必要があります。
If a reliable provisional response is retransmitted for 64*T1 seconds without reception of a corresponding PRACK, the UAS SHOULD reject the original request with a 5xx response.
信頼できる暫定的な応答は、対応するPRACKを受信することなく、64 * T1秒間再送信される場合、UASは5xxの応答で元の要求を拒否すべきです。
If the PRACK contained a session description, it is processed as described in Section 5 of this document. If the PRACK instead contained any other type of body, the body is treated in the same way that body in an ACK would be treated.
PRACKはセッション記述が含まれていた場合、この文書のセクション5に記載されているように、それが処理されます。 PRACKはなく、身体の他のタイプが含まれている場合、本体は、ACKにおける体が治療されるのと同じ方法で処理されます。
After the first reliable provisional response for a request has been acknowledged, the UAS MAY send additional reliable provisional responses. The UAS MUST NOT send a second reliable provisional response until the first is acknowledged. After the first, it is RECOMMENDED that the UAS not send an additional reliable provisional response until the previous is acknowledged. The first reliable provisional response receives special treatment because it conveys the initial sequence number. If additional reliable provisional responses were sent before the first was acknowledged, the UAS could not be certain these were received in order.
要求のための最初の信頼性のある暫定応答が認められた後、UASは、追加の信頼性のある暫定応答を送信することができます。最初が確認されるまでUASは、第二の信頼性のある暫定応答を送ってはいけません。最初の後、以前のが確認されるまで、UASは、追加の信頼性のある暫定応答を送信しないことをお勧めします。それは初期シーケンス番号を伝えるため、最初の信頼性のある暫定応答は特別な扱いを受けます。最初が確認される前に、追加の信頼性のある暫定応答が送られた場合、UASは、これらの順序で受信された特定することができませんでした。
The value of the RSeq in each subsequent reliable provisional response for the same request MUST be greater by exactly one. RSeq numbers MUST NOT wrap around. Because the initial one is chosen to be less than 2**31 - 1, but the maximum is 2**32 - 1, there can be up to 2**31 reliable provisional responses per request, which is more than sufficient.
同じ要求のための後続の各信頼できる暫定的な応答でRSEQの値は、正確に一つ大きくなければなりません。 RSEQ番号がラップアラウンドしてはなりません。最初の一つは2 ** 31よりも小さくなるように選択されるので - 1が、最大2 ** 32である - 1、十分以上であり、** 2まで要求当たり31個の信頼できる暫定的な応答が存在することができます。
The UAS MAY send a final response to the initial request before having received PRACKs for all unacknowledged reliable provisional responses, unless the final response is 2xx and any of the unacknowledged reliable provisional responses contained a session description. In that case, it MUST NOT send a final response until those provisional responses are acknowledged. If the UAS does send a final response when reliable responses are still unacknowledged, it SHOULD NOT continue to retransmit the unacknowledged reliable provisional responses, but it MUST be prepared to process PRACK requests for those outstanding responses. A UAS MUST NOT send new reliable provisional responses (as opposed to retransmissions of unacknowledged ones) after sending a final response to a request.
最終応答が2XXであり、未確認信頼できる暫定的な応答のいずれかが、セッション記述が含まれていない限り、UASは、全ての未確認信頼できる暫定的な応答のために受信PRACKsを有する前に、最初の要求に対する最終応答を送信することができます。これらの暫定応答が確認されるまで、その場合には、最終的な応答を送ってはいけません。 UASが信頼できる応答がまだ未確認のあるときに最終的な応答を送信した場合、それは未確認の信頼性のある暫定応答を再送し続けるべきではありませんが、これらの優れた応答に対するPRACK要求を処理するために準備しなければなりません。 UASは、リクエストに対する最終応答を送信した後（未確認のものの再送信ではなく）新しい信頼性の高い暫定応答を送ってはいけません。
4 UAC Behavior
4 UACの動作
When the UAC creates a new request, it can insist on reliable delivery of provisional responses for that request. To do that, it inserts a Require header field with the option tag 100rel into the request. A Require header with the value 100rel MUST NOT be present in any requests excepting INVITE, although extensions to SIP may allow its usage with other request methods.
UACは、新しい要求を作成すると、その要求のための暫定応答の信頼できる配信を主張することができます。これを行うには、その要求にオプションタグ100relを持つRequireヘッダーフィールドを挿入します。 SIPへの拡張は、他の要求方法とその使用を可能にすることができるものの、値100relとヘッダを必要とINVITE以外のリクエスト中に存在してはなりません。
Header field where PRACK
___________________________________
Accept R o
Accept 2xx -
Accept 415 c
Accept-Encoding R o
Accept-Encoding 2xx -
Accept-Encoding 415 c
Accept-Language R o
Accept-Language 2xx -
Accept-Language 415 c
Alert-Info R -
Alert-Info 180 -
Allow R o
Allow 2xx o
Allow r o
Allow 405 m
Authentication-Info 2xx o
Authorization R o
Call-ID c m
Call-Info -
Contact R -
Contact 1xx -
Contact 2xx -
Contact 3xx o
Contact 485 o
Content-Disposition o
Content-Encoding o
Content-Language o
Content-Length t
Content-Type *
CSeq c m
Date o
Error-Info 300-699 o
Expires -
From c m
In-Reply-To R -
Max-Forwards R m
Min-Expires 423 -
MIME-Version o
Organization -
Table 1: Summary of header fields, A--O
表1：ヘッダーフィールドの概要、A - O
Header field where PRACK
__________________________________________
Priority R -
Proxy-Authenticate 407 m
Proxy-Authenticate 401 o
Proxy-Authorization R o
Proxy-Require R o
Record-Route R o
Record-Route 2xx,18x o
Reply-To -
Require c
Retry-After 404,413,480,486 o
500,503 o
600,603 o
Route R c
Server r o
Subject R -
Supported R o
Supported 2xx o
Timestamp o
To c m
Unsupported 420 m
User-Agent o
Via c m
Warning r o
WWW-Authenticate 401 m
Table 2: Summary of header fields, P--Z
表2：ヘッダフィールドの概要、P - Z
If the UAC does not wish to insist on usage of reliable provisional responses, but merely indicate that it supports them if the UAS needs to send one, a Supported header MUST be included in the request with the option tag 100rel. The UAC SHOULD include this in all INVITE requests.
UACは、信頼できる暫定応答の使用を主張したいが、単にUASは1を送信する必要がある場合には、それらをサポートしていることを示していない場合は、サポートされているヘッダは、オプションタグ100relとの要求に含まれなければなりません。 UACはすべてのINVITEリクエストでこれを含むべきです。
If a provisional response is received for an initial request, and that response contains a Require header field containing the option tag 100rel, the response is to be sent reliably. If the response is a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be ignored, and the procedures below MUST NOT be used.
暫定的な応答は、初期要求を受信し、その応答がオプションタグ100relを含むRequireヘッダーフィールドが含まれている場合、応答が確実に送信されます。応答が100である場合（試行）（199から101とは対照的に）、このオプションタグは無視しなければなりません、そして以下の手順を使用してはいけません。
The provisional response MUST establish a dialog if one is not yet created.
1がまだ作成されていない場合は、暫定応答はダイアログを確立する必要があります。
Assuming the response is to be transmitted reliably, the UAC MUST create a new request with method PRACK. This request is sent within the dialog associated with the provisional response (indeed, the provisional response may have created the dialog). PRACK requests MAY contain bodies, which are interpreted according to their type and disposition.
応答が確実に送信されると仮定すると、UACは、メソッドPRACKで新しいリクエストを作成する必要があります。この要求は（確かに、暫定応答がダイアログを作成している場合があります）暫定応答に関連付けられたダイアログ内で送信されます。 PRACK要求は、その種類や配置に応じて解釈されている体を含んでいてもよいです。
Note that the PRACK is like any other non-INVITE request within a dialog. In particular, a UAC SHOULD NOT retransmit the PRACK request when it receives a retransmission of the provisional response being acknowledged, although doing so does not create a protocol error.
PRACKはダイアログ内の任意の他の非INVITE要求のようなものであることに注意してください。それは認知されている暫定応答の再送を受信したときにそうすることは、プロトコル・エラーを作成しませんが、特に、UACは、PRACK要求を再送信すべきではありません。
Once a reliable provisional response is received, retransmissions of that response MUST be discarded. A response is a retransmission when its dialog ID, CSeq, and RSeq match the original response. The UAC MUST maintain a sequence number that indicates the most recently received in-order reliable provisional response for the initial request. This sequence number MUST be maintained until a final response is received for the initial request. Its value MUST be initialized to the RSeq header field in the first reliable provisional response received for the initial request.
信頼性のある暫定応答が受信されると、その応答の再送は捨てなければなりません。そのダイアログID、のCSeq、およびRSEQが元の応答と一致したときに応答が再送です。 UACは、最初の要求のための最も最近受け取っインオーダー信頼性のある暫定応答を示すシーケンス番号を維持しなければなりません。最終的な応答は、最初の要求のために受信されるまで、このシーケンス番号を維持しなければなりません。その値は、最初のリクエストのために受信された最初の信頼できる暫定的な応答でRSEQヘッダフィールドに初期化されなければなりません。
Handling of subsequent reliable provisional responses for the same initial request follows the same rules as above, with the following difference: reliable provisional responses are guaranteed to be in order. As a result, if the UAC receives another reliable provisional response to the same request, and its RSeq value is not one higher than the value of the sequence number, that response MUST NOT be acknowledged with a PRACK, and MUST NOT be processed further by the UAC. An implementation MAY discard the response, or MAY cache the response in the hopes of receiving the missing responses.
同じ最初の要求に対する後続の信頼できる暫定的な応答の処理は、以下の違いが、上記と同じ規則に従う：信頼できる暫定的な応答は、順番にあることが保証されます。 UACが同じ要求に対する別の信頼できる暫定的な応答を受信し、そのRSEQ値は、シーケンス番号の値よりも高いものではない場合、結果として、その応答は、PRACKと認めてはいけません、とによってさらに処理してはいけませんUAC。実装は応答を破棄したり、行方不明の応答を受け取ることを希望して応答をキャッシュしてもよいです。
The UAC MAY acknowledge reliable provisional responses received after the final response or MAY discard them.
UACは、最終的な応答の後に受信信頼性のある暫定応答を確認したり、それらを捨てるかもしれ。
5 The Offer/Answer Model and PRACK
5オファー/アンサーモデルとPRACK
RFC 3261 describes guidelines for the sets of messages in which offers and answers [3] can appear. Based on those guidelines, this extension provides additional opportunities for offer/answer exchanges.
RFC 3261 [3]は表示することができたオファーとアンサーにメッセージのセットのためのガイドラインについて説明します。これらのガイドラインに基づいて、この拡張機能は、オファー/アンサー交換のための追加の機会を提供しています。
If the INVITE contained an offer, the UAS MAY generate an answer in a reliable provisional response (assuming these are supported by the UAC). That results in the establishment of the session before completion of the call. Similarly, if a reliable provisional response is the first reliable message sent back to the UAC, and the INVITE did not contain an offer, one MUST appear in that reliable provisional response.
申し出を含ま招待した場合、UASは（これらはUACによってサポートされていると仮定すると）信頼性のある暫定応答で答えを生成してもよいです。これは、コールが完了する前にセッションの確立につながります。信頼性のある暫定応答がUACに送り返さ最初の信頼性の高いメッセージがある、とのオファーを含まなかったINVITE場合は同様に、一つはその信頼性のある暫定応答に現れなければなりません。
If the UAC receives a reliable provisional response with an offer (this would occur if the UAC sent an INVITE without an offer, in which case the first reliable provisional response will contain the offer), it MUST generate an answer in the PRACK. If the UAC receives a reliable provisional response with an answer, it MAY generate an additional offer in the PRACK. If the UAS receives a PRACK with an offer, it MUST place the answer in the 2xx to the PRACK.
UACがオファーを信頼性のある暫定応答を受信した場合、それはPRACKで答えを発生させなければなりません（UACが最初の信頼性のある暫定応答は申し出が含まれている場合に提供、なしでINVITEを送信された場合に発生します）。 UACが答えで信頼性のある暫定応答を受信した場合、それはPRACKで、追加のオファーを生成してもよいです。 UASが提供してPRACKを受信した場合、それはPRACKへの2xxで答えを置かなければなりません。
Once an answer has been sent or received, the UA SHOULD establish the session based on the parameters of the offer and answer, even if the original INVITE itself has not been responded to.
答えが送信または受信された後、UAは、オファーのパラメータに基づいてセッションを確立し、答えて、オリジナル自体をINVITE場合でもべきであるに応えられていません。
If the UAS had placed a session description in any reliable provisional response that is unacknowledged when the INVITE is accepted, the UAS MUST delay sending the 2xx until the provisional response is acknowledged. Otherwise, the reliability of the 1xx cannot be guaranteed, and reliability is needed for proper operation of the offer/answer exchange.
UASは、INVITEが受理されたときに、未確認である任意の信頼性のある暫定応答でセッション記述を置いていた場合、UASは、暫定応答が確認されるまで2xxの送信を遅らせなければなりません。それ以外の場合は、1XXの信頼性を保証することはできません、そして信頼性がオファー/アンサー交換の適切な動作のために必要とされています。
All user agents that support this extension MUST support all offer/answer exchanges that are possible based on the rules in Section 13.2 of RFC 3261, based on the existence of INVITE and PRACK as requests, and 2xx and reliable 1xx as non-failure reliable responses.
この拡張機能をサポートするすべてのユーザエージェントは、非故障信頼性の高い応答などの要求としてINVITEとPRACKの有無に基づいて、RFC 3261のセクション13.2、および2XXおよび信頼性の1xxのルールに基づいて可能なすべてのオファー/アンサー交換をサポートしなければなりません。
6 Definition of the PRACK Method
PRACKメソッドの定義6
This specification defines a new SIP method, PRACK. The semantics of this method are described above. Tables 1 and 2 extend Tables 2 and 3 from RFC 3261 for this new method.
この仕様はPRACK、新しいSIPメソッドを定義します。この方法の意味は上記に記載されています。表1および表2は、この新しい方法は、RFC 3261から表2および表3を拡張します。
7 Header Field Definitions
7つのヘッダーフィールドの定義
This specification defines two new header fields, RAck and RSeq. Table 3 extends Tables 2 and 3 from RFC 3261 for these headers.
この仕様は、2つの新しいヘッダフィールド、ラックとRSEQを定義します。表3は、これらのヘッダは、RFC 3261から表2および表3を拡張します。
The RSeq header is used in provisional responses in order to transmit them reliably. It contains a single numeric value from 1 to 2**32 - 1. For details on its usage, see Section 3.
RSEQヘッダが確実にそれらを送信するために暫定的な応答に使用されます。第3節を参照してください、その使用方法の詳細については1 - それは1 ** 32から2つの数値が含まれています。
Example:
例：
RSeq: 988789
RSEQ：988789
Header field where proxy ACK BYE CAN INV OPT REG PRA
______________________________________________________
RAck R - - - - - - m
RSeq 1xx - - - o - - -
Table 3: RAck and RSeq Header Fields
表3：ラックとRSEQヘッダフィールド
The RAck header is sent in a PRACK request to support reliability of provisional responses. It contains two numbers and a method tag. The first number is the value from the RSeq header in the provisional response that is being acknowledged. The next number, and the method, are copied from the CSeq in the response that is being acknowledged. The method name in the RAck header is case sensitive.
ラックヘッダは暫定応答の信頼性をサポートするためにPRACK要求で送信されます。これは、2つの数字とメソッドタグが含まれています。最初の番号が承認されている暫定的な応答でRSEQヘッダからの値です。次の番号、および方法は、承認されている応答のCSeqからコピーされます。ラックヘッダのメソッド名は、大文字と小文字が区別されます。
Example:
例：
RAck: 776656 1 INVITE
ラック：776656 1は、INVITE
8 IANA Considerations
8つのIANAの考慮事項
This document registers a new option tag and two new headers, based on the IANA registration process of RFC 3261.
この文書は、RFC 3261のIANA登録プロセスに基づいて、新しいオプションタグと二つの新しいヘッダを登録します。
This specification registers a single option tag, 100rel. The required information for this registration, as specified in RFC 3261, is:
この仕様は、単一のオプションタグ、100relを登録します。この登録に必要な情報、RFC 3261で指定され、次のとおりです。
Name: 100rel
名前：100rel
Description: This option tag is for reliability of provisional responses. When present in a Supported header, it indicates that the UA can send or receive reliable provisional responses. When present in a Require header in a request, it indicates that the UAS MUST send all provisional responses reliably. When present in a Require header in a reliable provisional response, it indicates that the response is to be sent reliably.
説明：このオプションタグは暫定応答の信頼性のためです。場合サポートされているヘッダ内に存在する、そのUAが信頼できる暫定応答を送信または受信することができることを示しています。存在する場合、要求に要求ヘッダには、UASが確実にすべての暫定応答を送信しなければならないことを示しています。存在する場合に信頼できる暫定的な応答に必須ヘッダでは、応答が確実に送信されることを示しています。
The following is the registration for the RSeq header:
以下は、RSEQヘッダの登録です。
RFC Number: RFC3262
RFC番号：RFC3262
Header Name: RSeq
ヘッダー名：RSEQ
Compact Form: none
コンパクトなフォーム：なし
The following is the registration for the RAck header:
以下は、ラックヘッダの登録です。
RFC Number: RFC3262
RFC番号：RFC3262
Header Name: RAck
ヘッダー名：ラック
Compact Form: none
コンパクトなフォーム：なし
9 Security Considerations
9セキュリティに関する考慮事項
The PRACK request can be injected by attackers to force retransmissions of reliable provisional responses to cease. As these responses can convey important information, PRACK messages SHOULD be authenticated as any other request. Authentication procedures are specified in RFC 3261.
PRACK要求は中止する信頼性のある暫定応答の再送を強制するために、攻撃者によって注入することができます。これらの応答は、重要な情報を伝えることができるとして、PRACKメッセージは、他の要求として認証されるべきです。認証手順は、RFC 3261で指定されています。
10 Collected BNF
10収集BNF
The BNF for the RAck and RSeq headers and the PRACK method are defined here.
ラックのBNFとRSEQヘッダとPRACK方法は、ここで定義されています。
PRACKm = %x50.52.41.43.4B ; PRACK in caps Method = INVITEm / ACKm / OPTIONSm / BYEm / CANCELm / REGISTERm / PRACKm / extension-method RAck = "RAck" HCOLON response-num LWS CSeq-num LWS Method response-num = 1*DIGIT CSeq-num = 1*DIGIT RSeq = "RSeq" HCOLON response-num
PRACKm =％x50.52.41.43.4B。 PRACKキャップのメソッド= INVITEm / ACKM / OPTIONSm / BYEm / CANCELm / REGISTERm / PRACKm /拡張方法ラック= "ラック" HCOLON応答-NUM LWSのCSeq-NUM LWS方法応答NUM = 1 * DIGIT用のCSeq-NUM = 1 * DIGITのRSEQ = "RSEQ" HCOLON応答-NUM
11 Acknowledgements
11の謝辞
The authors would like to thank Jo Hornsby, Jonathan Lennox, Rohan Mahy, Allison Mankin, Adam Roach, and Tim Schroeder for the comments on this document.
作者はこのドキュメントへのコメントのためにジョー・ホーンズビー、ジョナサン・レノックス、ロハンマーイ、アリソンマンキン、アダムローチ、とティム・シュローダーに感謝したいと思います。
12 Normative References
12の引用規格
[1] 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.
[1]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、2002年6月。
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with SDP", RFC 3264, June 2002.
[3]ローゼンバーグ、J.とH. Schulzrinneと、 "SDP申し出/答えモデル"、RFC 3264、2002年6月。
13 Informative References
13件の参考文献
[4] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[4]ハンドレー、M.、Schulzrinneと、H.、学生はE.およびJ.ローゼンバーグ、 "SIP：セッション開始プロトコル"、RFC 2543、1999年3月。
14 Authors' Addresses
14本の著者のアドレス
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
72イーグルロックアベニューまず階イーストハノーバー、NJ 07936 dynamicsoftジョナサン・ローゼンバーグ
EMail: jdrosen@dynamicsoft.com
メールアドレス：jdrosen@dynamicsoft.com
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003
ヘニングSchulzrinneとコロンビア大学のM / S 0401 1214アムステルダムアベニュー。ニューヨーク、NY 10027-7003
EMail: schulzrinne@cs.columbia.edu
メールアドレス：schulzrinne@cs.columbia.edu
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。