[要約] RFC 6223は、Keep-Aliveのサポートを示すための方法を定義しています。その目的は、クライアントとサーバー間の接続を維持し、効率的な通信を実現することです。
Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 6223 Ericsson
Category: Standards Track April 2011
ISSN: 2070-1721
Indication of Support for Keep-Alive
Keep-Aliveのサポートの兆候
Abstract
概要
This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "keep", which allows adjacent SIP entities to explicitly negotiate usage of the Network Address Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in cases where SIP Outbound is not supported, cannot be applied, or where usage of keep-alives is not implicitly negotiated as part of the SIP Outbound negotiation.
この仕様では、ヘッダーフィールドパラメーター「Keep」を介して新しいセッション開始プロトコル（SIP）を定義します。これにより、隣接するSIPエンティティは、SIPアウトバウンドで定義されているネットワークアドレス変換（NAT）の使用可能メカニズムの使用を明示的に交渉できます。アウトバウンドはサポートされておらず、適用できません。また、SIPアウトバウンドネゴシエーションの一部としてKeep-Alivesの使用が暗黙的に交渉されない場合。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6223.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6223で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Use-Case: Dialog from Non-Registered UAs ...................3
1.2. Use-Case: SIP Outbound Not Supported .......................3
1.3. Use-Case: SIP Dialog Initiated Outbound Flows ..............3
2. Conventions .....................................................3
3. Definitions .....................................................4
4. User Agent and Proxy Behavior ...................................4
4.1. General ....................................................4
4.2. Lifetime of Keep-Alives ....................................5
4.2.1. General .............................................5
4.2.2. Keep-Alives Associated with Registration ............5
4.2.3. Keep-Alives Associated with Dialog ..................6
4.3. Behavior of a SIP Entity Willing to Send Keep-Alives .......6
4.4. Behavior of a SIP Entity Willing to Receive Keep-Alives ....7
5. Keep-Alive Frequency ............................................8
6. Connection Reuse ................................................9
7. Examples ........................................................9
7.1. General ....................................................9
7.2. Keep-Alive Negotiation Associated with
Registration: UA-Proxy .....................................9
7.3. Keep-Alive Negotiation Associated with Dialog: UA-Proxy ...11
7.4. Keep-Alive Negotiation Associated with Dialog: UA-UA ......13
8. Grammar ........................................................15
8.1. General ...................................................15
8.2. ABNF ......................................................15
9. IANA Considerations ............................................15
9.1. "keep" Via Header Field Parameter .........................15
10. Security Considerations .......................................15
11. Acknowledgements ..............................................16
12. References ....................................................17
12.1. Normative References .....................................17
12.2. Informative References ...................................17
Section 3.5 of SIP Outbound [RFC5626] defines two keep-alive mechanisms. Even though the keep-alive mechanisms are separated from the rest of the SIP Outbound mechanism, SIP Outbound does not define a mechanism to explicitly negotiate usage of the keep-alive mechanisms. In some cases, usage of keep-alives can be implicitly negotiated as part of the SIP Outbound negotiation.
SIPアウトバウンド[RFC5626]のセクション3.5は、2つのキープアライブメカニズムを定義しています。キープアライブメカニズムは、SIPアウトバウンドメカニズムの残りの部分から分離されていますが、SIPアウトバウンドは、キープアライブメカニズムの使用を明示的に交渉するメカニズムを定義しません。場合によっては、Keep-Alivesの使用は、SIPアウトバウンド交渉の一部として暗黙的に交渉することができます。
However, there are SIP Outbound use-cases where usage of keep-alives is not implicitly negotiated as part of the SIP Outbound negotiation. In addition, there are cases where SIP Outbound is not supported, or where it cannot be applied, but where there is still a need to be able to negotiate usage of keep-alives. Last, SIP Outbound only allows keep-alives to be negotiated between a User Agent (UA) and an edge proxy, and not between other SIP entities.
ただし、SIPアウトアリブの使用がSIPアウトバウンド交渉の一部として暗黙的に交渉されないSIPアウトバウンドの使用ケースがあります。さらに、SIPアウトバウンドがサポートされていない場合、または適用できない場合、キープアリブの使用を交渉できる必要がある場合があります。最後に、SIPアウトバウンドでは、他のSIPエンティティ間ではなく、ユーザーエージェント（UA）とEdgeプロキシの間でKeep-Alivesを交渉することができます。
This specification defines a new Session Initiation Protocol (SIP) [RFC3261] Via header field parameter, "keep", which allows adjacent SIP entities to explicitly negotiate usage of the NAT keep-alive mechanisms defined in SIP Outbound. The "keep" parameter allows SIP entities to indicate willingness to send keep-alives, to indicate willingness to receive keep-alives, and -- for SIP entities willing to receive keep-alives -- to provide a recommended keep-alive frequency.
この仕様では、ヘッダーフィールドパラメーター「Keep」を介して新しいセッション開始プロトコル（SIP）[RFC3261]を定義します。これにより、隣接するSIPエンティティは、SIPアウトバウンドで定義されたNAT Keep Aliveメカニズムの使用を明示的に交渉できます。「Keep」パラメーターにより、SIPエンティティはキープアリブを送信する意欲を示すことができ、Keep-Alivesを受け取る意欲を示し、-SIPエンティティがKeep-Alivesを受け取る意思があるため、推奨されるKeep Alive頻度を提供します。
The following sections describe use-cases where a mechanism to explicitly negotiate usage of keep-alives is needed.
次のセクションでは、Keep-Alivesの使用法を明示的に交渉するメカニズムが必要なユースケースについて説明します。
In some cases, a User Agent Client (UAC) does not register itself before it establishes a dialog, but in order to maintain NAT bindings open during the lifetime of the dialog, it still needs to be able to negotiate the sending of keep-alives towards its adjacent downstream SIP entity. A typical example is an emergency call, where a registration is not always required in order to make the call.
場合によっては、ユーザーエージェントクライアント（UAC）はダイアログを確立する前に登録しませんが、ダイアログの存続期間中にNATバインディングを開いていることを維持するために、Keep-Alivesの送信を交渉できる必要があります。隣接する下流のSIPエンティティに向かって。典型的な例は、緊急電話で、電話をかけるために必ずしも登録が必要ではありません。
In some cases, some SIP entities that need to be able to negotiate the use of keep-alives might not support SIP Outbound. However, they might still support the keep-alive mechanisms defined in SIP Outbound and need to be able to negotiate usage of them.
場合によっては、キープアリブの使用を交渉できる必要がある一部のSIPエンティティは、SIPアウトバウンドをサポートしない場合があります。ただし、SIPアウトバウンドで定義されている維持用アライブメカニズムをサポートしている可能性があり、それらの使用を交渉できる必要があります。
SIP Outbound allows the establishment of flows using the initial request for a dialog. As specified in RFC 5626 [RFC5626], usage of keep-alives is not implicitly negotiated for such flows.
SIPアウトバウンドにより、ダイアログの最初の要求を使用してフローを確立できます。RFC 5626 [RFC5626]で指定されているように、Keep-Alivesの使用は、そのようなフローについて暗黙的に交渉されません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [RFC2119]に記載されているように解釈される。
Edge proxy: As defined in RFC 5626, a SIP proxy that is located topologically between the registering User Agent (UA) and the Authoritative Proxy.
Edge Proxy：RFC 5626で定義されているように、登録ユーザーエージェント（UA）と権威あるプロキシの間にトポロジカルに位置するSIPプロキシ。
NOTE: In some deployments, the edge proxy might be physically located in the same SIP entity as the Authoritative Proxy.
注：一部の展開では、Edgeプロキシは、権威あるプロキシと同じSIPエンティティに物理的に配置される場合があります。
Keep-alives: The keep-alive messages defined in RFC 5626.
Keep-Alives：RFC 5626で定義されているキープアライブメッセージ。
"keep" parameter: A SIP Via header field parameter that a SIP entity can insert in the topmost Via header field that it adds to the request, to explicitly indicate willingness to send keep-alives towards its adjacent downstream SIP entity. A SIP entity can add a parameter value to the "keep" parameter in a response to explicitly indicate willingness to receive keep-alives from its adjacent upstream SIP entity.
「Keep」パラメーター：SIPエンティティがリクエストに追加するヘッダーフィールドを介して最上部に挿入できるヘッダーフィールドパラメーターを介したSIPは、隣接するダウンストリームSIPエンティティにキープアリブを送信する意欲を明示的に示します。SIPエンティティは、隣接する上流のSIPエンティティからKeep-Alivesを受け取る意欲を明示的に示すために、「Keep」パラメーターにパラメーター値を追加できます。
SIP entity: SIP User Agent (UA), or proxy, as defined in RFC 3261.
SIPエンティティ：RFC 3261で定義されているSIPユーザーエージェント（UA）、またはプロキシ。
Adjacent downstream SIP entity: The adjacent SIP entity in the direction towards which a SIP request is sent.
隣接するダウンストリームSIPエンティティ：SIPリクエストが送信される方向に隣接するSIPエンティティ。
Adjacent upstream SIP entity: The adjacent SIP entity in the direction from which a SIP request is received.
隣接するアップストリームSIPエンティティ：SIPリクエストが受信される方向の隣接するSIPエンティティ。
This section describes how SIP UAs and proxies negotiate usage of keep-alives associated with a registration or a dialog, which types of SIP requests can be used in order to negotiate the usage, and the lifetime of the negotiated keep-alives.
このセクションでは、SIP UAとプロキシが登録またはダイアログに関連付けられたKeep-Alivesの使用をどのように交渉するかについて説明します。これは、使用を交渉するために使用できる種類のSIP要求と、ネゴシエートされたKeep-Alivesの寿命について使用できます。
SIP entities indicate willingness to send keep-alives towards the adjacent downstream SIP entity using SIP requests. The associated responses are used by SIP entities to indicate willingness to receive keep-alives. SIP entities that indicate willingness to receive keep-alives can provide a recommended keep-alive frequency.
SIPエンティティは、SIPリクエストを使用して隣接する下流のSIPエンティティにKeep-Alivesを送信する意欲を示しています。関連する応答は、SIPエンティティによって使用され、Keep-Alivesを受け取る意欲を示します。Keep-Alivesを受け取る意欲を示すSIPエンティティは、推奨されるキープアリブ周波数を提供できます。
The procedures to negotiate usage of keep-alives are identical for SIP UAs and proxies.
Keep-Alivesの使用を交渉する手順は、SIP UASとプロキシと同じです。
In general, it can be useful for SIP entities to indicate willingness to send keep-alives, even if they are not aware of any necessity for them to send keep-alives, since the adjacent downstream SIP entity might have knowledge about the necessity. Similarly, if the adjacent upstream SIP entity has indicated willingness to send keep-alives, it can be useful for SIP entities to indicate willingness to receive keep-alives, even if they are not aware of any necessity for the adjacent upstream SIP entity to send them.
一般に、SIPエンティティは、隣接する下流のSIPエンティティが必要性について知識を持っている可能性があるため、Keep-Alivesを送信する必要性を知らない場合でも、Keep-Alivesを送信する意欲を示すことが有用です。同様に、隣接するアップストリームSIPエンティティがKeep-Alivesを送信する意欲を示している場合、SIPエンティティがKeep-Alivesを受け取る意欲を示すことは有用です。彼ら。
NOTE: Usage of keep-alives is negotiated per direction. If a SIP entity has indicated willingness to receive keep-alives from an adjacent SIP entity, the sending of keep-alives towards that adjacent SIP entity needs to be separately negotiated.
注：Keep-Alivesの使用は、方向ごとにネゴシエートされます。SIPエンティティが隣接するSIPエンティティからKeep-Alivesを受け取る意欲を示している場合、その隣接するSIPエンティティへのKeep-Alivesの送信は、個別に交渉する必要があります。
NOTE: Since there are SIP entities that already use a combination of Carriage Return and Line Feed (CRLF) as keep-alive messages, and SIP entities are expected to be able to receive those, this specification does not forbid the sending of double-CRLF keep-alive messages towards an adjacent SIP entity even if usage of keep-alives with that SIP entity has not been negotiated. However, the "keep" parameter is still important in order for a SIP entity to indicate that it supports the sending of double-CRLF keep-alive messages, so that the adjacent downstream SIP entity does not use other mechanisms (e.g., short registration refresh intervals) in order to keep NAT bindings open.
注：キャリッジリターンフィード（CRLF）の組み合わせをキープアライブメッセージとして既に使用しているSIPエンティティがあり、SIPエンティティはそれらを受け取ることができると予想されるため、この仕様はDouble-CRLFの送信を禁止しませんそのSIPエンティティを使用したKeep-Alivesの使用が交渉されていない場合でも、隣接するSIPエンティティへのアライブメッセージを維持します。ただし、SIPエンティティがDouble-CRLF Keep-Aliveメッセージの送信をサポートしていることを示すために「Keep」パラメーターは依然として重要です。そのため、隣接するダウンストリームSIPエンティティは他のメカニズムを使用しません（たとえば、短い登録リフレッシュ。間隔）ナットバインディングを開いたままにするため。
The lifetime of negotiated keep-alives depends on whether the keep-alives are associated with a registration or a dialog. This section describes the lifetime of negotiated keep-alives.
交渉されたキープアリブの寿命は、キープアリブが登録またはダイアログに関連付けられているかどうかに依存します。このセクションでは、ネゴシエートされたキープアリブの寿命について説明します。
SIP entities use a registration request in order to negotiate usage of keep-alives associated with a registration. Usage of keep-alives can be negotiated when the registration is established, or later during the registration. Once negotiated, keep-alives are sent until the registration is terminated, or until a subsequent registration refresh request is sent or forwarded. When a subsequent registration refresh request is sent or forwarded, if a SIP entity is willing to continue sending keep-alives associated with the registration, usage of keep-alives MUST be re-negotiated. If usage is not successfully re-negotiated, the SIP entity MUST cease the sending of keep-alives associated with the registration.
SIPエンティティは、登録に関連付けられたKeep-Alivesの使用を交渉するために登録リクエストを使用します。Keep-Alivesの使用は、登録が確立されたとき、または登録中に交渉することができます。交渉後、登録が終了するまで、または後続の登録更新リクエストが送信または転送されるまで、キープアリブが送信されます。後続の登録更新リクエストが送信または転送された場合、SIPエンティティが登録に関連付けられたKeep-Alivesの送信を続けることをいとわない場合、Keep Alivesの使用は再交渉する必要があります。使用法が正常に再交渉されていない場合、SIPエンティティは登録に関連するキープアリブの送信を停止する必要があります。
NOTE: The sending of keep-alives associated with a registration can only be negotiated in the direction from the registering SIP entity towards the registrar.
注：登録に関連付けられたキープアリブの送信は、登録SIPエンティティからレジストラへの方向でのみ交渉できます。
SIP entities use an initial request for a dialog, or a mid-dialog target refresh request [RFC3261], in order to negotiate the sending and receiving of keep-alives associated with a dialog. Usage of keep-alives can be negotiated when the dialog is established, or later during the lifetime of the dialog. Once negotiated, keep-alives MUST be sent for the lifetime of the dialog, until the dialog is terminated. Once the usage of keep-alives associated with a dialog has been negotiated, it is not possible to re-negotiate the usage associated with the dialog.
SIPエンティティは、ダイアログに関連付けられたKeep-Alivesの送信と受信を交渉するために、ダイアログの初期リクエスト、またはMid-Dialogターゲット更新リクエスト[RFC3261]を使用します。キープアリブの使用は、ダイアログが確立されたとき、またはダイアログの寿命の間にネゴシエートすることができます。交渉したら、ダイアログが終了するまで、ダイアログの寿命のためにキープアリブを送信する必要があります。ダイアログに関連付けられたキープアリブの使用が交渉されたら、ダイアログに関連付けられた使用を再交渉することはできません。
As defined in RFC 5626, a SIP entity that supports the sending of keep-alives must act as a Session Traversal Utilities for NAT (STUN) client [RFC5389]. The SIP entity must support those aspects of STUN that are required in order to apply the STUN keep-alive mechanism defined in RFC 5626, and it must support the CRLF keep-alive mechanism defined in RFC 5626. RFC 5626 defines when to use STUN and when to use double-CRLF for keep-alives.
RFC 5626で定義されているように、Keep-Alivesの送信をサポートするSIPエンティティは、NAT（STUN）クライアントのセッショントラバーサルユーティリティとして機能する必要があります[RFC5389]。SIPエンティティは、RFC 5626で定義されているスタンキープアライブメカニズムを適用するために必要なスタンの側面をサポートする必要があり、RFC 5626で定義されたCRLFキープアライブメカニズムをサポートする必要があります。Keep-AlivesにDouble-CRLFを使用するタイミング。
When a SIP entity sends or forwards a request, if it wants to negotiate the sending of keep-alives associated with a registration or a dialog, it MUST insert a "keep" parameter in the topmost Via header field that it adds to the request, to indicate willingness to send keep-alives.
SIPエンティティがリクエストを送信または転送する場合、登録またはダイアログに関連付けられたキープアリブの送信を交渉したい場合、リクエストに追加するヘッダーフィールドを介して最上部に「キープ」パラメーターを挿入する必要があります。Keep-Alivesを送信する意欲を示すため。
When the SIP entity receives the associated response, if the "keep" parameter in the topmost Via header field of the response contains a "keep" parameter value, it MUST start sending keep-alives towards the same destination where it would send a subsequent request (e.g., REGISTER requests and initial requests for dialog) associated with the registration (if the keep-alive negotiation is for a registration), or where it would send subsequent mid-dialog requests (if the keep-alive negotiation is for a dialog). Subsequent mid-dialog requests are addressed based on the dialog route set.
SIPエンティティが関連する応答を受信した場合、応答のヘッダーフィールドを介して最上部の「Keep」パラメーターに「Keep」パラメーター値が含まれている場合、その後のリクエストを送信する同じ宛先にKeep-Alivesを送信し始める必要があります。（例えば、登録要求とダイアログの初期リクエスト）登録に関連付けられている（キープアライブネゴシエーションが登録のための場合）、またはそれがその後のミッドダイアログリクエストを送信する場所（キープアライブネゴシエーションがダイアログの場合）。その後のMid-Dialogリクエストは、ダイアログルートセットに基づいて対処されます。
Once a SIP entity has negotiated the sending of keep-alives associated with a dialog towards an adjacent SIP entity, it MUST NOT insert a "keep" parameter in any subsequent SIP requests associated with that dialog towards that adjacent SIP entity. Such "keep" parameters MUST be ignored, if received.
SIPエンティティが、隣接するSIPエンティティに向けたダイアログに関連付けられたKeep-Alivesの送信を交渉したら、そのダイアログに関連付けられた後続のSIP要求に「Keep」パラメーターをその隣接するSIPエンティティに挿入してはなりません。このような「保持」パラメーターは、受け取った場合は無視する必要があります。
Since an ACK request does not have an associated response, it cannot be used to negotiate usage of keep-alives. Therefore, a SIP entity MUST NOT insert a "keep" parameter in the topmost Via header field of an ACK request. Such "keep" parameters MUST be ignored, if received.
ACKリクエストには関連する応答がないため、Keep-Alivesの使用を交渉するために使用することはできません。したがって、SIPエンティティは、ACK要求のヘッダーフィールドを介して最上部に「Keep」パラメーターを挿入してはなりません。このような「保持」パラメーターは、受け取った場合は無視する必要があります。
A SIP entity MUST NOT indicate willingness to send keep-alives associated with a dialog, unless it has also inserted itself in the dialog route set [RFC3261].
SIPエンティティは、ダイアログルートセット[RFC3261]にも挿入されていない限り、ダイアログに関連付けられたキープアリブを送信する意欲を示してはなりません。
NOTE: When a SIP entity sends an initial request for a dialog, if the adjacent downstream SIP entity does not insert itself in the dialog route set using a Record-Route header field [RFC3261], the adjacent downstream SIP entity will change once the dialog route set has been established. If a SIP entity inserts a "keep" parameter in the topmost Via header field of an initial request for a dialog, and the "keep" parameter in the associated response does not contain a parameter value, the SIP entity might choose to insert a "keep" parameter in the topmost Via header field of a subsequent SIP request associated with the dialog, in case the new adjacent downstream SIP entity (based on the dialog route set) is willing to receive keep-alives (in which case it will add a parameter value to the "keep" parameter).
注：SIPエンティティがダイアログの初期リクエストを送信すると、隣接する下流のSIPエンティティがレコードルートヘッダーフィールド[RFC3261]を使用してダイアログルートセットに挿入しない場合、ダイアログが変更されると隣接するダウンストリームSIPエンティティが変更されると、ルートセットが確立されました。SIPエンティティがダイアログの初期リクエストのヘッダーフィールドを介して最上部に「Keep」パラメーターを挿入し、関連する応答の「Keep」パラメーターにパラメーター値が含まれていない場合、SIPエンティティは挿入することを選択できます。ダイアログに関連付けられた後続のSIP要求のヘッダーフィールドを最上部に保持する。パラメーター値「Keep」パラメーター）。
If an INVITE request is used to indicate willingness to send keep-alives, as long as at least one response (provisional or final) to the INVITE request contains a "keep" parameter with a parameter value, it is seen as an indication that the adjacent downstream SIP entity is willing to receive keep-alives associated with the dialog on which the response is received.
招待状リクエストが、招待リクエストに対する少なくとも1つの応答（暫定または最終）にパラメーター値を持つ「キープ」パラメーターが含まれている限り、Keep-Alivesを送信する意欲を示すために使用されている場合、それは兆候と見なされます。隣接するダウンストリームSIPエンティティは、応答が受信されるダイアログに関連付けられたキープアリブを受け取ることをいとわない。
As defined in RFC 5626, a SIP entity that supports the receiving of keep-alives must act as a STUN server [RFC5389]. The SIP entity must support those aspects of STUN that are required in order to apply the STUN keep-alive mechanism defined in RFC 5626, and it must support the CRLF keep-alive mechanism defined in RFC 5626.
RFC 5626で定義されているように、Keep-Alivesの受信をサポートするSIPエンティティは、スタンサーバーとして機能する必要があります[RFC5389]。SIPエンティティは、RFC 5626で定義されているスタンキープアライブメカニズムを適用するために必要なスタンの側面をサポートする必要があり、RFC 5626で定義されたCRLFキープアライブメカニズムをサポートする必要があります。
When a SIP entity sends or forwards a response, and the adjacent upstream SIP entity has indicated willingness to send keep-alives, if the SIP entity is willing to receive keep-alives associated with the registration or with the dialog from that adjacent upstream SIP entity, then it MUST add a parameter value to the "keep" parameter before sending or forwarding the response. The parameter value, if present and with a value other than zero, represents a recommended keep-alive frequency, given in seconds.
SIPエンティティが応答を送信または転送するとき、および隣接する上流のSIPエンティティは、SIPエンティティが登録またはその隣接するアップストリームSIPエンティティからのダイアログと関連するKeep-Alivesを受け取ることをいとわない場合、Keep-Alivesを送信する意欲を示しています。、次に、応答を送信または転送する前に、パラメーター値を「Keep」パラメーターに追加する必要があります。存在する場合、ゼロ以外の値を持つパラメーター値は、数秒で与えられる推奨されるキープアリブ周波数を表します。
There might be multiple responses to an INVITE request. When a SIP entity indicates willingness to receive keep-alives in a response to an INVITE request, it MUST add a parameter value to the "keep" parameter in at least one reliable response to the request. The SIP entity MAY add identical parameter values to the "keep" parameters in other responses to the same request. The SIP entity MUST NOT add different parameter values to the "keep" parameters in responses to the same request. The SIP entity SHOULD indicate the willingness to receive keep-alives as soon as possible.
招待リクエストに対する複数の応答があるかもしれません。SIPエンティティが招待リクエストへの応答でKeep-Alivesを受け取る意欲を示した場合、リクエストに対する少なくとも1つの信頼できる応答で「Keep」パラメーターにパラメーター値を追加する必要があります。SIPエンティティは、同じリクエストに対する他の応答で「Keep」パラメーターに同一のパラメーター値を追加する場合があります。SIPエンティティは、同じリクエストに対する応答に「Keep」パラメーターに別のパラメーター値を追加してはなりません。SIPエンティティは、できるだけ早くKeep-Alivesを受け取る意欲を示す必要があります。
A SIP entity MUST NOT indicate willingness to receive keep-alives associated with a dialog, unless it has also inserted itself in the dialog route set [RFC3261].
SIPエンティティは、ダイアログルートセット[RFC3261]にも挿入されていない限り、ダイアログに関連付けられたキープアリブを受け取る意欲を示してはなりません。
If a SIP entity receives a SIP response, where the topmost Via header field contains a "keep" parameter with a non-zero value that indicates a recommended keep-alive frequency, given in seconds, it MUST use the procedures defined for the Flow-Timer header field [RFC5626]. According to the procedures, the SIP entity must send keep-alives at least as often as the indicated recommended keep-alive frequency, and if the SIP entity uses the recommended keep-alive frequency, then it should send its keep-alives so that the interval between each keep-alive is randomly distributed between 80% and 100% of the recommended keep-alive frequency.
SIPエンティティがSIP応答を受信した場合、ヘッダーフィールドを介して最上部には、推奨されるキープアライブ周波数を示す非ゼロ値を持つ「キープ」パラメーターが含まれている場合、フローで定義された手順を使用する必要があります。タイマーヘッダーフィールド[RFC5626]。手順によれば、SIPエンティティは、示されている推奨されるキープアライブ周波数と同じくらい頻繁にキープアリブを送信する必要があり、SIPエンティティが推奨されるキープアライブ周波数を使用する場合、そのキープアリブを送信して、各キープアリブ間の間隔は、推奨されるキープアリブ周波数の80％から100％の間でランダムに分布しています。
If the received "keep" parameter value is zero, the SIP entity can send keep-alives at its discretion. RFC 5626 provides additional guidance on selecting the keep-alive frequency in case a recommended keep-alive frequency is not provided.
受信した「Keep」パラメーター値がゼロの場合、SIPエンティティはその裁量でKeep-Alivesを送信できます。RFC 5626は、推奨されるキープアライブ周波数が提供されていない場合に備えて、キープアライブ周波数の選択に関する追加のガイダンスを提供します。
This specification does not specify actions to take if negotiated keep-alives are not received. As defined in RFC 5626, the receiving SIP entity may consider a connection to be dead in such situations.
この仕様では、ネゴシエートされたキープアリブが受信されない場合に実行するアクションを指定しません。RFC 5626で定義されているように、受信SIPエンティティは、そのような状況で接続が死んでいると考える場合があります。
If a SIP entity that adds a parameter value to the "keep" parameter in order to indicate willingness to receive keep-alives also inserts a Flow-Timer header field (that can happen if the SIP entity is using both the Outbound mechanism and the keep-alive mechanism) in the same SIP message, the header field value and the "keep" parameter value MUST be identical.
Keep-Alivesを受信する意欲を示すために「Keep」パラメーターにパラメーター値を追加するSIPエンティティがフロータイマーヘッダーフィールドを挿入する場合（SIPエンティティがアウトバウンドメカニズムとKeepの両方を使用している場合に発生する可能性があります。-Aliveメカニズム）同じSIPメッセージで、ヘッダーフィールド値と「Keep」パラメーター値は同一でなければなりません。
SIP Outbound uses the Flow-Timer header field to indicate the server-recommended keep-alive frequency; however, it will only be sent between a UA and an edge proxy. On the other hand, by using the "keep" parameter, the sending and receiving of keep-alives can be negotiated between multiple entities on the signalling path. In addition, since the server-recommended keep-alive frequency might vary between different SIP entities, a single Flow-Timer header field cannot be used to indicate all the different frequency values.
SIP Outboundは、フロータイマーヘッダーフィールドを使用して、サーバーが推奨するキープアライブ周波数を示します。ただし、UAとEdgeプロキシの間でのみ送信されます。一方、「Keep」パラメーターを使用することにより、Signalingパス上の複数のエンティティ間でKeep-Alivesの送信と受信を交渉できます。さらに、サーバーが推奨するキープアリブ周波数はSIPエンティティによって異なる場合があるため、単一のフロータイマーヘッダーフィールドを使用して、すべての異なる周波数値を示すことはできません。
Keep-alives are often sent in order to keep NAT bindings open, so that SIP requests sent in the reverse direction will pass by the NAT and reuse the same connection. In the case of non-connection-oriented transport protocols, keep-alives would permit the same path to be reused. This specification does not define such a connection reuse mechanism. The keep-alive mechanism defined in this specification is only used to negotiate the sending and receiving of keep-alives. Entities that want to reuse connections need to use another mechanism to ensure that security aspects associated with connection reuse are taken into consideration.
NATバインディングを開いたままにするために、KEEP-Alivesはしばしば送信されるため、逆方向に送信されるSIPリクエストはNATを通過し、同じ接続を再利用します。非接続指向の輸送プロトコルの場合、Keep-Alivesは同じパスを再利用できるようにします。この仕様は、このような接続再利用メカニズムを定義しません。この仕様で定義されているキープアライブメカニズムは、キープアリブの送信と受信の交渉にのみ使用されます。接続を再利用したいエンティティは、別のメカニズムを使用して、接続の再利用に関連するセキュリティの側面が考慮されるようにする必要があります。
RFC 5923 [RFC5923] specifies a mechanism for using connection-oriented transports to send requests in the reverse direction, and an entity that wants to use connection reuse as well as indicate support of keep-alives on that connection will insert both the "alias" parameter defined in RFC 5923 and the "keep" parameter defined in this specification.
RFC 5923 [RFC5923]は、接続指向のトランスポートを使用してリクエストを逆方向に送信するメカニズムと、接続の再利用を使用したいエンティティと、その接続のキープアリブのサポートを示すエンティティを指定します。RFC 5923で定義されているパラメーターと、この仕様で定義されている「Keep」パラメーター。
SIP Outbound specifies how registration flows are used to send requests in the reverse direction.
SIPアウトバウンドは、登録フローを使用してリクエストを逆方向に送信する方法を指定します。
This section shows example flows where usage of keep-alives, associated with a registration and a dialog, is negotiated between different SIP entities.
このセクションでは、登録とダイアログに関連付けられたKeep-Alivesの使用が、異なるSIPエンティティ間で交渉されるフローの例を示しています。
NOTE: The examples do not show the actual syntactical encoding of the request lines, response lines, and the Via header fields, but rather a pseudocode in order to identify the message type and also identify to which SIP entity a Via header field is associated.
注：例では、リクエスト行、応答線、およびヘッダーフィールドの実際の構文エンコードを表示するのではなく、メッセージタイプを識別し、どのSIPエンティティA Viaヘッダーフィールドが関連付けられているかを識別するための擬似コードを示しています。
Figure 1 shows an example where Alice sends a REGISTER request. She indicates willingness to send keep-alives by inserting a "keep" parameter in the Via header field of her request. The edge proxy (P1) forwards the request towards the registrar.
図1は、アリスがレジスタリクエストを送信する例を示しています。彼女は、リクエストのヘッダーViaヘッダーフィールドに「Keep」パラメーターを挿入することにより、Keep-Alivesを送信する意欲を示しています。Edge Proxy（P1）は、リクエストをレジストラに転送します。
P1 is willing to receive keep-alives from Alice for the duration of the registration, so when P1 receives the associated response it adds a "keep" parameter value, which indicates a recommended keep-alive frequency of 30 seconds, to Alice's Via header field, before it forwards the response towards Alice.
P1は登録期間中、アリスからキープアリブを受け取ることをいとわないため、P1が関連する応答を受信すると、「Keep」パラメーター値を追加します。、それがアリスへの応答を転送する前に。
When Alice receives the response, she determines from her Via header field that P1 is willing to receive keep-alives associated with the registration. Until either the registration expires or Alice sends a registration refresh request, Alice then sends periodic keep-alives (in this example using the STUN keep-alive technique) towards P1, using the recommended keep-alive frequency indicated by the "keep" parameter value.
アリスが応答を受け取ると、彼女はヘッダーフィールドを経由して、P1が登録に関連付けられたキープアリブを受け取ることをいとわないことを決定します。登録が期限切れになるか、アリスが登録リフレッシュリクエストを送信するまで、アリスは「キープ」パラメーター値で示される推奨されるキープアライブ周波数を使用して、P1に向かって定期的なキープアリブ（この例ではこの例で）を送信します。。
Alice P1 REGISTRAR
| | |
|--- REGISTER------------->| |
| Via: Alice;keep | |
| |--- REGISTER-------------->|
| | Via: P1 |
| | Via: Alice;keep |
| | |
| |<-- 200 OK ----------------|
| | Via: P1 |
| | Via: Alice;keep |
|<-- 200 OK ---------------| |
| Via: Alice;keep=30 | |
| | |
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
Figure 1: Example Call Flow
図1：コールフローの例
Figure 2 shows an example where Alice sends an initial INVITE request for a dialog. She indicates willingness to send keep-alives by inserting a "keep" parameter in the Via header field of her request. The edge proxy (P1) adds itself to the dialog route set by adding itself to a Record-Route header field, before it forwards the request towards Bob.
図2は、アリスがダイアログの最初の招待リクエストを送信する例を示しています。彼女は、リクエストのヘッダーViaヘッダーフィールドに「Keep」パラメーターを挿入することにより、Keep-Alivesを送信する意欲を示しています。Edge Proxy（P1）は、Recultsをボブに転送する前に、レコードルートヘッダーフィールドにそれ自体を追加することにより、設定されたダイアログルートに追加されます。
P1 is willing to receive keep-alives from Alice for the duration of the dialog, so when P1 receives the associated response it adds a "keep" parameter value, which indicates a recommended keep-alive frequency of 30 seconds, to Alice's Via header field, before it forwards the response towards Alice.
P1はダイアログの期間中、アリスからキープアリブを受け取ることをいとわないため、P1が関連する応答を受信すると、「Keep」パラメーター値を追加します。、それがアリスへの応答を転送する前に。
When Alice receives the response, she determines from her Via header field that P1 is willing to receive keep-alives associated with the dialog. For the lifetime of the dialog, Alice then sends periodic keep-alives (in this example using the STUN keep-alive technique) towards P1, using the recommended keep-alive frequency indicated by the "keep" parameter value.
アリスが応答を受け取ると、彼女はヘッダーフィールドを介して、P1がダイアログに関連付けられたキープアリブを受け取ることをいとわないことを決定します。ダイアログの寿命について、アリスは、「キープ」パラメーター値で示される推奨されるキープアライブ周波数を使用して、P1に対して定期的なキープアリブ（この例ではスタンキープアリブ技術を使用）を送信します。
Alice P1 Bob
| | |
|--- INVITE -------------->| |
| Via: Alice;keep | |
| |--- INVITE --------------->|
| | Via: P1 |
| | Via: Alice;keep |
| | Record-Route: P1 |
| | |
| |<-- 200 OK ----------------|
| | Via: P1 |
| | Via: Alice;keep |
| | Record-Route: P1 |
|<-- 200 OK ---------------| |
| Via: Alice;keep=30 | |
| Record-Route: P1 | |
| | |
|--- ACK ----------------->| |
| | |
| |--- ACK ------------------>|
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
| *** Timeout *** |
| | |
|=== STUN request ========>| |
|<== STUN response ========| |
| | |
| | |
|--- BYE ----------------->| |
| | |
| |--- BYE ------------------>|
| | |
| |<-- 200 OK ----------------|
| | |
Figure 2: Example Call Flow
図2：コールフローの例
Figure 3 shows an example where Alice sends an initial INVITE request for a dialog. She indicates willingness to send keep-alives by inserting a "keep" parameter in the Via header field of her request. In this scenario, the edge proxy (P1) does not add itself to a Record-Route header field (and so will not be added to the dialog route set) before forwarding the request towards Bob.
図3は、アリスがダイアログの最初の招待リクエストを送信する例を示しています。彼女は、リクエストのヘッダーViaヘッダーフィールドに「Keep」パラメーターを挿入することにより、Keep-Alivesを送信する意欲を示しています。このシナリオでは、エッジプロキシ（P1）は、リクエストをボブに転送する前に、レコードルートヘッダーフィールドに追加されません（ダイアログルートセットに追加されません）。
When Alice receives the response, she determines from the Via header field that P1 is not willing to receive keep-alives associated with the dialog from her. When the dialog route set has been established, Alice sends a mid-dialog UPDATE request towards Bob (since P1 did not insert itself in the dialog route set), and she once again indicates willingness to send keep-alives by inserting a "keep" parameter in the Via header field of her request. Bob supports the keep-alive mechanism, and is willing to receive keep-alives associated with the dialog from Alice, so he creates a response and adds a "keep" parameter value, which indicates a recommended keep-alive frequency of 30 seconds, to Alice's Via header field, before he forwards the response towards Alice.
アリスが応答を受け取ったとき、彼女はViaヘッダーフィールドから、P1が彼女からの対話に関連付けられたKeep-Alivesを受け取ることをいとわないと判断します。ダイアログルートセットが確立されたとき、アリスはボブにミッドダイアログ更新リクエストを送信します（P1はダイアログルートセットに挿入しなかったため）。彼女の要求のヘッダーViaヘッダーフィールドのパラメーター。ボブはキープアライブメカニズムをサポートし、アリスからのダイアログに関連付けられたキープアリブを受け取る意思があるため、応答を作成し、「キープ」パラメーター値を追加します。アリスはヘッダーフィールド経由で、アリスに応答を転送する前に。
When Alice receives the response, she determines from her Via header field that Bob is willing to receive keep-alives associated with the dialog. For the lifetime of the dialog, Alice then sends periodic keep-alives (in this example using the STUN keep-alive technique) towards Bob, using the recommended keep-alive frequency indicated by the "keep" parameter value.
アリスが応答を受け取ると、彼女はヘッダーフィールドを経由して、ボブが対話に関連付けられたキープアリブを受け取ることをいとわないことを決定します。ダイアログの寿命について、アリスは、「キープ」パラメーター値で示される推奨されるキープアライブ周波数を使用して、ボブに対して定期的なキープアリブ（この例ではスタンキープアリブテクニックを使用）を送信します。
Alice P1 Bob
| | |
|--- INVITE -------------->| |
| Via: Alice;keep | |
| |--- INVITE --------------->|
| | Via: P1 |
| | Via: Alice;keep |
| | |
| |<-- 200 OK ----------------|
| | Via: P1 |
| | Via: Alice;keep |
|<-- 200 OK ---------------| |
| Via: Alice;keep | |
| | |
| |
|--- ACK --------------------------------------------->|
| |
|--- UPDATE ------------------------------------------>|
| Via: Alice;keep |
| |
|<-- 200 OK -------------------------------------------|
| Via: Alice;keep=30 |
| |
| |
| *** Timeout *** |
| |
|=== STUN request ====================================>|
|<== STUN response ====================================|
| |
| *** Timeout *** |
| |
|=== STUN request ====================================>|
|<== STUN response ====================================|
| |
| |
|--- BYE --------------------------------------------->|
| |
|<-- 200 OK -------------------------------------------|
| |
Figure 3: Example Call Flow
図3：コールフローの例
This section extends the ABNF definition of via-params from [RFC3261] by adding a new Via header field parameter, "keep". The ABNF defined in this specification is conformant to RFC 5234 [RFC5234]. "EQUAL" is defined in RFC 3261. "DIGIT" is defined in RFC 5234.
このセクションでは、[RFC3261]からのVia-ParamsのABNF定義を拡張し、新しいVia Headerフィールドパラメーター「Keep」を追加します。この仕様で定義されているABNFは、RFC 5234 [RFC5234]に適合しています。「Equal」はRFC 3261で定義されています。「数字」はRFC 5234で定義されています。
via-params =/ keep
via-params =/ keep
keep = "keep" [ EQUAL 1*(DIGIT) ]
keep = "keep" [等しい1*（桁）]
This specification defines a new Via header field parameter called
"keep" in the "Header Field Parameters and Parameter Values"
sub-registry as per the registry created by [RFC3968]. The syntax is
defined in Section 8 of this document. IANA has registered the
following:
Predefined
Header Field Parameter Name Values Reference
---------------------- --------------------- ---------- ---------
Via keep No [RFC6223]
SIP entities that send or receive keep-alives are often required to use a connection reuse mechanism, in order to ensure that requests sent in the reverse direction, towards the sender of the keep-alives, traverse NATs, etc. This specification does not define a connection reuse mechanism, and it does not address security issues related to connection reuse. SIP entities that wish to reuse connections need to use a dedicated connection reuse mechanism, in conjunction with the keep-alive negotiation mechanism.
Keep-Alivesを送信または受信するSIPエンティティは、リクエストが逆方向に送信されることを保証するために、Keep-Alivesの送信者、トラバースNATなどを確認するために、多くの場合、接続再利用メカニズムを使用する必要があります。この仕様は定義されません。接続の再利用メカニズムであり、接続の再利用に関連するセキュリティの問題に対処しません。接続を再利用したいSIPエンティティは、キープアライブネゴシエーションメカニズムと組み合わせて、専用の接続再利用メカニズムを使用する必要があります。
Unless SIP messages are integrity protected hop-by-hop, e.g., using Transport Layer Security (TLS) [RFC5246] or Datagram Transport Layer Security (DTLS) [RFC4347], a man-in-the-middle can modify Via header fields used by two entities to negotiate the sending of keep-alives, e.g., by removing the designations used to indicate willingness to send and receive keep-alives, or by decreasing the timer value to a very low value, which might trigger additional resource consumption due to the frequently sent keep-alives.
SIPメッセージが整合性で保護されている場合、たとえば、トランスポートレイヤーセキュリティ（TLS）[RFC5246]またはデータグラムトランスポートレイヤーセキュリティ（DTLS）[RFC4347]を使用して、ミドルを使用するヘッダーフィールドを介して修正できます。Keep-Alivesの送信を交渉する2つのエンティティによって、たとえば、Keep-Alivesを送信および受信する意欲を示すために使用される指定を削除するか、タイマー値を非常に低い値に減らすことにより、追加のリソース消費をトリガーする可能性があります。頻繁に送信されるキープアリブ。
The behaviors defined in Sections 4.3 and 4.4 require a SIP entity using the mechanism defined in this specification to place a value in the "keep" parameter in the topmost Via header field value of a response the SIP entity sends. They do not instruct the entity to place a value in a "keep" parameter of any request it forwards. In particular, a SIP proxy MUST NOT place a value into the "keep" parameter of the topmost Via header field value of a request it receives before forwarding it. A SIP proxy implementing this specification SHOULD remove any "keep" parameter values in any Via header field values below the topmost one in responses it receives before forwarding them.
セクション4.3および4.4で定義されている動作には、この仕様で定義されたメカニズムを使用して、SIPエンティティが送信する応答のヘッダーフィールド値を介して最上部に「キープ」パラメーターに値を配置するSIPエンティティが必要です。彼らは、それを転送する要求の「維持」パラメーターに値を配置するようにエンティティに指示しません。特に、SIPプロキシは、転送する前に受け取ったリクエストのヘッダーフィールド値を介して、最上部の「キープ」パラメーターに値を配置してはなりません。この仕様を実装するSIPプロキシは、転送する前に受信する応答で、最上部の値以下のviaヘッダーフィールド値の「キープ」パラメーター値を削除する必要があります。
When requests are forwarded across multiple hops, it is possible for a malicious downstream SIP entity to tamper with the accrued values in the Via header field. The malicious SIP entity could place a value, or change an existing value in a "keep" parameter in any of the Via header field values -- not just the topmost value. A proxy implementation that simply forwards responses by stripping the topmost Via header field value and not inspecting the resulting new topmost Via header field value risks being adversely affected by such a malicious downstream SIP entity. In particular, such a proxy may start receiving STUN requests if it blindly forwards a response with a "keep" parameter with a value it did not create in the topmost Via header field.
要求が複数のホップにわたって転送されると、悪意のある下流のSIPエンティティがViaヘッダーフィールドのAccreued値を改ざんする可能性があります。悪意のあるSIPエンティティは、値だけでなく、viaヘッダーフィールド値のいずれかで「保持」パラメーターに値を配置したり、既存の値を変更したりできます。ヘッダーフィールド値を介して最上部を削除することで応答を単純に転送するプロキシ実装であり、そのような悪意のあるダウンストリームSIPエンティティによって悪影響を受けるヘッダーフィールド値リスクを介して結果の新しい最上位を検査せずに検査しません。特に、このようなプロキシは、ヘッダーフィールドを介して最上部に作成されなかった値で「Keep」パラメーターを使用して応答を盲目的に転送する場合、Stun要求の受信を開始する場合があります。
To lower the chances of the malicious SIP entity's actions having adverse effects on such proxies, when a SIP entity sends STUN keep-alives to an adjacent downstream SIP entity and does not receive a response to those STUN messages (as described in Section 7.2.1 of RFC 5389 [RFC5389], it MUST stop sending keep-alives for the remaining duration of the dialog (if the sending of keep-alives were negotiated for a dialog) or until the sending of keep-alives is re-negotiated for the registration (if the sending keep-alives were negotiated for a registration).
SIPエンティティがStun Keep-Alivesを隣接するダウンストリームSIPエンティティに送信し、それらのスタンメッセージへの応答を受け取らない（セクション7.2.1で説明されているように、SIPエンティティがそのようなプロキシに悪影響を与える可能性を低下させるためにRFC 5389 [RFC5389]のうち、ダイアログの残りの期間（キープアリブの送信がダイアログのために交渉された場合）または登録の送信が登録のために再交渉されるまで、キープアリブの送信を停止する必要があります（送信キープアリブが登録のために交渉された場合）。
Apart from the issues described above, this specification does not introduce security considerations in addition to those specified for keep-alives in [RFC5626].
上記の問題とは別に、この仕様では、[RFC5626]のKEEP-Alivesに指定されたものに加えて、セキュリティ上の考慮事項を導入するものではありません。
Thanks to Staffan Blau, Francois Audet, Hadriel Kaplan, Sean Schneyer, and Milo Orsic for their comments on the initial draft version of this document. Thanks to Juha Heinanen, Jiri Kuthan, Dean Willis, John Elwell, Paul Kyzivat, Peter Musgrave, Dale Worley, Adam Roach, and Robert Sparks for their comments on the sipcore mailing list. Thanks to Vijay Gurbani for providing text about the relationship with the connect reuse specification.
このドキュメントの最初のドラフトバージョンに関するコメントについて、スタッフンブラウ、フランソワオーデット、ハドリエルカプラン、ショーンシュニー、ミロオルシックに感謝します。Juha Heinanen、Jiri Kuthan、Dean Willis、John Elwell、Paul Kyzivat、Peter Musgrave、Dale Worley、Adam Roach、およびRobert Sparksのコメントに感謝します。Connect Reuse仕様との関係についてテキストを提供してくれたVijay Gurbaniに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NATのセッショントラバーサルユーティリティ（STUN）」、RFC 5389、2008年10月。
[RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626] Jennings、C.、ed。、Mahy、R.、ed。、およびF. Audet、ed。、「セッション開始プロトコル（SIP）のクライアント開始接続の管理」、RFC 5626、2009年10月。
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[RFC3968] Camarillo、G。、「インターネットは、セッション開始プロトコル（SIP）の番号が割り当てられたヘッダーフィールドパラメーターレジストリ」、BCP 98、RFC 3968、2004年12月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、RFC 4347、2006年4月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[RFC5923] Gurbani, V., Ed., Mahy, R., and B. Tate, "Connection Reuse in the Session Initiation Protocol (SIP)", RFC 5923, June 2010.
[RFC5923] Gurbani、V.、Ed。、Mahy、R。、およびB. Tate、「セッション開始プロトコル（SIP）での接続再利用」、RFC 5923、2010年6月。
Author's Address
著者の連絡先
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: christer.holmberg@ericsson.com