CN102291244B

CN102291244B - 一种云广播系统及方法

Info

Publication number: CN102291244B
Application number: CN 201110229450
Authority: CN
Inventors: 刘雅浪
Original assignee: HUNAN KANGTONG ELECTRONIC TECHNOLOGY Co Ltd
Current assignee: Hunan Comtom Electronic Technology Co ltd
Priority date: 2011-08-11
Filing date: 2011-08-11
Publication date: 2013-10-23
Anticipated expiration: 2031-08-11
Also published as: CN102291244A

Abstract

本发明公开了一种云广播系统及方法，首先从架构上设置应用层、网络服务层和终端层以构成一个IP广播系统；应用层为提供给用户使用的各种音频应用程序，这些应用程序用于将各种来源的音频流发送到广播终端，或者接收来自广播终端现场采集编码的音频流进行处理；网络服务层用于管理网络中所有会话对象和广播终端；在网络服务层设有会话服务器和终端服务器；终端层由多个广播终端组成，广播终端与终端服务器连接，最终完成声音信号的数模转换。该云广播系统及方法突破了单台服务器性能瓶颈，能支持大规模IP广播网络。

Description

一种云广播系统及方法

技术领域

本发明涉及一种云广播系统及方法。云广播即支持分布式扩展的IP网络广播。

背景技术

广播系统在社会的生产和生活中有着非常广泛的应用，可以快捷方便的以声音的形式将信息传播出去，或者用来作为背景音乐或者教学节目的播放设施，在车站、厂矿、学校、小区、酒店等场所都有着非常广泛的应用。

广播系统主要解决音频信息的传输问题。最初的广播系统采用定压功放实现，声音信号直接以模拟电信号传输，音频线上可以驳接多个扬声器。直接传输模拟信号最大的问题在于无法解决传输过程中信号衰减和噪声干扰的问题，传输的距离、接入的广播点数目都受到限制。数码多址广播是在基础定压功放广播系统之上增加频道选择功能的演进产品，本质上就是同时铺设多个音频线，另外外加一路控制信号线，可以控制扬声器选择哪一路音频进行扩音，即增加多路传输特性，但传输的音频信号本身还是模拟信号，无法克服定压功放广播自身固有的缺陷。

随着计算机网络技术的普及，计算机网络技术也应用到广播领域。采用TCP/IP网络协议传输声音信息的广播系统称之为IP广播。在IP广播系统传输的声音信号需要先经过采样编码为数字信号，传输的是纯数字信号，数字信号在传输过程中不会失真，信号传输距离不受限制，因此从根本上解决了定压功放在信号传输上的缺陷。IP广播主要由服务器软件系统、IP终端设备以及中间的网络传输设备构成，服务器软件将音频流发送到指定终端，终端将接收到的音频流解码还原为模拟信号，驱动喇叭播放声音。

随着IP广播系统越来越多的应用，人们希望采用IP广播技术构建更大规模的广播网络，譬如全省、全地区统一建立的农村广播，连锁机构广播系统，集团公司广播系统等等。现有IP广播技术还是基于单服务器架构模式，服务器硬件性能、服务器网络接口带宽限制了网络节点数目，一般单台服务器能够支持的终端节点数目为200～500个。因而，现有的IP广播系统扩展性能差。

现有IP广播系统一般由如下设备构成：

1.一台计算机作为广播服务器，运行系统服务软件，负责处理与系统中所有终端设备的通讯；

2.多个IP广播终端设备，接收来自广播服务器的音频流，将其解码还原为模拟音频信号，驱动扬声器输出声音，或者将现场声音进行采集编码，通过网络接口发送到广播服务器；

3.一些客户端应用程序，连接广播服务器，通过服务将音频流发送到指定终端，或者接收出来自指定终端的音频流；

现有技术的缺点

现有IP广播技术的问题在于存在服务器性能瓶颈，网络中所有终端都必须由一台服务器进行管理，不能通过扩展服务器数量增加网络容量(服务器之间没有任何关联，连接不同服务器的客户端和应用程序不能通讯，等同于隔离的网络)，当终端数量达到一定量时，服务器不能保证及时处理与所有终端的通讯，声音播放不再流畅。

