RFC4028学习笔记
1 RFC4028主要定义两个头域：
Session-Expires:表示会话的持续时间；
Min-SE：定义了Session-Expires的最小值
422响应代码表示Session-Expire的值太小了。
2 之所以定义RFC4028，是因为SIP中没有keep alive机制。一个会话，也许客户端可以使用某种机制确定其超时，但状态代理服务器并不能。如果客户端发送的BYE信息无法到达客户端，那么状态代理服务器将一直保持这个会话的状态。因此，有必要定义一个Keep alive机制，这就是RFC4028所定义的。
3 UA周期性发送re-INVITE请求或UPDATE请求(这样的请求称为——会话刷新请求)保持会话处于激活状态。会话刷新请求的发送间隔是通过协商机制来确定的。
4 如果在协商好的时间间隔里proxy没有接收到一个刷新请求，那么proxy就认为这个会话结束了，然后清除相关状态和资源。
5 ALG如何在呼叫期间维护状态？？？？
6 Session Interval: 一个对话中，在会话超时之前，两次会话刷新请求发出之间的最大时间间隔。这就是Session-Expires头域的值。UAS发送一个会话刷新请求之后，服务器对应返回一个2xx响应，响应中包含Session-Expires头域，UAS获取这个头域的值作为会话刷新请求发送的时间间隔。代理服务器和UACs决定针对他们接收到的会话刷新请求而发出的2xx响应中Session-Expires头域的值。
Minimum Timer: 由于对话中间请求的处理加载，所有元素(proxy,UAC,UAS)都有一个配置好的期待的最小会话刷新请求间隔的值。这个值被称为最小定时器。
Session Expiration: 如果会话刷新事务不成功，一个元素认为一个会话超时的时间值。
Session Refresh Request: 根据这个规范的一个INVITE或者UPDATE请求。如果这个请求有一个2xx响应，那么会话超时的时间就是当前时间加上从这个响应的Session-Expire头域获取到的值。一个会话刷新请求不能与一个target refresh request相混淆(defined in Section 6 of [2]),target refresh request更新一个dialog的远程target。
Initial Session Refresh Request: 第一次发送的有一个特定的Call-ID值的会话刷新请求。
Subsequent Session Refresh Request: 在初始会话刷新请求之后发出的有特定Call-ID的会话刷新请求。
Refresh: 本文档中与一个会话刷新请求相同。
7 本SIP扩展的一个特性是即使对话双方UA只有一个支持本规范，本规范也能够工作。处理过程根据四种情况而不同——UAC支持或者不支持，UAS支持或者不支持。下面假设对话双方都支持的情况。
一个UAC发送的INVITE请求中，如果一个支持的头域中包含了可选的标签——timer，表示支持本规范。
一个包含timer标签的请求会经过很多代理服务器，任何一个都可能要建立一个会话定时器。每一个代理服务器都能插入一个Session-Expires头域和一个Min-SE头域(如果这些头域不存在)或者修改这两个头域的值(如果已经存在的话。)
Min-SE头域确定了会话刷新的最短时间，这个头域可以防止恶意的proxy设置任意短的时间从而使得邻近的proxy过载而瘫痪。每一个代理服务器可以增大这个值但不能减小他。
Session-Expires头域设定会话刷新请求间隔时间的上限。一个维护会话状态的proxy在处理一个请求之后必须维护它的会话状态持续该头域指定的时间值。任何代理服务器可以降低这个时间值，但这个值不能小于Min-SE头域指定的值。
如果一个请求中的Session-Expires值小于一个代理服务器设定的Min-SE值，那么该代理服务器将返回一个422响应。这个422响应中包含了一个Min-SE头域说明了它支持的最小值。然后UAC会再次尝试发送请求，请求中的Min-SE头域的值是它之前接收到的所有422响应中的Min-SE头域的最大值。这样子就能符合这个请求的路径上所有proxy的要求。
在几个INVITE/422迭代之后，请求到达了UAS。这时，UAS像一个proxy一样调整会话刷新请求的时间间隔，它把这个时间间隔插入到一个2xx响应中的Session-Expires头域。这个头域中包含一个“refresher”参数，这个参数说明当前是谁在刷新这个会话，是UAC还是UAS。当这个2xx响应沿着路径返回的时候，每一个proxy能够观察到这个会话刷新的时间间隔，但不能够改变它。
根据响应中的Session-Expires头域，UAC和UAS都知道会话定时器是激活的，当该会话将要超时的时候是谁在刷新该会话。
当一个会话快要超时的时候，当前的刷新者将发送一个re-INVITE请求或UPDATE请求进行刷新。如果刷新者没有得到一个响应，那么他将发送一个BYE请求结束这个会话。同样的，如果另外一方一直没有得到一个会话刷新请求，那么它在会话超时之后发送一个BYE结束这个会话。
上面说的只是一个简要的过程，有时还要处理只有一方支持的情况，如下文。
8 Session-Expires头域定义：仅出现在INVITE或者UPDATE请求中，也出现在INVITE或者UPDATE请求的任何2xx响应中。Session-Expires头域的绝对最小值是90秒。这个值是一个SIP事务在超时之前维持的时间的2倍多一些。这个值是一个SIP事务在超时之前维持的时间的2倍多一些。这使得一个UA有足够的时间在一个会话间隔的中间尝试进行一个刷新，并使得这个事务在会话超时之前正常完成。但是，还是推荐使用1800秒这个值。
插入Session-Expires头域的实体选择的值不能小于1800秒。
太小的会话间隔是不允许发送到网络上的，因为这会在UA和proxy之间造成网络拥塞。而且这样很可能会发生'glare'，因为两个UA很可能在同一时间发送re-INVITE或者UPDATE请求。
Session-Expires头域的默认值是没有定义的。
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")
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].
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
Header whereproxyACKBYECANINVOPTREGPRAUPDSUBNOT
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
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
9. Min-SE Header Field Definition
用在一个INVITE或UPDATE请求中。值不小于90秒。
除了422响应之外，不会用在其他响应中。表示服务器所能接受的最小Session-Expires值。
语法如下：
Min-SE = "Min-SE" HCOLON delta-seconds *(SEMI generic-param)
10. 422 Response Code Definition
本扩展引入了422响应码(Session Interval太小)。由一个UAS或proxy产生。必须包含一个Min-SE头域，值是UAS或Proxy所能接受的最小Session-Expires值。
11. UAC Behavior
11.1. 产生一个初始会话刷新请求
一个支持会话定时器扩展的UAC必须在每个请求中(除了ACK)包含一个Supported头域，该头域中包含timer标签。即使该UAC对于一个会话不要求会话定时器，它也必须这么做。
一个UAC可能在请求中包含一个Require头域，Require头域包含一个timer参数，表示参与这个会话的UAS必须支持会话定时器，也就是支持本规范。此外，UAC可能在Proxy-Require头域中包含timer表示proxies必须支持会话定时器以正确处理请求。但是并不推荐UAC使用Require或者Proxy-Require头域。因为这是不需要的，因为即使只有UAC支持本扩展也能够正常工作。如果Require或Proxy-Require头域已经包含了timer，UAC发出的请求中的Supported头域仍然要包含timer。
一个UAC如果想要在一个会话中应用会话定时器，那么它可能要在初始的会话刷新请求中包含一个Session-Expires头域。
一个UAC如果想要执行一个会话的刷新，那么它要在Session-Expires头域中的refresher参数中包含'uac'。但推荐不要使用refresher参数而是让协商机制来确定由谁刷新，协商机制如下文所示。
11.2. 处理一个2xx响应
会话定时器要求UA创建和维护会话间隔、会话超时以及会话刷新者的标记。
如果针对一个会话刷新请求的2xx响应到达，如果它包含了一个Require头域，该头域的值包含了timer，那么UAC必须查找Session-Expires头域来处理该响应。也就是说，即使有会话刷新请求，也可能有没有使用会话定时器的时候？？？！！！是这样的。
如果该会话的Require头域确实包含了一个timer值，那么必须有Session-Expires头域。如果该头域包含了refresher参数，那么UAC必需标识刷新者。如果刷新者是uac，那么UAC必需执行会话刷新。
一个UAC请求会话定时器(该请求中包含一个Session-Expires头域)，但这个请求的2xx响应中却没有Require或者Session-Expires头域，这种情况是可能出现的。这是因为UAS不支持会话定时器扩展。在这种情况下，如果UAC仍然要求会话定时器，它必须执行会话的刷新。为了达到这个目的，使得UAC依照本规范的流程，那么2xx响应的Session-Expires头域的值必须跟请求中的相同，且refresher参数的值是uac.
如果2xx响应中没有包含Session-Expires头域，那么就没有会话超时这么回事。这意味着会话刷新定时器可以在dialog中途被关闭，只要发送一个没有Session-Expires头域的响应即可。
推荐一个UAC在会话间隔的中间发送会话刷新请求。
11.3. 处理一个422响应
对于一个422响应，UAC必须重新发送会话刷新请求，过程如11.4所示。新的请求的Call-ID、To和From与前一个请求相同，但CSeq的值加1.
11.4. 创建后续会话刷新请求
后续会话刷新请求中，Supported、Require和Proxy-Require的值必须跟初始会话刷新请求相同。
如果一个UAC在一个dialog中接收到针对一个会话刷新请求的422响应，或者接收到一个包含Min-SE头域的会话刷新请求，则该UAC必须在下一个会话刷新请求中包含一个Min-SE头域。同样地，如果UAC发送一个包含Session-Expires头域的INVITE请求之后接收到一个422响应，那么UAC在下一个有着同样Call-ID的INVITE请求中必须包含一个Min-SE头域。
如果一个dialog已经建立，UAC发送的会话刷新请求中的Min-SE头域必须是同一个dialog中所有接收到的422响应或接收到的所有会话刷新请求中最大的Min-SE头域。如果一个dialog尚未建立，那么Min-SE头域的值必须被设置为针对一个INVITE请求的所有的422响应的Min-SE头域的值中最大的值。这个规则的结果就是，一旦一个dialog被建立，Min-SE的最大值实际上就被清除了，并且从那一刻开始，只有这一proxy路径上的proxies返回的值最终被使用。
UAC对于最小的会话间隔也有自己的策略。所以，如果按照上述策略得到的Min-SE值太小，UAC可能会增加它。
在激活会话定时器的dialog中，发送的会话刷新请求都应该包含Session-Expires头域，且其值应该等于Min-SE头域和当前会话间隔的值的最大者，或者90秒。包含使用前面所说的值的Session-Expires头域能够避免拒绝服务攻击(denial-of-service)，如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。
如果会话刷新请求不是第一个，且发送该请求的元素当前正在刷新会话，则refresher参数最好设置为'uac'，如果是对方在刷新会话则设置为'uas'。这样，刷新者的角色在每一次刷新中都不会改变。但是，如果发送者希望显式地改变当前角色(刷新者)，且它知道对方支持会话定时器，它可能使用'uas'这个值。它可以通过对方发送的请求中Supported头域包含'timer'这个值来了解对方是否支持会话定时器。如果它试图重新选择角色，那么它可能忽略这个参数(refresher?)。
如果一个UAC知道对方支持UPDATE方法，那么推荐使用UPDATE方法，而不是re-INVITE。那么如何知道对方支持UPDATE方法呢？这完全可以通过查看对方发送的SIP包的Allow头域中是否包含UPDATE，或者在会话中间通过一个OPTIONS请求来确认。推荐UPDATE请求中不包含一个offer，但re-INVITE中应该包含一个，即使会话的详情没有变动。在这种情况，offer必须提示它没有改变。对这种情况的SDP，通过包含与发送给对方的前一个SDP一样的值来表示它没有改变。同样的，对于一个会话刷新请求的应答也是包含与前一个同样的SDP answer来提示。
12. Proxy Behavior
会话定时器总是对呼叫状态代理服务器感兴趣(也就是，那些维护呼叫状态和建立会话的服务器)。但是， 一个状态代理服务器(也就是维护一个事务状态但不维护一个呼叫或dialog状态)可能遵从这儿描述的规则。无状态代理服务器不需要尝试请求会话定时器。要求会话定时器的代理服务器应该记录路由。
12.1 请求处理
请求的处理与所有的会话刷新请求是一样的。对于一个会话，一个proxy为了请求一个会话定时器，必须在一个会话刷新请求中插入一个Session-Expires头域。如果一个请求中没有Session-Expires头域，那么proxy在转发它之前会插入一个以请求会话定时器。这个Session-Expires头域的值是proxy所希望的时间，但不应该小于Min-SE头域，如果有Min-SE头域的话。proxy不允许在头域中插入refresher参数。如果一个请求中已经有Session-Expires头域，proxy可以减少它但不应该比Min-SE头域值小，如果有Min-SE头域的话。如果Session-Expires的值大于或等于Min-SE头域的值(如果没有Min-SE头域则默认为90秒)，那么proxy就不应该增加Session-Expires头域的值。如果Session-Expires头域的值小于Min-SE头域的值(这是因为proxy增大Min-SE头域的值)，那么proxy应该增大Session-Expires头域的值等于Min-SE头域的值。proxy不允许在Session-Expires头域中插入refresher参数。也就是说，这里Session-Expires头域的值与Min-SE头域的值的比较，是在proxy设置Min-SE头域的值之后。
如果请求的Supported头域中包含了“timer”，且Session-Expires的值小于proxy本身指定的最小会话间隔，那么proxy将拒绝该请求并返回一个422响应(Session Interval Too Small)。发送的422响应中，应该包含一个Min-SE头域，值是该proxy的最小会话间隔，且这个间隔必须不小于90秒。也就是说上一段中所说的Session-Expires头域的值是大于proxy指定的最小会话间隔的。
如果请求中没有明确提示支持会话定时器(也就是Supported头域中没有包含timer)，而Session-Expires头域的值比proxy的最小会话时间间隔小，那么proxy一般不能拒绝该请求，因为这将导致呼叫失败。相反，proxy会插入一个Min-SE头域，值是该proxy设置的最小时间间隔。如果请求中已经有Min-SE头域，那么proxy应该增加Min-SE头域的值等于它的最小会话时间间隔。然后proxy必须增大Session-Expires头域的值等于Min-SE头域的值。如果一个被代理的请求(就是已经经过proxy的请求？？？)包含有timer的Supported头域，则proxy不允许插入Min-SE头域或者修改已经存在的头域的值。这个暂时无法理解。这是因为纺织DOS攻击，在Section 11中描述的。
假如proxy已经请求一个会话定时器(可能插入一个Session-Expires头域或减少它)，那么proxy必须记住它正在使用一个会话定时器，并且记住这个被代理的请求的Session-Expires头域的值。这在这个事务期间是必须记住的。
proxy在一个事务期间，必须记住，请求包含的Supported头域的timer。如果该请求没有包含具有timer值的Supported头域，proxy可以插入一个Require头域，Require头域包含‘timer’。但并不推荐这么做。因为这允许proxy在这个会话中坚持会话定时器。 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.
12.2. 处理响应
如果一个请求的最终响应到达，proxy将会对其进行检查。
如果响应中没有包含一个Session-Expires头域，但proxy记得它在请求中请求一个会话定时器(通过插入、修改或者检查和接受被代理的请求的Session-Expires头域)，这意味着UAS不支持会话定时器。如果proxy记得UAC也不支持会话定时器，那么proxy就前转这个响应。如果proxy记得UAC支持会话定时器，那么处理过程如下所述。
因为响应中没有任何Session-Expires或者Require头域，proxy知道它是接收到这个响应的proxy中第一个知道会话定时器规范的，那么这个proxy应该插入一个Session-Expires头域，头域的值是它记住的所转发的请求中的Session-Expires值。它必须设置Session-Expires头域的refresher参数的值为uac，且proxy必须添加timer可选标签到Require头域中，如果响应中没有Require头域则必须添加一个。
如果响应中包含了一个Session-Expires头域，则无需对该响应做任何修改。
在所有的情况中，如果被proxy转发的2xx响应包含一个Session-Expires头域，它的值就代表了这个会话的间隔时间。proxy将这个响应转发之后就为自己的会话定时器加上响应中的会话时间间隔。会话超时必须被这个会话的任何存在的session expiration更新的。2xx响应中的Session-Expires头域中必须出现refresher参数，这表示究竟是哪一个UA在刷新会话。对于单个INVITE，可以有多个2xx响应，每一个代表一个不同的dialog，导致有多个会话超时。
proxy不应该修改响应的Session-Expires头域。
12.3. Session Expiration
如果当前等于或者超过一个会话的session expiration，proxy可能移除相关呼叫状态，并且释放跟这个呼叫相关的资源。不像UA，proxy不应该发送一个BYE请求。
13. UAS行为
UAS必须响应一个会话定时器的请求，这个请求可能是UAC发出或者是请求所经过的路径中的proxy发出的，或者UAS请求一个会话定时器自身使用。
如果一个到来的请求的Supported头域中包含timer且有一个Session-Expires头域，如果Session-Expires头域包含的值小于UAS自身定义的最小会话时间间隔，那么UAS可能发送一个422响应拒绝该会话刷新请求。UAS发送422响应的时候，响应必须包含一个Min-SE头域，该头域是UAS自定义的最小会话时间间隔，这个间隔必须不小于90秒。
如果UAS接受一个会话刷新请求，那么它将拷贝请求中的Session-Expires头域的值到2xx响应中。如果一个请求中有Min-SE头域，UAS可以减少Session-Expires头域的值但不应该小于Min-SE头域的值；如果没有Min-SE头域的话，则不应该小于90秒。UAS不应该增加Session-Expires头域的值。
如果一个到来的请求包含了一个Supported头域且包含timer，但没有包含一个Session-Expires头域，这意味着UAS支持会话定时器但没有请求会话定时器。UAS可以在2xx响应中包含一个Session-Expires头域来请求一个会话定时器。会话定时器的值不能小于Min-SE头域的值，如果有Min-SE头域的话。
UAS必须设置2xx响应的Session-Expires头域的refresher参数。refresher参数的值基于请求的refresher参数的值以及UAC是否支持会话定时器扩展。如果请求中的Supported头域中包含timer则表示UAC支持会话定时器扩展。
Table 2定义响应中的值如何设置。第二列中none表示请求中没有refresher参数。第三列中NA表示这个特定的组合不应该发生，因为协议中不允许。
UAC supports? refresher parameter in request refresher parameter in response
--------------------------------------------------------------------------------------------------
N none uas
N uac NA
N uas NA
Y none uas or uac 这表示UAC和UAS都支持单UAC不选择谁来刷新，由UAS来决定
Y uac uac
Y uas uas
Table 2: UAS Behavior
由Table 2可以看出，UAS不能覆盖UAC设定的refresher参数的值，如果UAC支持会话定时器的话。
如果2xx响应中Session-Expires头域的refresher参数的值是'uac'，UAS必须放置一个Require头域到响应中，该头域包含'timer'。这是因为UAC执行刷新且UAC必须处理这个响应。
如果2xx响应中refresher参数的值是'uas'且请求中Supported头域中包含'timer'，那么UAS应该放置一个包含'timer'的Require头域到响应中。在这种情况下，UAC不执行刷新，但如果没有接收到会话刷新请求的话则发送一个BYE请求。因为UAC不发送一个BYE的话这个call仍然成功，所以插入Require是一个SHOULD，而不是MUST。
跟UAC一样，UAS也存储会话定时器的状态。这个状态包含了会花时间间隔、会话超时和refresher的标识。这个状态跟一个dialog是绑定的。会话间隔被设置为该dialog中最近一个会话刷新请求的2xx响应中的会话时间间隔。refresher的设置也是这样。
如果2xx响应没有Session-Expires头域，那么就没有会话超时，也就没有会话刷新的执行。如果UAS必须刷新会话，它将计算会话超时。会话超时是这样计算的，就是UAS发出最后一个2xx响应的时间加上会话刷新间隔。如果UA希望在会话超时这个时间之后继续会话，它必须在会话超时之前产生刷新。推荐在会话时间间隔的中间点发送刷新。刷新会话的其他过程在下一节中描述。
14 执行刷新
执行会话刷新的一方根据前面所述的UAC的过程来执行。要注意的是只有一个会话刷新请求的2xx响应增加了会话超时。这意味着，一个UA尝试刷新时，会接收到一个422响应，这个响应包含了一个Min-SE头域，该头域的值比当前会话刷新时间要大的多。然后UA在会话超时之前仍然发送一个会话刷新请求，该请求的Session-Expires头域的值是它接收到的所有422响应中的Min-SE头域中的最大值。
如果会话刷新请求事务超时，或者产生一个408或481响应，UAC将发送一个BYE请求。如果会话刷新请求不产生一个2xx响应，而是一个408或者481响应，UAC将根据这些响应的规则进行处理，如果可能的话还会再尝试刷新。例如，如果响应是401，那么UAC将使用一个新的证书重发请求。如果服务器还是返回同样的错误，那么UAC就不应该在尝试了。
同样地，如果不执行会话刷新的一方在会话超时之前没有接收到一个会话刷新请求，那么它将稍微在该会话超时之前发送BYE请求。一般推荐在会话超时之前的32秒或者会话时间间隔的三分之一。
Firewalls和NAT ALGs可能是不允许在会话超时之后再发送SIP数据的，这是为什么要在会话超时之前发送BYE请求的原因。
15. 安全性的考虑
会话定时器使得proxy或者UA元素能够按照他们的设置发送刷新。这引入了denial-of-service攻击的可能性。攻击者可能是外部的(尝试修改经过的消息)或者内部的(请求路径上的元素)。
15.1. 内部攻击
这引入欺骗性的proxy或者UA进行DOS攻击的可能性。本规范阻止了DOS攻击的可能性。
首先，假设UAC是一个欺骗者，它想要UAS快速地刷新会话。为了达到这个目的，UAC发送一个INVITE请求，该请求的Session-Expires头域的值非常小且refresher参数的值置为'uas'。假如该INVITE请求中包含了Supported头域，则UAS或者该请求经过的任何代理将发送422响应拒绝该请求从而防止了该次攻击。如果没有Supported头域，proxy将插入Min-SE头域到请求中然后前转该请求。这样UAS选择的是较大的会话刷新时间而防止了攻击。
其次，假设攻击的是UAS，希望UAC快速刷新会话。这种情况的一个前提是UAC支持会话定时器。初始的INVITE请求到达了UAS，UAS返回一个具有非常小的时间间隔的2xx响应。 这使得UAC快速发出会话刷新请求，但它会将2xx响应中的Session-Expires头域的值copy过来，然后proxy就会拒绝该请求，并提供它自己的Min-SE头域值，然后UAC再使用该值来刷新会话。如果proxy不拒绝仅是添加Min-SE头域的话该攻击还是可能会发生的，因为UAS完全可以不理睬Min-SE头域。
使用同样的攻击方法，一个欺骗性代理不能强制UAC或者UAS产生刷新，除非proxy一直在请求路径上并且看到每一个请求和响应。
15.2. 外部攻击
一个能够观察和修改一个请求或响应的一个元素能够强制快速的会话刷新。为了阻止这一点，请求和响应不得不通过message integrity来保护。因为会话定时器头域必须通过proxy传输而不是端到端传输的，所以SIP S/MIME能力并不适合这个任务。相反，integrity不得不通过使用hop-by-hop机制来保护。
结果，推荐一个元素发送一个有着Session-Expires头域的请求或者有'timer'的Supported头域，通过TLS来发送。因为只有每一跳都应用安全策略才能得到足够的保护，所以推荐SIPS URI模式和本规范一起使用。
16. IANA Considerations
This extension defines two new header fields, a new response code,
and a new option tag. SIP [2] defines IANA procedures for
registering these.
16.1. IANA Registration of Min-SE and Session-Expires Header Fields
The following is the registration for the Min-SE header field:
RFC Number: RFC 4028
Header Name: Min-SE
Compact Form: none
The following is the registration for the Session-Expires header
field:
RFC Number: RFC 4028
Header Name: Session-Expires
Compact Form: x
16.2. IANA Registration of the 422 (Session Interval Too Small)
Response Code
The following is the registration for the 422 (Session Interval Too
Small) response code:
Response Code: 422
Default Reason Phrase: Session Interval Too Small
RFC Number: RFC 4028
16.3. IANA Registration of the 'timer' Option Tag
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.
17. Example Call Flow
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
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:
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
From: Alice ;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
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):
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 ;tag=9a8kz
From: Alice ;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:
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
From: Alice ;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
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:
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
From: Alice ;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 INVITE
Contact:
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:
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 ;tag=9as888nd
From: Alice ;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 142
(Bob's SDP not shown)
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):
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 ;tag=9as888nd
From: Alice ;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314162 UPDATE
Contact:
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:
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 ;tag=9as888nd
From: Alice ;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314162 UPDATE
Contact:
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.
14. Acknowledgements
The authors wish to thank Brett Tate for his contributions to this
work. Brian Rosen completed the editing of the document.
15. References
15.1. Normative References
[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.
[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.
15.2. Informative References
[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.
[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.
Authors' Addresses
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
EMail: jdrosen@cisco.com
Full Copyright Statement
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.
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.
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.
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
浙公网安备 33010602011771号