CN101119535A - 一种实现集群通信业务的方法和系统 - Google Patents
一种实现集群通信业务的方法和系统 Download PDFInfo
- Publication number
- CN101119535A CN101119535A CN200610111528.1A CN200610111528A CN101119535A CN 101119535 A CN101119535 A CN 101119535A CN 200610111528 A CN200610111528 A CN 200610111528A CN 101119535 A CN101119535 A CN 101119535A
- Authority
- CN
- China
- Prior art keywords
- speaker
- end points
- hearer
- context
- dispatcher
- 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.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
- H04L12/1822—Conducting the conference, e.g. admission, detection, selection or grouping of participants, correlating users to one or more conference sessions, prioritising transmission
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/189—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
- H04L65/403—Arrangements for multi-party communication, e.g. for conferences
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/30—Resource management for broadcast services
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Telephonic Communication Services (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本发明公开了一种实现集群通信业务的方法,减少了会议桥上下文中端点数目,当呼叫者发起集群呼叫时,包括:建立呼叫者承载和会议桥上下文,并通过呼叫者承载将呼叫者终端与会议桥上下文相连;在会议桥上下文中建立听者代理端点,所述的听者代理端点用于将呼叫者的话音发给听者终端;建立听者承载,并通过听者承载将听者端点连接到会议桥上下文的听者代理端点。本发明还公开了实现集群通信业务的系统、集群通信方法和集群通信系统。通过在会议桥上下文中采用听者代理,可减少会议桥上下文中的端点数目,从而大大缩减了集群业务中所使用的会议混音资源的数量。
Description
技术领域
本发明涉及一种集群技术,尤其涉及一种实现集群通信业务的方法和系统。
背景技术
在基于GSM(Global System for Mobile Communications,全球移动通信系统)的集群通信系统中,支持VBS(Voice broadcast service,语音广播业务)和VGCS(Voice group call service,语音组呼业务)。这些业务在铁路、公安、消防等存在大范围资源调度的领域内得到了广泛的应用。
VBS是在GSM移动网络中,把业务用户发出的话音(或可以通过话音编码传送的其它信号)传送给在一个地理区域内的所有或一组业务用户的业务。VGCS是在GSM移动网络中,向预定义的一组用户提供半双工通话功能的业务。
VBS的业务功能与VGCS是相似的,二者的主要差别在于:对于VBS呼叫,除了发起呼叫的VBS签约用户,其它VBS签约用户只能收听,没有发言的权限;而对于VGCS呼叫,不论是发起呼叫的VGCS签约用户,还是参与呼叫的其它的VGCS签约用户,在通话过程中,都可以申请发言的权限,申请成功后即可发言。
在VBS/VGCS业务中,主叫用户拨打特定的组呼号码,呼叫属于预定义组呼区的组ID的目标用户,从而与指定区域内的小组成员建立通话业务。该组内所有目标VBS/VGCS签约用户均可共享同一业务信道进行接听,但调度员则各自占据自己的正常业务通道。对于VGCS呼叫,组内的VBS/VGCS签约用户可以通过按键讲话(PTT,Push toTalk)方式发出通话请求,系统为讲话的签约用户建立一个上行链路来提供通话服务。
在VBS/VGCS业务中,主叫用户可以是已经签约到相关组ID的VBS/VGCS签约用户,或者在网络中注册的调度员。目标用户是当前位于组呼区域内的、由被叫组呼ID标识的所有或部分VBS/VGCS签约用户,以及预先注册的调度员。
在VBS/VGCS业务中,在某一个时刻,只允许一个签约用户发言(称为“讲者”)。此外,最多五个调度员可以同时说话。调度员需要听到所有方的语音(除了自己的语音,即调度员不听自己的回声)。正在听的签约用户(称为“听者”),应该听到所有方语音的混音。正在发言的签约用户(“讲者”)应该在任何调度员说话时,收到声音指示。调度员应能在任何时候开口说话,不需要预先申请发言权限。VGCS签约用户若希望说话,则需要预先申请发言权限(按PTT键),只有在没有其它说话的VGCS签约用户时,它才能获得发言权限。发言权限通常是按照“先请求先服务”的原则分配的。VBS的签约用户,除了发起呼叫者可说话,其它签约用户始终没有发言权限。
随着第二代通信系统GSM向第三代移动通信系统UMTS(Universal MobileTelecommunications System,通用移动通信系统)的演进,核心网的体系结构发生了改变。3G R4(Release 4,即发布版本4)之后的电路域核心网,采用了呼叫控制与承载分离的架构。如图1所示,第二代通信系统中的MSC(移动交换中心)被拆分为MSC server(移动交换中心服务器)和MGW(媒体网关)。其中MSC server通过Iu/A口提供到RNC/BSC的信令面连接,执行关口路由、呼叫控制和移动性管理功能;MGW则包含承载终端和媒体管理设备(例如编解码转换器,回声抵消设备,或单音/通知音发生器),通过Iu/A口提供到RNC/BSC的用户面连接,对MGW与RNC/BSC之间,以及MGW与MGW之间传输的媒体流执行媒体转换和帧协议转换。MSC server和MGW间的接口称为Mc口,所述的Mc口以H.248/MEGACO(Media Gateway Control,媒体网关控制)作为控制协议。H.248/MEGACO是ITU-T(International Telecommunication Union-Telecommunication Standardization Sector,国际电信联盟电信标准化分部) 和IETF(Internet Engineering Task Force,互联网工程任务组)共同开发的媒体网关控制协议,它支持呼叫控制实体与承载控制实体的分离,以及承载控制实体与传输实体的分离。
在现有技术中,如H.248/MEGACO协议以上下文(Context)中的端点(Termination)作为基本呼叫模型。由于VGCS/VBS业务中都可能存在最多五个调度员,他们可以随时开口说话,因此承载模型应以多方会议为基础。3GPPTS23.205对多方会议的实现给出了两种承载模型:
第一种模型,参与多方会议的各方都在独立的上下文中处理,会议桥自身也在一个独立的上下文中处理。如图2所示,CTXA对应用户A;CTXAB对应用户B;CTXAC对应用户C;CTXMPTY对应会议桥,负责对用户A、B、C的语音进行混音;各会议方的上下文与会议桥上下文建立网关内部连接。分割为几个上下文是为了简化与其它功能的交互(如切换)。
第二种模型,在多方会议操作中,各方都在一个多方上下文中处理。如图3所示,用户A、B、C都被放在同一个上下文CTXA中。
对于VGCS/VBS中的调度员,由于可以随时开口说话,且不需要听到自己的回音,完全符合多方会议补充业务的特征,因此按照上述两种模型,将调度员作为普通多方会议中的用户来建立承载,都能获得所需的语音效果。
但是对于未取得发言权限的VBS/VGCS签约用户(“听者”),它听到的语音效果是讲者的声音与各调度员语音的混合;对于取得发言权限的VBS/VGCS签约用户(“讲者”),它听到的语音效果应该是自己的声音与各调度员语音的混合(如运营商另有要求,也可以去除“讲者”自己的声音)。这与普通的多方会议补充业务存在明显的差异(一般的会议实现,不会把讲话者的信息再反送给讲话者,以避免用户感受到回音)。
“讲者”端点需要听自己的回音,主要是由于“讲者”用户所处的小区中可能存在其它“听者”用户,这些“听者”用户与“讲者”用户通常共享相同的无线信道和地面电路,因此“讲者”端点上实际上同时接入了“讲者”用户和一些“听者”用户,媒体网关需要将“讲者”端点的语音再原路送回,播送给这些“听者”用户。如果运营商要求讲者不听自己的回音,就只能为“讲者”用户建立单独的下行链路。
对于上述的“听者”端点,可以通过设置“调度员”端点和“讲者”端点到“听者”端点的单向拓扑,或者设置“听者”端点的流模式为sendOnly来解决,此时“听者”只能被动接收“调度员”、“讲者”端点发送过来的语音流。
对于上述的“讲者”端点,一般需要听到自己的回声,这样的语音效果和“调度员”是有差别的,必须引入一个机制,以便把“讲者”与调度员区分开。例如为会议中的端点引入角色属性,指示其语音效果或者在集群中的角色。这样,调度员、讲者、听者都可以作为普通多方会议的端点在会议桥的上下文中来建立,只需要增加对该端点的集群相关的属性的指示。
然而,在上述现有技术中,存在如下缺点。
(1)“听者”端点对应的是属于组呼区域的各小区下行链路,如果把“听者”当作普通的会议方来建立承载,则会议桥所在的上下文中,其端点数量等于调度员数、讲者数、听者数之和,在组呼区域包含较多小区的情况下(如GSM网络中有支持1024小区的集群产品),上下文中端点数量可能太多,需要消耗大量的会议资源。
(2)按H.248标准,一个上下文中最多能支持多少个端点,是网关自行决定的一个属性。如果MSC server在一个上下文中加入太多的端点,有可能因为媒体网关不支持而导致集群建立失败。
(3)按H.248标准,当MSC server给媒体网关下发指令,若其中包含拓扑描述符,且一个端点没有出现在该拓扑描述符中时,则该端点相关联的拓扑保持不变。然而,如果一个新的端点被加入上下文,则该端点与上下文中已有的其它端点的拓扑缺省为“双向”,除非另外有拓扑描述符来明确说明其拓扑。这样,每次加入一个新的端点,如果不希望使用缺省的“双向”拓扑,就应该描述该端点与上下文中已有的其它端点的拓扑。当上下文中有较多端点时,描述拓扑将是一个巨大的负担。
(4)为描述端点的语音效果,需要对H.248标准进行扩充,引入新的集群包来定义端点的属性。对MSC server于MGW的互通性有一定影响。
发明内容
本发明的目的是提供一种实现集群通信业务的方法和系统,可提高VGCS/VBS的承载资源的使用效率,可减少会议桥上下文中端点的数量,从而缩减VGCS/VBS业务所使用的会议混音资源的数量。
本发明公开了一种实现集群通信业务的方法,当呼叫者发起集群呼叫时,包括:
建立呼叫者承载和会议桥上下文,并通过呼叫者承载将呼叫者终端与会议桥上下文相连;
在会议桥上下文中建立听者代理端点,所述的听者代理端点用于将呼叫者的话音发给听者终端;
建立听者承载,并通过听者承载将听者端点连接到会议桥上下文的听者代理端点。
所述的呼叫者包括讲者和调度员。
当呼叫者为讲者时,所述的建立呼叫者承载具体包括:
建立讲者接入端点和包括讲者接入端点的讲者上下文,并将所述的讲者接入端点与讲者终端相连;
建立讲者代理端点和包含讲者代理端点的会议桥上下文;
在讲者上下文中建立讲者连接端点,并将会议桥上下文中的讲者代理端点与讲者上下文的讲者连接端点相连,讲者上下文中的讲者连接端点与讲者接入端点相连。
所述的在会议桥上下文中建立讲者代理端点的过程中,所述的增加请求包括其值为讲者的模式参数。
当呼叫者为讲者时,所述的建立呼叫者承载具体包括:
建立讲者接入端点和包含讲者接入端点的会议桥上下文,并将所述的讲者接入端点与讲者终端相连。
所述的在会议桥上下文中建立讲者接入端点的过程中,所述的增加请求包括其值为讲者的模式参数。
所述的方法还包括:媒体网关根据模式参数对讲者和调度员采用不同的混音策略。
当呼叫者为讲者时,所述的建立呼叫者承载具体包括:
建立讲者接入端点和包括讲者接入端点的讲者上下文,并将所述的讲者接入端点与讲者终端相连;
建立会议桥上下文,并在会议桥上下文中建立讲者上行代理端点和讲者下行代理端点;
在讲者上下文中建立讲者上行连接端点和讲者下行连接端点,并将会议桥上下文的讲者上行代理端点与讲者上下文的讲者上行连接端点相连,会议桥上下文的讲者下行代理端点与讲者上下文的讲者下行连接端点相连,讲者接入端点分别与讲者上下文中的讲者上行连接端点和讲者下行连接端点相连。
当呼叫者为讲者时,所述的方法还包括建立调度员承载。
所述的建立调度员承载具体包括:
建立调度员接入端点和包括调度员接入端点的调度员上下文,并将所述的调度员接入端点与调度员终端相连;
在会议桥上下文中建立调度员代理端点;
在调度员上下文中建立调度员连接端点,并将会议桥上下文中的调度员代理端点与调度员上下文的调度员连接端点相连,将调度员上下文中的调度员接入端点与调度员连接端点相连。
所述的建立调度员承载具体包括:
在会议桥上下文中建立调度员接入端点,将调度员接入端点与调度员终端相连。
当呼叫者为调度员时,所述的建立呼叫者承载具体包括:
建立调度员接入端点和包括调度员接入端点的调度员上下文,并将所述的调度员接入端点与调度员终端相连;
建立调度员代理端点和包含调度员代理端点的会议桥上下文;
在调度员上下文中建立调度员连接端点,并使会议桥上下文中的调度员代理端点与调度员上下文的调度员连接端点相连,使调度员上下文中的调度员接入端点与调度员连接端点相连。
当呼叫者为调度员时,所述的建立呼叫者承载具体包括:
建立调度员接入端点和包括调度员接入端点的会议桥上下文,并将调度员接入端点与调度员终端相连。
当呼叫者为调度员时,所述的方法还包括建立讲者承载。
所述的建立讲者承载具体包括:
建立讲者接入端点和包括讲者接入端点的讲者上下文,将所述的讲者接入端点与讲者终端相连;
在会议桥上下文中建立讲者代理端点,在讲者上下文中建立讲者连接端点,将会议桥上下文中的讲者代理端点与讲者上下文的讲者连接端点相连,将讲者上下文中的讲者接入端点与讲者连接端点相连。
所述的建立讲者承载具体包括:
在会议桥上下文中建立讲者接入端点,将所述的讲者接入端点与讲者终端相连。
所述的建立讲者承载具体包括:
建立讲者接入端点和包括讲者接入端点的讲者上下文,并将所述的讲者接入端点与讲者终端相连;
在会议桥上下文中建立讲者代理上行连接端点和讲者代理下行连接端点;
在讲者上下文中建立上行连接端点和下行连接端点,并将会议桥上下文的讲者代理上行连接端点与讲者上下文的上行连接端点相连,会议桥上下文的讲者代理下行连接端点与讲者上下文的下行连接端点相连,接入端点分别与讲者上下文中的上行连接端点和下行连接端点相连。
所述的建立听者承载具体包括:
建立听者接入端点和包括听者接入端点的听者上下文,并将听者接入端点与听者终端相连;
在听者上下文中建立听者连接端点,并将会议桥上下文中的听者代理端点与听者上下文的听者连接端点相连,将听者上下文的听者连接端点与听者接入端点相连。
在创建多个听者承载过程中,仅创造一个听者上下文,该过程中创建的所有听者接入端点包括在该听者下文中;或者,在创建听者承载过程中,创建每一个听者接入端点时创建一个包括该听者接入端点的听者上下文。
本发明还公开一种实现集群通信业务的系统,包括:
呼叫者终端,用于发起集群呼叫;
听者端点代理建立单元,用于在会议桥上下文中建立听者代理端点,所述的听者代理端点用于将呼叫者的话音发给听者终端;
听者承载建立单元,用于建立听者承载,并通过听者承载将听者终端连接到会议桥上下文的听者代理端点。
所述的呼叫者终端包括讲者终端和调度员终端。
本发明还公开了一种集群通信的方法,包括:
讲者终端向会议桥上下文的讲者代理端点或讲者接入端点发送话音;
会议桥上下文将所述的讲者话音发给听者代理端点;
听者代理端点将来自会议桥的话音发给听者连接端点;
听者连接端点将来自听者代理端点的话音发给听者接入端点;
听者接入端点将来自听者连接端点的话音发给听者终端。
所述的方法还包括:
调度员终端向会议桥上下文的调度员代理端点或者调度员接入端点发送话音;
会议桥上下文将所述的讲者话音和调度员话音进行混音处理形成新的话音发给听者代理端点。
所述的听者代理端点将来自会议桥的话音发给听者连接端点具体包括:
移动交换中心服务器或媒体网关将听者连接端点归入多播组;
听者代理端点向多播组内的听者连接端点发送混音音频流。
所述的听者代理端点将来自会议桥的话音发给听者连接端点具体包括:听者代理端点向多个听者连接端点的地址同时发送混音音频流。
所述的听者代理端点将来自会议桥的话音发给听者连接端点具体包括:
听者代理端点向一个共享音源通道发送混音音频流;
各听者连接端点守候在该共享音源通道上收听语音。
所述的方法还包括听者与讲者角色转换步骤,所述的听者与讲者角色转换步骤包括:
移动交换中心服务器向媒体网关发送移动请求消息,将媒体网关将讲者接入端点从讲者上下文中移动到听者上下文中,并将听者上下文中的听者连接端点到讲者接入端点置为单向拓扑关系;
移动交换中心服务器向媒体网关发送移动请求消息,将媒体网关将听者接入端点从听者上下文中移动到讲者上下文中,将听者接入端点到讲者上行连接端点置为单向拓扑关系,将讲者下行连接端点到听者接入端点置为单向拓扑关系。
本发明还公开一种集群通信的系统,包括:
用于向会议桥上下文的讲者代理端点或讲者接入端点发送话音的讲者终端;
用于将所述的讲者话音发给听者代理端点的会议桥单元;
用于将来自会议桥的话音发给听者连接端点的听者代理单元;
用于将来自听者代理端点的话音发给听者接入端点的听者连接单元;
用于将来自听者连接端点的话音发给听者终端的听者接入单元;
用于接收听者接入单元的听者终端。
所述的系统还包括角色转换单元,用于使听者与讲者角色互相转换,所述的角色转换单元具体包括:
用于将讲者接入端点从讲者上下文中移动到听者上下文中,并将听者连接端点到讲者接入端点置为单向拓扑关系的移动讲者接入端点单元;
用于将听者接入端点从听者上下文中移动到讲者上下文中,将听者接入端点到讲者上行连接端点置为单向拓扑关系,将讲者下行连接端点到听者接入端点置为单向拓扑关系的移动听者接入端点单元。
因此,根据本发明,在H.248标准内,在不扩充新的包的前提下,就可实现集群业务。通过在会议桥上下文中采用听者代理,可以在会议桥上下文中大量减少端点的数目,从而大大缩减了集群业务中所使用的会议混音资源的数量。
附图说明
图1示出了呼叫控制与承载分离的示意图;
图2示出了现有技术中普通多方会议的第一种承载模型;
图3示出了现有技术中普通多方会议的第二种承载模型;
图4示出了本发明的集群业务的调度员的第一种承载模型;
图5示出了本发明的集群业务的调度员的第一种承载的建立过程;
图6示出了本发明的集群业务的调度员的第二种承载模型;
图7示出了本发明的集群业务的调度员的第二种承载的建立过程;
图8示出了本发明的集群业务的讲者的第一种承载模型;
图9示出了本发明的集群业务的讲者的第一种承载的建立过程;
图10示出了本发明的集群业务的讲者的第二种承载模型;
图11示出了本发明的集群业务的讲者的第二种承载的建立过程;
图12示出了本发明的集群业务的讲者的第三种承载模型;
图13示出了本发明的集群业务的讲者的第三种承载的建立过程;
图14示出了本发明的集群业务的听者的第一种承载模型;
图15示出了本发明的集群业务的听者的第一种承载的建立过程;
图16示出了本发明的集群业务的听者的第二种承载模型;
图17示出了本发明的集群业务的听者的第二种承载的建立过程;
图18示出了没有调度员情形的承载模型;
图19示出了本发明的实现集群业务系统的第一实施例;
图20示出了本发明的实现集群业务系统的第二实施例;
图21示出了本发明的集群通信的流程图;
图22示出了本发明的听者与讲者角色转换的流程图;
图23-24示出了听者与讲者角色转换过程中承载示意图;
图25为本发明的集群通信系统的示意图。
具体实施方式
为了便于本领域一般技术人员理解和实现本发明,现结合附图描绘本发明的实施例。
本发明提供了一种集群通信业务的实现方法,包括:建立调度员承载、讲者承载和听者承载三个步骤。下面分别描述上述三个步骤。
一、调度员承载的建立方法
对于VBS/VGCS呼叫中的调度员,当作多方会议补充业务中的用户来建立承载。即按照3GPP TS23.205的描述,可以采用两种承载模型:(1)每个调度员占用一个独立的上下文,会议桥也在一个独立的上下文中处理,在MGW中建立调度员上下文和会议桥上下文之间的内部连接。(2)所有的调度员都放在同一上下文内。下面分别描述上述二种建立调度员承载模型。
1、第一种调度员承载模型的建立方法
如图4所示,以及在下面图中,空心椭圆代表上下文,实心圆代表端点,图4示出了集群业务的调度员的第一种承载模型,在该种承载模型中,调度员的接入端点和会议桥使用不同的上下文。
MSC Server在收到VBS/VGCS呼叫时,如果发现该呼叫所在的组已经定义了调度员,则需要发起到各调度员的正常呼叫过程,因此,要为各调度员建立承载通道。假定本次VBS/VGCS呼叫具有2个调度员,且呼叫是调度员1发起的,MSC Server需要在媒体网关上建立调度员的接入端点(可能是连接BSC的无线接入的地面电路,也可能是连接PLMN/ISDN网络的局间中继电路,或者是连接本MSC Server的其它MGW的局内承载),以及到会议桥的内部连接端点。下面参照图5描述调度员承载的建立过程。
步骤51-52、MSC Server向MGW发送ADD.request(增加请求)消息,要求为调度员1建立调度员接入端点。如果调度员接入端点是分组端点(ATM或者IP),MGW使用ADD.reply(增加响应)消息响应,返回它所分配的调度员上下文(C1)和调度员接入端点(T1)标识,这对应的是3GPP TS 29.232中描述的准备承载过程(Prepare Bearer)。如果调度员接入端点是TDM(时分复用)端点,MSC Server在ADD.request消息中已经指明了调度员接入端点标识T1,MGW使用ADD.reply消息响应,返回它所分配的调度员上下文(C1)标识,这对应的是3GPP TS 29.232中描述的保留电路过程(Reserve Circuit)。
步骤53-54、MSC Server向MGW发送ADD.request消息,要求建立一个会议桥上下文,以及用于连接调度员1的调度员代理端点。如果调度员代理端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的会议桥上下文(Cmpty)和调度员代理端点(T10)标识,这对应的是3GPP TS 29.232中描述的准备承载过程(Prepare Bearer)。如果调度员连接端点是TDM端点,MSC Server在ADD.request消息中已经指明了调度员代理端点标识T10,MGW使用ADD.reply消息响应,返回它所分配的会议桥上下文(Cmpty)标识,这对应的是3GPP TS 29.232中描述的保留电路过程(Reserve Circuit)。
步骤55-56、MSC Server向MGW发送ADD.request消息,要求在上下文C1中建立一个调度员连接端点,以便连接到会议桥。如果调度员连接端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的调度员连接端点(T11)标识,这对应的是3GPP TS 29.232中描述的建立承载过程(Establish Bearer)。如果调度员连接端点是TDM端点,MSC Server在ADD.request消息中已经指明了调度员连接端点标识T11,MGW使用ADD.reply消息响应,这对应的是3GPP TS 29.232中描述的保留电路过程(ReserveCircuit)。这样,调度员1到会议桥的承载通路就建立起来了。
步骤57-512为调度员2承载的建立过程,其与调度员1承载的建立过程相同,只是Cmpty已经由调度员1建立,在第59-510步骤直接使用这个上下文即可,不需要由MGW分配新的上下文。
2、第二种调度员承载模型的建立方法
图6示出本发明的第二种调度员承载模型,在该承载模型中,调度员的接入端点和会议桥使用相同的上下文。
MSC Server在收到VBS/VGCS呼叫时,如发现该组呼ID已经定义了调度员,则需要发起到各调度员的正常呼叫过程,并为各调度员建立承载通道。假定本次VBS/VGCS呼叫具有2个调度员,且呼叫是调度员1发起的,MSC Server需要在媒体网关上建立调度员的接入端点。下面参照图7描述本发明的另一种调度员承载建立过程。
步骤71-72、MSC Server向MGW发送ADD.request消息,要求为调度员1建立调度员接入端点。如果调度员接入端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的调度员上下文(Cmpty)和调度员接入端点(T1)标识,这对应的是3GPP TS 29.232中描述的准备承载过程(PrepareBearer)。如果调度员接入端点是TDM端点,MSC Server在ADD.request消息中已经指明了调度员接入端点标识T1,MGW使用ADD.reply消息响应,返回它所分配的调度员上下文(Cmpty)标识,这对应的是3GPP TS 29.232中描述的保留电路过程(Reserve Circuit)。调度员所在的上下文,也同时承担会议桥的功能,完成各调度员及讲者话音的混音。
步骤73-74、调度员2与调度员1的建立过程相同,只是Cmpty已经由调度员1建立,在本步骤中直接使用这个上下文即可,不需要由MGW分配新的上下文。二、讲者承载的建立方法
对于VBS/VGCS呼叫中的“讲者”,处理方式与调度员类似,可以放在独立的上下文中,也可以直接放在会议桥上下文中,但是其语音效果应与调度员区分开(例如使用端点的属性来指示)。对于VGCS呼叫中的“讲者”,如果不希望使用扩展端点属性的方法来指示与调度员不同语音效果,可以把“讲者”放在独立的上下文中,同时建立“讲者”上下文到会议桥上下文的两个单向内部连接。单向内部连接可以通过单向拓扑、和/或单向流模式来指定。此时,讲者的发言会通过上行单向通道进入会议混音,同时他的发言又包含在混音之中,通过下行单向通道播放给讲者自己。
1、第一种讲者承载模型的建立方法
图8示出了第一种讲者承载模型,在该种讲者承载模型中,讲者的接入端点和会议桥使用不同的上下文,二者之间使用一个双向内部连接相连。本实施例假设呼叫由讲者发起,下面参照图9描述本发明的第一种讲者承载的建立过程。
步骤91-92、MSC Server在收到VBS/VGCS签约用户发起的VBS/VGCS呼叫时,需要在媒体网关上建立VBS/VGCS签约用户的讲者接入端点和包括讲者接入端点的讲者上下文。
MSC Server向MGW发送ADD.request消息,要求为讲者建立讲者接入端点。如果讲者接入端点是分组端点(ATM或者IP),MGW使用ADD.reply(增加响应)消息响应,返回它所分配的讲者上下文(C1)和讲者接入端点(T1)标识,这对应的是3GPP TS 29.232中描述的准备承载过程(Prepare Bearer)。如果讲者接入端点是TDM(时分复用)端点,MSC Server在ADD.request消息中已经指明了讲者接入端点标识T1,MGW使用ADD.reply消息响应,返回它所分配的讲者上下文(C1)标识,这对应的是3GPP TS 29.232中描述的保留电路过程(Reserve Circuit)。
步骤93-94、MSC Server向MGW发送ADD.request消息,要求建立一个会议桥上下文,以及用于连接讲者的讲者代理端点。如果讲者代理端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的会议桥上下文(Cmpty)和讲者代理端点(T10)标识,这对应的是3GPP TS 29.232中描述的准备承载过程(Prepare Bearer)。如果讲者连接端点是TDM端点,MSC Server在ADD.request消息中已经指明了讲者代理端点标识T10,MGW使用ADD.reply消息响应,返回它所分配的会议桥上下文(Cmpty)标识,这对应的是3GPP TS29.232中描述的保留电路过程(Reserve Circuit)。
MSC Server在建立讲者代理端点T10时,下发的命令ADD.request($,mode=speaker)中携带了一个模式参数,指示这是讲者。模式参数可以是讲者端点的一个属性,以便媒体网关对于讲者执行与调度员不同的混音策略(例如扩充一种新的StreamMode=SendRecvLoopBack,媒体网关能将讲者的语音与调度员混合后,又送回讲者端点)。
步骤95-96、MSC Server向MGW发送ADD.request消息,要求在上下文C1中建立一个讲者连接端点,以便连接到会议桥。如果讲者连接端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的讲者连接端点(T11)标识,这对应的是3GPP TS 29.232中描述的建立承载过程(EstablishBearer)。如果讲者连接端点是TDM端点,MSC Server在ADD.request消息中已经指明了讲者连接端点标识T11,MGW使用ADD.reply消息响应,这对应的是3GPP TS 29.232中描述的保留电路过程(Reserve Circuit)。然后使讲者接入端点与讲者连接端点相连。这样,讲者到会议桥的承载通路就建立起来了。
2、第二种讲者承载模型的建立方法
图10示出了第二种承载模型,在该种讲者承载模型中,讲者的接入端点和会议桥使用相同的上下文。本实施例假设呼叫由讲者发起,下面参照图11描述本发明的第二种讲者承载的建立过程。
步骤111-112、MSC Server在收到VBS/VGCS签约用户发起的VBS/VGCS呼叫时,向MGW发送ADD.request消息,为讲者建立讲者接入端点。如果讲者接入端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的讲者上下文(Cmpty)和讲者接入端点(T1)标识,这对应的是3GPPTS 29.232中描述的准备承载过程(Prepare Bearer)。如果讲者接入端点是TDM端点,MSC Server在ADD.request消息中已经指明了讲者接入端点标识T1,MGW使用ADD.reply消息响应,返回它所分配的讲者上下文(Cmpty)标识,这对应的是3GPP TS 29.232中描述的保留电路过程(Reserve Circuit)。讲者所在的上下文,也同时承担会议桥的功能,完成各调度员及讲者话音的混音。
MSC Server在建立端点T1时,下发的命令ADD.request($,mode=speaker)中携带了一个模式参数,指示这是讲者。模式参数可以是端点的一个属性,以便媒体网关对于讲者执行与调度员不同的混音策略(例如扩充一种新的StreamMode=SendRecvLoopBack,媒体网关能将讲者的语音与调度员混合后,又送回讲者端点)。
3、第三种讲者承载模型的建立方法
图12示出了第三种讲者承载模型,在该种讲者承载模型中,讲者的接入端点和会议桥使用不同的上下文,二者之间使用两个单向内部连接相连。
MSC Server在收到VBS/VGCS签约用户发起的VBS/VGCS呼叫时,需要在媒体网关上建立VBS/VGCS签约用户的讲者接入端点和包括讲者接入端点的讲者上下文,以及在讲者上下文中建立连接到会议桥的讲者上行连接端点和讲者下行连接端点。这个过程与集群业务的调度员的第一种承载模型的建立过程是类似的,区别在于讲者具有两个单向的连接端点。本实施例假设呼叫由讲者发起,下面参照图13描述本发明的第三种讲者承载的建立过程。
步骤1301-1302、MSC Server向MGW发送ADD.request消息,要求为讲者建立讲者接入端点。如果讲者接入端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的讲者上下文(C1)和讲者接入端点(T1)标识,这对应的是3GPP TS 29.232中描述的准备承载过程(Prepare Bearer)。如果接入端点是TDM端点,MSC Server在ADD.request消息中已经指明了讲者接入端点标识T1,MGW使用ADD.reply消息响应,返回它所分配的讲者上下文(C1)标识,这对应的是3GPP TS 29.232中描述的保留电路过程(ReserveCircuit)。
步骤1303-1306、MSC Server向MGW发送两条ADD.request消息,要求建立一个会议桥上下文,在会议桥上下文中建立用于连接讲者上下文中上行连接端点和下行连接端点的讲者上行代理端点和讲者下行代理端点。如果代理端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的上下文(Cmpty)和讲者上行代理端点和讲者下行代理端点(T10、T12)标识,这对应的是3GPP TS 29.232中描述的准备承载过程(Prepare Bearer)。如果代理端点是TDM端点,MSC Server在ADD.request消息中已经指明了端点标识T10、T12,MGW使用ADD.reply消息响应,返回它所分配的上下文(Cmpty)标识,这对应的是3GPP TS 29.232中描述的保留电路过程(Reserve Circuit)。注意,T10设置了recvOnly的流模式、T12设置了SendOnly的流模式;但T10、T12使用sendrecv的流模式也是可以的。
步骤1307-1310、MSC Server向MGW发送两条ADD.request消息,要求在讲者上下文C1中建立讲者上行连接端点和讲者下行连接端点,连接到会议桥上下文的讲者上行代理端点和讲者下行代理端点。如果讲者连接端点是分组端点(ATM或者IP),MGW使用两条ADD.reply消息响应,返回它所分配的讲者上行连接端点和讲者下行连接端点(T11、T13)标识,这对应的是3GPP TS 29.232中描述的建立承载过程(Establish Bearer)。如果讲者连接端点是TDM端点,MSC Server在两条ADD.request消息中已经指明了讲者连接端点标识T11、T13,MGW使用ADD.reply消息响应,这对应的是3GPP TS 29.232中描述的保留电路过程(Reserve Circuit)。注意,T13设置了recvOnly的流模式、T11设置了SendOnly的流模式;但T11、T13使用sendrecv的流模式也是可以的。此外,T1要设置到T11的单向拓扑,T13要设置到T1的单向拓扑。这样,讲者到会议桥的承载通路就建立起来了。
三、听者承载的建立方法
对于VBS/VGCS呼叫中的“听者”,由于多个“听者”听到的语音效果完全一样,因此无需在会议桥上下文中为每个“听者”都建立一个端点。在会议桥上下文中只需要建立一个“听者代理”,它获取讲者与各调度员的混音,并多播给所有的“听者”。“听者代理”不需要参与混音,因此可以设置单向拓扑或者单向流模式。听者的承载模型也有多种,下面分别描述之。
1、第一种听者承载模型的建立方法
图14示出了第一种听者承载模型,在该听者承载模型中,各听者接入端点放在独立的上下文中,以便通过多播实现会议桥到听者的单向连接。
MSC Server在收到VBS/VGCS呼叫时,向该组呼ID中预定小区中的签约用户指示呼叫,并为各小区中的听者建立承载通道。MSC Server需要在媒体网关上建立听者所在小区的接入端点,以及到会议桥的内部连接端点。下面参照图15描述本发明的第一种听者承载的建立过程。
步骤1501-1502、MSC Server向MGW发送ADD.request消息,要求为听者1建立听者接入端点。如果接入端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的听者上下文(C1)和听者接入端点(T1)标识,这对应的是3GPP TS 29.232中描述的准备承载过程(Prepare Bearer)。如果接入端点是TDM端点,MSC Server在ADD.request消息中已经指明了听者接入端点标识T1,MGW使用ADD.reply消息响应,返回它所分配的听者上下文(C1)标识,这对应的是3GPP TS 29.232中描述的保留电路过程(ReserveCircuit)。
步骤1503-1504、MSC Server向MGW发送ADD.request消息,在VBS/VGCS呼叫发起者已经建立的会议桥上下文Cmpty中,建立听者代理端点。如果听者代理端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的听者代理端点(Tlp)标识,这对应的是3GPP TS 29.232中描述的准备承载过程(Prepare Bearer)。如果内部连接端点是TDM端点,MSC Server在ADD.request消息中已经指明了听者代理端点标识Tlp,MGW使用ADD.reply消息响应,这对应的是3GPP TS 29.232中描述的保留电路过程(Reserve Circuit)。注意,ADD.request消息应携带多播请求指示,以便媒体网关根据多播配置返回多播地址,所述的多播地址可能是一个IP多播地址,或者是一个单播地址,或者是一个内部的共享音源通道标识,依据所采用的多播技术而定。
步骤1505-1506、MSC Server向MGW发送ADD.request消息,要求在听者上下文C1中建立一个听者连接端点,以便连接到会议桥上下文中的听者代理端点。如果听者连接端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的听者连接端点(T11)标识,这对应的是3GPP TS 29.232中描述的建立承载过程(Establish Bearer)。如果听者连接端点是TDM端点,MSC Server在ADD.request消息中已经指明了听者连接端点标识T11,MGW使用ADD.reply消息响应,这对应的是3GPP TS 29.232中描述的保留电路过程(Reserve Circuit)。这样,听者到会议桥的承载通路就建立起来了。此外,ADD.request消息应携带多播参数指示,将媒体网关在步骤1503-1504返回的多播参数下发给这个听者连接端点T11,以便建立听者代理端点到听者连接端点的下行多播通道。
听者2、3与听者1的建立过程相同,只是听者代理端点Tlp已经由听者1建立,可以跳过步骤步骤1503-1504,直接由步骤1501-1502进入步骤1505-1506。
注意,如果“讲者”使用了两个单向连接(即讲者的第三种承载模型),则下行单向连接可以与听者代理共用一个多播通道。即“讲者下行代理”与“听者代理”是同一个端点,这样可以节省媒体网关上的资源。
这种承载模型是将各听者放在独立的上下文中,建立“听者代理”到多个“听者”的单向通道,此时需要MSC server向媒体网关指示一些多播相关的参数,例如向“听者代理”和“听者”指示多播地址,以便“听者代理”向指定的多播地址发送混音音频流,“听者”则从指定的多播地址接收混音音频流;或者向“听者代理”指示多个单播地址,以便“听者代理”向各单播地址对应的“听者”复制和分发混音音频流;或者向“听者代理”和“听者”指示共享音源通道,以便“听者代理”将混音音频流送到该通道,而“听者”从该通道获取混音音频流。
由于“听者”数量众多,因此将各听者放在独立的上下文中,便于媒体网关将一个集群呼叫分散到多个处理模块上去处理,有利于降低媒体网关的负荷,提高响应速度。此外还能减少一个上下文中的端点数量,降低拓扑描述的复杂性。
2、第二种听者承载模型
图16示出了第二种听者承载模型,在该听者承载模型中,各听者放在相同的上下文中,通过一个内部连接实现会议桥到听者的单向连接。
MSC Server在收到VBS/VGCS呼叫时,向该组呼ID中预定小区中的签约用户指示呼叫,并为各小区中的听者建立承载通道。MSC Server需要在媒体网关上建立听者所在小区的接入端点,以及到会议桥的内部连接端点。下面参照图17以听者1为例描述本发明的第二种听者承载的建立过程。
步骤1701-1702、MSC Server向MGW发送ADD.request消息,要求为听者1建立听者接入端点。如果听者接入端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的听者上下文(C1)和听者接入端点(T1)标识,这对应的是3GPP TS 29.232中描述的准备承载过程(Prepare Bearer)。如果接入端点是TDM端点,MSC Server在ADD.request消息中已经指明了听者接入端点标识T1,MGW使用ADD.reply消息响应,返回它所分配的听者上下文(C1)标识,这对应的是3GPP TS 29.232中描述的保留电路过程(ReserveCircuit)。
步骤1703-1704、MSC Server向MGW发送ADD.request消息,在VBS/VGCS呼叫发起者已经建立的会议桥上下文Cmpty中,建立听者代理端点。如果听者代理端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的听者代理端点(Tlp0)标识,这对应的是3GPP TS 29.232中描述的准备承载过程(Prepare Bearer)。如果听者代理端点是TDM端点,MSC Server在ADD.request消息中已经指明了听者代理端点标识Tlp0,MGW使用ADD.reply消息响应,这对应的是3GPP TS 29.232中描述的保留电路过程(ReserveCircuit)。
步骤1705-1706、MSC Server向MGW发送ADD.request消息,要求在上下文C1中建立一个听者连接端点,以便连接到会议桥的听者代理端点。如果听者连接端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的听者连接端点(Tlp1)标识,这对应的是3GPP TS 29.232中描述的建立承载过程(Establish Bearer)。如果听者连接端点是TDM端点,MSC Server在ADD.request消息中已经指明了听者连接端点标识Tlp1,MGW使用ADD.reply消息响应,这对应的是3GPP TS 29.232中描述的保留电路过程(ReserveCircuit)。此外,应该指示Tlp1到T1的单向拓扑关系,和/或指示T1的StreamMode为sendOnly。这样,听者1到会议桥的承载通路就建立起来了。
对于听者2、3的承载过程,只需要在C1中建立听者接入端点T2、T3,并指示Tlp1到T2、T3的单向拓扑关系,即指示T2、T3的StreamMode为sendOnly。
以上听者承载建立步骤中建立的端点,可以描述单向拓扑、单向流模式,以便帮助网关判断媒体流向,减少占用的资源,这是因为各听者所公用的上下文中,只有听者连接端点在向听者接入端点发送媒体流,因此该上下文的所有拓扑都是听者连接端点指向各听者接入端点的单向拓扑,或者虽然没有描述拓扑,但该上下文中的所有端点中,只有听者连接端点的StreamMode是recvOnly,其它端点都是sendOnly,媒体网关不必分配会议桥资源,直接将听者连接端点收到的媒体流发送给各听者接入端点即可。
注意,如果“讲者”使用了两个单向连接(即讲者的第三种承载模型),则下行单向连接可以与其它听者接入端点共用一个下行多播通道。即讲者下行代理端点直接从听者连接端点上接收媒体流(如图16所示),这样可以节省媒体网关上的资源。
将所有“听者”放在一个上下文中,同时指定到“听者”的单向拓扑,或者指定“听者”的单向流模式,还可以把拓扑和流模式结合起来使用,通过单向拓扑和/或流模式,向媒体网关指示并不需要进行混音,从而避免媒体网关使用不必要的会议资源,此时多播发生在媒体网关内部,对MSC server不可见。
以上“调度员”、“讲者”、“听者”各自都描述了多种承载模型,这些承载模型是可以按照任何允许的形式搭配使用的。例如在图8中,调度员1使用的是第一种承载模型,即调度员接入端点使用一个独立上下文,通过调度员连接端点连接到会议桥上下文中;而调度员2使用的是第二种承载模型,即调度员接入端点直接放在会议桥上下文中。
在VBS/VGCS业务中,调度员是系统中预先配置的,一个集群可以不配置任何调度员。此时,在承载模型中只有讲者和听者。由于任一时刻都只有一个VBS/VGCS签约用户在说话,因此媒体网关上不需要插入会议桥资源,直接将讲者的语音发送给听者即可。
讲者的三种承载模型和听者的两种承载模型仍然适用。其信令流程也完全相同。例如图16采用的是讲者的第三种承载模型和听者的第二种承载模型,如果没有调度员,它就退化为图18,此时讲者上行代理端点和听者代理端点所处的上下文Cmpty实际上是一个普通的上下文,没有占用会议桥资源。
实施例一
本实施例描述了一种调度员发起的VBS呼叫,“调度员”、“听者”搭配,没有“讲者”的情形,即采用调度员第一种承载模型和听者第一种承载模型。
1、建立调度员承载
如图4所示,MSC Server在收到VBS/VGCS呼叫时,发现该呼叫所在的组已经定义了调度员,则需要发起到各调度员的正常呼叫过程,因此,要为各调度员建立承载通道。假定本次VBS/VGCS呼叫具有2个调度员,且呼叫是调度员1发起的,MSC Server需要在媒体网关上建立调度员的接入端点(可能是连接BSC的无线接入的地面电路,也可能是连接PLMN/ISDN网络的局间中继电路,或者是连接本MSC Server的其它MGW的局内承载),以及到会议桥的内部连接端点。下面参照图5描述调度员承载的建立过程。
步骤51-52、MSC Server向MGW发送ADD.request(增加请求)消息,要求为调度员1建立调度员接入端点。如果调度员接入端点是分组端点(ATM或者IP),MGW使用ADD.reply(增加响应)消息响应,返回它所分配的调度员上下文(C1)和调度员接入端点(T1)标识,这对应的是3GPP TS 29.232中描述的准备承载过程(Prepare Bearer)。如果调度员接入端点是TDM(时分复用)端点,MSC Server在ADD.request消息中已经指明了调度员接入端点标识T1,MGW使用ADD.reply消息响应,返回它所分配的调度员上下文(C1)标识,这对应的是3GPP TS 29.232中描述的保留电路过程(Reserve Circuit)。
步骤53-54、MSC Server向MGW发送ADD.request消息,要求建立一个会议桥上下文,以及用于连接调度员1的调度员代理端点。如果调度员代理端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的会议桥上下文(Cmpty)和调度员代理端点(T10)标识,这对应的是3GPP TS 29.232中描述的准备承载过程(Prepare Bearer)。如果调度员连接端点是TDM端点,MSC Server在ADD.request消息中已经指明了调度员代理端点标识T10,MGW使用ADD.reply消息响应,返回它所分配的会议桥上下文(Cmpty)标识,这对应的是3GPP TS 29.232中描述的保留电路过程(Reserve Circuit)。
步骤55-56、MSC Server向MGW发送ADD.request消息,要求在上下文C1中建立一个调度员连接端点,以便连接到会议桥。如果调度员连接端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的调度员连接端点(T11)标识,这对应的是3GPP TS 29.232中描述的建立承载过程(Establish Bearer)。如果调度员连接端点是TDM端点,MSC Server在ADD.request消息中已经指明了调度员连接端点标识T11,MGW使用ADD.reply消息响应,这对应的是3GPP TS 29.232中描述的保留电路过程(ReserveCircuit)。这样,调度员1到会议桥的承载通路就建立起来了。
步骤57-512为调度员2承载的建立过程,其与调度员1承载的建立过程相同,只是Cmpty已经由调度员1建立,在第59-510步骤直接使用这个上下文即可,不需要由MGW分配新的上下文。
2、建立听者承载
图14示出了本实施例的听者承载模型,在该听者承载模型中,各听者接入端点放在独立的上下文中,以便通过多播实现会议桥到听者的单向连接。
MSC Server在收到VBS/VGCS呼叫时,向该组呼ID中预定小区中的签约用户指示呼叫,并为各小区中的听者建立承载通道。MSC Server需要在媒体网关上建立听者所在小区的接入端点,以及到会议桥的内部连接端点。下面参照图15描述本发明的第一种听者承载的建立过程。
步骤1501-1502、MSC Server向MGW发送ADD.request消息,要求为听者1建立听者接入端点。如果接入端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的听者上下文(C1)和听者接入端点(T1)标识,这对应的是3GPP TS 29.232中描述的准备承载过程(Prepare Bearer)。如果接入端点是TDM端点,MSC Server在ADD.request消息中已经指明了听者接入端点标识T1,MGW使用ADD.reply消息响应,返回它所分配的听者上下文(C1)标识,这对应的是3GPP TS 29.232中描述的保留电路过程(ReserveCircuit)。
步骤1503-1504、MSC Server向MGW发送ADD.request消息,在VBS/VGCS呼叫发起者已经建立的会议桥上下文Cmpty中,建立听者代理端点。如果听者代理端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的听者代理端点(Tlp)标识,这对应的是3GPP TS 29.232中描述的准备承载过程(Prepare Bearer)。如果内部连接端点是TDM端点,MSC Server在ADD.request消息中已经指明了听者代理端点标识Tlp,MGW使用ADD.reply消息响应,这对应的是3GPP TS 29.232中描述的保留电路过程(Reserve Circuit)。注意,ADD.request消息应携带多播请求指示,以便媒体网关根据多播配置返回多播地址,所述的多播地址可能是一个IP多播地址,或者是一个单播地址,或者是一个内部的共享音源通道标识,依据所采用的多播技术而定。
步骤1505-1506、MSC Server向MGW发送ADD.request消息,要求在听者上下文C1中建立一个听者连接端点,以便连接到会议桥上下文中的听者代理端点。如果听者连接端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的听者连接端点(T11)标识,这对应的是3GPP TS 29.232中描述的建立承载过程(Establish Bearer)。如果听者连接端点是TDM端点,MSC Server在ADD.request消息中已经指明了听者连接端点标识T11,MGW使用ADD.reply消息响应,这对应的是3GPP TS 29.232中描述的保留电路过程(Reserve Circuit)。这样,听者到会议桥的承载通路就建立起来了。此外,ADD.request消息应携带多播参数指示,将媒体网关在步骤1503-1504返回的多播参数下发给这个听者连接端点T11,以便建立听者代理端点到听者连接端点的下行多播通道。
听者2、3与听者1的建立过程相同,只是听者代理端点Tlp已经由听者1建立,可以跳过步骤步骤1503-1504,直接由步骤1501-1502进入步骤1505-1506。
这种承载模型是将各听者放在独立的上下文中,建立“听者代理”到多个“听者”的单向通道,此时需要MSC server向媒体网关指示一些多播相关的参数,例如向“听者代理”和“听者”指示多播地址,以便“听者代理”向指定的多播地址发送混音音频流,“听者”则从指定的多播地址接收混音音频流;或者向“听者代理”指示多个单播地址,以便“听者代理”向各单播地址对应的“听者”复制和分发混音音频流;或者向“听者代理”和“听者”指示共享音源通道,以便“听者代理”将混音音频流送到该通道,而“听者”从该通道获取混音音频流。
由于“听者”数量众多,因此将各听者放在独立的上下文中,便于媒体网关将一个集群呼叫分散到多个处理模块上去处理,有利于降低媒体网关的负荷,提高响应速度。此外还能减少一个上下文中的端点数量,降低拓扑描述的复杂性。
当调度员承载和听者承载建立完毕后,调度员可以向会议桥上下文发送话音,听者可听到各调度员的混音。
实施例二
本实施例描述了另一种“调度员”、“讲者”、“听者”搭配情形,即采用调度员第二种承载模型,讲者第三种承载模型和听者第二种承载模型,在本实施例中,假设讲者发起VBS/VGCS呼叫。
1、建立讲者承载
图12示出了本实施例的讲者承载模型,在该种讲者承载模型中,讲者的接入端点和会议桥使用不同的上下文,二者之间使用两个单向内部连接相连。
MSC Server在收到VBS/VGCS签约用户发起的VBS/VGCS呼叫时,需要在媒体网关上建立VBS/VGCS签约用户的讲者接入端点和包括讲者接入端点的讲者上下文,以及在讲者上下文中建立连接到会议桥的讲者上行连接端点和讲者下行连接端点。这个过程与集群业务的调度员的第一种承载模型的建立过程是类似的,区别在于讲者具有两个单向的连接端点。本实施例假设呼叫由讲者发起,下面参照图13描述本发明的第三种讲者承载的建立过程。
步骤1301-1302、MSC Server向MGW发送ADD.request消息,要求为讲者建立讲者接入端点。如果讲者接入端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的讲者上下文(C1)和讲者接入端点(T1)标识,这对应的是3GPP TS 29.232中描述的准备承载过程(Prepare Bearer)。如果接入端点是TDM端点,MSC Server在ADD.request消息中已经指明了讲者接入端点标识T1,MGW使用ADD.reply消息响应,返回它所分配的讲者上下文(C1)标识,这对应的是3GPP TS 29.232中描述的保留电路过程(ReserveCircuit)。
步骤1303-1306、MSC Server向MGW发送两条ADD.request消息,要求建立一个会议桥上下文,在会议桥上下文中建立用于连接讲者上下文中上行连接端点和下行连接端点的讲者上行代理端点和讲者下行代理端点。如果代理端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的上下文(Cmpty)和讲者上行代理端点和讲者下行代理端点(T10、T12)标识,这对应的是3GPP TS 29.232中描述的准备承载过程(Prepare Bearer)。如果代理端点是TDM端点,MSC Server在ADD.request消息中已经指明了端点标识T10、T12,MGW使用ADD.reply消息响应,返回它所分配的上下文(Cmpty)标识,这对应的是3GPP TS 29.232中描述的保留电路过程(Reserve Circuit)。注意,T10设置了recvOnly的流模式、T12设置了SendOnly的流模式;但T10、T12使用sendrecv的流模式也是可以的。
步骤1307-1310、MSC Server向MGW发送两条ADD.request消息,要求在讲者上下文C1中建立讲者上行连接端点和讲者下行连接端点,连接到会议桥上下文的讲者上行代理端点和讲者下行代理端点。如果讲者连接端点是分组端点(ATM或者IP),MGW使用两条ADD.reply消息响应,返回它所分配的讲者上行连接端点和讲者下行连接端点(T11、T13)标识,这对应的是3GPP TS 29.232中描述的建立承载过程(Establish Bearer)。如果讲者连接端点是TDM端点,MSC Server在两条ADD.request消息中已经指明了讲者连接端点标识T11、T13,MGW使用ADD.reply消息响应,这对应的是3GPP TS 29.232中描述的保留电路过程(Reserve Circuit)。注意,T13设置了recvOnly的流模式、T11设置了SendOnly的流模式;但T11、T13使用sendrecv的流模式也是可以的。此外,T1要设置到T11的单向拓扑,T13要设置到T1的单向拓扑。这样,讲者到会议桥的承载通路就建立起来了。
2、建立调度员承载
图6示出本实施例的调度员承载模型,在该承载模型中,调度员的接入端点和会议桥使用相同的上下文。
MSC Server在收到VBS/VGCS呼叫时,如发现该组呼ID已经定义了调度员,则需要发起到各调度员的正常呼叫过程,并为各调度员建立承载通道。假定本次VBS/VGCS呼叫具有2个调度员,MSC Server需要在媒体网关上建立调度员的接入端点。下面参照图7描述本实施例的调度员承载建立过程。
步骤71-72、MSC Server向MGW发送ADD.request消息,要求在会议桥上下文中为调度员1建立调度员接入端点。如果调度员接入端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的调度员接入端点(T1)标识,这对应的是3GPP TS 29.232中描述的准备承载过程(Prepare Bearer)。如果调度员接入端点是TDM端点,MSC Server在ADD.request消息中已经指明了调度员接入端点标识T1,MGW使用ADD.reply消息响应,这对应的是3GPPTS 29.232中描述的保留电路过程(Reserve Circuit)。
步骤73-74、调度员2与调度员1的建立过程相同。
3、建立听者承载
图16示出了本实施例的听者承载模型,在该听者承载模型中,各听者放在相同的上下文中,通过一个内部连接实现会议桥到听者的单向连接。
MSC Server在收到VBS/VGCS呼叫时,向该组呼ID中预定小区中的签约用户指示呼叫,并为各小区中的听者建立承载通道。MSC Server需要在媒体网关上建立听者所在小区的接入端点,以及到会议桥的内部连接端点。下面参照图17以听者1为例描述本实施例的听者承载的建立过程。
步骤1701-1702、MSC Server向MGW发送ADD.request消息,要求为听者1建立听者接入端点。如果听者接入端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的听者上下文(C1)和听者接入端点(T1)标识,这对应的是3GPP TS 29.232中描述的准备承载过程(Prepare Bearer)。如果接入端点是TDM端点,MSC Server在ADD.request消息中已经指明了听者接入端点标识T1,MGW使用ADD.reply消息响应,返回它所分配的听者上下文(C1)标识,这对应的是3GPP TS 29.232中描述的保留电路过程(ReserveCircuit)。
步骤1703-1704、MSC Server向MGW发送ADD.request消息,在VBS/VGCS呼叫发起者已经建立的会议桥上下文Cmpty中,建立听者代理端点。如果听者代理端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的听者代理端点(Tlp0)标识,这对应的是3GPP TS 29.232中描述的准备承载过程(Prepare Bearer)。如果听者代理端点是TDM端点,MSC Server在ADD.request消息中已经指明了听者代理端点标识Tlp0,MGW使用ADD.reply消息响应,这对应的是3GPP TS 29.232中描述的保留电路过程(ReserveCircuit)。
步骤1705-1706、MSC Server向MGW发送ADD.request消息,要求在上下文C1中建立一个听者连接端点,以便连接到会议桥的听者代理端点。如果听者连接端点是分组端点(ATM或者IP),MGW使用ADD.reply消息响应,返回它所分配的听者连接端点(Tlp1)标识,这对应的是3GPP TS 29.232中描述的建立承载过程(Establish Bearer)。如果听者连接端点是TDM端点,MSC Server在ADD.request消息中已经指明了听者连接端点标识Tlp1,MGW使用ADD.reply消息响应,这对应的是3GPP TS 29.232中描述的保留电路过程(ReserveCircuit)。此外,应该指示Tlp1到T1的单向拓扑关系,和/或指示T1的StreamMode为sendOnly。这样,听者1到会议桥的承载通路就建立起来了。
对于听者2、3的承载过程,只需要在C1中建立听者接入端点T2、T3,并指示T1p1到T2、T3的单向拓扑关系,即指示T2、T3的StreamMode为sendOnly。
以上听者承载建立步骤中建立的端点,可以描述单向拓扑、单向流模式,以便帮助网关判断媒体流向,减少占用的资源,这是因为各听者所公用的上下文中,只有听者连接端点在向听者接入端点发送媒体流,因此该上下文的所有拓扑都是听者连接端点指向各听者接入端点的单向拓扑,或者虽然没有描述拓扑,但该上下文中的所有端点中,只有听者连接端点的StreamMode是recvOnly,其它端点都是sendOnly,媒体网关不必分配会议桥资源,直接将听者连接端点收到的媒体流发送给各听者接入端点即可。
如图19所示,本发明还公开了一种实现集群通信业务的系统,包括:讲者终端,用于发起集群呼叫;讲者承载建立单元,用于建立讲者承载和会议桥上下文,通过讲者承载将讲者终端和会议桥上下文相连;调度员建立承载单元,用于建立调度员承载,通过调度员承载将调度员终端连接到会议桥上下文;听者代理建立单元,用于在会议桥上下文中建立听者代理端点,所述的听者代理端点用于将讲者或/和调度员的话音发给听者终端;听者承载建立单元,用于建立听者承载,通过听者承载将听者终端连接到会议桥上下文。
如图20所示,本发明还公开了另一种实现集群通信业务的系统,包括:调度员终端,用于发起集群呼叫;调度员承载建立单元,用于建立调度员承载和会议桥上下文,通过调度员承载将调度员终端与会议桥上下文相连;听者端点代理建立单元,用于在会议桥上下文中建立听者代理端点,所述的听者代理端点用于将调度员的话音发给听者终端;听者承载建立单元,用于建立听者承载,使听者承载连接到会议桥上下文。
如图21所示,本发明还公开了一种集群通信的方法,下面参照图19描述本发明的集群通信方法。
步骤2101、讲者终端向会议桥上下文的讲者代理端点发送话音;
步骤2102、调度员终端向会议桥上下文的调度员代理端点或者调度员接入端点发送话音;
步骤2103、会议桥上下文将所述的讲者话音和调度员话音进行混音处理形成新的话音发给听者代理端点。
步骤2104、听者代理端点将来自会议桥的话音发给听者连接端点;
步骤2105、听者连接端点将来自听者代理端点的话音发给听者接入端点;
步骤2106、听者接入端点将来自听连接端点的话音发给听者终端。
“听者代理”向“听者”多播话音,可以有多种实现方式。下面仅介绍三个例子。
1、如果媒体网关的内部网络支持多播协议,例如IP多播,移动交换中心服务器或媒体网关将听者归入多播组。此时“听者代理”向一个多播地址发送混音音频流(其中包含讲者与各调度员的语音),MSC server或媒体网关将同一集群的听者归入该多播组,因此听者都能接收到“听者代理”所发送的数据。
2、如果媒体网关的内部网络不支持多播协议,可使用“多-单播”技术,即“听者代理”端点发送超过一份的媒体流拷贝到不同的听者端点。此时“听者代理”需要向多个单播地址同时发送混音音频流(其中包含讲者与各调度员的语音)。
3、采用类似异步音的方式。H.248标准指出,当一个事务中对多个端点下发相同的信号时,媒体网关可以考虑使用同一音源来产生这些信号。实际上,对于回铃、振铃之类的单音,无论端点是否在同一上下文中,也无论该信号是否在一个事务中下发,都可以共享一个音源。因此,如果媒体网关支持这种技术,就可以把集群中的混音音频流当作一个共享音源的信号,发送给各听者。此时,“听者代理”向一个共享音源通道发送混音音频流(其中包含讲者与各调度员的语音),而各听者守候在该共享音源通道上收听语音,这种连接在媒体网关内部实现(例如通过TDM背板连接)。
在集群通信过程中,VBS的签约用户,除了发起呼叫者可说话,其它签约用户始终没有发言权限。因此一旦按照上述步骤建立起调度员、讲者、听者的承载之后,在通话过程中,就不需要进行后续的承载操作了。
但是对于VGCS的签约用户,当讲者发言完毕时,其它的VGCS签约用户(听者)可以按PTT键申请发言权限,在没有其它说话的VGCS签约用户的情况下,系统即授予该听者发言权限,该听者成为新的讲者。这样,就必须完成原讲者到听者的承载转换,以及某个听者到新讲者的承载转换。在VGCS通话过程中,讲者与听者的角色转换是非常频繁的,因此承载转换操作也应该尽量简洁,以便提高系统的响应时间。
无论讲者、听者采用的是哪一种承载模型,使用H.248的MOV(移动端点)指令,将讲者接入端点和听者接入端点的位置对调,都能实现讲者与听者的快速角色转换。下面以讲者的第三种承载模型、听者的第二种承载模型为例,说明这个过程。
当VGCS呼叫建立完成后,承载模型如图16所示,若此时作为讲者的VGCS签约用户发言完毕,而作为听者的一个VGCS签约用户(听者终端1)要求发言,则系统应将原讲者终端改为听者承载,将原听者终端1改为讲者承载。下面参照图22描述讲者与听者的角色转换过程。
步骤2201-2202、MSC Server向MGW发送MOV.request(移动请求)消息,要求将讲者接入端点T4从讲者上下文C2中移动到听者上下文C1中,并指示听者连接端点Tlp1到T4的单向拓扑关系,和/或指示T4的StreamMode为sendOnly。这样,讲者接入端点T4就失去了发言权,降格成为听者接入端点T4,讲者终端也就成了听者终端4。MGW向MSC Server返回MOV.reply(移动响应)消息。此时的承载模型如图23所示。
步骤2203-2204、MSC Server向MGW发送MOV.request消息,要求将听者接入端点T1从听者上下文C1中,移动到讲者上下文C2中,并指示端点Tl到讲者上行连接端点的单向拓扑关系,以及讲者下行连接端点到端点T1的单向拓扑关系。这样,听者接入端点T1就获取了发言权,升格成为讲者接入端点T1,听者终端1也就成了讲者终端。MGW向MSC Server返回MOV.reply(移动响应)消息。此时的承载模型如图24所示。
如图25所示,本发明还公开了一种集群通信的系统,包括:用于向会议桥上下文的讲者代理端点发送话音的讲者终端;用于向会议桥上下文的调度员代理端点或者调度员接入端点发送话音的调度员终端;用于将所述的讲者话音发给听者代理端点的会议桥单元;用于将来自会议桥的话音发给听者连接端点的听者代理单元;用于将来自听者代理端点的话音发给听者接入端点的听者连接单元;用于将来自听连接端点的话音发给听者终端的听者接入单元,听者终端,用于接听听者接入单元的话音。
所述的系统还包括用于转换听者与讲者角色的角色转换单元。角色转换单元具体包括:用于将讲者接入端点从讲者上下文中移动到听者上下文中,并将听者连接端点到讲者接入端点置为单向拓扑关系的移动讲者接入端点单元;用于将听者接入端点从听者上下文中移动到讲者上下文中,将听者接入端点到讲者上行连接端点置为单向拓扑关系,将讲者下行连接端点到听者接入端点置为单向拓扑关系的移动听者接入端点单元。
在本发明集群通信的实现方法和集群通信中,可以没有调度员。
根据本发明,在H.248标准内,在不扩充新的包的前提下,就可实现集群业务。通过在会议桥上下文中采用听者代理,可以在会议桥上下文中大量减少端点的数目,从而大大缩减了集群业务中所使用的会议混音资源的数量。
虽然通过实施例描绘了本发明,但本领域普通技术人员知道,在不脱离本发明的精神和实质的情况下,就可使本发明有许多变形和变化,本发明的范围由所附的权利要求来限定。
Claims (29)
1.一种实现集群通信业务的方法,当呼叫者发起集群呼叫时,其特征在于,包括:
建立呼叫者承载和会议桥上下文,并通过呼叫者承载将呼叫者终端与会议桥上下文相连;
在会议桥上下文中建立听者代理端点,所述的听者代理端点用于将呼叫者的话音发给听者终端;
建立听者承载,并通过听者承载将听者端点连接到会议桥上下文的听者代理端点。
2.根据权利要求1所述的方法,其特征在于,所述的呼叫者包括讲者和调度员。
3.根据权利要求2所述的方法,其特征在于,当呼叫者为讲者时,所述的建立呼叫者承载具体包括:
建立讲者接入端点和包括讲者接入端点的讲者上下文,并将所述的讲者接入端点与讲者终端相连;
建立讲者代理端点和包含讲者代理端点的会议桥上下文;
在讲者上下文中建立讲者连接端点,并将会议桥上下文中的讲者代理端点与讲者上下文的讲者连接端点相连,讲者上下文中的讲者连接端点与讲者接入端点相连。
4.根据权利要求3所述的方法,其特征在于,所述的在会议桥上下文中建立讲者代理端点的过程中,所述的增加请求包括其值为讲者的模式参数。
5.根据权利要求2所述的方法,其特征在于,当呼叫者为讲者时,所述的建立呼叫者承载具体包括:
建立讲者接入端点和包含讲者接入端点的会议桥上下文,并将所述的讲者接入端点与讲者终端相连。
6.根据权利要求5所述的方法,其特征在于,所述的在会议桥上下文中建立讲者接入端点的过程中,所述的增加请求包括其值为讲者的模式参数。
7.根据权利要求4或6所述的方法,其特征在于,所述的方法还包括:媒体网关根据模式参数对讲者和调度员采用不同的混音策略。
8.根据权利要求2所述的方法,其特征在于,当呼叫者为讲者时,所述的建立呼叫者承载具体包括:
建立讲者接入端点和包括讲者接入端点的讲者上下文,并将所述的讲者接入端点与讲者终端相连;
建立会议桥上下文,并在会议桥上下文中建立讲者上行代理端点和讲者下行代理端点;
在讲者上下文中建立讲者上行连接端点和讲者下行连接端点,并将会议桥上下文的讲者上行代理端点与讲者上下文的讲者上行连接端点相连,会议桥上下文的讲者下行代理端点与讲者上下文的讲者下行连接端点相连,讲者接入端点分别与讲者上下文中的讲者上行连接端点和讲者下行连接端点相连。
9.根据权利要求2所述的方法,其特征在于,当呼叫者为讲者时,所述的方法还包括建立调度员承载。
10.根据权利要求9所述的方法,其特征在于,所述的建立调度员承载具体包括:
建立调度员接入端点和包括调度员接入端点的调度员上下文,并将所述的调度员接入端点与调度员终端相连;
在会议桥上下文中建立调度员代理端点;
在调度员上下文中建立调度员连接端点,并将会议桥上下文中的调度员代理端点与调度员上下文的调度员连接端点相连,将调度员上下文中的调度员接入端点与调度员连接端点相连。
11.根据权利要求9所述的方法,其特征在于,所述的建立调度员承载具体包括:
在会议桥上下文中建立调度员接入端点,将调度员接入端点与调度员终端相连。
12.根据权利要求2所述的方法,其特征在于,当呼叫者为调度员时,所述的建立呼叫者承载具体包括:
建立调度员接入端点和包括调度员接入端点的调度员上下文,并将所述的调度员接入端点与调度员终端相连;
建立调度员代理端点和包含调度员代理端点的会议桥上下文;
在调度员上下文中建立调度员连接端点,并使会议桥上下文中的调度员代理端点与调度员上下文的调度员连接端点相连,使调度员上下文中的调度员接入端点与调度员连接端点相连。
13.根据权利要求2所述的方法,其特征在于,当呼叫者为调度员时,所述的建立呼叫者承载具体包括:
建立调度员接入端点和包括调度员接入端点的会议桥上下文,并将调度员接入端点与调度员终端相连。
14.根据权利要求2所述的方法,其特征在于,当呼叫者为调度员时,所述的方法还包括建立讲者承载。
15.根据权利要求14所述的方法,其特征在于,所述的建立讲者承载具体包括:
建立讲者接入端点和包括讲者接入端点的讲者上下文,将所述的讲者接入端点与讲者终端相连;
在会议桥上下文中建立讲者代理端点,在讲者上下文中建立讲者连接端点,将会议桥上下文中的讲者代理端点与讲者上下文的讲者连接端点相连,将讲者上下文中的讲者接入端点与讲者连接端点相连。
16.根据权利要求14所述的方法,其特征在于,所述的建立讲者承载具体包括:
在会议桥上下文中建立讲者接入端点,将所述的讲者接入端点与讲者终端相连。
17.根据权利要求14所述的方法,其特征在于,所述的建立讲者承载具体包括:
建立讲者接入端点和包括讲者接入端点的讲者上下文,并将所述的讲者接入端点与讲者终端相连;
在会议桥上下文中建立讲者代理上行连接端点和讲者代理下行连接端点;
在讲者上下文中建立上行连接端点和下行连接端点,并将会议桥上下文的讲者代理上行连接端点与讲者上下文的上行连接端点相连,会议桥上下文的讲者代理下行连接端点与讲者上下文的下行连接端点相连,接入端点分别与讲者上下文中的上行连接端点和下行连接端点相连。
18.根据权利要求1至17其中之一所述的方法,其特征在于,所述的建立听者承载具体包括:
建立听者接入端点和包括听者接入端点的听者上下文,并将听者接入端点与听者终端相连;
在听者上下文中建立听者连接端点,并将会议桥上下文中的听者代理端点与听者上下文的听者连接端点相连,将听者上下文的听者连接端点与听者接入端点相连。
19.根据权利要求18所述的方法,其特征在于,在创建多个听者承载过程中,仅创造一个听者上下文,该过程中创建的所有听者接入端点包括在该听者下文中;或者,在创建听者承载过程中,创建每一个听者接入端点时创建一个包括该听者接入端点的听者上下文。
20.一种实现集群通信业务的系统,其特征在于,包括:
呼叫者终端,用于发起集群呼叫;
听者端点代理建立单元,用于在会议桥上下文中建立听者代理端点,所述的听者代理端点用于将呼叫者的话音发给听者终端;
听者承载建立单元,用于建立听者承载,并通过听者承载将听者终端连接到会议桥上下文的听者代理端点。
21.根据权利要求20所述的系统,其特在于,所述的呼叫者终端包括讲者终端和调度员终端。
22.一种集群通信的方法,其特征在于,包括:
讲者终端向会议桥上下文的讲者代理端点或讲者接入端点发送话音;
会议桥上下文将所述的讲者话音发给听者代理端点;
听者代理端点将来自会议桥的话音发给听者连接端点;
听者连接端点将来自听者代理端点的话音发给听者接入端点;
听者接入端点将来自听者连接端点的话音发给听者终端。
23.根据权利要求22所述的方法,其特征在于,所述的方法还包括:
调度员终端向会议桥上下文的调度员代理端点或者调度员接入端点发送话音;
会议桥上下文将所述的讲者话音和调度员话音进行混音处理形成新的话音发给听者代理端点。
24.根据权利要求22或23所述的方法,其特征在于,所述的听者代理端点将来自会议桥的话音发给听者连接端点具体包括:
移动交换中心服务器或媒体网关将听者连接端点归入多播组;
听者代理端点向多播组内的听者连接端点发送混音音频流。
25.根据权利要求22或23所述的方法,其特征在于,所述的听者代理端点将来自会议桥的话音发给听者连接端点具体包括:听者代理端点向多个听者连接端点的地址同时发送混音音频流。
26.根据权利要求22或23所述的方法,其特征在于,所述的听者代理端点将来自会议桥的话音发给听者连接端点具体包括:
听者代理端点向一个共享音源通道发送混音音频流;
各听者连接端点守候在该共享音源通道上收听语音。
27.根据权利要求22或23所述的方法,其特征在于,所述的方法还包括听者与讲者角色转换步骤,所述的听者与讲者角色转换步骤包括:
移动交换中心服务器向媒体网关发送移动请求消息,将媒体网关将讲者接入端点从讲者上下文中移动到听者上下文中,并将听者上下文中的听者连接端点到讲者接入端点置为单向拓扑关系;
移动交换中心服务器向媒体网关发送移动请求消息,将媒体网关将听者接入端点从听者上下文中移动到讲者上下文中,将听者接入端点到讲者上行连接端点置为单向拓扑关系,将讲者下行连接端点到听者接入端点置为单向拓扑关系。
28.一种集群通信的系统,其特征在于,包括:
用于向会议桥上下文的讲者代理端点或讲者接入端点发送话音的讲者终端;
用于将所述的讲者话音发给听者代理端点的会议桥单元;
用于将来自会议桥的话音发给听者连接端点的听者代理单元;
用于将来自听者代理端点的话音发给听者接入端点的听者连接单元;
用于将来自听者连接端点的话音发给听者终端的听者接入单元;
用于接收听者接入单元的听者终端。
29.根据权利要求28所述的系统,其特征在于,所述的系统还包括角色转换单元,用于使听者与讲者角色互相转换,所述的角色转换单元具体包括:
用于将讲者接入端点从讲者上下文中移动到听者上下文中,并将听者连接端点到讲者接入端点置为单向拓扑关系的移动讲者接入端点单元;
用于将听者接入端点从听者上下文中移动到讲者上下文中,将听者接入端点到讲者上行连接端点置为单向拓扑关系,将讲者下行连接端点到听者接入端点置为单向拓扑关系的移动听者接入端点单元。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2006101115281A CN100442877C (zh) | 2006-08-21 | 2006-08-21 | 一种实现集群通信业务的方法和系统 |
PCT/CN2007/002453 WO2008025230A1 (fr) | 2006-08-21 | 2007-08-14 | Procédé et système de fourniture de service de communication de groupe |
EP07785349A EP2061268B1 (en) | 2006-08-21 | 2007-08-14 | Method and system to achieve cluster communication service |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2006101115281A CN100442877C (zh) | 2006-08-21 | 2006-08-21 | 一种实现集群通信业务的方法和系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101119535A true CN101119535A (zh) | 2008-02-06 |
CN100442877C CN100442877C (zh) | 2008-12-10 |
Family
ID=39055423
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNB2006101115281A Active CN100442877C (zh) | 2006-08-21 | 2006-08-21 | 一种实现集群通信业务的方法和系统 |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP2061268B1 (zh) |
CN (1) | CN100442877C (zh) |
WO (1) | WO2008025230A1 (zh) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101860547A (zh) * | 2010-06-11 | 2010-10-13 | 中兴通讯股份有限公司 | 组呼或广播呼叫接续的控制方法、装置及系统 |
CN101868039A (zh) * | 2010-06-22 | 2010-10-20 | 中兴通讯股份有限公司 | 业务建立方法、装置和系统 |
WO2011160469A1 (zh) * | 2010-06-22 | 2011-12-29 | 中兴通讯股份有限公司 | 一种实现集群通信的方法及系统 |
CN103152185A (zh) * | 2013-02-27 | 2013-06-12 | 深圳大学 | 一种语音会议会场建立方法及系统 |
CN104980341A (zh) * | 2015-06-26 | 2015-10-14 | 上海迪静信息技术有限公司 | 一种实时连接多个移动终端远程调用数据的系统及其方法 |
CN106301812A (zh) * | 2015-05-20 | 2017-01-04 | 华为技术有限公司 | 多媒体会议实现方法、装置及系统 |
CN110121049A (zh) * | 2019-05-08 | 2019-08-13 | 视联动力信息技术股份有限公司 | 一种会议媒体流控制方法及装置 |
CN110831063A (zh) * | 2019-11-13 | 2020-02-21 | 深圳市共进电子股份有限公司 | 优化网络中继链路的方法、系统、计算机终端及存储介质 |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104427638B (zh) * | 2013-09-09 | 2019-09-17 | 中兴通讯股份有限公司 | 集群会话承载的建立方法、装置及设备 |
CN105656915B (zh) * | 2016-01-29 | 2019-01-18 | 腾讯科技(深圳)有限公司 | 即时通话方法、装置和系统 |
CN113556686B (zh) * | 2020-04-02 | 2022-07-08 | 成都鼎桥通信技术有限公司 | B-TrunC集群业务的EPS承载的识别方法和装置 |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6757259B1 (en) * | 1999-08-12 | 2004-06-29 | Intel Corporation | Control of internet based video conferencing |
US7161939B2 (en) * | 2001-06-29 | 2007-01-09 | Ip Unity | Method and system for switching among independent packetized audio streams |
US7469299B2 (en) * | 2001-10-25 | 2008-12-23 | Verizon Business Global Llc | Bridging user agent and a proxy server for supporting network services |
US7180997B2 (en) * | 2002-09-06 | 2007-02-20 | Cisco Technology, Inc. | Method and system for improving the intelligibility of a moderator during a multiparty communication session |
CN100417166C (zh) * | 2002-09-28 | 2008-09-03 | 中兴通讯股份有限公司 | 在会议中实现多路同时放音的方法 |
CN100359899C (zh) * | 2002-10-31 | 2008-01-02 | 中兴通讯股份有限公司 | 通过megaco协议在会议中实现多路同时放音的方法 |
CN100387031C (zh) * | 2003-06-03 | 2008-05-07 | 华为技术有限公司 | 一种虚拟媒体网关之间互通的方法 |
CN100393037C (zh) * | 2003-11-10 | 2008-06-04 | 中兴通讯股份有限公司 | 承载和控制相分离的通信网络中多方会议业务的实现方法 |
EP1560368A1 (fr) * | 2004-01-30 | 2005-08-03 | France Telecom | Procédé d'établissement d'une session multimédia entre un équipement appelant et un équipement appelé d'un réseau du type à sous domaine multimédia et système de communication mettant en oeuvre ce procédé |
CN100461715C (zh) * | 2004-04-29 | 2009-02-11 | Ut斯达康通讯有限公司 | 采用软交换体系实现合法监听的媒体控制方法 |
DE602004018199D1 (de) * | 2004-09-08 | 2009-01-15 | Ericsson Telefon Ab L M | Einer laufenden datensitzung |
EP1850614A1 (en) * | 2006-04-28 | 2007-10-31 | Nokia Siemens Networks Gmbh & Co. Kg | Advanced speech call items in networks comprising a MSC server and a media gateway |
-
2006
- 2006-08-21 CN CNB2006101115281A patent/CN100442877C/zh active Active
-
2007
- 2007-08-14 EP EP07785349A patent/EP2061268B1/en active Active
- 2007-08-14 WO PCT/CN2007/002453 patent/WO2008025230A1/zh active Application Filing
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101860547A (zh) * | 2010-06-11 | 2010-10-13 | 中兴通讯股份有限公司 | 组呼或广播呼叫接续的控制方法、装置及系统 |
WO2011153780A1 (zh) * | 2010-06-11 | 2011-12-15 | 中兴通讯股份有限公司 | 组呼或广播呼叫接续的控制方法、装置及系统 |
CN101868039A (zh) * | 2010-06-22 | 2010-10-20 | 中兴通讯股份有限公司 | 业务建立方法、装置和系统 |
WO2011160469A1 (zh) * | 2010-06-22 | 2011-12-29 | 中兴通讯股份有限公司 | 一种实现集群通信的方法及系统 |
CN103152185A (zh) * | 2013-02-27 | 2013-06-12 | 深圳大学 | 一种语音会议会场建立方法及系统 |
CN106301812A (zh) * | 2015-05-20 | 2017-01-04 | 华为技术有限公司 | 多媒体会议实现方法、装置及系统 |
CN106301812B (zh) * | 2015-05-20 | 2019-08-20 | 华为技术有限公司 | 多媒体会议实现方法、装置及系统 |
CN104980341A (zh) * | 2015-06-26 | 2015-10-14 | 上海迪静信息技术有限公司 | 一种实时连接多个移动终端远程调用数据的系统及其方法 |
CN110121049A (zh) * | 2019-05-08 | 2019-08-13 | 视联动力信息技术股份有限公司 | 一种会议媒体流控制方法及装置 |
CN110831063A (zh) * | 2019-11-13 | 2020-02-21 | 深圳市共进电子股份有限公司 | 优化网络中继链路的方法、系统、计算机终端及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
EP2061268A4 (en) | 2009-09-16 |
WO2008025230A1 (fr) | 2008-03-06 |
EP2061268B1 (en) | 2013-02-20 |
CN100442877C (zh) | 2008-12-10 |
EP2061268A1 (en) | 2009-05-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN100442877C (zh) | 一种实现集群通信业务的方法和系统 | |
KR100412185B1 (ko) | 무선 통신 시스템에서의 토크그룹 호출을 위한 방법 및 장치 | |
CN1534972B (zh) | 优化网络资源根据最终用户请求的用于会议接续的快速网络sip/sdp过程 | |
US20070281722A1 (en) | One-to-many communication service using composite broadcast/multicast flows in a wireless network | |
US8761071B2 (en) | Internet protocol radio dispatch system and method | |
EP1829302B1 (en) | Push-to-x over cellular coordinated floor and packet scheduling | |
CN103609147A (zh) | 集群通信系统、集群服务器、接入网络以及集群通信方法 | |
CN101689998A (zh) | 活动说话者标识 | |
KR100400423B1 (ko) | 무선 통신 시스템에서의 토크그룹 호출을 위한 방법 및장치 | |
WO2005120035A1 (fr) | Procede et systeme pour l'interconnexion d'un systeme de groupe numerique et d'un systeme telephonique publique | |
CN101159901A (zh) | 发起会议的方法、短信应用业务代理、会议服务器及系统 | |
WO2007028304A1 (fr) | Procede et systeme de realisation de service d'appels de groupe | |
KR20050101505A (ko) | 무선 통신 시스템에서 다중 세션 모니터링 방법 및 장치 | |
CN101931618A (zh) | 一种基于sip协议扩展的会话业务实现方法 | |
US20090299735A1 (en) | Method for Transferring an Audio Stream Between a Plurality of Terminals | |
CN104735629A (zh) | 一种全业务集群通信系统中广播通信的方法 | |
EP1850614A1 (en) | Advanced speech call items in networks comprising a MSC server and a media gateway | |
CN101170750B (zh) | 一种实现私密呼叫业务的方法和移动交换中心 | |
CN100353783C (zh) | 集群通信中组呼或组播业务讲者识别的实现方法 | |
CN101132392B (zh) | 一种单独载频广播系统及其实现业务传送的方法 | |
CN100450223C (zh) | 一种在移动软交换架构下实现集群业务的方法 | |
CN101557565B (zh) | 终端在反向业务信道间的切换方法及集群通信系统 | |
WO2006133645A1 (fr) | Procede d'implementation de la lecture du protocole de controle de passerelle multimedia | |
CN101167383A (zh) | Cdma系统组呼业务中终端在反向业务信道间切换的方法 | |
CN102368840A (zh) | 一种pstn终端接入集群通信系统的方法及pstn转换网关 |
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 | ||
EE01 | Entry into force of recordation of patent licensing contract |
Application publication date: 20080206 Assignee: Apple Computer, Inc. Assignor: Huawei Technologies Co., Ltd. Contract record no.: 2015990000755 Denomination of invention: System and method of implementing cluster communication service Granted publication date: 20081210 License type: Common License Record date: 20150827 |
|
LICC | Enforcement, change and cancellation of record of contracts on the licence for exploitation of a patent or utility model |