本發(fā)明涉及通信技術(shù)，尤其涉及一種通信方法和系統(tǒng)。

背景技術(shù)：

在4G移動互聯(lián)網(wǎng)時(shí)代，互聯(lián)網(wǎng)廠家在移動應(yīng)用領(lǐng)域快速發(fā)展，出現(xiàn)了一批類似微信、QQ、米聊等的OTT應(yīng)用，它們具有免費(fèi)、體驗(yàn)豐富等特色，并且迭代快速，能不斷為用戶提供新業(yè)務(wù)特性，因此逐漸蠶食著運(yùn)營商的用戶群與收入。

與OTT應(yīng)用相比，運(yùn)營商傳統(tǒng)的，作為基礎(chǔ)電信業(yè)務(wù)的短彩信業(yè)務(wù)常年體驗(yàn)單一，無法支持豐富的媒體類型和業(yè)務(wù)功能，無法滿足用戶增長的使用需求，因此，對傳統(tǒng)短彩信業(yè)務(wù)進(jìn)行升級，增強(qiáng)用戶粘度，成為了運(yùn)營商必須面對的課題。

為解決這個問題，運(yùn)營商大多采用了兩種不同的方式，推出了自身的即時(shí)消息業(yè)務(wù)：

第一種是運(yùn)營商直接學(xué)習(xí)互聯(lián)網(wǎng)廠家，推出自身使用OTT技術(shù)的即時(shí)消息軟件(以下稱OTT方式)，例如中國移動的飛信和中國電信的易信等，這種方式完全使用互聯(lián)網(wǎng)解決方案，用戶需要下載安裝特定的APP，并進(jìn)行注冊賬戶(對于運(yùn)營商的OTT即時(shí)消息軟件，通常使用手機(jī)號作為用戶賬號進(jìn)展注冊，即用戶名為手機(jī)號，而實(shí)際消息路由分發(fā)等使用OTT內(nèi)部標(biāo)識)、添加好友等操作，通過APP的互聯(lián)網(wǎng)私有通信協(xié)議與其他好友進(jìn)行即時(shí)消息通信，可以說，該方式是一種以用戶社交屬性為核心的方式；

第二種是使用電信國際標(biāo)準(zhǔn)，通過對GSMA RCS國際協(xié)議的支持，推動手機(jī)廠家升級終端上原有的通話、短/彩信和通訊錄三大通信入口，以終端原生方 式(Native，即終端在出廠時(shí)就已具備功能)支持即時(shí)消息(以下稱融合通信方式)，如中國移動融合通信。該方式用戶無需下載安裝特定APP或添加好友，可以繼承用戶原有通信習(xí)慣。同時(shí)，由于使用國際標(biāo)準(zhǔn)，該方式保證了運(yùn)營商基礎(chǔ)通信業(yè)務(wù)全球可達(dá)性和電信級服務(wù)質(zhì)量，可以說，該方式是以通信能力為核心的方式。

進(jìn)入移動互聯(lián)網(wǎng)時(shí)代時(shí)，運(yùn)營商通常會首先選擇第一方式提供即時(shí)消息，從而積累了一定的OTT即時(shí)消息用戶，隨著國際標(biāo)準(zhǔn)的發(fā)展和終端、芯片等產(chǎn)業(yè)的推進(jìn)，在手機(jī)上通過融合通信方式提供即時(shí)消息成為了可能。同時(shí)，隨著移動互聯(lián)網(wǎng)產(chǎn)品競爭壓力的加大，運(yùn)營商單純使用自身并不擅長的OTT方式很難在競爭中獲得優(yōu)勢，因此越來越多運(yùn)營商開始將升級基礎(chǔ)電信能力，以通信能力為核心的融合通信方式作為了即時(shí)消息的發(fā)展方向。但是，早期運(yùn)營商OTT即時(shí)消息已積累的一定的用戶，如何繼續(xù)充分利用這些用戶資源，使得融合通信方式提供的即時(shí)消息可以盡快被更多用戶使用，成為了運(yùn)營商需要考慮的問題。

解決這一問題的方式，就是實(shí)現(xiàn)運(yùn)營商互聯(lián)網(wǎng)即時(shí)通信系統(tǒng)與基于電信標(biāo)準(zhǔn)的即時(shí)通信系統(tǒng)的充分融合，保留用戶數(shù)據(jù)和關(guān)鍵業(yè)務(wù)功能，實(shí)現(xiàn)業(yè)務(wù)發(fā)展的“冷啟動”。用戶可以在手機(jī)、PC、Pad等終端上使用即使消息功能，對于同一個用戶來講，他在不同終端上使用的即時(shí)消息功能應(yīng)具備同樣的用戶身份。移動互聯(lián)網(wǎng)時(shí)代，用戶已更多將手機(jī)而非PC作為主要通信設(shè)備使用，因此融合時(shí)，考慮將手機(jī)作為用戶的主設(shè)備，即手機(jī)側(cè)以用戶的E.164號碼為通信基礎(chǔ)，以融合通信方式實(shí)現(xiàn)即時(shí)消息，同時(shí)將該用戶OTT即時(shí)消息使用的標(biāo)識與該用戶E.164號碼關(guān)聯(lián)，繼續(xù)在PC、Pad等客戶端上使用OTT方式提供即時(shí)消息，并將OTT形成的群聊等社交關(guān)系導(dǎo)入電信標(biāo)準(zhǔn)即時(shí)消息系統(tǒng)中。

這種方式，可以充分利用運(yùn)營商OTT即時(shí)消息積累的用戶，并可享受電信即使消息帶來的基礎(chǔ)電信互通、可達(dá)等優(yōu)勢，但這種方式需要將兩種原理機(jī)制不同的即時(shí)消息系統(tǒng)在用戶體驗(yàn)層面整合，如用戶在自身一個設(shè)備上發(fā)送或收到消息，在另一個使用不同方式實(shí)現(xiàn)的設(shè)備上也需要對這些消息進(jìn)行同步，即 也能顯示出已發(fā)送或收到了同樣的消息。由于互聯(lián)網(wǎng)和電信系統(tǒng)相互實(shí)現(xiàn)方式有很大區(qū)別，因此融合存在巨大挑戰(zhàn)。

現(xiàn)階段，不同消息系統(tǒng)之間，一般通過設(shè)置互通網(wǎng)關(guān)的方式進(jìn)行互通，如圖1所示。該方式由網(wǎng)關(guān)完成不同消息系統(tǒng)間的協(xié)議轉(zhuǎn)化工作。

多終端之間的消息同步，通常是在同構(gòu)系統(tǒng)中的不同終端之間進(jìn)行，如電信系統(tǒng)中IMS的多終端消息機(jī)制和OTT即時(shí)消息系統(tǒng)在不同平臺上同時(shí)登錄時(shí)的消息收發(fā)方式等。

其中，IMS多終端消息機(jī)制如圖2所示，該方式要求同一用戶使用的全部終端均基于SIP實(shí)現(xiàn)，都具有同樣的SIP用戶身份標(biāo)識(IMPI/IMPU)，通過不同的SIP實(shí)例(sip.instance或GRUU)在IMS中進(jìn)行注冊，所有消息都被存入集中消息存儲平臺中，在接收消息時(shí)，通過IMS的forking機(jī)制將同一個消息拆成多條，分別發(fā)到每一個終端實(shí)例，對于不在線的終端，在其上線后通過集中消息存儲平臺使用推送的方式實(shí)現(xiàn)消息同步。

OTT即時(shí)消息系統(tǒng)使用的方式與之類似，對于接收方有多個設(shè)備的場景，一般發(fā)送時(shí)根據(jù)接收方登陸狀態(tài)將消息分別寫入多個消息隊(duì)列中，并且分別通知接收方的各個終端有消息更新，由接收方對比本地消息記錄后，到服務(wù)器拉取相應(yīng)消息，此后接收設(shè)備通知服務(wù)器某消息已接收，服務(wù)器可以將該設(shè)備的這部分消息從對應(yīng)消息隊(duì)列中刪除。

圖1所示設(shè)置互通網(wǎng)關(guān)的方式，只能用于發(fā)送方和接收方使用不同消息協(xié)議的場景，無法滿足同一個用戶使用不同協(xié)議類型終端發(fā)送和接收到的消息進(jìn)行同步需求。

圖2所示IMS網(wǎng)絡(luò)中多終端的方案，不支持非IMS終端，并且要求IMS具備forking功能，現(xiàn)有電信網(wǎng)絡(luò)中的設(shè)備通常并不具備，需要改造，同時(shí)，要求新部署集中消息存儲平臺。

圖3所示OTT即時(shí)消息系統(tǒng)中多終端消息的方法要求所有終端都使用相同的消息協(xié)議實(shí)現(xiàn)，無法提供使用不同協(xié)議的終端之間的消息同步和轉(zhuǎn)化。

因此，現(xiàn)有多終端技術(shù)只實(shí)現(xiàn)了同一個即時(shí)消息系統(tǒng)內(nèi)的多終端消息同步， 對于互聯(lián)網(wǎng)與電信兩類不同機(jī)制的即時(shí)消息系統(tǒng)融合構(gòu)成的系統(tǒng)，現(xiàn)有互聯(lián)網(wǎng)領(lǐng)域或電信領(lǐng)域的多終端消息技術(shù)均較難滿足多終端消息收發(fā)和同步需求。

技術(shù)實(shí)現(xiàn)要素：