发明内容

本发明所要解决的技术问题是提供一种云广播系统及方法，该云广播系统及方法可以方便灵活地扩展IP广播系统的规模。

本发明为解决上述技术问题所采用的技术方案是：

一种云广播方法，其特征在于，从架构上设置应用层、网络服务层和终端层以构成一个IP广播系统；

应用层为提供给用户使用的各种音频应用程序，这些应用程序用于将各种来源的音频流发送到广播终端，或者接收来自广播终端现场采集编码的音频流进行处理；

网络服务层用于管理网络中所有会话对象和广播终端；在网络服务层设有会话服务器和终端服务器；

终端层由多个广播终端组成，广播终端与终端服务器连接，最终完成声音信号的数模转换。

会话服务器和终端服务器均为1个或多个，应用程序通过会话服务器建立和维护会话，一个应用程序只对应一个会话服务器，一个会话服务器能服务1个或多个应用程序；

终端服务器维护终端设备及广播终端的工作状态，一个终端设备只对应一个终端服务器，一个终端服务器管理一个或多个终端设备；

所述IP广播方法中涉及的数据流包括：会话指令流、媒体数据流和终端通讯流：

1)会话指令流：建立与维护广播会话关系的通讯指令，发生在应用程序与会话服务器、会话服务器与终端服务器之间，应用程序与终端服务器亦从会话指令中获取到媒体流的发送方向；

2)媒体数据流：承载音频数据，在应用程序、终端服务器和广播终端之间传送；

3)终端通讯流：终端控制指令，传递终端服务器和广播终端之间的控制信息；

会话服务器通过查询系统数据库【系统数据库一般设置在网络层，它是系统中各个模块相互交流的数据中心，存储数据包括：终端配置数据、会话状态数据、终端服务配置数据、会话服务配置数据、用户管理数据；】，建立起终端服务器与其管理的终端设备之间的连接关系视图【附图1中显示了终端服务器与其管理的终端设备之间的连接关系视图】，如果一个会话包含多个广播终端，这些广播终端分别与不同的终端服务器连接，会话服务器将会话操作请求分发到相关的终端服务器。

会话服务器定位到网络中所有的广播终端，将应用程序对广播终端的控制请求转发到对应的终端服务器处理；通过会话服务器和终端服务器使得IP广播系统获得了可以扩展的能力：通过扩展会话服务器数量，以增加可支持的应用程序的数量；通过扩展终端服务器的数量增加终端设备的数量。

与会话相关的过程包括会话建立过程和会话撤销过程：

会话建立过程为：

步骤1：应用程序发送邀请消息即INVITE消息到与该应用程序连接的会话服务器，在INVITE消息中，将音频流发送的目标终端ID通知给会话服务器；

步骤2：会话服务器收到INVITE消息后，解析目标终端ID，通过查询全局配置表，获取到这些终端所连接的终端服务器主机地址与端口；

步骤3：会话服务器将INVITE消息转发给步骤2所查询到终端服务器服务主机；

步骤4：终端服务器收到INVITE消息后，修改目标终端会话状态信息，准备好将数据流发送到目标终端，并打开接收音频流的端口；

步骤5：各个终端服务器发送加入消息即JOIN消息给应用程序，通知应用程序接收音频流的地址与端口，报告已经加入到会话中的终端；

步骤6：应用程序根据配置的策略，在收到一定数量【一般取目标终端总数的百分之三十】的JOIN消息后，启动数据流的传输，将音频数据流直接发送到各个终端服务器上报的媒体流接收端口；

在数据流的传输过程即会话生存期中，应用程序将周期性的发送心跳消息即HBEAT消息到会话服务器，报告会话生存，会话服务器在超过设定时间未收到会话的HBEAT消息，将通知终端服务器撤销会话；

会话撤销过程为：

1)应用程序在数据流传输完毕后，发送结束指令即BYE指令到会话服务器；

2)会话服务器将BYE指令转发至与当前会话关联的终端服务器；

3)终端服务器在收到BYE指令后，撤销当前会话；

