当前位置: 首页 > wzjs >正文

上海翼成信息科技有限公司做的什么网站用wordpress做企业门户

上海翼成信息科技有限公司做的什么网站,用wordpress做企业门户,容易做的html5的网站,买东西的网站1. Webrtc三种类型通信架构 1.1 1 对 1 通信 1 对 1 通信模型设计的主要⽬标是尽量让两个终端进⾏直联,这样即可以节省服务器的资源,⼜可以提⾼ ⾳视频的服务质量。WebRTC ⾸先尝试两个终端之间是否可以通过 P2P 直接进⾏通信,如果⽆法直接…

1. Webrtc三种类型通信架构

1.1  1 对 1 通信

1 对 1 通信模型设计的主要⽬标是尽量让两个终端进⾏直联,这样即可以节省服务器的资源,⼜可以提⾼ ⾳视频的服务质量。WebRTC ⾸先尝试两个终端之间是否可以通过 P2P 直接进⾏通信,如果⽆法直接通信 的话,则会通过 STUN/TURN 服务器进⾏中转,如下图:

 1.2  多对多通信

Mesh 架构:适合刚学习 WebRTC 的场景,简单易实现,但实际应用中因上行带宽占用大、线性资源占用等问题,超过 4 人时问题明显,几乎无人在真实场景中使用。

MCU 架构:硬件 MCU 曾在视频会议广泛应用,技术成熟,但价格昂贵,且随着互联网发展逐步被淘汰;软 MCU 如 FreeSWITCH 虽存在,但因 CPU 消耗大,真正使用者不多。

SFU 架构:近年来流行,是 WebRTC 多方通信媒体服务器的主流架构,具有高灵活性和高性能,配合 Simulcast 或 SVC 模式可更好地适应不同网络和终端,被多数公司采用。

Janus的多方视频通话使用VideoRoom插件,采用SFU架构。

mesh(P2P)SFUMCU
延迟最低(直连)中等(服务器中转)最高(处理流程复杂)
带宽消耗上行压力大(N²增长)下行压力大(服务器承担)整体最低(单一流)
扩展性差(适合1:1)优(适合中小型会议)一般(适合大型会议)
服务器成本低(仅需穿透辅助)中(高带宽需求)高(计算+带宽双重压力)
终端要求需处理多流解码需多流解码能力仅需解码单一流
灵活性高(端到端控制)高(自由订阅流)低(布局固定)
典型应用微信语音、Skype 1:1Zoom、腾讯会议传统硬件视频会议系统
特点多对多,Mesh 结构发布订阅混流集合

 

 

 1.2.1 架构优点

架构

方案

优势
Mesh 架构

- 无需中转服务器,直接利用 WebRTC 通信模型,无需额外开发媒体服务器,降低了开发成本和复杂度。

- 充分利用客户端的带宽资源,将服务器端的带宽压力分散到各客户端,节省了服务器成本。

- 原有通信模型的简洁性,这种架构充分利用了现有的 WebRTC 通信模型,结构相对简单,易于实现和维护。

MCU 架构

- 技术成熟,在硬件视频会议领域应用广泛,技术相对成熟可靠,能够提供稳定的通信服务。

- 兼容性强,作为音视频网关,通过解码、再编码可以屏蔽不同编解码设备之间的差异化,满足更多客户的集成需求,提升用户体验和产品竞争力。

- 统一画面输出,将多路视频混合成一路,所有参与者看到的是相同的画面,有助于提供一致的客户体验。

SFU 架构

- 低资源消耗,数据包直接转发,不需要进行编解码操作,对 CPU 资源消耗很小,降低了服务器的硬件成本和运营成本。

- 低延迟,数据包直接转发极大地降低了延迟,提高了通信的实时性,适合对实时性要求较高的应用场景。

- 灵活性高,可以根据终端下行网络状况进行流控,如根据带宽、网络延时情况选择性地丢弃一些媒体数据,以保证通信的连续性,更好地适应不同的网络状况和终端设备。

