CN101212719B - 一种无线通信网络中实现融合消息业务的方法及系统 - Google Patents
一种无线通信网络中实现融合消息业务的方法及系统 Download PDFInfo
- Publication number
- CN101212719B CN101212719B CN2007100008145A CN200710000814A CN101212719B CN 101212719 B CN101212719 B CN 101212719B CN 2007100008145 A CN2007100008145 A CN 2007100008145A CN 200710000814 A CN200710000814 A CN 200710000814A CN 101212719 B CN101212719 B CN 101212719B
- Authority
- CN
- China
- Prior art keywords
- message
- user
- converged
- cpm
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Telephonic Communication Services (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本发明涉及一种无线通信网络中实现融合消息业务的方法及系统,其主要包括:首先,网络侧接收需要发送的消息,所述的消息为融合消息或非融合消息,所述的融合消息为网络侧与支持融合消息的用户设备之间交互的格式统一的消息类型;之后,根据消息中承载的信息确定对应的用户信息,所述的用户信息包括融合消息与非融合消息之间的转换处理策略;最后,对所述需要发送的消息,根据确定的用户信息进行转换处理,并发送经转换处理后的消息。因此,本发明不仅可以解决无线通信网络中各种服务系统的仓筒式结构带来的弊端,也可以简化用户设备的实现复杂程度。
Description
技术领域
本发明涉及通信技术领域,尤其涉及一种无线通信网络中实现融合消息业务的技术方案。
背景技术
随着移动网络通信技术的快速发展,在通信网络中涌现出了各种各样的消息服务,以满足各用户的不同通信需求。所述的消息服务包括:SMS(Short Message Service,短消息业务)服务、MMS(Multimedia Message Service,多媒体消息业务)服务、IM(即时消息)服务及基于半双工的PoC(Push-to-Talk over Cellular,一键通)消息服务等。
在通信网络中,针对每一种消息服务均需要基于相应的技术规范设置独立的业务引擎,通过相应的独立的业务引擎可以为用户提供对应的消息服务,从而为用户带来不同的用户体验。
目前,在通信网络中,提供各种消息服务的体系架构如图1所示,该体系架构中包括:WAP(无线应用部分)网关,用于提供PUSH(消息推送)服务引擎的功能及多媒体消息处理功能;移动交换中心,用于提供短消息处理功能及Voice Mail(语音信箱)业务功能;以及Email(电子邮件)和IM功能。在图1所示的体系架构中提供了多种消息服务功能,其中:
所述的短消息服务、多媒体消息服务、Email和IM等业务功能均提供了传送文本消息的能力,且所述Email和IM还可以传送各种媒体内容;
所述的多媒体消息可以提供图片等简单的媒体内容的传送,因此,其与Email和IM提供的消息服务功能存在部分重叠,同时,消息服务的发展趋势也是要使用户能够获得更加丰富的消息服务。
在图1所示的体系架构中,所述的IM消息提供了即时的消息服务和延迟的消息服务;而短消息、多媒体消息、Email则仅提供了延迟的消息服务,对于提供延迟的消息服务的情况,则需要在网络侧提供相应的存储能力,以用于存储被延迟传送的消息。
因此,现有的消息服务系统在提供消息服务过程中存在以下缺陷:
(1)用户需要使用特定消息系统的特定客户端来发送相应的消息
为了使用各种消息服务,用户需要在终端安装各种消息服务的客户端,使得用户在发送消息前必须从众多的消息服务中进行选择;而且在选择过程中,用户需要理解某种消息格式提供哪些功能以及有哪些限制。
也就是说,用户在发送各种消息前必须选择消息类型和消息内容,例如当用户希望发送包含多媒体消息内容的消息时就不能选择SMS方式发送,而希望建立语音会话时PoC则是更加适合的消息会话方式。
(2)采用独立的垂直业务模型
即采用仓筒式结构实现业务模型,这种业务模型导致用户信息分散,使得用户数据之间不一致的可能增大,用户使用业务的方式受限;另外,各业务子系统的相对独立性导致与底层网络的重复集成,业务数据冗余,功能重复建设等问题。
(3)存在部分功能上的重叠
例如,需要支持多媒体消息,需要呈现业务的支持,需要提供统一的地址簿,需要某些共享的通用功能和能力等。
发明内容
本发明的实施例提供了一种无线通信网络中实现融合消息业务的方法,包括:
接收需要发送的消息,所述的消息为融合消息或非融合消息;
根据消息中承载的信息确定对应的用户信息,所述的用户信息包括融合消息与非融合消息之间的转换处理策略;
对所述消息,根据确定的用户信息进行转换处理,并发送经转换处理后的消息。
本发明的实施例提供了一种无线通信网络中实现融合消息业务的系统,包括消息服务装置、用户信息存储装置和消息转换装置,其中,
消息服务装置,用于接收需要发送的消息,所述的消息包括融合消息或非融合消息;还用于控制发送所述消息或转换处理后的消息;
用户信息存储装置,用于保存预先设置的用户信息,所述用户信息包括融合消息与非融合消息之间的转换处理策略;
消息转换装置,根据所述的转换处理策略对所述需要发送的消息进行转换处理。
本发明的实施例提供了一种用户设备,包括:
融合消息接收处理单元,用于接收无线通信网络发送来的融合消息,以获取融合消息中承载的信息;
融合消息发送处理单元,用于将需要向无线通信网络发送的信息承载于融合消息中,并向无线通信网络发送。
由上述本发明的实施例提供的技术方案可以看出,本发明提供的一种实现融合消息通信的方法及系统的实施例,使得用户可以与使用其它各种消息服务的用户通信,且用户无须从现有各种消息服务中做出选择。
因此,本发明提供的实施例不仅可以解决无线通信网络中各种服务系统的仓筒式结构带来的弊端,也可以简化用户设备的实现复杂程度。
附图说明
图1为现有技术中的服务体系架构示意图;
图2为本发明所述系统的实施例的结构示意图一;
图3为本发明所述系统的实施例的结构示意图二;
图4为消息转换装置的实施例结构示意图;
图5为用户设备的实施例结构示意图;
图6为本发明实施例的应用场景一的示意图;
图7为本发明实施例的应用场景二的示意图;
图8为本发明实施例的应用场景三的示意图;
图9为本发明所述方法的实施例的处理过程示意图;
图10为本发明所述方法中的转换过程的实施例流程示意图;
图11为实施例1中的CPM消息处理过程示意图一;
图12为实施例1中的CPM消息处理过程示意图二;
图13为实施例2提供的处理过程示意图一;
图14为实施例2提供的处理过程示意图二;
图15为实施例3提供的处理过程示意图一;
图16为实施例3提供的处理过程示意图二;
图17为本发明提供的实施例中CPM系统向HLR/HSS注册的处理过程示意图。
具体实施方式
本发明提供了一种无线通信网络中实现融合消息业务的方法的实施例,该实施例可以用于为用户设备提供消息业务服务,为此,首先需要在无线通信网络中预先设置并保存用户信息,包括但不限于服务设置和/或用户个性化设置等,所述的用户信息用于表示消息的处理策略,其中,具体可以包括融合消息与非融合消息之间的转换处理策略,如是否需要进行消息类型转换、转换后的消息类型等等,所述的处理策略可以为:根据所述用户的服务设置和用户的个性化设置中的至少一项,以及接收方用户的呈现信息、接收方用户的终端能力信息和消息中的消息体内容类型中的至少一项进行转换处理的信息;所述的融合消息为无线通信网络中的用户设备支持的一种格式统一的消息类型;
相应的,该实施例中,实现融合消息业务的过程具体包括:
(1)在上行方向,
支持融合消息的无线通信网络收到该无线通信网络中的用户设备发来的融合消息,则将所述的融合消息转换为接收方希望的消息类型,即某一种类型的非融合消息,并发送;
对于将转换后的非融合消息可以经由网关通过外部网络进行发送,所述的外部网络是指独立于支持融合消息的无线通信网络的其他网络,如互联网或普通电话网或不同类型的其他无线通信网络等等;
(2)在下行方向,
支持融合消息的无线通信网络中确定需要发送给该无线通信网络中的用户设备的消息后,则将所述需要发送给该用户设备的非融合消息转换为所述融合消息,并发送给该用户设备;
由于在网络侧均可以将不同种类的消息统一转换为一种格式统一的消息类型,即融合消息,从而使得用户设备仅需要支持一种消息类型,进而令其实现大大简化,有效克服了现有技术中存在的问题。
在上述处理过程中,在执行所述的转换处理过程之前,还可以根据所述的用户信息判断确定是否需要进行所述转换处理,若确定需要,则进一步根据所述用户信息对所述消息进行转换处理,否则,直接发送所述消息,其中,对于非融合消息可以经由网关通过外部网络发送,对于融合消息则可以直接在支持融合消息的无线通信网络中发送;
所述的转换处理过程可以为:根据需要发送的融合消息的接收方信息确定接收方对应的用户信息,根据所述的用户信息确定转换后的消息类型,并将所述消息转换为该消息类型对应的消息,实现融合消息与非融合消息之间的转换;另外,由于非融合消息可以为多种类型的消息,如SMS、多媒体消息或电子邮件等,故该转换处理还可选地包括不同类型的非融合消息之间的转换处理。
在该实施例中,所述的用户信息还可以包括是否需要对相应消息进行保存操作的信息,这样,在支持融合消息的无线通信网络中还可以根据所述的用户信息判断需要发送的消息是否需要保存,并在确定需要后,在支持融合消息的无线通信网络中保存该消息。
本发明还提供了一种无线通信网络中实现融合消息业务的系统的实施例,如图2和图3所示,该系统主要包括消息服务装置、用户信息存储装置和消息转换装置,其中,
(1)消息服务装置
该装置用于接收用户侧或网络侧发来的需要继续发送的消息,所述的消息包括融合消息和非融合消息,其中,通过与用户设备之间进行融合消息的交互;该装置还用于控制发送所述消息或转换处理后的消息,即直接发送不需要进行转换处理的消息,或者,控制消息转换装置发送转换后的消息;
所述的消息服务装置中还包括以下的处理:
根据接收到的消息中承载的信息,以及所述承载的信息对应的用户信息确定是否需要对该消息进行转换处理,若确定需要则将根据所述用户信息进一步确定转换后的消息类型及该消息提供给消息转换装置。
所述的消息服务装置中还可以包括以下处理:
根据收到的消息中承载的信息,以及所述承载的信息对应的所述的用户信息判决是否需要保存收到的消息,并在确定需要保存时,将所述消息传送给系统中的存储装置。
所述的消息服务装置还与其他服务引擎通信,从而可以获取在所述其他服务引擎中保存的信息,并将获取的信息作为所述用户信息。
其中,所述的消息服务装置具体可以基于会话初始协议SIP与用户设备之间进行融合消息的交互。
(2)用户信息存储装置
用于保存预先设置的用户信息,所述的用户信息包括融合消息与非融合消息之间的转换处理策略,并可选地包括不同类型的非融合消息之间的转换处理策略;
(3)消息转换装置
用于将消息服务装置收到的需要发送的消息根据所述用户信息存储装置中保存的用户信息转换为预定的消息类型,例如,转换为融合消息,或非融合消息(如SMS消息、多媒体消息或电子邮件等);
(4)网关
所述的消息转换装置和消息服务装置还分别与网关通信,以便于将消息转换装置将转换后的非融合消息,以及消息服务装置确定的需要直接发送的非融合消息,通过所述的网关发送给独立于所述支持融合消息的无线通信网络的外部网络,如互联网等。
基于该系统,便可以获得一种实现融合消息业务的无线通信网络,在该网络中,包括至少一个设置于无线通信网络中的实现融合消息业务的系统,以及与其通信的外部网络,所述的外部网络具体为独立于所述系统所在无线通信网络的网络;其中,所述的系统与无线通信网络的用户设备之间进行融合消息的交互,并用于根据用户信息实现融合消息与非融合消息之间的转换处理。在该网络中,为便于外部网络可以与实现融合消息业务的系统所在的无线通信网络之间的消息交互,则在所述的外部网络中需要保存实现融合消息业务的系统的信息,这样,外部网络便可以根据保存的实现融合消息业务的系统的信息将待发送信息发送给所述实现融合消息业务的系统。
具体一点讲,在所述的外部网络中,具体可以通过以下各种任意一种或多种方式获取并保存所述的实现融合消息业务的系统的信息,包括:
基于注册的方式获取实现融合消息业务的系统的信息,并保存于外部网络中的用于保存路由信息的实体中;
在外部网络中保存路由信息的实体中直接配置保存所述实现融合消息业务的系统的信息;
在外部网络中保存路由信息的实体中保存所述实现融合消息业务的系统的信息与IP地址间的对应关系。
本发明还提供了一种用户设备的实施例,仍参照图2所示,其结构包括:
融合消息接收处理单元,用于接收支持融合消息的无线通信网络发送来的融合消息,以获取融合消息中承载的信息,从而获得相应的消息业务服务;
融合消息发送处理单元,用于将需要向支持融合消息的无线通信网络发送的信息承载于融合消息中,并向支持融合消息的无线通信网络发送;所述的融合消息发送处理模块为基于SIP实现,且具体可以包括以下处理功能:
确定待发送的融合消息的大小,若其大小小于预定的值,则将所述的待发送的融合消息承载于SIP消息中,并发送;否则,建立基于SIP的会话连接,并通过该会话连接进行所述的融合消息的发送。
下面将结合附图对本发明的各实施例做进一步的解释说明。
本发明提供的一种实现融合消息通信的系统,以下简称为CPM(Converged IPMessaging,融合消息)系统,该系统及基于该系统构建的网络的实施例如图2所示,具体包括为CPM用户提供融合的IP消息服务的多个网络元素,通过该系统CPM服务提供商可以为CPM用户提供融合消息服务。
参照图3所示,所述系统的实施例具体包括消息服务装置、用户信息存储装置、消息转换装置、存储装置,以及网关和其他服务引擎;所述的系统用于为用户设备提供融合的IP消息服务;所述的系统通过网关与互联网及其他网络连接构成实现融合消息业务的网络,其中互联网及其他网络即为外部网络,所述其他网络可以不支持融合消息业务的其他无线通信网络或有线网络。下面将分别对CPM系统的各个组成元素的具体实现进行详细说明。
(一)消息服务装置
用于管理CPM消息和CPM会话,完成参与功能服务器和控制功能服务器的功能,根据CPM用户的服务设置和/或个性化设置产生与其他服务引擎交互的请求信息,判断接收的消息或会话是否是CPM消息或CPM会话,当需要与其他非CPM消息引擎交互时完成消息或会话的转换或调用消息转换装置完成消息或会话的转换;
所述的消息服务装置进一步可以包括:消息服务模块和消息会话模块,分别管理CPM消息服务和CPM会话服务;具体可以支持通过SIP-MESSAGE(SIP消息)协议承载的CPM消息和通过SIP协议建立的CPM会话,并支持CPM系统和CPM客户端之间的媒体能力协商和媒体的分发,此外还可以支持对PoC(一键通)消息服务和IM消息服务的管理;
所述的消息服务装置具体可以通过MSRP(消息会话中继协议)或RTP(实时传输协议)、RTCP(实时传输控制协议)访问存储装置中存储的媒体。
(二)消息转换装置
该消息转换装置可以内置于消息服务装置中,也可以独立于消息服务装置设置,即作为单独的服务器设置,故在该实施例中并不对其实现的位置作严格的限制。
该消息转换装置的具体功能作用包括以下各项中的至少一项:
(1)将CPM消息转换成根据用户的服务设置或用户个性化设置和/或消息接收方的呈现信息和/或消息体的媒体类型确定的消息形式;
(2)根据CPM消息中的控制信息将CPM消息转换成控制信息指示的消息形式;
(3)将收到的非CPM消息转换成根据用户的服务设置或用户个性化设置和/或消息接收方的呈现信息和/或消息体的媒体类型确定的消息形式。
为实现CPM消息与非CPM消息服务的消息之间的转换,该消息转换装置如图4所示,具体可以包括但不限于:CPM消息与SMS消息之间的转换模块、CPM消息与MM消息之间的转换模块及CPM消息与E mail之间的消息转换模块中的至少一个,其中;
所述的CPM消息与SMS的转换模块实现CPM消息与SMS消息的转换功能,实现CPM消息承载协议与SMS消息承载协议之间的转换,例如,当CPM消息采用SIP-MESSAGE消息承载时,实现SIP-MESSAGE协议与SMPP(短消息点对点协议)或CMPP(通讯短消息协议)的转换,或与MAP(移动应用部分)协议的转换;
所述的CPM消息与多媒体消息的转换模块实现CPM消息与多媒体消息的转换功能,实现CPM消息承载协议与多媒体消息承载协议之间的转换,例如,实现CPM消息与SMTP(简单邮件传输协议)之间的转换;
所述的CPM消息与Email的转换模块实现CPM消息与Email的转换功能,用于实现CPM消息承载协议与Email承载协议之间的转换。
(三)用户信息存储装置
该装置用于保存用户的个性化设置信息;或者,该装置也可以用于保存CPM系统用户的联系人列表,服务设置等用户信息,该用户信息通常是由用户设置,因此其也可以看作是用户的个性化设置信息,当然,该用户信息也可以由网络侧设置,或者,由第三方用户(如作为管理者的用户)进行设置;
所述的服务设置及所述的用户个性化设置均为用来表示与CPM客户端能力或CPM用户向CPM客户端和CPM系统表达服务意愿的一组参数,其中,所述的服务设备内容可以是用户个性化设置的一个子集;所述设置具体可以包括但不限于如下信息中的至少一项:
(1)在进行消息转换之前是否需要检查消息接收方的呈现信息的设置;
(2)CPM消息服务是否可用,以及CPM消息服务优先级的设置;
(3)当消息接收方的CPM消息服务优先级不是最高,或消息接收方的CPM消息服务不可用时,消息接收方可以选择最希望接收的消息形式并分配相应的优先级的设置;
(4)当消息接收方的CPM消息服务不可用时是否愿意将CPM消息暂时存储在存储装置的设置。
(四)存储装置
该装置用于保存用于根据用户的服务设置或用户的个性化设置需要保存CPM消息;该装置还支持用户的管理,例如支持CPM用户浏览消息列表和与消息相关的属性,支持CPM用户获取、播放、删除存储消息的请求,支持CPM用户在存储装置中搜索某消息等。
(五)网关
用于实现CPM系统与其他网络的互联,即所述的网关是CPM系统与其他通信网络互联的接口,根据消息服务中心配置方式的不同,网关实现的接口也会不同,例如:
(1)当现有短消息服务中心采用号码段的方式触发短消息时,该网关则需要提供支持SMPP协议或CMPP协议的接口;
(2)当现有短消息服务中心采用CSI(CAMEL签约信息)方式触发短消息时网关提供支持MAP协议的接口;
(3)当与多媒体消息中继服务器通信时,需要实现MM4接口;而与邮件服务器通信时则要提供支持SMTP(简单邮件传输协议)的接口。
(六)其他服务引擎
其他服务引擎主要包括呈现信息服务引擎、Share XDMS(共享文档管理服务器)服务引擎、设备管理服务引擎等可以为CPM系统重用的业务引擎;
CPM系统具体可以通过PRS-5与呈现服务引擎交互获得需要的呈现信息,PRS-5的具体定义和功能可以参考OMA Presence业务规范;CPM系统也可以通过DM-1与设备管理引擎交互获得需要的信息,DM-1的具体定义和功能可以参考OMA DM业务规范;CPM系统还可以通过XCAP协议与Shared XDMS服务引擎交互。
基于上述本发明提供的CPM系统实施例,可以获取该系统提供的融合的IP消息服务的用户设备需要具备的功能包括:可以发送或接收CPM消息,以及发起或接收CPM会话,参与群组会话;管理用户的服务设置和用户个性化设置;支持呈现信息的发布和查看其他好友的呈现信息;还包括根据CPM消息体包含的消息内容的大小自动选择合适的消息传送方式;因此,所述用户设备的结构具体可以包括:CPM客户端和XDM(XML文档管理)客户端,以及用于发布呈现信息的呈现体和用于接收呈现信息的呈现信息接收端,相应的用户设备的具体实现结构如图5所示,各组成部分的具体功能作用如下:
(1)所述的呈现体(Presentity)和呈现信息接收端(Watcher)分别用于发布用户的呈现信息和观察其他用户的呈现信息,其具体实现方式及功能可以参考OMA Presence(OMA呈现)技术规范;
(2)所述的CPM客户端(CPM Client)用于发送和接收CPM消息,以及发起和接收CPM会话;而且,该CPM客户端还可以支持SIP协议、支持SIP-MESSAGE(SIP消息)协议,且还支持MSRP(消息会话中继协议)、RTP(实时传输协议)、RTCP(实时传输控制协议)等媒体传输协议,从而可以通过SIP协议与CPM系统建立会话,通过SIP-MESSAGE协议发送消息到CPM系统,通过MSRP、RTP、RTCP协议访问存储装置中的各种媒体信息;
所述的CPM Client还可以根据用户发送的消息体的内容大小自动的选择合适的消息传送方式,例如,当消息体中包含的消息内容小于1.3K时,可以使用SIP-MESSAGE协议作为CPM消息的承载协议传送CPM消息,而当大于1.3K时,在CPM消息发送之前,CPM Client首先需要通过SIP协议与CPM系统建立对话,再通过MSRP协议或RTP、RTCP协议传送该CPM消息。
(3)XDM客户端(XDM Client)用于管理用户信息存储装置中的用户信息,通过XCAP(XML配置访问协议)访问用户信息存储装置,该XDM客户端的具体实现方式及功能可以参考OMA XDMS(OMA的XML文档管理服务器)技术规范。
本发明还提供了一种实现融合消息通信的方法实施例,在该实施例中融合消息的用户通过用户设备上的CPM客户端或XDM客户端设置自己的服务设置和用户个性化设置;所述CPM系统收到消息后,将根据消息接收方用户类型和消息类型,消息接收方用户的服务设置或用户个性化设置,对消息进行处理后发送给消息接收方,从而实现融合消息业务。
在该方法实施例中提供了融合消息处理的具体实现过程,下面将结合附图对该方法实施例进行详细描述。
为清楚描述该方法实施例,则需要将对实现融合消息业务的各种应用场景进行说明。在实现融合消息业务过程中,具体应用场景包括以下三种:
应用场景一为:由CPM用户向CPM用户发送CPM消息,如图6所示,CPM用户Tommy向另一CPM用户Alice发送CPM消息;
应用场景二为:由CPM用户向非CPM用户发送CPM消息,如图7所示,CPM用户Tommy或CPM用户Alice向非CPM用户Bob发送CPM消息,其中,CPM用户Tommy和CPM用户Alice可以与非CPM用户Bob同域(即属于同一归属网络)或不同域;
应用场景三为:由非CPM用户向CPM用户发送非CPM消息,如图8所示,非CPM用户Bob向CPM用户Tommy或CPM用户Alice发送CPM消息。
基于上述三种应用场景,CPM系统接收到的消息可能是CPM消息,也可能为非CPM消息,同时,CPM系统需要发送的消息同样可能是CPM消息,也可能为非CPM消息;而且,所述非CPM消息进一步又包含多种类型的消息,如SMS消息、多媒体消息及电子邮件等,这样,CPM系统便需要针对不同的消息传送需要进行不同的处理。
进一步讲,该方法实施例的具体实现过程如图9所示,包括:
步骤901:CPM系统收到消息;
其中,收到的消息包括CPM消息和非CPM消息,非CPM消息可以是短消息或多媒体消息或即时消息或Email等;CPM消息是指一个发送给一个或多个消息接收方包含多种媒体信息的消息,所述消息可以通过一个应用程序发送也可以通过终端用户设备发送;
步骤902:CPM系统判断所述收到的消息是否是CPM消息,如果不是,则执行步骤907,否则,执行步骤903;
即判断所述的消息类型为CPM消息还是非CPM消息,如果是非CPM消息,则执行步骤907,否则,执行步骤903
步骤903:CPM系统根据消息接收方标识判断CPM系统需要实现的功能,如果作为参与功能服务器,则执行步骤904,如果作为控制功能服务器,则执行步骤905;
所述的消息接收方标识用于判断消息接收方当前所在的域(即网络)是否是其归属域(即归属网络),并根据判断结果采用如下处理:
如果当前收到消息的CPM系统所在的域为消息接收方归属域,则无论收到消息的消息类型为CPM消息还是非CPM消息,则确定CPM系统需要作为参与功能服务器,并执行步骤904;
如果当前收到消息的CPM系统所在的域不是消息接收方归属域,且所述收到消息的消息类型为CPM消息,则确定CPM系统需要作为控制功能服务器,并执行步骤905;
如果当前收到消息的CPM系统所在的域不是消息接收方归属域,且所述收到消息的消息类型不是CPM消息,则CPM系统根据消息接收方标识包含的路由信息发送出去。
步骤904:CPM系统根据消息接收方标识获取消息接收方对应的用户信息(包括服务设置或用户个性化设置等);并根据消息接收方的服务设置或用户个性化设置判断CPM系统要执行的具体操作,相应的操作具体包括:
(1)根据接收方的服务设置或用户个性化设置,如果所述收到消息的消息类型的优先级不是最高优先级,则CPM系统可以根据:接收方的服务设置或用户个性化设置,消息接收方的呈现信息和消息体中包含的媒体类型中的至少一项对所述收到的消息进行转换;
其中,所述的转换是指将CPM消息转换成接收方的服务设置或用户个性化设置中优先级最高的消息形式,相应的转换过程如图10所示,具体包括:
步骤101:CPM系统的消息转换装置获取与消息转换相关的信息;
所述相关的信息包括消息接收方的服务设置或用户个性化设置,以及根据服务设置或用户个性化设置获取到的消息接收方的呈现信息;
其中,若在用户的服务设置或用户个性化设置中如果包含在消息转换前需要获取消息接收用户的呈现信息,则在步骤101之前,CPM系统还需要订阅消息接收方的呈现信息,获取的方法可以参考OMA标准组织Presence的相关技术规范;
步骤102:CPM系统的消息转换装置根据收到相关的信息和/或CPM消息体中消息的媒体类型确定转换后的消息类型;
其中,所述的媒体类型可以通过CPM消息中包含的内容类型头域确定;
步骤103:将CPM消息转换成步骤102确定的消息类型,如果转换成功,则执行步骤104,否则,返回消息转换失败的响应;
其中,若消息转换失败,CPM系统的消息转换装置也可以继续尝试将CPM消息转换成服务设置或用户个性化设置中优先级较低的消息类型,同样,若转换成功则执行步骤104,否则继续尝试转换,如果所有的转换尝试都失败了则向消息发送方返回失败响应。
步骤104:发送转换后的消息,发送成功后向消息发送方返回成功响应,若发送失败,则向消息发送方返回失败响应;
(2)根据接收方的服务设置或用户个性化设置,如果消息转换部分没有设置或为空,并且设置了在网络侧存储消息,则CPM系统将在存储装置中暂时保存所述收到的消息;
或者,如果消息转换部分没有设置或为空,并且设置了在网络侧存储消息以及在做进一步处理前先检测呈现信息,则CPM系统将向呈现服务器获取消息接收方的呈现信息,然后根据消息接收方的呈现信息判断将所述收到的消息发送给消息接收方还是将所述收到的消息保存在存储装置中;
(3)根据接收方的服务设置或用户个性化设置,如果所述收到消息的消息类型的优先级为最高优先级,则CPM系统将发送所述收到的消息;
在该步骤中,所述的服务设置或用户个性化设置可以是由CPM用户通过用户设备上的XDM客户端设置;其中,所述服务设置既可以保存在CPM系统的消息服务装置中,又可以保存在用户信息存储装置中,如果保存在用户信息存储装置中,则在执行该步骤之前还可以包括:CPM系统的消息服务装置向用户信息存储装置发起获取服务设置的请求;如果请求的内容存在于用户信息存储装置中,则用户信息存储装置在返回的成功响应的消息体中包含此用户的服务设置内容,否则,返回错误响应;所述用户个性化设置既可以保存在CPM系统的用户信息存储装置中又可以保存在其他服务引擎中(该其他服务引擎中保存的用户个性化设置可能不是专为实现本发明的实施例所设置,而为之前已经存在),例如,共享XDMS服务器上,此时,若需要根据用户的个性化设置来判断具体要执行的操作时,则需要先执行:CPM系统的消息服务装置向用户信息存储装置或其他服务引擎发起获取服务设置的请求;如果请求的内容存在于用户信息存储装置或其他服务引擎中,则用户信息存储装置或其他服务引擎在返回的成功响应的消息体中包含此用户的服务设置内容,否则,返回错误响应;
步骤905:CPM系统判断所述收到的消息中是否包含控制信息,如果包含,则执行步骤906,否则,将所述收到的消息发送出去;
所述的控制信息是指包含在CPM消息体中或包含在CPM消息头域中指示消息接收方接收消息的指示信息,如指示接收方接收消息的地址形式或会话模式的信息等,CPM系统将根据这些控制信息便可以将所述收到的消息转换成控制信息指示的消息形式,从而便于消息接收方的接收。
步骤906:CPM系统根据消息中包含的控制信息将CPM消息转换成控制信息描述的消息形式,转换成功后发送转换后的消息给接收方;
步骤907:CPM系统收到消息后,判断出所述收到的消息为非CPM消息,则CPM系统获得消息接收方的服务设置和/或用户个性化设置,根据消息接收方的服务设置和/或服务个性化设置判断处理收到的消息的方式,具体包括:
(1)如果确定需要转换该消息,则根据消息接收方的服务设置、服务个性化设置、呈现信息和消息体中包含的媒体类型中的至少一项判断转换的消息类型,并执行相应的转换,然后,发送出去;
进一步讲,若消息接收方的服务设置或用户个性化设置中CPM消息服务优先级不是最高,则CPM系统执行的转换方式包括以下任一种:
直接将收到的消息转换成根据消息接收方服务设置、消息接收方的呈现信息和消息体的媒体类型中的至少一项确定的消息形式;
将收到的消息首先转换成CPM消息,再由CPM消息转换成根据消息接收方服务设置、消息接收方的呈现信息和消息体的媒体类型中的至少一项确定的消息形式;例如,当CPM系统接收到SMS消息后,根据消息接收方服务设置、消息接收方的呈现信息和消息体的媒体类型中的至少一项确定消息接收方可以接收MMS消息,则CPM系统将这条SMS消息首先转换成CPM消息的形式,之后再转换成MMS消息的形式;
(2)如果确定需要存储该消息,则将所述消息保存在CPM系统中;
(3)如果确定仅需发送该消息,则通过网关发送所述消息。
为便于进一步理解本发明,下面将再以几个不同应用场景下的实际应用实施例对本发明的具体实现过程进行详细描述。
实施例1
在该实施例1中,用户1和用户2都是CPM用户,用户1开启用户设备后,成功注册到CPM服务,用户2也开启了用户设备,并成功注册到CPM服务,用户1向用户2发送CPM消息,CPM消息采用SIP-MESSAGE协议承载。
在该应用场景下,相应的用户1发送CPM消息的具体实现处理流程如图11所示,包括的步骤如下:
步骤111:用户1通过SIP-MESSAGE协议向用户2发送CPM消息;
步骤112:网络侧的SIP/IP Corel(SIP/IP核心网)或IMS1收到所述的CPM消息后,向CPM系统1转发用户1的CPM消息服务请求;
步骤113:所述的CPM系统1中的消息服务装置1接收消息后,根据消息类型来判断是否是CPM消息,并进行相应的处理;其中,所述的消息类型可以用SIP-MESSAGE消息的Event头域表示;
在该实施例中,根据消息类型将确定收到的是CPM消息,此时,消息服务装置将进一步通过消息中的Request-URI(请求用户资源标识)表示的用户2的用户标识来判断是作为参与功能服务器还是作为控制功能服务器,其中:
如果Request-URI是用户2的用户标识或临时群组,那么若用户1是此消息服务装置服务域的归属用户,则该消息服务装置就作为控制功能服务器,否则,作为参与功能服务器;
如果Request-URI是一个预定义群组,那么若此预定义群组为在此消息服务装置上定义,则该消息服务装置就作为控制功能服务器,否则,作为参与功能服务器;
步骤114:若作为控制功能服务器,则CPM系统1的消息服务装置1向所述的SIP/IPCorel或IMS1转发CPM消息,并完成控制功能服务器的相应功能;
步骤115、116、117:分别向对应的实体返回CPM消息发送成功的响应。
在该实施例1中,相应的在网络侧向用户2发送CPM消息的处理过程如图12所示,具体包括以下步骤:
步骤121:网络侧的SIP/IP Core2或IMS2将所述SIP/IP Corel或IMS1转发来的由用户1发来的CPM消息转发给CPM系统2的消息服务装置2;
步骤122:CPM系统2的消息服务装置根据用户2的服务设置将CPM消息发送给用户2,具体可以根据服务设置确定是否需要对CPM消息进行转换处理,并在确定需要进行转换处理时,还需要进一步根据服务设置确定转换后的消息类型,以进行相应的转换处理;
所述的服务设置可以存储于消息服务装置或者设置于用户信息存储装置中;
当用户2的服务设置存储在用户2所在域的CPM系统的消息服务装置中时,用户2具体可以通过SIP协议的PUBLISH(发布)方法将设置好的服务设置文档发送给消息服务装置,并设置SIP PUBLISH请求的Request-URI为CPM用户的标识,例如为:user2lab2.com;此外还应该包含Accept-Contact头域,并设置为CPM特征标签值,例如可以为‘+g.oma.sip-cpm’,并将其‘explicit’参数根据[RFC3841]中的规则来设置;在该步骤中,消息服务装置可以通过用户2的用户标识找到相关的服务设置文档;
当用户2设置的服务设置文档存储在用户信息存储装置中时,则在执行步骤122之前还应该包括如下获取服务设置的步骤:
(1)消息服务装置2使用XCAP协议的get(获取)方法或SQL(结构化查询语言)查询语句向用户信息存储装置2获取用户2的服务设置,当用户信息存储装置2采用XDMS的方式实现时,获取用户2服务设置的请求如表1所示;
表1
GET http://xcap.example.com/org.openmobilealliance.cpmxdms/users/sip:user2lab2.com/user2_servicesetting.xml HTTP/1.1…Content-Length:0 |
在该请求中,用户信息存储装置的AUID(应用服务唯一标识)可以为:org.openmobilealliance.cpmxdms。
(2)用户信息存储装置2根据所述请求确定相应的服务设置,并向所述的消息服务装置2返回成功响应消息(即200ok),并在该响应消息的消息体中携带消息服务装置2所请求的用户2的服务设置user2_servicesetting.xml。
在该实施例中,CPM用户的服务设置对应的文档具体可以包含PoC和/或IM服务设置的所有或部分内容,此外,所述的服务设置对应的文档还可以包括以下至少一项内容:
(1)在向消息接收方转发CPM消息之前获取用户2的呈现信息;
(2)当用户的CPM服务不可用时,将CPM消息暂时存储在CPM系统的存储装置中或是转换成用户最希望的接收方式,其中,可以选择的接收方式包括但不限于:短消息服务(SMS,Short Message Service)、多媒体消息服务(MMS,Multi Media Service)、无线一键通(PoC,Push to talk over cellular)、即时消息(IM,Instant Message)、电子邮件(Email)等;如果用户设置了短消息服务和多媒体消息服务,则还应该在服务设置文档中同时指明移动用户的MSISDN(国际ISDN号码);如果用户设置了电子邮件服务,则还应该在服务设置文档中同时指明电子邮件的地址;而对于无线一键通和即时消息服务,用户则无需指明具体的联系方式,使用CPM消息中的接收方用户地址即可;
(3)一个扩展字段,用于根据需要扩展相应的服务设置;
以具体采用XML的形式表示所述的服务设置为例,相应的服务发置对应的文档的具体表示方式可以如表2所示:
表2
<?xml version=″1.0″encoding=″UTF-8″?><cpm-settings xmlns=″urn:oma:params:xml:ns:cpm:cpm-settings″><entity id=″do39s8zksn2d98x″><dpib-setting><detect-presence-information-before active=″true″/></dpib-setting><cpm-service active=″true″PRI=0><iw-settings><iw-with-SMS active=″true″PRI=1 MSISDN=″13566008800″/><iw-with-MMS active=″true″PRI=2 Recipient_address=″13566008800″/><iw-with-IM active=″true″PRI=3><IM-settings ref=″do39s8zksn2d98x″/></iw-with-IM><iw-with-PoC active=″true″PRI=4><PoC-settings ref=″do39s8zksn2d98x″/></iw-with-PoC><iw-with-E_mail active=″true″PRI=5 E_mail_address=″user2lab2.com″/><interworking-with-other_service active=″true″PRI=6/></iw-settings><inbox-settings active=″true″><extention-settings/></entity></cpm-settings> |
在该表中,<cpm-settings>,用于表示该信息为用户的CPM服务设置文档,且具体包含零个或多个<entity>元素,每一个<entity>都包含一个id属性其值为发布这个设置文档的事件包代理的一个全局唯一的AOR(address-of-record,记录地址),<entity>元素代表发布CPM服务设置文档的事件包代理;且当CPM服务设置文件无效时,<cpm-settings>包含零个<entity>元素;
其中,所述的<entity>元素包含零个或多个<dpib-setting>元素,<cpm-service>元素,零个或多个<iw-settings>元素,零个或多个<inbox-settings>,零个或多个<extention-settings>元素,各个元素的含义如下:
(1)<dpib-setting>元素,包含一个唯一的子元素<detect-presence-information-before>,该子元素有一个布尔值的属性“active”,根据用户的喜好设置表示是否在转发CPM消息前获取用户2的呈现信息,其默认值为“false”,表示不获取含义;
如果用户2设置<detect-presence-information-before>元素的active属性值为true,那么消息服务装置在发送CPM消息前需要向呈现业务服务器获取用户的呈现信息,即在步骤126之前CPM系统的消息服务装置需要向呈现业务服务器发起订阅请求,具体可以采取一次订阅方式也可以长期订阅;
(2)<cpm-service>元素,包含一个布尔值的属性“active”,其默认值为true,用于表示此用户的CPM服务是否可用;以及一个表示优先级的整型属性“PRI”,其默认值为0,表示最高的优先级,其值不能与其他的消息服务优先级冲突,即不能与其他的消息服务优先级的数值相同,当PRI值大于0时,即使此时用户2的CPM服务可用,也会选择优先级高于CPM消息服务的消息服务方式将用户1发送的CPM消息发送给用户2;
(3)<iw-settings>元素,包含多个消息转换类型的子元素,每一个子元素包含一个布尔值的属性“active”,根据用户的喜好设置表示是否将CPM消息转换成相应的消息类型;且还包含一个整型的属性“PRI”,根据用户的喜好设置表示转换类型的优先级;
其中,包含的所述的消息转换类型的子元素可以为以下至少一项:
<iw-with-SMS>,表示将CPM消息转换成SMS消息的形式,其包含一个字符型的特殊属性“MSISDN”,表示移动用户的国际ISDN号码;
<iw-with-MMS>表示将CPM消息转换成MMS消息的形式,其也包含一个字符型的特殊属性“Recipient_address”,表示MM接收方的地址;
<iw-with-IM>表示将CPM消息转换成IM消息的形式;
<iw-with-PoC>表示将CPM消息转换成PoC消息的形式;
<iw-with-E_mail>表示将CPM消息转换成E_mail的形式,其包含一个字符型的特殊属性“E_mail_address”,表示用户的电子邮箱地址;
其中,所述的<iw-with-PoC>元素和<iw-with-IM>元素还可以包含一个可选的对PoC服务设置文档和IM服务设置文档的引用,即<PoC-settings>元素和<IM-settings>元素分别包含一个必选的ref属性,其值为PoC服务设置文档和IM服务设置文档的id值;若ref属性指定的PoC服务设置文档和IM服务设置文档不存在,则<iw-with-PoC>元素和<iw-with-IM>元素还可以引用PoC和IM规范中服务设置元素的定义;
该<iw-settings>元素包含的所有子元素的默认值为“false”。
如果用户2设置<iw-settings>中的某些子元素的active属性值为true,设置了PRI属性值,则即使将<inbox-settings>元素的active属性值设置为true,也需要对相应的消息转换;如果转换失败或消息发送失败,则可以根据<inbox-settings>元素中的设置信息将CPM消息存储在存储装置中;
(4)<inbox-settings>元素包含一个布尔值的属性“active”,根据用户的喜好设置表示当用户当前不可获得CPM消息或CPM消息发送失败时,是否将CPM消息发送到存储装置中存储,其默认的值为“ture”。
如果用户2设置<inbox-settings>元素的active属性值为true,那么CPM系统的消息服务装置在发送CPM消息失败后,会将CPM消息发送到存储装置存储,当用户可以接收CPM消息时(例如可以根据用户的呈现信息获知)重新发送消息给用户2,或采取短消息等其他消息形式向用户2发送提醒消息,用户2根据提醒消息中的链接访问存储装置来获取被存储的消息;
再例如,如果用户2的服务设置文档中没有消息转换相关内容的设置,则当后续的消息发送失败后需要根据<inbox-settings>元素的设置来判断是否将消息存储在存储装置中,如果<inbox-settings>元素的“active”属性值为“false”,那么消息服务装置就应该向用户1返回消息发送失败的响应,否则返回消息发送成功的响应;
(5)<extention-settings>元素为以后可能扩展的功能使用的可扩展的元素。
可以看出,利用上述服务设置信息便可以进行相应的消息转换处理;
步骤123:CPM系统2的消息服务装置将CPM消息转发给SIP/IP Core2或IMS2;
步骤124:所述的SIP/IP Core2或IMS2将CPM消息转发给用户2;
步骤125、126:用户2成功接收了CPM消息后,向对应的实体返回响应;
如果用户2设置<detect-presence-information-before>元素的active属性值为true,则在步骤126之前CPM系统的消息服务装置需要向呈现业务服务器发起订阅请求获取用户的呈现信息。
在该实施例中,主要的处理过程是步骤122提供的对消息进行转换处理的过程,通过相应的转换处理,可以保证用户2可以顺利地接收到其期望接收的消息格式。为便于对该实施例的进一步理解,下面将对该转换处理的具体实现过程进行说明。
(一)首先,确定转换后的消息类型;
在上述步骤122的处理过程中,除可以基于服务设置确定转换后的消息类型外,还可以基于以下任一种信息进行转换后的消息类型的确定:
(1)根据消息体的内容类型确定消息转换后的消息类型
为此,在将CPM消息发送给消息转换装置进行消息转换前还应该分析用户1的CPM消息体包含的内容类型,所述CPM消息体可以包含的内容类型包括:纯文本信息或各种多媒体文件,所述的各种多媒文件可以是图片、文本文件、音频文件、影音文件、离散的媒体、实时的流媒体等多媒体信息;
在消息服务装置中,具体可以从CPM消息的Content-type头域获知消息体中的内容类型,例如,用户1向用户2发送的CPM消息格式如表3所示:
表3
MESSAGE sip:user2lab2.com SIP/2.0Via:SIP/2.0/TCPproxy.lab 1.com;branch=z9hG4bK123dsghdsVia:SIP/2.0/TCPuser1pc.lab1.com;branch=z9hG4bK776sgdkse;received=1.2.3.4Max-Forwards:69From:sip:user1lab1.com;tag=49394 |
To:sip:user2lab2.comCall-ID:asd88asd77a1.2.3.4CSeq:1MESSAGEContent-Type:text/plainContent-Length:18Watson,come here. |
在所述的消息转换装置中,具体是根据消息体中的不同内容类型,将CPM消息转换成不同类型的消息,例如,对于文本消息可以转换为SMS或IM消息,而对于包含图片、文本文件、音频文件、离散的媒体、影音文件等的CPM消息可以转换成MMS消息或Email,对于实时的音频流则PoC是更加适合的通信方式。以上述表3中的SIP-MESSAGE消息为例,消息体中包含的内容类型为text/plain,根据用户2的服务设置短消息的优先级最高,因此,消息转换装置应该将此条消息转换成SMS的形式发送给用户2。
(2)根据用户2的呈现信息和服务设置共同确定转换后的消息类型
为此,CPM系统需要在消息转换前获取用户2的呈现信息,之后,根据用户2呈现信息中的描述获取用户当前正在使用的消息类型,并结合用户2的服务设置中消息转换的优先级将CPM消息转换成可用的消息服务中优先级最高的消息类型,然后,发送给用户2;例如用户2的呈现信息描述如表4所示:
表4
<?xml version=″1.0″encoding=″UTF-8″?><presence xmlns=″urn:ietf:params:xml:ns:pidf″xmlns:op=″urn:oma:xml:prs:pidf:oma-pres″entity=″sip:someoneexample.com″><tuple id=″a1232″><status><basic>open</basic></status><op:service-description><op:service-id>org.openmobilealliance:SMS</op:service-id><op:version>1.0</op:version></op:service-description>......</tuple><tuple id=″a5469″><status><basic>open</basic></status><op:service-description><op:service-id>org.openmobilealliance:IM</op:service-id><op:version>1.0</op:version></op:service-description>......</tuple></presence> |
从上述用户2的呈现信息可以看出,通过SMS和IM两种消息服务方式均可以与用户2通信,而根据用户2的服务设置中SMS的优先级最高,因此,消息转换装置应该将CPM消息转换成SMS消息的形式再发送给用户2;如果呈现信息中显示目前只能通过一种消息服务方式来和用户2联系,例如,只能通过IM消息与用户2通信,则消息转换装置需要将该消息转换成相应的可以与用户2进行消息通信的IM消息类型。
(3)根据用户2的呈现信息和用户1发送的CPM消息体中的内容类型以及服务设置三者结合起来确定转换后的消息类型
参照前例,若用户1发送的CPM消息体中包含的内容类型为text/plain,用户2的呈现信息中显示可以通过SMS消息和IM消息与用户2通信,而用户2的服务设置中SMS消息服务的优先级最高,结合三方面的信息,应该将CPM消息转换成SMS消息的形式与用户2通信。
(4)根据用户终端的设备能力信息
在消息转换前还可以获取用户2的终端设备UAProf(User Agent Profile,用户代理特性),并根据用户2的终端设备UAProf进行转换。为了获取用户2的终端设备UAProf,消息服务装置可以通过HTTP协议的GET(获取)请求向存储用户2的终端设备UAProf的存储器获取用户2的终端设备UAProf,消息服务装置获取这一信息的请求实例如下表所示:
GEThttp://anyuri/HTTP/1.1Host:plaintextx-wap-profile:“http://profilerepository/”,“l-uKdjJHuhj HUuj” |
在上表中,x-wap-profile头域表示存储用户2的终端设备UAProf的存储器标识和用户2的终端设备UAProf的文档标识。
如果获取成功,存储器返回成功响应,并在响应中包含用户2的终端设备UAProf,具体如下表所示:
HTTP/1.1 200 OKDate:…<rdf:RDF xmlns:rdf=″http://www.w3.org/1999/02/22-rdf-syntax-ns#″xmlns:prf=″http://www.openmobilealliance.org/tech/profiles/UAPROF/ccppschema-20021212#″><rdf:Description rdf:ID=″Huawei6260″><prf:component><rdf:Description rdf:ID=″HardwarePlatform″><rdf:typerdf:resource=″http://www.openmobilealliance.org/tech/profiles/UAPROF/ccppschema-20021212#HardwarePlatform″/><prf:Vendor>Huawei</prf:Vendor><prf:Model>6260</prf:Model><prf:ImageCapable>Yes</prf:ImageCapable> |
<prf:ScreenSize>78x30</prf:ScreenSize><prf:ScreenSizeChar>10x3</prf:ScreenSizeChar></rdf:Description></prf:component><prf:component><rdf:Description rdf:ID=″SoftwarePlatform″><rdf:typerdf:resource=″http://www.openmobilealliance.org/tech/profiles/UAPROF/ccppschema-20021212#SoftwarePlatform″/><prf:OSVendor>Huawei</prf:OSVendor></rdf:Description></prf:component></rdf:Description></rdf:RDF> |
根据上述实例描述的用户2的终端设备UAProf中包含的信息可知,用户2的终端设备支持图片输入,因此可以将用户1发送的消息转换成MMS消息的形式。
进一步,所述消息服务装置还可以在获取请求中指明用户2的终端设备UAProf中的某个元素,并在返回的成功响应中返回此元素的值。
上述实例中每一个元素的具体含义可以参考OMA标准组织中UAProf的相关规范,在此不再描述。
进一步,所述消息服务装置还可以通过网关来获取用户2终端设备能力信息,根据用户2终端设备能力信息存储位置的不同,网关获取用户2的终端设备能力信息的方式也有所不同,可以根据运营商的实现策略采用适当的方式获取,例如,当用户2的终端设备能力信息保存在用户2的终端设备的家乡位置寄存器时,可以通过MAP协议获取:当用户2的终端设备能力信息保存在HTTP服务上时,可以通过HTTP协议的GET方法获取。网关成功获取后将获取到的信息返回给消息服务装置,并由服务装置根据网关返回的信息确定转换成何种消息类型。
(二)在消息服务装置通过上述任一方式确定了消息转换类型后,将CPM消息、消息转换的具体类型等信息发送给消息转换装置,以触发消息转换装置进行相应的消息类型的转换处理;
针对上述表3所示实例,消息转换装置应该将表3所示的由SIP-MESSAGE承载的CPM消息转换成短消息,转换后采用SMPP(Short Message Peer-to-Peer Protocol,短消息点对点协议)协议的SMS消息实例如表5所示:
表5
Command Length:28Command ID:0X00000004Sequence No.:0534769h |
SUBMIT_SMservice_type:NULLsource-addr_ton:NULLsource_addr_npi:NULLsource_addr:13677051166dest_addr_ton:NULLdest_addr_npi:NULLdestination_addr:13566008800esm_class:NULLprotocol ID:3priority_flag:0schedule_delivery_time:NULLvalidity_period:NULLregistered_delivery_flag:0replace_if_present_flag:0data_coding:0sm_default_msg_id:NULLsm_length:18Short_message:Watson,come here. |
为了实现将CPM消息转换成SMS消息的能力,消息转换装置需要实现SME(短消息实体)的功能,具体可以参考GSM 0340的相关规范;在表5中消息头和消息体的参数也可以参照规范GSM 0340 0339中的定义;
在消息转换装置产生SMS消息时,消息体中的destination_addr、sm_length、short_message参数可以直接从服务设置文档和CPM消息中获得,而在产生参数source_addr值时需要消息转换装置获取相关的参数值,其他的参数如果用户1没有特殊指定可以参考规范GSM 0340 0339中定义的默认值;所述消息转换装置获取source_addr的参数值时可以要求用户1提供,也可以由消息转换装置为用户1临时分配一个符合SMS业务需求的标识符临时标识用户1,其中,
当采取用户1提供的方式时,消息转换装置可以使用SIP协议发送一个通知消息给用户1,当用户1确认同意使用SMS消息与用户2通信时提示用户1输入有效的符合SMS业务需求的用户标识,并提示输入其它的相关参数;若用户1不同意使用SMS消息与用户2通信,则消息转换装置向用户1返回CPM消息发送失败的响应消息;若CPM消息被成功的转换,则消息转换装置应该向用户1返回202的成功响应;
当采用临时分配标识符的方法时,消息转换装置应该为用户1分配一个临时的有效的用户标以,并将保存用户的临时标识与用户1原有用户标识的对应关系,此临时标识与消息转换装置产生的SMS消息的有效期一致,在一个完整的会话过程中此临时标识不变;对于由消息转装置产生的各临时标识可以采用以一个固定值开头的形式,例如,均以固定的6000、7000等值开头。
基于上述实施例的描述,当用户2直接对收到的转换后的消息进行回复时,如果SMS消息中的source_addr参数值是由用户1提供的MSISDN号码,则用户2回复的消息按照SMS进行回复处理即可:如果SMS消息中的source_addr参数值是由消息转换装置分配的临时用户标识,则用户2回复的消息最终应该由CPM系统接收,并由消息转换装置转换成由SIP-MESSAGE承载的CPM消息后再发送给用户1。
以上仅是采用SIP-MESSAGE承载的CPM消息与SMS消息转换的具体实施方式,当用户1发送的CPM消息的消息体中包含多媒体的消息内容而需要转换为其他的消息类型时,例如转换为Email的消息方式,则消息转换装置就需要实现将SIP-MESSAGE协议承载的CPM消息转换成采用SMTP协议承载的Email。
具体的SIP-MESSAGE协议与SMTP协议如何进行转换的实现方式如表6所示,表中的第一列给出了SIP-MESSAGE协议承载的CPM消息头域,第二列给出了SMTP协议承载的Email头域,对于一些SIP-MESSAGE协议头域不需要转换成SMTP协议头域,则使用“Suppressed”标记表示;
表6
CPM消息信息元素 | Email消息信息元素 | 备注 |
Request-URI | Suppressed | |
From | SMTP--MAIL FROMMIME-From | |
To | Suppressed | SMTP--RCPT TOMIME--To;Cc;其值通过用户2的服务设置文档获得,即E_mail_address属性值,并不从CPM消息头域中获得 |
Expires | SMTP--DELIVER-BYparameter of RCPT TO | 参照rfc2852的定义 |
Data andTimestamp | MIME--Date | |
Record-Route | Suppressed | |
Route | Suppressed | |
Accept | Suppressed | |
Allow | Suppressed | |
Authorization | Suppressed | |
Call-ID | SMTP--ENVIDMIME--Message-ID | 根据rfc 3461的定义,当返回递送状态通知时使用。同时消息转换装置可以根据此值返回响应 |
Call-Info | Suppressed | |
Contact | Suppressed | |
Content-Disposition | MIME--Content-Description | |
Content-Encoding | MIME--Content-Transfer-Encoding | |
Content-Language | Suppressed | |
Content-Length | Suppressed | |
Content-Type | MIME--Content-Type | |
CSeq | Suppressed | |
Max-Forwards | Suppressed | |
Priority | MIME--X-Priority | |
Proxy-Authorization | Suppressed | |
Proxy-Require | Suppressed | |
Require | Suppressed | |
Reply-To | SMTP--Reply-To | |
Via | Suppressed | |
<message body> | <message body> | 消息内容 |
在该转换实施例中,SIP-MESSAGE协议和SMTP协议头域的相关描述可以分别参考IETF的规范rfc3248和rfc2821。
需要说明的是,在将由SIP-MESSAGE协议承载的CPM消息转换成由SMTP协议承载的Email消息时,SMTP协议中的MAIL FROM头域值或MIME的FROM头域值可以由用户1提供,也可以由消息转换装置为用户1临时分配一个符合Email业务需求的标识符临时标识用户1;而且,对于SMTP协议中无法从CPM消息中获得的头域值,则可以由消息转换装置根据本地策略定义。
在该转换实施例中,将表3所示的由SIP-MESSAGE承载的CPM消息转换成Email的实例如表7所示:
表7
From:user1<user1example.com>To:user2<user2example.net>Subject:Message from user1Message-ID:<asd88asd77a1.2.3.4>Watson,come here. |
在这一实施例中,Subject头域的信息从CPM消息中无法获得,因此,可以由消息转换装置根据本地策略定义。
另外,当用户1发送的CPM消息需要转换成多媒体消息时,则消息转换装置也可以将CPM消息转换成由SMTP协议承载的MM形式的消息,并由网关转发给用户2归属网络的多媒体消息的中继服务器;或者,消息转换装置也可以将用户1发送的CPM消息直接转换成MM消息,在这种情况下消息转换装置需要实现MM4接口,MM4接口的相关定义可以参考3GPP技术规范23.140;
相应的SIP-MESSAGE协议承载的CPM消息与MM消息信息元素的映射关系如表8所示:
表8
CPM消息信息元素 | MM消息信息元素 | 备注 |
Request-URI | Suppressed | |
From | Suppressed | Forwarding address其值可以的获取方式与SMS实例中源地址的获取方法相似 |
To | Suppressed | Recipient address其值通过用户2的服务设置文档获得,即Recipient_address属性值,并不从CPM消息头域中获得。 |
Expires | Time of Expiry | |
Data and Timestamp | Date and time | |
Record-Route | Suppressed | |
Route | Suppressed | |
Accept | Suppressed | |
Allow | Suppressed | |
Authorization | Suppressed | |
Call-ID | Transaction ID | |
Call-Info | Suppressed | |
Contact | Suppressed | |
Content-Disposition | Suppressed | |
Content-Encoding | Suppressed | |
Content-Language | Suppressed | |
Content-Length | Suppressed | |
Content-Type | Content Type | |
CSeq | Suppressed | |
Max-Forwards | Suppressed | |
Priority | Priority | |
Proxy-Authorization | Suppressed | |
Proxy-Require | Suppressed | |
Require | Suppressed | |
Reply-To | Suppressed | |
Via | Suppressed | |
<message body> | <message body> | 消息内容 |
Message Type | MM中的必选信息元素,按照3GPP技术规范23.140中的定义由消息转换装置产生。 | |
MMS Version | MM中的必选信息元素,按照3GPP技术规范23.140中的定义由消息转换装置产生。 |
表中,相应的MM信息元素的相关描述可以参考3GPP技术规范23.140;相应的MM4_forward.REQ请求消息中的其他信息元素的值可以根据3GPP技术规范23.140中的定义由消息转换装置指定;
由SIP-MESSAGE承载的CPM消息转换成MM消息的实施例如表9所示:
表9
X-Mms-Message-Type:m-send-reqX-Mms-Transaction-ID:2X-Mms-MMS-Version:1.0From:13677051166/Type=PLMNTo:13566008800/Type=PLMNSubject:111Content-Type:text/plainData:Watson,come here. |
在消息转换装置中,若需要将用户1发送的CPM消息转换成即时消息,则该消息转换装置需要实现SIP代理服务器的相关功能,具体内容可以参考IETF规范文档rfc3261。
在上述实施例中,仅是以采用SIP-MESSAGE协议作为承载协议的CPM消息的处理过程为例进行的描述。在具体应用本发明的过程中,所述的CPM消息还可以使用SIP、HTTP、SMFP等协议作为承载协议,此时,相应的融合消息业务的实现过程同样适用。
实施例2
在该实施例2中,用户1是CPM用户;用户2为非CPM用户,其具体使用非CPM消息服务(如SMS、MMS、Email等);
在该实施例中,相应的处理过程如图13所示,包括如下步骤:
步骤131:用户1使用用户设备上的CPM客户端通过SIP-MESSAGE协议的MESSAGE方法或HTTP协议的POST方法向CPM系统发起CPM消息服务请求;
在该步骤中,用户1在发起CPM消息服务请求时,请求中可以携带将CPM消息转换成某种类型消息的控制信息;所述的控制信息可以在用户1将用户2的用户标识输入用户设备时设定,也可以在用户1发送CPM消息时通过CPM客户端设置;所述的控制信息可以在CPM消息的消息体中或者为某个CPM消息的头域值;且该控制信息可以为消息接收方标识的类型,例如,消息接收方的标识可以是MSISDN号码、Email地址等;
当控制信息在CPM消息体中时,消息服务装置在收到CPM消息时需要解析CPM消息的消息体,当采用SIP-MESSAGE协议承载时,包含控制信息的CPM消息如下表10所示:
表10
MESSAGE sip:CPMSysCPMSys.com SIP/2.0Via:SIP/2.0/TCP proxy.lab1.com;branch=z9hG4bK123dsghdsVia:SIP/2.0/TCP user1pc.lab1.com;branch=z9hG4bK776sgdkse;received=1.2.3.4Max-Forwards:69From:sip:user1lab1.com;tag=49394To:sip:CPMSys<sip:CPMSysCPMSys.com>Call-ID:asd88asd77a1.2.3.4CSeq:1 MESSAGEEvent:CPMContent-Type:text/plainContent-Length:18<?xml version=’1.0′?><cpm-message xmlns=″urn:ietf:params:xml:ns:cpmm″><Header><Senderldentification><From><CPMURI>sip:user1lab1.com</CPMURI></From></Senderldentification><Recipients><To><RFC2822Address>user2lab2.com</RFC2822Address></To></Recipients><TimeStamp>2006-12-02T09:30:47-05:00</Date><TransactionID>asd88asd77a1.2.3.4</TransactionID><ExpiryDate>P90D</ExpiryDate><DeliveryReport>True</DeliveryReport></Header><Body><Subject>Liaison</Subject><Content>Watson,come here.</Content><Body></cpm-message> |
在该表中,<RFC2822Address>即为所述控制信息;
在该表中,SIP-MESSAGE协议MESSAGE方法和各种头域的相关定义可以参考IETF规范rfc3428。
表10中,所述由SIP-MESSAGE协议承载的CpM消息包含一个根元素<cpm-message>,用于表示该SIP-MESSAGE的消息体是一个CPM消息;所述的<cpm-message>元素包含两个子元素<Header>和<Body>,分别表示CPM消息的消息头部分和消息体部分;具体为:
(1)<Header>部分包含CPM消息的控制信息,且可以为:CPM消息发送方标识<SenderIdentification>、CPM消息接收方信息<Recipients>、CPM消息发送的时间戳<TimeStamp>、过期时间<ExpiryDate>、一个是否需要发送递送报告的布尔型的元素<DeliveryReport>、唯一标识这个CPM消息的ID<TransactionID>等信息,而且,消息头部分的控制信息可以根据需要扩展,其中,
所述的<SenderIdentification>包含一个<From>子元素表示CPM消息的源发送端信息,<From>子元素包含一个表示消息发送方用户标识的子元素,当消息发送方是一个CPM用户时,则可以表示为<CPMURI>;
所述的<Recipients>子元素包含一个或多个<To>子元素,表示CPM消息接收方,所述的<To>子元素可以包含一个表示消息接收方用户标识的子元素:当消息接收方的地址是一个Email地址时,可以用<RFC2822Address>方式表示;而当消息接收方的地址时一个IM地址时,可以使用<IMURI>方式表示;当消息接收方的地址是一个PoC地址时,可以使用<PoCURI>的方式表示;当消息接收方的地址是一个MSISDN地址是,可以使用<MSISDN>的方式表示;即根据消息接收方的接收地址不同应该采取相应的地址表示方式。
(2)<Body>消息体部分包含消息内容,其包含一个可选的<Subject>元素,相应值为一个String类型的字符串,用于表示消息的主题;其还包含相应的<Content>元素,用于表示消息的内容,具体可以是文本信息,也可以是对多媒体信息的引用等,此外当包含多媒体信息时还可以包含一个可选的布尔型的属性allowAdaptations,用于表示是否允许收到消息的客户端根据消息内容进行适配;
步骤132:消息服务装置收到用户1发送的CPM消息服务请求后,根据消息中event头域判断出此消息是CPM消息,然后根据消息接收方标识判断出消息服务装置应该担任控制功能服务器,再判断消息中是否包含控制信息,如果包含,则执行步骤133,以将CPM消息服务请求转发给消息转换装置,由消息转换装置进一步处理,否则向用户1返回错误响应;
在该步骤中,具体是以消息接收方的用户标识类型作为消息服务装置判断是否需要将CPM消息转发给消息转换装置进行处理的依据;根据上述实例,CPM消息的To头域值为CPM系统的SIP URI地址,而消息接收方的地址则包含在MESSAGE消息体中,并用<Recipients>元素标识,消息转换装置在执行消息转换时从消息体中解析出消息接收方标识“user2lab2.com”,并根据消息接收方标识的提示信息进行消息转换,具体的转换方法可以参考实施例1中的相关描述,在此不再赘述;
当控制信息在CPM消息的某个头域中表示时,则可以对CPM消息的承载协议进行扩展,仍以上述实例为例,可以在SIP-MESSAGE协议的头域中增加一个字段X-CPM-Transformation-Tpye,其值可以是一个String型的字符串,具体的表现形式如下:
X-CPM-Transformation-Tpye:Email;
这样,消息服务装置收到CPM消息后便可以根据这个扩展的字段直接将CPM消息转发给消息转换装置处理,而不需要解析消息体中的具体内容;
另外,在该步骤或该步骤之前,消息服务装置还可以向其他服务引擎获取转换CPM消息的相关信息,例如,呈现信息、群组成员列表等信息,以便于根据相应的信息进行CPM消息的转换处理;以呈现信息为例,相应的获取呈现信息的方法可以参考实施例1中的描述的方法,而群组成员列表如果采用XDMS的存储则可以使用XCAP协议的GET请求获取,如果采用数据库的方式存储则可以采用SQL查询语句获取;而且,根据其他服务引擎的具体实现方式不同,消息服务装置可以采用相应的获取方法,在此不再一一列举说明;
步骤133:消息服务装置将CPM消息服务请求转发给消息转换装置;
步骤134:消息转换装置根据CPM消息中的控制信息(如接收方标识的类型等)将CPM消息服务请求转换成用户2可以接收的消息类型;
步骤135:消息转换成功后,则消息转换装置向消息服务装置返回消息转换成功的响应,否则,返回失败响应;
步骤136:CPM消息成功地被转换处理后,所述的消息转换装置会将转换后的消息转发给网关;
步骤137:通过网关将转换后的消息转发给相应的消息服务器处理;
步骤138、139:所述消息被成功转发后,网关及消息转换装置将会返回用户2收到用户1发送的消息的成功响应;
步骤1310:消息转换装置将收到的成功响应转换成CPM消息承载协议的成功响应消息,例如,200ok消息;
步骤1311、1312:消息转换装置将转换后的成功响应发送给用户1。
在该实施例2中,当CPM用户向非CPM用户发送多媒体消息内容时,如果多媒体消息内容的大小超过SIP-MESSAGE协议消息体大小的限制,即1.3K,则CPM客户端可以根据这一信息采取建立会话的方式发送多媒体消息给用户2;具体过程如图14所示,包括:
步骤141、142:用户1(即UE1)与消息服务装置之间建立会话连接,并进行相应的媒体流的传输,从而将媒体消息发送给消息服务装置;
步骤143:消息服务装置确定相应的消息为CPM消息后,则确定自身需要执行的处理功能,具体作为参与功能服务器还是控制功能服务器;
步骤144至步骤146:当确定需要转换所述CPM消息时,则通过相应的消息转换装置进行消息的转换处理,具体的转换处理过程前面已经描述,在此不再赘述;
步骤147、148:消息转换装置将转换后的消息发送给网关,并通过所述网关转发;
步骤149、1410:所述消息转发成功后,网关及消息转换装置将会收到相应的响应;
步骤1411至步骤1414:消息转换装置将所述响应转换后依次向消息服务器装置及用户1返回响应消息。
进一步地,消息服务装置收到所述的融和消息后,还可以通过网关根据实施例一中确定转换消息类型的方法(4),即通过网关来获取消息接收用户的终端设备能力信息,获取成功后网关向消息服务装置返回所述获取到的消息,消息服务装置根据所述网关返回的信息确定所述收到的融合消息转换的消息类型,并交给消息转换装置执行转换。
实施例3
在该实施例3中,用户1作为非CPM用户使用非CPM消息服务(如SMS、MMS、Email、IMPS等),用户2则是CPM用户。
在该实施例中,相应的实现融合消息业务的处理过程如图15所示,具体包括:
步骤151:用户1使用非CPM消息服务发送非CPM消息给CPM消息服务用户2,例如用户1发送使用SMPP协议承载的短消息给用户2;
步骤152:用户1发送的非CPM消息通过其他通信网络触发到用户2归属域的CPM网关;
步骤153:网关将用户1发送的非CPM消息以及此消息的类型信息转发给CPM系统的消息服务装置;
步骤154;消息服务装置判断出此消息不是CPM消息,则获取消息接收方的服务设置和/或用户个性化设置,并根据消息接收方的服务设置或用户个性化设置确定将此消息转发给消息转换装置处理;
步骤155:消息服务装置将用户1发送的非CPM消息以及消息接收方的服务设置和/或用户个性化设置转发给消息转换装置,如果在消息接收方的服务设置和/或用户个性化设置中<dpib>元素的active属性设置为“true”,那么消息服务装置还应当将消息接收方的呈现信息转发给消息转换装置;
步骤156:消息转换装置根据用户2的服务设置和/或用户个性化设置和/或消息接收方的呈现信息和/或消息体中包含的媒体类型确定将消息转换成何种类型,然后将收到的消息转换成该类型,例如根据实施例1中的服务设置实例应将用户1发送的消息转换成CPM消息;
在该步骤中,如果用户2的服务设置中没有将CPM消息服务设置为优先级最高的消息服务,则消息服务装置需要根据服务设置、消息中包含的媒体信息类型和用户2的呈现信息中的至少一项将消息转换成其他的消息类型;且在转换时,消息转换装置可以将用户1发送的消息直接转换成用户2可以接收的消息类型,也可以首先将用户1发送的消息转换成CPM消息,再将CPM消息转换成用户2可以接收的消息类型;相应的具体的转换方案可以参考实施例1的描述,在此不再赘述;
步骤157:转换装置成功将用户1发送的非CPM消息转换后向消息服务装置返回成功响应,并将转换后的消息发送给消息转换装置;
步骤158:消息服务装置将CPM消息发送给CPM消息服务用户2;
步骤159:用户2成功接收了CPM消息,返回成功响应给消息服务装置;
步骤1510:消息服务装置将收到的成功响应转发给消息转换装置;
步骤1511:消息转换装置将收到的成功响应转换成用户1可以接收的消息形式;
步骤1512至步骤1514:消息转换装置将转换后的响应消息通过网关发送出去,在经过用户1所在域的归属通信网络发送给用户1。
在该实施例3中,需要说明的是,若消息转换装置收到消息转换装置发送的消息转换请求后,根据用户2的服务设置和/或用户服务设置和/或用户2的呈现信息和/或消息的媒体类型以及消息大小,判断出将所述收到的消息应以会话的形式下发,则在返回给消息服务装置的响应中包含消息下发方式、消息体内容、消息接收方和发送方的用户标识等必要信息;例如,当用户1发送的媒体内容超过SIP-MESSAGE协议的最大消息体大小限制时,通过建立会话方式传输媒体的信令流程图如图16所示,包括:
参见图16中的步骤8至步骤11所示,消息服务装置收到成功响应后通过SIP协议的INVITE请求向用户2发起建立会话请求就;用户2接受了消息服务装置的建立会话请求后向消息服务装置返回会话建立成功的响应200ok;会话建立成功后,消息服务装置根据消息体的媒体类型选择适当的协议向用户2传输媒体内容,所述适当的协议为MSRP协议或RTP协议;媒体传送结束后用户2通过SIP协议的Bye方法发起结束会话请求;消息服务装置向用户2返回会话结束的成功响应200ok。
在上述描述中,具体介绍了基于CPM系统实现融合消息业务的具体过程,在实现融合消息业务过程中,相应的消息需要以各种方式发送到CPM系统中,下面将对各种CPM消息及非CPM消息路由到CPM系统的实现方式进行描述。
目前,现有通信网络中消息服务器的消息路由方法主要有以下四种:
(1)通过路由信息来触发路由,例如,短消息服务等;
(2)通过用户签约信息触发路由,例如、IM服务、PoC服务等;
(3)用户使用MSISDN作为移动通信网络用户标识时,根据消息接收方用户标识的号码段触发路由,例如,短消息服务、多媒体消息服务等。
(4)使用DNS域名解析触发路由,例如,多媒体消息服务可以使用Enum DNS解析,Email服务可以使用Internet DNS解析。
基于上述几种消息触发方式,本发明提供的各实施例中,具体可以采用以下几种触发实施例将所述的CPM消息及非CPM消息路由到CPM系统:
触发实施例一
在该实施例一中,具体是采用注册的方式将实现融合消息业务的系统的信息注册到外部网络中用于保存路由信息的实体中。例如,可以扩展HLR/HSS中保存的信息,增加新的CPM网关的地址,以便于将相应的消息触发发送给CPM系统。短消息服务的处理流程中SMS-GMSC(短消息网关移动交换中心)向HLR/HSS查询路由信息,HLR/HSS在响应中返回CPM接入网关的E.164地址,SMS-GMSC根据响应中返回的地址,将短消息转发给相应的CPM接入网关,以触发到CPM系统。
其中,CPM接入网关的E.164地址可以在CPM用户向CPM系统注册时由CPM系统向HLR/HSS注册;相应的CPM用户向CPM系统的注册过程如图17所示,具体包括:
1、CPM用户使用终端通过SIP INVITE请求向IMS网络注册;
2、S-CSCF从HSS中获取IFC(Initial Filter Criteria,初始过滤标准);
3、S-CSCF根据IFC将CPM用户注册信息通知给CPM系统;
4、CpM系统向S-CSCF返回注册成功的响应;
5、CPM系统向HLR/HSS发送注册请求;
6、注册成功,HLR/HSS向CPM系统返回成功响应。
触发实施例二
在该实施例二中,在外部网络中保存路由信息的实体中直接配置保存所述实现融合消息业务的系统的信息。例如,在第三代移动通信网络中,设置HSS中存储的IFC(初始过滤规则),使其支持CPM服务,具体的CPM服务的IFC具体实例如表11所示:
表11
<?xml version=″1.0″encoding=″UTF-8″?><IMSSubscription xmlns:xsi=″http://www.w3.org/2001/XMLSchema-instance″xsi:noNamespaceSchemaLocation=″D:\\CxDataType.xsd″><PrivateID>IMPI1homedomain.com</PrivateID><ServiceProfile><PublicIdentity><Identity>sip:IMPU1homedomain.com</Identity></PublicIdentity><InitialFiIterCriteria><Priority>0</Priority><TriggerPoint><ConditionTypeCNF>1</ConditionTypeCNF><SPT><ConditionNegated>0</ConditionNegated><Group>0</Group><Method>INVITE</Method></SPT><SPT><ConditionNegated>0</ConditionNegated><Group>0</Group><Method>MESSAGE</Method></SPT></TriggerPoint><ApplicationServer> |
<ServerName>sip:CPMSyshomedomain.com</ServerName><DefaultHandling>0</DefaultHandling></ApplicationServer></InitialFilterCriteria></ServiceProfile></IMSSubscription> |
在该实例中,各种元素的定义可以参考3GPP规范29.228的相关描述;
在该表11中,<PrivateID>元素的值表示CPM签约用户的私有用户标识;<PublicIdentity>元素表示CPM签约用户的公有用户标识;<Priority>元素表示CPM服务的优先级,此处设置为最高优先级0;<ServerName>表示当IFC满足时,S-CSCF联系的应用服务器地址,此处设置为CPM系统的SIP URI地址。
当S-CSCF收到一个SIP请求时,首先初始化一个SIP会话,然后S-CSCF评估SPT并检查他们是否与到CPM系统的IFC匹配,如果匹配,则将请求转发到CPM系统。
触发实施例三
在该实施例三中,也是在外部网络中保存路由信息的实体中直接配置保存所述实现融合消息业务的系统的信息。其具体可以是根据消息接收方用户标识的号码段触发将消息发送到CPM系统,具体可以通过在消息服务器上扩展号码段配置的方法来实现;相应的引码段配置文件中可以包括如表12所示的各参数:
表12
起始MSISDN号 | 终止MSISDN号 | CPM系统地址 |
其中,参数“起始MSISDN号”到参数“终止MSISDN号”表示从[起始MSISDN号]到[终止MSISDN号]的所有MSISDN号码定义为一个具有相同属性的用户号段,例如[起始MSISDN号]设置为13901110000、[终止MSISDN号]设置为13901120000,则该号段包括的号码为13901110000~13901119999;如果起始和终止MSISDN相同,则为散号;在该实施例中,可以将CPM用户标识Tel URI地址的数字部分作为起始MSISDN号或终止MSISDN号。
CPM系统地址为CPM网关的地址,可以为E.164地址或者是IP地址,通过MAP或者SMPP协议实现消息的转发。
触发实施例四
在该实施例中,是在外部网络中保存路由信息的实体中保存所述实现融合消息业务的系统的信息与IP地址间的对应关系。其具体可以是使用DNS域名解析方法触发将消息发送到CPM系统,为此,需要建立相应的在主机名称与IP地址的映射文件中增加CPM系统的域名与CPM系统的IP地址之间的映射关系,该映射关系具体可以如表13所示:
表13
域名 | IP地址 |
CPMSys.homedomain.com | Ip:10.20.15.87 |
综上所述,本发明提供的一种实现融合消息通信的系统及方法的实施例,使得用户可以与使用其它任何消息服务的用户通信,用户无须从现有各种消息服务中做出选择,并有效解决了现有技术中存在的各种消息系统相对独立、重复建设的问题,功能重叠,用户体验差等问题。
以上所述,仅为本发明较佳的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到的变化或替换,部应涵盖在本发明的保护范围之内。因此,本发明的保护范围应该以权利要求的保护范围为准。
Claims (17)
1.一种无线通信网络中实现融合消息业务的方法,其特征在于,包括:
接收需要发送的消息,所述的消息为融合消息或非融合消息;
根据消息中承载的信息确定对应的用户信息,所述的用户信息包括融合消息与非融合消息之间的转换处理策略;
对所述消息,根据确定的用户信息进行转换处理,并发送经转换处理后的消息;
所述的用户信息包括用户的服务设置和/或用户的个性化设置,且所述根据确定的用户信息进行转换处理的转换处理为:根据所述用户的服务设置和用户的个性化设置中的至少一项,以及接收方用户的呈现信息、接收方用户的终端能力信息和消息中的消息体内容类型中的至少一项进行转换处理。
2.根据权利要求1所述的方法,其特征在于,所述的根据确定的用户信息进行转换处理具体包括:
所述消息为融合消息,根据所述的转换处理策略将所述的融合消息转换为非融合消息;
所述消息为非融合消息,根据所述转换处理策略将所述非融合消息转换为融合消息。
3.根据权利要求1所述的方法,其特征在于,在接收需要发送的消息后,所述的方法还包括根据所述用户信息确定所述消息是否需要进行转换处理的步骤。
4.根据权利要求1或2所述的方法,其特征在于,所述根据消息中承载的信息确定对应的用户信息,根据所述的用户信息进行转换处理包括:
根据所述消息中承载的接收方信息确定接收方对应的用户信息,根据所述的用户信息确定转换后的消息类型,并将所述消息转换为确定的转换后的消息类型对应的消息。
5.根据权利要求4所述的方法,其特征在于,所述用户信息包括是否需要保存收到的融合消息或非融合消息,所述的方法还包括:
根据所述的用户信息确定需要保存所述接收的需要发送的消息,并保存该消息或保存转换处理后的消息。
6.根据权利要求2所述的方法,其特征在于,所述发送经转换处理后的消息包括:
所述消息为融合消息,通过无线通信网络发送所述融合消息;或者,所述消息为非融合消息,通过网关及外部网络发送所述非融合消息。
7.根据权利要求1所述的方法,其特征在于,所述的用户信息具体包括:接收方设备可以接收的消息类型,接收方设备可以接收的各种非融合消息类型的优先级信息和从其他服务引擎中获取的接收方用户对应信息中的至少一项,且所述的根据确定的用户信息进行转换处理的转换处理为:根据所述接收方设备可以接收的消息类型,接收方设备可以接收的各种非融合消息类型的优先级信息和从其他服务引擎中获取的接收方用户对应信息中的至少一项进行转换处理。
8.根据权利要求1所述的方法,其特征在于,所述消息为融合消息,且所述融合消息中携带接收方标识,则所述的方法还包括:根据所述接收方标识判断所述收到消息的网络是否为接收方的归属网络,如果收到消息的网络是接收方的归属网络,则:
根据接收方对应的用户信息判断是否对该融合消息进行转换处理,若确定需要进行转换,则进一步根据所述用户信息将该融合消息转换为对应的非融合消息,并发送给外部网络,否则,直接在支持融合消息的无线通信网络内发送该融合消息。
9.根据权利要求1所述的方法,其特征在于,所述消息为融合消息,且所述融合消息中携带接收方标识,则所述的方法还包括:根据所述接收方标识判断所述收到消息的网络是否为接收方的归属网络,如果收到消息的网络不是接收方的归属网络,则:
判断该融合消息中携带接收方标识的类型,根据所述接收方标识类型信息获取接收方用户的终端能力信息,根据所述接收方用户的终端能力信息对所述的融合消息进行转换,并发送;或者,
判断该融合消息中是否包含控制信息,所述控制信息中记录着接收方接收消息类型的指示信息,若包含控制信息,则根据所述控制信息对所述的融合消息进行转换,并发送,若不包含控制信息,则直接发送所述消息。
10.根据权利要求1所述的方法,其特征在于,所述的消息为非融合消息后,则所述的方法还包括:根据非融合消息中的接收方标识,判断所述收到消息的网络是否为接收方的归属网络,其中,
如果收到消息的网络是接收方的归属网络,则根据接收方对应的用户信息判断是否对该非融合消息进行转换处理,若确定需要进行转换,则进一步根据所述用户信息将该非融合消息转换为对应消息类型的消息,将转换后的融合消息直接在支持融合消息的无线通信网络内发送,将转换后的非融合消息发送给外部网络,若确定无需进行转换,则直接将该非融合消息发送给外部网络;
如果收到消息的网络不是接收方的归属网络,则直接将该非融合消息发送给外部网络。
11.一种无线通信网络中实现融合消息业务的系统,其特征在于,包括消息服务装置、用户信息存储装置和消息转换装置,其中,
消息服务装置,用于接收需要发送的消息,所述的消息包括融合消息或非融合消息;还用于控制发送所述消息或转换处理后的消息;
用户信息存储装置,用于保存预先设置的用户信息,所述用户信息包括融合消息与非融合消息之间的转换处理策略;
消息转换装置,根据所述的转换处理策略对所述需要发送的消息进行转换处理;
所述的用户信息包括用户的服务设置和/或用户的个性化设置,所述消息转换装置,用于根据所述用户的服务设置和用户的个性化设置中的至少一项,以及接收方用户的呈现信息、接收方用户的终端能力信息和消息中的消息体内容类型中的至少一项进行转换处理。
12.根据权利要求11所述的系统,其特征在于,所述的消息服务装置还用于:
根据接收到的消息中承载的信息,以及所述承载的信息对应的用户信息确定是否需要对该消息进行转换处理,若确定需要则将根据用户信息确定的转换后的消息类型及该消息提供给消息转换装置。
13.根据权利要求11所述的系统,其特征在于,所述的系统还包括存储装置,用于在消息服务装置根据收到的消息中承载的信息,以及所述承载的信息对应的用户信息确定需要保存所述消息后,保存所述消息或者保存经消息转换装置转换处理后的消息。
14.根据权利要求11所述的系统,其特征在于,所述的系统还包括网关,用于发送消息转换装置转换后的非融合消息及消息服务装置收到的无需进行转换处理的非融合消息。
15.根据权利要求11所述的系统,其特征在于,所述的消息服务装置还与其他服务引擎通信,以获取在所述其他服务引擎中保存的信息。
16.根据权利要求11至15任一项所述的系统,其特征在于,所述的消息服务装置基于会话初始协议SIP与用户设备之间进行融合消息的交互。
17.根据权利要求11至15任一项所述的系统,其特征在于,所述的消息转换装置还用于:
将消息服务装置收到的消息转换为SMS消息;和/或,
将消息服务装置收到的消息转换为多媒体消息;和/或,
将消息服务装置收到的消息转换为电子邮件信息。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007100008145A CN101212719B (zh) | 2006-12-31 | 2007-01-12 | 一种无线通信网络中实现融合消息业务的方法及系统 |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200610167381 | 2006-12-31 | ||
CN200610167381.8 | 2006-12-31 | ||
CN2007100008145A CN101212719B (zh) | 2006-12-31 | 2007-01-12 | 一种无线通信网络中实现融合消息业务的方法及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101212719A CN101212719A (zh) | 2008-07-02 |
CN101212719B true CN101212719B (zh) | 2011-12-28 |
Family
ID=39612312
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2007100008145A Active CN101212719B (zh) | 2006-12-31 | 2007-01-12 | 一种无线通信网络中实现融合消息业务的方法及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101212719B (zh) |
Families Citing this family (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101854599B (zh) * | 2009-04-03 | 2015-07-22 | 中兴通讯股份有限公司 | 大融合ip消息传输方法及系统 |
CN101883322B (zh) * | 2009-05-05 | 2013-01-23 | 中兴通讯股份有限公司 | 向群组发送大消息模式融合ip消息的方法和系统 |
CN101998302B (zh) * | 2009-08-10 | 2014-07-16 | 中兴通讯股份有限公司 | 消息发送方法、装置、系统及用于融合业务系统的pf、cf和isf |
CN102006564B (zh) * | 2009-09-03 | 2014-08-13 | 中兴通讯股份有限公司 | 消息互通方法及融合业务系统 |
CN102137065B (zh) * | 2010-01-25 | 2014-02-12 | 中国移动通信集团公司 | 多网络应用通信方法、终端及系统 |
CN105701187B (zh) * | 2010-08-13 | 2019-04-26 | 北京环球国广媒体科技有限公司 | 流程整合服务器及利用其实现系统整合的方法 |
CN105701188B (zh) * | 2010-08-13 | 2019-04-26 | 重庆软维科技有限公司 | 流程整合服务器及利用其实现系统整合的方法 |
CN102143444B (zh) * | 2010-09-02 | 2014-01-01 | 华为技术有限公司 | 一种业务分发平台消息推送方法、相关设备及系统 |
CN102130910B (zh) | 2011-02-28 | 2015-04-29 | 华为技术有限公司 | Tcp代理插入和卸载方法及业务网关设备 |
CN102905231B (zh) * | 2011-07-30 | 2015-11-25 | 华为技术有限公司 | 实现内容分析的消息传播业务方法和系统 |
CN103327458A (zh) * | 2012-03-23 | 2013-09-25 | 中兴通讯股份有限公司 | 一种短信递送方法及系统 |
CN103368821A (zh) * | 2012-04-10 | 2013-10-23 | 中兴通讯股份有限公司 | 发送语音消息的方法及系统、融合消息服务器及客户端 |
CN105279033B (zh) * | 2014-07-22 | 2019-04-16 | Tcl集团股份有限公司 | Android平台下C++和Java通信的方法及系统 |
CN106506316A (zh) * | 2015-09-06 | 2017-03-15 | 中兴通讯股份有限公司 | 信息传输方法和装置 |
CN107770033A (zh) * | 2016-08-16 | 2018-03-06 | 中国移动通信有限公司研究院 | 一种多系统中的终端之间通信的方法及装置 |
CN108075904A (zh) * | 2016-11-16 | 2018-05-25 | 中兴通讯股份有限公司 | 群消息的传输方法和系统 |
CN109120502B (zh) * | 2017-06-26 | 2022-05-20 | 中兴通讯股份有限公司 | 用于多业务融合平台的通信方法、设备、系统及存储介质 |
CN108156069A (zh) * | 2017-12-26 | 2018-06-12 | 中兴通讯股份有限公司 | 一种融合消息系统及消息处理方法 |
CN111193661B (zh) * | 2020-04-09 | 2020-07-14 | 广州市玄武无线科技股份有限公司 | 一种基于企业通信渠道融合系统的管理方法及装置 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1264232A (zh) * | 1998-08-18 | 2000-08-23 | 朗迅科技公司 | 通用消息接发结构 |
CN1642117A (zh) * | 2004-07-07 | 2005-07-20 | 华为技术有限公司 | 一种基于软交换实现监听的方法 |
-
2007
- 2007-01-12 CN CN2007100008145A patent/CN101212719B/zh active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1264232A (zh) * | 1998-08-18 | 2000-08-23 | 朗迅科技公司 | 通用消息接发结构 |
CN1642117A (zh) * | 2004-07-07 | 2005-07-20 | 华为技术有限公司 | 一种基于软交换实现监听的方法 |
Non-Patent Citations (1)
Title |
---|
Jiangang et al..Terminal Capability Use Cases.《Open Mobile Alliance》.2006,第2~4页. * |
Also Published As
Publication number | Publication date |
---|---|
CN101212719A (zh) | 2008-07-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101212719B (zh) | 一种无线通信网络中实现融合消息业务的方法及系统 | |
US7526563B2 (en) | Interworking gateway and method | |
US8671156B2 (en) | Method and apparatus for providing communication history | |
US8327024B2 (en) | System and method for SMS/IP interoperability | |
US7991848B2 (en) | Method and apparatus for sending instant message disposition notification request and response in a converged-IP messaging service and system thereof | |
CN100499598C (zh) | 即时消息用户使用其它即时消息系统聊天室的方法及系统 | |
US20070208809A1 (en) | Group invitation | |
US20060053208A1 (en) | Group details of group services | |
CN101714170B (zh) | 一种基于xdms的群组管理系统及方法 | |
KR20080043264A (ko) | 통합 ip 메시징 서비스에서 메시지 스레드 관리 방법 및시스템 | |
CN101374118A (zh) | 一种消息互连的方法、系统及装置 | |
EP1738553A1 (en) | Method and system for providing information on a resource in a communication system | |
CN101325740A (zh) | 实现会话初始协议消息与短消息互通的方法、装置及系统 | |
CN101542989A (zh) | 群组通信 | |
CN101223746B (zh) | 寻呼模式消息收发 | |
CN100471150C (zh) | 建立订阅对话的方法及订阅用户事件的方法 | |
CN101355533B (zh) | 一种通信互连方法和设备 | |
KR20090087791A (ko) | 비통합메시징 서비스와 인터워킹하기 위한 통합메시징서비스 제공 시스템 및 방법 | |
CN101854597B (zh) | 大消息模式融合ip消息传输方法及系统 | |
KR101043696B1 (ko) | 인스턴트 메시지 서비스 시스템 및 이동통신 단말기, 및 그 서비스방법 | |
EP2301225B1 (en) | Methods, telecommunications node, and user equipment for transmission of user identifier | |
CN101047668B (zh) | 扩展信息发送方法 | |
CN100525257C (zh) | Ip多媒体子系统域与分组交换域多媒体消息互通的方法 | |
CN1878171B (zh) | 一种聊天室中阻塞信息通知的方法 | |
WO2009054614A1 (en) | Method for interworking between a cpm service and a non-cpm service |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant |