專(zhuān)利名稱(chēng)：基于sip-c協(xié)議的交互方法及系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及計(jì)算機(jī)網(wǎng)絡(luò)通信技術(shù)領(lǐng)域，特別涉及一種基于SIP-C協(xié)議的交互方法 及系統(tǒng)。
背景技術(shù)：
會(huì)話(huà)起始協(xié)議(SessionInitiation Protocol, SIP)是由 IETF 定義，基于 IP 的 一個(gè)應(yīng)用層控制協(xié)議。通過(guò)與RTP/RCP、SDP、RTSP等協(xié)議及DNS配合，SIP支持語(yǔ)音、視頻、 數(shù)據(jù)、E-mail、狀態(tài)、IM、聊天、游戲等，目前廣泛應(yīng)用于多方多媒體通信。SIP-C(Compact SIP)是一個(gè)簡(jiǎn)化和增強(qiáng)的SIP協(xié)議，是為適應(yīng)移動(dòng)終端設(shè)備的接入特點(diǎn)而設(shè)計(jì)的，但會(huì)話(huà) 的邏輯過(guò)程與SIP及相關(guān)協(xié)議確立的邏輯過(guò)程保持不變。目前各個(gè)主流操作系統(tǒng)平臺(tái)下都有自己的SIP-C協(xié)議棧實(shí)現(xiàn)方案，雖然這些方案 在各自平臺(tái)下都實(shí)現(xiàn)得較好，但是無(wú)一例外也都有一些缺陷1、未兼容多種協(xié)議，SIP-C協(xié)議應(yīng)用時(shí)所依賴(lài)的協(xié)議都是基于某一種協(xié)議(如 TCP、HTTP、HTTPS等)實(shí)現(xiàn)的，若承載協(xié)議改變(如TCP變?yōu)镠TTP)，整個(gè)實(shí)現(xiàn)都要重新設(shè) 計(jì)。2、都是基于特定平臺(tái)的，不能滿(mǎn)足跨平臺(tái)應(yīng)用的需求。3、目前基于SIP-C的應(yīng)用就需要在不同的平臺(tái)下開(kāi)發(fā)不同的版本，開(kāi)發(fā)量大大增 加，且維護(hù)成本高昂。因此，亟需設(shè)計(jì)出一種能兼容多種承載協(xié)議，能跨平臺(tái)應(yīng)用的SIP-C協(xié)議棧實(shí)現(xiàn) 方式。