為解決現(xiàn)有存在的技術(shù)問題，本發(fā)明實(shí)施例提供一種融合通信方法和系統(tǒng)。

本發(fā)明實(shí)施例提供的一種通信方法，所述方法包括：

確定接入第一即時(shí)消息系統(tǒng)的移動通信終端在所述第一即時(shí)消息系統(tǒng)所使用的功能，所述第一即時(shí)消息系統(tǒng)基于電信系統(tǒng)實(shí)現(xiàn)即時(shí)消息通信，所述功能基于第一協(xié)議；

將所述功能抽象為應(yīng)用程序編程接口API，所述API采用第二協(xié)議；

所述第一即時(shí)消息系統(tǒng)通過所述API與第二即時(shí)消息系統(tǒng)進(jìn)行交互，使接入所述第二即時(shí)消息系統(tǒng)的客戶端獲取所述移動通信終端通過所述第一即時(shí)消息系統(tǒng)進(jìn)行通信的信息，所述客戶端使用所述移動終端的唯一識別碼進(jìn)行的注冊，所述第二即時(shí)消息系統(tǒng)基于互聯(lián)網(wǎng)實(shí)現(xiàn)即時(shí)消息通信；

所述第一協(xié)議與所述第二協(xié)議不相同。

其中，所述API基于OMA表述性狀態(tài)轉(zhuǎn)移架構(gòu)RESTful，所述第二協(xié)議采用HTTP協(xié)議；所述第一即時(shí)消息系統(tǒng)通過所述API與所述第二即時(shí)消息系統(tǒng)進(jìn)行交互包括：

所述第一即時(shí)消息系統(tǒng)通過所述API和REST接口與所述第二即時(shí)消息系統(tǒng)進(jìn)行交互；

所述API能夠供所述第二即時(shí)消息系統(tǒng)通過所述第二協(xié)議調(diào)用，或者所述第一即時(shí)消息系統(tǒng)內(nèi)的消息或功能以HTTP調(diào)用或響應(yīng)的方式告知所述第二即時(shí)消息系統(tǒng)。

其中，所述功能包括至少以下功能中的一種：登記功能、即時(shí)消息功能、文件傳輸功能、群聊功能；所述第一協(xié)議為SIP協(xié)議；

所述將第一即時(shí)消息系統(tǒng)的功能抽象為API包括至少以下抽象中的一種：

將SIP登記通告抽象為RESTful注冊；

將SIP即時(shí)消息抽象為RESTful消息；

將SIP Invite/MSRP文件傳輸抽象為RESTful消息；

將SIP Invite/MSRP群聊抽象為RESTful群聊。

其中，所述移動通信終端通過SIP協(xié)議接入第一即時(shí)消息系統(tǒng)的IMS；

所述第二即時(shí)消息系統(tǒng)為OTT即時(shí)消息系統(tǒng)，客戶端通過HTTP協(xié)議接入OTT即時(shí)消息系統(tǒng)。

其中，所述第一即時(shí)消息系統(tǒng)通過所述API與第二即時(shí)消息系統(tǒng)進(jìn)行交互包括：

所述第一即時(shí)消息系統(tǒng)的即時(shí)消息AS通過所述API和第二即時(shí)消息系統(tǒng)的OTT服務(wù)器進(jìn)行交互。

其中，所述方法還包括：獲取所述第二即時(shí)消息系統(tǒng)的登錄記錄；

根據(jù)所述登錄記錄，確定所述第二即時(shí)消息系統(tǒng)所處的狀態(tài)；

當(dāng)所述第二即時(shí)消息系統(tǒng)處于第一狀態(tài)時(shí)，將所述第二即時(shí)消息系統(tǒng)具有客戶端的信息進(jìn)行登記。

其中，所述第一即時(shí)消息系統(tǒng)通過所述API與第二即時(shí)消息系統(tǒng)進(jìn)行交互包括：

當(dāng)所述移動通信終端發(fā)送的消息到達(dá)主叫歸屬的即時(shí)消息AS時(shí)，所述即時(shí)消息AS判斷主叫用戶是否具有客戶端的登記，若有，則在所述即時(shí)消息系統(tǒng)內(nèi)進(jìn)行正常的后續(xù)消息流程的同時(shí)，將即時(shí)消息業(yè)務(wù)通過所述API轉(zhuǎn)發(fā)到第二即時(shí)消息系統(tǒng)的OTT服務(wù)器，后續(xù)由所述OTT服務(wù)器下發(fā)給此主叫用戶的OTT客戶端。

其中，所述第一即時(shí)消息系統(tǒng)通過所述API與第二即時(shí)消息系統(tǒng)進(jìn)行交互包括：

當(dāng)即時(shí)消息到達(dá)被叫歸屬的即時(shí)消息AS時(shí)，所述即時(shí)消息AS判斷被叫用戶是否具有客戶端的登記，若有，則在所述即時(shí)消息系統(tǒng)內(nèi)進(jìn)行正常的后續(xù)消息流程的同時(shí)，將即時(shí)消息業(yè)務(wù)通過所述API轉(zhuǎn)發(fā)到第二即時(shí)消息系統(tǒng)的OTT服務(wù)器，后續(xù)由所述OTT服務(wù)器下發(fā)給此被叫用戶的OTT客戶端。

其中，所述方法還包括：獲取所述客戶端的信息收發(fā)記錄；

根據(jù)所述信息收發(fā)記錄，確定所述客戶端的類別；

當(dāng)所述客戶端為第一類別時(shí)，向所述客戶端發(fā)送的消息中包括第一標(biāo)識字段，所述第一標(biāo)識字段用于指示所述客戶端在收到所述消息后不做提示處理。

本發(fā)明實(shí)施例提供一種即時(shí)消息系統(tǒng)，所述即時(shí)消息系統(tǒng)包括電信系統(tǒng)，所述即時(shí)消息系統(tǒng)基于所述電信系統(tǒng)實(shí)現(xiàn)即時(shí)消息通信，所述電信系統(tǒng)用于確定接入所述即時(shí)消息系統(tǒng)的移動通信終端在所述即時(shí)消息系統(tǒng)所使用的功能，所述功能基于第一協(xié)議；所述即時(shí)消息系統(tǒng)還包括Network API設(shè)備：

所述Network API設(shè)備，用于將所述功能抽象為應(yīng)用程序編程接口API，所述API采用第二協(xié)議；

所述電信系統(tǒng)，用于通過所述API與第二即時(shí)消息系統(tǒng)進(jìn)行交互，使接入所述第二即時(shí)消息系統(tǒng)的客戶端獲取所述移動通信終端通過所述即時(shí)消息系統(tǒng)進(jìn)行通信的信息，所述客戶端使用所述移動終端的唯一識別碼進(jìn)行的注冊，所述第二即時(shí)消息系統(tǒng)基于互聯(lián)網(wǎng)實(shí)現(xiàn)即時(shí)消息通信；

所述第一協(xié)議與所述第二協(xié)議不相同。

其中，所述API基于OMA表述性狀態(tài)轉(zhuǎn)移架構(gòu)RESTful，所述第二協(xié)議采用HTTP協(xié)議；

所述電信系統(tǒng)，用于通過所述API和REST接口與所述第二即時(shí)消息系統(tǒng)進(jìn)行交互；

所述API能夠供所述第二即時(shí)消息系統(tǒng)通過所述第二協(xié)議調(diào)用，或者將所述即時(shí)消息系統(tǒng)內(nèi)的消息或功能以HTTP調(diào)用或響應(yīng)的方式告知所述第二即時(shí)消息系統(tǒng)。

其中，所述功能包括至少以下功能中的一種：登記功能、即時(shí)消息功能、文件傳輸功能、群聊功能；所述第一協(xié)議為SIP協(xié)議；

所述Network API設(shè)備，用于將SIP登記通告抽象為RESTful注冊；將SIP即時(shí)消息抽象為RESTful消息；將SIP Invite/MSRP文件傳輸抽象為RESTful消息；將SIP Invite/MSRP群聊抽象為RESTful群聊。

其中，所述移動通信終端通過SIP協(xié)議接入所述電信系統(tǒng)的IMS；

所述第二即時(shí)消息系統(tǒng)為OTT即時(shí)消息系統(tǒng)，客戶端通過HTTP協(xié)議接入OTT即時(shí)消息系統(tǒng)。

其中，所述電信系統(tǒng)的即時(shí)消息AS通過所述API和第二即時(shí)消息系統(tǒng)的OTT服務(wù)器進(jìn)行交互。

其中，所述電信系統(tǒng)的即時(shí)消息AS，用于獲取所述第二即時(shí)消息系統(tǒng)的登錄記錄；

根據(jù)所述登錄記錄，確定所述第二即時(shí)消息系統(tǒng)所處的狀態(tài)；

當(dāng)所述第二即時(shí)消息系統(tǒng)處于第一狀態(tài)時(shí)，將所述第二即時(shí)消息系統(tǒng)具有客戶端的信息進(jìn)行登記。

其中，當(dāng)所述移動通信終端發(fā)送的消息到達(dá)主叫歸屬的即時(shí)消息AS時(shí)，所述即時(shí)消息AS用于判斷主叫用戶是否具有客戶端的登記，若有，則在所述即時(shí)消息系統(tǒng)內(nèi)進(jìn)行正常的后續(xù)消息流程的同時(shí)，將即時(shí)消息業(yè)務(wù)通過所述API轉(zhuǎn)發(fā)到第二即時(shí)消息系統(tǒng)的OTT服務(wù)器，后續(xù)由所述OTT服務(wù)器下發(fā)給此主叫用戶的OTT客戶端。