会话生存期间，终端服务器选择性地主动发送离开指令即LEAVE指令给应用程序，通知自身管理的某些广播终端离开会话。

一种云广播系统，包括应用层设备、网络服务层设备和终端层设备；

所述的应用层设备包括音频播放设备；

网络服务层设备包括会话服务器和终端服务器；

终端层设备由多个广播终端组成；

广播终端、会话服务器以及应用层设备均与终端服务服务器连接；会话服务服务器与应用层设备连接；

所述的云广播系统采用前述的云广播方法进行实现会话和音频数据传输。

应用层设备还包括音频采集设备。

广播属于一对多的通信模式，和电话通信有所区别，电话通信属于一对一的通信，必须确保双方都能接收到对方的语音流，广播通信存在多个数据接收者(SA)，不必保证每个接收者都能接收到的数据流，接收者也可以选择何时开始接收数据流，将会话建立分为“邀请”和“加入”两个阶段，这样便将各个SA的行为独立开来，可以比较灵活的处理多方通信的场景。名词说明

Session：会话，如无特殊说明，本专利中专指广播会话，广播会话表示一个广播事务，即多个通信节点之间进行一次信息传递所包含的从发起、执行到结束的过程由某个发起者发起的；

Session Server：SessionSvr，会话服务程序，系统中管理会话信息的服务程序；负责将会话请求发送到被邀请的网络节点；

Terminal Server：TRMSvr，终端服务程序，系统中管理终端设备工作状态的服务程序；

Session Protocol：会话通讯协议，会话协议定义会话建立和运行期间参与者之间消息报文格式以及邀请、关闭、加入、离开等会话事务的执行过程；

有益效果：

本发明的云广播系统及方法，通过部署多个服务器支持大规模IP广播网络，使系统可以平行扩展。本发明建立分布式架构，将管理终端的负载分担多个服务上，保障与每个终端的通讯能得到及时处理。

SessionSvr为App屏蔽了网络部署结构细节，应用不需要知道各个终端的具体分布，以及各个TRMSvr与终端之间的对应关系，只需将会话请求发送给SessionSvr处理即可，便于用户使用。

本发明的优点如下：

1.良好的可扩展性：由分层设计、会话状态与终端状态分布存储与维护、标准会话管理协议设计使得系统具备良好的可扩展性。每一个终端，每一次会话，在服务程序都需要分配相应的CPU和内存资源对其进行逻辑运算和状态保存，因此计算机硬件性能(CPU计算能力，内存大小，出口带宽等)限制了单台服务最大能支持的终端数量和会话数量.虽然当前IP广播系统通过增加服务器，可以增加支持终端数量，但连接不同服务器的终端之间，不同的服务器之间是彼此完全独立的，不能构成一个互联互通的网络，因此只能是彼此毫无关系的小规模广播系统。“云广播”系统(即本发明的IP广播系统)将终端状态和会话状态数据分布到不同的服务主机保存和处理，各个服务主机之间通过会话协议进行通讯，构成了互联互通的网络系统，通过扩展服务器数量，便可以扩大网络规模。

2.会话管理协议比较好的描述了广播会话各个阶段的操作，依据标准协议，可以比较方便的在核心服务系统之上建立各种应用。

附图说明

图1是本发明的架构图。

具体实施方式

下面结合附图和具体实施方式对本发明作进一步说明。

实施例1：

如图1，整个系统划分为三个层次，从上至下依次为：应用层、网络服务层，终端层。其中网络服务层为分布式IP广播系统核心组件，为上层应用屏蔽了终端设备的分布细节。

系统分层说明

应用层：应用层为提供给用户使用的各种音频应用程序，这些应用程序完成将各种来源的音频流发送到终端设备，或者接收来自终端设备现场采集编码的音频流进行处理。这些应用程序包括音频文件播放、电脑实时采集播放、报警广播、内部对讲、定时广播等；

网络服务层：网络服务层主要包括会话服务(SessionSvr)和终端服务(TRMSvr)两个模块，这两个模块起到管理网络中所有会话对象和终端设备的作用，是构建分布式IP广播系统的核心组件；

