Network Working Group S. Donovan
Request for Comments: 4028 J. Rosenberg
Category: Standards Track Cisco Systems
April 2005
Session Timers in the Session Initiation Protocol (SIP)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントでは、インターネットコミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めています。 このプロトコルの標準化状態とステータスについては、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。 このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document defines an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine whether the SIP session is still active. The extension defines two new header fields: Session-Expires, which conveys the lifetime of the session, and Min-SE, which conveys the minimum allowed value for the session timer.
このドキュメントでは、セッション開始プロトコル（SIP）の拡張機能を定義しています。 この拡張機能により、re-INVITEまたはUPDATE要求を介してSIPセッションを定期的に更新できます。 更新により、ユーザーエージェントとプロキシの両方が、SIPセッションがまだアクティブかどうかを判断できます。 この拡張機能では、セッションの有効期間を伝えるSession-Expiresと、セッションタイマーの最小許容値を伝えるMin-SEという2つの新しいヘッダーフィールドを定義しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . 4
4. Session-Expires Header Field Definition . . . . . . . . . . 6
5. Min-SE Header Field Definition . . . . . . . . . . . . . . . 8
6. 422 Response Code Definition . . . . . . . . . . . . . . . . 8
7. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Generating an Initial Session Refresh Request . . . . 9
7.2. Processing a 2xx Response . . . . . . . . . . . . . . 9
7.3. Processing a 422 Response . . . . . . . . . . . . . . 11
7.4. Generating Subsequent Session Refresh Requests . . . . 11
8. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Processing of Requests . . . . . . . . . . . . . . . . 13
8.2. Processing of Responses . . . . . . . . . . . . . . . 14
8.3. Session Expiration . . . . . . . . . . . . . . . . . . 15
9. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Performing Refreshes . . . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . 18
11.1. Inside Attacks . . . . . . . . . . . . . . . . . . . . 18
11.2. Outside Attacks . . . . . . . . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
12.1. IANA Registration of Min-SE and Session-Expires
Header Fields . . . . . . . . . . . . . . . . . . . . 19
12.2. IANA Registration of the 422 (Session Interval Too
Small) Response Code . . . . . . . . . . . . . . . . . 20
12.3. IANA Registration of the 'timer' Option Tag . . . . . 20
13. Example Call Flow . . . . . . . . . . . . . . . . . . . . . 20
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
15.1. Normative References . . . . . . . . . . . . . . . . . 25
15.2. Informative References . . . . . . . . . . . . . . . . 26
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 27
The Session Initiation Protocol (SIP) [2] does not define a keepalive mechanism for the sessions it establishes. Although the user agents may be able to determine whether the session has timed out by using session specific mechanisms, proxies will not be able to do so. The result is that call stateful proxies will not always be able to determine whether a session is still active. For instance, when a user agent fails to send a BYE message at the end of a session, or when the BYE message gets lost due to network problems, a call stateful proxy will not know when the session has ended. In this situation, the call stateful proxy will retain state for the call and has no method to determine when the call state information no longer applies.
Session Initiation Protocol（SIP）[2]は、確立するセッションのキープアライブメカニズムを定義しません。 ユーザーエージェントは、セッション固有のメカニズムを使用してセッションがタイムアウトしたかどうかを判断できる場合がありますが、プロキシはそうすることはできません。 その結果、コールステートフルプロキシは、セッションがまだアクティブかどうかを常に判断できるとは限りません。 たとえば、ユーザーエージェントがセッションの終了時にBYEメッセージの送信に失敗した場合、またはネットワークの問題が原因でBYEメッセージが失われた場合、コールステートフルプロキシはセッションの終了を認識しません。 この状況では、コールステートフルプロキシはコールの状態を保持し、コール状態情報がいつ適用されなくなるかを判断する方法がありません。
To resolve this problem, this extension defines a keepalive mechanism for SIP sessions. UAs send periodic re-INVITE or UPDATE [3] requests (referred to as session refresh requests) to keep the session alive. The interval for the session refresh requests is determined through a negotiation mechanism defined here. If a session refresh request is not received before the interval passes, the session is considered terminated. Both UAs are supposed to send a BYE, and call stateful proxies can remove any state for the call.
この問題を解決するために、この拡張機能はSIPセッションのキープアライブメカニズムを定義します。 UAは、セッションを維持するために、定期的なre-INVITEまたはUPDATE [3]要求（セッション更新要求と呼ばれる）を送信します。 セッションリフレッシュリクエストの間隔は、ここで定義されているネゴシエーションメカニズムによって決定されます。 間隔が経過する前にセッションリフレッシュリクエストを受信しなかった場合、セッションは終了したと見なされます。 両方のUAはBYEを送信することになっており、コールステートフルプロキシはコールの状態を削除できます。
This refresh mechanism has additional applications. A user agent would like to determine whether the session is still active for the same reasons a call stateful proxy server would. This determination can be made at a user agent without the use of SIP level mechanisms; for audio sessions, periodic RTCP packets serve as an indication of liveness [5]. However, it is desirable to separate indications of SIP session liveness from the details of the particular session.
この更新メカニズムには追加のアプリケーションがあります。 ユーザーエージェントは、ステートフルプロキシサーバーを呼び出すのと同じ理由で、セッションがまだアクティブであるかどうかを判断します。 この決定は、SIPレベルのメカニズムを使用せずにユーザーエージェントで行うことができます。 オーディオセッションの場合、定期的なRTCPパケットは活性の指標として機能します[5]。 ただし、特定のセッションの詳細からSIPセッションの活性の表示を分離することが望ましい。
Another application of the session timer is in the construction of a SIP Network Address Translator (NAT) Application Level Gateway (ALG) [6]. The ALG embedded in a NAT will need to maintain state for the duration of a call. This state must eventually be removed. Relying on a BYE to trigger the removal of state, besides being unreliable, introduces a potential denial of service attack.
セッションタイマーの別のアプリケーションは、SIPネットワークアドレス変換（NAT）アプリケーションレベルゲートウェイ（ALG）[6]の構築です。 NATに組み込まれたALGは、通話中に状態を維持する必要があります。 この状態は最終的に削除する必要があります。 信頼性が低いことに加えて、状態の削除をトリガーするためにBYEに依存すると、潜在的なサービス拒否攻撃が発生します。
This document provides an extension to SIP that defines a session expiration mechanism. Periodic refreshes, through re-INVITEs or UPDATEs, are used to keep the session active. The extension is sufficiently backward compatible with SIP that it works as long as either one of the two participants in a dialog understands the extension. Two new header fields (Session-Expires and Min-SE) and a new response code (422) are defined. Session-Expires conveys the duration of the session, and Min-SE conveys the minimum allowed value for the session expiration. The 422 response code indicates that the session timer duration was too small.
このドキュメントは、セッションの有効期限メカニズムを定義するSIPの拡張機能を提供します。 re-INVITEまたはUPDATEによる定期的な更新は、セッションをアクティブに保つために使用されます。 拡張機能はSIPと十分に下位互換性があるため、ダイアログの2人の参加者のいずれかが拡張機能を理解する限り機能します。 2つの新しいヘッダーフィールド（Session-ExpiresおよびMin-SE）と新しい応答コード（422）が定義されています。 Session-Expiresはセッションの継続時間を伝え、Min-SEはセッションの有効期限の最小許容値を伝えます。 422応答コードは、セッションタイマーの期間が短すぎることを示しています。
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 [1] and indicate requirement levels for compliant SIP implementations.
このドキュメントでは、キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」 RFC 2119 [1]で説明されているように解釈され、準拠するSIP実装の要件レベルを示します。
Additionally, we define the following terms:
さらに、次の用語を定義します。
Session Interval: The maximum amount of time that can occur between session refresh requests in a dialog before the session will be considered timed out. The session interval is conveyed in the Session-Expires header field, which is defined here. The UAS obtains this value from the Session-Expires header field in a 2xx response to a session refresh request that it sends. Proxies and UACs determine this value from the Session-Expires header field in a 2xx response to a session refresh request that they receive.
セッション間隔：セッションがタイムアウトしたと見なされるまでの、ダイアログ内のセッション更新要求の間に発生する可能性がある最大時間。 セッション間隔は、ここで定義されているSession-Expiresヘッダーフィールドで伝達されます。 UASは、送信するセッションリフレッシュ要求に対する2xx応答のSession-Expiresヘッダーフィールドからこの値を取得します。 プロキシとUACは、受信したセッション更新要求に対する2xx応答のSession-Expiresヘッダーフィールドからこの値を決定します。
Minimum Timer: Because of the processing load of mid-dialog requests, all elements (proxy, UAC, UAS) can have a configured minimum value for the session interval that they are willing to accept. This value is called the minimum timer.
最小タイマー：中間ダイアログリクエストの処理負荷のために、すべての要素（プロキシ、UAC、UAS）は、受け入れたいセッション間隔の最小値を設定できます。 この値は、最小タイマーと呼ばれます。
Session Expiration: The time at which an element will consider the session timed out, if no successful session refresh transaction occurs beforehand.
セッションの有効期限：事前にセッションリフレッシュトランザクションが成功しなかった場合に、要素がセッションをタイムアウトと見なす時間。
Session Refresh Request: An INVITE or UPDATE request processed according to the rules of this specification. If the request generates a 2xx response, the session expiration is increased to the current time plus the session interval obtained from the response. A session refresh request is not to be confused with a target refresh request, defined in Section 6 of [2], which is a request that can update the remote target of a dialog.
セッションリフレッシュリクエスト：この仕様のルールに従って処理されたINVITEまたはUPDATEリクエスト。 要求が2xx応答を生成する場合、セッションの有効期限は、現在の時間に応答から取得したセッション間隔を加えた値に増加します。 セッションリフレッシュリクエストは、ダイアログのリモートターゲットを更新できるリクエストである[2]のセクション6で定義されているターゲットリフレッシュリクエストと混同しないでください。
Initial Session Refresh Request: The first session refresh request sent with a particular Call-ID value.
初期セッションリフレッシュリクエスト：特定のCall-ID値で送信される最初のセッションリフレッシュリクエスト。
Subsequent Session Refresh Request: Any session refresh request sent with a particular Call-ID after the initial session refresh request.
後続のセッションリフレッシュリクエスト：最初のセッションリフレッシュリクエストの後に特定のCall-IDで送信されたセッションリフレッシュリクエスト。
Refresh: Same as a session refresh request.
更新：セッション更新要求と同じです。
This section provides a brief overview of the operation of the extension. It is tutorial in nature and should not be considered normative.
このセクションでは、拡張機能の操作の概要を簡単に説明します。 それは本質的にチュートリアルであり、規範と見なされるべきではありません。
This extension has the property that it works even when only one UA in a dialog supports it. The processing steps differ for handling each of the four cases (the UAC does or doesn't support it, and the UAS does or doesn't support it). For simplicity's sake, this section will describe basic operation in the case where both sides support the extension.
この拡張機能には、ダイアログ内の1つのUAのみがサポートする場合でも機能するという特性があります。 4つのケースのそれぞれを処理するための処理手順は異なります（UACはサポートするかどうか、UASはサポートするかしないか）。 簡単にするために、このセクションでは、両側が拡張機能をサポートする場合の基本的な操作について説明します。
A UAC starts by sending an INVITE. This includes a Supported header field with the option tag 'timer', indicating support for this extension.
UACは、INVITEを送信することから始まります。 これには、この拡張機能のサポートを示すオプションタグ 'timer'を持つサポートヘッダーフィールドが含まれます。
This request passes through proxies, any one of which may have an interest in establishing a session timer. Each proxy can insert a Session-Expires header field and a Min-SE header field into the request (if none is already there) or alter the value of existing Session-Expires and Min-SE header fields as described below.
この要求はプロキシを通過します。プロキシのいずれかがセッションタイマーの確立に関心を持っている可能性があります。 各プロキシは、Session-ExpiresヘッダーフィールドとMin-SEヘッダーフィールドをリクエストに挿入するか（存在しない場合）、既存のSession-ExpiresおよびMin-SEヘッダーフィールドの値を以下に説明するように変更できます。
The Min-SE header field establishes the lower bound for the session refresh interval; i.e., the fastest rate any proxy servicing this request will be allowed to require. The purpose of this header field is to prevent hostile proxies from setting arbitrarily short refresh intervals so that their neighbors are overloaded. Each proxy processing the request can raise this lower bound (increase the period between refreshes) but is not allowed to lower it.
Min-SEヘッダーフィールドは、セッションリフレッシュ間隔の下限を確立します。 つまり、このリクエストを処理するプロキシが要求する最速のレートです。 このヘッダーフィールドの目的は、悪意のあるプロキシが任意の短い更新間隔を設定して、隣接するノードが過負荷になるのを防ぐことです。 要求を処理する各プロキシは、この下限を引き上げることができます（更新間の間隔を長くします）が、下げることはできません。
The Session-Expires header field establishes the upper bound for the session refresh interval; i.e., the time period after processing a request for which any session-stateful proxy must retain its state for this session. Any proxy servicing this request can lower this value, but it is not allowed to decrease it below the value specified in the Min-SE header field.
Session-Expiresヘッダーフィールドは、セッションリフレッシュ間隔の上限を確立します。 つまり、セッションステートフルプロキシがこのセッションの状態を保持する必要がある要求を処理した後の期間。 このリクエストにサービスを提供するプロキシは、この値を下げることができますが、Min-SEヘッダーフィールドで指定された値以下に減らすことはできません。
If the Session-Expires interval is too low for a proxy (i.e., lower than the value of Min-SE that the proxy would wish to assert), the proxy rejects the request with a 422 response. That response contains a Min-SE header field identifying the minimum session interval it is willing to support. The UAC will try again, this time including the Min-SE header field in the request. The header field contains the largest Min-SE header field it observed in all 422 responses previously received. This way, the minimum timer meets the constraints of all proxies along the path.
Session-Expires間隔がプロキシに対して低すぎる（つまり、プロキシがアサートしたいMin-SEの値よりも低い）場合、プロキシは422応答でリクエストを拒否します。 その応答には、サポートする最小セッション間隔を識別するMin-SEヘッダーフィールドが含まれます。 UACは再試行しますが、今回はリクエストにMin-SEヘッダーフィールドを含めます。 ヘッダーフィールドには、以前に受信したすべての422応答で観測された最大のMin-SEヘッダーフィールドが含まれています。 このようにして、最小タイマーはパスに沿ったすべてのプロキシの制約を満たします。
After several INVITE/422 iterations, the request eventually arrives at the UAS. The UAS can adjust the value of the session interval as if it were a proxy; when done, it places the final session interval into the Session-Expires header field in a 2xx response. The Session-Expires header field also contains a 'refresher' parameter, which indicates who is doing the refreshing -- the UA that is currently the UAC, or the UA that is currently the UAS. As the 2xx response travels back through the proxy chain, each proxy can observe the final session interval but can't change it.
INVITE / 422を数回繰り返した後、要求は最終的にUASに到着します。 UASは、プロキシのようにセッション間隔の値を調整できます。 完了すると、2xx応答のSession-Expiresヘッダーフィールドに最終セッション間隔が配置されます。 Session-Expiresヘッダーフィールドには、「refresher」パラメータも含まれます。これは、誰が更新を行っているかを示します。現在のUACであるUA、または現在のUASであるUAです。 2xx応答がプロキシチェーンを介して戻ると、各プロキシは最終セッション間隔を監視できますが、変更することはできません。
From the Session-Expires header field in the response, both UAs know that a session timer is active, when it will expire, and who is refreshing. At some point before the expiration, the currently active refresher generates a session refresh request, which is a re-INVITE or UPDATE [3] request. If the refresher never gets a response to that session refresh request, it sends a BYE to terminate the session. Similarly, if the other side never gets the session refresh request before the session expires, it sends a BYE.
応答のSession-Expiresヘッダーフィールドから、両方のUAは、セッションタイマーがアクティブであること、有効期限がいつ切れるか、誰が更新しているかを認識します。 有効期限が切れる前のある時点で、現在アクティブなリフレッシャーがセッションリフレッシュリクエストを生成します。これはre-INVITEまたはUPDATE [3]リクエストです。 リフレッシャがそのセッションリフレッシュリクエストに対する応答を取得しない場合、BYEを送信してセッションを終了します。 同様に、セッションの有効期限が切れる前に相手側がセッションリフレッシュリクエストを取得しない場合、BYEを送信します。
The refresh requests sent once the session is established are processed identically to the initial requests, as described above. This means that a successful session refresh request will extend the session, as desired.
前述のように、セッションが確立されると送信される更新リクエストは、最初のリクエストと同様に処理されます。 これは、セッションリフレッシュリクエストが成功すると、必要に応じてセッションが延長されることを意味します。
The extension introduces additional complications beyond this basic flow to support cases where only one of the UAs supports it. One such complication is that a proxy may need to insert the Session-Expires header field into the response, in the event that the UAS doesn't support the extension. The negotiation of the role of refresher is also affected by this capability; it takes into consideration which participants support the extension.
拡張機能は、この基本的なフローを超えて追加の複雑さを導入して、UAの1つだけがそれをサポートする場合をサポートします。 そのような複雑さの1つは、UASが拡張機能をサポートしていない場合、プロキシがSession-Expiresヘッダーフィールドを応答に挿入する必要がある場合があることです。 リフレッシャーの役割のネゴシエーションもこの機能の影響を受けます。 どの参加者が拡張機能をサポートするかを考慮します。
Note that the session timer refreshes the session, not the dialog used to establish the session. Of course, the two are related. If the session expires, a BYE is sent, which terminates the session and, generally, the dialog.
セッションを確立するために使用されるダイアログではなく、セッションタイマーがセッションを更新することに注意してください。 もちろん、この2つは関連しています。 セッションの有効期限が切れると、BYEが送信され、セッションと、通常はダイアログが終了します。
The Session-Expires header field conveys the session interval for a SIP session. It is placed only in INVITE or UPDATE requests, as well as in any 2xx response to an INVITE or UPDATE. Like the SIP Expires header field, it contains a delta-time.
Session-Expiresヘッダーフィールドは、SIPセッションのセッション間隔を伝えます。 INVITEまたはUPDATE要求、およびINVITEまたはUPDATEへの2xx応答にのみ配置されます。 SIP Expiresヘッダーフィールドと同様に、デルタ時間が含まれています。
The absolute minimum for the Session-Expires header field is 90 seconds. This value represents a bit more than twice the duration that a SIP transaction can take in the event of a timeout. This allows sufficient time for a UA to attempt a refresh at the halfpoint of the session interval, and for that transaction to complete normally before the session expires. However, 1800 seconds (30 minutes) is RECOMMENDED as the value for the Session-Expires header field. In other words, SIP entities MUST be prepared to handle Session-Expires header field values of any duration greater than 90 seconds, but entities that insert the Session-Expires header field SHOULD NOT choose values of less than 30 minutes.
Session-Expiresヘッダーフィールドの絶対最小値は90秒です。 この値は、タイムアウトが発生した場合にSIPトランザクションが取ることができる期間の2倍を少し上回ります。 これにより、セッション間隔の中間点でUAがリフレッシュを試行し、そのトランザクションがセッションの有効期限が切れる前に正常に完了するのに十分な時間を確保できます。 ただし、Session-Expiresヘッダーフィールドの値として1800秒（30分）が推奨されます。 言い換えれば、SIPエンティティは、90秒を超える期間のSession-Expiresヘッダーフィールド値を処理する準備をしなければなりませんが、Session-Expiresヘッダーフィールドを挿入するエンティティは、30分未満の値を選択すべきではありません。
Small session intervals can be destructive to the network. They cause excessive messaging traffic that affects both user agents and proxy servers. They increase the possibility of 'glare' that can occur when both user agents send a re-INVITE or UPDATE at the same time. Since the primary purpose of the session timer is to provide a means to time out state in SIP elements, very small values won't generally be needed. 30 minutes was chosen because 95% of phone calls are shorter than this duration. However, the 30 minute minimum is listed as a SHOULD, and not as a MUST, since the exact value for this number is dependent on many network factors, including network bandwidths and latencies, computing power, memory availability, network topology, and, of course, the application scenario. After all, SIP can set up any kind of session, not just a phone call. At the time of publication of this document, 30 minutes seems appropriate. Advances in technologies may result in the number being excessively large five years in the future.
短いセッション間隔は、ネットワークを破壊する可能性があります。これらは、ユーザーエージェントとプロキシサーバーの両方に影響を与える過度のメッセージングトラフィックを引き起こします。これらは、両方のユーザーエージェントがre-INVITEまたはUPDATEを同時に送信するときに発生する「グレア」の可能性を高めます。セッションタイマーの主な目的は、SIP要素の状態をタイムアウトする手段を提供することであるため、通常、非常に小さな値は必要ありません。電話の95％がこの時間より短いため、30分が選択されました。ただし、この数値の正確な値は、ネットワーク帯域幅と待機時間、計算能力、メモリの可用性、ネットワークトポロジなどの多くのネットワーク要素に依存するため、30分以上は必須としてではなく、SHOULDとしてリストされています。もちろん、アプリケーションのシナリオ。結局のところ、SIPは電話だけでなく、あらゆる種類のセッションをセットアップできます。このドキュメントの公開時点では、30分が適切と思われます。技術の進歩により、今後5年で数が過度に大きくなる可能性があります。
The default value of the Session-Expires header field is undefined. This means that the absence of the Session-Expires header field implies no expiration of the session, using the mechanism defined in this specification. Note that other mechanisms not defined in this specification, such as locally configured timers, may apply.
Session-Expiresヘッダーフィールドのデフォルト値は未定義です。 これは、この仕様で定義されたメカニズムを使用して、Session-Expiresヘッダーフィールドがないことはセッションの有効期限がないことを意味することを意味します。 ローカルに設定されたタイマーなど、この仕様で定義されていない他のメカニズムが適用される場合があることに注意してください。
The syntax of the Session-Expires header field is as follows:
Session-Expiresヘッダーフィールドの構文は次のとおりです。
Session-Expires = ("Session-Expires" / "x") HCOLON delta-seconds *(SEMI se-params) se-params = refresher-param / generic-param refresher-param = "refresher" EQUAL ("uas" / "uac")
Session-Expires =（ "Session-Expires" / "x"）HCOLON delta-seconds *（SEMI se-params）se-params = refresher-param / generic-param refresher-param = "refresher" EQUAL（ "uas" / 「uac」）
Note that a compact form, the letter x, has been reserved for Session-Expires. The BNF for delta-seconds and generic-param is defined in Section 25 of RFC 3261 [2].
Session-Expiresには、コンパクトなフォームである文字xが予約されています。 デルタ秒とgeneric-paramのBNFは、RFC 3261 [2]のセクション25で定義されています。
Table 1 is an extension of Tables 2 and 3 in [2] for the Session-Expires and Min-SE header fields. The column 'PRA' is for the PRACK method [7], 'UPD' is for the UPDATE method [3], 'SUB' is for the SUBSCRIBE method [8], and 'NOT' is for the NOTIFY method [8].
表1は、[2]のSession-ExpiresおよびMin-SEヘッダーフィールドの表2および3の拡張です。 列 'PRA'はPRACKメソッド[7]、 'UPD'はUPDATEメソッド[3]、 'SUB'はSUBSCRIBEメソッド[8]、および 'NOT'はNOTIFYメソッド[8]です。 。
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
| Header |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT|
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
|Session-Expires| R | amr | - | - | - | o | - | - | - | o | - | - |
| | | | | | | | | | | | | |
|Session-Expires| 2xx | ar | - | - | - | o | - | - | - | o | - | - |
| | | | | | | | | | | | | |
|Min-SE | R | amr | - | - | - | o | - | - | - | o | - | - |
| | | | | | | | | | | | | |
|Min-SE | 422 | | - | - | - | m | - | - | - | m | - | - |
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
Table 1: Session-Expires and Min-SE Header Fields
表1：Session-ExpiresおよびMin-SEヘッダーフィールド
The Min-SE header field indicates the minimum value for the session interval, in units of delta-seconds. When used in an INVITE or UPDATE request, it indicates the smallest value of the session interval that can be used for that session. When present in a request or response, its value MUST NOT be less than 90 seconds.
Min-SEヘッダーフィールドは、セッション間隔の最小値をデルタ秒単位で示します。 INVITEまたはUPDATEリクエストで使用される場合、そのセッションで使用できるセッション間隔の最小値を示します。 要求または応答に存在する場合、その値は90秒未満であってはなりません。
When the header field is not present, its default value for is 90 seconds.
ヘッダーフィールドが存在しない場合、デフォルト値は90秒です。
The Min-SE header field MUST NOT be used in responses except for those with a 422 response code. It indicates the minimum value of the session interval that the server is willing to accept.
Min-SEヘッダーフィールドは、422応答コードを持つものを除き、応答で使用してはなりません（MUST NOT）。 サーバーが受け入れ可能なセッション間隔の最小値を示します。
The syntax of the Min-SE header field is as follows:
Min-SEヘッダーフィールドの構文は次のとおりです。
Min-SE = "Min-SE" HCOLON delta-seconds *(SEMI generic-param)
Min-SE = "Min-SE" HCOLONデルタ秒*（SEMI generic-param）
This extension introduces the 422 (Session Interval Too Small) response code. It is generated by a UAS or proxy when a request contains a Session-Expires header field with a duration below the minimum timer for the server. The 422 response MUST contain a Min-SE header field with the minimum timer for that server.
この拡張機能は、422（セッション間隔が小さすぎる）応答コードを導入します。 要求が、サーバーの最小タイマーよりも短い期間のSession-Expiresヘッダーフィールドを含む場合、UASまたはプロキシによって生成されます。 422応答には、そのサーバーの最小タイマーを持つMin-SEヘッダーフィールドが含まれている必要があります。
A UAC that supports the session timer extension defined here MUST include a Supported header field in each request (except ACK), listing the option tag 'timer' [2]. It MUST do so even if the UAC is not requesting usage of the session timer for this session.
ここで定義されたセッションタイマー拡張をサポートするUACは、各リクエスト（ACKを除く）にオプションヘッダー 'timer' [2]をリストするSupportedヘッダーフィールドを含める必要があります。 UACがこのセッションのセッションタイマーの使用を要求していない場合でも、そうする必要があります。
The UAC MAY include a Require header field in the request with the value 'timer' to indicate that the UAS must support the session timer to participate in the session. This does not mean that the UAC is requiring the UAS to perform the refreshes, only that it is requiring the UAS to support the extension. In addition, the UAC MAY include a Proxy-Require header field in the request with the value 'timer' to indicate that proxies must support the session timer in order to correctly process the request. However, usage of either Require or Proxy-Require by the UAC is NOT RECOMMENDED. They are not needed, since the extension works even when only the UAC supports the extension. The Supported header field containing 'timer' MUST still be included, even if the Require or Proxy-Require header fields are present containing 'timer'.
UACは、UASがセッションに参加するためにセッションタイマーをサポートする必要があることを示すために、値 'timer'で要求ヘッダーフィールドを含めることができます。 これは、UACが更新を実行することをUASに要求していることを意味するのではなく、拡張をサポートすることをUASに要求していることだけを意味します。 さらに、UACは、リクエストにProxy-Requireヘッダーフィールドを値「timer」とともに含めて、リクエストを正しく処理するためにプロキシがセッションタイマーをサポートする必要があることを示すことができます。 ただし、UACによるRequireまたはProxy-Requireの使用は推奨されません。 UACのみが拡張機能をサポートしている場合でも拡張機能が動作するため、これらは必要ありません。 'timer'を含むRequireまたはProxy-Requireヘッダーフィールドが存在する場合でも、 'timer'を含むサポートヘッダーフィールドを含める必要があります。
A UAC MAY include the Min-SE header field in the initial INVITE request.
UACは、最初のINVITE要求にMin-SEヘッダーフィールドを含めることができます。
A UAC MAY include a Session-Expires header field in an initial session refresh request if it wants a session timer applied to the session. The value of this header field indicates the session interval desired by the UAC. If a Min-SE header is included in the initial session refresh request, the value of the Session-Expires MUST be greater than or equal to the value in Min-SE.
UACは、セッションタイマーをセッションに適用したい場合、最初のセッションリフレッシュ要求にSession-Expiresヘッダーフィールドを含めることができます。 このヘッダーフィールドの値は、UACが希望するセッション間隔を示します。 Min-SEヘッダーが初期セッションリフレッシュリクエストに含まれる場合、Session-Expiresの値はMin-SEの値以上でなければなりません。
The UAC MAY include the refresher parameter with value 'uac' if it wants to perform the refreshes. However, it is RECOMMENDED that the parameter be omitted so that it can be selected by the negotiation mechanisms described below.
UACは、更新を実行する場合、値 'uac'の更新パラメーターを含めることができます。 ただし、以下で説明するネゴシエーションメカニズムで選択できるように、パラメータを省略することをお勧めします。
The session timer requires a UA to create and maintain state. This state includes the session interval, the session expiration, and the identity of the refresher. This state is associated with the dialog on which the session has been negotiated.
セッションタイマーでは、UAが状態を作成および維持する必要があります。 この状態には、セッション間隔、セッションの有効期限、およびリフレッシャーのIDが含まれます。 この状態は、セッションがネゴシエートされたダイアログに関連付けられています。
When a 2xx response to a session refresh request arrives, it may or may not contain a Require header field with the value 'timer'. If it does, the UAC MUST look for the Session-Expires header field to process the response.
セッションリフレッシュリクエストに対する2xx応答が到着すると、値「timer」のRequireヘッダーフィールドが含まれている場合と含まれていない場合があります。 存在する場合、UACはSession-Expiresヘッダーフィールドを探して応答を処理する必要があります。
If there was a Require header field in the response with the value 'timer', the Session-Expires header field will always be present. UACs MUST be prepared to receive a Session-Expires header field in a response, even if none were present in the request. The 'refresher' parameter will be present in the Session-Expires header field, indicating who will perform the refreshes. The UAC MUST set the identity of the refresher to the value of this parameter. If the parameter contains the value 'uac', the UAC will perform them. It is possible that the UAC requested the session timer (and thus included a Session-Expires header field in the request) and that there was no Require or Session-Expires header field in the 2xx response. This will happen when the UAS doesn't support the session timer extension and only the UAC has asked for a session timer (no proxies have requested it). In this case, if the UAC still wishes to use the session timer (which is purely for its benefit alone), it has to perform them. To do this, the UAC follows the procedures defined in this specification as if the Session-Expires header field were in the 2xx response, and its value was the same as that in the request, but with a refresher parameter of 'uac'.
応答に値 'timer'を持つRequireヘッダーフィールドがあった場合、Session-Expiresヘッダーフィールドは常に存在します。 UACは、リクエストに何も存在していなくても、応答でSession-Expiresヘッダーフィールドを受信する準備をする必要があります。 'refresher'パラメーターはSession-Expiresヘッダーフィールドに存在し、だれが更新を実行するかを示します。 UACは、リフレッシャーのIDをこのパラメーターの値に設定する必要があります。パラメーターに値 'uac'が含まれている場合、UACはそれらを実行します。 UACがセッションタイマーを要求し（したがって、要求にSession-Expiresヘッダーフィールドを含めた）、2xx応答にRequireまたはSession-Expiresヘッダーフィールドがなかった可能性があります。これは、UASがセッションタイマー拡張をサポートせず、UACのみがセッションタイマーを要求した場合に発生します（プロキシは要求しませんでした）。この場合、UACがセッションタイマー（純粋に利益だけのため）を使用したい場合は、それらを実行する必要があります。これを行うために、UACは、Session-Expiresヘッダーフィールドが2xx応答にあるかのように、この仕様で定義された手順に従います。その値は、リクエストの値と同じでしたが、リフレッシャーパラメーターは 'uac'です。
If the 2xx response did not contain a Session-Expires header field, there is no session expiration. In this case, no refreshes need to be sent. A 2xx without a Session-Expires can come for both initial and subsequent session refresh requests. This means that the session timer can be 'turned-off' in mid dialog by receiving a response without a Session-Expires header field.
2xx応答にSession-Expiresヘッダーフィールドが含まれていない場合、セッションの有効期限はありません。 この場合、更新を送信する必要はありません。 Session-Expiresのない2xxは、初期および後続のセッションリフレッシュリクエストの両方に対応できます。 これは、Session-Expiresヘッダーフィールドなしで応答を受信することにより、ダイアログ中にセッションタイマーを「オフ」にできることを意味します。
The UAC remembers the session interval for a session as the value of the delta-time from the Session-Expires header field in the most recent 2xx response to a session refresh request on a dialog. It is explicitly allowed for there to be differing session intervals (or none at all) on differing dialogs established as a result of a single INVITE. The UAC also remembers whether it or its peer is the refresher on for the session.
UACは、セッションのセッション間隔を、ダイアログのセッションリフレッシュリクエストに対する最新の2xx応答のSession-Expiresヘッダーフィールドからのデルタ時間の値として記憶します。 単一のINVITEの結果として確立された異なるダイアログ上で、異なるセッション間隔（またはまったくない）が明示的に許可されます。 UACは、セッションのリフレッシャーが自分自身またはそのピアであるかどうかも記憶します。
If the UAC must perform the refreshes, it computes the session expiration for that session. The session expiration is the time of reception of the last 2xx response to a session refresh request on that dialog plus the session interval for that session. If the UA seeks to continue with the session beyond the session expiration, it MUST generate a refresh before the session expiration. It is
UACが更新を実行する必要がある場合、UACはそのセッションのセッション有効期限を計算します。 セッションの有効期限は、そのダイアログでのセッションリフレッシュリクエストに対する最後の2xx応答の受信時間と、そのセッションのセッション間隔です。 UAがセッションの有効期限を超えてセッションを継続しようとする場合、セッションの有効期限が切れる前に更新を生成する必要があります。 それは
RECOMMENDED that this refresh be sent once half the session interval has elapsed. Additional procedures for this refresh are described in Section 10.
セッション間隔の半分が経過したら、この更新を送信することをお勧めします。 この更新の追加手順については、セクション10で説明します。
Similarly, a re-INVITE or UPDATE request sent within a dialog for purposes other than session refreshes will also have the effect of refreshing the session, and its processing will follow the procedures defined in this specification.
同様に、セッションリフレッシュ以外の目的でダイアログ内で送信されたre-INVITEまたはUPDATE要求もセッションをリフレッシュする効果があり、その処理はこの仕様で定義された手順に従います。
If the response to a session refresh request is a 422 (Session Interval Too Small) response message, then the UAC MAY retry the request. The procedures for retrying are described in Section 7.4. This new request constitutes a new transaction and SHOULD have the same value as the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous.
セッション更新要求への応答が422（セッション間隔が小さすぎる）応答メッセージである場合、UACは要求を再試行する場合があります。 再試行の手順については、セクション7.4で説明します。 この新しい要求は新しいトランザクションを構成し、前の要求のCall-ID、To、およびFromと同じ値を持つ必要がありますが、CSeqには前よりも1つ大きい新しいシーケンス番号を含める必要があります。
The values of Supported, Require, and Proxy-Require used in the initial Session refresh request MUST be used.
最初のセッション更新要求で使用される、Supported、Require、およびProxy-Requireの値を使用する必要があります。
The UAC MUST insert the Min-SE header field into a session refresh request for a particular dialog if it has ever received a 422 response to a previous session refresh request on the same dialog, or if it has received a session refresh request on that dialog that contained a Min-SE header field. Similarly, if no dialog has been established yet, a UAC MUST insert the Min-SE header field into an INVITE request if it has ever received a 422 response to a previous INVITE request with the same Call-ID.
UACは、同じダイアログで以前のセッション更新要求に対する422応答を受信した場合、またはそのダイアログでセッション更新要求を受信した場合、特定のダイアログのセッション更新要求にMin-SEヘッダーフィールドを挿入する必要があります。 Min-SEヘッダーフィールドが含まれていました。 同様に、ダイアログがまだ確立されていない場合、同じCall-IDを持つ以前のINVITE要求に対する422応答を受け取った場合、UACはMin-SEヘッダーフィールドをINVITE要求に挿入する必要があります。
The value of the Min-SE header field present in a session refresh request MUST be the largest value among all Min-SE header field values returned in all 422 responses or received in session refresh requests, on the same dialog, if a dialog has been established. If no dialog has been established, the Min-SE header field value is set to the largest value among all Min-SE header field values returned in all 422 responses for an INVITE request with the same Call-ID. A result of this rule is that the maximum value of the Min-SE is effectively 'cleared' once the dialog is established, and from that point on, only the values from proxies known to be on the proxy path will end up being used.
セッションリフレッシュリクエストに存在するMin-SEヘッダーフィールドの値は、すべての422応答で返される、または同じダイアログでセッションリフレッシュリクエストで受信されるすべてのMin-SEヘッダーフィールド値の中で最大値でなければなりません。 設立。 ダイアログが確立されていない場合、Min-SEヘッダーフィールド値は、同じCall-IDを持つINVITEリクエストのすべての422応答で返されるすべてのMin-SEヘッダーフィールド値の中で最大値に設定されます。 この規則の結果、ダイアログが確立されるとMin-SEの最大値が事実上「クリア」され、それ以降はプロキシパス上にあることがわかっているプロキシからの値のみが使用されます。
The UAC may have its own opinions about the minimum session interval. In that case, if the value above is too small, the UAC MAY increase it.
UACは、最小セッション間隔について独自の意見を持っている場合があります。 その場合、上記の値が小さすぎると、UACはそれを増やすことができます。
In a session refresh request sent within a dialog with an active session timer, the Session-Expires header field SHOULD be present. When present, it SHOULD be equal to the maximum of the Min-SE header field (recall that its default value when not present is 90 seconds) and the current session interval. Inclusion of the Session-Expires header field with this value avoids certain denial-of-service attacks, as documented in Section 11. As such, a UA should only ignore the SHOULD in unusual and singular cases where it is desirable to change the session interval mid-dialog.
アクティブなセッションタイマーを使用してダイアログ内で送信されるセッションリフレッシュリクエストには、Session-Expiresヘッダーフィールドが存在する必要があります。 存在する場合、Min-SEヘッダーフィールドの最大値（存在しない場合のデフォルト値は90秒であることを思い出してください）と現在のセッション間隔に等しくする必要があります。 この値にSession-Expiresヘッダーフィールドを含めると、セクション11で文書化されているように、特定のサービス拒否攻撃を回避できます。したがって、UAは、セッション間隔を変更することが望ましい異常で特異な場合にのみSHOULDを無視する必要があります 中間ダイアログ。
If the session refresh request is not the initial one, it is RECOMMENDED that the refresher parameter be set to 'uac' if the element sending the request is currently performing refreshes, and to 'uas' if its peer is performing the refreshes. This way, the role of refresher does not change on each refresh. However, if it wishes to explicitly change the roles, it MAY use a value of 'uas' if it knows that the other side supports the session timer. It could know this by having received a request from its peer with a Supported header field containing the value 'timer'. If it seeks to reselect the roles, it MAY omit the parameter.
セッションリフレッシュリクエストが最初のリクエストではない場合、リクエストを送信する要素が現在リフレッシュを実行している場合、refresherパラメータを「uac」に設定し、ピアがリフレッシュを実行している場合は「uas」に設定することをお勧めします。 このように、更新の役割は更新ごとに変わりません。 ただし、役割を明示的に変更する場合、相手側がセッションタイマーをサポートしていることがわかっている場合は、「uas」の値を使用できます。 値 'timer'を含むSupportedヘッダーフィールドを持つピアからリクエストを受信することにより、これを知ることができます。 ロールを再選択しようとする場合、パラメータを省略してもよい[MAY]。
A re-INVITE generated to refresh the session is a normal re-INVITE, and an UPDATE generated to refresh a session is a normal UPDATE. If a UAC knows that its peer supports the UPDATE method, it is RECOMMENDED that UPDATE be used instead of a re-INVITE. A UA can make this determination if it has seen an Allow header field from its peer with the value 'UPDATE', or through a mid-dialog OPTIONS request. It is RECOMMENDED that the UPDATE request not contain an offer [4], but a re-INVITE SHOULD contain one, even if the details of the session have not changed. In that case, the offer MUST indicate that it has not changed. In the case of SDP, this is accomplished by including the same value for the origin field as did previous SDP messages to its peer. The same is true for an answer exchanged as a result of a session refresh request; if it has not changed, that MUST be indicated.
セッションをリフレッシュするために生成されたre-INVITEは通常のre-INVITEであり、セッションをリフレッシュするために生成されたUPDATEは通常のUPDATEです。 UACがそのピアがUPDATEメソッドをサポートしていることを知っている場合、再招待の代わりにUPDATEを使用することをお勧めします。 UAは、値が「UPDATE」のピアからAllowヘッダーフィールドを見た場合、またはダイアログ中のOPTIONS要求を介してこの決定を行うことができます。 セッションの詳細が変更されていない場合でも、UPDATE要求にはオファー[4]が含まれないことをお勧めしますが、re-INVITEにはオファーが含まれる必要があります。 その場合、オファーは変更されていないことを示さなければなりません。 SDPの場合、これは、ピアへの以前のSDPメッセージと同じように、起点フィールドに同じ値を含めることによって実現されます。 セッションリフレッシュリクエストの結果として交換される回答についても同様です。 変更されていない場合は、それを示さなければなりません。
Session timers are mostly of interest to call stateful proxy servers (that is, to servers that maintain the state of calls and dialogs established through them). However, a stateful proxy server (that is, a server which is aware of transaction state but does not retain call or dialog state) MAY also follow the rules described here. Stateless proxies MUST NOT attempt to request session timers. Proxies that ask for session timers SHOULD record-route, as they won't receive refreshes if they don't.
セッションタイマーは、ステートフルプロキシサーバー（つまり、それらを介して確立された呼び出しとダイアログの状態を維持するサーバー）を呼び出すために最も重要です。 ただし、ステートフルプロキシサーバー（つまり、トランザクションの状態は認識しているが、呼び出しまたはダイアログの状態を保持していないサーバー）も、ここで説明する規則に従う場合があります。 ステートレスプロキシは、セッションタイマーを要求しないでください。 セッションタイマーを要求するプロキシは、更新しない場合は更新を受信しないため、レコードルートを記録する必要があります。
The proxy processing rules require the proxy to remember information between the request and response, ruling out stateless proxies.
プロキシ処理ルールでは、プロキシはリクエストとレスポンスの間の情報を記憶し、ステートレスプロキシを排除する必要があります。
Processing of requests is identical for all session refresh requests.
リクエストの処理は、すべてのセッション更新リクエストで同じです。
To request a session timer for a session, a proxy makes sure that a Session-Expires header field is present in a session refresh request for that session. A proxy MAY insert a Session-Expires header field in the request before forwarding it if none was present in the request. This Session-Expires header field may contain any desired expiration time the proxy would like, but not with a duration lower than the value in the Min-SE header field in the request, if it is present. The proxy MUST NOT include a refresher parameter in the header field value.
セッションのセッションタイマーを要求するために、プロキシは、そのセッションのセッション更新要求にSession-Expiresヘッダーフィールドが存在することを確認します。 プロキシは、リクエストにSession-Expiresヘッダーフィールドが挿入されていない場合、リクエストを転送する前にリクエストに挿入することができます。 このSession-Expiresヘッダーフィールドには、プロキシが希望する任意の有効期限を含めることができますが、リクエストのMin-SEヘッダーフィールドの値よりも短い期間ではありません。 プロキシは、ヘッダーフィールドの値に更新パラメータを含めてはいけません。
If the request already had a Session-Expires header field, the proxy MAY reduce its value but MUST NOT set it to a duration lower than the value in the Min-SE header field in the request, if it is present. If the value of the Session-Expires header field is greater than or equal to the value in the Min-SE header field (recall that the default is 90 seconds when the Min-SE header field is not present), the proxy MUST NOT increase the value of the Session-Expires header field. If the value of the Session-Expires header field is lower than the value of the Min-SE header field (possibly because the proxy increased the value of the Min-SE header field, as described below), the proxy MUST increase the value of the Session-Expires header field to make it equal to Min-SE header field value. The proxy MUST NOT insert or modify the value of the 'refresher' parameter in the Session-Expires header field.
リクエストに既にSession-Expiresヘッダーフィールドがある場合、プロキシはその値を減らすことができますが、リクエストのMin-SEヘッダーフィールドの値（存在する場合）よりも短い期間に設定してはなりません。 Session-Expiresヘッダーフィールドの値がMin-SEヘッダーフィールドの値以上である場合（Min-SEヘッダーフィールドが存在しない場合のデフォルトは90秒であることを思い出してください）、プロキシは増加してはなりません Session-Expiresヘッダーフィールドの値。 Session-Expiresヘッダーフィールドの値がMin-SEヘッダーフィールドの値よりも低い場合（おそらく、以下で説明するようにプロキシがMin-SEヘッダーフィールドの値を増やしたため）、プロキシは Session-ExpiresヘッダーフィールドをMin-SEヘッダーフィールド値と等しくなるようにします。 プロキシは、Session-Expiresヘッダーフィールドの「refresher」パラメータの値を挿入または変更してはなりません。
If the request contains a Supported header field with a value 'timer', the proxy MAY reject the INVITE request with a 422 (Session Interval Too Small) response if the session interval in the Session-Expires header field is smaller than the minimum interval defined by the proxy's local policy. When sending the 422 response, the proxy MUST include a Min-SE header field with the value of its minimum interval. That minimum MUST NOT be lower than 90 seconds.
要求に値 'timer'のサポートされたヘッダーフィールドが含まれる場合、Session-Expiresヘッダーフィールドのセッション間隔が定義された最小間隔より小さい場合、プロキシは422（セッション間隔が小さすぎる）応答でINVITE要求を拒否する場合があります プロキシのローカルポリシーによって。 422応答を送信する場合、プロキシは最小間隔の値を持つMin-SEヘッダーフィールドを含める必要があります。 その最小値は90秒未満であってはなりません。
If the request doesn't indicate support for the session timer but contains a session interval that is too small, the proxy cannot usefully reject the request, as this would result in a call failure. Rather, the proxy SHOULD insert a Min-SE header field containing its minimum interval. If a Min-SE header field is already present, the proxy SHOULD increase (but MUST NOT decrease) the value to its minimum interval. The proxy MUST then increase the Session-Expires header field value to be equal to the value in the Min-SE header field, as described above. A proxy MUST NOT insert a Min-SE header field or modify the value of an existing header field in a proxied request if that request contains a Supported header field with the value 'timer'. This is needed to protect against certain denial of service attacks, described in Section 11.
リクエストがセッションタイマーのサポートを示していないが、セッション間隔が短すぎる場合、プロキシはリクエストを拒否することができません。これは、呼び出しが失敗するためです。 むしろ、プロキシは、最小間隔を含むMin-SEヘッダーフィールドを挿入する必要があります。 Min-SEヘッダーフィールドが既に存在する場合、プロキシは値を最小間隔まで増加させる必要があります（ただし、減少してはなりません）。 次に、プロキシは、前述のように、Session-Expiresヘッダーフィールドの値をMin-SEヘッダーフィールドの値と等しくなるように増加する必要があります。 プロキシは、リクエストに値「timer」のサポートされたヘッダーフィールドが含まれている場合、プロキシされたリクエストのMin-SEヘッダーフィールドを挿入したり、既存のヘッダーフィールドの値を変更してはなりません。 これは、セクション11で説明されている特定のサービス拒否攻撃から保護するために必要です。
Assuming that the proxy has requested a session timer (and thus has possibly inserted the Session-Expires header field or reduced it), the proxy MUST remember that it is using a session timer, and also remember the value of the Session-Expires header field from the proxied request. This MUST be remembered for the duration of the transaction.
プロキシがセッションタイマーを要求した（したがって、おそらくSession-Expiresヘッダーフィールドを挿入または縮小した）と仮定すると、プロキシは、セッションタイマーを使用していることを覚えておく必要があり、Session-Expiresヘッダーフィールドの値も覚えている必要があります プロキシされたリクエストから。 これは、トランザクションの期間中は覚えておく必要があります。
The proxy MUST remember, for the duration of the transaction, whether the request contained the Supported header field with the value 'timer'. If the request did not contain a Supported header field with the value 'timer', the proxy MAY insert a Require header field with the value 'timer' into the request. However, this is NOT RECOMMENDED. This allows the proxy to insist on a session timer for the session. This header field is not needed if a Supported header field was in the request; in this case, the proxy would already be sure the session timer can be used for the session.
プロキシは、トランザクションの期間中、リクエストに値「timer」を持つSupportedヘッダーフィールドが含まれていたかどうかを覚えていなければなりません。 リクエストに値「timer」のSupportedヘッダーフィールドが含まれていない場合、プロキシは値「timer」のRequireヘッダーフィールドをリクエストに挿入できます。 ただし、これは推奨されません。 これにより、プロキシはセッションのセッションタイマーを要求できます。 サポートされているヘッダーフィールドがリクエストに含まれていた場合、このヘッダーフィールドは不要です。 この場合、プロキシはすでにセッションタイマーをセッションに使用できることを確認しています。
When the final response to the request arrives, it is examined by the proxy.
要求に対する最終応答が到着すると、プロキシによって検査されます。
If the response does not contain a Session-Expires header field but the proxy remembers that it requested a session timer in the request (by inserting, modifying, or examining and accepting the Session-Expires header field in the proxied request), this means that the UAS did not support the session timer. If the proxy remembers that the UAC did not support the session timer either, the proxy forwards the response upstream normally. There is no session expiration for this session. If, however, the proxy remembers that the UAC did support the session timer, additional processing is needed.
応答にSession-Expiresヘッダーフィールドが含まれていないが、プロキシがリクエストでセッションタイマーをリクエストしたことを覚えている場合（プロキシされたリクエストでSession-Expiresヘッダーフィールドを挿入、変更、または調査して受け入れる）、これは UASはセッションタイマーをサポートしていませんでした。 UACがセッションタイマーもサポートしていないことをプロキシが記憶している場合、プロキシは通常どおり応答をアップストリームに転送します。 このセッションにはセッションの有効期限はありません。 ただし、UACがセッションタイマーをサポートしていたことをプロキシが記憶している場合は、追加の処理が必要です。
Because there is no Session-Expires or Require header field in the response, the proxy knows that it is the first session-timer-aware proxy to receive the response. This proxy MUST insert a Session-Expires header field into the response with the value it remembered from the forwarded request. It MUST set the value of the 'refresher' parameter to 'uac'. The proxy MUST add the 'timer' option tag to any Require header field in the response, and if none was present, add the Require header field with that value before forwarding it upstream.
応答にはSession-ExpiresまたはRequireヘッダーフィールドがないため、プロキシは、それが応答を受信する最初のセッションタイマー対応プロキシであることを認識しています。 このプロキシは、転送された要求から記憶された値を含むSession-Expiresヘッダーフィールドを応答に挿入する必要があります。 「refresher」パラメーターの値を「uac」に設定する必要があります。 プロキシは、応答のRequireヘッダーフィールドに「timer」オプションタグを追加する必要があります。存在しない場合、アップストリームに転送する前に、その値を持つRequireヘッダーフィールドを追加します。
If the received response contains a Session-Expires header field, no modification of the response is needed.
受信した応答にSession-Expiresヘッダーフィールドが含まれる場合、応答を変更する必要はありません。
In all cases, if the 2xx response forwarded upstream by the proxy contains a Session-Expires header field, its value represents the session interval for the session associated with that response. The proxy computes the session expiration as the time when the 2xx response is forwarded upstream, plus the session interval. This session expiration MUST update any existing session expiration for the session. The refresher parameter in the Session-Expires header field in the 2xx response forwarded upstream will be present, and it indicates which UA is performing the refreshes. There can be multiple 2xx responses to a single INVITE, each representing a different dialog, resulting in multiple session expirations, one for each session associated with each dialog.
すべての場合において、プロキシによってアップストリームに転送された2xx応答にSession-Expiresヘッダーフィールドが含まれている場合、その値はその応答に関連付けられたセッションのセッション間隔を表します。 プロキシは、セッションの有効期限を、2xx応答がアップストリームに転送される時間にセッション間隔を加えたものとして計算します。 このセッションの有効期限は、セッションの既存のセッションの有効期限を更新しなければなりません。 アップストリームに転送された2xx応答のSession-Expiresヘッダーフィールドにrefresherパラメーターが存在し、どのUAが更新を実行しているかを示します。 単一のINVITEに対する複数の2xx応答があり、それぞれ異なるダイアログを表し、各ダイアログに関連付けられたセッションごとに複数のセッションの有効期限が切れます。
The proxy MUST NOT modify the value of the Session-Expires header field received in the response (assuming one was present) before forwarding it upstream.
プロキシは、応答で受信したSession-Expiresヘッダーフィールドの値を変更してはなりません（1つが存在すると仮定して）。
When the current time equals or passes the session expiration for a session, the proxy MAY remove associated call state, and MAY free any resources associated with the call. Unlike the UA, it MUST NOT send a BYE.
現在の時間がセッションのセッション有効期限と等しいか、セッションの有効期限を過ぎると、プロキシは関連するコール状態を削除し、そのコールに関連するリソースを解放することができます。 UAとは異なり、BYEを送信してはなりません。
The UAS must respond to a request for a session timer by the UAC or a proxy in the path of the request, or it may request that a session timer be used itself.
UASは、UACまたは要求のパス内のプロキシによるセッションタイマーの要求に応答する必要があります。そうでない場合、セッションタイマーの使用を要求する場合があります。
If an incoming request contains a Supported header field with a value 'timer' and a Session Expires header field, the UAS MAY reject the INVITE request with a 422 (Session Interval Too Small) response if the session interval in the Session-Expires header field is smaller than the minimum interval defined by the UAS' local policy. When sending the 422 response, the UAS MUST include a Min-SE header field with the value of its minimum interval. This minimum interval MUST NOT be lower than 90 seconds.
着信要求に、値「タイマー」とSession Expiresヘッダーフィールドを持つサポートヘッダーフィールドが含まれる場合、UASは、Session-Expiresヘッダーフィールドのセッション間隔が UASのローカルポリシーで定義されている最小間隔よりも小さい。 422応答を送信するとき、UASは最小間隔の値を持つMin-SEヘッダーフィールドを含めなければなりません。 この最小間隔は、90秒未満であってはなりません。
If the UAS wishes to accept the request, it copies the value of the Session-Expires header field from the request into the 2xx response.
UASが要求を受け入れる場合、Session-Expiresヘッダーフィールドの値を要求から2xx応答にコピーします。
The UAS response MAY reduce its value but MUST NOT set it to a duration lower than the value in the Min-SE header field in the request, if it is present; otherwise the UAS MAY reduce its value but MUST NOT set it to a duration lower than 90 seconds. The UAS MUST NOT increase the value of the Session-Expires header field.
UAS応答はその値を減らすことができますが、要求のMin-SEヘッダーフィールドの値（存在する場合）よりも短い期間に設定してはなりません（MUST NOT）。 それ以外の場合、UASはその値を減らすことができますが、90秒よりも短い期間に設定してはなりません。 UASは、Session-Expiresヘッダーフィールドの値を増やしてはなりません。
If the incoming request contains a Supported header field with a value 'timer' but does not contain a Session-Expires header, it means that the UAS is indicating support for timers but is not requesting one. The UAS may request a session timer in the 2XX response by including a Session-Expires header field. The value MUST NOT be set to a duration lower than the value in the Min-SE header field in the request, if it is present.
着信要求に値 'timer'のSupportedヘッダーフィールドが含まれているがSession-Expiresヘッダーが含まれていない場合、UASはタイマーのサポートを示しているが要求していないことを意味します。 UASは、Session-Expiresヘッダーフィールドを含めることにより、2XX応答でセッションタイマーを要求できます。 値が存在する場合、要求のMin-SEヘッダーフィールドの値よりも短い期間に値を設定しないでください。
The UAS MUST set the value of the refresher parameter in the Session-Expires header field in the 2xx response. This value specifies who will perform refreshes for the dialog. The value is based on the value of this parameter in the request, and on whether the UAC supports the session timer extension. The UAC supports the extension if the 'timer' option tag was present in a Supported header field in the request. Table 2 defines how the value in the response is set. A value of 'none' in the 2nd column means that there was no refresher parameter in the request. A value of 'NA' in the third column means that this particular combination shouldn't happen, as it is disallowed by the protocol.
UASは、2xx応答のSession-Expiresヘッダーフィールドに更新パラメータの値を設定する必要があります。 この値は、ダイアログの更新を実行するユーザーを指定します。 値は、要求内のこのパラメーターの値、およびUACがセッションタイマー拡張をサポートしているかどうかに基づいています。 要求の[サポートされているヘッダーフィールドに 'timer'オプションタグが存在する場合、UACは拡張機能をサポートします。 表2は、応答の値の設定方法を定義しています。 2列目の「なし」の値は、リクエストに更新パラメータがなかったことを意味します。 3番目の列の「NA」の値は、この特定の組み合わせがプロトコルによって許可されていないため、この特定の組み合わせが発生しないことを意味します。
UAC supports? refresher parameter refresher parameter
in request in response
-------------------------------------------------------
N none uas
N uac NA
N uas NA
Y none uas or uac
Y uac uac
Y uas uas
Table 2: UAS Behavior
表2：UASの動作
The fourth row of Table 2 describes a case where both the UAC and UAS support the session timer extension, and where the UAC did not select who will perform refreshes. This allows the UAS to decide whether it or the UAC will perform the refreshes. However, as the table indicates, the UAS cannot override the UAC's choice of refresher, if it made one.
表2の4行目は、UACとUASの両方がセッションタイマー拡張をサポートし、UACが更新を実行するユーザーを選択しなかった場合を示しています。 これにより、UASは、UASまたはUACが更新を実行するかどうかを決定できます。 ただし、表が示すように、UASは、UACが選択したリフレッシャーを上書きすることはできません。
If the refresher parameter in the Session-Expires header field in the 2xx response has a value of 'uac', the UAS MUST place a Require header field into the response with the value 'timer'. This is because the uac is performing refreshes and the response has to be processed for the UAC to know this. If the refresher parameter in the 2xx response has a value of 'uas' and the Supported header field in the request contained the value 'timer', the UAS SHOULD place a Require header field into the response with the value 'timer'. In this case, the UAC is not refreshing, but it is supposed to send a BYE if it never receives a refresh. Since the call will still succeed without the UAC sending a BYE, insertion of the Require is a SHOULD here, and not a MUST.
2xx応答のSession-Expiresヘッダーフィールドの更新パラメータの値が「uac」の場合、UASは値「timer」の応答にRequireヘッダーフィールドを配置する必要があります。 これは、UACが更新を実行しており、UACがこれを知るために応答を処理する必要があるためです。 2xx応答のリフレッシャーパラメーターの値が「uas」であり、要求のサポートされているヘッダーフィールドに値「timer」が含まれている場合、UASは値「timer」の応答にRequireヘッダーフィールドを配置する必要があります。 この場合、UACは更新されていませんが、更新を受信しない場合はBYEを送信することになっています。 UACがBYEを送信しなくても呼び出しは成功するため、Requireの挿入はここではSHOULDであり、MUSTではありません。
Just like the UAC, the UAS stores state for the session timer. This state includes the session interval, the session expiration, and the identity of the refresher. This state is bound to the dialog used to set up the session. The session interval is set to the value of the delta-time from the Session-Expires header field in the most recent 2xx response to a session refresh request on that dialog. It also remembers whether it or its peer is the refresher on the dialog, based on the value of the refresher parameter from the most recent 2xx response to a session refresh request on that dialog. If the most recent 2xx response had no Session-Expires header field, there is no session expiration, and no refreshes have to be performed.
UACと同様に、UASはセッションタイマーの状態を保存します。 この状態には、セッション間隔、セッションの有効期限、およびリフレッシャーのIDが含まれます。 この状態は、セッションのセットアップに使用されるダイアログにバインドされています。 セッション間隔は、そのダイアログのセッション更新要求に対する最新の2xx応答のSession-Expiresヘッダーフィールドからのデルタ時間の値に設定されます。 また、そのダイアログのセッションリフレッシュリクエストに対する最新の2xx応答からのリフレッシャーパラメーターの値に基づいて、ピアまたはそのピアがダイアログのリフレッシャーであるかどうかを記憶します。 最新の2xx応答にSession-Expiresヘッダーフィールドがない場合、セッションの有効期限はなく、更新を実行する必要はありません。
If the UAS must refresh the session, it computes the session expiration. The session expiration is the time of transmission of the last 2xx response to a session refresh request on that dialog plus the session interval. If UA wishes to continue with the session beyond the session expiration, it MUST generate a refresh before the session expiration. It is RECOMMENDED that this refresh be sent once half the session interval has elapsed. Additional procedures for this refresh are described in Section 10.
UASがセッションを更新する必要がある場合、セッションの有効期限を計算します。 セッションの有効期限は、そのダイアログでのセッションリフレッシュリクエストに対する最後の2xx応答の送信時間とセッション間隔です。 UAがセッションの有効期限を超えてセッションを続行したい場合、セッションの有効期限が切れる前にリフレッシュを生成しなければなりません。 セッション間隔の半分が経過したら、この更新を送信することをお勧めします。 この更新の追加手順については、セクション10で説明します。
The side generating a refresh does so according to the UAC procedures defined in Section 7. Note that only a 2xx response to a session refresh request extends the session expiration. This means that a UA could attempt a refresh and receive a 422 response with a Min-SE header field that contains a value much larger than the current session interval. The UA will still have to send a session refresh request before the session expiration (which has not changed), even though this request will contain a value of the Session-Expires that is much larger than the current session interval.
更新を生成する側は、セクション7で定義されているUAC手順に従ってそうします。セッション更新要求に対する2xx応答のみがセッションの有効期限を延長することに注意してください。 これは、UAがリフレッシュを試行し、現在のセッション間隔よりもはるかに大きい値を含むMin-SEヘッダーフィールドを持つ422応答を受信できることを意味します。 UAは、現在のセッション間隔よりもはるかに大きいSession-Expiresの値がこの要求に含まれている場合でも、セッションの有効期限（変更されていない）の前にセッション更新要求を送信する必要があります。
If the session refresh request transaction times out or generates a 408 or 481 response, then the UAC sends a BYE request as per Section 12.2.1.2 of RFC 3261 [2]. If the session refresh request does not generate a 2xx response (and, as a result, the session is not refreshed), and a response other than 408 or 481 is received, the UAC
セッションリフレッシュ要求トランザクションがタイムアウトするか、408または481応答を生成する場合、UACはRFC 3261 [2]のセクション12.2.1.2に従ってBYE要求を送信します。 セッション更新要求が2xx応答を生成せず（その結果、セッションが更新されない）、408または481以外の応答が受信される場合、UAC
SHOULD follow the rules specific to that response code and retry if possible. For example, if the response is a 401, the UAC would retry the request with new credentials. However, the UAC SHOULD NOT continuously retry the request if the server indicates the same error response.
その応答コードに固有のルールに従い、可能であれば再試行する必要があります。 たとえば、応答が401の場合、UACは新しい資格情報で要求を再試行します。 ただし、サーバーが同じエラー応答を示した場合、UACは要求を継続的に再試行するべきではありません。
Similarly, if the side not performing refreshes does not receive a session refresh request before the session expiration, it SHOULD send a BYE to terminate the session, slightly before the session expiration. The minimum of 32 seconds and one third of the session interval is RECOMMENDED.
同様に、リフレッシュを実行していない側がセッションの有効期限が切れる前にセッションリフレッシュリクエストを受信しない場合、セッションの有効期限が切れる少し前に、BYEを送信してセッションを終了する必要があります。 最小の32秒とセッション間隔の3分の1が推奨されます。
Firewalls and NAT ALGs may be very unforgiving about allowing SIP traffic to pass after the expiration time of the session. This is why the BYE should be sent before the expiration.
ファイアウォールとNAT ALGは、セッションの有効期限が切れた後、SIPトラフィックの通過を許可することについて非常に寛容かもしれません。 これが、期限が切れる前にBYEを送信する必要がある理由です。
The session timer introduces the capability of a proxy or UA element to force compliant UAs to send refreshes at a rate of the element's choosing. This introduces the possibility of denial-of-service attacks with significant amplification properties. These attacks can be launched from 'outsiders' (elements that attempt to modify messages in transit) or by 'insiders' (elements that are legitimately in the request path but are intent on doing harm). Fortunately, both cases are adequately handled by this specification.
セッションタイマーは、プロキシまたはUA要素の機能を導入して、準拠したUAが要素の選択したレートでリフレッシュを送信するように強制します。 これにより、重大な増幅特性を持つサービス拒否攻撃の可能性が生じます。 これらの攻撃は、「外部」（送信中のメッセージを変更しようとする要素）から、または「インサイダー」（要求パスに正当に存在するが危害を加えようとする要素）によって開始できます。 幸いなことに、両方のケースはこの仕様で適切に処理されます。
This introduces the possibility of rogue proxies or UAs introducing denial-of-service attacks. However, the mechanisms in this specification prevent that from happening.
これにより、不正なプロキシまたはUAがDoS攻撃を導入する可能性が生じます。 ただし、この仕様のメカニズムにより、このようなことが起こりません。
First, consider the case of a rogue UAC that wishes to force a UAS to generate refreshes at a rapid rate. To do so, it inserts a Session-Expires header field into an INVITE with a low duration and a refresher parameter equal to uas. Assume it places a Supported header field into the request. The UAS or any proxy that objects to this low timer will reject the request with a 422, thereby preventing the attack. If no Supported header field was present, the proxies will insert a Min-SE header field into the request before forwarding it. As a result, the UAS will not choose a session timer lower than the minimum allowed by all elements on the path. This too prevents the attack.
最初に、UASに更新を高速で強制的に生成させようとする不正なUACの場合を考えます。 これを行うために、Session-Expiresヘッダーフィールドを、短い継続時間とuasに等しいリフレッシャーパラメーターでINVITEに挿入します。 サポートされているヘッダーフィールドをリクエストに配置するとします。 UASまたはこの低タイマーに反対するプロキシは、422で要求を拒否し、攻撃を防ぎます。 サポートされているヘッダーフィールドが存在しない場合、プロキシはリクエストを転送する前にMin-SEヘッダーフィールドをリクエストに挿入します。 その結果、UASは、パス上のすべての要素で許可される最小値よりも低いセッションタイマーを選択しません。 これも攻撃を防ぎます。
Next, consider the case of a rogue UAS that wishes to force a UAC to generate refreshes at a rapid rate. In that case, the UAC has to support session timer. The initial INVITE arrives at the rogue UAS, which returns a 2xx with a very small session interval. The UAC uses this timer and quickly sends a refresh. Section 7.4 requires that the UAC copy the current session interval into the Session-Expires header field in the request. This enables the proxies to see the current value. The proxies will reject this request and provide a Min-SE with a higher minimum, which the UAC will then use. Note, that if the proxies did not reject the request, but rather proxied the request with a Min-SE header field, an attack would still be possible. The UAS could discard this header field in a 2xx response and force the UAC to continue to generate rapid requests.
次に、UACに更新を高速で強制的に生成させようとする不正なUASの場合を考えます。 その場合、UACはセッションタイマーをサポートする必要があります。 最初のINVITEは不正なUASに到着し、非常に短いセッション間隔で2xxを返します。 UACはこのタイマーを使用し、すぐに更新を送信します。 セクション7.4では、UACが現在のセッション間隔をリクエストのSession-Expiresヘッダーフィールドにコピーする必要があります。 これにより、プロキシは現在の値を確認できます。 プロキシはこの要求を拒否し、Min-SEに最小値を高めて提供し、UACはそれを使用します。 プロキシがリクエストを拒否せず、Min-SEヘッダーフィールドでリクエストをプロキシした場合、攻撃が可能になることに注意してください。 UASは、2xx応答でこのヘッダーフィールドを破棄し、UACに高速リクエストの生成を強制することができます。
In a similar fashion, a rogue proxy cannot force either the UAC or UAS to generate refreshes unless the proxy remains on the signaling path and sees every request and response.
同様に、不正なプロキシは、プロキシがシグナリングパス上にあり、すべての要求と応答を確認しない限り、UACまたはUASに強制的に更新を生成させることはできません。
An element that can observe and modify a request or response in transit can force rapid session refreshes. To prevent this, requests and responses have to be protected by message integrity. Since the session timer header fields are not end-to-end and are manipulated by proxies, the SIP S/MIME capabilities are not suitable for this task. Rather, integrity has to be protected by using hop-by-hop mechanisms. As a result, it is RECOMMENDED that an element send a request with a Session-Expires header field or a Supported header field with the value 'timer' by using TLS. As adequate protection is obtained only if security is applied on each hop, it is RECOMMENDED that the SIPS URI scheme be used in conjunction with this extension. This means that proxies that record-route and request session timer SHOULD record-route with a SIPS URI. A UA that inserts a Session-Expires header into a request or response SHOULD include a Contact URI that is a SIPS URI.
転送中の要求または応答を監視および変更できる要素は、セッションの迅速な更新を強制できます。 これを防ぐには、要求と応答をメッセージの整合性で保護する必要があります。 セッションタイマーヘッダーフィールドはエンドツーエンドではなく、プロキシによって操作されるため、SIP S / MIME機能はこのタスクには適していません。 むしろ、ホップバイホップのメカニズムを使用して整合性を保護する必要があります。 その結果、TLSを使用して、要素が値 'timer'を持つSession-Expiresヘッダーフィールドまたはサポートされているヘッダーフィールドを含むリクエストを送信することが推奨されます。 セキュリティが各ホップに適用される場合にのみ適切な保護が得られるため、SIPS URIスキームをこの拡張機能と組み合わせて使用することをお勧めします。 これは、レコードをルーティングし、セッションタイマーを要求するプロキシが、SIPS URIを使用してレコードをルーティングする必要があることを意味します。 Session-Expiresヘッダーを要求または応答に挿入するUAには、SIPS URIであるContact URIを含める必要があります。
This extension defines two new header fields, a new response code, and a new option tag. SIP [2] defines IANA procedures for registering these.
この拡張機能は、2つの新しいヘッダーフィールド、新しい応答コード、および新しいオプションタグを定義します。 SIP [2]は、これらを登録するためのIANA手順を定義しています。
The following is the registration for the Min-SE header field:
以下は、Min-SEヘッダーフィールドの登録です。
RFC Number: RFC 4028 Header Name: Min-SE Compact Form: none
RFC番号：RFC 4028ヘッダー名：Min-SE Compact Form：なし
The following is the registration for the Session-Expires header field:
以下は、Session-Expiresヘッダーフィールドの登録です。
RFC Number: RFC 4028 Header Name: Session-Expires Compact Form: x
RFC番号：RFC 4028ヘッダー名：Session-Expires Compact Form：x
12.2. IANA Registration of the 422 (Session Interval Too Small) Response Code
12.2. 422（セッション間隔が小さすぎる）応答コードのIANA登録
The following is the registration for the 422 (Session Interval Too Small) response code:
以下は、422（Session Interval Too Small）応答コードの登録です。
Response Code: 422 Default Reason Phrase: Session Interval Too Small RFC Number: RFC 4028
応答コード：422デフォルト理由フレーズ：セッション間隔が小さすぎるRFC番号：RFC 4028
The following is the registration for the 'timer' option tag:
「タイマー」オプションタグの登録は次のとおりです。
Name: timer Description: This option tag is for support of the session timer extension. Inclusion in a Supported header field in a request or response indicates that the UA can perform refreshes according to that specification. Inclusion in a Require header in a request means that the UAS must understand the session timer extension to process the request. Inclusion in a Require header field in a response indicates that the UAC must look for the Session-Expires header field in the response and process it accordingly.
名前：timer説明：このオプションタグは、セッションタイマー拡張機能をサポートするためのものです。 要求または応答のサポートされているヘッダーフィールドに含めることは、UAがその仕様に従って更新を実行できることを示します。 要求にRequireヘッダーを含めることは、UASが要求を処理するためにセッションタイマー拡張を理解する必要があることを意味します。 応答にRequireヘッダーフィールドを含めることは、UACが応答でSession-Expiresヘッダーフィールドを探し、それに応じて処理する必要があることを示します。
Example Session Timer Flow
セッションタイマーフローの例
Alice Proxy P1 Proxy P2 Bob
|(1) INVITE | | |
|SE: 50 | | |
|----------->| | |
|(2) 422 | | |
|MSE: 3600 | | |
|<-----------| | |
|(3) ACK | | |
|----------->| | |
|(4) INVITE | | |
|SE:3600 | | |
|MSE:3600 | | |
|----------->| | |
| |(5) INVITE | |
| |SE:3600 | |
| |MSE:3600 | |
| |----------->| |
| |(6) 422 | |
| |MSE:4000 | |
| |<-----------| |
| |(7) ACK | |
| |----------->| |
|(8) 422 | | |
|MSE:4000 | | |
|<-----------| | |
|(9) ACK | | |
|----------->| | |
|(10) INVITE | | |
|SE:4000 | | |
|MSE:4000 | | |
|----------->| | |
| |(11) INVITE | |
| |SE:4000 | |
| |MSE:4000 | |
| |----------->| |
| | |(12) INVITE |
| | |SE:4000 |
| | |MSE:4000 |
| | |----------->|
| | |(13) 200 OK |
| | |SE:4000 |
| | |<-----------|
| |(14) 200 OK | |
| |SE:4000 | |
| |<-----------| |
|(15) 200 OK | | |
|SE:4000 | | |
|<-----------| | |
|(16) ACK | | |
|----------->| | |
| |(17) ACK | |
| |------------------------>|
|(18) UPDATE | | |
|SE:4000 | | |
|----------->| | |
| |(19) UPDATE | |
| |SE:4000 | |
| |------------------------>|
| |(20) 200 OK | |
| |SE:4000 | |
| |<------------------------|
|(21) 200 OK | | |
|SE:4000 | | |
|<-----------| | |
| |(22) BYE | |
| |<------------------------|
|(23) BYE | | |
|<-----------| | |
| |(24) 408 | |
| |------------------------>|
Figure 1: Example Session Timer Flow
図1：セッションタイマーフローの例
Figure 1 gives an example of a call flow that makes use of the session timer. In this example, both the UAC and UAS support the session timer extension. The initial INVITE request generated by the UAC, Alice (message 1), might look like this:
図1は、セッションタイマーを利用するコールフローの例を示しています。 この例では、UACとUASの両方がセッションタイマー拡張をサポートしています。 UACによって生成された最初のINVITE要求であるAlice（メッセージ1）は、次のようになります。
INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 Supported: timer Session-Expires: 50 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sips:alice@pc33.atlanta.example.com> Content-Type: application/sdp Content-Length: 142
INVITE sips：bob@biloxi.example.com SIP / 2.0 Via：SIP / 2.0 / TLS pc33.atlanta.example.com; branch = z9hG4bKnashds8サポート：timer Session-Expires：50 Max-Forwards：70 To：Bob <sips： bob@biloxi.example.com> From：Alice <sips：alice@atlanta.example.com>; tag = 1928301774 Call-ID：a84b4c76e66710 CSeq：314159 INVITE Contact：<sips：alice@pc33.atlanta.example.com> コンテンツタイプ：application / sdpコンテンツ長：142
(Alice's SDP not shown)
（アリスのSDPは表示されていません）
This request indicates that Alice supports the session timer, and is requesting session refreshes every 50 seconds. This arrives at the first proxy, P1. This session interval is below the minimum allowed value of 3600. So P1 rejects the request with a 422 (message 2):
この要求は、Aliceがセッションタイマーをサポートし、50秒ごとにセッションの更新を要求していることを示しています。 これは、最初のプロキシP1に到達します。 このセッション間隔は、3600の最小許容値を下回っています。したがって、P1は422（メッセージ2）で要求を拒否します。
SIP/2.0 422 Session Interval Too Small Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 Min-SE: 3600 To: Bob <sips:bob@biloxi.example.com>;tag=9a8kz From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE
SIP / 2.0 422セッション間隔が小さすぎるVia：SIP / 2.0 / TLS pc33.atlanta.example.com; branch = z9hG4bKnashds8; received = 192.0.2.1 Min-SE：3600 To：Bob <sips：bob@biloxi.example.com >; tag = 9a8kz差出人：Alice <sips：alice@atlanta.example.com>; tag = 1928301774 Call-ID：a84b4c76e66710 CSeq：314159 INVITE
This response contains a Min-SE header field with the value 3600. Alice then retries the request. This time, the request contains a Min-SE header, as Alice has received a 422 for other INVITE requests with the same Call-ID. The new request (message 4) might look like this:
この応答には、値3600のMin-SEヘッダーフィールドが含まれています。その後、アリスは要求を再試行します。 アリスは同じCall-IDを持つ他のINVITE要求に対して422を受信したため、今回は、要求にMin-SEヘッダーが含まれています。 新しい要求（メッセージ4）は次のようになります。
INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 Supported: timer Session-Expires: 3600 Min-SE: 3600 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314160 INVITE Contact: <sips:alice@pc33.atlanta.example.com> Content-Type: application/sdp Content-Length: 142
INVITE sips：bob@biloxi.example.com SIP / 2.0 Via：SIP / 2.0 / TLS pc33.atlanta.example.com; branch = z9hG4bKnashds9サポート：timer Session-Expires：3600 Min-SE：3600 Max-Forwards：70 To ：Bob <sips：bob@biloxi.example.com> From：Alice <sips：alice@atlanta.example.com>; tag = 1928301774 Call-ID：a84b4c76e66710 CSeq：314160 INVITE Contact：<sips：alice@pc33.atlanta .example.com> Content-Type：application / sdp Content-Length：142
(Alice's SDP not shown)
（アリスのSDPは表示されていません）
Proxy P1 record-routes. Since the session interval is now acceptable to it, it forwards the request to P2 (message 5). However, the session interval is below its minimum configured amount of 4000. So it rejects the request with a 422 response code (message 6) and includes a Min-SE header field with the value of 4000. Once more, Alice retries the INVITE. This time, the Min-SE header field in her INVITE is the maximum of all Min-SE she has received (3600 and 4000). Message 10 might look like this:
プロキシP1レコードルート。 セッション間隔が受け入れられるようになったため、要求をP2に転送します（メッセージ5）。 ただし、セッション間隔は設定された最小の4000を下回っています。したがって、422応答コード（メッセージ6）で要求を拒否し、値4000のMin-SEヘッダーフィールドを含めます。もう一度、AliceはINVITEを再試行します。 今回、INVITEのMin-SEヘッダーフィールドは、受信したすべてのMin-SEの最大値（3600および4000）です。 メッセージ10は次のようになります。
INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10 Supported: timer Session-Expires: 4000 Min-SE: 4000 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314161 INVITE Contact: <sips:alice@pc33.atlanta.example.com> Content-Type: application/sdp Content-Length: 142
INVITE sips：bob@biloxi.example.com SIP / 2.0 Via：SIP / 2.0 / TLS pc33.atlanta.example.com; branch = z9hG4bKnashds10サポート：timer Session-Expires：4000 Min-SE：4000 Max-Forwards：70 To ：Bob <sips：bob@biloxi.example.com> From：Alice <sips：alice@atlanta.example.com>; tag = 1928301774 Call-ID：a84b4c76e66710 CSeq：314161 INVITE Contact：<sips：alice@pc33.atlanta .example.com> Content-Type：application / sdp Content-Length：142
(Alice's SDP not shown)
（アリスのSDPは表示されていません）
P1 record-routes once again, but P2 does not (this wouldn't normally happen; presumably, if it asked for session timer, it would record-route the subsequent request). The UAS receives the request. It copies the Session-Expires header from the request to the response and adds a refresher parameter with value 'uac'. This 200 OK is forwarded back to Alice. The response she receives (message 15) might look like this:
P1はもう一度ルートを記録しますが、P2はそうではありません（これは通常は発生しません。おそらく、セッションタイマーを要求した場合、後続の要求を記録するでしょう）。 UASは要求を受け取ります。 Session-Expiresヘッダーを要求から応答にコピーし、値「uac」の更新パラメーターを追加します。 この200 OKは、アリスに転送されます。 彼女が受け取る応答（メッセージ15）は次のようになります。
SIP/2.0 200 OK Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10 ;received=192.0.2.1 Require: timer Supported: timer Record-Route: sips:p1.atlanta.example.com;lr Session-Expires: 4000;refresher=uac To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314161 INVITE Contact: <sips:bob@192.0.2.4> Content-Type: application/sdp Content-Length: 142
SIP / 2.0 200 OK Via：SIP / 2.0 / TLS pc33.atlanta.example.com; branch = z9hG4bKnashds10; received = 192.0.2.1必須：timerサポート：timer Record-Route：sips：p1.atlanta.example.com; lr Session-Expires：4000; refresher = uac To：Bob <sips：bob@biloxi.example.com>; tag = 9as888nd From：Alice <sips：alice@atlanta.example.com>; tag = 1928301774 Call-ID：a84b4c76e66710 CSeq：314161 INVITE連絡先：<sips：bob@192.0.2.4> Content-Type：application / sdp Content-Length：142
(Bob's SDP not shown)
（ボブのSDPは表示されていません）
Alice generates an ACK (message 16), which is routed through P1 and then to Bob. Since Alice is the refresher, around 2000 seconds later Alice sends an UPDATE request to refresh the session. Because this request is part of an established dialog and Alice has not received any 422 responses or requests on that dialog, there is no Min-SE header field in her request (message 18):
アリスはACK（メッセージ16）を生成し、P1を経由してボブにルーティングされます。 アリスはリフレッシャーなので、約2000秒後にアリスはUPDATE要求を送信してセッションをリフレッシュします。 この要求は確立されたダイアログの一部であり、アリスはそのダイアログで422応答または要求を受信していないため、要求にはMin-SEヘッダーフィールドがありません（メッセージ18）。
UPDATE sips:bob@192.0.2.4 SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12 Route: sips:p1.atlanta.example.com;lr Supported: timer Session-Expires: 4000;refresher=uac Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314162 UPDATE Contact: <sips:alice@pc33.atlanta.example.com>
UPDATE sips：bob@192.0.2.4 SIP / 2.0 Via：SIP / 2.0 / TLS pc33.atlanta.example.com; branch = z9hG4bKnashds12 Route：sips：p1.atlanta.example.com; lrサポート：timer Session-Expires：4000 ; refresher = uac Max-Forwards：70 To：Bob <sips：bob@biloxi.example.com>; tag = 9as888nd From：Alice <sips：alice@atlanta.example.com>; tag = 1928301774 Call-ID：a84b4c76e66710 CSeq：314162 UPDATE連絡先：<sips：alice@pc33.atlanta.example.com>
This is forwarded through P1 to Bob. Bob generates a 200 OK, copying the Session-Expires header field into the response. This is forwarded through P1 and arrives at Alice. The response she receives (message 21) might look like this:
これはP1を介してBobに転送されます。 Bobは200 OKを生成し、Session-Expiresヘッダーフィールドを応答にコピーします。 これはP1を介して転送され、アリスに到着します。 彼女が受け取る応答（メッセージ21）は次のようになります。
SIP/2.0 200 OK Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12 ;received=192.0.2.1 Require: timer Session-Expires: 4000;refresher=uac To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314162 UPDATE Contact: <sips:bob@192.0.2.4>
SIP / 2.0 200 OK Via：SIP / 2.0 / TLS pc33.atlanta.example.com; branch = z9hG4bKnashds12; received = 192.0.2.1 Require：timer Session-Expires：4000; refresher = uac To：Bob <sips：bob @ biloxi .example.com>; tag = 9as888nd From：Alice <sips：alice@atlanta.example.com>; tag = 1928301774 Call-ID：a84b4c76e66710 CSeq：314162 UPDATE Contact：<sips：bob@192.0.2.4>
Shortly afterward, Alice's UA crashes. As a result, she never sends a session refresh request. 3968 seconds later, Bob times out and sends a BYE request (message 22). This is sent to P1. P1 attempts to deliver it but fails (because Alice's UA has crashed). P1 then returns a 408 (Request Timeout) to Bob.
その後すぐに、アリスのUAがクラッシュします。 その結果、彼女はセッションリフレッシュリクエストを送信しません。 3968秒後、ボブはタイムアウトし、BYE要求を送信します（メッセージ22）。 これはP1に送信されます。 P1は配信を試みますが失敗します（AliceのUAがクラッシュしたため）。 次に、P1は408（要求タイムアウト）をボブに返します。
The authors wish to thank Brett Tate for his contributions to this work. Brian Rosen completed the editing of the document.
著者は、この作業に貢献してくれたBrett Tateに感謝します。 ブライアンローゼンはドキュメントの編集を完了しました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[2] 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.
[2] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。
[3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[3]ローゼンバーグ、J。、「セッション開始プロトコル（SIP）更新メソッド」、RFC 3311、2002年10月。
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] Rosenberg、J。およびH. Schulzrinne、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、2002年6月。
[5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[5] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーションのトランスポートプロトコル」、STD 64、RFC 3550、2003年7月。
[6] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[6] Srisuresh、P。、およびM. Holdrege、「IPネットワークアドレス変換（NAT）の用語と考慮事項」、RFC 2663、1999年8月。
[7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[7] Rosenberg、J。、およびH. Schulzrinne、「セッション開始プロトコル（SIP）の暫定応答の信頼性」、RFC 3262、2002年6月。
[8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[8] Roach、A。、「セッション開始プロトコル（SIP）固有のイベント通知」、RFC 3265、2002年6月。
Authors' Addresses
著者のアドレス
Steve Donovan Cisco Systems, Inc. 2200 E. President George Bush Turnpike Richardson, Texas 75082 US
Steve Donovan Cisco Systems、Inc. 2200 E.ジョージブッシュターンパイクリチャードソン、テキサス州75082米国
EMail: srd@cisco.com
メール：srd@cisco.com
Jonathan Rosenberg Cisco Systems, Inc. 600 Lanidex Plaza Parsippany, NJ 07054 US
Jonathan Rosenberg Cisco Systems、Inc. 600 Lanidex Plaza Parsippany、NJ 07054 US
EMail: jdrosen@cisco.com
メール：jdrosen@cisco.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、制限の対象となります。また、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本書および本書に含まれる情報は「現状のまま」提供され、寄稿者、代表者または代表者（もしあれば）、インターネット協会、インターネットエンジニアリングタスクフォースはすべての保証を放棄します 黙示的であるが、ここに記載されている情報の使用が商品性または特定の目的への適合性の黙示的保証を侵害しないという保証に限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書に記載されている技術の実装または使用に関連すると主張される可能性のある知的財産権またはその他の権利の有効性または範囲、またはそのような権利の下でのライセンスの有無に関して、立場をとりません。 利用可能 また、そのような権利を特定するための独立した努力を行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーおよび利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用許可の取得を試みた結果を取得できます。 IETFオンラインIPRリポジトリ（http://www.ietf.org/ipr）から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この標準を実装するために必要な技術を対象とする著作権、特許、特許出願、またはその他の所有権に関心を寄せるよう、あらゆる利害関係者を招待します。 IETFのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能の資金は、現在インターネット協会によって提供されています。