- 支持多种模式,许多 SFU 实现支持 SVC 模式和 Simulcast 模式,能够更好地适配 WiFi、4G 等不同网络状况,以及 Phone、Pad、PC 等不同终端设备,提高了系统的兼容性和可用性。

        Simulcast 模式就是指视频的共享者可以同时向 SFU 发送多路不同分辨率的视频流(⼀般为三路, 如 1080P、720P、360P)。⽽ SFU 可以将接收到的三路流根据各终端的情况⽽选择其中某⼀路发送出 去。例如,由于 PC 端⽹络特别好,给 PC 端发送 1080P 分辨率的视频;⽽移动⽹络较差,就给 Phone 发送 360P 分辨率的视频。 Simulcast 模式对移动端的终端类型⾮常有⽤,它 可以灵活⽽⼜智能地适应不同的⽹络环境。      

         SVC( Scalable Video Coding) 是可伸缩的视频编码模式。与 Simulcast 模式的 SVC 模式是 同时传多路流不同, 在视频编码时做“ ⼿脚” 。它在视频编码时将视频分成多层—— 核⼼层、中间层和扩展层。上层依赖于底层,⽽且越上层越清晰,越底层越模糊。在带宽不好的情况下,可以只传输核⼼层在带宽充⾜的情况下,可以将三层全部 传输过去。

  

 2. Janus 系统架构

        Janus 被设计为通用的 WebRTC 服务器,专注于模块化和可扩展性。它提供必要的 WebRTC 基础设施,同时将特定的应用程序逻辑委托给插件。这种分离使 Janus 变得轻量级和灵活,无需更改内核即可支持广泛的用例。

架构的关键原则:

  • 模块化设计:核心组件通过定义明确的接口清晰分离
  • 基于插件的可扩展性:所有特定于应用程序的逻辑都在插件中实现
  • 多传输支持:用于客户端交互的多种通信协议
  • 媒体和信令分离:WebRTC 媒体处理和信令逻辑之间的明确分离

全局架构图如下:

2.1 核心组件

        Janus 核心处理 WebRTC 和会话管理基础知识,提供插件和传输构建的基础基础设施。

2.1.1 会话和句柄模型

Janus 中最重要的架构概念之一是 session/handle 模型:

  • 会话:表示用户与 Janus 的连接
  • Handle:表示用户与特定插件之间的连接
  • PeerConnection:与句柄关联的 WebRTC 连接
  • transaction:表示当前消息信息的唯一句柄

这种关系在用户、插件和媒体连接之间建立了明确的分离。客户端与 Janus 创建会话。在此会话中,客户端可以附加到多个插件(创建句柄)。每个句柄都有自己的 WebRTC PeerConnection,用于管理媒体交换。

 

2.1.2 会话管理

会话是客户端连接到 Janus 的核心抽象。会话管理系统处理:

  • 会话创建和销毁
  • 会话超时(可配置,默认 60 秒)
  • 会话声明(在传输断开连接后恢复会话)

每个会话都包含句柄,这些句柄是会话和插件实例之间的桥梁。会话层维护客户端与其插件附件之间的关系。

2.1.3 Media Handl管理

Janus 的媒体处理层负责 WebRTC 连接和媒体处理。ICE (Interactive Connectivity Establishment) 组件处理:

  • 候选人聚集和交流
  • NAT 遍历
  • 连接建立
  • 用于安全连接的 DTLS 协商
  • 用于加密媒体的 SRTP

 ​​​​​

媒体路径处理:

  • RTP/RTCP 数据包从 routing 到plugins
  • SDP offer/answer 处理
  • 媒体统计和监控
  • 数据包重传的 NACK 处理
  • TWCC(全交通拥堵控制)

 

2.2 插件系统

        Janus 提供了一个插件架构,允许开发人员在不修改核心代码库的情况下实现各种 WebRTC 应用程序。插件向 Janus 核心注册,并为消息处理和媒体处理等事件实施回调。内核仅负责 WebRTC 连接和数据包路由,而插件则决定媒体会发生什么并实现应用程序逻辑。