终端层：这一层为终端设备，与上层的终端服务连接，最终完成声音信号的数模转换；

系统中的实体主要包括应用(App)【这里的应用就是和广播系统服务(SessionSvr，TRMSvr)有关联的应用程序，一个应用就是一套程序，但可以部署到多个电脑上运行。】、会话服务(SessionSvr)、终端服务(TRMSvr)、终端(Terminal)，它们之间的关系如下：【会话服务(SessionSvr)、终端服务(TRMSvr)对应的实体或者硬件设备就是服务器】

这里的终端指网络音频编解码设设备，是类似电视机顶盒的多媒体网络设备，主要构成为MCU(微处理器)、网卡芯片等硬件和运行在上面的嵌入式软件构成。

会话服务和终端服务都可以部署多个。每个终端服务管理一定数量的终端，每个会话服务负责处理一定数量的应用接入请求，根据全局的配置信息，会话服务可以定位到网络中所有的终端服务，将应用对终端的控制请求转发到对应的终端服务处理。

4)App通过SessionSvr建立和维护会话，一个App只对应一个SessionSvr，一个SessionSvr可以服务多个App；

5)TRMSvr维护终端设备的工作状态，一个终端设备只对应一个TRMSvr，一个TRMSvr可以管理多个终端；

6)系统中的数据流主要包括：会话指令流，媒体数据流，终端通讯流。

a)会话指令流：建立与维护广播会话关系的通讯指令，发生在App与SessionSvr、SessionSvr与TRMSvr之间，App与TRMSvr亦从会话指令中获取到媒体流的发送方向；

b)媒体数据流：承载音频数据，在App，TRMSvr，Terminal之间传送；

c)终端通讯流：终端控制指令，传递TRMSvr和Terminal之间的控制信息；

7)SessionSvr通过查询系统数据库，建立起TRMSvr与其管理终端之间的连接关系视图，如果一个会话包含多个终端，这些终端分别与不同的TRMSvr连接，SessionSvr将会话操作请求分发到相关的TRMSvr。通过SessionSvr和TRMSvr，系统获得了可以扩展的能力：通过扩展SessionSvr服务器数量，系统可以增加可支持应用的数量；通过扩展TRMSvr服务器数量，可以增加终端设备的数量，一般的，终端设备数量是网络规模的主要指标；

i.会话协议(Session Protocol，SP)

会话协议是建立分布式广播会话的表达方式，是“云广播”系统的关键技术之一。会话协议格式参考在互联网服务中广泛使用的http协议，是一种文本协议，具备良好的可读性和可扩展性，包含请求和应答两种类型的报文。

协议报文格式

1.请求格式：

Method SP Request-Uri SP Version CRLF

message-header*

CRLF

[message-body]

其中SP为字段之间的间隔符，使用一个或者多个空格，CRLF为“\r\n；

Method：请求方法，表示是何种请求，可以是“INVITE”，“CANCEL”，“JOIN”，“LEAVE”，“BYE”，各个方法的具体意义下面章节再详细说明；

Request-Uri：请求发送目标节点URI，格式为sp:node-id，譬如：sp:ss.domain.com

Version：协议版本，当前为“bsp/1.0”

message-header：消息头部，每行为一个字段，可以有零项或者多项，承载请求的参数，字段格式后面说明；

message-body：消息正文，保存消息扩展内容，保存体积较大，格式复杂，不适合在头部承载的参数。Message-body的长度由Header中“Content-Length”字段说明，类型由“Content-Type”字段说明；

字段格式：FieldName COLON SP*FieldValue CRLF，其中COLON为‘:’，COLON和字段值之间可以有零个或者多个空格；

2.应答格式：

Version SP Status-code SP Reason-Phrase CRLF

message-header*

CRLF

[message-body]

Respond中除第一行外，其它部分格式与Request相同，这里只对第一行进行说明。

Version：协议版本，当前为“sp/1.0”

Status-code：请求处理返回状态码，表示接收者对请求的处理情况，具体编码后面章节说明；

Reason-Phrase：处理状态描述信息；

会话协议中的参与者

