Session timer协商失败导致呼叫被释放案例分析论文.docx

Sessiontimer协商失败导致呼叫被释放案例分析论文Sessiontimer协商失败导致呼叫被释放案例分析论文摘要：首先介绍了在IMS5.0SIT测试中碰到的两个因为Sessiontimer协商失败导致呼叫被释放的案例，然后对比RFC4028的规定分析了问题发生时各个网元的处理是否合规，最后总结介绍RFC4028的规定。关键词：Sessiontimer;IMS;SIP;终端;ATS在IMS5.0SIT测试中发现多款终端在使用ATS的HOLD业务时有断话问题，跟踪消息显示是由于ATS的释放，但最终分析确认是终端对sessiontimer的支持存在问题，造成终端和ATS的sessiontimer协商出现问题，导致呼叫被释放。基于此，对比RFC4028分析了测试中碰到的两个sessiontimer相关问题，并总结RFC4028规范。1案例分析1.1案例一该终端做主叫呼叫其他用户，其他用户有HOLD业务，呼叫接通后用户拍叉保持该终端用户，保持失败呼叫被释放。对该终端用户来说流程如下所示。从消息中可看出，在会话建立初期，ATS发送给终端的200响应中携带Session-Expires头域要求开启会话上的sessiontimer，刷新时间为1800秒，refresher为uas(即ATS)如图1所示。图1会话建立初期的消息终端被HOLD后ATS要发re-INVITE给终端，在re-INVITE中携带了Session-Expires头域，其值为当前会话的刷新间隔1800秒，同时按照RFC4028,在发起后续刷新请求时尽量保持refresher身份不变，在上次会话中uas作为refresher，即ATS本端完成会话刷新操作。而在本次会话中ATS成为了uac，所以在re-INVITE消息Session-Expires头域的refresher参数值为uac(还是ATS)，如图2所示。图2终端被HOLD后ATS发送给终端的re-INVITE终端收到该re-INVITE后按照RFC4028的规定，此时uac(ATS)支持sessiontimer，Session-Expires头域的refresher参数值为uac，那么终端在200响应中也必须设置Session-Expires头域的refresher参数值为uac，可是这款终端却修改200响应中的refresher参数值为uas，ATS收到该响应消息后认为终端发送的200不符合协议规定释放呼叫。该问题通过使终端不再修改re-INVITE消息中的refresher参数值而得以解决。1.2案例二问题现象同案例一。在终端发送INVITE的supporter头域中包含timer标签。ATS收到该请求消息后在200响应消息中增加Session-Expires头域，头域制定会话刷新间隔为1800秒，refresh为uac。图3终端发送INVITE的supporter头域终端被HOLD后ATS要发re-INVITE给该终端用户，在re-INVITE消息中携带了Session-Expires头域，其值为当前会话的刷新间隔1800秒，同时按照RCF4028，在发起后续刷新请求时尽量保持refresher身份不变，在上次会话中uac作为refresher，即终端完成会话刷新操作。而在本次会话中终端成了uas，所以在re-INVITE消息Session-Expires头域的.refresher参数值为uas(还是终端)图4终端被HOLD后ATS发给该终端用户的re-INVITE终端收到该re-INVITE后在发送的200响应消息中没有携带Session-Expires头域，按照RCF4028规定，uas可在会话中通过发送不带Session-Expires头域的200响应来关闭会话上的sessiontimer。PROXY可以确定本次事务交互的uac(ATS)支持sessiontimer，按照RCF4028规定，PROXY在响应消息中增加了Session-Expires头域，并指定refresher为uac。图5PROXY的响应消息ATS收到响应后对比请求消息中的Session-Expires和响应的Session-Expires头域，发现请求消息和响应消息中的refresher不一致而导致释放呼叫。该问题通过终端修改INVITE消息，使其不携带supporter:timer得以解决。2RFC4028规范在SIP协议中未定义检测会话机制，尽管UA可以通过其他手段来判断会话是否还存在，但callstatefulproxy却做不到这一点。为解决这一问题，定义了一种SIP会话刷新机制，通过UA周期发送re-INVITE或UPDATE消息来保持会话的激活状态，发送间隔由uac、uas、PROXY协商确定。2.1基本流程Sessi