發(fā)明內(nèi)容
(一)要解決的技術(shù)問(wèn)題本發(fā)明要解決的技術(shù)問(wèn)題是在SIP-C協(xié)議的數(shù)據(jù)交互中，如何實(shí)現(xiàn)兼容多種承 載協(xié)議，跨平臺(tái)的數(shù)據(jù)交互。(二)技術(shù)方案為解決上述技術(shù)問(wèn)題，本發(fā)明提供了一種基于SIP-C協(xié)議的交互方法，包括以下 步驟Sl 請(qǐng)求建立用戶(hù)代理客戶(hù)端到用戶(hù)代理服務(wù)端的連接，具體請(qǐng)求采用下述一種 方式或下述幾種方式組合進(jìn)行連接以一種承載協(xié)議的方式連接，成功與否都不再使用其它協(xié)議連接，所述承載協(xié)議 為SIP-C協(xié)議應(yīng)用時(shí)所依賴(lài)的協(xié)議；以多種承載協(xié)議的方式順序連接，且只有在當(dāng)前方式連接失敗后才嘗試下一種承 載協(xié)議連接方式，其中任一種連接成功即成功，所有連接都失敗才失敗；以多種承載協(xié)議方式并行連接，當(dāng)其中一種承載協(xié)議方式連接成功后取消其它連 接；
S2 用戶(hù)代理客戶(hù)端利用所建立的連接與用戶(hù)代理服務(wù)端進(jìn)行數(shù)據(jù)交互；S3 數(shù)據(jù)交互完成后，斷開(kāi)連接。其中，所述步驟S1中承載協(xié)議包括TCP協(xié)議，HTTP協(xié)議和HTTPS協(xié)議。其中，所述步驟S2具體包括S211 所述用戶(hù)代理客戶(hù)端利用所述連接發(fā)送數(shù)據(jù)請(qǐng)求；S212:用戶(hù)代理服務(wù)端接收并解析所述數(shù)據(jù)請(qǐng)求，并通知應(yīng)用層處理，并發(fā)送應(yīng)答 數(shù)據(jù)；S213:用戶(hù)代理客戶(hù)端接收所述應(yīng)答數(shù)據(jù)，并通知應(yīng)用層處理，同時(shí)返回確認(rèn)應(yīng)答。其中，所述步驟S211中發(fā)送數(shù)據(jù)請(qǐng)求時(shí)，先將數(shù)據(jù)緩存到發(fā)送隊(duì)列，等待發(fā)送隊(duì) 列中當(dāng)前正在發(fā)送的請(qǐng)求和應(yīng)答完畢后，再發(fā)送所述數(shù)據(jù)請(qǐng)求。其中，所述連接為異步連接。本發(fā)明還提供了一種基于SIP-C協(xié)議的交互系統(tǒng)，包括適配連接模塊，用于請(qǐng)求建立用戶(hù)代理客戶(hù)端到用戶(hù)代理服務(wù)端的連接，具體請(qǐng) 求采用下述一種方式或下述幾種方式組合進(jìn)行連接以一種承載協(xié)議的方式連接，成功與否都不再使用其它協(xié)議連接，所述承載協(xié)議 為SIP-C協(xié)議應(yīng)用時(shí)所依賴(lài)的協(xié)議；以多種承載協(xié)議的方式順序連接，且只有在當(dāng)前方式連接失敗后才嘗試下一種承 載協(xié)議連接方式，其中任一種連接成功即成功，所有連接都失敗才失?。灰远喾N承載協(xié)議方式并行連接，當(dāng)其中一種承載協(xié)議方式連接成功后取消其它連 接；數(shù)據(jù)交互模塊，用于利用所建立的連接使用戶(hù)代理客戶(hù)端與用戶(hù)代理服務(wù)端進(jìn)行 數(shù)據(jù)交互； 連接斷開(kāi)模塊，用于在數(shù)據(jù)交互完成后，斷開(kāi)連接。(三)有益效果本發(fā)明通過(guò)在連接階段對(duì)SIP-C不同的承載協(xié)議進(jìn)行適配連接，實(shí)現(xiàn)了在SIP-C 協(xié)議的數(shù)據(jù)交互中，兼容多種承載協(xié)議，跨平臺(tái)的數(shù)據(jù)交互。