1.Session Initator(SI)，会话发起者：发起建立会话，并负责维护整个会话的生命周期，在本系统中，各种应用即承担了SI的角色；

2.Session Server(SS)，会话服务：在会话服务上，保存了当前有效的会话状态数据，在本系统中，各个SessionSvr实例即为SS；

3.Session Agent(SA)，会话代理：

代理其它不支持SP协议的设备或者应用执行各种会话操作，并将会话请求转化为被代理对象能够处理的操作，在本系统中，TRMSvr即为SA，代理终端设备处理会话请求；

会话协议主要内容

会话协议包括如下命令：INVITE，BYE，JOIN，LEAVE，HBEAT。其中INVITE建立会话或者邀请新的终端设备加入会话，BYE撤销会话，JOIN表示SA请求加入会话，LEAVE表示SA通知离开会话，HBEAT由SI周期性发给SS，表示会话处于活动状态。

INVITE命令内容

SI(或者SI的代理者)通过INVITE消息对SA节点发出会话邀请，建立起会话。会话相关请求主要包括INVITE，BYE，JOIN，LEAVE这4个，下面将详细说明其请求和应答格式，以及处理流程。

INVITE可以邀请新的终端加入已经建立的会话；

请求：

Request：

-----------------------------------------------------------------------------------------------

INVITE SS-URI sp/1.0

From：SIUri

To：TargetID1，TargetID2，...

CSeq：nnnn INVITE

SessionId：{uuid of session}

Appdata：

头部字段说明：

1)From：会话发起用户ID

2)To：会话目标节点ID，各个目标ID之间用‘，’隔开；

3)CSeq：请求序列号，32位无符号整数，在一个会话内，在同一方向上的请求序列号单调递增；

4)SessionId：会话ID，必须保证全局唯一；

5)Appdata：应用自定义数据，交由SS统一维护；

应答：

INVITE请求的应答有两种，一是SI发送INVITE请求给SS后，SS给SI的应答(Respond1)；另外一个是SS解析完会话目标SA集合后，各个SA发送给SS的应答(Respond2)。

Respond1：

Respond1：SS→SI

sp/1.0 Status-Code Reason-Phrase

[Via：xxxxx]

CSeq：nnn INVITE

SessionId：

Agents：

字段说明：

■CSeq：与请求中CSeq字段相同；

■Agents：目标SA ID清单(即目标终端所属区号清单)；

Respond2：

Respond2：SA→SS

sp/1.0 Status-Code Reason-Phrase

CSeq：nnn INVITE

SessionId：

From：SAUri

字段说明：

■CSeq：与请求中CSeq字段相同；

■AgentId：SA节点ID(区号)

BYE命令内容

SI发送BYE请求，通知参与者结束会话。SS和SA接收到BYE请求时，撤销本地存储的会话数据；

请求

Request：

BYE SS-URI sp/1.0

[Via：transport-of-proxy

Via：...]

From：SIUriCSeq:nnnn BYE

SessionId：

[To：trmid，trmid，...]

请求发送路径：SI→SS→SA1，SA2，...

应答

Respond1：SS→SI

sp/1.0 Status-Code Reason-Phrase

[Via...]

CSeq：nnn BYE

SessionId：

Respond2：SA→SS

sp/1.0 Status-Code Reason-Phrase

CSeq：nnn BYE

SessionId：

From：SAUri

JOIN命令内容

SA(或者SA的代理者)发送JOIN请求给SI，报告加入已存在的会话，并告知自己媒体数据接收设置。SA可以在收到SI的INVITE请求后加入到会话中，也可以直接向SI发送JOIN请求(在获取到SessionId的情况下)。

请求

Request：SA→SS→SI

JOIN SS-URI sp/1.0

[Via：transport-of-proxy

Via：...]

From：AgentUri

CSeq：nnnn JOIN

SessionId：

Receive-Port：recv-address:recv-port

Targets：

头部字段说明：

■Receive-Port：RTP数据流接收端口；

■Targets：加入会话的目标终端号码清单，如果为AAA0000，则表示包括全区所有终端，多个号码之间用’，’隔开；

应答

Respond：SI→SS→SA

sp/1.0 Status-Code Reason-Phrase