其中，當(dāng)即時(shí)消息到達(dá)被叫歸屬的即時(shí)消息AS時(shí)，所述即時(shí)消息AS用于判斷被叫用戶是否具有客戶端的登記，若有，則在所述即時(shí)消息系統(tǒng)內(nèi)進(jìn)行正常的后續(xù)消息流程的同時(shí)，將即時(shí)消息業(yè)務(wù)通過所述API轉(zhuǎn)發(fā)到第二即時(shí)消息系統(tǒng)的OTT服務(wù)器，后續(xù)由所述OTT服務(wù)器下發(fā)給此被叫用戶的OTT客戶端。

其中，所述即時(shí)消息AS用于獲取所述客戶端的信息收發(fā)記錄；根據(jù)所述信息收發(fā)記錄，確定所述客戶端的類別；

當(dāng)所述客戶端為第一類別時(shí)，向所述客戶端發(fā)送的消息中包括第一標(biāo)識字段，所述第一標(biāo)識字段用于指示所述客戶端在收到所述消息后不做提示處理。

由上可知，本發(fā)明實(shí)施例的技術(shù)方案包括：確定接入第一即時(shí)消息系統(tǒng)的移動通信終端在所述第一即時(shí)消息系統(tǒng)所使用的功能，所述第一即時(shí)消息系統(tǒng)基于電信系統(tǒng)實(shí)現(xiàn)即時(shí)消息通信，所述功能基于第一協(xié)議；將所述功能抽象為應(yīng)用程序編程接口API，所述API采用第二協(xié)議；所述第一即時(shí)消息系統(tǒng)通過 所述API與第二即時(shí)消息系統(tǒng)進(jìn)行交互，使接入所述第二即時(shí)消息系統(tǒng)的客戶端獲取所述移動通信終端通過所述第一即時(shí)消息系統(tǒng)進(jìn)行通信的信息，所述客戶端使用所述移動終端的唯一識別碼進(jìn)行的注冊，所述第二即時(shí)消息系統(tǒng)基于互聯(lián)網(wǎng)實(shí)現(xiàn)即時(shí)消息通信；所述第一協(xié)議與所述第二協(xié)議不相同。由此，本發(fā)明實(shí)施例具備下述有益效果：1、通過API調(diào)用的方式，使同一用戶使用同樣的移動電話號碼身份可以使用多種不同的終端，這些終端分別使用不同的協(xié)議并且可以分別處于互聯(lián)網(wǎng)和電信網(wǎng)等不同架構(gòu)網(wǎng)絡(luò)環(huán)境中的，可以分別收發(fā)消息并實(shí)現(xiàn)不同終端之間的消息同步；2、電信網(wǎng)即時(shí)通信系統(tǒng)與互聯(lián)網(wǎng)OTT即時(shí)通信系統(tǒng)相對獨(dú)立，分別自身控制向另外一方的消息抄送，可以實(shí)現(xiàn)多終端一對一消息、群聊和管理的流程。3、不需要對電信核心網(wǎng)設(shè)備就行修改，不改變IMS路由流程，所有到PC側(cè)的消息抄送邏輯由應(yīng)用服務(wù)器進(jìn)行，同時(shí)不需要改變OTT側(cè)的協(xié)議和實(shí)現(xiàn)模式，由OTT服務(wù)器作為API調(diào)用方控制消息流程。

附圖說明

圖1為不同即時(shí)消息系統(tǒng)通過設(shè)置互通網(wǎng)關(guān)的方式進(jìn)行互通的示意圖；

圖2為IMS網(wǎng)絡(luò)中多終端消息的原理示意圖；

圖3為OTT即時(shí)消息系統(tǒng)中多終端消息的原理示意圖；

圖4為本發(fā)明提供的一種通信方法的第一實(shí)施例的流程示意圖；

圖5為本發(fā)明提供的一種通信方法的第二實(shí)施例的流程示意圖；

圖6為本發(fā)明提供的一種通信方法的第三實(shí)施例的流程示意圖；

圖7為本發(fā)明提供的一種通信方法的第四實(shí)施例的流程示意圖；

圖8為本發(fā)明提供的一種即時(shí)消息系統(tǒng)的一實(shí)施例的結(jié)構(gòu)示意圖；

圖9為互聯(lián)網(wǎng)即時(shí)通信系統(tǒng)與電信即時(shí)通信系統(tǒng)融合后的系統(tǒng)總體架的示意圖；

圖10為Network API將電信網(wǎng)即時(shí)消息系統(tǒng)能力抽象為OTT系統(tǒng)可理解的API的示意圖；

圖11為為OTT客戶端到融合通信系統(tǒng)的注冊的流程示意圖；

圖12為Native終端/APP客戶端實(shí)現(xiàn)遠(yuǎn)程控制的架構(gòu)示意圖；

圖13為用戶Native終端/APP客戶端獲取自身PC客戶端登錄狀態(tài)的流程示意圖；

圖14為PC客戶端強(qiáng)制注銷的流程示意圖；

圖15為用戶A使用手機(jī)向用戶B發(fā)送消息的流程示意圖；

圖16為用戶A使用OTT客戶端向用戶B發(fā)送消息的流程示意圖；

圖17為用戶手機(jī)向自身OTT客戶端發(fā)送消息的流程示意圖；

圖18為用戶PC客戶端向自身Native/APP發(fā)送消息的流程示意圖；

圖19為過渡期結(jié)束后UE_A發(fā)起群聊的流程示意圖；

圖20為過渡期結(jié)束后PC_A發(fā)起群聊的流程示意圖。

具體實(shí)施方式

本發(fā)明提供的一種通信方法的第一實(shí)施例，如圖4所示，所述方法包括：

步驟401、確定接入第一即時(shí)消息系統(tǒng)的移動通信終端在所述第一即時(shí)消息系統(tǒng)所使用的功能；

所述第一即時(shí)消息系統(tǒng)基于電信系統(tǒng)實(shí)現(xiàn)即時(shí)消息通信，所述功能基于第一協(xié)議；這里，所述第一協(xié)議可以為SIP協(xié)議；

所述功能包括至少以下功能中的一種：登記功能、即時(shí)消息功能、文件傳輸功能、群聊功能；

在實(shí)際應(yīng)用中，所述移動通信終端通過SIP協(xié)議接入第一即時(shí)消息系統(tǒng)的IMS。

這里要說明的是，所述第一即時(shí)消息系統(tǒng)可以是電信即時(shí)消息系統(tǒng)。所述移動通信終端以終端原生方式(Native，即終端在出廠時(shí)就已具備功能)支持即時(shí)消息，本文中也稱為融合通信方式。

步驟402、將所述功能抽象為應(yīng)用程序編程接口API；

這里，所述API采用第二協(xié)議；

在實(shí)際應(yīng)用中，參見圖10所示，所述將第一即時(shí)消息系統(tǒng)的功能抽象為API包括至少以下抽象中的一種：

將SIP登記通告抽象為RESTful注冊；

將SIP即時(shí)消息抽象為RESTful消息；

將SIP Invite/MSRP文件傳輸抽象為RESTful消息；

將SIP Invite/MSRP群聊抽象為RESTful群聊。

下面舉例對如何進(jìn)行抽象進(jìn)行說明。

例如，電信系統(tǒng)中的注冊功能，可以抽象為：HTTP POST方法，調(diào)用連接為http://{serverRoot}/register/{apiVersion}/{userId}/sessions，其中，serverRoot標(biāo)識要注冊的服務(wù)器地址，apiVersion為OTT系統(tǒng)調(diào)用電信系統(tǒng)注冊能力時(shí)使用的API版本號，userId為發(fā)起注冊的用戶的ID，例如，發(fā)起注冊的用戶電話號碼為19585550100，則此處值為tel:+19585550100。

即時(shí)消息功能可抽象為HTTP POST方法，調(diào)用鏈接為http://{serverRoot}/messaging/{apiVersion}/outbound/{senderAddress}/requests，其中，serverRoot標(biāo)識即時(shí)消息服務(wù)器地址，apiVersion為OTT系統(tǒng)調(diào)用電信系統(tǒng)注冊能力時(shí)使用的API版本號，senderAddress標(biāo)識為發(fā)送用戶標(biāo)識，同時(shí)，通過http消息的消息體攜帶聊天相關(guān)信息，如表1所示。

表1

步驟403、所述第一即時(shí)消息系統(tǒng)通過所述API與第二即時(shí)消息系統(tǒng)進(jìn)行交互，使接入所述第二即時(shí)消息系統(tǒng)的客戶端獲取所述移動通信終端通過所述第一即時(shí)消息系統(tǒng)進(jìn)行通信的信息；

這里，需要說明的是，所述客戶端使用所述移動終端的唯一識別碼如MSISDN進(jìn)行的注冊，所述第二即時(shí)消息系統(tǒng)基于互聯(lián)網(wǎng)實(shí)現(xiàn)即時(shí)消息通信；所述第一協(xié)議與所述第二協(xié)議不相同。

這里要說明的是，所述第二即時(shí)消息系統(tǒng)可以是OTT即時(shí)消息系統(tǒng)。

本發(fā)明提供的一種通信方法的第二實(shí)施例，如圖5所示，所述方法包括：

