具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
本发明实施例提供富媒体通信业务的处理方法及终端设备和通信系统,可以降低不必要的网络资源和系统资源的消耗、节约终端的耗电量、增加待机时间,以下分别进行详细说明。
实施例一、一种富媒体通信业务的处理方法,流程图如图1所示,包括:
A1,第一终端发送呈现业务激活通知信息给第二终端;
本发明实施例中,具体的将呈现业务激活通知信息发送给第二终端的过程可以是:通过分组交换域控制信令发送呈现业务激活通知信息给所述第二终端;或者通过短消息发送呈现业务激活通知信息给所述第二终端;或者通过电路交换域控制信令发送激活通知信息给所述第二终端。
将呈现业务激活通知信息发送给第二终端的过程还可以为:
所述第一终端发送呈现业务激活通知信息给业务激活中心;
所述业务激活中心通过短消息或推送业务消息发送业务激活通知信息给所述第二终端。
所述可以理解的是,通知承载的消息还可能有多种常规实现方式,具体的实现方式不构成对本发明的限制。
A2,第一终端通过呈现业务获取所述第二终端的状态;
本发明实施例中所述第二终端的状态可以包括但不限于终端支持网络类型,终端在各个网络的注册状态、登陆状态、支持的业务能力等等。这里的登陆状态可以是在线、隐身、离线等等。呈现业务进行的表现形式可以是以列表形式向第一终端的用户显现或者以具有呈现(呈现业务)业务能力的网络地址本,如融合网络地址本(CAB)的形式实现,还可以采用类似于QQ、MSN等类似软件功能套件实现。
本发明实施例中,第一终端可以等待接收所述第二终端返回的激活结果后才执行步骤A2,也可以发送激活请求后,就执行步骤A2。
A3,第一终端根据所述第二终端的状态向所述第二终端发起的富媒体通信业务。
本发明实施例中,第一终端发送呈现业务激活通知信息给第二终端之后,若在预置的时间内未收到所述第二终端的返回的激活结果,则再次发送激活通知信息给所述第二终端。使得方案更加完善。
本发明方法实施例一中,第一终端发送呈现业务激活通知信息给第二终端;第一终端接收第二终端返回的激活结果;若所述激活结果为第二终端呈现业务激活成功,则第一终端通过呈现业务消息向所述第二终端发起的富媒体通信业务。在需要进行富媒体通信业务时,才开启相应的业务能力,可以有效的降低终端各种应用程序常对网络资源和系统资源的消耗,同时同等条件下降低终端的耗电量,增长终端待机时间。
实施例二、一种富媒体通信业务的处理方法,流程如图如2所示,包括:
B1,第二终端接收第一终端发送的呈现业务激活通知信息;
具体的呈现业务的通知方式参见实施例一步骤A1中的描述。
B2,第二终端根据所述呈现业务激活通知信息进行呈现业务的激活;
本实施例中,步骤B2之后可以向所述第一终端返回激活结果,以使得第一终端可以选择是否发起呈现业务。
可以理解,本发明实施例中可以在激活呈现业务的过程中,判断分组交换域是否已经激活,如若未激活,则激活分组交换域。
激活分组交换域。
B3,若呈现业务激活成功,则通过呈现业务向所述第一终端反馈第二终端的状态;
B4,通过呈现业务消息与所述第一终端进行的富媒体通信业务。
本发明实施例中,所述步骤B2,进行呈现业务的激活之前还可以包括:
对呈现业务的激活的可行性进行判断,若判断结果为不能完成激活,则直接进行B4向所述第一终端返回激活结果的步骤,所述返回的激活结果指示激活失败。
所述进行可行性判断的依据可以包括:终端的处理能力和/或终端的网络接入能力还可以是以及事先制定的规则等。
第二终端根据所述呈现业务激活通知信息进行呈现业务的激活之前还可以包括:
向用户询问是否允许激活呈现业务,若用户选择拒绝激活,则直接执行所述B3向所述第一终端返回激活结果的步骤,所述返回的激活结果指示激活失败。
通过第二终端用户控制的参与,使得本发明方法用户体验更好,更加贴近用户的需求。
实施例三,一种富媒体通信业务的处理方法,其特征在于,包括:
C1,富媒体业务服务器接收第一终端的富媒体通信业务请求;
C2,业务服务器向第二终端发送的呈现业务激活通知信息;
C3,根据所述呈现业务激活通知信息进行呈现业务的激活;
C4,第二终端向所述富媒体业务服务器返回激活结果;若激活结果为激活成功,则所述富媒体业务服务器的控制所述第一终端和所述第二终端进行的富媒体通信业务。
实施例三将富媒体业务服务器引入激活的流程,由富媒体业务服务器发送激活请求进行激活控制,使得本发明激活方法与富媒体通信业务进一步融合。
下面结合具体应用对本发明进行进一步描述。
本发明实施例中,终端可以不保持分组交换域(PS域)一直在线,而是在终端启动相应业务,或者通信对端具有相应的业务呼叫请求时,激活相应的分组域。本实施例是富媒体通信业务在呈现业务基础上实现,通信的发起方,即第一终端在向通信对端,即第二终端发起富媒体通信呼叫之前,希望通过呈现业务来获得对端的能力,但是此时通信对端(UEB)的状态是没有在线,无法显示其第二终端的富媒体通信能力。
实施例四,一种呈现业务激活的方法,如图如4所示,本方法提供的激活对端呈现业务的方法为富媒体通信业务提供支持,流程示意图如图4所示包括:
步骤D1:第一终端向通信网络发送通知,通知第二终端呈现业务上线。
在此,第一终端向第二终端发送的用于通知激活呈现业务能力的消息可以但不限于为以下的消息:短消息、推送(Push)消息、非结构化补充数据业务(Unstructured Supplementary Service Data,简称USSD)消息、信令消息(如:Facility)等。
步骤D2:通信网络将该通知传递至第二终端。
通信网络接收到第一终端发送的用于通知第二终端激活呈现业务的通知后,将该通知下发至第二终端。比如:
当第一终端、第二终端属于同一个移动交换中心时,由该移动交换中心将该通知进行中继转发。
当第一终端、第二终端属于不同的移动交换中心时,则由第一终端所属的移动交换中心接收到该通知后,将其传递到第二终端所属的移动交换中心,然后再由该移动交换中心下发至其覆盖范围内的第二终端。
步骤D3:第二终端接收该通知,并根据通知激活呈现业务。
第二终端接收到该通知后,获知当前第一终端请求其激活呈现业务,第二终端可以在接收到该通知之后,发起对呈现业务的激活。
另外的,为了优化第二终端进行呈现业务激活,避免当第二终端或其所在的网络不支持的情况下第二终端执行激活呈现业务操作给网络和终端而带来不必要的处理,第二终端可以在接收到该激活通知后,判断本终端是否支持呈现业务(即是否支持激活呈现业务域)、本终端所在的网络是否允许使用呈现业务,当本终端支持呈现业务、本终端所在的网络允许使用呈现业务时,才执行激活呈现业务域的操作。
并且,实际应用中,终端用户可以能择是否同意接受该呈现业务的请求和是否进行呈现业务激活。
由于富媒体通信套件中的呈现业务通信能力是基于分组交换域的,所以,在第二终端激活呈现业务的时候,需要同时完成分组交换域(PS域)激活。即,在第二终端完成呈现业务激活后,第二终端的分组交换域处于激活状态,第一终端可以同第二终端进行基于分组交换域的富媒体通信业务。
由上可见,由于应用本实施例方法,第二终端可以根据基于呈现业务发起方的通知,被动激活呈现业务,并可以基于呈现业务相关信息,进行富媒体通信的相关能力通信。实现了富媒体通信中,无需长时间保持呈现业务在线即可根据呈现信息发起相应的富媒体通信业务。
下面以第一终端需要发起与第二终端的富媒体通信业务的情况,第一终端通过信令消息通知第二终端激活呈现业务的情况为例,对实施例四中激活呈现业务的方法进行具体描述。
实施例五,一种呈现业务激活的方法,流程如图5所示,包括:
步骤E1,终端21生成信令消息,本实施例中所述信令消息可以为Facility消息,并在信令消息(如Facility消息)中携带通知激活终端24激活呈现业务的信息,使得终端24可以根据该信息获知当前需要执行呈现业务的操作(比如可以在消息中携带一个特定的比特值,使得终端24按照预先确定的协议,根据该特定的比特值,可以获知当前需要执行呈现业务的操作);终端21将所生成的信令消息(如Facility消息)发送至终端21所属的移动交换中心22。
本实施例中提供以下一种较优的用于通知激活终端24激活呈现业务的信息的结构,该信息结构包括:业务标识、消息类型、流码、业务数据信息。其中:
业务标识,用于表示当前消息为通知激活呈现业务的消息,在本实施例中规定其占用3个字符,协议该标识取值为abc时,表示当前消息为通知激活呈现业务的消息;
消息类型,用于标识该消息的类型,在本实施例中规定其占用1个字符,协议约定:当其取值为1时表示该消息为请求消息,当其取值为0时表示该消息为响应消息;
流码,用于标识流码率,在本实施例中规定其占用1个字符,取值范围可以为1、2......9的任一;
状态码,用于标识终端的状态,在本实施例中规定其占用2个字符,协议约定当其取值为01时表示激活,当其取值为02时表示终端不支持呈现业务激活,当其取值为03时,表明终端用户拒绝激活操作,当其取值为04时,表示终端所在的网络不支持呈现业务激活,其他的取值可以作为扩展使用;
业务数据,用于携带扩展数据,在本实施例中不规定其长度。
根据上述提供的信息格式以及取值协议,在步骤E1中,终端21向移动交换中心22发送其中携带的信息体为“abc1101”的信令消息(如Facility消息)。
步骤E2,移动交换中心22将收到的携带的信息体为“abc1101”信令消息(如Facility消息)发送到终端24所属的移动交换中心23。
步骤E3,移动交换中心33解析Facility消息,根据其携带的信息(“abc1101”),可以获知此Facility消息携带激活呈现业务请求,并将Facility息中所封装的信息(“abc1101”)提取出来重新封装在信令消息(在本实施例中可以但不限于:facility消息)中,下发到终端24。
相应的,终端24接收到移动交换中心23下发的信令消息(比如使用facility消息封装,携带信息“abc1101”的消息)后,解析其携带的信息(“acb1101”),获知当前的消息为用于请求激活呈现业务的消息,进行相应的激活呈现业务的操作。
为了高可靠传输,终端24在收到业务请求信息后,可以继续进行以下的流程进行确认。
步骤E4:终端24生成响应消息并在所生成的消息,如信令消息(如Facility消息)中携带以下信息“acb0101”后,向移动交换中心23发送。
步骤E5:移动交换中心23将收到的响应消息转发至移动交换中心22。
步骤E6:移动交换中心22将该响应消息转发至终端21。
终端21在接收到该响应消息后,从中解析出该响应的信息:“acb0101”,获知终端24已正确收到了业务请求,并且同意激活呈现业务。
为了防止由于信令在传输过程中的丢失而造成呈现业务激活不成功,可以进行以下的规定:如果终端21在一定时间后未收到业务请求回复信息,终端21将重新启动步骤E1。
另外的:终端24返回的响应消息中还可以携带多种信息,例如:一定条件(时间段内)拒绝请求,这样终端21在这一条件下不再重发(如“03”拒绝激活请求,终端21不再重发)。
下面以通过短消息通知第二终端激活呈现业务的情况为例,对实施例四中激活呈现业务的方法进行具体描述。
实施例六,一种呈现业务激活的方法,流程如图6所示,包括:
步骤F1:终端31生成短消息(Short Message Service,简称SMS)并在该短消息中携带:通知激活终端32激活呈现业务的信息,使得终端32可以根据该信息获知:当前需要执行呈现业务的激活操作。终端31将所生成的短消息通过短消息中心,发送至终端32。
根据短消息协议,可以通过一个特定的标识(如呼叫业务标识(Teleserviceid)、端口号(port number),标识的名称视不同协议而有所不同)来区分短消息所承载的业务,如:通常所见的短消息,Push业务,语音邮件通知等。这些业务的特定标识的值不同,终端依此区分,并对收到的短消息进行不同的应用处理。在本实施例中,可以利用如上所述特定标识值中的保留部分,将该特定标识取一特定的值来指明该短消息用于请求对端终端激活呈现业务。
步骤F2:终端32从短消息中解析出需要激活的业务标识,获知当前的短消息为协议消息:用于通知激活呈现业务。该短消息可以不必要向用户显示,而进行呈现业务激活。
在图6呈现业务激活方法的基础上增加了业务激活中心42,由业务激活中心42中继处理用于通知终端53激活呈现业务的短消息。
实施例七,一种呈现业务激活的方法,如图7所示,该流程包括:
步骤G1:终端41生成短消息,并在该短消息中携带通知激活终端43激活呈现业务的信息,使得终端43可以根据该信息获知当前需要执行呈现业务激活的操作,并且在该短消息中添加业务激活中心42的地址,然后终端41将所生成的短消息发送至业务激活中心42。
步骤G2:业务激活中心42通过短消息向终端43发送该通知激活终端43激活呈现业务的信息。
步骤G3:终端43解析该短消息,根据该短消息中的地址——业务激活中心42的地址,获知当前的短消息来自业务激活中心42,该短消息用于业务激活处理,并且根据该短消息内携带的具体信息内容,可以获知当前短消息用于请求激活呈现业务。此时,可以不向用户显示具体的消息。
在本方案中。业务激活中心42可以具体和短消息中心相连,即可以理解为短消息中心将业务激活中心42逻辑上看作一个增值业务服务器,并为业务激活中心42分配一个源发送地址(可以但不限为OOA)。终端43可以根据该源发送地址,判定此短消息来自业务激活中心,并进行相应的处理。
下面以通过Push消息通知第二终端激活呈现业务域的情况为例,本发明实施例四激活呈现业务的方法进行具体描述。
实施例八,一种呈现业务激活的方法,流程如图如8所示,包括:
步骤H1:终端51生成激活消息,并在该激活消息中携带通知终端54激活呈现业务的信息,使得终端54可以根据该信息获知当前需要执行激活呈现业务的操作,并且在该激活消息中添加业务激活中心52的地址,然后终端51将所生成的短消息发送至业务激活中心52。
这里的业务激活中心52既可以是专门的服务器,也可以是一般的业务服务器。当业务激活中心52是专门服务器时,终端51需要发送专门的业务请求消息(如使用短消息承载);当其是一般的业务服务器时,其可以将终端51发起业务(如富媒体通信业务)的过程同时看作是业务请求,即,无需终端51发送专门的业务请求消息即可自动进入下述流程。
在本实施例中,Push消息可以使用其中的应用标识(app-id)的取值来标识当前的Push消息为用于通知对端终端执行激活呈现业务的消息。
步骤H2:业务激活中心52充当推送发起者(PUSH Initiator,简称PI),经推送网关(Push Proxy Gateway,简称PPG)向终端54发送该Push消息。
步骤H3:终端54从Push消息中解析获取当前的Push消息为:请求本终端执行激活呈现业务的消息。
可以理解,本发明实施例激活呈现业务的过程也可以通过电路交换域实现。例如:在进行基于分组交换域(PS域)的富媒体通信会话前,存在一个电路域的语音电话正在进行,此时,可以借助该语音会话实施如下两种方法,实现激活呈现业务的功能。
下面以第一终端通过DTMF消息通知第二终端激活呈现业务的情况为例,对激活呈现业务域的方法进行具体描述。
实施例九,一种呈现业务激活的方法,本实施例中,终端61与终端64正在进行CS会话过程,终端61发起基于分组交换域(PS域)的富媒体通信会话。由于终端61发起基于分组交换域(PS域)的富媒体通信会话,其在发起时完成呈现业务的激活,但是由于终端64没有驻留在分组交换域(PS域),同时未激活呈现业务,因此,需要进行以下的流程(见图6所示),流程如图如9所示,包括:
步骤J1:终端61生成DTMF消息,并在DTMF消息中携带通知激活终端64激活呈现业务的信息,使得终端64可以根据该信息获知当前需要执行呈现业务的操作(比如可以在消息中携带一个特定的比特值,使得终端64按照预先确定的协议,根据该特定的比特值,可以获知当前需要执行呈现业务的操作);终端61将所生成的DTMF消息发送至终端61所属的移动交换中心62。
本方案提供以下一种较优的用于通知激活终端64激活呈现业务域的信息的结构,该信息结构包括:业务标识、消息类型、流码、业务数据信息。其中:
业务标识,用于表示当前消息为通知激活呈现业务域的消息,在本方案中规定其占用3个字符,协议该标识取值为abc时,表示当前消息为通知激活呈现业务的消息;
消息类型,用于标识该消息的类型,在本实施例中规定其占用1个字符,协议约定:当其取值为1时表示该消息为请求消息,当其取值为0时表示该消息为响应消息;
流码,用于标识流码率,在本方案中规定其占用1个字符,取值范围可以为1、2......9的任一;
状态码,用于标识终端的状态,在本实施例中规定其占用2个字符,协议约定当其取值为01时表示激活,当其取值为02时表示终端不支持呈现业务激活,当其取值为03时,表明终端用户拒绝激活操作,当其取值为04时,表示终端所在的网络不支持呈现业务激活,其他的取值可以作为扩展使用;
业务数据,用于携带扩展数据,在本实施例中规定其不定长。
根据上述提供的信息格式以及取值协议,在流程J1中,终端31向移动交换中心62发送其中携带的信息体为“abc1101”的双音多频(Dual Tone MultiFrequency,DTMF)消息。
步骤J2:移动交换中心62将收到的DTMF消息(“abc1101”)发送到终端64所属的移动交换中心63。
步骤J3:移动交换中心62将收到的DTMF消息(“abc1101”)中的信息(abc1101)提取出来,封装成包含该信息(abc1101)的信令发送到终端64所属的移动交换中心63。
步骤J4:移动交换中心63将该DTMF消息转发至终端64。
终端64接收到移动交换中心63下发的DTMF消息(携带信息“abc1101”的消息)后,从中解析出其携带的信息(“acb1101”),获知当前的消息为用于请求激活呈现业务的消息,进行相应的激活呈现业务的操作:直接执行激活呈现业务操作;或者,在判断本终端是否支持呈现业务激活、本终端所在的网络是否支持激活呈现业务后,当上述的判断结果均为“是”的情况下,执行激活呈现业务域操作;或者,在判断本终端是否支持呈现业务激活、本终端所在的网络是否支持激活呈现业务、本终端是否同意激活呈现业务后,当上述的判断结果均为“是”的情况下,才执行激活呈现业务操作。
步骤J4也可以替换为步骤J5:移动交换中心63解析DTMF消息,根据其携带的信息(“abc1101”),可以获知此DTMF消息携带激活呈现业务请求,并将DTMF消息中所封装的信息(“abc1101”)提取出来重新封装在信令消息(在本实施例中可以但不限于:facility消息等)中,下发到终端64。
相应的,终端34接收到移动交换中心63下发的信令消息(比如使用facility消息封装,携带信息“abc1101”的消息)后,解析其携带的信息(“acb1101”),获知当前的消息为用于请求激活呈现业务的消息,进行相应的激活呈现业务的操作,其具体操作见上所述。
在步骤J5中,移动交换中心63将所接收到的DTMF消息中携带的信息重新封装为诸如facility消息等的信令消息,而不是采用DTMF消息的封装形式下发至终端64,可以使得终端64对该消息的接收,不对当前的CS会话产生不必要的干扰。
同理,移动交换中心63,可以将接收到的信令消息转发到终端64,
移动交换中心63,可以将接收到的信令消息中的信息封装为DTMF消息发至终端64。
为了高可靠传输,终端64在收到业务请求信息后,可以继续进行以下的步骤:回复确认信息:
步骤J6:终端64生成DTMF响应消息(其还可以为:Facility或其它消息,即J7)并在所生成的消息中携带以下信息“acb0101”后,向移动交换中心63发送。
步骤J8:移动交换中心63将收到的DTMF消息(其还可以为:Facility或其它消息)转发至移动交换中心62。
步骤J9:移动交换中心63将收到的DTMF消息封装为信令消息(其还可以为:Facility或其它消息封装为DTMF消息)转发至移动交换中心62。
步骤J10:移动交换中心62将该DTMF响应消息转发至终端61。
终端61在接收到该DTMF响应消息后,从混音中解析出该DTMF响应信息的信息:“acb0101”,获知终端64已正确收到了业务请求,并且同意激活。
步骤J10也可以替换为步骤J11:
步骤J11:移动交换中心62解析该DTMF响应消息,并将DTMF消息中所封装的信息(“abc0101”)提取出来重新封装在信令消息(可以但不限于:facility消息等)中,下发到终端61。
终端61在接收到该信令消息(比如使用facility消息封装,携带信息“abc0101”的消息)后,解析出该DTMF响应信息的信息:“acb0101”,获知终端64已正确收到了业务请求,并且同意激活。
在步骤J11中,移动交换中心62将所接收到的DTMF响应消息中携带的信息重新封装为诸如facility消息等的信令消息,而不是采用DTMF消息的封装形式下发至终端61,可以使得终端61对该消息的接收不对当前的CS会话产生不必要的干扰。
同理,还可以移动交换中心62转发信令消息(如Facility消息)至终端61;
移动交换中心62将信令消息(如Facility消息)重新封装为DTMF消息后发至终端61。相应的处理方法同上类似。
为了防止由于信令在传输过程中的丢失而造成呈现业务激活不成功,可以进行以下的规定:如果终端61在一定时间后未收到业务请求回复信息,终端61将重新启动步骤J1。
另外的:终端64返回的响应消息中还可以携带多种信息,例如:一定条件(时间段内)拒绝请求,这样终端61在这一条件下不再重发(如“03”拒绝激活请求,终端61不再重发)。
本方案以通过电路域呼叫建立(Setup)消息通知第二终端激活呈现业务域的情况为例,,对激活呈现业务域的方法进行具体描述。
实施例十,一种呈现业务激活的方法,终端71与终端74正在进行CS会话过程,终端71发起CSI业务。由于终端71发起CSI业务,其在发起时完成呈现业务域的激活,但是由于终端74没有驻留在呈现业务域,即未激活呈现业务域,需要进行呈现业务的激活,流程如图10所示,包括:
步骤K1:终端71向被叫终端74发送Setup消息(该消息先到达移动交换中心72),并在其消息中的用户到用户(user to user)字段中按照一定的协议格式携带协议数据,协议数据可以表示出业务的类型——当前的消息用于通知被叫终端激活呈现业务。
步骤K2:移动交换中心72收到该Setup消息后,向被叫终端74所属的移动交换中心73发起呼叫操作,发送包括初始地址的与承载无关的呼叫控制协议消息(BICC_IAM消息),并在该消息中携带user to user字段数据。
步骤K3:移动交换中心73收到BICC_IAM消息后,向被叫终端74发送Facility消息,并携带user to user字段数据。
步骤K4:终端74收到该Facility消息,并解析出user to user字段数据中的封装协议,得到相应的业务数据内容,获知当前终端71请求本终端激活呈现业务,并根据请求执行相应的操作:直接执行激活呈现业务操作;或者,在判断本终端是否支持呈现业务激活、本终端是否同意激活呈现业务、以及本终端所在的网络是否支持激活呈现业务后,当上述的判断结果均为“是”的情况下,执行激活呈现业务操作。
在终端74接收到该Facility消息后,终端74向主叫终端71发送拆线请求消息(disconnect消息)以释放由于当前Setup消息而建立的资源连接,并携带终端74成功、或失败接收user to user数据的原因值。
步骤K5:移动交换中心73收到终端74的拆线请求消息后,向移动交换中心72发送与承载无关的呼叫控制协议释放消息(BICC_Release消息),同时携带终端74成功、或失败接收user to user数据的原因值。
步骤K6:移动交换中心72收到移动交换中心73的BICC_Release消息后,向终端71发起拆线请求消息(disconnect消息),同时携带终端74成功、或失败接收user to user数据的原因值。
步骤K7:终端71收到拆线请求消息后,进行拆线操作,并根据拆线请求消息中携带的其原因值分析,可以获知到终端74是否正确接收到user to user字段中的封装协议数据。为了使得拆线流程更加完善,终端71还可以在拆线完成后,向移动交换中心72返回释放(Release)消息,通知其拆线完成的结果。
步骤K8:移动交换中心72收到Release消息后,向移动交换中心73发送与承载无关的呼叫控制协议释放完成消息(例如:BICC_release_complete消息),并携带原因值——拆线完成。
步骤K9:移动交换中心73接收到BICC_release_complete消息后,向终端74发送拆线消息(disconnect消息),并携带原因值——拆线完成,终端74通过其原因值了解到对端应答拆线完成。
由上可见,利用本实施例的方法,终端71可以通过发送Setup消息通知终端74激活呈现业务,终端74可以由该通知触发其激活呈现业务的操作,从而实现了终端74的被动激活呈现业务。
以上所有实施例中提到的呈现业务,可以是驻留在终端上的呈现业务客户端,也可以是具备呈现业务功能的其它客户端,例如具备呈现业务能力的地址本。
上述本发明实施例方法在实际应用中,不需要一直使用分组交换域(PS域)来进行富媒体通信业务。同时,对于呈现信息也不需要一直关注。本发明方案,在富媒体通信业务中,提供技术方案,使得终端不需一直保持分组交换域激活,也不用一直保持呈现业务在线。而是在需要相应的业务服务时,启用相应的业务功能。可以有效的降低同等条件下终端的耗电量,增长同等条件下的终端待机时间。
本发明实施例提供富媒体通信业务的处理方法还可以通过富媒体业务服务器进行对端呈现业务的激活。
实施例十一、一种富媒体通信业务的处理方法,流程如图11所示,包括:
S1,富媒体业务服务器接收第一终端的富媒体通信业务请求;
S2,富媒体业务服务器向第二终端发送的呈现业务激活通知信息;
S3,第二终端根据所述呈现业务激活通知信息进行呈现业务的激活;
S4,第二终端向所述富媒体业务服务器返回激活结果;若激活结果为激活成功,则在所述富媒体业务服务器的控制下通过呈现业务消息与第一终端进行的富媒体通信业务。
实施例十一与上述方法实施例的区别在于通过富媒体业务服务器完成对端的激活,激活的过程中,对于富媒体业务的发起方透明。简化了呼叫发起方终端的复杂度。降低了终端的生产成本。
本发明实施例中,对于富媒体业务也可以不依赖于呈现业务实现,具体如下实施例。
实施例十二、一种富媒体通信业务的处理方法,流程图如图12所示,包括:
T1,第一终端向第二终端发起富媒体业务通信;
T2,所述第一终端通知第二终端本次通信请求使用的富媒体通信能力;
该激活通知至少包括:
所要激活的富媒体通信通信能力标识——用于标识所要激活的富媒体通信相关通信能力;
该激活通知还可以包括:
激活标识——标识该通知用于富媒体通信业务激活;
激活通知源地址——标识第一富媒体通信客户端的身份(让第二富媒体通信客户端知道这次激活是为了和谁进行富媒体通信通信);
序列号——区别不同的通知,同时,在需要第二富媒体通信客户端回复时,用序列号标识回复的是哪一条通知。
由进行通知的主体不同,向第二富媒体通信客户端发送激活通知可有下述不同方法:
第一富媒体通信客户端使用带外通知的方式,直接向第二富媒体通信客户端发送通知。具体的承载方式可以多种,前面实施例提到的方法这里同样适用。
第一富媒体通信客户端请求发起至第二富媒体通信客户端的相应会话,富媒体通信服务器来触发向第二富媒体通信客户端的激活通知。
相关激活通知的承载可以多样,前面实施例中提到的方法这里同样适用。
T3,所述第二终端接收所述通知,激活相应的富媒体通信能力;并向所述第一终端返回激活结果;
本实施例中,第二终端通过解析所述通知可以获知所要激活的相应能力;进行相应能力的激活操作。在进行激活操作前,第二富媒体通信客户端还可以进行如下操作:
1.判断相关业务能力,本终端是否具备;
2.判断相关业务能力终端所处网络是否具备;
3.判断是否同意为所述第一终端激活相应得业务能力。
在上述判断都为是的情况下,第二终端才进行激活操作。
本实施例中,所述第二终端激活响应的富媒体通信能力的过程中还可以包括:
所述第二终端激活分组交换域。
T4,若所述激活结果为激活成功,则所述第一终端和第二终端进行富媒体通信。
所述第二终端向第一终端返回的激活结果可以包括;是否成功处理激活通知的相应能力激活;
若激活失败,所述激活结果可以包括:处理失败的原因;激活某种能力失败后还可以返回所述第二终端支持的富媒体能力,用于进行媒体协商。
具体返回的通信能力的方式可以携带现在可用的能力列表。供对方选择第二终端当前可用能力进行富媒体通信会话。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成,该程序可以存储于一计算机可读存储介质中,存储介质可以包括:ROM、RAM、磁盘或光盘等。
实施例十三,一种终端设备1300,包括:激活通知发送单元1310、激活结果接收单元1320和富媒体业务处理单元1330;
激活通知发送单元1310,用于发送呈现业务激活通知信息给第二终端;
激活结果接收单元1320,用于第一终端接收第二终端返回的激活结果;
富媒体业务处理单元1330,用于通过呈现业务获取所述第二终端的状态;并根据所述第二终端的状态向所述第二终端发起的富媒体通信业务。本发明实施例中,也可以不包含激活结果接收单元1320,即终端无需接收激活结果就可以尝试发起呈现业务。当然,在收到激活结果,确认对端呈现业务激活后再发起业务显然可以使得本发明流程更加优化。
实施例十四,一种终端设备1400,包括:激活通知接收单元1410、激活单元1420、激活结果反馈单元1430和富媒体业务处理单元1440;
激活通知接收单元1410,用于接收第一终端发送的呈现业务激活通知信息;
激活单元1420,用于根据所述呈现业务激活通知信息进行呈现业务的激活;
激活结果反馈单元1430,用于向所述第一终端返回激活结果;
富媒体业务处理单元1440,若呈现业务激活成功,则通过呈现业务向所述第一终端反馈第二终端的状态;并接收所述第一终端的请求与所述第一终端进行的富媒体通信业务。
本发明实施例中,也可以不包含激活结果反馈单元1430,即终端无需反馈激活结果而直接发起呈现业务。
实施例十五,一种通信系统,包括:富媒体业务服务器1510、第一终端1520和第二终端1530;
所述第一终端1520用于向富媒体业务服务器发送富媒体通信业务请求;并在富媒体业务服务器的控制下与第二终端1530进行富媒体通信;
所述富媒体业务服务器1510用于接收第一终端1520的富媒体通信业务请求;向第二终端1530发送的呈现业务激活通知信息;接收第二终端1530的激活结果,若激活结果为激活成功,则控制所述第一终端1520和第二终端1530进行富媒体业务通信;
所述第二终端1530根据所述呈现业务激活通知信息进行呈现业务的激活;向所述富媒体业务服务器1510返回激活结果;若激活结果为激活成功,则在所述富媒体业务服务器1510的控制下通过呈现业务消息与第一终端1520进行的富媒体通信业务。
实施例十六,一种通信系统,包括:第一终端1610和第二终端1620;
第一终端1610用于向第二终端1620发起富媒体业务通信;通知第二终端1620本次通信请求使用的富媒体通信能力;并接收第二终端1620的激活结果,若激活结果为激活成功,则与第二终端1620进行富媒体通信业务。
所述第二终端1620,用于接收所述第一终端1610的通知,激活相应的富媒体通信能力;并向所述第一终端1610返回激活结果;并在激活结果为激活成功后,与第一终端1610进行富媒体通信业务。
本发明实施例提供的终端设备和通信系统的可以运行的方法,可参考上文对本发明提供的提供多个富媒体通信业务处理方法和呈现业务激活方法实施例的描述,在此不再重复。
以上对本发明实施例所提供的富媒体通信业务的处理方法及终端设备和通信系统进行了详细介绍,其中:
本发明方法实施例中,第一终端发送呈现业务激活通知信息给第二终端;第一终端接收第二终端返回的激活结果;若所述激活结果为第二终端呈现业务激活成功,则第一终端通过呈现业务消息向所述第二终端发起的富媒体通信业务。在需要进行富媒体通信业务时,才开启相应的业务能力,可以有效的降低终端各种应用程序常对网络资源和系统资源的消耗,同时同等条件下降低终端的耗电量,增长终端待机时间。
本文中应用了具体个例对本发明的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本发明的方法及其核心思想;同时,对于本领域的一般技术人员,依据本发明的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本发明的限制。