RFC3262 日本語訳
3262 Reliability of Provisional Responses in Session InitiationProtocol (SIP). J. Rosenberg, H. Schulzrinne. June 2002. (Format: TXT=29643 bytes) (Obsoletes RFC2543) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Rosenberg Request for Comments: 3262 dynamicsoft Category: Standards Track H. Schulzrinne Columbia U. June 2002
コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 3262dynamicsoft Category: 標準化過程H.SchulzrinneコロンビアU.2002年6月
Reliability of Provisional Responses in the Session Initiation Protocol (SIP)
セッション開始プロトコルの暫定的な応答の信頼性(一口)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
このドキュメントは、信頼できる暫定的な応答メッセージを提供しながら、Session Initiationプロトコル(SIP)に拡大を指定します。 この拡大は、オプションタグ100relを使用して、Provisional Response ACKnowledgement(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
1つの序論… 2 2用語… 3 3UASの振舞い… 3 4UACの振舞い… 申し出/答えがモデル化する6 5とPRACK… PRACK方法の9 6定義… 10 7 ヘッダーフィールド定義… 10 7.1RSeq… 10 7.2 だめになってください… 11 8 IANA問題… 11 8.1 100relオプションタグのIANA登録… 11 8.2 RSeqとラックヘッダーのIANA登録… 12 9 セキュリティ問題… 12 10の集まっているBNF… 12 11の承認… 12 12の引用規格… 13 13の有益な参照箇所… 13
Rosenberg & Schulzrinne Standards Track [Page 1] RFC 3262 Reliability of Provisional Responses in SIP June 2002
ローゼンバーグとSchulzrinne規格は2002年6月に一口における、暫定的な応答のRFC3262の信頼性を追跡します[1ページ]。
14 Authors' Addresses .................................. 13 15. Full Copyright Statement............................. 14
14人の作者のアドレス… 13 15. 完全な著作権宣言文… 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.
Session Initiationプロトコル、(SIP) (RFC3261[1])は、コミュニケーションセッションを開始して、管理するための要求応答プロトコルです。 SIPは2つのタイプの暫定的で最終的な応答を定義します。 最終的な応答を要求処理の結果を伝えて、確かに送ります。 暫定的な応答は、要求処理の進歩で情報を提供しますが、RFC3261で確かに送られません。
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の最終的な応答のために現在の信頼性のメカニズムを反映することによって、動作します。 それらの要求は別々の取引(ACK)が受け取られているまでTransaction User(TU)によって定期的に伝えられて、それがUACで2xxのレセプションを示すということです。 2xx応答のためのINVITEへの信頼性とACKメッセージは終わらせる終わりです。 暫定的な応答のために信頼性を獲得するために、私たちはほとんど同じことをします。 信頼できる暫定的な応答は指数のbackoffでTUによって再送されます。 PRACKメッセージが受信されているとき、それらの「再-トランスミッション」はやみます。 ACKと同じ役割を果たしますが、PRACK要求は暫定的な応答のためにそうします。 しかしながら、重要な違いがあります。PRACKはBYEのように正常なSIPメッセージです。 そういうものとして、それ自身の信頼性はホップごとにそれぞれのstatefulプロキシを通して確実にされます。 BYEにもかかわらずも、ACKと異なって、PRACKには、それ自身の応答があります。 これがそうでないなら、PRACKメッセージはRFC2543[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メッセージはRAckヘッダーフィールドを含んでいます。(それは、承諾されている暫定的な応答の一連番号を示します)。 承認は累積していません、そして、仕様は一度にただ一つの傑出している暫定的な応答を推薦します、輻輳制御の目的のために。
Rosenberg & Schulzrinne Standards Track [Page 2] RFC 3262 Reliability of Provisional Responses in SIP June 2002
ローゼンバーグとSchulzrinne規格は2002年6月に一口における、暫定的な応答のRFC3262の信頼性を追跡します[2ページ]。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFCで2119[2]について説明して、対応する一口実現のために要件レベルを示すとき解釈されることであるべきですか?
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 MAYはどんな非100の暫定的な応答もINVITEに確かに送ります、初期のINVITEが、(暫定的な応答が確かに送られる要求)がオプションタグ100relがあるSupportedヘッダーフィールドを含んだよう要求する限り。 この仕様はどんな方法にもかかわらず、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.
初期の要求がオプションタグ100relがあるRequireヘッダーフィールドを含んだなら、UAS MUSTはどんな非100の暫定的な応答も確かに送ります。 UASがそうしたがっていないなら、それは、420(悪いExtension)で初期の要求を拒絶して、オプションタグ100relを含むUnsupportedヘッダーフィールドを含まなければなりません。
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.
100の(試みること)の応答を確かに送るUAS MUST NOT試み。 101〜199に付番された暫定的な応答だけを確かに送るかもしれません。 要求がこの特徴を示すSupportedかRequireヘッダーフィールドのどちらかを含んでいなかったなら、UAS MUST NOTは暫定的な応答を確かに送ります。
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 MUST。proxiedされます。
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
UASが信頼できる暫定的な応答を送りたがっているかもしれないいくつかの理由があります。 1つの理由はINVITE取引が最終的な応答を発生させるにはいくらかの時間がかかるかどうかということです。 セクション13.3.1で.1RFC3261について議論するので、UASは、プロキシで取引の「拡大」を要求するために周期的な暫定的な応答を送る必要があるでしょう。 要件はしかし、プロキシが3分毎にそれらを受けるということです。
Rosenberg & Schulzrinne Standards Track [Page 3] RFC 3262 Reliability of Provisional Responses in SIP June 2002
ローゼンバーグとSchulzrinne規格は2002年6月に一口における、暫定的な応答のRFC3262の信頼性を追跡します[3ページ]。
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分はお勧めである)に彼らを送る必要があります。 より効率的な代替手段として、UASは応答を確かに送ることができます、その場合、UAS SHOULDがあらゆる2半分に一度暫定的な応答を送ります。 信頼できる暫定的な応答の取引を広げる使用はRECOMMENDEDです。
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を記載するSupportedか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.
.6セクション8.2RFC3261の手順によると、送られる暫定的な応答はUASコアによって確かに構成されます。 さらに、それは、オプションタグ100relを含むRequireヘッダーフィールドを含まなければならなくて、RSeqヘッダーフィールドを含まなければなりません。 1と2**31--1の間には、取引における最初の信頼できる暫定的な応答のためのヘッダーフィールドの値があるに違いありません。 それがこの範囲で一様に選ばれているのは、RECOMMENDEDです。 単一取引の中に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秒に始まって、各「再-トランスミッション」の代わりをする間隔で取引層に通過されます(T1はRFC3261のセクション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を受け取るとき、信頼できる暫定的な応答のRetransmissionsはやみます。 PRACKは対話の中のいかなる他の要求にも似ています、そして、.2セクション8.2と12.2RFC3261の手順によると、UASコアはそれを処理します。 合っているPRACKは応答と同じ対話の中で1つと定義されて、RAckヘッダーフィールドにおけるだれの方法、CSeq-num、および応答numがCSeq、CSeqからの一連番号、および信頼できる暫定的な応答のRSeqからの一連番号からそれぞれ方法に合っているかをそうされます。
Rosenberg & Schulzrinne Standards Track [Page 4] RFC 3262 Reliability of Provisional Responses in SIP June 2002
ローゼンバーグとSchulzrinne規格は2002年6月に一口における、暫定的な応答のRFC3262の信頼性を追跡します[4ページ]。
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コアでPRACK要求を受け取るなら、UAS MUSTは481応答でPRACKに応じます。 PRACKが不承認の信頼できる暫定的な応答に合っているなら、2xx応答でそれに応じなければなりません。 UASはここに暫定的な応答がオーダーで受けられたのを確信している場合があります。 それ、SHOULDは信頼できる臨時郵便切手応答の「再-トランスミッション」をやめて、不承認の暫定的な応答のリストからそれを取り除かなければなりません。
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秒の間、対応するPRACKのレセプションなしで再送されるなら、UAS SHOULDは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 MAYは追加信頼できる暫定的な応答を送ります。 1番目が承認されるまで、UAS MUST NOTは2番目の信頼できる暫定的な応答を送ります。 1日以降、UASが前まで追加信頼できる暫定的な応答を送らないRECOMMENDEDが承認されるということです。 初期シーケンス番号を伝えるので、最初の信頼できる暫定的な応答は特別な処理を受けます。 1番目を承認する前に追加信頼できる暫定的な応答を送るなら、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であるので、1要求あたり31の信頼できる暫定的な応答が2**次第であることができます。(要求は十二分に十分です)。
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.
すべての不承認の信頼できる暫定的な応答のためにPRACKsを受ける前にUAS MAYは最終的な応答を初期の要求に送ります、最終的な応答が2xxであり、不承認の信頼できる暫定的な応答のいずれもセッション記述を含まなかったなら。 その場合、それらの暫定的な応答が承諾されるまで、それは最終的な応答を送ってはいけません。 UASが信頼できる応答がまだ認められなく、それがSHOULD NOTである最終的な応答を送るなら、不承認の信頼できる暫定的な応答を再送し続けなさい、ただし、それらの傑出している応答を求めるPRACK要求を処理するのは準備していなければなりません。 最終的な応答を要求に送った後に、UAS MUST NOTは新しい信頼できる暫定的な応答(不承認のものの「再-トランスミッション」と対照的に)を送ります。
Rosenberg & Schulzrinne Standards Track [Page 5] RFC 3262 Reliability of Provisional Responses in SIP June 2002
ローゼンバーグとSchulzrinne規格は2002年6月に一口における、暫定的な応答のRFC3262の信頼性を追跡します[5ページ]。
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ヘッダーフィールドを要求に挿入します。 値の100relがあるRequireヘッダーはINVITEを除きながら、どんな要求にも出席しているはずがありません、SIPへの拡大が他の要求方法がある用法を許容するかもしれませんが。
Rosenberg & Schulzrinne Standards Track [Page 6] RFC 3262 Reliability of Provisional Responses in SIP June 2002
ローゼンバーグとSchulzrinne規格は2002年6月に一口における、暫定的な応答のRFC3262の信頼性を追跡します[6ページ]。
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 -
ヘッダーフィールドどこPRACK___________________________________ R o Accept 2xxを受け入れてください--Call-インフォメーションをAcceptをコード化している415c○Acceptをコード化しているR2xx--コード化を受け入れている415c Accept-言語R o Accept-言語2xx--405mの言語を受け入れている415R(注意深いインフォメーション180)が許容するc Alert-インフォメーションR o Allow 2xx o Allow r o Allow Authentication-インフォメーション2xx o Authorization R o Call-ID c m受け入れてください; - Rに連絡してください--1xxに連絡してください--2xxに連絡してください--c mから3xx o Contact485o Content-気質o Contentをコード化しているo o Content-長さのtコンテントタイプ*CSeq c Content-言語m Date o Error-インフォメーション300-699o Expiresに連絡してください、Inが答える、R--R mがMin吐き出すマックス-フォワード423--MIMEバージョンo Organization、-
Table 1: Summary of header fields, A--O
テーブル1: A--ヘッダーフィールドの概要、O
Rosenberg & Schulzrinne Standards Track [Page 7] RFC 3262 Reliability of Provisional Responses in SIP June 2002
ローゼンバーグとSchulzrinne規格は2002年6月に一口における、暫定的な応答のRFC3262の信頼性を追跡します[7ページ]。
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
ヘッダーフィールドどこPRACK__________________________________________ 優先権R--407mをプロキシで認証するのは401R oがProxy必要とするo Proxy-認可R o Record-ルートR o Record-ルート2xxをProxy認証します、18x o、Reply、-、--c後のRetry4044億1348万486o500,503o600,603o Route R c Server r o Subject R--To c m Unsupported420m User-エージェントo Via c m Warning r oが401mにWWW認証するR o Supported 2xx o Timestamp○を支持するのを必要であってください
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との要求にSupportedヘッダーを含まなければなりません。 UAC SHOULDはすべての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(トライ)(101〜199と対照的に)であるなら、このオプションタグを無視しなければなりません、そして、以下の手順は用いられてはいけません。
Rosenberg & Schulzrinne Standards Track [Page 8] RFC 3262 Reliability of Provisional Responses in SIP June 2002
ローゼンバーグとSchulzrinne規格は2002年6月に一口における、暫定的な応答のRFC3262の信頼性を追跡します[8ページ]。
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 MUSTは方法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 SHOULD NOTは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 MUSTは初期の要求のためのオーダーにおける最も最近容認された信頼できる暫定的な応答を示す一連番号を維持します。 初期の要求のために最終的な応答を受けるまでこの一連番号を維持しなければなりません。 初期の要求のために受けられた最初の信頼できる暫定的な応答における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値が一連番号の値より高い1つでないなら、その応答を、PRACKと共に承諾してはいけなくて、より遠くにUACで処理してはいけません。 実現は、応答を捨てるか、またはなくなった応答を受けるという望みで応答をキャッシュするかもしれません。
The UAC MAY acknowledge reliable provisional responses received after the final response or MAY discard them.
UAC MAYは、信頼できる暫定的な応答が最終的な応答の後に受信するか、またはそれらを捨てるかもしれないと認めます。
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.
RFC3261は申し出と答え[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
INVITEが申し出を含んだなら、UAS MAYは信頼できる暫定的な応答における答えを発生させます(これらがUACによって支持されると仮定して)。 それは以前、セッションの設立をもたらします。
Rosenberg & Schulzrinne Standards Track [Page 9] RFC 3262 Reliability of Provisional Responses in SIP June 2002
ローゼンバーグとSchulzrinne規格は2002年6月に一口における、暫定的な応答のRFC3262の信頼性を追跡します[9ページ]。
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.
呼び出しの完成。 同様に、信頼できる暫定的な応答が最初の信頼できる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が申し出で信頼できる暫定的な応答を受けるなら(UACが申し出なしでINVITEを送るなら、これは起こるでしょうに、その場合、最初の信頼できる暫定的な応答は申し出を含むでしょう)、それはPRACKで答えを発生させなければなりません。 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 SHOULDは申し出と答えのパラメタに基づくセッションを確立します、オリジナルの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 MUSTは、暫定的な応答が承諾されるまで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.
この拡大を支持するすべてのユーザエージェントがすべてのRFC3261のセクション13.2の規則に基づいて可能な申し出/答え交換を支持しなければなりません、非失敗の信頼できる応答としての要求としてのINVITEとPRACKの存在、2xx、および信頼できる1xxに基づいて。
6 Definition of the PRACK Method
6 PRACK方法の定義
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はこの新しい方法のためにRFC3261からTables2と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つの新しいヘッダーフィールド、RAck、およびRSeqを定義します。 テーブル3はこれらのヘッダーのためにRFC3261からTables2と3を広げています。
7.1 RSeq
7.1 RSeq
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を見てください。
Rosenberg & Schulzrinne Standards Track [Page 10] RFC 3262 Reliability of Provisional Responses in SIP June 2002
ローゼンバーグとSchulzrinne規格は2002年6月に一口における、暫定的な応答のRFC3262の信頼性を追跡します[10ページ]。
Example:
例:
RSeq: 988789
RSeq: 988789
Header field where proxy ACK BYE CAN INV OPT REG PRA ______________________________________________________ RAck R - - - - - - m RSeq 1xx - - - o - - -
ヘッダーフィールドどこプロキシACK BYE CAN INV OPT REG PRA______________________________________________________ RAck R------------m RSeq 1xx--、--、--o----、-
Table 3: RAck and RSeq Header Fields
テーブル3: ラックとRSeqヘッダーフィールド
7.2 RAck
7.2 ラック
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要求でRAckヘッダーを送ります。 それは2つの番号と方法タグを含んでいます。 最初の数は承諾されている暫定的な応答におけるRSeqヘッダーからの値です。 次の数、および方法はCSeqから承諾されている応答でコピーされます。 RAckヘッダーの方法名は大文字と小文字を区別しています。
Example:
例:
RAck: 776656 1 INVITE
ラック: 1が招待する776656
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.
このドキュメントはRFC3261のIANA登録手続に基づいて新しいオプションタグと2個の新しいヘッダーを登録します。
8.1 IANA Registration of the 100rel Option Tag
8.1 100relオプションタグのIANA登録
This specification registers a single option tag, 100rel. The required information for this registration, as specified in RFC 3261, is:
この仕様は単一のオプションタグ、100relを登録します。 この登録のためのRFC3261で指定される必須情報は以下の通りです。
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.
記述: このオプションタグは暫定的な応答の信頼性のためのものです。 Supportedヘッダーに存在しているとき、それは、UAが信頼できる暫定的な応答を送るか、または受けることができるのを示します。 要求におけるRequireヘッダーに存在しているとき、それは、UAS MUSTがすべての暫定的な応答を確かに送るのを示します。 信頼できる暫定的な応答におけるRequireヘッダーに存在しているとき、それは、応答が確かに送られることであることを示します。
Rosenberg & Schulzrinne Standards Track [Page 11] RFC 3262 Reliability of Provisional Responses in SIP June 2002
ローゼンバーグとSchulzrinne規格は2002年6月に一口における、暫定的な応答のRFC3262の信頼性を追跡します[11ページ]。
8.2 IANA Registration of RSeq and RAck Headers
8.2 RSeqとラックヘッダーのIANA登録
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:
↓これはRAckヘッダーのための登録です:
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メッセージSHOULD、これらとして、応答は重要情報を伝えることができます。いかなる他のも要求するように、認証されます。 認証手順はRFC3261で指定されます。
10 Collected BNF
10 集まっているBNF
The BNF for the RAck and RSeq headers and the PRACK method are defined here.
RAck、RSeqヘッダー、およびPRACK方法のためのBNFはここで定義されます。
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。 キャップでは、拡大INVITEm/ACKm/OPTIONSm/BYEm/CANCELm/REGISTERm/PRACKm/方法Method=RAck=が「だめになる」というPRACK HCOLON応答-num LWS CSeq-num LWS Method応答-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.
作者はこのドキュメントのコメントについてジョウ・ホーンスビー、ジョナサンレノックス、Rohanマーイ、アリソン・マンキン、アダム・ローチ、およびティム・シュローダーに感謝したがっています。
Rosenberg & Schulzrinne Standards Track [Page 12] RFC 3262 Reliability of Provisional Responses in SIP June 2002
ローゼンバーグとSchulzrinne規格は2002年6月に一口における、暫定的な応答のRFC3262の信頼性を追跡します[12ページ]。
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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with SDP", RFC 3264, June 2002.
[3] ローゼンバーグとJ.とH.Schulzrinne、「SDPの申し出/答えモデル」、RFC3264、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.ローゼンバーグは「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC2543、1999年3月。
14 Authors' Addresses
14人の作者のアドレス
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
ジョナサンローゼンバーグdynamicsoft72Eagle Rock AvenueのFirst Floorの東ハノーバー王家、ニュージャージー 07936
EMail: jdrosen@dynamicsoft.com
メール: jdrosen@dynamicsoft.com
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003
ヘニングSchulzrinneコロンビア大学M/S0401 1214アムステルダムAve。 ニューヨーク、ニューヨーク10027-7003
EMail: schulzrinne@cs.columbia.edu
メール: schulzrinne@cs.columbia.edu
Rosenberg & Schulzrinne Standards Track [Page 13] RFC 3262 Reliability of Provisional Responses in SIP June 2002
ローゼンバーグとSchulzrinne規格は2002年6月に一口における、暫定的な応答のRFC3262の信頼性を追跡します[13ページ]。
15. Full Copyright Statement
15. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Rosenberg & Schulzrinne Standards Track [Page 14]
ローゼンバーグとSchulzrinne標準化過程[14ページ]
一覧
スポンサーリンク