步驟501、確定接入第一即時(shí)消息系統(tǒng)的移動通信終端在所述第一即時(shí)消息系統(tǒng)所使用的功能；

這里，所述第一即時(shí)消息系統(tǒng)基于電信系統(tǒng)實(shí)現(xiàn)即時(shí)消息通信，所述功能基于第一協(xié)議；

步驟502、將所述功能抽象為應(yīng)用程序編程接口API；

這里，所述API采用第二協(xié)議；所述第二協(xié)議采用HTTP協(xié)議；

在實(shí)際應(yīng)用中，所述API基于OMA表述性狀態(tài)轉(zhuǎn)移架構(gòu)RESTful；

步驟503、所述第一即時(shí)消息系統(tǒng)通過所述API和REST接口與所述第二即時(shí)消息系統(tǒng)進(jìn)行交互；使接入所述第二即時(shí)消息系統(tǒng)的客戶端獲取所述移動通信終端通過所述第一即時(shí)消息系統(tǒng)進(jìn)行通信的信息；

這里，所述API能夠供所述第二即時(shí)消息系統(tǒng)通過所述第二協(xié)議調(diào)用，或者所述第一即時(shí)消息系統(tǒng)內(nèi)的消息或功能以HTTP調(diào)用或響應(yīng)的方式告知所述第二即時(shí)消息系統(tǒng)。

需要說明的是，所述客戶端使用所述移動終端的唯一識別碼進(jìn)行的注冊， 所述第二即時(shí)消息系統(tǒng)基于互聯(lián)網(wǎng)實(shí)現(xiàn)即時(shí)消息通信；所述第一協(xié)議與所述第二協(xié)議不相同。

在實(shí)際應(yīng)用中，所述第二即時(shí)消息系統(tǒng)為OTT即時(shí)消息系統(tǒng)，客戶端通過HTTP協(xié)議接入OTT即時(shí)消息系統(tǒng)。

具體的，所述第一即時(shí)消息系統(tǒng)通過所述API與第二即時(shí)消息系統(tǒng)進(jìn)行交互包括：

所述第一即時(shí)消息系統(tǒng)的即時(shí)消息AS通過所述API和第二即時(shí)消息系統(tǒng)的OTT服務(wù)器進(jìn)行交互。

本發(fā)明提供的一種通信方法的第三實(shí)施例，如圖6所示，所述方法包括：

步驟601、確定接入第一即時(shí)消息系統(tǒng)的移動通信終端在所述第一即時(shí)消息系統(tǒng)所使用的功能；

這里，所述第一即時(shí)消息系統(tǒng)基于電信系統(tǒng)實(shí)現(xiàn)即時(shí)消息通信，所述功能基于第一協(xié)議；所述第一協(xié)議為SIP協(xié)議；

可以理解的是，所述功能包括至少以下功能中的一種：登記功能、即時(shí)消息功能、文件傳輸功能、群聊功能；

在實(shí)際應(yīng)用中，所述移動通信終端通過SIP協(xié)議接入第一即時(shí)消息系統(tǒng)的IMS；

步驟602、將所述功能抽象為應(yīng)用程序編程接口API；

這里，所述API采用第二協(xié)議；

在實(shí)際應(yīng)用中，所述將第一即時(shí)消息系統(tǒng)的功能抽象為API包括至少以下抽象中的一種：

將SIP登記通告抽象為RESTful注冊；

將SIP即時(shí)消息抽象為RESTful消息；

將SIP Invite/MSRP文件傳輸抽象為RESTful消息；

將SIP Invite/MSRP群聊抽象為RESTful群聊。

步驟603、所述第一即時(shí)消息系統(tǒng)通過所述API與第二即時(shí)消息系統(tǒng)進(jìn)行交互，使接入所述第二即時(shí)消息系統(tǒng)的客戶端獲取所述移動通信終端通過所述 第一即時(shí)消息系統(tǒng)進(jìn)行通信的信息；

這里，所述客戶端使用所述移動終端的唯一識別碼進(jìn)行的注冊，所述第二即時(shí)消息系統(tǒng)基于互聯(lián)網(wǎng)實(shí)現(xiàn)即時(shí)消息通信；所述第一協(xié)議與所述第二協(xié)議不相同。

步驟604、獲取所述第二即時(shí)消息系統(tǒng)的登錄記錄；

步驟605、根據(jù)所述登錄記錄，確定所述第二即時(shí)消息系統(tǒng)所處的狀態(tài)；

步驟606、當(dāng)所述第二即時(shí)消息系統(tǒng)處于第一狀態(tài)時(shí)，將所述第二即時(shí)消息系統(tǒng)具有客戶端的信息進(jìn)行登記；

步驟607、將所述移動通信終端通過所述第一即時(shí)消息系統(tǒng)進(jìn)行通信的信息通過所述API轉(zhuǎn)發(fā)給所述第二即時(shí)消息系統(tǒng)，以使所述客戶端獲取所述信息。

具體的，將所述移動通信終端通過所述第一即時(shí)消息系統(tǒng)進(jìn)行通信的信息通過所述API轉(zhuǎn)發(fā)給所述第二即時(shí)消息系統(tǒng)包括：

當(dāng)所述移動通信終端發(fā)送的消息到達(dá)主叫歸屬的即時(shí)消息AS時(shí)，所述即時(shí)消息AS判斷主叫用戶是否具有客戶端的登記，若有，則在所述即時(shí)消息系統(tǒng)內(nèi)進(jìn)行正常的后續(xù)消息流程的同時(shí)，將即時(shí)消息業(yè)務(wù)通過所述API轉(zhuǎn)發(fā)到第二即時(shí)消息系統(tǒng)的OTT服務(wù)器，后續(xù)由所述OTT服務(wù)器下發(fā)給此主叫用戶的OTT客戶端；或者，

當(dāng)即時(shí)消息到達(dá)被叫歸屬的即時(shí)消息AS時(shí)，所述即時(shí)消息AS判斷被叫用戶是否具有客戶端的登記，若有，則在所述即時(shí)消息系統(tǒng)內(nèi)進(jìn)行正常的后續(xù)消息流程的同時(shí)，將即時(shí)消息業(yè)務(wù)通過所述API轉(zhuǎn)發(fā)到第二即時(shí)消息系統(tǒng)的OTT服務(wù)器，后續(xù)由所述OTT服務(wù)器下發(fā)給此被叫用戶的OTT客戶端。

這里，所述第一狀態(tài)是指所述第二即時(shí)消息系統(tǒng)處于活躍狀態(tài)，如沒有超過一周未登錄。

本發(fā)明提供的一種通信方法的第四實(shí)施例，如圖7所示，所述方法包括：

步驟701、確定接入第一即時(shí)消息系統(tǒng)的移動通信終端在所述第一即時(shí)消息系統(tǒng)所使用的功能；

這里，所述第一即時(shí)消息系統(tǒng)基于電信系統(tǒng)實(shí)現(xiàn)即時(shí)消息通信，所述功能 基于第一協(xié)議；所述第一協(xié)議為SIP協(xié)議；

在實(shí)際應(yīng)用中，所述功能包括至少以下功能中的一種：登記功能、即時(shí)消息功能、文件傳輸功能、群聊功能；

可以理解的是，所述移動通信終端通過SIP協(xié)議接入第一即時(shí)消息系統(tǒng)的IMS；

步驟702、將所述功能抽象為應(yīng)用程序編程接口API；

這里，所述API采用第二協(xié)議；

可以理解的是，所述將第一即時(shí)消息系統(tǒng)的功能抽象為API包括至少以下抽象中的一種：

將SIP登記通告抽象為RESTful注冊；

將SIP即時(shí)消息抽象為RESTful消息；

將SIP Invite/MSRP文件傳輸抽象為RESTful消息；

將SIP Invite/MSRP群聊抽象為RESTful群聊。

步驟703、所述第一即時(shí)消息系統(tǒng)通過所述API與第二即時(shí)消息系統(tǒng)進(jìn)行交互，使接入所述第二即時(shí)消息系統(tǒng)的客戶端獲取所述移動通信終端通過所述第一即時(shí)消息系統(tǒng)進(jìn)行通信的信息；

這里，所述客戶端使用所述移動終端的唯一識別碼進(jìn)行的注冊，所述第二即時(shí)消息系統(tǒng)基于互聯(lián)網(wǎng)實(shí)現(xiàn)即時(shí)消息通信；所述第一協(xié)議與所述第二協(xié)議不相同。

步驟704、獲取所述客戶端的信息收發(fā)記錄；

步驟705、根據(jù)所述信息收發(fā)記錄，確定所述客戶端的類別；

步驟706、當(dāng)所述客戶端為第一類別時(shí)，向所述客戶端發(fā)送的消息中包括第一標(biāo)識字段，所述第一標(biāo)識字段用于指示所述客戶端在收到所述消息后不做提示處理。

這里，所述第一類別是指所述客戶端為靜默客戶端。具體的，即時(shí)消息AS將最近一條消息來自的客戶端判定其為活躍客戶端，另外一種客戶端為靜默客戶端，當(dāng)超過一定時(shí)間長度(如5分鐘)時(shí)，若即時(shí)消息AS沒有再收到消息， 則即時(shí)消息AS認(rèn)為所有在線客戶端均應(yīng)視為活躍客戶端。