[Via：transport-of-proxy

Via：...]

From：AgentUri

CSeq：nnn JOIN

SessionId：

Owner：

SessionAttr：

Media：

Targets：

头部字段说明：

■Owner：Uri of SI

■SessionAttr：Session Attr

■Targets：新加入会话的终端ID清单；

LEAVE命令内容

SA(或者SA代理者)向SI发送LEAVE请求，报告离开会话的终端清单。

请求

Request：SA→SS→SI

JOIN SS-URI sp/1.0

CSeq：nnnn LEAVE

SessionId：

From：AgentUri

Targets：

头部字段说明：

■Target-num：当前还存在于会话中的终端数量；

■Targets：离开会话的目标终端号码清单；

应答

Respond：SI→SS→SA

sp/1.0 Status-Code Reason-Phrase

CSeq：nnn LEAVE

SessionId：

From：AgentUri

Targets：

■Targets：新退出会话的终端ID清单。

HBEAT命令内容

SI定期向SS发送的心跳请求，报告自己的状态以及当前发起的会话ID清单，如果SS长时间没有收到SI的HBEAT请求，则认为SI状态异常，由该SI发起的会话已失效。

请求

Request：SI→SS

HBEAT SS-URI sp/1.0

Via：transport-of-SI

From：Session-Owner-UserID

CSeq：nnnn HBEAT

Sessions：session-id1，session-id2

头部字段说明：

■Sessions：SI当前拥有会话ID清单；SI如果通过NAT设备与SS连接，可以先设置Sessions为空串，发送HBEAT请求至SS，获得自己今后NAT映射后的出口地址；

应答

Respond：SS→SI

sp/1.0 Status-Code Reason-Phrase

CSeq：nnn HBEAT

{NATAddr：xxx.xxx.xxx.xxx:nnnn}

头部字段说明：

NATAddr：SS将实际收到SI请求的数据源地址、端口发回到SI，以便SI获取到自己的NAT映射端口，可选；

会话建立与撤销过程

1.SI发出INVITE消息到SS，INVITE消息中包含需要加入到会话中的终端编号清单；

2.SS接收到SI的INVITE消息后，解析会话所包含的终端ID，通过全局配置信息，获取到管理这些终端的TRMSvr服务地址与端口，将INVITE消息转发到这些TRMSvr(SA)；

3.TRMSvr接收到INVITE消息后，根据各自现实情形与策略配置，决定是否加入会话，以及决定自己所哪些终端可以加入到会话中。如果存在需要加入会话的终端，则发送JOIN消息到SS，由SS转发至SI；

4.SI根据接收到的JOIN请求，可以获知哪些受邀对象已经加入到会话中，如果加入到会话中的终端设备数量满足策略需求，则启动媒体流的传输；

5.在会话进行过程中，SA可以通过主动发送JOIN，LEAVE加入或者离开会话，SI也可以通过主动向其它SA发送INVITE请求，将该SA管理的设备加入到会话中；

6.在会话进行过程中，SI周期性发送心跳请求(HBEAT命令)到SS，SS如超过规定时间未收到SI的心跳，则认为会话已异常终止，发送BYE命令到各个SA，请它们退出会话；

7.当媒体流传输完毕，SI发送BYE命令到SS，通知会话结束，SS负责转发BYE命令到其它会话参与者；

会话建立过程：

1.App发送INVITE消息到与之连接的SessionSvr(每个应用可以配置不同的SessionSvr为之服务)，在INVITE消息中，将音频流发送的目标终端ID通知给SessionSvr；

2.SessionSvr收到INVITE消息后，解析目标终端ID，通过查询全局配置表，获取到这些终端所连接的TRMSvr主机地址与端口；

3.SessionSvr将INVITE消息转发给步骤2所查询到TRMSvr服务主机；

4.TRMSvr收到INVITE消息后，修改目标终端会话状态信息，准备好将数据流发送到目标终端，并打开接收音频流的端口；

5.各个TRMSvr发送JOIN消息给App，通知App接收音频流的地址与端口，报告已经加入到会话中的终端；

