Session timer協(xié)商失敗導致呼叫被釋放案例分析論文

　　摘 要：首先介紹了在IMS5.0 SIT測試中碰到的兩個因為Session timer協(xié)商失敗導致呼叫被釋放的案例，然后對比RFC4028的規(guī)定分析了問題發(fā)生時各個網(wǎng)元的處理是否合規(guī)，最后總結介紹RFC4028的規(guī)定。

　　關鍵詞：Session timer;IMS;SIP;終端;ATS

　　在IMS5.0 SIT測試中發(fā)現(xiàn)多款終端在使用ATS的HOLD業(yè)務時有斷話問題，跟蹤消息顯示是由于ATS的釋放，但最終分析確認是終端對session timer的支持存在問題，造成終端和ATS的session timer協(xié)商出現(xiàn)問題，導致呼叫被釋放。

　　基于此，對比RFC4028分析了測試中碰到的兩個session timer相關問題，并總結RFC4028規(guī)范。

　　1 案例分析

　　1.1 案例一

　　該終端做主叫呼叫其他用戶，其他用戶有HOLD業(yè)務，呼叫接通后用戶拍叉保持該終端用戶，保持失敗呼叫被釋放。對該終端用戶來說流程如下所示。

　　從消息中可看出，在會話建立初期，ATS發(fā)送給終端的200響應中攜帶Session-Expires頭域要求開啟會話上的session timer，刷新時間為1800秒，refresher為uas(即ATS)如圖1所示。

　　圖1 會話建立初期的消息

　　終端被HOLD后ATS要發(fā)re-INVITE給終端，在re-INVITE中攜帶了Session-Expires頭域，其值為當前會話的刷新間隔1800秒，同時按照RFC4028,在發(fā)起后續(xù)刷新請求時盡量保持refresher身份不變，在上次會話中uas作為refresher，即ATS本端完成會話刷新操作。而在本次會話中ATS成為了uac，所以在re-INVITE消息Session-Expires頭域的refresher參數(shù)值為uac(還是ATS)，如圖2所示。

　　圖2 終端被HOLD后ATS發(fā)送給終端的re-INVITE

　　終端收到該re-INVITE后按照RFC4028的規(guī)定，此時uac(ATS)支持session timer，Session-Expires頭域的refresher參數(shù)值為uac，那么終端在200響應中也必須設置Session-Expires頭域的refresher參數(shù)值為uac，可是這款終端卻修改200響應中的refresher參數(shù)值為uas，ATS收到該響應消息后認為終端發(fā)送的200不符合協(xié)議規(guī)定釋放呼叫。

　　該問題通過使終端不再修改re-INVITE消息中的refresher參數(shù)值而得以解決。

　　1.2 案例二

　　問題現(xiàn)象同案例一。

　　在終端發(fā)送INVITE的supporter頭域中包含timer標簽。ATS收到該請求消息后在200響應消息中增加Session-Expires頭域，頭域制定會話刷新間隔為1800秒，refresh為uac。

　　圖3 終端發(fā)送INVITE的supporter頭域

　　終端被HOLD后ATS要發(fā)re-INVITE給該終端用戶，在re-INVITE消息中攜帶了Session-Expires頭域，其值為當前會話的刷新間隔1800秒，同時按照RCF4028，在發(fā)起后續(xù)刷新請求時盡量保持refresher身份不變，在上次會話中uac作為refresher，即終端完成會話刷新操作。而在本次會話中終端成了uas，所以在re-INVITE消息Session-Expires頭域的refresher參數(shù)值為uas(還是終端)

　　圖4 終端被HOLD后ATS發(fā)給該終端用戶的re-INVITE

　　終端收到該re-INVITE后在發(fā)送的200響應消息中沒有攜帶Session-Expires頭域，按照RCF4028規(guī)定，uas可在會話中通過發(fā)送不帶Session-Expires頭域的200響應來關閉會話上的session timer。PROXY可以確定本次事務交互的uac(ATS)支持session timer，按照RCF4028規(guī)定，PROXY在響應消息中增加了Session-Expires頭域，并指定refresher為uac。

　　圖5 PROXY的響應消息

　　ATS收到響應后對比請求消息中的Session-Expires和響應的Session-Expires頭域，發(fā)現(xiàn)請求消息和響應消息中的refresher不一致而導致釋放呼叫。

　　該問題通過終端修改INVITE消息，使其不攜帶supporter:timer得以解決。

　　2 RFC4028規(guī)范

　　在SIP協(xié)議中未定義檢測會話機制，盡管UA可以通過其他手段來判斷會話是否還存在，但call stateful proxy卻做不到這一點。為解決這一問題，定義了一種SIP會話刷新機制，通過UA周期發(fā)送re-INVITE或UPDATE消息來保持會話的激活狀態(tài)，發(fā)送間隔由uac、uas、PROXY協(xié)商確定。

　　2.1 基本流程

　　Session timer擴展在只有一個UA支持時仍能正常工作。uac發(fā)送初始INVITE消息SUPPORT頭域中加入timer標簽以指示uac支持session timer擴展，請求消息經(jīng)過代理時，任何一個代理都可以通過插入或修改Session-Expires和MIN-SE頭域來請求開啟session timer。MIN-SE頭域規(guī)定了會話刷新間隔的最小值，PROXY能增加但不能減少該頭域值;Session-Expires規(guī)定了會話刷新間隔的最大值，PROXY能減少但不能增加該頭域值。

　　如果Session-Expires值小于PROXY配置的最小會話刷新時間間隔，PXORY則以422響應拒絕該請求消息，響應須攜帶MIN-SE頭域指示PROXY能接受的最小會話刷新時間間隔。uac收到422響應后修改Session-Expires頭域值重新發(fā)起請求，請求消息中攜帶MIN-SE頭域，該頭域值為uac之前收到的所有422響應中MIN-SE頭域的最大值，這樣

【Session timer協(xié)商失敗導致呼叫被釋放案例分析論文】相關文章：

案例分析論文11-07

案例分析論文(15篇)11-10

案例分析論文15篇11-09

民法案例分析基本方法分析論文10-10

高職數(shù)學案例教學分析論文10-10

冶金工業(yè)管道失效案例分析論文10-10

書刊印刷的印刷壓力調(diào)節(jié)案例分析論文10-10

典型的案例分析報告05-12

案例分析報告范文02-14

電話禮儀案例分析06-12