本發(fā)明提供的一種即時(shí)消息系統(tǒng)的實(shí)施例，如圖8所示，所述即時(shí)消息系統(tǒng)包括電信系統(tǒng)801，所述即時(shí)消息系統(tǒng)基于所述電信系統(tǒng)801實(shí)現(xiàn)即時(shí)消息通信，所示電信系統(tǒng)801用于確定接入所述即時(shí)消息系統(tǒng)的移動通信終端在所述即時(shí)消息系統(tǒng)所使用的功能，所述功能基于第一協(xié)議；所述即時(shí)消息系統(tǒng)還包括Network API設(shè)備802：

所述Network API設(shè)備802，用于將所述功能抽象為應(yīng)用程序編程接口API，所述API采用第二協(xié)議；

所述電信系統(tǒng)801，用于通過所述API與第二即時(shí)消息系統(tǒng)進(jìn)行交互，使接入所述第二即時(shí)消息系統(tǒng)的客戶端獲取所述移動通信終端通過所述即時(shí)消息系統(tǒng)進(jìn)行通信的信息，所述客戶端使用所述移動終端的唯一識別碼進(jìn)行的注冊，所述第二即時(shí)消息系統(tǒng)基于互聯(lián)網(wǎng)實(shí)現(xiàn)即時(shí)消息通信；

所述第一協(xié)議與所述第二協(xié)議不相同。

在實(shí)際應(yīng)用中，所述移動通信終端通過SIP協(xié)議接入所述電信系統(tǒng)801的IMS；

所述第二即時(shí)消息系統(tǒng)為OTT即時(shí)消息系統(tǒng)，客戶端通過HTTP協(xié)議接入OTT即時(shí)消息系統(tǒng)。

具體的，所述電信系統(tǒng)801的即時(shí)消息AS通過所述API和第二即時(shí)消息系統(tǒng)的OTT服務(wù)器進(jìn)行交互。

在一實(shí)施例中，所述API基于OMA表述性狀態(tài)轉(zhuǎn)移架構(gòu)RESTful，所述第二協(xié)議采用HTTP協(xié)議；

所述電信系統(tǒng)801，用于通過所述API和REST接口與所述第二即時(shí)消息系統(tǒng)進(jìn)行交互；

所述API能夠供所述第二即時(shí)消息系統(tǒng)通過所述第二協(xié)議調(diào)用，或者將所述即時(shí)消息系統(tǒng)內(nèi)的消息或功能以HTTP調(diào)用或響應(yīng)的方式告知所述第二即時(shí)消息系統(tǒng)。

在一實(shí)施例中，所述功能包括至少以下功能中的一種：登記功能、即時(shí)消 息功能、文件傳輸功能、群聊功能；所述第一協(xié)議為SIP協(xié)議；

參見圖10所示，所述Network API設(shè)備802，用于將SIP登記通告抽象為RESTful注冊；將SIP即時(shí)消息抽象為RESTful消息；將SIP Invite/MSRP文件傳輸抽象為RESTful消息；將SIP Invite/MSRP群聊抽象為RESTful群聊。

在一實(shí)施例中，所述電信系統(tǒng)801的即時(shí)消息AS，用于獲取所述第二即時(shí)消息系統(tǒng)的登錄記錄；

根據(jù)所述登錄記錄，確定所述第二即時(shí)消息系統(tǒng)所處的狀態(tài)；

當(dāng)所述第二即時(shí)消息系統(tǒng)處于第一狀態(tài)時(shí)，將所述第二即時(shí)消息系統(tǒng)具有客戶端的信息進(jìn)行登記。

當(dāng)所述移動通信終端發(fā)送的消息到達(dá)主叫歸屬的即時(shí)消息AS時(shí)，所述即時(shí)消息AS用于判斷主叫用戶是否具有客戶端的登記，若有，則在所述即時(shí)消息系統(tǒng)內(nèi)進(jìn)行正常的后續(xù)消息流程的同時(shí)，將即時(shí)消息業(yè)務(wù)通過所述API轉(zhuǎn)發(fā)到第二即時(shí)消息系統(tǒng)的OTT服務(wù)器，后續(xù)由所述OTT服務(wù)器下發(fā)給此主叫用戶的OTT客戶端。

當(dāng)即時(shí)消息到達(dá)被叫歸屬的即時(shí)消息AS時(shí)，所述即時(shí)消息AS用于判斷被叫用戶是否具有客戶端的登記，若有，則在所述即時(shí)消息系統(tǒng)內(nèi)進(jìn)行正常的后續(xù)消息流程的同時(shí)，將即時(shí)消息業(yè)務(wù)通過所述API轉(zhuǎn)發(fā)到第二即時(shí)消息系統(tǒng)的OTT服務(wù)器，后續(xù)由所述OTT服務(wù)器下發(fā)給此被叫用戶的OTT客戶端。

在一實(shí)施例中，所述即時(shí)消息AS用于獲取所述客戶端的信息收發(fā)記錄；

根據(jù)所述信息收發(fā)記錄，確定所述客戶端的類別；

當(dāng)所述客戶端為第一類別時(shí)，向所述客戶端發(fā)送的消息中包括第一標(biāo)識字段，所述第一標(biāo)識字段用于指示所述客戶端在收到所述消息后不做提示處理。

下面結(jié)合附圖和具體實(shí)施例對本發(fā)明的技術(shù)方案進(jìn)一步詳細(xì)闡述。

為解決同一用戶分別擁有互聯(lián)網(wǎng)和電信兩類即時(shí)消息系統(tǒng)這一場景下的多終端消息收發(fā)問題，本發(fā)明提出了一種使用電信能力開放思想，將互聯(lián)網(wǎng)即時(shí)消息系統(tǒng)作為電信能力開放的調(diào)用者，通過API方式與電信即時(shí)消息系統(tǒng)交互實(shí)現(xiàn)用戶多終端消息收發(fā)和同步的技術(shù)方案。該方案整體架構(gòu)如圖9所示。

該方案中，通過在電信即時(shí)消息系統(tǒng)中設(shè)置Network API設(shè)備，將電信即時(shí)消息系統(tǒng)的能力，包含基于SIP協(xié)議的注冊、即時(shí)消息、文件傳輸、群聊等抽象成使用HTTP協(xié)議，基于OMA表述性狀態(tài)轉(zhuǎn)移(representational state transfer,RESTFul)架構(gòu)設(shè)計(jì)的的一組應(yīng)用程序編程接口(Application Programming Interface,API)，這些API可以供OTT即時(shí)消息系統(tǒng)通過HTTP方法調(diào)用，或者將電信即時(shí)消息系統(tǒng)內(nèi)的消息或能力以HTTP調(diào)用/響應(yīng)的方式告知OTT即時(shí)消息系統(tǒng)。

該架構(gòu)下，用戶A和B的手機(jī)(UE_A、UE_B)使用電信融合通信方式實(shí)現(xiàn)即時(shí)消息，通過SIP協(xié)議接入電信融合通信系統(tǒng)中的IMS，其他客戶端，如PC等(PC_A、PC_B)，使用互聯(lián)網(wǎng)OTT方式實(shí)現(xiàn)即時(shí)消息，通過HTTP協(xié)議接入互聯(lián)網(wǎng)OTT系統(tǒng)，同時(shí)，假設(shè)用戶的所有OTT客戶端均使用該用戶的手機(jī)號碼MSISDN進(jìn)行注冊，并且能夠注冊的用戶應(yīng)具備手機(jī)，同時(shí)其手機(jī)具有融合通信功能。融合通信系統(tǒng)和OTT系統(tǒng)分別負(fù)責(zé)各自客戶端的接入、鑒權(quán)、業(yè)務(wù)處理工作。融合通信系統(tǒng)內(nèi)的Network API負(fù)責(zé)將融合通信的能力抽象為RESTFul風(fēng)格的API，而OTT系統(tǒng)內(nèi)的Network API網(wǎng)關(guān)負(fù)責(zé)對這些API進(jìn)行調(diào)用，兩個消息系統(tǒng)間通過REST接口進(jìn)行交互。這里需要說明的是，OTT系統(tǒng)內(nèi)不設(shè)置Network API，僅通過Network API網(wǎng)關(guān)對電信系統(tǒng)能力進(jìn)行調(diào)用以及被電信系統(tǒng)抽象出的HTTP方法進(jìn)行訪問。此處是假設(shè)OTT系統(tǒng)本身是基于HTTP相關(guān)方式實(shí)現(xiàn)，因此只需要設(shè)置網(wǎng)關(guān)即可，不需要再設(shè)置一個網(wǎng)管設(shè)備用于轉(zhuǎn)化能力。但是，若OTT系統(tǒng)使用的私有協(xié)議是非標(biāo)準(zhǔn)協(xié)議，則需要設(shè)置一個OTT的Network API，將非標(biāo)準(zhǔn)協(xié)議轉(zhuǎn)化為標(biāo)準(zhǔn)HTTP協(xié)議。

該方案中，同一用戶不同終端之間的消息分發(fā)分別由融合通信系統(tǒng)內(nèi)的即時(shí)消息AS和OTT系統(tǒng)內(nèi)的OTT服務(wù)器通過API交互實(shí)現(xiàn)。若用戶具備電信即時(shí)消息系統(tǒng)的同時(shí)還具備OTT即時(shí)消息系統(tǒng)，并且該OTT即時(shí)消息系統(tǒng)處于活躍狀態(tài)(沒有超過一周未登錄)，則該用戶具有OTT即時(shí)消息客戶端這一信息將通過Network API在電信融合通信系統(tǒng)內(nèi)登記。若OTT客戶端一段時(shí)間未活躍，則用戶具有OTT即時(shí)消息客戶端這一信息將通過Network API在電信 融合通信系統(tǒng)內(nèi)去除登記狀態(tài)。

