本申请要求于2006年4月18日提交中国专利局、申请号为200610035050.9、发明名称为“通信系统中协商语音编解码格式的方法及系统”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
背景技术
采用码分多址(CDMA)调制技术的移动通信系统采用软交换架构,并使用IP承载方式进行语音数据传输。
在软交换架构下,进行通信的双方在呼叫的建立过程中需要进行语音编解码格式(Codec)的协商。现有技术中的协商过程可简单归结为下列步骤:
1、主叫用户发起呼叫请求,同时向被叫用户传递主叫用户所支持的编解码格式列表CodecListA(Codec1、Codec2、Codec3...),及主叫用户推荐的编解码格式,例如Codec1;
2、被叫用户收到来自主叫用户的编解码格式列表后,从CodecListA中找到一个能够支持的语音编解码格式,并指定给主叫用户使用该编解码格式。被叫用户在选择被叫方使用的编解码格式时,会优先考虑主叫用户所推荐的编解码格式,如上面的Codec1;
被叫用户的选择有下面三种情况:
A、如果被叫用户选用主叫用户所推荐的优选编解码格式(如都是Codec1),即主被叫编解码格式一致,那么主叫用户到被叫用户的话音通路中不使用语音编解码器,这是理想的情况。
B、如果被叫用户没有选用主叫用户所推荐的编解码格式(被叫用户不支持主叫用户推荐的语音编解码格式,如上述的Codec1),而是选用了主叫用户所支持的编解码格式列表CodecListA中的某个非优选编解码格式(如Codec2),那么通信系统中的移动交换系统将向主叫用户发起一个更改流程,命令主叫用户更改编解码格式为Codec2。这种情况下主被叫编解码格式一致,主叫用户到被叫用户的话音通路中不使用语音编解码器。但比A情况中多了一个针对主叫用户的编解码格式更改流程。
C、如果被叫用户没有选用主叫用户所支持的编解码格式列表CodecListA中的任何一个编解码格式,例如被叫用户选用了Codec9,而Codec9不在主叫用户所支持的编解码格式列表CodecListA之内,那么通信系统将在主叫用户和被叫用户之间插入一个语音编解码器,以实现主、被叫间不同编解码格式语音流的转换。
可以看出,协商主要由主叫用户、被叫用户和通信系统中的移动交换系统(例如移动交换中心(MSC或MSCe))来交互完成。对于上述情况B,现有技术中的流程至少包括下列步骤:
1、主叫用户发起呼叫请求,由该呼叫请求引发的到MSCe的信号中携带了主叫用户支持的语音编解码格式列表,例如CodecListA,并且在该列表中指定了优选语音编解码格式(例如Codec1),目的是指示期望使用该优选语音编解码格式建立承载;
2、MSCe接收到所述信号后,利用优选语音编解码格式(即Codec1)建立承载,具体建立过程为:MSCe向媒体网关(MGW)发送建立主叫承载端点请求,MGW收到该请求后利用Codec1建立主叫承载端点后向MSCe返回建立成功信息;
3、MSCe向被叫用户发起寻呼;
4、被叫用户向MSCe发送寻呼响应信号,该响应信号中携带了被叫用户支持的语音编解码格式列表,例如CodecListB,并且在该列表中指定了优选语音编解码格式(例如Codec2),目的是指示期望使用该优选语音编解码格式建立承载;
5、MSCe判断CodecListA和CodecListB有交集,但是该交集中不包含Codec1,包含Codec2(或其它主叫用户和被叫用户都支持的Codec),MSCe则向主叫用户发送承载更新请求,要求主叫用户更改优选语音编解码格式为Codec2(或其它主叫用户和被叫用户都支持的Codec);并且在接到主叫用户的响应后更新在步骤2中建立的主叫承载端点;并且建立被叫承载端点(建立过程同步骤2中主叫承载端点的建立相似)。
从上述的协商步骤来看,对于主、被叫双方具有共同支持的Codec列表(即上述CodecListA和CodecListB的交集),但主叫方的优选Codec却不在该列表中的情况下,需要有一个承载更新的流程,这个承载更新流程增加了系统开销和接续时间。
具体实施方式
本发明在任意一个移动台进行语音通话时,记录该移动台支持的语音编解码格式列表,并将记录的信息存储到数据库中。这样,在主叫用户发起呼叫后,就可以由移动交换中心根据该呼叫信号中携带的被叫移动台的号码,从所述数据库中提取出该被叫移动台最近使用的语音编解码格式列表,然后,根据主叫用户支持的语音编解码格式列表及被叫移动台最近使用的语音编解码格式列表确定主叫用户与被叫移动台进行通信时使用的语音编解码格式,并且以该语音编解码格式建立主叫用户和被叫移动台的语音承载。
参照图1,图1示出了本发明方法的一个实施例的实现流程,包括以下步骤:
步骤1001:通信系统中的移动交换中心接收主叫用户发送的始呼信号,该始呼信号中携带有被叫移动台的号码。
主叫用户可以是移动台,也可以是固定电话。
步骤1002:根据被叫移动台的号码在存储有移动台信息的数据库中获取被叫移动台最近使用的语音编解码格式列表。
存储有移动台信息的数据库可以是VLR(访问位置寄存器)。可以在任意一个移动台(作为主叫或被叫)进行语音通话时,将该移动台支持的语音编解码格式列表记录并保存到该数据库中。这样,每个移动台号码可能对应了一个或多个语音编解码格式列表,在选取时,可以从中选择被叫移动台最近使用的语音编解码格式列表。当然,也可以在保存新的语音编解码格式列表时将对应该移动台号码的其他语音编解码格式列表覆盖。也就是说,在该数据库中只存储移动台最近使用的语音编解码格式列表。
另外,还可以在该数据库中存储移动台推荐的语音编解码格式。
移动交换中心向VLR发送请求信号,在该请求信号中携带被叫移动台的号码;访问位置寄存器收到所述请求信号后,将被叫移动台最近使用的语音编解码格式列表发送给移动交换中心。移动交换中心可以经由HLR(归属位置寄存器)与VLR进行消息交互,比如,通过LOCREQ、ROUTREQ、routreq、locreq消息交互获得被叫移动台最近使用的语音编解码格式列表。
步骤1003:移动交换中心获取主叫用户支持的语音编解码格式列表。
在主叫用户发送的呼叫请求消息中携带了主叫用户所推荐的语音编解码格式及主叫用户所支持的语音编解码格式列表,可以由主叫用户所属的基站向移动交换中心转发该始呼信号时携带主叫用户支持的语音编解码格式列表。这样,移动交换中心直接从该始呼信号中就可获取到主叫用户支持的语音编解码格式列表。也可以通过移动交换中心与主叫用户所属的基站交互,获取主叫用户支持的语音编解码格式列表。
步骤1004:根据主叫用户支持的语音编解码格式列表及被叫移动台最近使用的语音编解码格式列表确定主叫用户与被叫移动台进行通信时使用的语音编解码格式。
在确定主叫用户与被叫移动台进行通信时使用的语音编解码格式时,可以选取被叫移动台最近使用的语音编解码格式列表与主叫用户支持的语音编解码格式列表的交集中的语音编解码格式,作为主叫用户与被叫移动台进行通信时使用的语音编解码格式。当然,如果该交集中有主叫用户或被叫移动台用户推荐优选的语音编解码格式,则可以优选该语音编解码格式。
这样,主叫用户和被叫移动台就可以按照该语音编解码格式建立主叫用户和被叫移动台的语音承载。
可以在寻呼被叫移动台之前或与寻呼被叫移动台并行执行建立被叫移动台的承载的过程。
参考图2,该图示出了本发明系统第一实施例的组网结构:
如图所示,MS(移动台)100和MS200是两个移动台,为了便于区别,称MS100为第一通信装置,MS200为第二通信装置。当MS100始发与MS200进行通话时,MS100为主叫用户,而MS200为被叫用户。
所述MS100和MS200协商语音编解码格式及后面的通话都要通过通信网络(图未标号)。该通信网络包括接入网(图未标号)和核心网(图未标号)两部分。如图所示,接入网包括BSC(基站控制器)105和BSC205。所述BSC105是主叫用户MS100的接入网设备,BSC205则是被叫用户MS200的接入网设备。所述MS100与BSC105耦合,MS200与BSC205耦合。当然,接入网还可能包括BTS(基站收发器)等设备,但这些设备及其信号传递是本领域普通技术人员熟知的技术,在此不赘述。
所述BSC105和BSC205与核心网设备MSCe(移动交换中心)300耦合。该MSCe300与核心网其它设备,例如VLR(访问位置寄存器)400、MGW(媒体网关)500耦合。所述BSC105和BSC205分别与MGW500耦合。当MS100和MS200语音编解码格式协商完成后,通信双方将以MGW500提供的话路进行通信。当然,核心网设备还可以包括其它设备,因其并不是本发明的重点,故不赘述。
值得说明的是,上述各网元设备在数量上包括单数和复数。
参考图3,该图示出了图2中移动交换中心一个实施例的结构。在该实施例中,移动交换中心包括:发送装置303、接收装置302和业务协商器301,发送装置303和接收装置302分别与业务协商器301耦接。发送装置303和接收装置302分别与接口310耦接,通过接口310发送或接收消息。
参考图4,该图示出了本发明提供的一种基于图2的通信系统的协商语音编解码格式的消息交互流程。如图所示,包括步骤:
1、MS100始发与MS200进行语音编解码格式的协商,MS100发送始呼信号。该始呼信号中包括被叫用户MS200的号码。
2、BSC105接收到所述始呼信号,处理后以CM Service Request消息的方式发送出去。处理时,可以在该消息中携带MS100支持的语音编解码格式列表,例如CodecListA,其中包括(Codec1、Codec2、Codec3、Codec4),并且指定优选Codec为Codec1,即希望以Codec1建立承载连接。当然也可以不携带MS100支持的语音编解码格式列表,即BSC105负责转发所述始呼信号,并且有权处理该始呼信号。
3、MSCe300通过接口310和接收装置302接收到所述CM Service Request消息,由业务协商器301生成一请求信号,该请求信号携带MS200的号码(该号码从CM Service Request消息中获得),该请求信号指示请求获得MS200最近使用的语音编解码格式列表。该请求信号(图4中的Request)被发送装置303通过接口310发送出去。
4、VLR400接收到所述请求信号,找到MS200最近使用的语音编解码格式列表,例如CodecListB,包括(Codec2、Codec3、Codec4、Codec5),并生成响应信号(图4中的Answer),该响应信号携带所述列表(CodecListB)。该响应信号被发送出去。
MSCe300通过接口310和接收装置302接收到所述响应信号,业务协商器301根据在所述始呼信号中的CodecListA与所述响应信号中的CodecListB的交集中选定用于MS100和MS200通信的优选语音编解码格式。因为CodecListA为(Codec1、Codec2、Codec3、Codec4),CodecListB为(Codec2、Codec3、Codec4、Codec5),二者的交集为(Codec2、Codec3、Codec4),MS100推荐的优选Codec,即Codec1并不在该交集中,因此MSCe300可以选用交集中的Codec2建立承载(当然也可以选用Codec3或Codec4)。建立承载包括下述步骤5、6、7、8、9、10、11、12。
5、MSCe300通过发送装置303和接口310向MGW500发送ADD消息,请求MGW创建MS100的语音承载端点,ADD消息中指定了该端点采用的语音编解码格式为MSCe300选定的Codec2。
6、MGW500建立MS100的语音承载端点后,向MSCe300发送ADD Reply消息,指示建立承载端点成功。
7、MSCe300接收到ADD Reply消息后,通过发送装置303和接口310向BSC105发送Assignment Request消息,同时携带MSCe300指定MS100使用语音编解码格式Codec2的消息。
8、BSC105向MSCe300返回Assignment Complete消息,表明指定成功。
9、MSCe300向BSC205发送指配请求(Paging Request)。
10、BSC205向MSCe300发送指配响应(Paging Response),表明指配成功。
11、MSCe300通过发送装置303和接口310向MGW500发送ADD消息,请求MGW创建MS200的语音承载端点,ADD消息中指定了该端点采用的语音编解码格式为MSCe300选定的Codec2。
12、MGW500建立MS100的语音承载端点后,向MSCe300发送ADD Reply消息,指示建立承载端点成功。
13、MSCe300接收到ADD Reply消息后,通过发送装置303和接口310向BSC205发送Assignment Request消息,同时携带MSCe300指定MS200使用语音编解码格式Codec2的消息。
14、BSC205向MSCe300返回Assignment Complete消息,表明指定成功。
值得说明的是,步骤11、12和13、14可以并行执行,也可以互换执行顺序。也即是说,建立被叫端点和指定请求响应过程可以并行执行,也可以不用区分先后顺序。
在本发明的另一个具体实施例中,步骤2中的CM Service Request消息没有携带MS100支持的语音编解码格式列表,而是在步骤7、8中MSCe300在Assignment Request消息中请求MS100发送其支持的语音编解码格式列表,而MS100则通过Assignment Complete返回该语音编解码格式列表。如此一来,步骤4中介绍的选定优选语音编解码格式的过程和步骤5、6中的指定MS100的语音承载端点过程就要移动到步骤7、8之后。也即是说,步骤5、6、7、8、9、10、11、12是MSCe300决定MS100和MS200的语音编解码格式过程,交互方式可以有多种变化形式。
此时协商已经成功,MS100和MS200进入通话状态。而在MS100和MS200通话期间,MSCe300可以将MS100和/或MS200支持的语音编解码格式列表传送到VLR400处,VLR400将其保存,以备下次协商时使用。这个过程包括步骤15和16。
15、MSCe300通过发送装置303和接口310向VLR400发送一传送信号(如图中的NOTIFY消息),该传送信号携带CodecListA和/或CodecListB。
16、VLR400接收到所述传送信号后,将该传送信号中携带的CodecListA和/或CodecListB存储,并向MSCe300发送应答信号(如图中的REPLY消息),表示存储成功。
值得说明的是,步骤15和16也可以在MSCe300在接收到MS100发送请求后就执行,这时仅存储MS100的CodecListA。
从上面的说明可知,本发明提供的这种方法及系统,通过在VLR400或其它存储移动台信息的存储器中存储移动台最近使用的语音编解码格式,在移动台进行语音编解码格式协商时,移动交换中心通过查询VLR400或其它存储移动台信息的存储器并提取移动台的语音编解码格式,提前判决主被叫移动台采用何种语音编解码格式通话,从而省略了针对主叫用户的更改流程,减少了系统处理开销,缩短了接续时间。
参考图5,该图示出了本发明系统的第二实施例的网络结构:
同时参考图2,如图所示,图5与图2相比,MS100和MS200处于不同的局中,即MS100针对MS200的呼叫是跨局呼叫。此时,为MS100服务的移动交换中心和访问位置寄存器是MSCe300和VLR400,为MS100服务的媒体网关是MGW500;而为MS200服务的移动交换中心和访问位置寄存器是MSCe700和VLR800,为MS200服务的媒体网关是MGW900。MGW500于MGW900相连接。此时,如果MS100发起始呼与MS200协商语音编解码格式,因为MS200最近使用的语音编解码格式存储在VLR800中,做协商的MSCe300就必须到VLR800中去取该语音编解码格式,因此需要通过HLR(归属位置寄存器)600到达MSCe700和VLR800中。
针对跨局呼叫的情况,现有技术中主叫MSCe/VLR和被叫MSCe/VLR之间有LOCREQ、ROUTREQ、routreq、locreq的消息交互过程,被叫移动台的语音编解码格式可以通过routreq->locreq消息携带传递回主叫的MSCe/VLR中。
具体到本实施例中,参考图6,该图示出了本发明提供的一种基于图5的通信系统的协商语音编解码格式的方法在跨局呼叫时主叫MSCe/VLR在被叫的MSCe/VLR中获取被叫的语音编解码格式的消息交互流程:
同时参考图4,图6所示的消息交互流程即图4中步骤3和4所做的工作。其它消息与图4一致,不再赘述。
参考图6,同时参考图5,主叫用户MS100发起始呼后,主叫侧的MSCe300/VLR400要通过HLR600获得被叫移动台MS200的语音编解码格式。消息包括:MSCe300/VLR400向HLR600发送LOCREQ消息;HLR600向MSCe700/VLR800发送ROUTREQ消息;MSCe700/VLR800向HLR600发送routreq消息,表示响应请求;HLR600向MSCe300/VLR400发送locreq消息,表示响应;MSCe300/VLR400在向MSCe700/VLR400发送INVITE消息,表示请求获得MS200的最近使用的语音编解码格式。此后MSCe300/VLR400和MSCe700/VLR800通过SIP协议通信,传递MS200的语音编解码格式。
在上述本发明系统的实施例中,描述了主叫用户设备为移动台的情况,当主叫用户设备为固定电话,即固化用户呼叫移动用户时,也同样可以适用,在此不再赘述。
参照图7,该图示出了本发明通信系统中协商语音编解码格式的设备的一个优选实施例的原理框图:
在该实施例中,本发明设备包括:收发装置71、移动台信息获取装置72、数据库73和业务协商器74。
其中,收发装置71与通信系统中的其他设备进行消息交互,包括接收主叫用户发送的始呼信号,以及被叫移动台发送的应答信号,所述始呼信号中携带有被叫移动台的号码;移动台信息获取装置72用于根据所述收发装置接收的消息获取语音通话的移动台的信息,所述信息包括移动台支持的语音编解码格式列表;数据库73分别与移动台信息获取装置72及业务协商器74耦接,用于存储所述移动台信息获取装置获取的移动台的信息;业务协商器74用于根据所述始呼信号从数据库73中获取被叫移动台最近使用的语音编解码格式列表,并根据收发装置接收的始呼信号获取主叫用户支持的语音编解码格式列表,并确定主叫用户与被叫移动台进行通信时使用的语音编解码格式。
在图7中,业务协商器74的一个实施例包括:比较单元741和编解码格式选择单元742。其中,比较单元741用于获取被叫移动台最近使用的语音编解码格式列表与主叫用户支持的语音编解码格式列表的交集中的语音编解码格式。编解码格式选择单元742用于从该交集中选择作为主叫用户与被叫移动台进行通信时使用的语音编解码格式,如果该交集中包含主叫用户或被叫移动台推荐的语音编解码格式,则优先选择该语音编解码格式。当然,业务协商器还可以通过其它方式来实现。
为了向移动台提供语音承载业务,还可以在该设备中设置一个与业务协商器耦接的语音承载建立装置75。在业务协商器确定了主叫用户和被叫移动台可以使用的语音编解码格式后,由语音承载建立装置75为主叫用户和被叫移动台建立该语音编解码格式的语音承载。可见,利用本发明,在主叫用户支持的语音编解码格式和被叫移动台支持的语音编解码格式存在交集时,即使主叫用户先前推荐的语音编解码格式没有包含在其支持的语音编解码格式列表中,也可以避免主被叫间语音编解码格式的协商过程,从而减少了系统处理开销,缩短了接续时间。
以上所揭露的仅为本发明的优选实施例而已,当然不能以此来限定本发明之权利范围,因此依本发明申请专利范围所作的等同变化,仍属本发明所涵盖的范围。