圖1是本發(fā)明實(shí)施例的一種基于SIP-C協(xié)議的交互方法流程圖；圖2是圖1為實(shí)現(xiàn)步驟SlOl中的連接方式的SIP協(xié)議棧架構(gòu)圖；圖3是本發(fā)明實(shí)施例的一種基于SIP-C協(xié)議的交互系統(tǒng)結(jié)構(gòu)示意圖。
具體實(shí)施例方式下面結(jié)合附圖和實(shí)施例，對(duì)本發(fā)明的具體實(shí)施方式
作進(jìn)一步詳細(xì)描述。以下實(shí)施 例用于說(shuō)明本發(fā)明，但不用來(lái)限制本發(fā)明的范圍。如圖1所示，為本發(fā)明實(shí)施例的一種基于SIP-C協(xié)議的交互方法流程圖，包括步驟S101，請(qǐng)求建立用戶(hù)代理客戶(hù)端到用戶(hù)代理服務(wù)端的連接，請(qǐng)求采用下述一 種方式或下述幾種方式組合進(jìn)行連接
①、以一種承載協(xié)議的方式連接，成功與否都不再使用其它協(xié)議連接，所述承載協(xié) 議為SIP-C協(xié)議應(yīng)用時(shí)所依賴(lài)的協(xié)議，如傳輸層的TCP協(xié)議，應(yīng)用層的HTTPS協(xié)議和HTTP 協(xié)議；②、以多種承載協(xié)議的方式順序連接，且只有在當(dāng)前方式連接失敗后才嘗試下一 種承載協(xié)議連接方式，其中任一種連接成功即成功，所有連接都失敗才失??；③、以多種承載協(xié)議方式并行連接，當(dāng)其中一種承載協(xié)議方式連接成功后取消其 它連接。要實(shí)現(xiàn)上述三種連接方式，需要對(duì)常用的承載協(xié)議進(jìn)行封裝，并抽象出統(tǒng)一的連 接接口，為達(dá)到上述目的本實(shí)施例實(shí)現(xiàn)了三層結(jié)構(gòu)的SIP-C協(xié)議棧，如圖2所示，三個(gè)層次 為接口層、實(shí)現(xiàn)層和封裝層。1、接口層ISipcConnect是SIP-C組件的接口定義層，定義了統(tǒng)一的SIP-C組件接口，定義統(tǒng) 一的SIP-C組件接口是為了本方案能兼容多種承載協(xié)議，實(shí)現(xiàn)層的每種SIP-C組件均需實(shí) 現(xiàn)本接口。2、實(shí)現(xiàn)層(1) SipcTcpConnect是基于傳輸層TCP協(xié)議的SIP-C實(shí)現(xiàn)，基于TCP協(xié)議的SIP-C 組件實(shí)現(xiàn)了 SIP-C的發(fā)送、接收等相關(guān)操作；(2) SicpcHttpsConnect是基于應(yīng)用層HTTPS協(xié)議的SIP-C實(shí)現(xiàn)，基于HTTPS協(xié)議 的SIP-C組件實(shí)現(xiàn)了 SIP-C的發(fā)送、接收等相關(guān)操作；(3) SipcHttpConnect是基于應(yīng)用層HTTP協(xié)議的SIP-C實(shí)現(xiàn)，基于HTTP協(xié)議的 SIP-C組件實(shí)現(xiàn)了 SIP-C的發(fā)送、接收相關(guān)操作。上述具體TCP、HTTP和HTTPS協(xié)議的SIP-C組件是基于相應(yīng)操作系統(tǒng)(WINDOWS、 LINUX或MAC)的基礎(chǔ)組件實(shí)現(xiàn)。3、封裝層協(xié)議棧SipcStack 封裝 了基于 TCP 協(xié)議的 SIP-C 組件(SipcTcpConnect)， 基于HTTPS協(xié)議的SIP-C組件(SipcHttpsConnect)，基于HTTP協(xié)議的SIP-C組件 (SipcHttpConnect)，統(tǒng)一組裝和解析SIP-C信令，對(duì)外提供統(tǒng)一的SIP-C操作接口，提供了 上述定制SAP-C連接方式的方法。SipcStack還維護(hù)了一個(gè)SIP-C請(qǐng)求隊(duì)列，一個(gè)SIP-C應(yīng) 答隊(duì)列，維護(hù)網(wǎng)絡(luò)操作線(xiàn)程池，并負(fù)責(zé)組裝上層的請(qǐng)求和解析底層的應(yīng)答，上層交互。具體由UAC中的應(yīng)用程序SipcApp向協(xié)議棧SipcStack發(fā)起連接，用戶(hù)在應(yīng) 用程序中可定制采用上述①、②和③三種連接方式中的哪一種方式連接，SipcStack對(duì) 協(xié)議進(jìn)行適配，并利用適配成功的連接鏈路SipcTcpConnect、SicpcHttpsConnect或 SipcHttpConnect發(fā)起向服務(wù)器的連接，優(yōu)選為采用異步方式連接。步驟S102，用戶(hù)代理客戶(hù)端UAC(User Agent Client)利用所述連接與用戶(hù)代理服 務(wù)端UAS (User Agent Server)進(jìn)行數(shù)據(jù)交互。具體包括UAC利用步驟SlOl中建立的連接，即連接鏈路SipcTcpConnect、 SicpcHttpsConnect 禾口 SipcHttpConnect 其中之一發(fā)送數(shù)據(jù)請(qǐng)求。UAS接收并解析該數(shù)據(jù)請(qǐng)求，并由協(xié)議棧SipcStack通知應(yīng)用層處理，應(yīng)用層根據(jù) 不同的請(qǐng)求進(jìn)行不同的處理，處理后也利用該連接向UAC發(fā)送應(yīng)答數(shù)據(jù)；
UAC接收所述應(yīng)答數(shù)據(jù)，并由協(xié)議棧SipcStack通知應(yīng)用層處理，同時(shí)利用該連接 返回確認(rèn)應(yīng)答。協(xié)議棧SipcStack通知應(yīng)用層處理的方式為全局回調(diào)和局部回調(diào)，通知只發(fā)生在 用戶(hù)的主線(xiàn)程。不管是全局回調(diào)還是局部回調(diào)都在主線(xiàn)程發(fā)生的；當(dāng)上層用戶(hù)執(zhí)行一個(gè)操 作(請(qǐng)求)時(shí)，應(yīng)該在主線(xiàn)程調(diào)用，然后本協(xié)議棧會(huì)在工作線(xiàn)程執(zhí)行具體的動(dòng)作，當(dāng)執(zhí)行完 成后再通過(guò)回調(diào)函數(shù)在主線(xiàn)程回調(diào)用戶(hù)。全局回調(diào)是針對(duì)UAS來(lái)說(shuō)，因?yàn)閁AS并不知道UAC 什么時(shí)候會(huì)請(qǐng)求，所以此回調(diào)必須預(yù)先設(shè)置；當(dāng)UAS收到UAC的請(qǐng)求后，就要通過(guò)全局回調(diào) 通知給上層用戶(hù)；局部回調(diào)是針對(duì)UAC來(lái)說(shuō)，UAC發(fā)出請(qǐng)求時(shí)，就要設(shè)置一個(gè)回調(diào)函數(shù)(請(qǐng) 求時(shí)設(shè)置)，當(dāng)收到UAS的應(yīng)答時(shí)，會(huì)通過(guò)此回調(diào)函數(shù)通知上層用戶(hù)。步驟S103，當(dāng)數(shù)據(jù)交互完畢時(shí)，斷開(kāi)上述連接。本發(fā)明還提出了一種基于SIP-C協(xié)議的交互系統(tǒng)，如圖3所示，包括適配連接模塊，用于請(qǐng)求建立用戶(hù)代理客戶(hù)端到用戶(hù)代理服務(wù)端的連接，具體請(qǐng) 求采用下述一種方式或下述幾種方式組合進(jìn)行連接以一種承載協(xié)議的方式連接，成功與否都不再使用其它承載協(xié)議連接，所述承載 協(xié)議為SIP-C協(xié)議應(yīng)用時(shí)所依賴(lài)的協(xié)議；以多種承載協(xié)議的方式順序連接，且只有在當(dāng)前方式連接失敗后才嘗試下一種承 載協(xié)議連接方式，其中任一種連接成功即成功，所有連接都失敗才失??；以多種承載協(xié)議方式并行連接，當(dāng)其中一種承載協(xié)議方式連接成功后取消其它連 接；數(shù)據(jù)交互模塊，用于用戶(hù)代理客戶(hù)端利用所述連接與用戶(hù)代理服務(wù)端進(jìn)行數(shù)據(jù)交 互；連接斷開(kāi)模塊，用于數(shù)據(jù)交互完成后，斷開(kāi)連接。以上實(shí)施方式僅用于說(shuō)明本發(fā)明，而并非對(duì)本發(fā)明的限制，有關(guān)技術(shù)領(lǐng)域的普通 技術(shù)人員，在不脫離本發(fā)明的精神和范圍的情況下，還可以做出各種變化和變型，因此所有 等同的技術(shù)方案也屬于本發(fā)明的范疇，本發(fā)明的專(zhuān)利保護(hù)范圍應(yīng)由權(quán)利要求限定。
權(quán)利要求
一種基于SIP C協(xié)議的交互方法，其特征在于，包括以下步驟S 1請(qǐng)求建立用戶(hù)代理客戶(hù)端到用戶(hù)代理服務(wù)端的連接，具體請(qǐng)求采用下述一種方式或下述幾種方式組合進(jìn)行連接以一種承載協(xié)議的方式連接，成功與否都不再使用其它協(xié)議連接，所述承載協(xié)議為SIP C協(xié)議應(yīng)用時(shí)所依賴(lài)的協(xié)議；以多種承載協(xié)議的方式順序連接，且只有在當(dāng)前方式連接失敗后才嘗試下一種承載協(xié)議連接方式，其中任一種連接成功即成功，所有連接都失敗才失??；以多種承載協(xié)議方式并行連接，當(dāng)其中一種承載協(xié)議方式連接成功后取消其它連接；S2用戶(hù)代理客戶(hù)端利用所建立的連接與用戶(hù)代理服務(wù)端進(jìn)行數(shù)據(jù)交互；S3數(shù)據(jù)交互完成后，斷開(kāi)連接。
2.如權(quán)利要求1所述的基于SIP-C協(xié)議的交互方法，其特征在于，所述步驟Sl中承載 協(xié)議包括TCP協(xié)議，HTTP協(xié)議和HTTPS協(xié)議。
3.如權(quán)利要求1所述的基于SIP-C協(xié)議的交互方法，其特征在于，所述步驟S2具體包括5211所述用戶(hù)代理客戶(hù)端利用所述連接發(fā)送數(shù)據(jù)請(qǐng)求；5212用戶(hù)代理服務(wù)端接收并解析所述數(shù)據(jù)請(qǐng)求，并通知應(yīng)用層處理，處理后并發(fā)送應(yīng) 答數(shù)據(jù)；5213用戶(hù)代理客戶(hù)端接收所述應(yīng)答數(shù)據(jù)，并通知應(yīng)用層處理，同時(shí)返回確認(rèn)應(yīng)答。
4.如權(quán)利要求3所述的基于SIP-C協(xié)議的交互方法，其特征在于，所述步驟S211中發(fā) 送數(shù)據(jù)請(qǐng)求時(shí)，先將數(shù)據(jù)緩存到發(fā)送隊(duì)列，等待發(fā)送隊(duì)列中當(dāng)前正在發(fā)送的請(qǐng)求和應(yīng)答完 畢后，再發(fā)送所述數(shù)據(jù)請(qǐng)求。
5.如權(quán)利要求1 4中任一項(xiàng)所述的基于SIP-C協(xié)議的交互方法，其特征在于，所述連 接為異步連接。
6.一種基于SIP-C協(xié)議的交互系統(tǒng)，其特征在于，包括適配連接模塊，用于請(qǐng)求建立用戶(hù)代理客戶(hù)端到用戶(hù)代理服務(wù)端的連接，具體請(qǐng)求采 用下述一種方式或下述幾種方式組合進(jìn)行連接以一種承載協(xié)議的方式連接，成功與否都不再使用其它協(xié)議連接，所述承載協(xié)議為 SIP-C協(xié)議應(yīng)用時(shí)所依賴(lài)的協(xié)議；以多種承載協(xié)議的方式順序連接，且只有在當(dāng)前方式連接失敗后才嘗試下一種承載協(xié) 議連接方式，其中任一種連接成功即成功，所有連接都失敗才失?。灰远喾N承載協(xié)議方式并行連接，當(dāng)其中一種承載協(xié)議方式連接成功后取消其它連接； 數(shù)據(jù)交互模塊，用于利用所建立的連接使用戶(hù)代理客戶(hù)端與用戶(hù)代理服務(wù)端進(jìn)行數(shù)據(jù) 交互；連接斷開(kāi)模塊，用于在數(shù)據(jù)交互完成后，斷開(kāi)連接。
全文摘要
本發(fā)明公開(kāi)了一種基于SIP-C協(xié)議的交互方法，包括S1請(qǐng)求建立用戶(hù)代理客戶(hù)端到用戶(hù)代理服務(wù)端的連接，請(qǐng)求連接采用下述一種方式或下述幾種方式組合進(jìn)行連接，以一種承載協(xié)議的方式連接，成功與否都不再使用其它承載協(xié)議連接；以多種承載協(xié)議的方式順序連接，且只有在當(dāng)前方式連接失敗后才嘗試下一種承載協(xié)議連接方式，其中任一種連接成功即成功，所有連接都失敗才失??；以多種承載協(xié)議方式并行連接，當(dāng)其中一種承載協(xié)議方式連接成功后取消其它連接；S2用戶(hù)代理客戶(hù)端利用所述連接與用戶(hù)代理服務(wù)端進(jìn)行數(shù)據(jù)交互；S3數(shù)據(jù)交互完成后，斷開(kāi)所述連接。本發(fā)明實(shí)現(xiàn)了在SIP-C協(xié)議的數(shù)據(jù)交互中，兼容多種承載協(xié)議，跨平臺(tái)的數(shù)據(jù)交互。
文檔編號(hào)H04W80/10GK101969435SQ20101050389
公開(kāi)日2011年2月9日 申請(qǐng)日期2010年9月30日 優(yōu)先權(quán)日2010年9月30日
發(fā)明者唐春林, 張大偉, 梁斌, 蔣衛(wèi)濱, 馬家智 申請(qǐng)人:北京新媒傳信科技有限公司