當(dāng)用戶在電信即時(shí)消息系統(tǒng)內(nèi)的終端發(fā)送的消息到達(dá)主叫歸屬的電信融合通信系統(tǒng)應(yīng)用服務(wù)器時(shí)，該服務(wù)器判斷此主叫用戶是否具有OTT客戶端的登記，若有，則在電信即時(shí)消息系統(tǒng)內(nèi)進(jìn)行正常的后續(xù)消息流程的同時(shí)，將所有的即時(shí)消息、文件傳輸、群聊等即時(shí)消息業(yè)務(wù)均通過Network API設(shè)備轉(zhuǎn)發(fā)到OTT即時(shí)消息系統(tǒng)的應(yīng)用服務(wù)器，后續(xù)由OTT即時(shí)通信系統(tǒng)應(yīng)用服務(wù)器下發(fā)給此主叫用戶的OTT客戶端，實(shí)現(xiàn)即時(shí)消息在主叫用戶的電信即時(shí)消息客戶端和OTT即時(shí)消息客戶端之間的同步；

當(dāng)電信系統(tǒng)內(nèi)的即時(shí)消息到達(dá)被叫融合通信系統(tǒng)應(yīng)用服務(wù)器時(shí)，該服務(wù)器判斷此被叫用戶是否具有OTT客戶端的登記，若有，則在電信即時(shí)消息系統(tǒng)內(nèi)進(jìn)行正常的后續(xù)消息流程的同時(shí)，將所有的即時(shí)消息、文件傳輸、群聊等即時(shí)消息業(yè)務(wù)均通過Network API設(shè)備轉(zhuǎn)發(fā)到OTT即時(shí)消息系統(tǒng)的應(yīng)用服務(wù)器，后續(xù)由OTT即時(shí)通信系統(tǒng)應(yīng)用服務(wù)器下發(fā)給此被叫用戶的OTT客戶端，實(shí)現(xiàn)即時(shí)消息同時(shí)發(fā)往被叫用戶的電信即時(shí)消息客戶端和OTT即時(shí)消息客戶端。

此方法，不需要對電信網(wǎng)內(nèi)的IMS系統(tǒng)進(jìn)行改造。

該方案所涉及主要流程包括：

1互聯(lián)網(wǎng)與電信即時(shí)通信系統(tǒng)融合后多終端管理

1.1多終端同時(shí)注冊

由于融合通信客戶端和OTT客戶端分別屬于不同系統(tǒng)，因此他們可以分別直接使用自身在本系統(tǒng)內(nèi)原有的用戶標(biāo)識進(jìn)行登錄，而不需要對標(biāo)識進(jìn)行重新規(guī)劃和分配。

為使融合通信系統(tǒng)內(nèi)的IMS AS實(shí)現(xiàn)消息分發(fā)和后續(xù)路由，對于用戶其他OTT客戶端，每一個OTT客戶端均會分配一個“偽”IMPU，形如MSISDN@pc.ims.mnc000.mcc460.3gppnetwork.org，其中MSISDN為用戶手機(jī)號，該偽IMPU在IMS中無需寫入HSS、無需EnumDNS配置、僅在用戶同時(shí)具有OTT客戶端時(shí)，將用戶擁有OTT客戶端這一信息通過登記的方式告知即時(shí)消息AS，即時(shí)消息AS根據(jù)該標(biāo)識，無條件將收到的消息抄送一份到Network API，由 Network API進(jìn)行后續(xù)路由。OTT客戶端在融合通信系統(tǒng)的登記流程如下圖所示：

用戶具有手機(jī)UE_A，且UE_A已完成到融合通信系統(tǒng)的注冊流程，同時(shí)，用戶具有PC客戶端PC_A，當(dāng)PC_A第一次登陸時(shí)，需要向融合通信系統(tǒng)進(jìn)行注冊，參見圖11所示，其流程如下：

1～2)PC_A通過OTT接入點(diǎn)向OTT服務(wù)器進(jìn)行注冊；

3～5)OTT服務(wù)器判斷此用戶是否曾經(jīng)進(jìn)行過注冊，若有，則僅向PC_A回復(fù)注冊成功響應(yīng)；

6～7)否則，OTT服務(wù)器使用基于RESTFul架構(gòu)的Network API，經(jīng)過Network API GW，向融合通信系統(tǒng)內(nèi)部的Network API設(shè)備發(fā)起登記請求，此登記請求攜帶用戶的身份信息PC_A@pc.ims.mnc000.mcc460.3gppnetwork.org(其中PC_A為該用戶A的MSISDN)，該用戶PC客戶端具備哪些業(yè)務(wù)能力；

8)Network API設(shè)備將此登記請求轉(zhuǎn)為SIP Notify通知，告知融合通信即時(shí)消息AS用戶A擁有PC客戶端；

9)融合通信即時(shí)消息AS根據(jù)PC用戶身份標(biāo)識，將PC_A與已注冊的融合通信用戶UE_A進(jìn)行關(guān)聯(lián)，記錄此用戶同時(shí)具有Native/APP客戶端UE_A以及PC客戶端PC_A；

10)融合通信即時(shí)消息AS向融合通信Network API設(shè)備回復(fù)SIP 200OK確認(rèn)消息

11)融合通信Network API設(shè)備使用基于RESTFul架構(gòu)的Network API，經(jīng)過Network API GW向OTT服務(wù)器回復(fù)登記成功響應(yīng)。

對于OTT服務(wù)器，由于用戶使用MSISDN進(jìn)行注冊，因此注冊后OTT服務(wù)器可知該用戶具有的手機(jī)端所在的服務(wù)器地址(可在用戶OTT客戶端注冊時(shí)通過發(fā)起攜帶MSISDN的API查詢等方式獲得)，當(dāng)消息需要同時(shí)發(fā)往該用戶的手機(jī)時(shí)，OTT服務(wù)器可以將消息復(fù)制一份，直接通過API調(diào)用的方式將該復(fù)制的消息發(fā)往用戶手機(jī)端所在的服務(wù)器地址。

1.2多終端遠(yuǎn)程控制

融合架構(gòu)下，用戶手機(jī)UE具有對自身OTT客戶端進(jìn)行遠(yuǎn)程控制的能力，可以獲取當(dāng)前OTT客戶端的登錄狀態(tài)，并可以將OTT客戶端強(qiáng)制注銷，參見圖12所示。

場景1：獲取PC客戶端登陸狀態(tài)，參見圖13所示：

1)UE_A直接向OTT接入發(fā)起Http查詢請求；

2)OTT接入將查詢請求轉(zhuǎn)給用戶OTT服務(wù)器；

3)用戶OTT服務(wù)器向OTT接入返回用戶OTT客戶端當(dāng)前登陸狀態(tài)；

4)OTT接入將用戶OTT客戶端當(dāng)前登陸狀態(tài)返回給UE_A。

場景2：PC客戶端強(qiáng)制注銷，參見圖14所示：

1～2)UE_A向OTT接入發(fā)起強(qiáng)制注銷請求，OTT接入將強(qiáng)制注銷請求轉(zhuǎn)給用戶OTT服務(wù)器；

3～6)用戶OTT服務(wù)器更新OTT客戶端注冊狀態(tài)，并將注銷命令經(jīng)OTT接入發(fā)往OTT客戶端，OTT客戶端回復(fù)注銷成功響應(yīng)；

7～8)OTT服務(wù)器經(jīng)OTT接入向UE_A返回注銷成功響應(yīng)。

2互聯(lián)網(wǎng)與電信即時(shí)通信系統(tǒng)融合后多終端消息收發(fā)方案

2.1消息收發(fā)總體策略

互聯(lián)網(wǎng)與電信即時(shí)通信系統(tǒng)融合后，用戶手機(jī)與OTT客戶端之間的消息交互采用Network API方式進(jìn)行。

對于手機(jī)，其收到的消息是基于SIP的融合通信消息，可通過消息SIP頭中的From、To、Request-URI和P-Asserted-Identity四個頭域的不同組合，判斷多終端消息的業(yè)務(wù)類型。例如，用戶B有手機(jī)UE_B，其標(biāo)識為SIP URI＝“UE_B”，同時(shí)擁有OTT客戶端，其標(biāo)識為SIP URI＝“PC_B”,A的SIP URI＝“URI_A”各業(yè)務(wù)類型的消息頭組合如下表，表2手機(jī)側(cè)收到的各類消息業(yè)務(wù)SIP頭域組合：

表2

即時(shí)消息AS在此場景下的路由規(guī)則如下：

收到來自IMS的SIP消息，則進(jìn)行正常IMS后續(xù)路由流程，并判斷是否需要使用Network API對OTT側(cè)進(jìn)行消息抄送

收到來自Network API的消息，則只進(jìn)行正常IMS后續(xù)路由流程，不對OTT側(cè)進(jìn)行消息抄送。

2.2多終端消息抄送

用戶可使用手機(jī)或OTT客戶端發(fā)送消息。當(dāng)用戶擁有多個終端時(shí)，用戶若使用某一客戶端發(fā)送消息，另一個客戶端可見同樣發(fā)送出去的消息，當(dāng)接收方用戶擁有多個終端時(shí)，用戶在一個設(shè)備上收到消息時(shí)，在另一個設(shè)備上也會收到同樣的業(yè)務(wù)。下面以Pager Mode消息為例，說明多終端場景下的消息流程。Large Message Mode及文件傳輸路由方式與Pager Mode消息相同，流程省略遞送報(bào)告過程。

