Session Timer机制分析

功能介绍

会话初始化协议（SIP）并没有为所建立的会话定义存活机制。尽管用户代理可以通过会话特定的机制判断会话是否超时，但是代理服务器却做不到这点。如此一来，代理服务器有时会无法判断会话是否还是活动的。例如，当一个用户代理在会话结束时发送BYE消息失败，或者由于网络问题BYE消息丢失，代理服务器将不会知道会话已经结束。在这种情况下，代理服务器将保持呼叫的状态并且无法知道呼叫状态信息何时失效。

为了解决这个问题，RFC4028为SIP会话定义了一种存活机制。用户代理周期性的发送re-INVITE或UPDATE请求用来保持会话的活动。会话更新请求的间隔通过其定义的协商机制决定。如果在间隔内没有收到会话更新请求，该会话被认为已经终止。用户代理会发送一个BYE消息，代理服务器则将该呼叫的所移除。

工作原理

UAC通过发送一个INVITE消息发起流程,这个消息包括一个带有可选标签“timer”的Supported头字段，用来表明支持Session Timer功能。该请求通过代理服务器传递，所经过的任一个代理服务器都可以依据他们的兴趣建立会话定时器。每个代理服务器都可以在请求中插入一个Session-Expires头字段和一个Min-SE头字段（前提是请求中还没有这些字段），或者修改上述已存在头字段的值。

Min-SE头字段为会话更新间隔建立了下限，也就是处理这条请求消息的SIP代理的最快会话刷新率。这个头字段的目的是防止怀有恶意的代理服务器设置任意短的更新间隔以致它的邻居代理负荷超载。处理请求的每个代理服务器可以提高这个下限（实际上就是提高刷新的周期），但是不能降低下限。

Session-Expires头字段为会话更新间隔建立了上限，也就是任何一个代理服务器在处理一个请求之后必须为这个会话保持状态的时间周期。任何服务于该请求的代理可以降低这个值，但必须大于Min-SE头字段指定的值。

如果Session-Expires的间隔太小（小于代理服务器要维护的Min-SE头字段的值），那么代理服务器将拒绝这个请求并返回一个422响应。该响应包含一个Min-SE头字段表明它所支持的最小会话间隔。UAC再次尝试发送请求，这次请求中包含了Min-SE头字段，头字段等于先前接收到的所有422响应中最大的Min-SE头字段。这样一来，最小定时器就能满足所经过的所有代理服务器的约束条件。

在几次INVITE/422消息的反复传送后，请求最终到达UAS。UAS可以调整会话间隔的值就好像它自己也是一个代理服务器。之后，它将这个最终的会话间隔发入2xx响应的Session-Expires头字段。Session-Expires头字段还包含一个“refresher”参数用来表示更新的执行者（是当前的UAC还是UAS）。当2xx响应沿代理服务器链返回时，任何代理服务器可以观察这个最终的会话间隔但不能修改它。

通过响应中的Session-Expires头字段，UAC和UAS都知道会话定时器是活动的，它何时终止以及谁在更新会话。在终止前的某个时刻，当前活动的更新者生成一个会话更新请求，可以是一个re-INVITE或者UPDATE请求。如果更新者始终得不到这个会话更新请求的响应，它就会发送一个BYE消息结束会话。同样，如果另一端在会话终止前始终收不到会话更新请求，它也会发送一个BYE消息结束会话。

图1-1 Sesstion Timer正常工作流程示意图

功能相关测试重点

（1）话机终端是否支持Session Timer功能，相关头字段信息：

Supported: timer;

（2）会话更新的时间准确性，每次更新的时间间隔应为已经协商确定的Session-Expires值一半；

（3）会话更新者的确定，可能是UAC也可能是UAS，但无论是哪方进行更新都应该有相应的更新请求或者回应；

（4）逻辑验证会话更新请求发送后，如果在Session-Expires/2的时间内没有得到对方的响应（200 OK）信息，则发送BYE以拆掉当前会话；同样的，假如在规定时间内得不到更新者（Refresher）发送的会话更新请求信息，话机终端是否也会发送BYE；

（5）话机终端在更新过程中，如果更新者(Reresher)变动后，其会话的后续更新逻辑验证；

(6) 不是所有的参与者都支持Session Timer情况下的会话更新逻辑验证。