[要約] このRFCは、SIP（Session Initiation Protocol）においてセッションの「生存確認」を行うためのセッションタイマー機能を定義しています。「Session-Expires」ヘッダーを用いて、一定時間ごとに接続の維持（リフレッシュ）を要求する手順を規定することで、ネットワーク障害や予期せぬ端末の停止により「幽霊セッション（ステートの残り）」がサーバーやプロキシに滞留するのを防ぎ、リソースの有効活用を図ります。
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.
この文書は、インターネットコミュニティ向けのインターネット標準化過程のプロトコルを定め、改善に向けた議論や提案を求めています。このプロトコルの標準化状況については、「Internet Official Protocol Standards」（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.
この文書は、Session Initiation Protocol（SIP）の拡張を定義します。この拡張では、re-INVITEまたはUPDATE要求を使ってSIPセッションを定期的に更新できます。更新により、ユーザーエージェントとプロキシの両方がSIPセッションの継続中かどうかを判断できます。この拡張では2つの新しいヘッダーフィールドを定義します。Session-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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1. はじめに ......................................................2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. 用語 ..........................................................3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . 4
3. 操作の概要 ....................................................4
4. Session-Expires Header Field Definition . . . . . . . . . . 6
4. Session-Expiresヘッダーフィールドの定義 .......................6
5. Min-SE Header Field Definition . . . . . . . . . . . . . . . 8
5. Min-SEヘッダーフィールドの定義 ................................8
6. 422 Response Code Definition . . . . . . . . . . . . . . . . 8
6. 応答コード422の定義 ...........................................8
7. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . 9
7. UACの動作 .....................................................9
7.1. Generating an Initial Session Refresh Request . . . . 9
7.1. 初回セッション更新要求の生成 ............................9
7.2. Processing a 2xx Response . . . . . . . . . . . . . . 9
7.2. 2xx応答の処理 ...........................................9
7.3. Processing a 422 Response . . . . . . . . . . . . . . 11
7.3. 422応答の処理 ..........................................11
7.4. Generating Subsequent Session Refresh Requests . . . . 11
7.4. 後続セッション更新要求の生成 ...........................11
8. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 12
8. プロキシの動作 ...............................................12
8.1. Processing of Requests . . . . . . . . . . . . . . . . 13
8.1. 要求の処理 .............................................13
8.2. Processing of Responses . . . . . . . . . . . . . . . 14
8.2. 応答の処理 .............................................14
8.3. Session Expiration . . . . . . . . . . . . . . . . . . 15
8.3. セッション有効期限 .....................................15
9. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . 15
9. UASの動作 ....................................................15
10. Performing Refreshes . . . . . . . . . . . . . . . . . . . . 17
10. 更新の実行 ...................................................17
11. Security Considerations . . . . . . . . . . . . . . . . . . 18
11. セキュリティに関する考慮事項 .................................18
11.1. Inside Attacks . . . . . . . . . . . . . . . . . . . . 18
11.1. 内部者による攻撃 .......................................18
11.2. Outside Attacks . . . . . . . . . . . . . . . . . . . 19
11.2. 外部者による攻撃 .......................................19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
12. IANAに関する考慮事項 .........................................19
12.1. IANA Registration of Min-SE and Session-Expires
Header Fields . . . . . . . . . . . . . . . . . . . . 19
12.1. Min-SEおよびSession-ExpiresヘッダーフィールドのIANA登録 ..19
12.2. IANA Registration of the 422 (Session Interval Too
Small) Response Code . . . . . . . . . . . . . . . . . 20
12.2. 応答コード422（Session Interval Too Small）のIANA登録 ..20
12.3. IANA Registration of the 'timer' Option Tag . . . . . 20
12.3. 'timer'オプションタグのIANA登録 ........................20
13. Example Call Flow . . . . . . . . . . . . . . . . . . . . . 20
13. 呼フローの例 .................................................20
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
14. 謝辞 .........................................................25
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
15. 参考文献 .....................................................25
15.1. Normative References . . . . . . . . . . . . . . . . . 25
15.1. 規範的参考文献 .........................................25
15.2. Informative References . . . . . . . . . . . . . . . . 26
15.2. 参考情報文献 ...........................................26
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 26
著者の連絡先 .....................................................26
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 27
完全な著作権表示 .................................................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応答の同フィールドから値を取得します。
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.
この拡張は、ダイアログ内の一方のUAだけが対応している場合にも動作します。UACとUASがそれぞれ対応するかどうかに応じて、4通りの処理があります。説明を簡潔にするため、この節では両側が拡張に対応する場合の基本動作を説明します。
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'を含むSupportedヘッダーフィールドを設定します。
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ヘッダーフィールドがまだなければ追加できます。また、以下の説明に従って既存の各フィールドの値を変更できます。
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ヘッダーフィールドに設定します。このフィールドには'refresher'パラメーターも含まれ、現在のUACとUASのどちらが更新を行うかを示します。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だけが拡張に対応する場合には、この基本的な流れに追加の処理が必要です。たとえば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.
セッションタイマーが更新するのはセッションであり、そのセッションを確立したダイアログではありません。もちろん両者は関連しています。セッションが期限切れになると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ヘッダーフィールドと同様に、delta-timeを含みます。
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分）を推奨します (SHOULD)。つまり、SIP要素は90秒を超えるあらゆる期間の値を処理できなければなりません (MUST)。一方、このフィールドを挿入する要素は30分未満の値を選ぶべきではありません (SHOULD NOT)。
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分を選びました。ただし、ネットワーク帯域幅や遅延、計算能力、メモリ量、ネットワークトポロジー、アプリケーションの状況など、多くの要因で適切な値が変わるため、30分という最小値はMUSTではなくSHOULDとして示しています (MUST) (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ヘッダーフィールドのデフォルト値は定義されていません。このフィールドがない場合、この仕様の機構ではセッションに有効期限を設定しないことを意味します。ただし、ローカル設定タイマーなど、この仕様で定義しない別の機構が適用される場合があります。
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")
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'が予約されています。delta-secondsと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は、Session-ExpiresおよびMin-SEヘッダーフィールドについて、[2]の表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ヘッダーフィールドは、セッション間隔の最小値をdelta-seconds単位で示します。INVITEまたはUPDATE要求に設定した場合、そのセッションで使用できるセッション間隔の最小値を示します。要求または応答にこのフィールドがある場合、その値は90秒以上でなければなりません (MUST NOT)。
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)
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 Interval Too Small）応答コードを導入します。要求のSession-Expiresヘッダーフィールドの期間がサーバーの最小タイマーを下回る場合、UASまたはプロキシがこの応答を生成します。422応答には、そのサーバーの最小タイマーを示すMin-SEヘッダーフィールドを含めなければなりません (MUST)。
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'を列挙したSupportedヘッダーフィールドを含めなければなりません (MUST)。このセッションでタイマーの使用を要求していない場合も同様です (MUST)。
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'のRequireヘッダーフィールドを要求に含めてもよいです (MAY)。これは、UASに更新の実行を要求するのではなく、拡張への対応だけを要求します。要求を正しく処理するためにプロキシも対応することを示す場合、UACは値'timer'のProxy-Requireヘッダーフィールドも含めてもよいです (MAY)。ただし、UACがRequireまたはProxy-Requireを使うことは推奨されません (SHOULD NOT)。UACだけが拡張に対応していても動作するため、これらは不要です。RequireまたはProxy-Requireに'timer'が含まれている場合でも、Supportedヘッダーフィールドに'timer'を含めなければなりません (MUST)。
A UAC MAY include the Min-SE header field in the initial INVITE request.
UACは、初回INVITE要求にMin-SEヘッダーフィールドを含めてもよいです (MAY)。
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ヘッダーフィールドを含めてもよいです (MAY)。その値はUACが希望するセッション間隔を示します。初回セッション更新要求にMin-SEヘッダーフィールドがある場合、Session-Expiresの値はMin-SEの値以上でなければなりません (MUST)。
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は値'uac'のrefresherパラメーターを含めてもよいです (MAY)。ただし、以下で説明するネゴシエーション機構で選択できるよう、パラメーターを省略することを推奨します (SHOULD)。
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応答には、値'timer'のRequireヘッダーフィールドが含まれる場合と含まれない場合があります。含まれている場合、UACは応答を処理するためにSession-Expiresヘッダーフィールドを確認しなければなりません (MUST)。
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'.
応答のRequireヘッダーフィールドに'timer'が含まれる場合、Session-Expiresヘッダーフィールドも必ず存在します。要求にこのフィールドがなかった場合でも、UACは応答にSession-Expiresヘッダーフィールドが含まれる場合に備えなければなりません (MUST)。Session-Expiresの'refresher'パラメーターは更新担当者を示すため、UACはその値を更新担当者として設定しなければなりません (MUST)。値が'uac'ならUACが更新します。UACがセッションタイマーを要求したにもかかわらず、UASが拡張に対応せず、プロキシも要求しなかった場合、2xx応答にはRequireもSession-Expiresも含まれないことがあります。この場合もUACが自身のためにタイマーを使うなら、更新を実行します。その際は、2xx応答にSession-Expiresがあり、その値が要求時と同じで'refresher'が'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ヘッダーフィールドがない場合、セッション有効期限は設定されず、更新も送信しません。初回または後続のセッション更新要求のどちらに対する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のdelta-timeを、そのセッションの間隔として記憶します。1つのINVITEから複数のダイアログが確立された場合、各ダイアログのセッション間隔は異なっていても、また設定されていなくてもかまいません。UACは、最新の2xx応答の'refresher'パラメーターに基づき、自身とピアのどちらが更新担当者かも記憶します。
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が有効期限を越えてセッションを継続する場合、有効期限前に更新を生成しなければなりません (MUST)。セッション間隔の半分が経過した時点で更新を送信することを推奨します (SHOULD)。追加の手順はセクション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（Session Interval Too Small）の場合、UACは要求を再試行してもよいです (MAY)。再試行手順はセクション7.4で説明します。この要求は新しいトランザクションとなり、Call-ID、To、Fromの値は前の要求と同じにすべきです (SHOULD)。CSeqには、前より1大きい新しいシーケンス番号を設定します。
The values of Supported, Require, and Proxy-Require used in the initial Session refresh request MUST be used.
初回のセッション更新要求で使用したSupported、Require、Proxy-Requireの各値を後続要求でも使用しなければなりません (MUST)。
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.
同じダイアログの前のセッション更新要求に対して422応答を受信したことがある場合、または同じダイアログでMin-SEヘッダーフィールドを含むセッション更新要求を受信した場合、UACはそのダイアログの後続セッション更新要求にMin-SEヘッダーフィールドを挿入しなければなりません (MUST)。まだダイアログが確立されていない場合も、同じCall-IDのINVITE要求に対して422応答を受信したことがあれば、UACはINVITE要求にMin-SEヘッダーフィールドを挿入しなければなりません (MUST)。
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応答で返された値とセッション更新要求で受信した値のうち最大の値でなければなりません (MUST)。ダイアログが未確立の場合、同じ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はさらに引き上げてもよいです (MAY)。
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ヘッダーフィールドを含めるべきです (SHOULD)。含める場合、その値はMin-SE（フィールドがない場合のデフォルトは90秒）と現在のセッション間隔の大きい方にすべきです (SHOULD)。この値を含めると、セクション11で説明する特定のサービス拒否攻撃を防げます。セッション間隔をダイアログ途中で変更する例外的で単発の状況に限り、この推奨レベル (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'に設定することを推奨します (SHOULD)。こうすれば更新のたびに担当者が変わりません。役割を明示的に変更したい場合、相手がセッションタイマーに対応していると分かっていれば、値'uas'を使ってもよいです (MAY)。相手から値'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もUPDATEも、それぞれ通常のre-INVITE、UPDATEとして扱います。ピアがUPDATEメソッドに対応すると分かっている場合、re-INVITEよりUPDATEを使うことを推奨します (SHOULD)。UAは、ピアから値'UPDATE'のAllowヘッダーフィールドを受け取った場合、またはダイアログ途中でOPTIONS要求を送った場合に対応状況を判定できます。UPDATE要求にはオファー[4]を含めないことを推奨します (SHOULD)。セッションの詳細に変更がなくても、re-INVITEにはオファーを含めるべきです (SHOULD)。その場合、オファーは変更がないことを示さなければなりません (MUST)。SDPでは、ピアに送った前のSDPメッセージと同じoriginフィールド値を含めます。セッション更新要求への応答として交換するanswerも同様で、変更がなければそのことを示さなければなりません (MUST)。
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.
セッションタイマーは主に、通話やダイアログの状態を保持するプロキシサーバーに関係します。ただし、トランザクション状態は認識していても通話やダイアログの状態を保持しないプロキシも、ここで説明する規則に従ってもよいです (MAY)。ステートレスプロキシはセッションタイマーを要求してはなりません (MUST NOT)。セッションタイマーを要求するプロキシは、更新を受け取れるようrecord-routeを設定すべきです (SHOULD)。
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ヘッダーフィールドがあることをプロキシが確認します。要求にフィールドがなければ、プロキシは転送前に追加してもよいです (MAY)。値にはプロキシが希望する有効期間を設定できますが、要求にMin-SEヘッダーフィールドがある場合、その値より短くしてはなりません。プロキシはヘッダーフィールド値に'refresher'パラメーターを含めてはなりません (MUST NOT)。
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ヘッダーフィールドが既にある場合、プロキシはその値を短縮してもよいですが (MAY)、要求にMin-SEがあるときは、その値より短く設定してはなりません (MUST NOT)。Session-Expiresの値がMin-SE以上の場合（Min-SEがないときのデフォルトは90秒です）、プロキシはSession-Expiresの値を増やしてはなりません (MUST NOT)。Session-ExpiresがMin-SEより小さい場合（下記のようにプロキシがMin-SEを引き上げた可能性があります）、プロキシはSession-ExpiresをMin-SEと同じ値に引き上げなければなりません (MUST)。プロキシはSession-Expiresヘッダーフィールドの'refresher'パラメーターを挿入または変更してはなりません (MUST NOT)。
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.
要求のSupportedヘッダーフィールドに'timer'が含まれる場合、Session-Expiresの間隔がプロキシのローカルポリシーで定めた最小間隔を下回れば、プロキシは422（Session Interval Too Small）応答でINVITE要求を拒否してもよいです (MAY)。422応答を送信するときは、プロキシ自身の最小間隔を示すMin-SEヘッダーフィールドを含めなければなりません (MUST)。この最小間隔は90秒未満であってはなりません (MUST NOT)。
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ヘッダーフィールドを挿入すべきです (SHOULD)。Min-SEが既にある場合は最小間隔まで引き上げるべきですが (SHOULD)、値を引き下げてはなりません (MUST NOT)。次にプロキシは、上記のとおりSession-ExpiresをMin-SEと同じ値に引き上げなければなりません (MUST)。要求に値'timer'のSupportedヘッダーフィールドが含まれる場合、プロキシは転送する要求にMin-SEを挿入したり、既存のヘッダーフィールドの値を変更したりしてはなりません (MUST NOT)。これはセクション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値をトランザクションの間、記憶しなければなりません (MUST)。この情報はトランザクションの間保持しなければなりません (MUST)。
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ヘッダーフィールドがあったかを記憶しなければなりません (MUST)。要求にこのフィールドがなかった場合、プロキシは値'timer'のRequireヘッダーフィールドを要求に追加してもよいです (MAY)。ただし、この方法は推奨されません (SHOULD NOT)。こうすると、プロキシはセッションタイマーの使用を要求できます。要求にSupportedヘッダーフィールドがあれば、この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ヘッダーフィールドを応答に挿入しなければなりません (MUST)。'refresher'パラメーターを'uac'に設定しなければなりません (MUST)。応答にRequireヘッダーフィールドがあれば'timer'オプションタグを追加しなければなりません (MUST)。Requireがなければ、その値を持つ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応答を上流へ転送した時刻にセッション間隔を加えて有効期限を計算します。この有効期限で、そのセッションに既に設定されている有効期限を更新しなければなりません (MUST)。上流へ転送する2xx応答のSession-Expiresには'refresher'パラメーターがあり、どのUAが更新を実行するかを示します。1つの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ヘッダーフィールドの値を変更してはなりません (MUST NOT)。
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.
現在時刻がセッション有効期限に達したか過ぎた場合、プロキシは関連する呼状態を削除してもよく (MAY)、その呼に関連するリソースを解放してもよいです (MAY)。UAとは異なり、BYEを送信してはなりません (MUST NOT)。
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または要求経路上のプロキシが要求するセッションタイマーに応答する必要があります。また、UAS自身がセッションタイマーの使用を要求する場合もあります。
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.
受信要求に'timer'を含むSupportedヘッダーフィールドとSession-Expiresがあり、その間隔がUASのローカルポリシーで定めた最小値を下回る場合、UASは422（Session Interval Too Small）応答でINVITE要求を拒否してもよいです (MAY)。422応答を送信するときは、UAS自身の最小間隔を示すMin-SEヘッダーフィールドを含めなければなりません (MUST)。この最小間隔は90秒未満であってはなりません (MUST NOT)。
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は値を短縮してもよいですが (MAY)、要求にMin-SEがある場合はその値より短く設定してはなりません (MUST NOT)。Min-SEがなければ値を短縮してもよいですが (MAY)、90秒未満に設定してはなりません (MUST NOT)。UASはSession-Expiresヘッダーフィールドの値を増やしてはなりません (MUST NOT)。
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は2xx応答にSession-Expiresヘッダーフィールドを含めて、セッションタイマーを要求できます。要求にMin-SEヘッダーフィールドがある場合、その値より短い期間を設定してはなりません (MUST NOT)。
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ヘッダーフィールドに'refresher'パラメーターを設定しなければなりません (MUST)。この値は、ダイアログの更新をどちらが実行するかを示します。応答値は、要求中の同パラメーターの値とUACがセッションタイマー拡張に対応しているかどうかに基づきます。要求のSupportedヘッダーフィールドに'timer'オプションタグがあれば、UACは拡張に対応しています。表2に応答値の決め方を示します。2列目の'none'は要求に'refresher'パラメーターがなかったことを示します。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は自身とUACのどちらが更新するかを決められます。ただし、表に示すとおり、UACが更新担当者を選んでいた場合、UASはその選択を上書きできません。
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ヘッダーフィールドの'refresher'値が'uac'の場合、UASは値'timer'のRequireヘッダーフィールドを応答に含めなければなりません (MUST)。更新を行うのはUACなので、UACがこのことを知るために応答を処理する必要があるからです。応答の'refresher'値が'uas'で、要求のSupportedヘッダーフィールドに'timer'があった場合、UASは値'timer'のRequireヘッダーフィールドを応答に含めるべきです (SHOULD)。この場合、UACは更新しませんが、更新を受信できなければBYEを送信することになっています。UACがBYEを送信しなくても呼は成功するため、ここでRequireの挿入はこの場合、必須要件ではなく、推奨にとどまります (SHOULD)。
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応答にあるSession-Expiresのdelta-timeを設定します。また、同じ応答の更新担当者パラメーターに基づいて、自身とピアのどちらが更新を行うかを記憶します。最新の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が有効期限後もセッションを継続する場合、有効期限前に更新を生成しなければなりません (MUST)。セッション間隔の半分が経過した時点で更新を送ることを推奨します (SHOULD)。追加の手順はセクション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応答を受信することがあります。有効期限自体は変わっていないため、Session-Expiresに現在のセッション間隔より大きな値を設定する場合でも、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 [2]のセクション12.2.1.2に従ってBYE要求を送信します。セッション更新要求が2xx応答を生成せず（その結果、セッションが更新されず）、408または481以外の応答を受信した場合、UACはその応答コード固有の規則に従い、可能であれば再試行すべきです (SHOULD)。たとえば応答が401なら、新しい資格情報を使って再試行します。ただし、サーバーが同じエラー応答を示す場合、UACは要求を繰り返し再試行すべきではありません (SHOULD NOT)。
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を送信すべきです (SHOULD)。有効期限より前の時間は、32秒とセッション間隔の3分の1のうち短い方を推奨します (SHOULD)。
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がサービス拒否攻撃を仕掛ける可能性があります。ただし、この仕様の機構が攻撃を防ぎます。
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.
まず、不正なUACがUASに非常に短い間隔で更新させようとする場合を考えます。そのために、UACは短い期間と'refresher'値'uas'を持つSession-ExpiresヘッダーフィールドをINVITEに挿入し、Supportedヘッダーフィールドも含めたとします。この短いタイマーに異議を唱えるUASまたはプロキシは422で要求を拒否し、攻撃を防ぎます。Supportedヘッダーフィールドがなければ、プロキシは転送前に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.
次に、不正なUASがUACに非常に短い間隔で更新させようとする場合を考えます。この攻撃にはUACがセッションタイマーに対応している必要があります。初回INVITEが不正なUASに届き、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機能は適しません。代わりにホップ単位の機構で完全性を保護する必要があります。そのため、Session-Expiresヘッダーフィールドまたは値'timer'のSupportedヘッダーフィールドを含む要求は、TLSを使って送信することを推奨します (SHOULD)。各ホップでセキュリティを適用して初めて十分に保護されるため、この拡張と併せてSIPS URIスキームを使うことを推奨します (SHOULD)。Record-Routeを設定してセッションタイマーを要求するプロキシは、SIPS URIでRecord-Routeを設定すべきです (SHOULD)。要求または応答にSession-Expiresを挿入するUAは、SIPS URIのContact URIを含めるべきです (SHOULD)。
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つの新しいヘッダーフィールド、新しい応答コード、新しいオプションタグを定義します。これらの登録に関するIANA手続きはSIP [2]で定義されています。
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。短縮形式：なし。Session-Expiresヘッダーフィールドの登録情報は次のとおりです：
RFC Number: RFC 4028 Header Name: Session-Expires Compact Form: x
RFC番号：RFC 4028。ヘッダー名：Session-Expires。短縮形式：x。
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。デフォルトの理由句：Session Interval Too Small。RFC番号：RFC 4028。
The following is the registration for the 'timer' option tag:
'timer'オプションタグの登録情報は次のとおりです：
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。説明：このオプションタグはセッションタイマー拡張への対応を示します。要求または応答のSupportedヘッダーフィールドに含まれる場合、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の両方がセッションタイマー拡張に対応しています。AliceというUACが生成する初回INVITE（メッセージ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)
（Aliceの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 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 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 この応答には値3600のMin-SEヘッダーフィールドが含まれます。その後Aliceは要求を再試行します。今回は、同じ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
(Alice's SDP not shown)
（Aliceの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はrecord-routeを設定します。セッション間隔がP1の許容範囲になったため、P1は要求をP2へ転送します（メッセージ5）。しかし、P2が設定した最小値4000秒を下回るため、P2は応答コード422で要求を拒否し（メッセージ6）、値4000のMin-SEヘッダーフィールドを含めます。Aliceは再びINVITEを再試行します。今回は、INVITEの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-routeを設定しますが、P2は設定しません（通常はこのようになりません。セッションタイマーを要求したP2は、後続要求にもrecord-routeを設定すると考えられます）。UASは要求を受信し、要求のSession-Expiresを応答にコピーして、値'uac'のrefresherパラメーターを追加します。この200 OKはAliceに返されます。Aliceが受け取る応答（メッセージ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)
（Bobの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):
AliceはACK（メッセージ16）を生成し、P1経由でBobに送ります。更新担当者はAliceなので、約2000秒後にAliceはセッションを更新するUPDATE要求を送信します。これは確立済みのダイアログ内の要求であり、そのダイアログではAliceは422応答も要求も受信していないため、この要求（メッセージ18）にMin-SEヘッダーフィールドはありません：
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:
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> この要求はP1経由でBobに転送されます。BobはSession-Expiresヘッダーフィールドを応答にコピーして200 OKを生成します。応答はP1を経由してAliceに届きます。Aliceが受け取る応答（メッセージ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.
その後まもなくAliceのUAがクラッシュし、セッション更新要求を送信できなくなります。3968秒後、Bobはタイムアウトを検出し、BYE要求（メッセージ22）をP1へ送信します。P1はAliceへの配信を試みますが、UAがクラッシュしているため失敗します。その後、P1は408（Request Timeout）をBobに返します。
The authors wish to thank Brett Tate for his contributions to this work. Brian Rosen completed the editing of the document.
著者は、この作業への貢献についてBrett Tateに感謝します。Brian Rosenが文書の編集を完了しました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[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., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[6] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[6] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
Authors' Addresses
著者の連絡先
Steve Donovan Cisco Systems, Inc. 2200 E. President George Bush Turnpike Richardson, Texas 75082 US
Steve Donovan Cisco Systems, Inc. 2200 E. President George Bush Turnpike Richardson, Texas 75082 US
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に定められた権利、ライセンス、制限に従います。同BCPに記載された場合を除き、著者はすべての権利を保持します。
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.
この文書およびここに含まれる情報は「現状有姿」で提供されます。貢献者、その貢献者が代表する組織または後援を受ける組織（該当する場合）、Internet Society、およびInternet Engineering Task Forceは、明示または黙示を問わず、すべての保証を否認します。これには、ここに含まれる情報の使用がいかなる権利も侵害しないこと、商品性の黙示保証、特定目的への適合性の黙示保証が含まれますが、これらに限定されません。
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に知らせるよう求めます。情報はietf-ipr@ietf.org宛てに送付してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能の資金は、現在Internet Societyが提供しています。