6.App根据配置的策略，在收到一定数量的JOIN消息后，启动数据流的传输，将音频数据流直接发送到各个TRMSvr上报的媒体流接收端口；

7.在数据流的传输过程中(会话生存期)，App将周期性的发送HBEAT消息到SessionSvr，报告会话生存，SessionSvr在超过设定时间未收到会话的HBEAT消息，将通知TRMSvr撤销会话；

会话撤销过程

8)App在数据流传输完毕后，发送BYE指令到SessionSvr；

9)SessionSvr将BYE指令转发至与当前会话关联的TRMSvr；

10)TRMSvr在收到BYE指令后，撤销当前会话，终端可能切换到其它会话(发送其它会话音频流到终端播放)或者空闲；

11)会话生存期间，TRMSvr也可以主动发送LEAVE指令给App，通知自身管理的某些终端离开会话(可能需要加入到其它会话中，或者在某些终端需要临时屏蔽当前会话音频流)；

见会话建立过程说明，为提高网络传输效率，避免出现网络瓶颈，音频流由应用直接发送给TRMSvr，再由TRMSvr根据终端所在网络的情况，通过单播或者组播方式将数据流传输到终端。

这里说一下“云广播”系统即云广播系统可能的一种应用场景。譬如农村广播，假定某市建立了统一的农村IP广播系统，每个县分配一个TRMSvr，管理全县的终端设备，全市建立2台SessionSvr，每10个县分配一台SessionSvr(假定共有20个县)，县和市都有广播站，广播站应用程序具备音乐播放和实时广播讲话的功能。这些功能都依托“云广播”系统来实现，通过系统权限管理，各县广播站应用只允许访问本县终端，市广播站应用允许访问全市终端设备。广播站应用程序读取所运行电脑上存储的音乐文件，或者通过电脑MIC实时采集编码音频流，通过SessionSvr建立会话，将音频流发送到TRMSvr通过JOIN消息上报的数据流接收端口，TRMSvr再将音频流转发至目标终端设备，终端将音频流解码还原为声音进行播放。

本发明的协议参考了以下资料：《RFC：3261》，SIP协议标准。

Claims

1.一种云广播方法，其特征在于，从架构上设置应用层、网络服务层和终端层以构成一个IP广播系统；

终端层由多个广播终端组成，广播终端与终端服务器连接，最终完成声音信号的数模转换；

终端服务器维护广播终端的工作状态，一个广播终端只对应一个终端服务器，一个终端服务器管理一个或多个广播终端；

所述云广播方法中涉及的数据流包括：会话指令流、媒体数据流和终端通讯流：

会话服务器通过查询系统数据库，建立起终端服务器与其管理的广播终端之间的连接关系视图，如果一个会话包含多个广播终端，这些广播终端分别与不同的终端服务器连接，会话服务器将会话操作请求分发到相关的终端服务器；

会话服务器定位到网络中所有的广播终端，将应用程序对广播终端的控制请求转发到对应的终端服务器处理；通过会话服务器和终端服务器使得IP广播系统获得了可以扩展的能力：通过扩展会话服务器数量，以增加可支持的应用程序的数量；通过扩展终端服务器的数量增加广播终端的数量；

与会话相关的过程包括会话建立过程和会话撤销过程：

会话建立过程为：

步骤6：应用程序根据配置的策略，在收到一定数量的JOIN消息后，启动数据流的传输，将音频数据流直接发送到各个终端服务器上报的媒体流接收端口；

会话撤销过程为：

1）应用程序在数据流传输完毕后，发送结束指令即BYE指令到会话服务器；

2）会话服务器将BYE指令转发至与当前会话关联的终端服务器；

3）终端服务器在收到BYE指令后，撤销当前会话；

2.一种云广播系统，其特征在于，包括应用层设备、网络服务层设备和终端层设备；

所述的应用层设备包括音频播放设备；

网络服务层设备包括会话服务器和终端服务器；

终端层设备由多个广播终端组成；

所述的云广播系统采用权利要求1所述的云广播方法进行实现会话和音频数据传输。

3.根据权利要求2所述的云广播系统，其特征在于，应用层设备还包括音频采集设备。