CN106559396A - 基于Web实时通信的媒体多播方法和系统 - Google Patents
基于Web实时通信的媒体多播方法和系统 Download PDFInfo
- Publication number
- CN106559396A CN106559396A CN201510639340.3A CN201510639340A CN106559396A CN 106559396 A CN106559396 A CN 106559396A CN 201510639340 A CN201510639340 A CN 201510639340A CN 106559396 A CN106559396 A CN 106559396A
- Authority
- CN
- China
- Prior art keywords
- media
- webrtc
- virtual
- transmitting terminal
- distribution
- 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
Classifications
-
- 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/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
Abstract
本发明公开一种基于Web实时通信的媒体多播方法和系统。其中WebRTC发送端将需要传输的媒体信息进行加密以得到加密媒体流，将加密媒体流发送给媒体广播设备。在媒体广播设备中，虚拟接收端将加密媒体流进行解密以得到媒体信息，并将媒体信息发送给媒体分发模块，媒体分发模块将媒体信息转发给相关联的虚拟发送端，虚拟发送端根据预先协商的加密参数对媒体信息进行加密以得到相应的分发媒体流，并将分发媒体流发送给对应的WebRTC接收端。WebRTC接收端利用预先协商的加密参数对分发媒体流进行解密以得到媒体信息，从而实现媒体多播。本发明通过媒体广播设备将一个WebRTC发送端产生的媒体流分发给多个WebRTC接收端，在避免多次编码的同时实现了媒体流的多播功能。
Description
技术领域
本发明涉及通信领域，特别涉及一种基于Web实时通信的媒体多播方法和系统。
背景技术
Web实时通信技术(WebRTC)是一种旨在通过浏览器和Web技术实现多媒体音视频实时通信的技术体系。现有规范主要针对P2P的通信应用场景，缺少多播、广播、会议等多方通信的相关技术规范。现有WebRTC多播(Multicast)方案需要发送端与每个接收端建立连接，并对每一路音视频流进行独立的音视频编码。现有WebRTC多播方案存在以下一些问题：并发多路编码造成计算复杂度高、功耗大，可支持的多播路数少。
发明内容
本发明实施例提供一种基于Web实时通信的媒体多播方法和系统。通过在媒体广播设备中实现虚拟WebRTC接收端及发送端以与WebRTC发送端及接收端进行交互，从而将一个WebRTC发送端产生的媒体流分发给多个WebRTC接收端，在避免多次编码的同时实现了媒体流的多播功能。
根据本发明的一个方面，提供一种基于Web实时通信的媒体多播方法，包括：
WebRTC发送端将需要传输的媒体信息进行加密以得到加密媒体流，将加密媒体流发送给媒体广播设备，其中媒体广播设备具有虚拟接收端、媒体分发模块、与媒体分发模块相关联的虚拟发送端；
虚拟接收端将加密媒体流进行解密以得到媒体信息，并将媒体信息发送给媒体分发模块；
媒体分发模块将媒体信息转发给相关联的虚拟发送端；
虚拟发送端根据预先协商的加密参数对媒体信息进行加密，以得到相应的分发媒体流，并将分发媒体流发送给对应的WebRTC接收端；
WebRTC接收端利用预先协商的加密参数对分发媒体流进行解密以得到媒体信息，从而实现媒体多播。
在一个实施例中，WebRTC接收端在希望加入媒体多播时，向信令服务器发送加入请求；
信令服务器在接收到加入请求后，判断是否存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端；
若不存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端，则信令服务器指示媒体分发模块启动一个新虚拟接收端和一个新虚拟发送端，其中新虚拟发送端与媒体分发模块相关联；
信令服务器分别与新虚拟接收端和新虚拟发送端建立信令连接；
新虚拟接收端与WebRTC发送端、新虚拟发送端与WebRTC接收端分别进行媒体参数协商，以建立媒体流通信连接。
在一个实施例中，若存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端，则信令服务器指示媒体分发模块启动一个新虚拟发送端，其中新虚拟发送端与媒体分发模块相关联；
WebRTC接收端与新虚拟发送端进行媒体参数协商，以建立媒体流通信连接。
在一个实施例中，信令服务器在接收到加入请求后，还包括：
信令服务器向WebRTC发送端发送查询请求；
WebRTC发送端在判断允许WebRTC接收端加入媒体多播时，向信令服务器发送确认响应；
信令服务器在接收到确认响应后，执行判断是否存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端的步骤。
在一个实施例中，WebRTC接收端在退出时，向信令服务器发送退出请求；
信令服务器关闭与该WebRTC接收端对应虚拟发送端M的信令连接，并指示媒体分发模块关闭虚拟发送端M。
在一个实施例中，信令服务器指示媒体分发模块关闭虚拟发送端M后，还包括：
信令服务器判断与媒体分发模块相关联的虚拟发送端是否全部关闭；
若与媒体分发模块相关联的虚拟发送端全部关闭，则信令服务器指示媒体分发模块关闭虚拟接收端与信令服务器的信令连接，并关闭虚拟接收端。
根据本发明的另一方面，提供一种基于Web实时通信的媒体多播系统，包括WebRTC发送端、媒体广播设备和WebRTC接收端，媒体广播设备具有虚拟接收端、媒体分发模块、与媒体分发模块相关联的虚拟发送端，其中：
WebRTC发送端，用于将需要传输的媒体信息进行加密以得到加密媒体流，将加密媒体流发送给媒体广播设备；
虚拟接收端，用于将加密媒体流进行解密以得到媒体信息，并将媒体信息发送给媒体分发模块；
媒体分发模块，用于将媒体信息转发给相关联的虚拟发送端；
虚拟发送端，用于根据预先协商的加密参数对媒体信息进行加密，以得到相应的分发媒体流，并将分发媒体流发送给对应的WebRTC接收端；
WebRTC接收端，用于利用预先协商的加密参数对分发媒体流进行解密以得到媒体信息，从而实现媒体多播。
在一个实施例中，WebRTC接收端还用于在希望加入媒体多播时，向信令服务器发送加入请求；
信令服务器还用于在接收到加入请求后，判断是否存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端；若不存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端，则指示媒体分发模块启动一个新虚拟接收端和一个新虚拟发送端，其中新虚拟发送端与媒体分发模块相关联；与新虚拟接收端和新虚拟发送端建立信令连接；
WebRTC发送端还用于与新虚拟接收端进行媒体参数协商，以建立媒体流通信连接；
WebRTC接收端还用于与新虚拟发送端进行媒体参数协商，以建立媒体流通信连接。
在一个实施例中，信令服务器还用于在判断存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端时，指示媒体分发模块启动一个新虚拟发送端，其中新虚拟发送端与媒体分发模块相关联；
WebRTC接收端还用于与新虚拟发送端进行媒体参数协商，以建立媒体流通信连接。
在一个实施例中，信令服务器还用于在接收到加入请求后，向WebRTC发送端发送查询请求；在接收到WebRTC发送端发送的确认响应后，执行判断是否存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端的操作；
WebRTC发送端还用于在判断允许WebRTC接收端加入媒体多播时，向信令服务器发送确认响应。
在一个实施例中，WebRTC接收端还用于在退出时，向信令服务器发送退出请求；
信令服务器还用于关闭与该WebRTC接收端对应虚拟发送端M的信令连接，并指示媒体分发模块关闭虚拟发送端M。
在一个实施例中，信令服务器在指示媒体分发模块关闭虚拟发送端M后，还判断与媒体分发模块相关联的虚拟发送端是否全部关闭；若与媒体分发模块相关联的虚拟发送端全部关闭，则指示媒体分发模块关闭虚拟接收端与信令服务器的信令连接，并关闭虚拟接收端。
本发明通过在媒体广播设备中实现虚拟WebRTC接收端及发送端以与WebRTC发送端及接收端进行交互，从而将一个WebRTC发送端产生的媒体流分发给多个WebRTC接收端，在避免多次编码的同时实现了媒体流的多播功能。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本发明基于Web实时通信的媒体多播方法一个实施例的示意图。
图2为本发明基于Web实时通信的媒体多播方法另一实施例的示意图。
图3为本发明基于Web实时通信的媒体多播方法又一实施例的示意图。
图4为本发明基于Web实时通信的媒体多播系统一个实施例的示意图。
图5为本发明基于Web实时通信的媒体多播系统另一实施例的示意图。
图6为本发明用户加入媒体多播系统一个实施例的示意图。
图7为本发明用户加入媒体多播系统另一实施例的示意图。
图8为本发明用户退出媒体多播系统一个实施例的示意图。
图9为本发明用户退出媒体多播系统另一实施例的示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本发明及其应用或使用的任何限制。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本发明的范围。
同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。
对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为授权说明书的一部分。
在这里示出和讨论的所有示例中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它示例可以具有不同的值。
应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。
图1为本发明基于Web实时通信的媒体多播方法一个实施例的示意图。其中，本实施例的方法步骤包括：
步骤101，WebRTC发送端将需要传输的媒体信息进行加密以得到加密媒体流，将加密媒体流发送给媒体广播设备。
其中媒体广播设备具有虚拟接收端、媒体分发模块、与媒体分发模块相关联的虚拟发送端。
步骤102，虚拟接收端将加密媒体流进行解密以得到媒体信息，并将媒体信息发送给媒体分发模块。
例如，虚拟接收端将接收到的SRTP加密媒体流进行解密以得到RTP数据，并将RTP数据发送给媒体分发模块。
步骤103，媒体分发模块将媒体信息转发给相关联的虚拟发送端。
例如，媒体分发模块会根据现有虚拟发送端的数量，将RTP包进行复制后转发给每个虚拟发送端。
步骤104，虚拟发送端根据预先协商的加密参数对媒体信息进行加密，以得到相应的分发媒体流，并将分发媒体流发送给对应的WebRTC接收端。
步骤105，WebRTC接收端利用预先协商的加密参数对分发媒体流进行解密以得到媒体信息，从而实现媒体多播。
例如，虚拟发送端在接收到RTP数据后，会使用自身与WebRTC接收端进行媒体协商过程中确定的加密套件以及加密参数将其加密为SRTP流，并从协商好的媒体发送端口发送给WebRTC接收端。WebRTC接收端接收到SRTP流后进行解密、解码，后通过屏幕或喇叭等方式呈现给用户。
基于本发明上述实施例提供的基于Web实时通信的媒体多播方法，通过在媒体广播设备中实现虚拟WebRTC接收端及发送端以与WebRTC发送端及接收端进行交互，从而将一个WebRTC发送端产生的媒体流分发给多个WebRTC接收端，在避免多次编码的同时实现了媒体流的多播功能。
需要说明的是，WebRTC客户端通常是指运行于计算机系统上的Web浏览器中的Web应用程序。该Web应用程序通过脚本语言，如JavaScript，控制程序进行信令及媒体的通信。WebRTC客户端在建立连接前需要交换媒体信息，通信地址信息，该信息通常使用SDP协议方式进行编码。处于安全性考虑，运行于浏览器中的WebRTC客户端需要通过信令服务器转发其通信请求/要约，WebRTC客户端与该服务器间的通信被称为信令通道，信令传输承载一般采用WebSocket或者HTTP协议。WebRTC的媒体流采用了SRTP技术进行加密，并DTLS进行加密套件及相其具体加密参数的协商，接收端需要获得该协商结果以解密媒体流。
图2为本发明基于Web实时通信的媒体多播方法另一实施例的示意图。在该实施例中，当WebRTC接收端希望加入正在进行的媒体多播时，可执行以下步骤：
步骤201，WebRTC接收端在希望加入媒体多播时，向信令服务器发送加入请求。
步骤202，信令服务器在接收到加入请求后，判断是否存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端。若不存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端，则执行步骤203；若存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端，则执行步骤206。
其中，若不存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端，则表明该WebRTC接收端是首个加入的用户终端，在这种情况下需要在媒体广播设备中开启一个新的虚拟接收端和新的虚拟发送端。若存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端，则表明该WebRTC接收端不是首个加入的用户终端，媒体广播设备中已开启虚拟接收端和为其它用户终端提供服务的虚拟发送端，在这种情况下媒体广播设备仅需为该WebRTC发送端开启相对应的虚拟发送端即可。
步骤203，信令服务器指示媒体分发模块启动一个新虚拟接收端和一个新虚拟发送端，其中新虚拟发送端与媒体分发模块相关联。
步骤204，信令服务器分别与新虚拟接收端和新虚拟发送端建立信令连接。
步骤205，新虚拟接收端与WebRTC发送端、新虚拟发送端与WebRTC接收端分别进行媒体参数协商，以建立媒体流通信连接。之后，不再执行本实施例的其它步骤。
步骤206，信令服务器指示媒体分发模块启动一个新虚拟发送端，其中新虚拟发送端与媒体分发模块相关联。
步骤207，WebRTC接收端与新虚拟发送端进行媒体参数协商，以建立媒体流通信连接。
通过该实施例，用户可在媒体多播进行中方便地进行加入。
优选的，在上述步骤202中，信令服务器在接收到加入请求后，还会向WebRTC发送端发送查询请求，以便由WebRTC发送端决定是否允许该WebRTC接收端加入媒体多播。若WebRTC发送端允许该WebRTC接收端加入媒体多播，则向信令服务器发送确认响应，例如根据查询请求中携带的SDP信息构造响应消息并附带自身的SDP信息，以便信令服务器进行后续处理。
在一个实施例中，虚拟接收机在启动后，根据SDP中的信息分配通信及计算资源，并构造自身的SDP信息，该SDP信息中的媒体能力描述部分与WebRTC发送端提供的SDP相同，并将该信息发送给信令服务器。并开始在媒体接收端口启动监听。
同样，虚拟发送端在启动后，根据SDP中的信息分配通信及计算资源，并构造自身的SDP信息，该SDP信息中的媒体能力描述部分与WebRTC发送端提供的SDP相同，并将该信息发送给信令服务器。并开始在媒体发送端口启动监听。
信令服务器将虚拟接收端提供的SDP信息转发给WebRTC发送端。将虚拟发送端提供的SDP信息作为响应消息发给WebRTC接收端。
之后WebRTC发送端与虚拟接收端，WebRTC接收端与虚拟发送端分别执行WebRTC媒体流建立流程，完成后两者间就可以进行媒体流通信。
WebRTC发送端与虚拟接收端间的WebRTC媒体流建立流程，同虚拟发送端与WebRTC接收端间的WebRTC媒体流建立流程是一样的。下面以WebRTC发送端与虚拟接收端间的WebRTC媒体流建立流程为例进行说明。
1.WebRTC发送端收到信令服务器发来的虚拟接收端SDP信息。
2.WebRTC发送端根据SDP信息中提供的ICE候选地址列表信息，并对表中所有地址持续不断地进行ICE协议规范的连通性检测。
3.当找到一个可以联通的ICE地址时，WebRTC发送端向该地址发起DTLS密钥协商流程。当DTLS协商完成后，WebRTC发送端用获得进行加密的SRTP报文所需的加密套件参数，同样虚拟接收端也获得了相应的用来解密SRTP报文的密码套件参数。
4.WebRTC发送端开始向虚拟接收端发送经过加密的SRTP报文。
5.虚拟接收端收到该SRTP报文后进行解密得到原始媒体编码载荷。
在上述步骤2中，对一个候选地址进行ICE连通性检测的具体步骤可为(其中将通信双方简记为A和B)：
1.A向候选地址(IP+端口形式)发送特定的STUN协议报文。
2.当B收端收到上述报文时，会以对应STUN报文进行回应。
3.A发送端收到后即可确认该路由可通达B。
图3为本发明基于Web实时通信的媒体多播方法又一实施例的示意图。在该实施例中，当WebRTC接收端希望退出正在进行的媒体多播时，可执行以下步骤：
步骤301，WebRTC接收端在退出时，向信令服务器发送退出请求。
步骤302，信令服务器关闭与该WebRTC接收端对应虚拟发送端M的信令连接，并指示媒体分发模块关闭虚拟发送端M。
步骤303，信令服务器判断与媒体分发模块相关联的虚拟发送端是否全部关闭。
步骤304，若与媒体分发模块相关联的虚拟发送端全部关闭，则信令服务器指示媒体分发模块关闭虚拟接收端与信令服务器的信令连接，并关闭虚拟接收端。
在该实施例中，如有用户退出，则信令服务器指示媒体分发模块关闭相应的虚拟发送端。之后，信令服务器进一步判断全部用户已退出，若全部用户退出，则进一步指示媒体分发模块关闭相应的虚拟接收端。
由于在媒体多播过程中，用户可随意加入或退出媒体多播，因此提高了用户体验。
图4为本发明基于Web实时通信的媒体多播系统一个实施例的示意图。如图4所示，该系统可括WebRTC发送端401、媒体广播设备402和WebRTC接收端403，媒体广播设备具有虚拟接收端4021、媒体分发模块4022、与媒体分发模块4022相关联的虚拟发送端403。其中：
WebRTC发送端401，用于将需要传输的媒体信息进行加密以得到加密媒体流，将加密媒体流发送给媒体广播设备402。
虚拟接收端4021，用于将加密媒体流进行解密以得到媒体信息，并将媒体信息发送给媒体分发模块4022。
媒体分发模块4022，用于将媒体信息转发给相关联的虚拟发送端4023。
虚拟发送端4023，用于根据预先协商的加密参数对媒体信息进行加密，以得到相应的分发媒体流，并将分发媒体流发送给对应的WebRTC接收端403。
WebRTC接收端403，用于利用预先协商的加密参数对分发媒体流进行解密以得到媒体信息，从而实现媒体多播。
基于本发明上述实施例提供的基于Web实时通信的媒体多播系统，通过在媒体广播设备中实现虚拟WebRTC接收端及发送端以与WebRTC发送端及接收端进行交互，从而将一个WebRTC发送端产生的媒体流分发给多个WebRTC接收端，在避免多次编码的同时实现了媒体流的多播功能。
图5为本发明基于Web实时通信的媒体多播系统另一实施例的示意图。与图4所示实施例相比，在图5所示实施例中，还包括信令服务器501。
优选的，WebRTC接收端在希望加入媒体多播时，向信令服务器501发送加入请求。
信令服务器501还用于在接收到加入请求后，判断是否存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端；若不存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端，则指示媒体分发模块启动一个新虚拟接收端和一个新虚拟发送端，其中新虚拟发送端与媒体分发模块相关联；与新虚拟接收端和新虚拟发送端建立信令连接。
WebRTC发送端与新虚拟接收端进行媒体参数协商，以建立媒体流通信连接。WebRTC接收端与新虚拟发送端进行媒体参数协商，以建立媒体流通信连接。
信令服务器501在判断存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端时，指示媒体分发模块启动一个新虚拟发送端，其中新虚拟发送端与媒体分发模块相关联。WebRTC接收端与新虚拟发送端进行媒体参数协商，以建立媒体流通信连接。
优选的，信令服务器501在接收到加入请求后，向WebRTC发送端发送查询请求。WebRTC发送端在判断允许WebRTC接收端加入媒体多播时，向信令服务器发送确认响应。信令服务器501在接收到WebRTC发送端发送的确认响应后，执行判断是否存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端的操作。
优选的，WebRTC接收端还用于在退出时，向信令服务器501发送退出请求。信令服务器501关闭与该WebRTC接收端对应虚拟发送端的信令连接，并指示媒体分发模块关闭该虚拟发送端。
信令服务器501在指示媒体分发模块关闭该虚拟发送端后，还判断与媒体分发模块相关联的虚拟发送端是否全部关闭；若与媒体分发模块相关联的虚拟发送端全部关闭，则指示媒体分发模块关闭虚拟接收端与信令服务器的信令连接，并关闭虚拟接收端。
优选的，虚拟接收端和虚拟发送端都具有信令控制模块和媒体流处理模块，以分别处理相应的WebSocket信令信息和媒体流信息。
下面通过具体示例对本发明进行说明。
实施例一：首个用户终端加入媒体多播
如图6所示，WebRTC接收端1在希望加入媒体多播时，向信令服务器发送加入请求。信令服务器在接收到加入请求后，判断该WebRTC接收端1为首个用户终端，则指示媒体分发模块启动一个虚拟接收端和一个虚拟发送端1，其中虚拟发送端1与媒体分发模块相关联。信令服务器分别与虚拟接收端和虚拟发送端1建立信令连接。
虚拟接收端与WebRTC发送端、虚拟发送端1与WebRTC接收端1分别进行媒体参数协商，以建立媒体流通信连接。从而媒体分发模块可将接收到的媒体信息转发给相关联的虚拟发送端1。虚拟发送端1根据预先协商的加密参数对媒体信息进行加密，以得到相应的分发媒体流，并将分发媒体流发送给对应的WebRTC接收端1。WebRTC接收端1利用预先协商的加密参数对分发媒体流进行解密以得到媒体信息，从而实现媒体多播的加入。
实施例二：非首个用户终端加入媒体多播
如图7所示，WebRTC接收端2在希望加入媒体多播时，向信令服务器发送加入请求。信令服务器在接收到加入请求后，判断该WebRTC接收端2并非为首个用户终端，则指示媒体分发模块启动一个新虚拟发送端2，其中新虚拟发送端2与媒体分发模块相关联。
WebRTC接收端2与新虚拟发送端1进行媒体参数协商，以建立媒体流通信连接。从而媒体分发模块可将接收到的媒体信息转发给相关联的虚拟发送端1和虚拟发送端2。虚拟发送端1和虚拟发送端2分别根据预先协商的加密参数对媒体信息进行加密，以得到相应的分发媒体流，并将分发媒体流发送给对应的WebRTC接收端1和WebRTC接收端2，从而实现媒体多播的加入。
实施例三：用户终端退出媒体多播(系统中还有其它用户终端)
如图8所示，WebRTC接收端2在希望退出媒体多播时，向信令服务器发送加入请求。信令服务器关闭与该WebRTC接收端2对应虚拟发送端2的信令连接，并指示媒体分发模块关闭虚拟发送端2。由于此时还有WebRTC接收端1参与媒体多播，因此系统维持其它部件的正常工作。
实施例四：用户终端退出媒体多播(系统中没有其它用户终端)
如图9所示，WebRTC接收端1在希望退出媒体多播时，向信令服务器发送加入请求。信令服务器关闭与该WebRTC接收端1对应虚拟发送端1的信令连接，并指示媒体分发模块关闭虚拟发送端1。由于此时与媒体分发模块相关联的虚拟发送端已全部关闭，表明全部用户都已退出该媒体多播，则信令服务器指示媒体分发模块关闭虚拟接收端与信令服务器的信令连接，并关闭虚拟接收端。
通过实施本发明，可以得到以下有益效果：
1)具有WebRTC媒体流分发能力，支持一点对多点的通信方式。
2)通过采用虚拟终端，实现了媒体广播设备以虚拟终端形式与一般WebRTC终端间的信息交互，具有较好的互操作性。该系统也可以被级联使用，从而实现负载均衡或流量分流。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
本发明的描述是为了示例和描述起见而给出的，而并不是无遗漏的或者将本发明限于所公开的形式。很多修改和变化对于本领域的普通技术人员而言是显然的。选择和描述实施例是为了更好说明本发明的原理和实际应用，并且使本领域的普通技术人员能够理解本发明从而设计适于特定用途的带有各种修改的各种实施例。
Claims (12)
1.一种基于Web实时通信的媒体多播方法，其特征在于，包括：
WebRTC发送端将需要传输的媒体信息进行加密以得到加密媒体流，将加密媒体流发送给媒体广播设备，其中媒体广播设备具有虚拟接收端、媒体分发模块、与媒体分发模块相关联的虚拟发送端；
虚拟接收端将加密媒体流进行解密以得到媒体信息，并将媒体信息发送给媒体分发模块；
媒体分发模块将媒体信息转发给相关联的虚拟发送端；
虚拟发送端根据预先协商的加密参数对媒体信息进行加密，以得到相应的分发媒体流，并将分发媒体流发送给对应的WebRTC接收端；
WebRTC接收端利用预先协商的加密参数对分发媒体流进行解密以得到媒体信息，从而实现媒体多播。
2.根据权利要求1所述的方法，其特征在于，还包括：
WebRTC接收端在希望加入媒体多播时，向信令服务器发送加入请求；
信令服务器在接收到加入请求后，判断是否存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端；
若不存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端，则信令服务器指示媒体分发模块启动一个新虚拟接收端和一个新虚拟发送端，其中新虚拟发送端与媒体分发模块相关联；
信令服务器分别与新虚拟接收端和新虚拟发送端建立信令连接；
新虚拟接收端与WebRTC发送端、新虚拟发送端与WebRTC接收端分别进行媒体参数协商，以建立媒体流通信连接。
3.根据权利要求2所述的方法，其特征在于，还包括：
若存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端，则信令服务器指示媒体分发模块启动一个新虚拟发送端，其中新虚拟发送端与媒体分发模块相关联；
WebRTC接收端与新虚拟发送端进行媒体参数协商，以建立媒体流通信连接。
4.根据权利要求3所述的方法，其特征在于，
信令服务器在接收到加入请求后，还包括：
信令服务器向WebRTC发送端发送查询请求；
WebRTC发送端在判断允许WebRTC接收端加入媒体多播时，向信令服务器发送确认响应；
信令服务器在接收到确认响应后，执行判断是否存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端的步骤。
5.根据权利要求1-4中任一项所述的方法，其特征在于，还包括：
WebRTC接收端在退出时，向信令服务器发送退出请求；
信令服务器关闭与该WebRTC接收端对应虚拟发送端M的信令连接，并指示媒体分发模块关闭虚拟发送端M。
6.根据权利要求5所述的方法，其特征在于，还包括：
信令服务器指示媒体分发模块关闭虚拟发送端M后，还包括：
信令服务器判断与媒体分发模块相关联的虚拟发送端是否全部关闭；
若与媒体分发模块相关联的虚拟发送端全部关闭，则信令服务器指示媒体分发模块关闭虚拟接收端与信令服务器的信令连接，并关闭虚拟接收端。
7.一种基于Web实时通信的媒体多播系统，其特征在于，包括WebRTC发送端、媒体广播设备和WebRTC接收端，媒体广播设备具有虚拟接收端、媒体分发模块、与媒体分发模块相关联的虚拟发送端，其中：
WebRTC发送端，用于将需要传输的媒体信息进行加密以得到加密媒体流，将加密媒体流发送给媒体广播设备；
虚拟接收端，用于将加密媒体流进行解密以得到媒体信息，并将媒体信息发送给媒体分发模块；
媒体分发模块，用于将媒体信息转发给相关联的虚拟发送端；
虚拟发送端，用于根据预先协商的加密参数对媒体信息进行加密，以得到相应的分发媒体流，并将分发媒体流发送给对应的WebRTC接收端；
WebRTC接收端，用于利用预先协商的加密参数对分发媒体流进行解密以得到媒体信息，从而实现媒体多播。
8.根据权利要求7所述的系统，其特征在于，
WebRTC接收端还用于在希望加入媒体多播时，向信令服务器发送加入请求；
信令服务器还用于在接收到加入请求后，判断是否存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端；若不存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端，则指示媒体分发模块启动一个新虚拟接收端和一个新虚拟发送端，其中新虚拟发送端与媒体分发模块相关联；与新虚拟接收端和新虚拟发送端建立信令连接；
WebRTC发送端还用于与新虚拟接收端进行媒体参数协商，以建立媒体流通信连接；
WebRTC接收端还用于与新虚拟发送端进行媒体参数协商，以建立媒体流通信连接。
9.根据权利要求8所述的系统，其特征在于，
信令服务器还用于在判断存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端时，指示媒体分发模块启动一个新虚拟发送端，其中新虚拟发送端与媒体分发模块相关联；
WebRTC接收端还用于与新虚拟发送端进行媒体参数协商，以建立媒体流通信连接。
10.根据权利要求9所述的系统，其特征在于，
信令服务器还用于在接收到加入请求后，向WebRTC发送端发送查询请求；在接收到WebRTC发送端发送的确认响应后，执行判断是否存在与WebRTC发送端相对应的虚拟接收端和虚拟发送端的操作；
WebRTC发送端还用于在判断允许WebRTC接收端加入媒体多播时，向信令服务器发送确认响应。
11.根据权利要求7-10中任一项所述的系统，其特征在于，
WebRTC接收端还用于在退出时，向信令服务器发送退出请求；
信令服务器还用于关闭与该WebRTC接收端对应虚拟发送端M的信令连接，并指示媒体分发模块关闭虚拟发送端M。
12.根据权利要求11所述的系统，其特征在于，
信令服务器在指示媒体分发模块关闭虚拟发送端M后，还判断与媒体分发模块相关联的虚拟发送端是否全部关闭；若与媒体分发模块相关联的虚拟发送端全部关闭，则指示媒体分发模块关闭虚拟接收端与信令服务器的信令连接，并关闭虚拟接收端。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510639340.3A CN106559396B (zh) | 2015-09-30 | 2015-09-30 | 基于Web实时通信的媒体多播方法和系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510639340.3A CN106559396B (zh) | 2015-09-30 | 2015-09-30 | 基于Web实时通信的媒体多播方法和系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN106559396A true CN106559396A (zh) | 2017-04-05 |
| CN106559396B CN106559396B (zh) | 2019-12-06 |
Family
ID=58417750
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201510639340.3A Active CN106559396B (zh) | 2015-09-30 | 2015-09-30 | 基于Web实时通信的媒体多播方法和系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN106559396B (zh) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107948676A (zh) * | 2017-12-08 | 2018-04-20 | 苏州科达科技股份有限公司 | 视频数据传输方法及装置 |
| CN112261057A (zh) * | 2020-10-28 | 2021-01-22 | 湖南天琛信息科技有限公司 | 一种音视频通话的加密处理系统 |
| CN112423007A (zh) * | 2020-11-09 | 2021-02-26 | 杭州叙简科技股份有限公司 | 一种基于组播的webrtc的视频流传输系统 |
| CN112671944A (zh) * | 2020-12-18 | 2021-04-16 | 杭州叙简科技股份有限公司 | 一种基于webrtc和ice探测的音视频交互方法 |
| CN113014544A (zh) * | 2021-01-25 | 2021-06-22 | 阳光凯讯(北京)科技有限公司 | 基于webRtc无中心媒体链路建立方法及装置 |
| CN113691822A (zh) * | 2021-08-04 | 2021-11-23 | 江苏怀业信息技术股份有限公司 | 一种WebRTC Simulcast的自适应调节方法和装置 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101262361A (zh) * | 2008-04-14 | 2008-09-10 | 中国网络通信集团公司 | 实现广播业务的方法及系统 |
| EP2096838A1 (en) * | 2008-02-29 | 2009-09-02 | Design Srl Telecom | Interactive system for synchronized multimedia communication on the web |
| CN101551821A (zh) * | 2009-05-19 | 2009-10-07 | 周佺喜 | 一种在网页中进行实时信息广播的方法 |
| CN103384247A (zh) * | 2013-07-05 | 2013-11-06 | 福建星网锐捷通讯股份有限公司 | 一种基于sip监控系统的视频多播实现方法 |
-
2015
- 2015-09-30 CN CN201510639340.3A patent/CN106559396B/zh active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2096838A1 (en) * | 2008-02-29 | 2009-09-02 | Design Srl Telecom | Interactive system for synchronized multimedia communication on the web |
| CN101262361A (zh) * | 2008-04-14 | 2008-09-10 | 中国网络通信集团公司 | 实现广播业务的方法及系统 |
| CN101551821A (zh) * | 2009-05-19 | 2009-10-07 | 周佺喜 | 一种在网页中进行实时信息广播的方法 |
| CN103384247A (zh) * | 2013-07-05 | 2013-11-06 | 福建星网锐捷通讯股份有限公司 | 一种基于sip监控系统的视频多播实现方法 |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107948676A (zh) * | 2017-12-08 | 2018-04-20 | 苏州科达科技股份有限公司 | 视频数据传输方法及装置 |
| CN112261057A (zh) * | 2020-10-28 | 2021-01-22 | 湖南天琛信息科技有限公司 | 一种音视频通话的加密处理系统 |
| CN112423007A (zh) * | 2020-11-09 | 2021-02-26 | 杭州叙简科技股份有限公司 | 一种基于组播的webrtc的视频流传输系统 |
| CN112423007B (zh) * | 2020-11-09 | 2022-07-08 | 杭州叙简科技股份有限公司 | 一种基于组播的webrtc的视频流传输系统 |
| CN112671944A (zh) * | 2020-12-18 | 2021-04-16 | 杭州叙简科技股份有限公司 | 一种基于webrtc和ice探测的音视频交互方法 |
| CN113014544A (zh) * | 2021-01-25 | 2021-06-22 | 阳光凯讯(北京)科技有限公司 | 基于webRtc无中心媒体链路建立方法及装置 |
| CN113014544B (zh) * | 2021-01-25 | 2023-02-10 | 阳光凯讯(北京)科技有限公司 | 基于webRtc无中心媒体链路建立方法及装置 |
| CN113691822A (zh) * | 2021-08-04 | 2021-11-23 | 江苏怀业信息技术股份有限公司 | 一种WebRTC Simulcast的自适应调节方法和装置 |
| CN113691822B (zh) * | 2021-08-04 | 2023-11-07 | 江苏怀业信息技术股份有限公司 | 一种WebRTC Simulcast的自适应调节方法和装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN106559396B (zh) | 2019-12-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106559396A (zh) | 基于Web实时通信的媒体多播方法和系统 | |
| CN110213652B (zh) | 一种音视频数据传输方法、装置及存储介质 | |
| CN100583989C (zh) | 媒体流传输方法 | |
| CN101702725A (zh) | 一种流媒体数据传输的系统、方法及装置 | |
| CN109408015A (zh) | 一种多媒体文件处理方法、发送终端和显示终端 | |
| CN108063911B (zh) | 一种视频会议扩容方法 | |
| CN101370137A (zh) | 流媒体传输以及播放方法、系统和用户端设备 | |
| WO2016144366A1 (en) | Real-time transport protocol (rtp) media conference server routing engine | |
| CN102195955A (zh) | 一种直播业务和时移业务的切换方法以及相应设备 | |
| US20220078169A1 (en) | Methods, systems, and media for providing secure network communications | |
| CN103283205A (zh) | 本地媒体再现 | |
| US9264662B2 (en) | Chat preauthorization | |
| CN101635919B (zh) | 一种ip多媒体系统会议媒体数据的加密方法及系统 | |
| CN102594794B (zh) | 一种媒体加密会议的接入方法及装置 | |
| CN105187678B (zh) | 一种电话会议室桥接的方法及VoIP服务器 | |
| CN102256165B (zh) | 一种用于网络电视机顶盒的视频会议权限分享系统的方法 | |
| CN112202882B (zh) | 一种传输方法、客户端及传输系统 | |
| CN104283771B (zh) | 用于移动终端的im用户协同通讯方法与系统 | |
| CN113297603A (zh) | 数据处理方法、装置、设备、存储介质和程序产品 | |
| CN211791776U (zh) | 一种分布式录播系统 | |
| CN108810475A (zh) | 一种基于Onvif标准及Sip协议的Android视频监控装置 | |
| CN105338286B (zh) | 一种辅流传输方法及装置 | |
| CN101997677B (zh) | Ip多媒体子系统中会议媒体流密钥的管理方法与装置 | |
| Goncalves et al. | LiveCity: A Secure Live Video-to-Video Interactive City Infrastructure | |
| CN113612734A (zh) | 一种跨网远程庭审媒体流的传输方法和装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |