Network Working Group S. Donovan
Request for Comments: 4028 J. Rosenberg
Category: Standards Track Cisco Systems
April 2005
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).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document defines an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine whether the SIP session is still active. The extension defines two new header fields: Session-Expires, which conveys the lifetime of the session, and Min-SE, which conveys the minimum allowed value for the session timer.
本文档定义了会话启动协议（SIP）的扩展。此扩展允许通过重新邀请或更新请求定期刷新SIP会话。刷新允许用户代理和代理确定SIP会话是否仍处于活动状态。扩展定义了两个新的头字段：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
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
会话启动协议（SIP）[2]没有为其建立的会话定义保留机制。尽管用户代理可以通过使用特定于会话的机制来确定会话是否超时，但代理将无法这样做。结果是，调用有状态代理并不总是能够确定会话是否仍然处于活动状态。例如，当用户代理无法在会话结束时发送BYE消息，或者当BYE消息由于网络问题丢失时，呼叫状态代理将不知道会话何时结束。在这种情况下，call stateful代理将保留调用的状态，并且
has no method to determine when the call state information no longer applies.
没有确定何时调用状态信息不再适用的方法。
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会话定义了一个keepalive机制。UAs定期发送重新邀请或更新[3]请求（称为会话刷新请求）以保持会话活动。会话刷新请求的间隔通过此处定义的协商机制确定。如果在间隔过去之前未收到会话刷新请求，则认为会话已终止。两个UAs都应该发送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的扩展，该扩展定义了会话过期机制。定期刷新（通过重新邀请或更新）用于保持会话处于活动状态。该扩展与SIP具有足够的向后兼容性，只要对话中的两个参与者中的任何一个理解该扩展，它就可以工作。定义了两个新的头字段（会话到期和最小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.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可能”和“可选”将按照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从其发送的会话刷新请求的2xx响应中的会话到期报头字段中获取该值。代理和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.
最小计时器：由于mid对话请求的处理负载，所有元素（代理、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.
初始会话刷新请求：使用特定呼叫ID值发送的第一个会话刷新请求。
Subsequent Session Refresh Request: Any session refresh request sent with a particular Call-ID after the initial session refresh request.
后续会话刷新请求：在初始会话刷新请求之后，使用特定调用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
此扩展的特性是，即使对话框中只有一个UA支持它，它也可以工作。处理这四个案例的步骤各不相同（UAC支持或不支持，UAS支持或不支持）。为了简单起见，本节
will describe basic operation in the case where both sides support the extension.
将描述在双方都支持扩展的情况下的基本操作。
A UAC starts by sending an INVITE. This includes a Supported header field with the option tag 'timer', indicating support for this extension.
UAC从发送邀请开始。这包括一个支持的标题字段，带有选项标记“timer”，表示支持此扩展。
This request passes through proxies, any one of which may have an interest in establishing a session timer. Each proxy can insert a Session-Expires header field and a Min-SE header field into the request (if none is already there) or alter the value of existing Session-Expires and Min-SE header fields as described below.
此请求通过代理传递，其中任何一个都可能对建立会话计时器感兴趣。每个代理都可以在请求中插入一个Session Expires标头字段和一个Min-SE标头字段（如果没有），或者如下所述更改现有Session Expires和Min-SE标头字段的值。
The Min-SE header field establishes the lower bound for the session refresh interval; i.e., the fastest rate any proxy servicing this request will be allowed to require. The purpose of this header field is to prevent hostile proxies from setting arbitrarily short refresh intervals so that their neighbors are overloaded. Each proxy processing the request can raise this lower bound (increase the period between refreshes) but is not allowed to lower it.
Min SE header字段建立会话刷新间隔的下限；i、 例如，为该请求提供服务的任何代理所允许的最快速率。此标头字段的目的是防止恶意代理设置任意短的刷新间隔，从而使其邻居过载。处理请求的每个代理都可以提高此下限（增加刷新间隔），但不允许降低此下限。
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标头字段确定会话刷新间隔的上限；i、 例如，处理请求后的时间段，对于该时间段，任何会话状态代理都必须为此会话保留其状态。为该请求提供服务的任何代理都可以降低该值，但不允许将其降低到Min SE header字段中指定的值以下。
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.
如果会话过期时间间隔对于代理来说太低（即，低于代理希望断言的最小SE值），代理将使用422响应拒绝请求。该响应包含一个Min SE header字段，标识它愿意支持的最小会话间隔。UAC将重试，这次将在请求中包含Min SE header字段。header字段包含它在之前收到的所有422个响应中观察到的最大的Min-SE header字段。这样，最小计时器满足路径上所有代理的约束。
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响应中的sessionexpires头字段中。Session Expires标头字段还包含一个“refresher”参数，该参数指示正在进行刷新的用户——当前为UAC的UA或当前为UAS的UA。当2xx响应通过代理链返回时，每个代理都可以观察最终会话间隔，但不能更改它。
From the Session-Expires header field in the response, both UAs know that a session timer is active, when it will expire, and who is refreshing. At some point before the expiration, the currently active refresher generates a session refresh request, which is a re-INVITE or UPDATE [3] request. If the refresher never gets a response to that session refresh request, it sends a BYE to terminate the session. Similarly, if the other side never gets the session refresh request before the session expires, it sends a BYE.
从响应中的Session Expires标头字段中，两个UAs都知道会话计时器处于活动状态、何时过期以及谁正在刷新。在到期前的某个时间点，当前活动的刷新程序生成会话刷新请求，这是一个重新邀请或更新[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.
扩展引入了除此基本流程之外的其他复杂性，以支持只有一个UAs支持的情况。其中一个复杂问题是，如果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会话的会话间隔。它只放在邀请或更新请求中，以及对邀请或更新的任何2xx响应中。与SIP Expires标头字段一样，它包含一个增量时间。
The absolute minimum for the Session-Expires header field is 90 seconds. This value represents a bit more than twice the duration that a SIP transaction can take in the event of a timeout. This allows sufficient time for a UA to attempt a refresh at the halfpoint of the session interval, and for that transaction to complete normally before the session expires. However, 1800 seconds (30 minutes) is RECOMMENDED as the value for the Session-Expires header field. In other words, SIP entities MUST be prepared to handle Session-Expires header field values of any duration greater than 90 seconds, but entities that insert the Session-Expires header field SHOULD NOT choose values of less than 30 minutes.
Session Expires标头字段的绝对最小值为90秒。该值表示在超时事件中SIP事务可花费的持续时间的两倍多一点。这使得UA有足够的时间在会话间隔的半点尝试刷新，并使该事务在会话到期之前正常完成。但是，建议将1800秒（30分钟）作为Session Expires标头字段的值。换句话说，SIP实体必须准备好处理任何持续时间大于90秒的Session Expires标头字段值，但插入Session Expires标头字段的实体不应选择小于30分钟的值。
Small session intervals can be destructive to the network. They cause excessive messaging traffic that affects both user agents and proxy servers. They increase the possibility of 'glare' that can occur when both user agents send a re-INVITE or UPDATE at the same time. Since the primary purpose of the session timer is to provide a means to time out state in SIP elements, very small values won't generally be needed. 30 minutes was chosen because 95% of phone calls are shorter than this duration. However, the 30 minute minimum is listed as a SHOULD, and not as a MUST, since the exact value for this number is dependent on many network factors, including network bandwidths and latencies, computing power, memory availability, network topology, and, of course, the application scenario. After all, SIP can set up any kind of session, not just a phone call. At the time of publication of this document, 30 minutes seems appropriate. Advances in technologies may result in the number being excessively large five years in the future.
较小的会话间隔可能会破坏网络。它们会导致过多的消息传递流量，从而影响用户代理和代理服务器。它们增加了当两个用户代理同时发送重新邀请或更新时发生“眩光”的可能性。由于会话计时器的主要目的是提供在SIP元素中超时状态的方法，因此通常不需要非常小的值。之所以选择30分钟，是因为95%的电话通话时间短于此时间。然而，30分钟的最短时间是应该列出的，而不是必须列出的，因为这个数字的确切值取决于许多网络因素，包括网络带宽和延迟、计算能力、内存可用性、网络拓扑，当然还有应用场景。毕竟，SIP可以建立任何类型的会话，而不仅仅是一个电话。在本文件出版时，30分钟似乎是合适的。技术的进步可能会导致未来五年的数量过多。
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.
会话过期标头字段的默认值未定义。这意味着，使用本规范中定义的机制，缺少sessionexpires头字段意味着Session不会过期。请注意，本规范中未定义的其他机制（如本地配置的计时器）可能适用。
The syntax of the Session-Expires header field is as follows:
Session Expires标头字段的语法如下所示：
Session-Expires = ("Session-Expires" / "x") HCOLON delta-seconds
*(SEMI se-params)
se-params = refresher-param / generic-param
refresher-param = "refresher" EQUAL ("uas" / "uac")
Session-Expires = ("Session-Expires" / "x") HCOLON delta-seconds
*(SEMI se-params)
se-params = refresher-param / generic-param
refresher-param = "refresher" EQUAL ("uas" / "uac")
Note that a compact form, the letter x, has been reserved for Session-Expires. The BNF for delta-seconds and generic-param is defined in Section 25 of RFC 3261 [2].
请注意，已为会话过期保留了一个紧凑的表单，即字母x。RFC 3261[2]第25节定义了增量秒和通用参数的BNF。
Table 1 is an extension of Tables 2 and 3 in [2] for the Session-Expires and Min-SE header fields. The column 'PRA' is for the PRACK method [7], 'UPD' is for the UPDATE method [3], 'SUB' is for the SUBSCRIBE method [8], and 'NOT' is for the NOTIFY method [8].
表1是[2]中表2和表3对会话到期和最小SE头字段的扩展。列“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 | - | - |
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
| 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：会话到期和最小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 header字段以增量秒为单位指示会话间隔的最小值。在INVITE或UPDATE请求中使用时，它表示可用于该会话的会话间隔的最小值。当出现在请求或响应中时，其值不得小于90秒。
When the header field is not present, its default value for is 90 seconds.
当标题字段不存在时，其默认值为90秒。
The Min-SE header field MUST NOT be used in responses except for those with a 422 response code. It indicates the minimum value of the session interval that the server is willing to accept.
除带有422响应代码的响应外，不得在响应中使用Min SE header字段。它指示服务器愿意接受的会话间隔的最小值。
The syntax of the Min-SE header field is as follows:
Min SE header字段的语法如下所示：
Min-SE = "Min-SE" HCOLON delta-seconds *(SEMI generic-param)
Min SE=“Min SE”HCOLON增量秒*（半通用参数）
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 header字段。
A UAC that supports the session timer extension defined here MUST include a Supported header field in each request (except ACK), listing the option tag 'timer' [2]. It MUST do so even if the UAC is not requesting usage of the session timer for this session.
支持此处定义的会话计时器扩展的UAC必须在每个请求（ACK除外）中包含一个受支持的标头字段，其中列出选项标记“timer”[2]。即使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可以在请求中包含一个Require头字段，该字段的值为“timer”，以指示UAS必须支持会话计时器才能参与会话。这并不意味着UAC要求UAS执行刷新，只是要求UAS支持扩展。此外，UAC可以在请求中包括一个值为“timer”的Proxy Require报头字段，以指示代理必须支持会话计时器才能正确处理请求。但是，不建议UAC使用Require或Proxy Require。不需要它们，因为即使只有UAC支持扩展，扩展也可以工作。即使存在包含“timer”的Require或Proxy Require标头字段，也必须包含包含“timer”的受支持标头字段。
A UAC MAY include the Min-SE header field in the initial INVITE request.
UAC可以在初始INVITE请求中包含Min SE头字段。
A UAC MAY include a Session-Expires header field in an initial session refresh request if it wants a session timer applied to the session. The value of this header field indicates the session interval desired by the UAC. If a Min-SE header is included in the initial session refresh request, the value of the Session-Expires MUST be greater than or equal to the value in Min-SE.
如果UAC希望将会话计时器应用于会话，则可以在初始会话刷新请求中包含会话到期报头字段。此标头字段的值表示UAC所需的会话间隔。如果初始会话刷新请求中包含Min-SE标头，则会话Expires的值必须大于或等于Min-SE中的值。
The UAC MAY include the refresher parameter with value 'uac' if it wants to perform the refreshes. However, it is RECOMMENDED that the parameter be omitted so that it can be selected by the negotiation mechanisms described below.
如果UAC想要执行刷新，它可以包括值为“UAC”的刷新器参数。但是，建议省略该参数，以便可以通过下面描述的协商机制选择该参数。
The session timer requires a UA to create and maintain state. This state includes the session interval, the session expiration, and the identity of the refresher. This state is associated with the dialog on which the session has been negotiated.
会话计时器需要UA来创建和维护状态。此状态包括会话间隔、会话到期和刷新器的标识。此状态与已协商会话的对话框相关联。
When a 2xx response to a session refresh request arrives, it may or may not contain a Require header field with the value 'timer'. If it does, the UAC MUST look for the Session-Expires header field to process the response.
当对会话刷新请求的2xx响应到达时，它可能包含也可能不包含值为“timer”的Require头字段。如果确实如此，UAC必须查找Session Expires标头字段以处理响应。
If there was a Require header field in the response with the value 'timer', the Session-Expires header field will always be present. UACs MUST be prepared to receive a Session-Expires header field in a response, even if none were present in the request. The 'refresher' parameter will be present in the Session-Expires header field, indicating who will perform the refreshes. The UAC MUST set the identity of the refresher to the value of this parameter. If the parameter contains the value 'uac', the UAC will perform them. It is possible that the UAC requested the session timer (and thus included a Session-Expires header field in the request) and that there was no Require or Session-Expires header field in the 2xx response. This will happen when the UAS doesn't support the session timer extension and only the UAC has asked for a session timer (no proxies have requested it). In this case, if the UAC still wishes to use the session timer (which is purely for its benefit alone), it has to perform them. To do this, the UAC follows the procedures defined in this specification as if the Session-Expires header field were in the 2xx response, and its value was the same as that in the request, but with a refresher parameter of 'uac'.
如果响应中有一个值为“timer”的Require标头字段，则会话过期标头字段将始终存在。UACs必须准备好接收响应中的Session Expires标头字段，即使请求中不存在任何字段。“refresher”参数将出现在Session Expires标头字段中，指示谁将执行刷新。UAC必须将刷新器的标识设置为此参数的值。如果参数包含值“uac”，uac将执行这些操作。UAC可能请求了会话计时器（因此在请求中包含了一个会话到期报头字段），并且2xx响应中没有Require或session Expires报头字段。当UAS不支持会话计时器扩展，并且只有UAC请求了会话计时器（没有代理请求它）时，就会发生这种情况。在这种情况下，如果UAC仍然希望使用会话计时器（这纯粹是为了它的利益），它必须执行这些操作。为此，UAC遵循本规范中定义的过程，就好像2xx响应中的Session Expires标头字段一样，其值与请求中的值相同，但具有刷新参数“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。这意味着会话计时器可以在mid对话框中“关闭”，方法是在没有会话过期标头字段的情况下接收响应。
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还记得它或它的对等方是否是会话的复习者。
If the UAC must perform the refreshes, it computes the session expiration for that session. The session expiration is the time of reception of the last 2xx response to a session refresh request on that dialog plus the session interval for that session. If the UA seeks to continue with the session beyond the session expiration, it MUST generate a refresh before the session expiration. It is
如果UAC必须执行刷新，它将计算该会话的会话到期时间。会话过期时间是在该对话框上接收到对会话刷新请求的最后2xx响应的时间加上该会话的会话间隔。如果UA试图在会话过期之后继续会话，则必须在会话过期之前生成刷新。它是
RECOMMENDED that this refresh be sent once half the session interval has elapsed. Additional procedures for this refresh are described in Section 10.
建议在会话间隔超过一半后发送此刷新。第10节介绍了此刷新的其他步骤。
Similarly, a re-INVITE or UPDATE request sent within a dialog for purposes other than session refreshes will also have the effect of refreshing the session, and its processing will follow the procedures defined in this specification.
类似地，出于会话刷新以外的目的在对话框中发送的重新邀请或更新请求也将具有刷新会话的效果，其处理将遵循本规范中定义的过程。
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、To和From相同的值，但CSeq应包含比前一请求高一个的新序列号。
The values of Supported, Require, and Proxy-Require used in the initial Session refresh request MUST be used.
必须使用初始会话刷新请求中使用的Supported、Require和Proxy Require的值。
The UAC MUST insert the Min-SE header field into a session refresh request for a particular dialog if it has ever received a 422 response to a previous session refresh request on the same dialog, or if it has received a session refresh request on that dialog that contained a Min-SE header field. Similarly, if no dialog has been established yet, a UAC MUST insert the Min-SE header field into an INVITE request if it has ever received a 422 response to a previous INVITE request with the same Call-ID.
如果UAC曾经在同一对话框上收到对上一个会话刷新请求的422响应，或者如果UAC在该对话框上收到包含Min SE头字段的会话刷新请求，则必须将Min SE头字段插入特定对话框的会话刷新请求中。类似地，如果尚未建立对话框，UAC必须在INVITE请求中插入Min SE header字段，前提是它曾经收到对具有相同调用ID的先前INVITE请求的422响应。
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 header字段的值必须是所有422响应中返回的所有Min SE header字段值中的最大值，或者如果已建立对话框，则在同一对话框中接收到的Min SE header字段值。如果未建立对话框，则Min-SE标头字段值将设置为所有422响应中返回的具有相同调用ID的INVITE请求的所有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 header字段（回想一下，不存在时的默认值是90秒）和当前会话间隔的最大值。如第11节所述，包含具有此值的Session Expires标头字段可避免某些拒绝服务攻击。因此，UA只应在需要在对话中间更改会话间隔的异常和单一情况下忽略应。
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”。这样，刷新者的角色不会在每次刷新时更改。但是，如果它希望显式更改角色，如果它知道另一方支持会话计时器，则可以使用“uas”值。它可以通过从它的对等方接收到一个包含值“timer”的受支持标头字段的请求来了解这一点。如果它试图重新选择角色，则可能会忽略该参数。
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.
为刷新会话而生成的重新邀请是正常的重新邀请，为刷新会话而生成的更新是正常的更新。如果UAC知道其对等方支持更新方法，建议使用更新而不是重新邀请。如果UA从其对等方看到值为“UPDATE”的Allow header字段，或通过mid对话选项请求，则UA可以进行此确定。建议更新请求不包含要约[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.
会话计时器最感兴趣的是调用有状态代理服务器（即，维护通过它们建立的调用和对话框状态的服务器）。但是，有状态代理服务器（即，知道事务状态但不保留调用或对话框状态的服务器）也可以遵循此处描述的规则。无状态代理不得尝试请求会话计时器。请求会话计时器的代理应该记录路由，因为如果不记录，它们将不会收到刷新。
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标头字段可能包含代理希望的任何期望过期时间，但持续时间不得低于请求中Min-SE标头字段中的值（如果存在）。代理不得在标头字段值中包含刷新器参数。
If the request already had a Session-Expires header field, the proxy MAY reduce its value but MUST NOT set it to a duration lower than the value in the Min-SE header field in the request, if it is present. If the value of the Session-Expires header field is greater than or equal to the value in the Min-SE header field (recall that the default is 90 seconds when the Min-SE header field is not present), the proxy MUST NOT increase the value of the Session-Expires header field. If the value of the Session-Expires header field is lower than the value of the Min-SE header field (possibly because the proxy increased the value of the Min-SE header field, as described below), the proxy MUST increase the value of the Session-Expires header field to make it equal to Min-SE header field value. The proxy MUST NOT insert or modify the value of the 'refresher' parameter in the Session-Expires header field.
如果请求已经有一个Session Expires标头字段，则代理可以减少其值，但不得将其设置为低于请求中Min SE标头字段（如果存在）中的值的持续时间。如果Session Expires标头字段的值大于或等于Min-SE标头字段的值（回想一下，当Min-SE标头字段不存在时，默认值为90秒），则代理服务器不得增加Session Expires标头字段的值。如果Session Expires标头字段的值低于Min-SE标头字段的值（可能是因为代理增加了Min-SE标头字段的值，如下所述），则代理必须增加Session Expires标头字段的值，使其等于Min-SE标头字段的值。代理不得在Session Expires标头字段中插入或修改“refresher”参数的值。
If the request contains a Supported header field with a value 'timer', the proxy MAY reject the INVITE request with a 422 (Session Interval Too Small) response if the session interval in the Session-Expires header field is smaller than the minimum interval defined by the proxy's local policy. When sending the 422 response, the proxy MUST include a Min-SE header field with the value of its minimum interval. That minimum MUST NOT be lower than 90 seconds.
如果请求包含值为“timer”的受支持标头字段，则如果会话过期标头字段中的会话间隔小于代理的本地策略定义的最小间隔，则代理可以使用422（会话间隔太小）响应拒绝INVITE请求。当发送422响应时，代理必须包括一个Min-SE头字段，该字段的值为其最小间隔。该最小值不得低于90秒。
If the request doesn't indicate support for the session timer but contains a session interval that is too small, the proxy cannot usefully reject the request, as this would result in a call failure. Rather, the proxy SHOULD insert a Min-SE header field containing its minimum interval. If a Min-SE header field is already present, the proxy SHOULD increase (but MUST NOT decrease) the value to its minimum interval. The proxy MUST then increase the Session-Expires
如果请求不表示支持会话计时器，但包含太小的会话间隔，则代理无法有效地拒绝该请求，因为这将导致调用失败。相反，代理应该插入一个包含其最小间隔的Min SE头字段。如果已存在Min SE标头字段，则代理应将该值增加（但不得减少）到其最小间隔。然后，代理必须增加会话到期时间
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标题字段中的值，如上所述。如果代理请求包含值为“timer”的受支持标头字段，则代理不得在代理请求中插入Min-SE标头字段或修改现有标头字段的值。这是防止第11节所述的某些拒绝服务攻击所必需的。
Assuming that the proxy has requested a session timer (and thus has possibly inserted the Session-Expires header field or reduced it), the proxy MUST remember that it is using a session timer, and also remember the value of the Session-Expires header field from the proxied request. This MUST be remembered for the duration of the transaction.
假设代理请求了会话计时器（因此可能插入了会话过期标头字段或减少了该字段），代理必须记住它正在使用会话计时器，还必须记住代理请求中会话过期标头字段的值。在交易期间必须记住这一点。
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”的受支持标头字段。如果请求不包含值为“timer”的受支持标头字段，则代理可以在请求中插入值为“timer”的Require标头字段。但是，不建议这样做。这允许代理坚持会话的会话计时器。如果请求中有受支持的标头字段，则不需要此标头字段；在这种情况下，代理将确保会话计时器可以用于会话。
When the final response to the request arrives, it is examined by the proxy.
当请求的最终响应到达时，代理将对其进行检查。
If the response does not contain a Session-Expires header field but the proxy remembers that it requested a session timer in the request (by inserting, modifying, or examining and accepting the Session-Expires header field in the proxied request), this means that the UAS did not support the session timer. If the proxy remembers that the UAC did not support the session timer either, the proxy forwards the response upstream normally. There is no session expiration for this session. If, however, the proxy remembers that the UAC did support the session timer, additional processing is needed.
如果响应不包含会话过期标头字段，但代理记得它在请求中请求了会话计时器（通过插入、修改或检查并接受代理请求中的会话过期标头字段），这意味着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'
因为响应中没有会话过期或Require header字段，所以代理知道它是第一个接收响应的会话计时器感知代理。此代理必须在响应中插入会话过期标头字段，该字段的值必须是从转发的请求中记住的值。它必须将'refresher'参数的值设置为'uac'。代理必须添加“计时器”
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.
选项标记到响应中的任何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响应向上游转发的时间加上会话间隔。此会话过期必须更新会话的任何现有会话过期。2xx响应中的会话到期报头字段中的刷新器参数将出现，并指示哪个UA正在执行刷新。对单个邀请可以有多个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.
在向上游转发之前，代理不得修改响应中接收到的会话过期标头字段的值（假设存在）。
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.
如果传入请求包含值为“timer”的受支持标头字段和会话过期标头字段，则如果会话过期标头字段中的会话间隔小于UAS本地策略定义的最小间隔，UAS可能会以422（会话间隔太小）响应拒绝INVITE请求。在发送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 header字段中的值（如果存在）的持续时间；否则，UAS可能会降低其值，但不得将其设置为低于90秒的持续时间。UAS不得增加Session Expires标头字段的值。
If the incoming request contains a Supported header field with a value 'timer' but does not contain a Session-Expires header, it means that the UAS is indicating support for timers but is not requesting one. The UAS may request a session timer in the 2XX response by including a Session-Expires header field. The value MUST NOT be set to a duration lower than the value in the Min-SE header field in the request, if it is present.
如果传入请求包含值为“timer”的受支持标头字段，但不包含Session Expires标头，则表示UAS表示支持计时器，但不请求计时器。UAS可通过包括会话到期报头字段，在2XX响应中请求会话计时器。如果存在，则该值不得设置为低于请求中Min SE header字段中的值的持续时间。
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参数的值。此值指定谁将对对话框执行刷新。该值基于请求中该参数的值，以及UAC是否支持会话计时器扩展。如果请求中受支持的标头字段中存在“timer”选项标记，UAC支持扩展。表2定义了如何设置响应中的值。第2列中的值“none”表示请求中没有刷新器参数。第三列中的“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
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：无人机行为
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的第四行描述了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
如果2xx响应中Session Expires标头字段中的refresher参数的值为“uac”，则UAS必须在响应中放置一个Require标头字段，该字段的值为“timer”。这是
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.
因为uac正在执行刷新，并且必须处理响应才能让uac知道这一点。如果2xx响应中的刷新器参数的值为“uas”，且请求中支持的标头字段包含值“timer”，则uas应在响应中放置一个值为“timer”的Require标头字段。在这种情况下，UAC不会刷新，但如果它从未收到刷新，则应该发送BYE。因为在UAC不发送BYE的情况下，呼叫仍然会成功，所以在这里插入Require是应该的，而不是必须的。
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响应没有Session Expires标头字段，则不存在Session Expires，并且不需要执行刷新。
If the UAS must refresh the session, it computes the session expiration. The session expiration is the time of transmission of the last 2xx response to a session refresh request on that dialog plus the session interval. If UA wishes to continue with the session beyond the session expiration, it MUST generate a refresh before the session expiration. It is RECOMMENDED that this refresh be sent once half the session interval has elapsed. Additional procedures for this refresh are described in Section 10.
如果UAS必须刷新会话，它将计算会话到期时间。会话过期时间是对该对话框上的会话刷新请求传输最后2xx响应的时间加上会话间隔。如果UA希望在会话过期之后继续会话，则必须在会话过期之前生成刷新。建议在会话间隔超过一半后发送此刷新。第10节介绍了此刷新的其他步骤。
The side generating a refresh does so according to the UAC procedures defined in Section 7. Note that only a 2xx response to a session refresh request extends the session expiration. This means that a UA could attempt a refresh and receive a 422 response with a Min-SE header field that contains a value much larger than the current session interval. The UA will still have to send a session refresh request before the session expiration (which has not changed), even though this request will contain a value of the Session-Expires that is much larger than the current session interval.
生成刷新的一方根据第7节中定义的UAC程序进行刷新。请注意，只有对会话刷新请求的2xx响应会延长会话到期时间。这意味着UA可以尝试刷新并接收422响应，该响应带有Min SE头字段，该字段包含的值远远大于当前会话间隔。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
如果会话刷新请求事务超时或生成408或481响应，则UAC根据RFC 3261[2]第12.2.1.2节发送BYE请求。如果会话刷新请求没有生成2xx响应（因此，会话没有被刷新），并且接收到408或481以外的响应，则UAC
SHOULD follow the rules specific to that response code and retry if possible. For example, if the response is a 401, the UAC would retry the request with new credentials. However, the UAC SHOULD NOT continuously retry the request if the server indicates the same error response.
应遵循特定于该响应代码的规则，并在可能的情况下重试。例如，如果响应是401，UAC将使用新凭据重试请求。但是，如果服务器指示相同的错误响应，UAC不应连续重试该请求。
Similarly, if the side not performing refreshes does not receive a session refresh request before the session expiration, it SHOULD send a BYE to terminate the session, slightly before the session expiration. The minimum of 32 seconds and one third of the session interval is RECOMMENDED.
类似地，如果不执行刷新的一方在会话到期之前没有收到会话刷新请求，它应该在会话到期之前发送BYE以终止会话。建议至少32秒和会话间隔的三分之一。
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元素的功能，以强制符合要求的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.
首先，考虑流氓UAC的情况，希望强制UAS快速生成刷新。为此，它将会话过期标头字段插入一个持续时间较短且刷新参数等于uas的INVITE中。假设它在请求中放置了一个受支持的头字段。UAS或任何反对此低定时器的代理将使用422拒绝请求，从而防止攻击。如果不存在受支持的标头字段，代理将在转发请求之前在请求中插入一个Min SE标头字段。因此，UAS不会选择低于路径上所有元素允许的最小值的会话计时器。这也可以防止攻击。
Next, consider the case of a rogue UAS that wishes to force a UAC to generate refreshes at a rapid rate. In that case, the UAC has to support session timer. The initial INVITE arrives at the rogue UAS,
接下来，考虑流氓UA的情况，希望强制UAC快速生成刷新。在这种情况下，UAC必须支持会话计时器。初始邀请到达流氓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.
它返回一个2xx，会话间隔非常小。UAC使用此计时器并快速发送刷新。第7.4节要求UAC将当前会话间隔复制到请求中的session Expires标头字段中。这使代理可以查看当前值。代理将拒绝该请求，并提供最小值较高的最小值，然后UAC将使用该最小值。注意，如果代理没有拒绝请求，而是使用Min-SE头字段代理请求，则仍然可能发生攻击。UAS可以在2xx响应中丢弃此标头字段，并强制UAC继续生成快速请求。
In a similar fashion, a rogue proxy cannot force either the UAC or UAS to generate refreshes unless the proxy remains on the signaling path and sees every request and response.
以类似的方式，恶意代理无法强制UAC或UAS生成刷新，除非代理保留在信令路径上并查看每个请求和响应。
An element that can observe and modify a request or response in transit can force rapid session refreshes. To prevent this, requests and responses have to be protected by message integrity. Since the session timer header fields are not end-to-end and are manipulated by proxies, the SIP S/MIME capabilities are not suitable for this task. Rather, integrity has to be protected by using hop-by-hop mechanisms. As a result, it is RECOMMENDED that an element send a request with a Session-Expires header field or a Supported header field with the value 'timer' by using TLS. As adequate protection is obtained only if security is applied on each hop, it is RECOMMENDED that the SIPS URI scheme be used in conjunction with this extension. This means that proxies that record-route and request session timer SHOULD record-route with a SIPS URI. A UA that inserts a Session-Expires header into a request or response SHOULD include a Contact URI that is a SIPS URI.
可以观察和修改传输中的请求或响应的元素可以强制快速会话刷新。为了防止这种情况，请求和响应必须受到消息完整性的保护。由于会话计时器标头字段不是端到端的，并且由代理操作，因此SIP S/MIME功能不适合此任务。相反，必须使用逐跳机制来保护完整性。因此，建议元素使用TLS发送带有Session Expires标头字段或值为“timer”的受支持标头字段的请求。由于只有在每个跃点上应用安全性时才能获得足够的保护，因此建议将SIPS URI方案与此扩展结合使用。这意味着记录路由和请求会话计时器的代理应该使用SIPS URI记录路由。在请求或响应中插入会话过期标头的UA应包括作为SIPS URI的联系人URI。
This extension defines two new header fields, a new response code, and a new option tag. SIP [2] defines IANA procedures for registering these.
此扩展定义了两个新的标题字段、一个新的响应代码和一个新的选项标记。SIP[2]定义了注册这些文件的IANA过程。
The following is the registration for the Min-SE header field:
以下是Min SE header字段的注册：
RFC Number: RFC 4028 Header Name: Min-SE Compact Form: none
RFC编号：RFC 4028标题名称：Min-SE Compact表单：无
The following is the registration for the Session-Expires header field:
以下是会话过期标头字段的注册：
RFC Number: RFC 4028 Header Name: Session-Expires Compact Form: x
RFC编号：RFC 4028标题名称：会话过期压缩格式：x
12.2. IANA Registration of the 422 (Session Interval Too Small) Response Code
12.2. IANA注册422（会话间隔太小）响应代码
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可以根据该规范执行刷新。请求中包含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 | | |
|----------->| | |
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 | |
| |<------------------------|
| |(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 | |
| |------------------------>|
|(21) 200 OK | | |
|SE:4000 | | |
|<-----------| | |
| |(22) BYE | |
| |<------------------------|
|(23) BYE | | |
|<-----------| | |
| |(24) 408 | |
| |------------------------>|
Figure 1: Example Session Timer Flow
图1：示例会话计时器流
Figure 1 gives an example of a call flow that makes use of the session timer. In this example, both the UAC and UAS support the session timer extension. The initial INVITE request generated by the UAC, Alice (message 1), might look like this:
图1给出了一个使用会话计时器的调用流示例。在本例中，UAC和UAS都支持会话计时器扩展。UAC生成的初始INVITE请求Alice（消息1）可能如下所示：
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
Supported: timer
Session-Expires: 50
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: application/sdp
Content-Length: 142
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
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
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:
此响应包含一个值为3600的Min SE标头字段。Alice然后重试该请求。这一次，请求包含一个Min-SE头，因为Alice收到了一个422，用于其他具有相同Call-ID的INVITE请求。新请求（消息4）可能如下所示：
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
Supported: timer
Session-Expires: 3600
Min-SE: 3600
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 INVITE
Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: application/sdp
Content-Length: 142
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
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记录路由。由于会话间隔现在可以接受，它将请求转发给P2（消息5）。但是，会话间隔低于其最小配置量4000。因此，它使用422响应代码（消息6）拒绝请求，并包含一个值为4000的Min SE header字段。Alice再次重试邀请。这一次，她的邀请中的Min-SE头字段是她收到的所有Min-SE的最大值（3600和4000）。消息10可能如下所示：
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10
Supported: timer
Session-Expires: 4000
Min-SE: 4000
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 INVITE
Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: application/sdp
Content-Length: 142
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10
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)
（未显示Alice的SDP）
P1 record-routes once again, but P2 does not (this wouldn't normally happen; presumably, if it asked for session timer, it would record-route the subsequent request). The UAS receives the request. It copies the Session-Expires header from the request to the response and adds a refresher parameter with value 'uac'. This 200 OK is forwarded back to Alice. The response she receives (message 15) might look like this:
P1会再次记录路由，但P2不会（通常不会发生这种情况；假设它请求会话计时器，它会记录后续请求的路由）。UAS收到请求。它将会话过期标头从请求复制到响应，并添加一个值为“uac”的刷新器参数。这个200 OK被转发回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
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):
Alice生成一个ACK（消息16），该ACK通过P1路由，然后发送到Bob。由于Alice是刷新者，大约2000秒后Alice发送更新请求以刷新会话。由于此请求是已建立对话框的一部分，并且Alice在该对话框上未收到任何422个响应或请求，因此她的请求中没有Min-SE header字段（消息18）：
UPDATE sips:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12
Route: sips:p1.atlanta.example.com;lr
Supported: timer
Session-Expires: 4000;refresher=uac
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314162 UPDATE
Contact: <sips:alice@pc33.atlanta.example.com>
UPDATE sips:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12
Route: sips:p1.atlanta.example.com;lr
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:
这通过P1转发给Bob。Bob生成一个200 OK，将会话到期头字段复制到响应中。这将通过P1转发并到达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>
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.
不久之后，爱丽丝的行动单位崩溃了。因此，她从不发送会话刷新请求。3968秒后，Bob超时并发送BYE请求（消息22）。这将被发送到P1。P1尝试交付，但失败（因为Alice的UA已崩溃）。然后，P1向Bob返回408（请求超时）。
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.，“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：会话启动协议”，RFC 3261，2002年6月。
[3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[3] Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，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 35502003年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）-特定事件通知”，RFC3265，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号，邮编75082
EMail: srd@cisco.com
EMail: srd@cisco.com
Jonathan Rosenberg Cisco Systems, Inc. 600 Lanidex Plaza Parsippany, NJ 07054 US
Jonathan Rosenberg Cisco Systems，Inc.美国新泽西州帕西帕尼市拉尼德斯广场600号，邮编：07054
EMail: jdrosen@cisco.com
EMail: jdrosen@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。