場景1：用戶A使用手機(jī)向用戶B發(fā)送消息，參見圖15所示：

用戶A使用手機(jī)向用戶B發(fā)送消息的流程如下

1～4)發(fā)送方UE_A經(jīng)過主叫IMS發(fā)送即時(shí)消息到主叫所屬的即時(shí)消息AS，主叫即時(shí)消息AS返回已收到即時(shí)消息的應(yīng)答；

5～10)主叫即時(shí)消息AS經(jīng)過主叫IMS和被叫IMS，向接收方用戶UE_B 所歸屬的即時(shí)消息AS發(fā)送即時(shí)消息，被叫即時(shí)消息AS返回已收到即時(shí)消息的應(yīng)答；

11)UE_A歸屬即時(shí)消息AS檢查用戶A是否有OTT客戶端PC_A登記過，若有，則將Message消息復(fù)制一份發(fā)往融合通信Network API設(shè)備；

12～15)Network API設(shè)備使用基于RESTFul架構(gòu)的Network API，經(jīng)過Network API GW，向OTT服務(wù)器發(fā)送消息，OTT服務(wù)器返回已收到即時(shí)消息的應(yīng)答；

16)Network API設(shè)備向UE_A歸屬即時(shí)消息AS返回已收到即時(shí)消息的應(yīng)答；

17～20)OTT服務(wù)器通過OTT私有協(xié)議向PC_A發(fā)送此消息，PC_A收到此抄送消息并向OTT服務(wù)器返回已收到即時(shí)消息的應(yīng)答；

21～24)被叫即時(shí)消息AS向接收方UE_B遞送即時(shí)消息，接收方UE_B返回成功收到即時(shí)消息的應(yīng)答；

25)UE_B歸屬即時(shí)消息AS檢查用戶A是否有PC客戶端PC_B登記過，若有，則將Message消息復(fù)制一份發(fā)往融合通信Network API設(shè)備；

26～29)Network API設(shè)備使用基于RESTFul架構(gòu)的Network API，經(jīng)過Network API GW，向OTT服務(wù)器發(fā)送消息，OTT服務(wù)器返回已收到即時(shí)消息的應(yīng)答；

30)Network API設(shè)備向UE_B歸屬即時(shí)消息AS返回已收到即時(shí)消息的應(yīng)答；

31～35)OTT服務(wù)器通過OTT私有協(xié)議向PC_B發(fā)送此消息，PC_B收到此消息并向OTT服務(wù)器返回已收到即時(shí)消息的應(yīng)答；

場景2：用戶A使用OTT客戶端向用戶B發(fā)送消息

用戶A使用OTT客戶端向用戶B發(fā)送消息的流程，參見圖16所示，

1～4)發(fā)送方PC_A通過OTT私有協(xié)議向OTT服務(wù)器發(fā)送此消息，OTT服務(wù)器收到此消息并向PC_A返回已收到即時(shí)消息的應(yīng)答；

5～6)OTT服務(wù)器使用基于RESTFul架構(gòu)的Network API，經(jīng)過Network API GW，向UE_A歸屬的Network API設(shè)備發(fā)送消息，此消息中包含有不轉(zhuǎn)短信的標(biāo)識；

7～8)UE_A歸屬的Network API設(shè)備將消息轉(zhuǎn)為SIP Messge，發(fā)往用戶UE_A歸屬的即時(shí)消息AS，UE_A歸屬的即時(shí)消息AS返回已收到即時(shí)消息的應(yīng)答；

9～10)UE_A歸屬的Network API設(shè)備向OTT服務(wù)器返回已收到即時(shí)消息的應(yīng)答；

11～14)UE_A歸屬的即時(shí)消息AS向抄送方UE_A遞送即時(shí)消息，抄送方UE_A返回成功收到即時(shí)消息的應(yīng)答；

15～16)OTT服務(wù)器使用基于RESTFul架構(gòu)的Network API，經(jīng)過Network API GW，向UE_B歸屬的Network API設(shè)備發(fā)送消息，此消息中包含有是否轉(zhuǎn)短信的標(biāo)識；

17～18)UE_B歸屬的Network API設(shè)備將消息轉(zhuǎn)為SIP Messge，發(fā)往用戶UE_B歸屬的即時(shí)消息AS，UE_B歸屬的即時(shí)消息AS返回已收到即時(shí)消息的應(yīng)答；

19～20)UE_B歸屬的Network API設(shè)備向OTT服務(wù)器返回已收到即時(shí)消息的應(yīng)答；

21～24)被叫UE_B歸屬的即時(shí)消息AS判斷此消息是否需要轉(zhuǎn)短信，此后向接收方UE_B遞送即時(shí)消息，接收方UE B返回成功收到即時(shí)消息的應(yīng)答，若UE_B不在線且消息需要轉(zhuǎn)短信，則進(jìn)行轉(zhuǎn)短信處理；

25～28)OTT服務(wù)器通過OTT私有協(xié)議向PC_B發(fā)送此消息，PC_B收到此消息并向OTT服務(wù)器返回已收到即時(shí)消息的應(yīng)答；

2.3消息靜默提醒

為避免消息在OTT客戶端和手機(jī)上雙收雙提示，需要增加靜默功能。

多終端消息接收和抄送過程中，即時(shí)消息AS負(fù)責(zé)靜默邏輯，即時(shí)消息AS將最近一條消息來自的客戶端判定其為活躍客戶端，另外一種客戶端為靜默客戶端，此后，即時(shí)消息AS向需要靜默的客戶端發(fā)送的消息中加入需要靜默標(biāo) 志字段，客戶端收到含有靜默標(biāo)志字段的消息后，不做提示處理。

當(dāng)超過一定時(shí)間長度(如5分鐘)時(shí)，若即時(shí)消息AS沒有再收到消息，則即時(shí)消息AS認(rèn)為所有在線客戶端均應(yīng)視為活躍客戶端，均需要提醒消息。此時(shí)，即時(shí)消息AS向所有客戶端發(fā)送的消息內(nèi)都將不包含靜默標(biāo)志字段。

2.4定向消息

定向消息指同一用戶的手機(jī)與OTT客戶端之間可以互相發(fā)送消息。定向消息可分為用戶手機(jī)向自身OTT客戶端發(fā)送消息，以及OTT客戶端向自身手機(jī)發(fā)送消息兩種場景。

場景1：用戶手機(jī)向自身OTT客戶端發(fā)送消息，參見圖17所示，

1～4)發(fā)送方UE_A經(jīng)過主叫IMS發(fā)送到主叫所屬的即時(shí)消息AS，主叫即時(shí)消息AS返回已收到即時(shí)消息的應(yīng)答；

5)UA_A歸屬即時(shí)消息AS檢查用戶A是否有PC客戶端PC_A登記過，若有，則將Message消息復(fù)制一份發(fā)往融合通信Network API設(shè)備；

6～9)Network API設(shè)備使用基于RESTFul架構(gòu)的Network API，經(jīng)過Network API GW，向OTT服務(wù)器發(fā)送消息，OTT服務(wù)器返回已收到即時(shí)消息的應(yīng)答；

10)Network API設(shè)備向UE_A歸屬即時(shí)消息AS返回已收到即時(shí)消息的應(yīng)答；

11～14)OTT服務(wù)器通過OTT私有協(xié)議向PC_A發(fā)送此消息，PC_A收到此消息并向OTT服務(wù)器返回已收到即時(shí)消息的應(yīng)答；

場景2：用戶OTT客戶端向自身手機(jī)發(fā)送消息，參見圖18所示，

1～4)發(fā)送方PC_A通過OTT私有協(xié)議向OTT服務(wù)器發(fā)送消息，OTT服務(wù)器收到此消息并向PC_A返回已收到即時(shí)消息的應(yīng)答；

5～6)OTT服務(wù)器使用基于RESTFul架構(gòu)的Network API，經(jīng)過Network API GW，向UE_A歸屬的Network API設(shè)備發(fā)送消息，此消息中包含有不轉(zhuǎn)短信的標(biāo)識；

7～8)UE_A歸屬的Network API設(shè)備將消息轉(zhuǎn)為SIP Messge，發(fā)往用戶UE_A歸屬的即時(shí)消息AS，UE_A歸屬的即時(shí)消息AS返回已收到即時(shí)消息的 應(yīng)答；

9～10)UE_A歸屬的Network API設(shè)備向OTT服務(wù)器返回已收到即時(shí)消息的應(yīng)答；

11～14)UE_A歸屬的即時(shí)消息AS向UE_A遞送即時(shí)消息，UE_A返回成功收到即時(shí)消息的應(yīng)答；

2.5群聊

場景1：用戶A使用手機(jī)建立群聊，參見圖19所示，

1～9)發(fā)送方UE_A經(jīng)過主叫IMS發(fā)起群聊創(chuàng)建請求到UE_A歸屬群聊服務(wù)器，UE_A歸屬群聊服務(wù)器進(jìn)行應(yīng)答，UE_A與UE_A歸屬群聊服務(wù)器之間建立MSRP通道；

