[要約] RFC 4028は、SIPセッションでのセッションタイマーの使用方法を定義しています。その目的は、セッションの有効期限を制御し、セッションの状態を維持することです。
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)
セッション開始プロトコル（SIP）のセッションタイマー
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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または更新リクエストを介して、SIPセッションの定期的な更新が可能になります。更新により、ユーザーエージェントとプロキシの両方がSIPセッションがまだアクティブかどうかを判断できます。拡張機能は、2つの新しいヘッダーフィールドを定義します。セッションの寿命を伝えるセッションとexpiresと、セッションタイマーの最小許容値を伝えるmin-seです。
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.
セッション開始プロトコル（SIP）[2]は、確立するセッションのキープライブメカニズムを定義しません。ユーザーエージェントは、セッション固有のメカニズムを使用してセッションがタイムアウトしたかどうかを判断できる場合がありますが、プロキシはそうすることができません。その結果、Call Stateful Proxiesがセッションがまだアクティブであるかどうかを常に判断できるとは限りません。たとえば、ユーザーエージェントがセッションの終了時にさようならメッセージを送信できなかった場合、またはネットワークの問題のためにさようならメッセージが失われた場合、Stateful Proxyはセッションがいつ終了したかわかりません。この状況では、コールステートフルプロキシはコールのために状態を保持し、コール状態情報が適用されなくなった時期を判断する方法はありません。
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セッションのキープライブメカニズムを定義します。UASは、セッションを生かし続けるために、定期的なre-inviteまたはupdate [3]リクエスト（セッション更新リクエストと呼ばれる）を送信します。セッション更新リクエストの間隔は、ここで定義されている交渉メカニズムを通じて決定されます。インターバルが通過する前にセッション更新リクエストが受信されない場合、セッションは終了したと見なされます。両方のUASはさようならを送信することになっており、Callful Proxiesはコールの任意の状態を削除できます。
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.
この更新メカニズムには追加のアプリケーションがあります。ユーザーエージェントは、Stateful Proxyサーバーがコールするのと同じ理由で、セッションがまだアクティブであるかどうかを判断したいと考えています。この決定は、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に埋め込まれたアルグは、コールの期間中状態を維持する必要があります。この状態は最終的に削除する必要があります。信頼性が低いことに加えて、州の除去を引き起こすためにさようならに依存すると、潜在的なサービス攻撃が導入されます。
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の拡張機能を提供します。Reinvitesまたは更新を介した定期的な更新は、セッションをアクティブに保つために使用されます。拡張機能は、ダイアログの2人の参加者のいずれかが拡張機能を理解している限り、SIPと十分に後方互換性があります。2つの新しいヘッダーフィールド（Session-ExpiresとMin-SE）と新しい応答コード（422）が定義されています。セッションは、セッションの期間を伝え、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.
このドキュメントでは、キーワード「必須」、「必須」、「必須」、「必要」、「しない」、「そうではない」、「必要」、「推奨」、「5月」、および「オプション」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.
セッション間隔：セッション前のダイアログでセッション更新リクエスト間で発生する可能性のある時間の最大時間は、タイミングが刻まれていると見なされます。セッション間隔は、セッションのヘッダーフィールドで伝えられます。ここでは定義されています。UASは、セッションヘッダーフィールドからこの値を取得します。プロキシとUACは、セッションのヘッダーフィールドからこの値を決定します。
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.
最小タイマー：Mid-Dialog要求の処理荷重のため、すべての要素（プロキシ、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.
セッション更新リクエスト：この仕様のルールに従って処理された招待または更新リクエスト。リクエストが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は招待状を送信することから始めます。これには、オプションタグ「タイマー」を備えたサポートされているヘッダーフィールドが含まれ、この拡張機能のサポートを示しています。
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.
このリクエストはプロキシを通過しますが、そのいずれかがセッションタイマーの確立に関心を持っている可能性があります。各プロキシは、セッションのヘッダーフィールドとmin-seヘッダーフィールドをリクエストに挿入することができます（既に存在しない場合）、既存のセッションエクスピアと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.
セッションは、ヘッダーフィールドがセッション更新間隔の上限を確立します。つまり、セッション状態のプロキシがこのセッションの状態を保持する必要がある要求を処理した後の期間。このリクエストにサービスを提供するプロキシは、この値を下げることができますが、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.
セッションと標準の間隔がプロキシに対して低すぎる場合（つまり、プロキシが主張したい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.
いくつかの招待/422反復の後、リクエストは最終的にUASに到着します。UASは、セッション間隔の値をプロキシであるかのように調整できます。完了すると、最終セッションインターバルをセッションに配置します。ヘッダーフィールドは2xx応答です。セッションエッピングヘッダーフィールドには、「リフレッシャー」パラメーターも含まれています。これには、誰がさわやかなことをしているのかを示します。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.
セッションのヘッダーフィールドから応答中に、両方のUASは、セッションタイマーがアクティブであり、期限切れになるとき、誰がリフレッシュしていることを知っています。有効期限の前のある時点で、現在アクティブなリフレッシャーはセッション更新リクエストを生成します。これは、再入札または更新[3]リクエストです。Refresherがそのセッションの更新リクエストへの応答を決して取得しない場合、セッションを終了するためにさようならを送信します。同様に、セッションが期限切れになる前に反対側がセッションの更新要求を取得しない場合、それはさようならを送信します。
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.
この拡張は、この基本的な流れを超えて追加の合併症を導入して、UASの1つだけがサポートするケースをサポートします。そのような合併症の1つは、UASが拡張機能をサポートしていない場合に、プロキシがセッションヘッダーフィールドを応答に挿入する必要がある可能性があることです。Refresherの役割の交渉もこの能力の影響を受けます。どの参加者が拡張機能をサポートするかを考慮します。
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つは関連しています。セッションの有効期限が切れると、さようならが送信され、セッションと一般的にダイアログが終了します。
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.
セッションは、SIPセッションのセッション間隔を伝えます。招待状または更新リクエスト、および招待状または更新に対する2xxの応答のみに配置されます。SIPの有効期限がヘッダーフィールドと同様に、デルタタイムが含まれています。
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.
セッションのヘッダーフィールドの絶対最小値は90秒です。この値は、SIPトランザクションがタイムアウトの場合に取ることができる期間の2倍以上を表しています。これにより、UAがセッション間隔のハーフポイントで更新を試み、セッションが期限切れになる前にそのトランザクションが正常に完了するのに十分な時間が与えられます。ただし、セッションヘッダーフィールドの値として1800秒（30分）が推奨されます。言い換えれば、SIPエンティティは、90秒を超える任意の期間のセッションヘッダーフィールド値を処理するために準備する必要がありますが、セッションを挿入するエンティティは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.
小さなセッション間隔は、ネットワークにとって破壊的です。ユーザーエージェントとプロキシサーバーの両方に影響を与える過度のメッセージングトラフィックを引き起こします。彼らは、両方のユーザーエージェントが同時に再インバイトまたは更新を送信するときに発生する「まぶしさ」の可能性を高めます。セッションタイマーの主な目的は、SIP要素のタイムアウト状態を提供することであるため、一般に非常に小さな値は必要ありません。電話の95％がこの期間よりも短いため、30分が選択されました。ただし、この数の正確な値は、ネットワーク帯域幅とレイテンシ、コンピューティングパワー、メモリの可用性、ネットワークトポロジ、および、および、、この数値の正確な値は依存しているため、最低30分は必須ではありません。もちろん、アプリケーションシナリオ。結局のところ、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.
セッションのデフォルト値は、ヘッダーフィールドに定義されていません。これは、セッションを発見するヘッダーフィールドの欠如が、この仕様で定義されたメカニズムを使用して、セッションの有効期限を暗示していないことを意味します。ローカルで構成されたタイマーなど、この仕様では定義されていない他のメカニズムが適用される場合があることに注意してください。
The syntax of the Session-Expires header field is as follows:
セッションと予見されたヘッダーフィールドの構文は次のとおりです。
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].
コンパクトなフォームである文字Xは、セッションの発言のために予約されていることに注意してください。デルタ秒およびジェネリックパラムのBNFは、RFC 3261のセクション25で定義されています[2]。
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は、セッションとMIN-SEヘッダーフィールドの[2]の表2および3の拡張です。列「PRA」はPrackメソッド[7]用、「Upd」は更新方法[3]、「sub」はサブスクライブメソッド[8]、「not」は通知方法[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：セッションと標識と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ヘッダーフィールドは、デルタ秒単位のセッション間隔の最小値を示します。招待状または更新リクエストで使用する場合、そのセッションに使用できるセッション間隔の最小値を示します。リクエストまたは応答に存在する場合、その値は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の応答コードを持つ人を除き、応答に使用してはなりません。サーバーが受け入れる意思があるセッション間隔の最小値を示します。
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 delta-seconds *（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（セッション間隔が小さすぎる）応答コードを導入します。リクエストにセッションが含まれている場合、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を除く）にサポートされているヘッダーフィールドを含める必要があり、オプションタグ「タイマー」[2]をリストします。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がセッションに参加するためにセッションタイマーをサポートする必要があることを示す値「タイマー」を含む要求に要求ヘッダーフィールドを含めることができます。これは、UACがUASにリフレッシュを実行することを要求していることを意味するものではなく、UASが拡張機能をサポートすることを要求していることだけです。さらに、UACには、リクエストを正しく処理するためにプロキシがセッションタイマーをサポートする必要があることを示す値「タイマー」を備えたリクエストにプロキシレクイアヘッダーフィールドをリクエストに含めることができます。ただし、UACによる要求またはプロキシレクイアの使用は推奨されません。UACのみが拡張機能をサポートしている場合でも、拡張機能が機能するため、それらは必要ありません。「タイマー」またはプロキシレクイアヘッダーフィールドが「タイマー」を含む場合でも、「タイマー」を含むサポートされているヘッダーフィールドを含める必要があります。
A UAC MAY include the Min-SE header field in the initial INVITE request.
UACには、最初の招待リクエストに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には、セッションに適用されるセッションタイマーが必要な場合、初期セッションの更新リクエストでセッションヘッダーフィールドを含めることができます。このヘッダーフィールドの値は、UACが望むセッション間隔を示します。MIN-SEヘッダーが最初のセッションの更新要求に含まれている場合、セッションの標識の値は、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」を備えたRefresherパラメーターを含めることができます。ただし、以下で説明する交渉メカニズムによって選択できるように、パラメーターを省略することをお勧めします。
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が必要です。この状態には、セッション間隔、セッションの有効期限、復習の身元が含まれます。この状態は、セッションが交渉された対話に関連付けられています。
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応答が届くと、値「タイマー」を備えた要求ヘッダーフィールドが含まれている場合と含まれていない場合があります。もしそうなら、UACは応答を処理するためにセッションヘッダーフィールドを探す必要があります。
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'.
値「タイマー」を使用して応答に必要なヘッダーフィールドがあった場合、セッションのヘッダーフィールドは常に存在します。UACは、リクエストに存在していなくても、セッションヘッダーフィールドを応答して準備する必要があります。「リフレッシャー」パラメーターはセッションヘッダーフィールドに存在し、誰がリフレッシュを実行するかを示します。UACは、このパラメーターの値に復習のアイデンティティを設定する必要があります。パラメーターに値「UAC」が含まれている場合、UACはそれらを実行します。UACがセッションタイマーを要求し（したがって、リクエストにセッションヘッダーフィールドが含まれている）、2XX応答に必要またはセッションヘッダーフィールドがなかった可能性があります。これは、UASがセッションタイマー拡張機能をサポートせず、UACのみがセッションタイマーを要求した場合に発生します（プロキシは要求していません）。この場合、UACがまだセッションタイマーを使用したい場合（これは純粋にその利益のためだけではありません）、それらを実行する必要があります。これを行うために、UACはこの仕様で定義されている手順に従って、セッションエクサイヤーヘッダーフィールドが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応答にセッションのヘッダーフィールドが含まれていなかった場合、セッションの有効期限はありません。この場合、リフレッシュを送信する必要はありません。セッションのない2xxは、初期およびその後のセッションの更新リクエストの両方で来ることができます。つまり、セッションタイマーは、セッションのヘッダーフィールドなしで応答を受信することにより、ダイアログの中間ダイアログで「ターンオフ」できることを意味します。
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応答で、セッション時間のデルタ時間の値としてセッションのセッション間隔を覚えています。単一の招待状の結果として確立された異なるダイアログで、異なるセッション間隔（またはまったくない）があることが明示的に許可されています。UACはまた、ITまたはそのピアがセッションの復習であるかどうかを覚えています。
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 RECOMMENDED that this refresh be sent once half the session interval has elapsed. Additional procedures for this refresh are described in Section 10.
UACがリフレッシュを実行する必要がある場合、そのセッションのセッションの有効期限を計算します。セッションの有効期限は、そのダイアログとそのセッションのセッション間隔に対するセッション更新リクエストに対する最後の2xx応答を受信する時間です。UAがセッションの有効期限を超えてセッションを継続しようとしている場合、セッションの有効期限が切れる前に更新を生成する必要があります。セッション間隔の半分が経過すると、この更新を送信することをお勧めします。この更新の追加手順については、セクション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.
同様に、セッションのリフレッシュ以外の目的でダイアログ内で送信された再入札または更新リクエストもセッションを更新する効果があり、その処理はこの仕様で定義されている手順に従います。
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で説明されています。この新しいリクエストは新しいトランザクションを構成し、前のリクエストのコールIDと同じ値を持つ必要がありますが、CSEQには前のものよりも高い新しいシーケンス番号を含める必要があります。
The values of Supported, Require, and Proxy-Require used in the initial Session refresh request MUST be used.
初期セッションの更新リクエストで使用されるサポート、要求、およびプロキシレクイアの値を使用する必要があります。
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ヘッダーフィールドが含まれていました。同様に、ダイアログがまだ確立されていない場合、UACは、同じCall-IDを使用した以前の招待リクエストに対する422の応答を受け取ったことがある場合、MIN-SEヘッダーフィールドを招待リクエストに挿入する必要があります。
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を使用した招待リクエストの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.
アクティブなセッションタイマーを使用してダイアログ内で送信されたセッション更新リクエストでは、セッションヘッダーフィールドが存在する必要があります。存在する場合、Min-SEヘッダーフィールドの最大値（存在しない場合のデフォルト値が90秒であることを思い出してください）と現在のセッション間隔に等しくなければなりません。セクション11で文書化されているように、セッションのヘッダーフィールドをこの値に含めることで、特定のサービス拒否攻撃を回避します。ミッドディアログ。
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.
セッションの更新リクエストが最初の要求でない場合、リクエストを送信する要素が現在リフレッシュを実行している場合は、復習パラメーターを「UAC」に設定することをお勧めします。このようにして、リフレッシャーの役割は、リフレッシュごとに変更されません。ただし、役割を明示的に変更したい場合、反対側がセッションタイマーをサポートしていることがわかっている場合、「UAS」の値を使用する場合があります。値「タイマー」を含むサポートされているヘッダーフィールドを備えたピアからリクエストを受け取ったことでこれを知ることができました。役割を再選択しようとする場合、パラメーターを省略する可能性があります。
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は通常の再入力であり、セッションを更新するために生成された更新は通常のアップデートです。UACがピアが更新方法をサポートしていることを知っている場合、Re Inviteの代わりに更新を使用することをお勧めします。UAは、値「アップデート」を使用してピアからヘッダーフィールドを許可している場合、またはMid-Dialogオプションリクエストを使用して、この決定を行うことができます。更新要求にはオファー[4]が含まれていないが、セッションの詳細が変更されていない場合でも、再インバイトにはそれを含めることをお勧めします。その場合、オファーはそれが変更されていないことを示す必要があります。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.
セッションタイマーは、Stateful Proxyサーバー（つまり、それらを通して確立されたコールとダイアログの状態を維持するサーバーに）を呼び出すことにほとんど興味があります。ただし、ステートフルプロキシサーバー（つまり、トランザクション状態を認識しているが、通話またはダイアログ状態を保持しないサーバー）もここで説明するルールに従うことができます。ステートレスプロキシは、セッションタイマーを要求しようとしてはなりません。セッションタイマーを要求するプロキシは、レコードルートを記録する必要があります。
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.
セッションのセッションタイマーをリクエストするために、プロキシにより、セッションのヘッダーフィールドがそのセッションの更新リクエストに存在することを確認します。プロキシは、リクエストに存在していなかった場合、それを転送する前に、リクエストにヘッダーフィールドにセッションを挿入する場合があります。このセッションは、ヘッダーフィールドにプロキシが望む任意の有効期限時間を含む場合がありますが、存在する場合、リクエストの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.
リクエストにセッションのヘッダーフィールドが既にある場合、プロキシはその値を減らすことができますが、存在する場合、リクエストのMIN-SEヘッダーフィールドの値よりも低い期間に設定してはなりません。セッションの値がヘッダーフィールドの値がMin-SEヘッダーフィールドの値以上である場合（Min-SEヘッダーフィールドが存在しない場合はデフォルトが90秒であることを思い出してください）、プロキシは増加してはなりません。セッションの値はヘッダーフィールドを発見します。セッションの値がヘッダーフィールドの値がMIN-SEヘッダーフィールドの値よりも低い場合（おそらく、以下で説明するように、プロキシがMIN-SEヘッダーフィールドの値を増加させたため）、プロキシはの値を増やす必要があります。セッションは、ヘッダーフィールドを発見して、Min-SEヘッダーフィールド値に等しくなります。プロキシは、セッションヘッダーフィールドに「リフレッシャー」パラメーターの値を挿入または変更してはなりません。
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.
リクエストに値「タイマー」を備えたサポートされているヘッダーフィールドが含まれている場合、プロキシは、セッションのセッション間隔が定義された最小間隔よりも小さい場合、422（セッション間隔が小さすぎる）応答で招待要求を拒否する場合があります。プロキシのローカルポリシーによって。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ヘッダーフィールドが既に存在している場合、プロキシは値を最小間隔まで増加させる（ただし、減少させてはならない）するはずです。その後、プロキシは、セッションヘッダーのフィールド値を増やして、上記のようにMIN-SEヘッダーフィールドの値に等しくなります。プロキシは、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.
プロキシがセッションタイマーを要求したと仮定して（したがって、セッションのヘッダーフィールドを挿入するか、それを削減した可能性があります）、プロキシはセッションタイマーを使用していることを覚えておく必要があります。プロキシリクエストから。これは、トランザクションの期間中に記憶する必要があります。
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.
プロキシは、トランザクションの期間中、リクエストに値「タイマー」のサポートされているヘッダーフィールドが含まれていたかどうかを覚えておく必要があります。リクエストに値「タイマー」を備えたサポートされているヘッダーフィールドが含まれていなかった場合、プロキシは、値「タイマー」がリクエストに必要なヘッダーフィールドを挿入する場合があります。ただし、これは推奨されません。これにより、プロキシはセッションのセッションタイマーを主張できます。サポートされているヘッダーフィールドがリクエストにある場合、このヘッダーフィールドは必要ありません。この場合、プロキシはすでにセッションタイマーをセッションに使用できることを確認します。
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.
応答にセッションが含まれていないが、ヘッダーフィールドのフィールドがあるが、プロキシは、リクエストでセッションタイマーを要求したことを覚えている（プロキシリクエストでセッションのヘッダーフィールドを挿入、変更、または検査、受け入れることにより）。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.
応答にセッションの標準がないか、ヘッダーフィールドが必要であるため、プロキシは、それが応答を受信した最初のセッションタイマに認識されたプロキシであることを知っています。このプロキシは、セッションを挿入する必要があります。ヘッダーフィールドは、転送されたリクエストから覚えていた値を使用して応答になります。「Refresher」パラメーターの値を「UAC」に設定する必要があります。プロキシは、「タイマー」オプションタグを応答に必要なヘッダーフィールドに追加する必要があり、存在しない場合は、上流に転送する前にその値で要求ヘッダーフィールドを追加します。
If the received response contains a Session-Expires header field, no modification of the response is needed.
受信した応答にセッションが含まれている場合、ヘッダーフィールドがあり、応答の変更は必要ありません。
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応答がプロキシによって上流に転送された場合、セッションのヘッダーフィールドが含まれている場合、その値はその応答に関連付けられたセッションのセッション間隔を表します。プロキシは、2xx応答が上流に転送される時間とセッション間隔としてセッションの有効期限を計算します。このセッションの有効期限は、セッションの既存のセッションの有効期限を更新する必要があります。セッションの復習パラメーターは、上流に転送された2xx応答のヘッダーフィールドが存在し、どのUAがリフレッシュを実行しているかを示します。単一の招待に対する複数の2xx応答があり、それぞれが異なるダイアログを表しているため、各ダイアログに関連付けられた各セッションに1つは複数のセッションの満了になります。
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.
プロキシは、上流に転送する前に、応答で受け取った（存在すると仮定する）セッションのヘッダーフィールドの値を変更してはなりません。
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とは異なり、さようならを送ってはなりません。
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.
受信リクエストに、値「タイマー」とセッションの有効期限が切れるサポートされているヘッダーフィールドが含まれている場合、UASはセッションインターバルがヘッダーフィールドにある場合、422（セッション間隔が小さすぎる）応答で招待要求を拒否することができます。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がリクエストを受け入れたい場合、セッションの値をリクエストから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ヘッダーフィールドの値よりも低い期間に設定してはなりません。それ以外の場合、UASはその値を減らすことができますが、90秒未満の期間に設定してはなりません。UASは、セッションのヘッダーフィールドの値を増やしてはなりません。
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.
着信リクエストに、値「タイマー」を備えたサポートされているヘッダーフィールドが含まれているが、セッションを象徴するヘッダーが含まれていない場合、UASがタイマーのサポートを示しているが、それを要求していないことを意味します。UASは、セッションヘッダーフィールドを含めることにより、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応答のセッションエクサイヤーヘッダーフィールドにリフレッシャーパラメーターの値を設定する必要があります。この値は、ダイアログのリフレッシュを実行する人を指定します。値は、リクエスト内のこのパラメーターの値と、UACがセッションタイマー拡張機能をサポートするかどうかに基づいています。UACは、リクエストのサポートされているヘッダーフィールドに「タイマー」オプションタグが存在する場合、拡張機能をサポートします。表2は、応答の値の設定方法を定義しています。2番目の列の「none」の値は、リクエストに復習パラメーターがなかったことを意味します。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はITまたはUACがリフレッシュを実行するかどうかを決定できます。ただし、テーブルが示すように、UASがそれを作成した場合、UASがRefresherの選択を無効にすることはできません。
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応答のヘッダーフィールドに「UAC」の値を持っている場合、UASは値「タイマー」を使用して応答に必要なヘッダーフィールドを配置する必要があります。これは、UACがリフレッシュを実行しており、UACがこれを知るために応答を処理する必要があるためです。2XX応答の復習パラメーターに「UAS」の値があり、リクエストのサポートされているヘッダーフィールドに値「タイマー」が含まれている場合、UASは値「タイマー」を使用して応答にヘッダーフィールドを必要とする必要があります。この場合、UACはリフレッシュしませんが、リフレッシュを受け取らない場合は別れを送信することになっています。UACがさようならを送信せずに呼び出しは引き続き成功するため、要件の挿入はここに必要であり、必須ではありません。
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はセッションタイマーのために記載されています。この状態には、セッション間隔、セッションの有効期限、復習の身元が含まれます。この状態は、セッションのセットアップに使用されるダイアログに縛られています。セッション間隔は、そのダイアログのセッション更新リクエストに対する最新の2XX応答で、セッションのヘッダーフィールドからのデルタタイムの値に設定されます。また、最新の2xx応答からそのダイアログのセッション更新要求までの復習パラメーターの値に基づいて、それまたはそのピアがダイアログの復習であるかどうかを覚えています。最新の2XX応答にセッションのヘッダーフィールドがなかった場合、セッションの有効期限はなく、リフレッシュを実行する必要はありません。
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は、セッションの有効期限が切れる前にセッション更新要求を送信する必要があります（変更されていません）。
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 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.
セッション更新リクエストのトランザクションがタイムアウトするか、408または481の応答が生成される場合、UACはRFC 3261のセクション12.2.1.2に従ってByeリクエストを送信します[2]。セッション更新要求が2xx応答を生成しない場合（および結果としてセッションは更新されていません）、408または481以外の応答が受信された場合、UACはその応答コードに固有のルールに従い、場合は再試行する必要があります。可能。たとえば、応答が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.
同様に、リフレッシュを実行していないサイドがセッションの有効期限が切れる前にセッション更新リクエストを受信しない場合、セッションの有効期限がわずかに前にセッションを終了するためにさようならを送信する必要があります。セッション間隔の最低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アルグは、セッションの有効期限が切れた後、SIPトラフィックが通過できるようにすることに非常に容赦ない場合があります。これが、満了前にさようならを送信する必要がある理由です。
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要素の機能を導入して、準拠したUASに要素の選択レートでリフレッシュを送信させます。これは、重要な増幅特性を備えたサービス拒否攻撃の可能性を導入します。これらの攻撃は、「アウトサイダー」（輸送中のメッセージを変更しようとする要素）または「インサイダー」（合法的にリクエストパスにあるが、害を及ぼすことを意図している要素）から開始できます。幸いなことに、両方のケースはこの仕様によって適切に処理されます。
This introduces the possibility of rogue proxies or UAs introducing denial-of-service attacks. However, the mechanisms in this specification prevent that from happening.
これにより、不正なプロキシまたはUASがサービス拒否攻撃を導入する可能性が導入されます。ただし、この仕様のメカニズムにより、それが発生することができません。
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の場合を考えてください。そのためには、セッションを挿入して、ヘッダーフィールドが低い期間とUASに等しい復習パラメーターの招待状に挿入されます。サポートされているヘッダーフィールドをリクエストに配置すると仮定します。この低いタイマーに反対する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はセッションタイマーをサポートする必要があります。最初の招待状は、非常に小さなセッション間隔で2xxを返すRogue UASに到着します。UACはこのタイマーを使用し、すばやく更新を送信します。セクション7.4では、UACが現在のセッション間隔をセッションのヘッダーフィールドにコピーすることが要求されています。これにより、プロキシは現在の値を確認できます。プロキシはこのリクエストを拒否し、最小限の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.
同様の方法で、不正なプロキシは、Proxyがシグナリングパスに残り、すべての要求と応答を確認しない限り、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を使用して、セッションヘッダーフィールドまたはサポートされたヘッダーフィールドを使用してサポートされているヘッダーフィールドを要素を送信することをお勧めします。適切な保護は、各ホップにセキュリティが適用される場合にのみ取得されるため、SIPS URIスキームをこの拡張機能と組み合わせて使用することをお勧めします。これは、Record-routeおよびリクエストセッションタイマーがSIPS URIでレコードルートする必要があることをプロキシであることを意味します。セッションを挿入するUAは、ヘッダーを要求または応答に挿入する必要があります。
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 The following is the registration for the Session-Expires header field:
RFC番号：RFC 4028ヘッダー名：min-seコンパクトフォーム：なし以下はセッションの登録です - ヘッダーフィールド：
RFC Number: RFC 4028 Header Name: Session-Expires Compact Form: x
RFC番号：RFC 4028ヘッダー名：セッション - コンパクトフォーム：X
The following is the registration for the 422 (Session Interval Too Small) response code:
以下は、422（セッション間隔が小さすぎる）応答コードの登録です。
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.
名前：タイマーの説明：このオプションタグは、セッションタイマー拡張機能をサポートするためのものです。リクエストまたは応答にサポートされているヘッダーフィールドに含めることは、UAがその仕様に従ってリフレッシュを実行できることを示しています。要求に必要なヘッダーに含めることは、UASがリクエストを処理するためにセッションタイマー拡張機能を理解する必要があることを意味します。応答に必要なヘッダーフィールドに含めることは、UACがセッションのヘッダーフィールドを応答で探す必要があることを示し、それに応じて処理します。
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によって生成された最初の招待リクエスト、アリス（メッセージ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
(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):
このリクエストは、アリスがセッションタイマーをサポートしており、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 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:
SIP/2.0 422セッション間隔は小さすぎます：SIP/2.0/TLS PC33.ATLANTA.EXAMPLE.COM; BRANCH = Z9HG4BKNASHDS8;受信= 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この応答には、値3600のmin-seヘッダーフィールドが含まれています。リクエスト。今回は、アリスが同じCall-IDで他の招待リクエストに対して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
(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ヘッダーフィールドが含まれています。今回、彼女の招待状の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
(Alice's SDP not shown) 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:
（AliceのSDPには表示されていません）P1 Record-routesはもう一度ありませんが、P2はそうではありません（これは通常は発生しません。おそらく、セッションタイマーを要求した場合、後続のリクエストを記録するでしょう）。UASはリクエストを受け取ります。セッションをコピーして、リクエストから応答までヘッダーを把握し、値「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
(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秒後にアリスはセッションを更新するための更新リクエストを送信します。このリクエストは確立されたダイアログの一部であり、アリスはそのダイアログに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> 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:
SIPSの更新：bob@192.0.2.4 SIP/2.0経由：SIP/2.0/TLS PC33.ATLANTA.EXAMPLE.COM; BRANCH = Z9HG4BKNASHDS12ルート：SIPS：P1.ATLANTA.EXAMPLE.COM; LRサポート：タイマーセッション - 例：4000; refresher = uac max-forwards：70 to：bob <sips：bob@biloxi.example.com>; tag = 9as888nd from：alice <sips：alice@atlanta.example.com>;タグ= 1928301774 Call-ID：A84B4C76E6710101010CSEQ：314162更新連絡先：<SIPS：alice@pc33.atlanta.example.com>これはP1を介してBOBに転送されます。ボブは200 OKを生成し、セッションのヘッダーフィールドを応答にコピーします。これは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>
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秒後、ボブはタイムアを出して、さようならリクエストを送信します（メッセージ22）。これはP1に送信されます。P1はそれを配信しようとしますが、失敗します（アリスのUAがクラッシュしたため）。P1は408（リクエストタイムアウト）をBOBに返します。
The authors wish to thank Brett Tate for his contributions to this work. Brian Rosen completed the editing of the document.
著者は、この仕事への貢献についてブレット・テイトに感謝したいと考えています。ブライアン・ローゼンはドキュメントの編集を完了しました。
[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 INIATIATION Protocol"、RFC 3261、2002年6月。
[3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[3] Rosenberg、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
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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。