Janus 包含的常见插件:

  • VideoRoom:用于多方视频会议的选择性转发单元 (SFU)
  • AudioBridge:具有混音功能的音频会议
  • 流式处理:媒体流式处理(RTP、RTSP、HLS 源)
  • SIP:用于 WebRTC 到 SIP 互作性的 SIP 网关
  • EchoTest:用于测试 WebRTC 功能的简单 echo 测试插件
  • TextRoom:基于数据通道的文本聊天室
  • RecordPlay:WebRTC 会话的录制和播放

插件 API 公开了允许插件执行以下作的函数:

  • 接收和发送媒体 (RTP/RTCP)
  • 与客户交换消息
  • 管理 WebRTC 连接
  • 处理 SDP offers/answers
  • 通过 Data Channel 发送和接收数据

2.3 传输层

        传输层提供客户端和 Janus 服务器之间的通信通道。可以同时使用多种传输机制,从而灵活地选择客户端连接到 Janus 的方式。

  • HTTP/REST:用于请求-响应交互的传统 REST API
  • WebSockets:实时双向通信
  • RabbitMQ:基于消息队列的通信
  • MQTT:轻量级发布-订阅消息传递
  • Unix 套接字:同一台机器上的进程间通信

        所有传输都实现相同的 API,无论底层协议如何,都为核心提供一致的接口。这允许客户端选择最适合其需求的传输机制。

传输层负责:

  • 身份验证请求(如果已配置)
  • 解析和验证 JSON 消息
  • 将请求路由到适当的会话/句柄
  • 将事件和响应返回给客户端

2.4 事件处理程序

        事件处理程序为外部应用程序提供了一种监视和响应 Janus 中发生的事件的方法。这些事件可以包括会话创建/销毁、媒体统计、特定于插件的事件等。事件处理程序(如传输和插件)在启动时动态加载,并在内核中注册。它们从核心接收事件,并将其转发到外部系统进行监控、记录或处理。

2.5 数据流架构

        下图说明了在典型的 WebRTC 交互期间通过 Janus 架构的完整数据流。此流程展示了 Janus 的不同层如何协同工作以处理 WebRTC 信令、媒体交换和特定于应用程序的逻辑。各个组件之间的干净分离实现了灵活性和可扩展性。

英文版: 

 

学习资料分享

0voice · GitHub

http://www.dtcms.com/wzjs/543151.html

相关文章:

  • 外贸产品开发网站用wordpress做的网站有哪些
  • 建设心理网站的背景咨询公司经营范围大全
  • 网站建设价格怎么算那个装修公司的网站做的好
  • 计算机毕设网站开发中期报告做斗图的网站
  • 知名做网站公司有哪些关键词网站建设价格
  • 怎样创建网站的代码双流县规划建设局网站
  • 如何抄袭网站上海物流网站建设
  • 网站建设的用户环境中文互联网巨头衰亡史
  • 网站排名易下拉效率seo产品优化免费软件
  • 太原网站建设列表网深圳flash网站建设
  • 网站怎么做用什么软件尚云网站建设
  • 烟台网站建设电话黄山seo排名优化技术
  • 建设网站为网站网站做广告东莞有哪些互联网公司
  • 做网站服务器硬盘多大购买淘宝店铺
  • 米课做网站node.js网站开发框架
  • 网站不显示域名解析错误怎么办软件开发的几个阶段
  • 网站建设教程视频百度云怎样做分销网站
  • 中国建设银行官方网站悦生活深圳外贸公司前十名
  • 重庆石桥铺网站建设做网站ui
  • 面料做电商 哪个网站好在线制作图片视频
  • 南宁网站怎么做seo互联网网站备案表
  • 中国石化工程建设公司网站临沂招聘信息最新招聘
  • 好用的seo软件广东seo推广软件
  • 建设银行官网首页 网站1核1g可以做几个网站
  • 公司网站建设多少费用哪儿济南兴田德润联系电话黄骅港高铁最新进展
  • 简单个人网站设计剁椒怎么做制作方法
  • 网站托管目的是什么重庆网站推广产品企业
  • 学做美食交流网站有哪些做引流推广的平台
  • 东晓南门户网站制作好看网站的浏览器
  • 网站全站开发需要学什么教育集团网站建设