專利名稱：一種實(shí)現(xiàn)數(shù)字集群調(diào)度臺(tái)檢測機(jī)制的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信技術(shù)領(lǐng)域，尤其涉及數(shù)字集群通信技術(shù)領(lǐng)域。
技術(shù)背景移動(dòng)通信技術(shù)在近幾年獲得了突飛猛進(jìn)的發(fā)展，其中集群通信已經(jīng)漸漸成 為不可或缺的一種通訊業(yè)務(wù)。集群通信是指一種專用的調(diào)度通訊方式，包括專 用指揮和調(diào)度通信，在使用中集群用戶可以同時(shí)加入呼叫，通話以單工方式工作。為了使集群通信業(yè)務(wù)更好地適應(yīng)專用指揮和調(diào)度通信的需求，在早期的集 群通信系統(tǒng)結(jié)構(gòu)中引入了調(diào)度臺(tái)的功能，其分為調(diào)度臺(tái)服務(wù)器和調(diào)度臺(tái)客戶端，兩者之間采用目前流行的BS即基站架構(gòu)。管理人員或操作人員通過調(diào)度 臺(tái)客戶端登錄后，可以通過WEB界面對整個(gè)系統(tǒng)的一些業(yè)務(wù)進(jìn)行管理和控制。 這個(gè)管理操作在調(diào)度臺(tái)服務(wù)器和調(diào)度臺(tái)客戶端之間是通過HTTP協(xié)議交互的。目前，由于每個(gè)session即會(huì)話擁有特定的生命周期，這樣，當(dāng)調(diào)度員一 直在忙碌于某些不和WEB服務(wù)打交道的操作，以至于超過WEB服務(wù)的session 失效時(shí)間時(shí)，將會(huì)導(dǎo)致調(diào)度員在調(diào)度臺(tái)WEB服務(wù)上的session失效，從而導(dǎo) 致調(diào)度員被調(diào)度臺(tái)強(qiáng)制退出。這種不和WEB服務(wù)打交道的操作主要分兩類 一 ，和DAS即調(diào)度臺(tái)服務(wù)器或PDS即集群調(diào)度服務(wù)器有交互，但是走的是UDP 通道，而沒有和WEB服務(wù)交互；二，根本就沒有和調(diào)度臺(tái)服務(wù)器交互，完全 只是客戶端的操作
發(fā)明內(nèi)容本發(fā)明提供一種實(shí)現(xiàn)數(shù)字集群調(diào)度臺(tái)檢測機(jī)制的方法，用以解決當(dāng)調(diào)度員忙于某些不和WEB服務(wù)器打交道的操作而超過WEB服務(wù)器的會(huì)話時(shí)效時(shí)間， 導(dǎo)致調(diào)度員被調(diào)度臺(tái)強(qiáng)制退出的問題。本發(fā)明所述方法包括手動(dòng)刷新過程和自動(dòng)刷新過程， 其中，所述自動(dòng)刷新過程具體包括以下步驟步驟A:語音控件根據(jù)相應(yīng)的操作，觸發(fā)一個(gè)自動(dòng)刷新消息給調(diào)度臺(tái)客戶二山，彿；步驟B:調(diào)度臺(tái)客戶端根據(jù)所述自動(dòng)刷新消息，調(diào)用API控件的接口；步驟C: API控件對調(diào)用消息進(jìn)行封裝，并將所述封裝后的消息發(fā)送給調(diào) 度臺(tái)服務(wù)器；所述封裝后的消息中攜帶有會(huì)話標(biāo)識(shí)；步驟D:調(diào)度臺(tái)服務(wù)器根據(jù)接收到的封裝的消息進(jìn)行解碼，判斷其中的會(huì) 話標(biāo)識(shí)是否有效，當(dāng)確認(rèn)所述標(biāo)識(shí)有效時(shí)，對所述會(huì)話進(jìn)行刷新，并向API 控件返回響應(yīng)；所述手動(dòng)刷新過程具體包括如下步驟步驟E:調(diào)度臺(tái)服務(wù)器對其保存的每個(gè)會(huì)話標(biāo)識(shí)進(jìn)行定時(shí)的掃描，判斷是否有會(huì)話將要超時(shí)，當(dāng)發(fā)現(xiàn)有會(huì)話將要超時(shí)時(shí)，關(guān)于所述會(huì)話發(fā)送一個(gè)手工刷新消息給業(yè)務(wù)控件；步驟F:業(yè)務(wù)控件將手工刷新消息上報(bào)給調(diào)度臺(tái)客戶端；步驟G:通過所述調(diào)度臺(tái)客戶端，如果所述手工刷新消息不被確認(rèn)，則本次會(huì)話將會(huì)超時(shí)退出；如果所述刷新通知被確認(rèn)，調(diào)度臺(tái)客戶端調(diào)用API控件的會(huì)話刷新接口，并依次執(zhí)行步驟C和步驟D。 進(jìn)一步地，在執(zhí)行所述步驟D之后還包括 API控件收到返回響應(yīng)后，將所述返回響應(yīng)發(fā)送給調(diào)度臺(tái)客戶端。進(jìn)一步地，所述步驟D具體包括以下步驟步驟Dl:調(diào)度臺(tái)服務(wù)器收到所述封裝后的消息后，判斷其中的會(huì)話標(biāo)識(shí) 是否存在于服務(wù)端且處于激活狀態(tài)，如果是，記錄本次客戶端對服務(wù)端的訪問 時(shí)間，并復(fù)位刷行對應(yīng)的會(huì)話定時(shí)器；否則，直接將該條消息丟棄；步驟D2:調(diào)度臺(tái)服務(wù)器向API控件返回響應(yīng)。進(jìn)一步地，所述步驟E具體包括步驟El:調(diào)度臺(tái)服務(wù)器對其保存的每個(gè)會(huì)話標(biāo)識(shí)進(jìn)行定時(shí)的掃描，判斷 所述會(huì)話非激活時(shí)長是否大于會(huì)話超時(shí)最大時(shí)長，如果是，作會(huì)話超時(shí)處理， 否則，獲取所述會(huì)話標(biāo)識(shí)對應(yīng)的是否發(fā)送過手工刷新的標(biāo)志；步驟E2:根據(jù)所述標(biāo)志進(jìn)行判斷，如果已經(jīng)發(fā)送過手工刷新消息，且所 述會(huì)話非激活時(shí)長小于會(huì)話刷新最大時(shí)長時(shí)，則將所述標(biāo)志設(shè)置為沒有發(fā)送過 手工刷性通知；如果尚未發(fā)送過手工刷新消息，且會(huì)話非激活時(shí)長大于會(huì)話刷 新最大時(shí)長時(shí)，發(fā)送手工刷新消息給業(yè)務(wù)控件。進(jìn)一步地，所述會(huì)話刷新最大時(shí)長等于會(huì)話超時(shí)最大時(shí)長減去超時(shí)保護(hù)時(shí) 間得到的差值。進(jìn)一步地，所述會(huì)話非激活時(shí)長等于所述會(huì)話當(dāng)前時(shí)間減去上訪時(shí)間得到 的差值。進(jìn)一步地，所述步驟A中，所述相應(yīng)的操作包括下述操作之一申請?jiān)挋?quán)，釋放話權(quán)，申請?jiān)挋?quán)后講話、設(shè)置當(dāng)前通道、設(shè)置語音的聲道。進(jìn)一步地，所述步驟C中，API控件將所述自動(dòng)刷新消息封裝成HTTP+XML的形式。綜上所述，本發(fā)明提供了一種實(shí)現(xiàn)數(shù)字集群調(diào)度臺(tái)檢測機(jī)制的方法，根據(jù)
具體業(yè)務(wù)的需要，是會(huì)話能被合理地清除和保活，以方便會(huì)話的管理。從而達(dá) 到既滿足調(diào)度員可以控制即將超時(shí)的會(huì)話是否被刷新的需要，也避免了因?yàn)榭?制即將超時(shí)而給調(diào)度員來帶過多的不必要干擾信息的問題。