10～16)UE_A歸屬群聊服務(wù)器檢查用戶A是否有OTT客戶端PC_A曾經(jīng)登記過，若有，則通過Network API將群聊創(chuàng)建請求發(fā)往融合通信Network API設(shè)備，Network API設(shè)備通過基于RESTFul架構(gòu)的消息將邀請發(fā)往OTT服務(wù)器，OTT服務(wù)器進(jìn)行應(yīng)答后，UE_A歸屬群聊服務(wù)器與UE_A歸屬Network API設(shè)備間建立MSRP通道；

17～20)OTT服務(wù)器將群聊創(chuàng)建請求通過OTT消息抄送給UE_A自身OTT客戶端PC_A；

21～27)UE_A歸屬群聊服務(wù)器向UE_B歸屬群聊服務(wù)器(即時(shí)消息AS)發(fā)送群聊創(chuàng)建請求，UE_B歸屬群聊服務(wù)器(即時(shí)消息AS)進(jìn)行應(yīng)答，與UE_A歸屬群聊服務(wù)器之間建立MSRP通道；

28～29)UE_B歸屬群聊服務(wù)器(即時(shí)消息AS)向UE_B發(fā)送群聊創(chuàng)建請求；

30～34)UE_B歸屬群聊服務(wù)器(即時(shí)消息AS)檢查用戶B的OTT客戶端PC_B是否登記過，若有，則將群聊創(chuàng)建請求發(fā)往融合通信Network API設(shè)備，Network API設(shè)備通過基于RESTFul架構(gòu)的消息將邀請發(fā)往OTT服務(wù)器，OTT服務(wù)器將此邀請發(fā)往PC_B；

35～38)若UE_B先接受群聊創(chuàng)建請求，則UE_B歸屬群聊服務(wù)器(即時(shí)消 息AS)與UE_B之間建立MSRP通道；

39～48)UE_B歸屬群聊服務(wù)器(即時(shí)消息AS)更新PC_B狀態(tài)，將其加入群聊，并通過Network API通知PC_B，此后群聊消息均抄送給PC_B；

49～53)若OTT客戶端先接受群聊創(chuàng)建請求，則OTT服務(wù)器通過Network API通知UE_B歸屬即時(shí)消息AS；

54～57)UE_B歸屬群聊服務(wù)器(即時(shí)消息AS)更新UE_B狀態(tài)，將其加入群聊，更新群列表服務(wù)器，并將UE_B已加入群聊這一群聊變化信息通過Notify發(fā)送給UE_B，UE_B本地獲得此群聊列表。

58～65)UE_B所在群聊服務(wù)器(即時(shí)消息AS)發(fā)送Cancel消息，結(jié)束此前發(fā)往UE_B的群聊創(chuàng)建請求；

66～71)UE_B歸屬群聊服務(wù)器(即時(shí)消息AS)使用激活群聊的消息邀請UE_B加入群聊，UE_B接受邀請，與UE_B歸屬新消息模塊建立MSRP通道。

場景2：用戶A使用OTT客戶端建立群聊，參見圖20所示，

1～4)用戶A的OTT客戶端PC_A發(fā)起群聊，OTT服務(wù)器接受群聊請求；

5-12)OTT服務(wù)器檢查用戶A是否有手機(jī)客戶端UE_A，若有，通過Network API將群聊建立請求抄送給手機(jī)側(cè)，Network API將群聊創(chuàng)建請求發(fā)送給UE_A歸屬的群聊服務(wù)器，與UE_A歸屬的群聊服務(wù)器之間建立MSRP通道；

13～18)UE_A歸屬的群聊服務(wù)器更新用戶更新UE_A狀態(tài)，將UE_A加入群聊，更新群列表服務(wù)器，并將UE_A已加入群聊這一群聊變化信息通過Notify發(fā)送給UE_A，UE_A本地獲得此群聊列表；

19～27)UE_A歸屬群聊服務(wù)器使用激活群聊的消息邀請UE_A加入群聊，UE_A接受邀請，與UE_A歸屬群聊服務(wù)器建立MSRP通道；

28～32)PC群聊服務(wù)器向UE_B歸屬群聊服務(wù)器(即時(shí)消息AS)發(fā)送群聊創(chuàng)建請求，UE_B歸屬群聊服務(wù)器(即時(shí)消息AS)進(jìn)行應(yīng)答，與UE_A歸屬群聊服務(wù)器之間建立MSRP通道；

33～34)UE_B歸屬群聊服務(wù)器(即時(shí)消息AS)向UE_B發(fā)送群聊創(chuàng)建請求；

35～36)OTT服務(wù)器向PC_B發(fā)送群聊創(chuàng)建請求；

37～40)若UE_B先接受群聊創(chuàng)建請求，則UE_B歸屬群聊服務(wù)器(即時(shí)消息AS)與UE_B之間建立MSRP通道；

41～50)UE_B歸屬群聊服務(wù)器(即時(shí)消息AS)更新PC_B狀態(tài)，將其加入群聊，并通過Network API通知PC_B，此后群聊消息均抄送給PC_B；

51～55)若PC客戶端先接受群聊創(chuàng)建請求，則OTT服務(wù)器通過Network API通知UE_B歸屬新消息模塊；

56～59)UE_B歸屬群聊服務(wù)器(即時(shí)消息AS)更新UE_B狀態(tài)，將其加入群聊，更新群列表服務(wù)器，并將UE_B已加入群聊這一群聊變化信息通過Notify發(fā)送給UE_B，UE_B本地獲得此群聊列表。

60～67)UE_B所在群聊服務(wù)器(即時(shí)消息AS)發(fā)送Cancel消息，結(jié)束此前發(fā)往UE_B的群聊創(chuàng)建請求；

68～73)UE_B歸屬群聊服務(wù)器(即時(shí)消息AS)使用激活群聊的消息邀請UE_B加入群聊，UE_B接受邀請，與UE_B歸屬群聊服務(wù)器(即時(shí)消息AS)建立MSRP通道。

本發(fā)明相比其他技術(shù)具有以下優(yōu)點(diǎn)：

實(shí)現(xiàn)了在電信網(wǎng)與互聯(lián)網(wǎng)兩種不同機(jī)制的網(wǎng)絡(luò)中的實(shí)現(xiàn)異構(gòu)多終端同時(shí)在線和消息同步的即時(shí)消息，同一個用戶可以分別擁有基于電信標(biāo)準(zhǔn)的即時(shí)消息客戶端和基于互聯(lián)網(wǎng)OTT私有協(xié)議方式實(shí)現(xiàn)的的即時(shí)消息客戶端，并且兩類客戶端就有相同的用戶身份；

不需要對電信核心網(wǎng)設(shè)備就行修改，不改變IMS路由流程，所有到PC側(cè)的消息抄送邏輯由應(yīng)用服務(wù)器進(jìn)行，同時(shí)不需要改變OTT側(cè)的協(xié)議和實(shí)現(xiàn)模式，由OTT服務(wù)器作為API調(diào)用方控制消息流程。

本領(lǐng)域內(nèi)的技術(shù)人員應(yīng)明白，本發(fā)明的實(shí)施例可提供為方法、系統(tǒng)、或計(jì)算機(jī)程序產(chǎn)品。因此，本發(fā)明可采用硬件實(shí)施例、軟件實(shí)施例、或結(jié)合軟件和硬件方面的實(shí)施例的形式。而且，本發(fā)明可采用在一個或多個其中包含有計(jì)算機(jī)可用程序代碼的計(jì)算機(jī)可用存儲介質(zhì)(包括但不限于磁盤存儲器和光學(xué)存儲 器等)上實(shí)施的計(jì)算機(jī)程序產(chǎn)品的形式。

本發(fā)明是參照根據(jù)本發(fā)明實(shí)施例的方法、設(shè)備(系統(tǒng))、和計(jì)算機(jī)程序產(chǎn)品的流程圖和/或方框圖來描述的。應(yīng)理解可由計(jì)算機(jī)程序指令實(shí)現(xiàn)流程圖和/或方框圖中的每一流程和/或方框、以及流程圖和/或方框圖中的流程和/或方框的結(jié)合?？商峁┻@些計(jì)算機(jī)程序指令到通用計(jì)算機(jī)、專用計(jì)算機(jī)、嵌入式處理機(jī)或其他可編程數(shù)據(jù)處理設(shè)備的處理器以產(chǎn)生一個機(jī)器，使得通過計(jì)算機(jī)或其他可編程數(shù)據(jù)處理設(shè)備的處理器執(zhí)行的指令產(chǎn)生用于實(shí)現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的裝置。

這些計(jì)算機(jī)程序指令也可存儲在能引導(dǎo)計(jì)算機(jī)或其他可編程數(shù)據(jù)處理設(shè)備以特定方式工作的計(jì)算機(jī)可讀存儲器中，使得存儲在該計(jì)算機(jī)可讀存儲器中的指令產(chǎn)生包括指令裝置的制造品，該指令裝置實(shí)現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能。

這些計(jì)算機(jī)程序指令也可裝載到計(jì)算機(jī)或其他可編程數(shù)據(jù)處理設(shè)備上，使得在計(jì)算機(jī)或其他可編程設(shè)備上執(zhí)行一系列操作步驟以產(chǎn)生計(jì)算機(jī)實(shí)現(xiàn)的處理，從而在計(jì)算機(jī)或其他可編程設(shè)備上執(zhí)行的指令提供用于實(shí)現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的步驟。

以上所述，僅為本發(fā)明的較佳實(shí)施例而已，并非用于限定本發(fā)明的保護(hù)范圍。