[要約] RFC 3262は、SIPにおける仮の応答の信頼性に関する規格であり、仮の応答の確認と再送信の方法を定義しています。このRFCの目的は、SIPセッションの信頼性を向上させ、通信の品質と安定性を確保することです。
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)
セッション開始プロトコル（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.
Copyright（c）The Internet Society（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].
信頼性メカニズムは、招待への2XX最終応答の現在の信頼性メカニズムを反映することにより機能します。これらのリクエストは、UACによる2XXの受信を示す別のトランザクションACKを受信するまで、トランザクションユーザー（TU）によって定期的に送信されます。InviteおよびACKメッセージに対する2XX応答の信頼性は、エンドツーエンドです。暫定的な対応の信頼性を達成するために、私たちはほぼ同じことをします。信頼できる暫定的な回答は、指数関数的なバックオフでTUによって再送信されます。これらの再送信は、プラックメッセージが受信されると停止します。PrackリクエストはACKと同じ役割を果たしますが、暫定的な応答の場合。ただし、重要な違いがあります。プラックは、さようならのような通常のSIPメッセージです。そのため、独自の信頼性は、各ステートフルプロキシを通じてホップごとに保証されます。また、さようならと同様ですが、ACKとは異なり、Prackには独自の反応があります。そうでない場合、PrackメッセージはRFC 2543に準拠したプロキシサーバーを通過できませんでした[4]。
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.
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"RFC 2119 [2]で説明されているように解釈され、準拠したSIP実装の要件レベルを示します。
3 UAS Behavior
3 UASの動作
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のサポートされたヘッダーフィールドが含まれている限り、確実に招待するために100以外の暫定的な応答を送信する場合があります。この仕様では、招待以外の信頼できる暫定的な応答は許可されていませんが、ダイアログを確立できる新しい方法を定義する拡張機能は、メカニズムを利用する可能性があります。
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を備えた要求ヘッダーフィールドが含まれている場合、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（試行）応答を確実に送信しようとしてはなりません。101から199の番号が付けられた暫定的な回答のみを確実に送信できます。リクエストにサポートされているか、この機能を示すヘッダーフィールドを要求しなかった場合、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として機能します。ただし、フィールドにタグを含むリクエストについては、そうしようとしてはなりません。つまり、プロキシは、ダイアログのコンテキスト内で送信されたリクエストに対して信頼できる暫定的な応答を生成することはできません。もちろん、UASとは異なり、プロキシ要素が未解決の信頼できる暫定的な応答と一致しないプラックを受け取る場合、プラックをプロキシにする必要があります。
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が信頼できる暫定的な対応を送りたいと思うかもしれない理由はいくつかあります。理由の1つは、招待状のトランザクションが最終的な応答を生成するのに少し時間がかかる場合です。RFC 3261のセクション13.3.1.1で説明したように、UASは、プロキシでのトランザクションの「拡張」を要求するために、定期的な暫定的な回答を送信する必要があります。要件は、プロキシが3分ごとにそれらを受け取ることですが、UASはパケットの損失の可能性があるため、より頻繁に（1分に1回推奨される）必要があります。より効率的な代替品として、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が必要であること、および確実に送信される暫定的な応答があると想定しています。
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の手順に従ってUASコアによって構築されます。さらに、オプションタグ100RELを含む必要なヘッダーフィールドを含む必要があり、RSEQヘッダーフィールドを含める必要があります。トランザクションにおける最初の信頼できる暫定的な対応に対するヘッダーフィールドの値は、1〜2 ** 31-1でなければなりません。この範囲で均一に選択することをお勧めします。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秒から始まり、各再送信の2倍の間隔で定期的にトランザクション層に渡されます（T1はRFC 3261のセクション17で定義されています）。サーバートランザクションに渡されると、承認されていない信頼できる暫定的な応答の内部リストに追加されます。トランザクションレイヤーは、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.
これは、2xx応答の再送信とは異なり、その間隔はT2秒でキャップされます。これは、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.
信頼できる暫定的な対応の再送信は、UAコアによって一致するプラックが受信された場合に停止します。Prackはダイアログ内の他の要求と同じであり、UASコアはRFC 3261のセクション8.2および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.
UAコアがプラックリクエストを受け取っていない場合、承認されていない信頼できる暫定的な応答と一致しない場合、UAは481応答でプラックに応答する必要があります。プラックが承認されていない信頼できる暫定的な対応と一致する場合、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.
対応するプラックを受信せずに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.
プラックにセッションの説明が含まれている場合、このドキュメントのセクション5で説明されているように処理されます。代わりにプラックに他のタイプの体が含まれていた場合、身体は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は、最初のものが認められるまで、2番目の信頼できる暫定的な対応を送信してはなりません。最初の後、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の値は、正確に1つ以上大きくなければなりません。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.
UASは、最終的な応答が2xxであり、承認されていない信頼できる暫定的な回答にセッションの説明が含まれていない限り、すべての未承認の信頼できる暫定的な応答のプラックを受け取る前に、最初の要求に最終的な応答を送信する場合があります。その場合、これらの暫定的な回答が認められるまで、最終的な応答を送信してはなりません。信頼性の高い応答がまだ承認されていない場合、UASが最終的な応答を送信する場合、承認されていない信頼できる暫定的な応答を再送信し続けるべきではありませんが、それらの未解決の応答のリクエストを処理する準備をする必要があります。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を使用して要求ヘッダーフィールドをリクエストに挿入します。SIPの拡張は他の要求方法での使用を可能にする場合がありますが、値100RELを持つ必要のある100RELの要求は、招待状を除くいずれでも存在してはなりません。
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は、すべての招待リクエストにこれを含める必要があります。
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を含む要求ヘッダーフィールドが含まれている場合、応答は確実に送信されます。応答が100（試行）の場合（101〜199ではなく）、このオプションタグを無視する必要があり、以下の手順を使用してはなりません。
The provisional response MUST establish a dialog if one is not yet created.
暫定的な応答は、まだ作成されていない場合はダイアログを確立する必要があります。
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はメソッドプラックを使用して新しいリクエストを作成する必要があります。このリクエストは、暫定的な応答に関連付けられたダイアログ内で送信されます（実際、暫定的な応答がダイアログを作成した可能性があります）。プラックリクエストには、その種類と気質に従って解釈されるボディが含まれている場合があります。
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.
プラックは、ダイアログ内の他の非インバイト要求と同じであることに注意してください。特に、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値がシーケンス番号の値よりも高い場合、その応答はプラックで認められてはならず、さらに処理してはなりません。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オファー/回答モデルとプラック
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に送られた最初の信頼できるメッセージであり、招待には申し出が含まれていない場合、その信頼できる暫定的な対応に表示されなければなりません。
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がオファーで信頼できる暫定的な応答を受け取った場合（これは、UACがオファーなしで招待を送信した場合に発生します。その場合、最初の信頼できる暫定的な対応には申し出が含まれます）。UACが回答を使用して信頼できる暫定的な応答を受け取った場合、プラックに追加のオファーが生成される場合があります。UASがオファーでプラックを受け取った場合、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は、元の招待自体が応答されていなくても、オファーと回答のパラメーターに基づいてセッションを確立する必要があります。
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が招待を受け入れたときに承認されていない信頼できる暫定的な対応にセッションの説明を配置した場合、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.
この拡張機能をサポートするすべてのユーザーエージェントは、RFC 3261のセクション13.2のルールに基づいて可能なすべてのオファー/回答交換をサポートする必要があります。。
6 Definition of the PRACK Method
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.
この仕様は、新しいSIPメソッドであるPrackを定義します。この方法のセマンティクスは上記で説明されています。表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ヘッダーは、それらを確実に送信するために暫定的な応答で使用されます。1から2 ** 32-1の単一の数値が含まれています。その使用の詳細については、セクション3を参照してください。
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.
ラックヘッダーは、暫定的な応答の信頼性をサポートするためにプラックリクエストで送信されます。2つの数字とメソッドタグが含まれています。最初の数字は、認められている暫定的な応答のRSEQヘッダーからの値です。次の番号、およびメソッドは、認められている応答のCSEQからコピーされます。ラックヘッダーのメソッド名はケースに敏感です。
Example:
例：
RAck: 776656 1 INVITE
ラック：776656 1招待
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登録プロセスに基づいて、新しいオプションタグと2つの新しいヘッダーを登録します。
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メッセージは他の要求と同じように認証される必要があります。認証手順は、RFC 3261で指定されています。
10 Collected BNF
10収集されたBNF
The BNF for the RAck and RSeq headers and the PRACK method are defined here.
ラックおよびRSEQヘッダーのBNFと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
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.
著者は、この文書に関するコメントについて、Jo Hornsby、Jonathan Lennox、Rohan Mahy、Allison Mankin、Adam Roach、Tim Schroederに感謝したいと思います。
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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with SDP", RFC 3264, June 2002.
[3] Rosenberg、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] Handley、M.、Schulzrinne、H.、Schooler、E。and J. Rosenberg、「SIP：SESSION INTIATION Protocol」、RFC 2543、1999年3月。
14 Authors' Addresses
14の著者のアドレス
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
ジョナサンローゼンバーグダイナミクスソフト72イーグルロックアベニュー1階イーストハノーバー、ニュージャージー07936
EMail: jdrosen@dynamicsoft.com
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003
ヘニングシュルツリンヌコロンビア大学M/S 0401 1214 AMSTERDAM AVE. NEW YORK、NY 10027-7003
EMail: schulzrinne@cs.columbia.edu
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。