圖l是本發(fā)明實(shí)施例用到的調(diào)度臺(tái)服務(wù)器、調(diào)度服務(wù)器和調(diào)度臺(tái)客戶端內(nèi)部結(jié)構(gòu)的模塊連接圖；圖2是本發(fā)明實(shí)施例所述方法的流程示意圖；圖3是本發(fā)明實(shí)施例中，調(diào)度臺(tái)服務(wù)器進(jìn)行會(huì)話掃描和管理的流程示意圖； 圖4是本發(fā)明實(shí)施例中，調(diào)度臺(tái)客戶端處理手工刷新的流程示意圖。
具體實(shí)施方式
下面結(jié)合附圖對本發(fā)明實(shí)施例所述方法進(jìn)行詳細(xì)闡述。本發(fā)明實(shí)施例所述的實(shí)現(xiàn)數(shù)字集群調(diào)度臺(tái)檢測機(jī)制的方法，主要用于以下情況當(dāng)調(diào)度員一直在忙碌于某些不和WEB服務(wù)打交道的操作，以至于超過WEB服務(wù)的session失效時(shí)間時(shí)，將會(huì)導(dǎo)致調(diào)度員在調(diào)度臺(tái)WEB服務(wù)上的session失效，從而導(dǎo)致調(diào)度員被調(diào)度臺(tái)強(qiáng)制退出。這種不和WEB服務(wù)打交道的操作主要分兩類 一，和調(diào)度臺(tái)服務(wù)器或集群調(diào)度服務(wù)器有交互，但是走的是UDP通道，而沒有和WEB服務(wù)交互；二，根本就沒有和調(diào)度臺(tái)服務(wù)器交互，完全只是客戶端的操作。如圖l所示，圖1是本發(fā)明實(shí)施例涉及到的調(diào)度臺(tái)服務(wù)器和調(diào)度臺(tái)客戶端內(nèi)部結(jié)構(gòu)的模塊連接圖，本發(fā)明實(shí)施所述方法主要涉及調(diào)度臺(tái)服務(wù)器和調(diào)度臺(tái)客戶端之間的消息交互，其中所述調(diào)度臺(tái)客戶端主要包括API控件、語音控件、業(yè)務(wù)控件和WEB頁面。
所述方法包括自動(dòng)刷新過程和手動(dòng)刷新過程，下面分別進(jìn)行說明。所述自動(dòng)刷新過程具體可以包括如下步驟步驟201，語音控件發(fā)出自動(dòng)刷新消息；具體的說就是，語音控件根據(jù)實(shí) 現(xiàn)定義的操作，所述實(shí)現(xiàn)定義的操作，比如申請?jiān)挋?quán)，釋放話權(quán)，申請?jiān)挋?quán)后 講話，設(shè)置當(dāng)前通道，設(shè)置語音的聲道等操:作，觸發(fā)一個(gè)自動(dòng)刷新消息給調(diào)度 臺(tái)客戶端，所述自動(dòng)通知消息是一個(gè)異步消息；自動(dòng)刷新是由特定的操作觸發(fā) 的， 一旦動(dòng)作發(fā)生，即觸發(fā)自動(dòng)刷新；這類動(dòng)作定義為和調(diào)度臺(tái)服務(wù)器/調(diào)度服 務(wù)器有交互，但是走的是UDP (用戶數(shù)據(jù)報(bào)協(xié)議)通道，而沒有和WEB服務(wù) 交互的操作；步驟202,調(diào)度臺(tái)客戶端調(diào)用SessionRefresh (會(huì)話更新)接口；具體的說 就是，調(diào)度臺(tái)客戶端收到語音控件發(fā)來的自動(dòng)刷新消息后，開始調(diào)用API控件 的會(huì)話更新接口，這里調(diào)用所用的調(diào)用消息是一個(gè)同步消息；這里在API控件 里要定義接口刷新方法給調(diào)度臺(tái)客戶端調(diào)用；步驟203， API控件對所述調(diào)用消息進(jìn)行處理，進(jìn)行格式的處理封裝；具 體的說就是，API將接收到的調(diào)用消息封裝成HTTP+XML的格式，并攜帶有 本次會(huì)話的sesssion id (會(huì)話標(biāo)識(shí))；攜帶有本次會(huì)話的session id，是為了使調(diào) 度臺(tái)服務(wù)器能夠區(qū)分不同的調(diào)度臺(tái)客戶端所對應(yīng)的會(huì)話，以使得相應(yīng)的會(huì)話能 在本次消息的處理中得到刷新；然后API控件將封裝后的消息發(fā)給調(diào)度臺(tái)服務(wù) 器；步驟204,調(diào)度臺(tái)服務(wù)器收到所述封裝后的消息后，對其進(jìn)行解碼分析， 這里主要是分析其中的session id是否合理，即該session id存在于服務(wù)端且處 于激活狀態(tài)，如果合理則進(jìn)行相應(yīng)的會(huì)話刷新操作，記錄本次客戶端對服務(wù)端
的訪問時(shí)間，并復(fù)位刷4亍對應(yīng)的 session定日于器；^口果i亥session id不合玉里,貝'J 調(diào)度臺(tái)服務(wù)器直接將該條消息丟棄，不進(jìn)行下一步的處理；同時(shí)，調(diào)度臺(tái)服務(wù) 器需要給調(diào)度臺(tái)客戶端返回響應(yīng)。所述手工刷新過程可以包括如下步驟步驟205，調(diào)度臺(tái)服務(wù)器的用于會(huì)話管理的掃描定時(shí)器對其管理的所有激 活的會(huì)話進(jìn)行掃描，如果發(fā)現(xiàn)有會(huì)話快要超時(shí)的話，則會(huì)向業(yè)務(wù)控件發(fā)出手工 刷新消息；具體的說就是，對會(huì)話是否超時(shí)的判斷會(huì)涉及到兩個(gè)配置文件， Tomcat的<CATALINA—HOME>/webapps/applicationname/WEB-INF/目錄下的 一個(gè)文件中設(shè)置有某個(gè)具體WEB應(yīng)用的超時(shí)間隔，例如設(shè)置為30分鐘；在同 目錄下的另外一個(gè)文件中配置有一個(gè)超時(shí)保護(hù)時(shí)間，如果會(huì)話的客戶端對服務(wù) 端的訪問間隔超過上面提及的兩個(gè)配置的時(shí)間的差的話，則調(diào)度臺(tái)服務(wù)器給業(yè) 務(wù)控件發(fā)出關(guān)于所述會(huì)話的手工刷新消息；有關(guān)調(diào)度臺(tái)服務(wù)器掃描和管理的具 體過程如圖2所示，后面將作詳細(xì)說明。步驟206,業(yè)務(wù)控件將手工刷新消息上報(bào)給調(diào)度臺(tái)客戶端； 步驟207,調(diào)度臺(tái)客戶端的web頁面彈出手工刷新提示的對話框，提示調(diào) 度員會(huì)話即將超時(shí)退出，并將在隨后的多長時(shí)間結(jié)束會(huì)話，比如5分鐘之后； 需要調(diào)度員手工確認(rèn)該條信息才能?；顣?huì)話，如果調(diào)度員 一直不對該信息進(jìn)行 確認(rèn)，那么該次會(huì)話將在5分鐘之后被超時(shí)退出；這個(gè)提示的5分鐘，是從調(diào) 度臺(tái)服務(wù)器的配置文件中讀取的，參見步驟中205提到的第二個(gè)配置文件；當(dāng) 調(diào)度員登錄的時(shí)候，調(diào)度臺(tái)服務(wù)器回復(fù)給調(diào)度臺(tái)客戶端的登錄響應(yīng)中，帶上調(diào) 度臺(tái)服務(wù)器端的這個(gè)配置時(shí)間；同時(shí)在調(diào)度臺(tái)客戶端中設(shè)置一個(gè)全局變量，例 如命名為sessionTimeoutkiterval,以保存調(diào)度臺(tái)服務(wù)器發(fā)來的這個(gè)配置時(shí)間； 當(dāng)調(diào)度臺(tái)客戶端彈出需要調(diào)度員手工確認(rèn)的提示框時(shí)，填入該變量的值即可； 為了實(shí)際應(yīng)用上的方便，對于某些特殊的操作，不需要彈出頁面讓用戶確認(rèn)； 比如某些持續(xù)時(shí)間比較長，但是人工干預(yù)時(shí)間跨度比較大的操作可能會(huì)導(dǎo)致會(huì) 話超時(shí)退出，這樣的話就要求調(diào)度員定期來做確認(rèn)操作，比較麻煩；這里以錄 音為例子來說明，當(dāng)調(diào)度臺(tái)進(jìn)行錄音操作的時(shí)候，調(diào)度員本人可以離開操作地 點(diǎn)，但是當(dāng)滿足會(huì)話刷新條件時(shí)，如果調(diào)度員沒有及時(shí)回來確認(rèn)，將導(dǎo)致會(huì)話 超時(shí)退出；這里對錄音進(jìn)行特殊處理，當(dāng)業(yè)務(wù)控件向調(diào)度臺(tái)客戶端上報(bào)手工刷 新消息的時(shí)候，不再彈出對話框要求調(diào)度員確認(rèn)，而是由調(diào)度臺(tái)客戶端直接處 理，調(diào)用API控件的會(huì)話刷新接口，直接進(jìn)入下一步的處理；調(diào)度員對提示信息手工確認(rèn)后，隨后調(diào)度臺(tái)客戶端調(diào)用API控件的會(huì)話刷 新的接口；隨后的處理同步驟202 204。圖3是步驟205，調(diào)度臺(tái)服務(wù)器掃描和管理過程的流程示意圖，具體包括 以下步驟步驟301,調(diào)度臺(tái)服務(wù)器的session掃描定時(shí)器到達(dá)的時(shí)候，啟動(dòng)掃描線程， 遍歷服務(wù)端保存的session id,對于每個(gè)具體的session id,調(diào)用會(huì)話超時(shí)處理 函數(shù)，在本實(shí)施例中將該函數(shù)命名為isSessionTimeout;然后執(zhí)行步驟302;步驟302，計(jì)算該sessionid所關(guān)聯(lián)的session的非激活時(shí)長t，計(jì)算方法為 當(dāng)前時(shí)間減去上去訪問的時(shí)間；然后執(zhí)行步驟303;步艱《303, 乂人Tomcat的<CATALINA—HOME>/ webapps/applicat ionname/WEB-INF/目錄下的web.xml文件中獲取會(huì)話超時(shí)最大時(shí)長tl ，在同目 錄下的另外一個(gè)配置文件再讀取超時(shí)保護(hù)時(shí)間t3,用tl減去t3,得到會(huì)話刷 新最大時(shí)長t2;然后執(zhí)行步驟304;
步驟304,比較非激活時(shí)長t與會(huì)話超時(shí)最大時(shí)長tl;如果t〉tl， 轉(zhuǎn)步驟305,否則轉(zhuǎn)步驟307;步驟305,做會(huì)話超時(shí)處理，調(diào)度臺(tái)服務(wù)器清除該session id所關(guān)聯(lián)的相關(guān) 信息，并將調(diào)度員從頁面退出；并執(zhí)行步驟306;步驟306， isSessionTimeout函數(shù)執(zhí)行結(jié)束,該session id所關(guān)聯(lián)的session 的處理結(jié)束。步驟307, session不滿足超時(shí)退出的條件，獲取該sessionid的對應(yīng)的是否 發(fā)送過手工刷新的標(biāo)志；然后執(zhí)行步驟308;步驟308，根據(jù)獲得的是否發(fā)送過手工刷性的標(biāo)志進(jìn)行判斷，如果沒有發(fā) 送過手工刷新消息，轉(zhuǎn)步驟309;如果已經(jīng)發(fā)送過手工刷新消息，轉(zhuǎn)步驟311; 此處進(jìn)行是否發(fā)送過手工刷新消息的判斷，是為了避免在調(diào)度臺(tái)客戶端頁面彈 出多余的對話框；步驟309,比較該session的非激活時(shí)長t與會(huì)話刷新最大時(shí)長t2，如果t>t2， 轉(zhuǎn)步驟310,否則轉(zhuǎn)步驟312;步驟310,滿足發(fā)手工刷新消息的條件，此時(shí)調(diào)度臺(tái)服務(wù)器發(fā)送手工刷新 請求給業(yè)務(wù)控件，并將該session id的是否發(fā)送過手工刷新標(biāo)志的標(biāo)識(shí)置為已 發(fā)送；并執(zhí)行步驟312;步驟311,經(jīng)判斷已經(jīng)發(fā)送過手工刷新消息后，才會(huì)進(jìn)入此步驟；所以比 較該session的非激活時(shí)長t與會(huì)話刷新最大時(shí)長t2;若干1>12，轉(zhuǎn)入步驟312; 否則轉(zhuǎn)入步驟313; t>t2表明調(diào)度臺(tái)服務(wù)器發(fā)送過手工刷新消息給業(yè)務(wù)控件， 但是業(yè)務(wù)控件沒有將該通知消息發(fā)給調(diào)度臺(tái)客戶端頁面；或者調(diào)度員還沒有確 認(rèn)該消息；或者調(diào)度員已經(jīng)確認(rèn)，但是API控件的接口發(fā)送給調(diào)度臺(tái)服務(wù)器的 消息還沒有到調(diào)度臺(tái)服務(wù)器；所以調(diào)度臺(tái)服務(wù)器端的時(shí)間差值t還沒有被復(fù)位； 這一步的操作是為了避免在調(diào)度臺(tái)客戶端頁面出現(xiàn)多余的提示對話框。步驟312， isSessionTimeout函數(shù)執(zhí)行結(jié)束，針對此次的 session掃描,該 sessionid所關(guān)耳關(guān)的session的處J里結(jié)束；步驟313, t<t2表明調(diào)度臺(tái)服務(wù)器端的時(shí)間差值t已經(jīng)被復(fù)位，此次session 自動(dòng)檢測刷新流程已經(jīng)結(jié)束；所以此時(shí)設(shè)置該session id的是否發(fā)送過手工刷 新標(biāo)志的標(biāo)識(shí)為未發(fā)送；標(biāo)識(shí)為未發(fā)送是為了讓下次的session檢測能繼續(xù)正 常工作；隨后轉(zhuǎn)入步驟312;再由步驟312結(jié)束該session的此次刷新操作。圖4是本發(fā)明調(diào)度臺(tái)客戶端手工刷新的流程圖，包括的步驟如下步驟401，當(dāng)調(diào)度臺(tái)客戶端收到由業(yè)務(wù)控件發(fā)來的手工刷新消息的時(shí)候， 開始調(diào)用手工會(huì)話刷新函數(shù)，在本實(shí)施例中命名為manualSessionRefresh;步驟402，在manualSessionRefresh函數(shù)中，遍歷所有組呼、單呼對象， 判斷是否有對象處于錄音狀態(tài)，若有則置錄音變量值為"true",如果所有對象 都不處于錄音狀態(tài)，則置錄音變量值為"false";在本實(shí)施例中，錄音變量記 為isRecordVoice;步驟403，根據(jù)isRecordVoice的取值進(jìn)行判斷，如果值為true,轉(zhuǎn)入步驟 404,如果值為false,轉(zhuǎn)入406。步驟404，因?yàn)橛袑ο筇幚礓浺魻顟B(tài)，所以在這里直接調(diào)用API控件的會(huì) 話刷新接口 ，將刷新請求封裝成HTTP+XML的格式發(fā)送給調(diào)度臺(tái)服務(wù)器處理；步驟405，調(diào)度臺(tái)服務(wù)器對刷新請求進(jìn)行處理，同時(shí)向調(diào)度臺(tái)客戶端返回 響應(yīng)。步驟406，因設(shè)置了變量記錄是否已經(jīng)彈出了手工刷新消息的對話框，所
以在這里根據(jù)該變量的值來判斷是否已經(jīng)彈出了對話框；如果已經(jīng)彈出對話 框，轉(zhuǎn)步驟407;如果還沒有彈出對話框，則轉(zhuǎn)入408。步驟407，不彈出手工刷新消息的對話框，manualSessionRefresh函數(shù)返回。步驟408,在調(diào)度臺(tái)客戶端的頁面彈出手工刷新消息的對話框，等待調(diào)度 員對其進(jìn)行確認(rèn)操作；步驟409,調(diào)度員對彈出的對話進(jìn)行操作，不進(jìn)行確認(rèn)，轉(zhuǎn)入步驟410; 如果調(diào)度員進(jìn)行確認(rèn)操作，轉(zhuǎn)入步驟404，隨后的流程同404-405。步驟410,由于調(diào)度員未進(jìn)行確認(rèn)，刷新流程處于等待狀態(tài)，頁面的對話 框也處于等待狀態(tài)；如果等待的時(shí)間超過步驟205中提到的第二個(gè)配置文件里 所描述的時(shí)長后，會(huì)話超時(shí)退出；在該時(shí)長范圍內(nèi)調(diào)度員如果進(jìn)行確認(rèn)操作， 則隨后的步驟同409 ~ 404 ~ 405 。綜上所述，本發(fā)明實(shí)施例提供了 一種在實(shí)現(xiàn)數(shù)字集群通信系統(tǒng)中調(diào)度臺(tái)檢 測機(jī)制的方法，以方便會(huì)話的管理，根據(jù)具體業(yè)務(wù)的需要，使會(huì)話能被合理地 清除和?；睢＿@種方法既滿足調(diào)度員可以控制即將超時(shí)的會(huì)話是否被刷新的需 要，也避免了因?yàn)榭刂萍磳⒊瑫r(shí)的會(huì)話而帶來的過多的提示信息，避免給調(diào)度 員帶來不必要的干擾信息。此種方法更加符合數(shù)字集群業(yè)務(wù)的使用習(xí)慣和現(xiàn)實(shí) 的需求，也符合集群通信作為調(diào)度指揮，緊急聯(lián)動(dòng)系統(tǒng)本身的特殊需要，符合 曰益人性化并且不斷細(xì)化的集群通信業(yè)務(wù)的需求。以上所述也僅是本發(fā)明實(shí)施 的優(yōu)選實(shí)例而已，并不僅限于本發(fā)明實(shí)施例。本發(fā)明實(shí)施例所述方法也可以用 在其它的基于BS架構(gòu)的應(yīng)用系統(tǒng)中；其中WEB服務(wù)器也可以采用非Jakarta Tomcat的服務(wù)器，比如Weblogic，WebSphere等WEB服務(wù)器。以上所述，僅為本發(fā)明較佳的具體實(shí)施方式
，但本發(fā)明的保護(hù)范圍并不局
限于此，任何熟悉本技術(shù)領(lǐng)域的技術(shù)人員在本發(fā)明揭露的技術(shù)范圍內(nèi)，可輕易 想到的變化或替換，都應(yīng)涵蓋在本發(fā)明的保護(hù)范圍之內(nèi)。因此，本發(fā)明的保護(hù) 范圍應(yīng)該以權(quán)利要求書的保護(hù)范圍為準(zhǔn)。
權(quán)利要求
1、一種實(shí)現(xiàn)數(shù)字集群調(diào)度臺(tái)檢測機(jī)制的方法，其特征在于，所述方法包括手動(dòng)刷新過程和自動(dòng)刷新過程，其中，所述自動(dòng)刷新過程包括以下步驟步驟A語音控件根據(jù)相應(yīng)的操作，觸發(fā)一個(gè)自動(dòng)刷新消息給調(diào)度臺(tái)客戶端；步驟B調(diào)度臺(tái)客戶端根據(jù)所述自動(dòng)刷新消息，調(diào)用API控件的接口；步驟CAPI控件對調(diào)用消息進(jìn)行封裝，并將所述封裝后的消息發(fā)送給調(diào)度臺(tái)服務(wù)器；所述封裝后的消息中攜帶有會(huì)話標(biāo)識(shí)；步驟D調(diào)度臺(tái)服務(wù)器根據(jù)接收到的封裝的消息進(jìn)行解碼，判斷其中的會(huì)話標(biāo)識(shí)是否有效，當(dāng)確認(rèn)所述標(biāo)識(shí)有效時(shí)，對所述會(huì)話進(jìn)行刷新，并向API控件返回響應(yīng)；所述手動(dòng)刷新過程包括如下步驟步驟E調(diào)度臺(tái)服務(wù)器對其保存的每個(gè)會(huì)話標(biāo)識(shí)進(jìn)行定時(shí)的掃描，判斷是否有會(huì)話將要超時(shí)，當(dāng)發(fā)現(xiàn)有會(huì)話將要超時(shí)時(shí)，關(guān)于所述會(huì)話發(fā)送一個(gè)手工刷新消息給業(yè)務(wù)控件；步驟F業(yè)務(wù)控件將手工刷新消息上報(bào)給調(diào)度臺(tái)客戶端；步驟G通過所述調(diào)度臺(tái)客戶端，如果所述手工刷新消息不被確認(rèn)，則本次會(huì)話將會(huì)超時(shí)退出；如果所述刷新消息被確認(rèn)，調(diào)度臺(tái)客戶端調(diào)用API控件的會(huì)話刷新接口，并依次執(zhí)行步驟C和步驟D。
2、根據(jù)權(quán)利要求1所述的方法，其特在在于，在執(zhí)行所述步驟D之后還包括..API控件收到返回響應(yīng)后，將所述返回響應(yīng)發(fā)送給調(diào)度臺(tái)客戶端。
3、 根據(jù)權(quán)利要求1或2所述的方法，其特征在于，所述步驟D具體包括 以下步驟步驟Dl:調(diào)度臺(tái)服務(wù)器收到所述封裝后的消息后，判斷其中的會(huì)話標(biāo)識(shí) 是否存在于服務(wù)端且處于激活狀態(tài)，如果是，記錄本次客戶端對服務(wù)端的訪問 時(shí)間，并復(fù)位刷行對應(yīng)的會(huì)話定時(shí)器；否則，直接將該條消息丟棄；步驟D2:調(diào)度臺(tái)服務(wù)器向API控件返回響應(yīng)。
4、 根據(jù)權(quán)利要求1或2所述的方法，其特征在于，所述步驟E具體包括 步驟El:調(diào)度臺(tái)服務(wù)器對其保存的每個(gè)會(huì)話標(biāo)識(shí)進(jìn)行定時(shí)的掃描，判斷所述會(huì)話非激活時(shí)長是否大于會(huì)話超時(shí)最大時(shí)長，如果是，作會(huì)話超時(shí)處理， 否則，獲取所述會(huì)話標(biāo)識(shí)對應(yīng)的是否發(fā)送過手工刷新的標(biāo)志；步驟E2:根據(jù)所述標(biāo)志進(jìn)行判斷，如果已經(jīng)發(fā)送過手工刷新消息，且所 述會(huì)話非激活時(shí)長小于會(huì)話刷新最大時(shí)長時(shí)，則將所述標(biāo)志設(shè)置為沒有發(fā)送過 手工刷性通知；如果尚未發(fā)送過手工刷新消息，且會(huì)話非激活時(shí)長大于會(huì)話刷 新最大時(shí)長時(shí)，發(fā)送手工刷新消息給業(yè)務(wù)控件。
5、 根據(jù)權(quán)利要求4所述的方法，其特征在于，所述會(huì)話刷新最大時(shí)長等 于會(huì)話超時(shí)最大時(shí)長減去超時(shí)保護(hù)時(shí)間得到的差值。
6、 根據(jù)權(quán)利要求4所述的方法，其特征在于，所述會(huì)話非激活時(shí)長等于 所述會(huì)話當(dāng)前時(shí)間減去上訪時(shí)間得到的差值。
7、 根據(jù)權(quán)利要求1或2所述的方法，其特征在于，所述步驟A中，所述 相應(yīng)的操作包括下述操作之一申請?jiān)挋?quán)，釋放話權(quán)，申請?jiān)挋?quán)后講話、設(shè)置 當(dāng)前通道、設(shè)置語音的聲道。
8、 根據(jù)權(quán)利要求1或2所述的方法，其特征在于，所述步驟C中，API 控件將所述自動(dòng)刷新消息封裝成HTTP+XML的形式。
全文摘要
本發(fā)明公開了一種實(shí)現(xiàn)數(shù)字集群調(diào)度臺(tái)檢測機(jī)制的方法，本發(fā)明所述方法包括手動(dòng)刷新過程和自動(dòng)刷新過程。本發(fā)明所述方法根據(jù)具體業(yè)務(wù)的需要，使會(huì)話能被合理地清除和?；睢＿@種方法既滿足調(diào)度員可以控制即將超時(shí)的會(huì)話是否被刷新的需要，也避免了因?yàn)榭刂萍磳⒊瑫r(shí)的會(huì)話而帶來的過多的提示信息，避免給調(diào)度員帶來不必要的干擾信息。
文檔編號(hào)H04Q7/28GK101159925SQ20071014546
公開日2008年4月9日 申請日期2007年9月13日 優(yōu)先權(quán)日2007年9月13日
發(fā)明者操 丁, 玥 李, 王小平 申請人:中興通訊股份有限公司