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
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.
明示的にネットワークアドレス変換（NAT）の使用を交渉するために、隣接するSIPエンティティを可能にするこの仕様ヘッダフィールドパラメータで新しいセッション開始プロトコル（SIP）を定義し、「続ける」、SIPの場合、SIPアウトバウンドで定義されたキープアライブメカニズム、アウトバウンドは、サポートされていない適用できない、またはどこキープアライブの使用は、暗黙的にSIPアウトバウンドネゴシエーションの一部として交渉されていません。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6223.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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は、二つのキープアライブ機構を定義しています。キープアライブメカニズムはSIPアウトバウンド機構の残りの部分から分離されているにもかかわらず、SIPアウトバウンドは、明示的にキープアライブメカニズムの使用を交渉するためのメカニズムを定義していません。いくつかのケースでは、キープアライブの使用は、暗黙的に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アウトバウンドのみキープアライブユーザーエージェント（UA）とエッジプロキシの間ではなく、他のSIPエンティティ間で交渉することが可能になります。
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.
この仕様は、隣接するSIPエンティティが明示SIPアウトバウンドで定義されたNATキープアライブ機構の使用を交渉することを可能にする、「維持」、ヘッダフィールドパラメータで新しいセッション開始プロトコル（SIP）[RFC3261]を定義します。推奨キープアライブ周波数を提供するために - キープアライブを受信しようとSIPエンティティのために - 「キープ」パラメータは、SIPエンティティは、キープアライブを送信するためにキープアライブを受信する意欲を示すために、と意欲を示すことができます。
The following sections describe use-cases where a mechanism to explicitly negotiate usage of keep-alives is needed.
次のセクションでは、明示的にキープアライブの使用を交渉する仕組みが必要とされているユースケースを記述する。
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バインディングを維持するために、それはまだキープアライブの送信を交渉できるようにする必要がありますその隣接する下流の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]で指定されるように、キープアライブの使用は、暗黙的に、そのような流れのために交渉されていません。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
エッジプロキシ：RFC 5626で定義されているように、登録ユーザエージェント（UA）と権限のプロキシ間トポロジカルに配置されているSIPプロキシ。
NOTE: In some deployments, the edge proxy might be physically located in the same SIP entity as the Authoritative Proxy.
注：一部の展開では、エッジプロキシは、物理的に権威プロキシと同じSIPエンティティに存在する可能性があります。
Keep-alives: The keep-alive messages defined in RFC 5626.
キープアライブ：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.
明示的にキープアライブをその隣接する下流のSIPエンティティに向けて送信する意欲を示すために、SIPエンティティは、それが要求に追加することにViaヘッダーフィールド一番上に挿入できることをSIP Viaヘッダーフィールドパラメータ：パラメータを「キープ」。 SIPエンティティは、明示的にその隣接する上流のSIPエンティティからキープアライブを受信する意思を示すために応答して「続ける」パラメータにパラメータ値を追加することができます。
SIP entity: SIP User Agent (UA), or proxy, as defined in RFC 3261.
SIPエンティティ：SIPユーザエージェント（UA）、またはプロキシ、RFC 3261で定義されています。
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とプロキシは、登録やダイアログ、SIPリクエストの種類は、使用を交渉するために使用することができ、かつ、ネゴシエートキープアライブの寿命に関連したキープアライブの使用を交渉する方法を説明します。
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エンティティに向けてキープアライブを送信する意欲を示しています。関連する応答は、キープアライブを受信する意欲を示すために、SIPエンティティによって使用されています。キープアライブを受信する意欲を示しているSIPエンティティは、推奨キープアライブ周波数を提供することができます。
The procedures to negotiate usage of keep-alives are identical for SIP UAs and proxies.
キープアライブの使用を交渉するための手順は、SIP UAとプロキシのために同一です。
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エンティティが必要についての知識を持っている可能性があるため、一般的には、それは、便利です。隣接する上流のSIPエンティティがキープアライブを送信する意思を示した場合、SIPエンティティは、キープアライブを受信する意欲を示すようにするために同様に、それが送信する隣接する上流のSIPエンティティの任意の必要性を認識していない場合でも、有用であり得ますそれら。
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.
注：キープアライブの使用方法は、方向ごとに交渉されています。 SIPエンティティは、隣接するSIPエンティティからキープアライブを受信する意思を示した場合、その隣接したSIPエンティティに向かってキープアライブの送信は別々にネゴシエートする必要があります。
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エンティティは、それらを受信することができるように期待されている通り、この仕様は、ダブルCRLFの送信を禁止していませんキープアライブメッセージをそのSIPエンティティとキープアライブの使用が交渉されていない場合でも、隣接するSIPエンティティに向けて。しかし、「続ける」パラメータは、SIPエンティティは、それがキープアライブメッセージ、隣接する下流のSIPエンティティが他のメカニズム（例えば、短い登録リフレッシュを使用しないように二重CRLFの送信をサポートすることを示すようにするためには重要ですオープンNATバインディングを維持するために間隔）。
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エンティティは、登録に関連付けられているキープアライブの使用を交渉するために、登録要求を使用します。登録は、登録の際に、後に確立、またはされたときにキープアライブの使用法を交渉することができます。一度交渉し、後続の登録リフレッシュ要求を送信または転送されるまでの登録が終了し、またはされるまで、キープアライブが送信されます。その後の登録のリフレッシュ要求が送信または転送されたときにSIPエンティティは、登録に関連付けられたキープアライブ、キープアライブの使用を送信し続けても構わないと思っている場合、再交渉されなければなりません。使い方が正常に再交渉されていない場合は、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エンティティは、ダイアログに関連した送信と受信のキープアライブを交渉するためには、ダイアログの最初の要求、または、ダイアログ中のターゲットリフレッシュ要求[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で定義されているように、キープアライブの送信をサポートしているSIPエンティティは、NAT（STUN）クライアント[RFC5389]のためのセッショントラバーサルユーティリティとして行動しなければなりません。 SIPエンティティは、RFC 5626で定義されたSTUNキープアライブ機構を適用するために必要とされるSTUNのそれらの局面をサポートする必要があり、それはSTUNを使用する場合、RFC 5626、RFC 5626.に定義されてCRLFキープアライブ機構を定義サポートしなければならないとキープアライブのための二重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エンティティがリクエストを送信または転送するとき、それは登録またはダイアログに関連付けられたキープアライブの送信を交渉したい場合、それは、それが要求に追加する最上位のViaヘッダーフィールドに「キープ」パラメータを挿入しなければなりませんキープアライブを送信する意欲を示します。
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エンティティは、関連する応答を受信すると、応答の最上位のViaヘッダフィールドのパラメータを「維持」が「維持」のパラメータ値が含まれている場合、それは後続の要求を送信するのと同じ宛先に向けてキープアライブ送信を開始しなければなりません（キープアライブ交渉が登録されている場合）、または（キープアライブ交渉は、ダイアログ用の場合）ここで、それはそれ以降、ダイアログ中のリクエストを送信し、登録に関連付けられている（例えば、要求と対話のための最初の要求をREGISTER） 。その後の半ばダイアログの要求は、ダイアログのルートセットに基づいて対処しています。
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エンティティに向けた対話に関連付けられたキープアライブの送信を交渉していたら、それはその隣接するSIPエンティティに向けて、そのダイアログに関連付けられている任意のその後の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要求は、関連する応答を持っていないので、キープアライブの使用を交渉するために使用することはできません。そのため、SIPエンティティは、ACK要求の最上位Viaヘッダーフィールドに「キープ」パラメータを挿入してはなりません。受け取った場合には、このような「キープ」パラメータは、無視しなければなりません。
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].
また、ダイアログルートセット[RFC3261]にそれ自体を挿入していない限り、SIPエンティティは、ダイアログに関連付けられたキープアライブを送信する意欲を示してはいけません。
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エンティティは、Record-Routeヘッダフィールド[RFC3261]を使用して、ダイアログのルートセットに自身を挿入しない場合、隣接する下流側のSIPエンティティは、ダイアログ一度変更されルートセットが確立されています。 SIPエンティティは、ダイアログの最初の要求のViaヘッダーフィールドの最上位にある「続ける」パラメータを挿入し、パラメータの値が含まれていない関連する応答のパラメータを「キープ」した場合、SIPエンティティは、「挿入することを選択するかもしれませんキープアライブを受信する意思がある場合には、ダイアログで（ダイアログルートセットに基づいて）新しい隣接下流SIPエンティティに関連するその後のSIPリクエストのヘッダフィールドを介して「最上におけるパラメータを保つ（この場合には、追加します「続ける」パラメータにパラメータ値）。
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.
INVITE要求は、要求がパラメータ値とパラメータを「キープ」が含まINVITEにキープアライブを送信する意欲限り、少なくとも1つの応答（仮または最終）を示すために使用されている場合は、その指標として見られています隣接する下流側の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で定義されているように、キープアライブの受信をサポートしているSIPエンティティは、STUNサーバ[RFC5389]として行動しなければなりません。 SIPエンティティは、RFC 5626で定義されたSTUNのキープアライブメカニズムを適用するために必要とされているSTUNのそれらの局面をサポートする必要があり、それは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エンティティからダイアログに関連付けられたキープアライブを受信する意思がある場合は、キープアライブを送信する意思を示した場合、それは応答を送信または転送する前に、「キープ」パラメータにパラメータ値を追加する必要があります。パラメータ値は、存在する場合、ゼロ以外の値で、秒単位で与えられる推奨キープアライブ周波数を表します。
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.
INVITEリクエストに対する複数の応答があるかもしれません。 SIPエンティティは、INVITE要求に応答してキープアライブを受信する意思を示したときに、その要求に少なくとも一つの信頼できる応答して「続ける」パラメータにパラメータ値を追加しなければなりません。 SIPエンティティは、同じ要求に他の応答で「続ける」パラメータと同じパラメータ値を追加するかもしれません。 SIPエンティティは、同じ要求に応答して、「続ける」パラメータに異なるパラメータ値を追加してはなりません。 SIPエンティティは、できるだけ早くキープアライブを受信する意欲を示す必要があります。
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].
また、ダイアログルートセット[RFC3261]にそれ自体を挿入していない限り、SIPエンティティは、ダイアログに関連付けられたキープアライブを受信する意欲を示してはいけません。
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エンティティは秒単位で指定されたViaヘッダーフィールド最上推奨キープアライブ周波数を示す非ゼロ値を持つ「キープ」パラメータが含まれているSIP応答を、受信した場合、それはFlow-ために定義された手順を使用しなければなりませんタイマーヘッダーフィールド[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.
受信した「キープ」パラメータの値がゼロの場合、SIPエンティティは、その裁量でキープアライブを送信することができます。 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.
また、キープアライブを受信する意思を示すために「保持」パラメータにパラメータ値を加算するSIPエンティティは、フロータイマヘッダフィールドを挿入する場合、SIPエンティティは、送信機構とキープの両方を使用している場合（つまり、発生する可能性が同じSIPメッセージ内-alive機構）、ヘッダフィールド値と「維持」パラメータの値は同一でなければなりません。
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アウトバウンドサーバ推奨キープアライブ周波数を示すために、フロータイマヘッダフィールドを使用します。しかし、それだけでUAとエッジプロキシとの間で送信されます。一方、「キープ」パラメータを使用して、送信及びシグナリングパス上の複数のエンティティ間で交渉することができるのキープアライブを受信します。また、サーバ推奨キープアライブ周波数が異なる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.
キープアライブは、多くの場合、逆方向に送信されたSIP要求は、NATを通過し、同じ接続を再利用しますので、オープンNATバインディングを維持するために送信されます。非接続指向のトランスポートプロトコルの場合には、キープアライブを再利用するために同じパスを可能にします。この仕様は、このような接続の再利用メカニズムを定義していません。本明細書で定義されるキープアライブ機構のみ送信し、キープアライブの受信をネゴシエートするために使用されます。接続を再利用したいエンティティは、接続の再利用に関連するセキュリティ面を考慮していることを確認するために、別のメカニズムを使用する必要があります。
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で定義されたパラメータと、この仕様で定義された「続ける」パラメータ。
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.
このセクションでは、登録およびダイアログに関連付けられたキープアライブの使用は、異なる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.
注：例は、実際の構文要求ラインの符号化、応答線、およびViaヘッダフィールドではなく、メッセージタイプを識別し、またViaヘッダーフィールドSIPエンティティAが関連付けられている識別するための擬似コードを示していません。
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は、アリスがREGISTERリクエストを送信する例を示しています。彼女は、要求のViaヘッダーフィールドに「キープ」パラメータを挿入することにより、キープアライブを送信する意欲を示しています。エッジプロキシ（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は、関連する応答を受信するときに、それは30秒の推奨キープアライブ周波数を示す「キープ」パラメータ値を、加算し、アリスのViaヘッダフィールドを受信する意思があります、それはアリスへの応答を転送する前に。
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は、登録に関連付けられているキープアライブを受信しようとしている彼女のViaヘッダーフィールドから決定します。登録のいずれかの有効期限が切れるか、アリスは、登録更新要求を送信するまで、アリスは次いで、「キープ」パラメータ値が示す推奨キープアライブ周波数を用いて、P1に向かって（STUNキープアライブ技法を使用して、この例では）周期的なキープアライブを送信します。 。
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は、アリスがダイアログの初期INVITE要求を送信する例を示しています。彼女は、要求のViaヘッダーフィールドに「キープ」パラメータを挿入することにより、キープアライブを送信する意欲を示しています。エッジプロキシ（P1）は、ボブの方へ要求を転送する前に、Record-Routeヘッダフィールドに自分自身を追加することにより、設定ダイアログルートに自身を付加します。
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は、関連する応答を受信したときにそれが30秒の推奨キープアライブ頻度を示す「キープ」パラメータの値を加算し、アリスのViaヘッダーフィールドに受信していく所存です、それはアリスへの応答を転送する前に。
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は、ダイアログに関連付けられたキープアライブを受信しようとしている彼女のViaヘッダーフィールドから決定します。ダイアログの寿命のため、アリスは次いで、「キープ」パラメータ値が示す推奨キープアライブ周波数を用いて、P1に向かって（STUNキープアライブ技法を使用して、この例では）周期的なキープアライブを送信します。
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は、アリスがダイアログの初期INVITE要求を送信する例を示しています。彼女は、要求のViaヘッダーフィールドに「キープ」パラメータを挿入することにより、キープアライブを送信する意欲を示しています。ボブの方へ要求を転送する前に、このシナリオでは、エッジプロキシ（P1）は、Record-Routeヘッダフィールドに自分自身を追加しない（したがって、ダイアログルートセットに追加されません）。
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.
アリスは、応答を受信すると、彼女はP1が彼女からダイアログに関連付けられたキープアライブを受けることを望んでいないViaヘッダーフィールドから決定します。ダイアログのルートセットが確立されると、アリスは（P1、ダイアログルートセットに自身を挿入しませんでしたので）ボブに向けた中期ダイアログUPDATEリクエストを送信し、彼女は再び、「続ける」を挿入することによってキープアライブを送信するために意欲を示しています彼女の要求のViaヘッダーフィールドのパラメータ。ボブは、キープアライブメカニズムをサポートし、アリスからダイアログに関連付けられたキープアライブを受信しようとしているので、彼はに、応答を作成し、30秒の推奨キープアライブ頻度を示す「キープ」パラメータの値を加算し、彼はアリスへの応答を転送する前に、アリスのヴィアは、ヘッダーフィールド。
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.
アリスは、応答を受信すると、彼女はボブがダイアログに関連付けられたキープアライブを受信しようとしている彼女のViaヘッダーフィールドから決定します。ダイアログの寿命のため、アリスは次いで、「キープ」パラメータ値が示す推奨キープアライブ周波数を使用して、ボブに向かって（STUNキープアライブ技法を使用して、この例では）周期的なキープアライブを送信します。
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.
このセクションでは、「キープ」、新たなViaヘッダフィールドパラメータを追加することにより、ビアparamsは[RFC3261]からのABNFの定義を拡張します。本明細書で定義されたABNFは、RFC 5234 [RFC5234]に準拠しています。 「EQUAL」は、RFC 3261で定義されている「DIGITは、」RFC 5234で定義されています。
via-params =/ keep
ビアのparams = /維持
keep = "keep" [ EQUAL 1*(DIGIT) ]
キープ= "続ける" [EQUAL 1 *（DIGIT）]
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.
多くの場合、キープアライブ、トラバースのNATの送信者に向けて、要求は逆方向に送られたことを確実にするために、接続の再利用メカニズムを使用する必要がありますを送信したり、キープアライブを受信SIPエンティティ、などこの仕様は定義していません接続の再利用メカニズム、およびそれが接続の再利用に関連するセキュリティ問題に対処しません。接続を再利用したい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]を使用して、のman-in-the-middle使用Viaヘッダーフィールドを変更することができます2つのエンティティによって、または起因する追加のリソースの消費を誘発する可能性が非常に低い値にタイマ値を減少させることにより、キープアライブを送受信するために意欲を示すために使用される名称を除去することで、例えば、キープアライブの送信を交渉します頻繁にキープアライブを送りました。
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エンティティが送信する応答の最上位Viaヘッダーフィールド値にパラメータを「維持」に価値を置くために、この仕様で定義されたメカニズムを使用してSIPエンティティが必要です。彼らはすべての要求を転送し、それを「維持」パラメータに値を配置するエンティティを指示していません。具体的には、SIPプロキシは、それはそれを転送する前に受信要求の最上位のViaヘッダーフィールド値の「キープ」パラメータに値を配置してはならず。この仕様を実装するSIPプロキシはそれがそれらを転送する前に受信した応答の一番上の1以下のいずれかを介してヘッダーフィールド値に任意の「維持」のパラメータ値を削除する必要があります。
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ヘッダフィールドの未収値を改ざんすることが可能です。悪質なSIPエンティティは、値を置くかのViaヘッダーフィールド値のいずれかで「続ける」パラメータで既存の値を変更することができます - だけではなく、一番上の値。単に一番上のViaヘッダフィールド値を除去し、そのような悪影響悪意のある下流SIPエンティティによって影響を受けたヘッダフィールド値のリスクを介して得られた新たな最上位を検査しないことによって、応答を転送するプロキシ実装。特に、このようなプロキシは、それは盲目的にそれが最上位のViaヘッダーフィールドに作成していない値を持つ「続ける」パラメータを使用して応答を転送する場合は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エンティティは、隣接する下流のSIPエンティティにSTUNキープアライブを送信し、7.2.1項で説明したように（これらのSTUNメッセージに対する応答を受信しない場合に、このようなプロキシへの悪影響を持つ悪意のある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]でキープアライブに指定したものに加えて、セキュリティ上の考慮事項を導入しません。
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.
このドキュメントの最初のドラフト版に彼らのコメントのためのStaffanブラウ、フランソワAudet、Hadrielカプラン、ショーンSchneyer、そしてミロOrsicに感謝します。 sipcoreメーリングリスト上の彼らのコメントのためのユハHeinanen、智異Kuthan、ディーンウィリス、ジョンエルウェル、ポールKyzivat、ピーター・マスグレイブ、デイル・ウォーリー、アダムローチ、そしてロバート・スパークスに感謝します。接続の再利用の仕様との関係についてのテキストを提供するためのビジェイGurbaniに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
"構文仕様のための増大しているBNF：ABNF" [RFC5234]クロッカー、D.、エド、およびP. Overell、。、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]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "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]ジェニングス、C.、エド。、マーイ、R.、エド。、およびF. Audet、エド。、RFC 5626、2009年10月 "セッション開始プロトコル（SIP）におけるクライアント開始された接続の管理"。
[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]キャマリロ、G.、BCP 98、RFC 3968、2004年12月 "インターネットは、セッション開始プロトコル（SIP）のための番号機関（IANA）ヘッダーフィールドパラメータレジストリを割り当てられました"。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティ"、RFC 4347、2006年4月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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.、編、マーイ、R.、およびB.テート、 "セッション開始プロトコル（SIP）における接続の再利用"、RFC 5923、2010年6月。
Author's Address
著者のアドレス
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
クリステルHolmbergのエリクソンHirsalantie 11 02420 Jorvasフィンランド
EMail: christer.holmberg@ericsson.com
メールアドレス：christer.holmberg@ericsson.com