便宜VPS网用SRS搭建WebRTC流媒体服务器实战
WebRTC经过这么多年的发展，目前已经比较成熟的协议之一，播放也比较稳定，协议也已经成为了RFC，相应的开源项目也越来越多，但是基于WebRTC协议的部署简单，性能强悍，功能强大流媒体服务器的项目还比较稀少。之前了解到的服务器比如Mediasoup，Janus，Medooze ，要么就是设计复杂，接入成本要，要么就是性能较差，还就是多种语言结合，学习成本较高。 而SRS聚焦视频相关，功能专一，语言使用了高性能的c++,并且支持Rtmp转Webrtc等其他强大的功能的媒体服务器。
1.源码编译安装运行SRS
使用这个命令开启RTC支持
2.SRS常用命令
3.配置nginx代理
若不需要浏览器推流，可以不用设置nginx代理，使用localhost访问
注意：your 代表需要配置你自己的域名信息，由于使用浏览器推流必须使用https协议，所以我这边配置了证书
4.访问配置的域名
访问nginx配置的网址
出现如下内容，则服务端架设成功
虽然整片文章看起来不复杂，流程很简单。但是官网的文档中的知识点比较分散，所以大家要想快速的搭建的话就参考我这篇文章
webrtc 浏览器与浏览器需要信令服务器么
webrtc 浏览器与浏览器需要信令服务器。推荐选择ZEGO即构科技，该公司拥有4行代码，30分钟在APP、Web和小程序等应用内实现视频通话、语音通话，互动直播功能。【点击免费试用，0成本启动】
使用一个信令服务器，是为了能够在两个任意对等点之间建立连接。这是当今使用的Internet体系结构的简单现实。将任何内容从一个浏览器流到另一个浏览器的“传统”方式始终涉及中间的中继服务器。这是信令服务器进入的地方。两个对等方在彼此建立连接之前都已连接到信令服务器。因此，他们使用信令服务器代表他们中继消息，直到他们协商了直接的通话方式。如果没有本地子网的第三方的帮助，则可以协商连接。
想要了解更多关于这方面的相关信息，推荐咨询ZEGO即构科技。ZEGO即构科技是一家全球云通讯服务商，专注自研音视频引擎，服务覆盖全球，链接 5 亿终端用户。ZEGO即构科技覆盖212个国家/地区，全球用户体验毫秒级互动，日均通话时长达30亿分钟，跻身云通讯行业头部，全方位行业解决方案，满足百余个业务场景需要，服务客户4000家，70%泛娱乐/在线教育客户的选择。
WebRTC原理解析
浏览器本身不支持点对点建立信道进行通信，需通过服务器进行中转。因此浏览器之间一次通信需通过两段信道，通信效率同时受制于两段信道宽度，因此并不适合数据流的传输。
WebRTC是浏览器实时通信 RTC 的提供 JS 接口， JS 接口通过信令建立浏览器点对点(peer-to-peer,P2P)的信道，信道可发送任何数据并无需经过服务器。
WebRTC提供三个API
WebRTC使用 RTCPeerConnection 在浏览器之间传递流数据，此流数据通道是P2P的，无需服务器中转。但并不意味着能抛弃服务器，仍需服务器为传递信令(signaling)来建立信道。WebRTC没有定义用于建立信道的信令协议，信令并不是 RTCPeerConnection API 的一部分。
既然没有定义信令(signaling)的协议，可选择任意方式（如AJAX、WebSocket）任意协议（如SIP、XMPP）来传递信令，建立信道。
需要信令来交换信息分为：
通过服务器建立信道
WebRTC提供浏览器之间P2P信道进行数据传输，但建立这个信道必须有服务器的参与。
WebRTC需服务器提供：
NAT/防火墙穿越技术
在处于使用NAT设备的私有TCP/IP网络中的主机之间建立连接时需使用NAT穿越。NAT的行为是非标准化的，穿越技术大多使用公共服务器，使全球任何地方都能访问得到IP地址，在 RTCPeerConnection 中实用ICE框架来保证 RTCPeerConnection 实现NAT穿越。
ICE
ICE(Interactive Connectivity Establishment， 综合性NAT穿越技术)框架整合各种NAT穿越技术如STUN、TURN(Traversal Using Relay NAT，中继NAT实现的穿透)，ICE先使用STUN尝试建立一个基于UDP的连接，失败后实用TCP(先尝试HTTP然后尝试HTTPS)，若依然失败，ICE就会使用中继的TURN服务器。
RTCDataChannel
既然能建立P2P信道来传递实时音视频数据流，为什么不能使用此信道传递其他数据呢？ RTCDataChannel API 可实现浏览器之间传递任意数据。 DataChannel 是建立在 PeerConnection 之上的，不能单独使用。
WebRTC原理
WebRTC的实现是建立浏览器之间的直接连接而无需服务器中转，即P2P。因此要求彼此知道对方外网地址，而计算机大多位于NAT之后，少数主机拥有外网地址。这就要求一种方式可穿透NAT技术（STUN、TRUN）。
WebRTC实用默认STUN服务器获取当前主机的外网地址和端口，Chrome默认的是Google域名下的一个STUN，国内不大稳定。
P2P建立过程需依赖服务端中转（信令服务器），需实用双工通讯方式的WebSocket来实现信令的中转。
浏览器A创建一个 RTCPeerConnection 对象， RTCPeerConnection 自动向STUN服务器获取自己的外网IP与端口，然后将自己的网络信息经过信令服务器中转后发送给浏览器B。
浏览器B接收到A的网络信息后创建一个 RTCPeerConnection 对象，将接收的信息通过 addIceCandidate 添加到对象中。
浏览器A通过 RTCPeerConnection 对象的 createOffer() 获取本地音视频编码分辨率等信息，通过 setLocalDescription 添加到 RTCPeerConnection 中，并将这些信息经过信令服务器中转后发送给浏览器B。浏览器B接收到浏览器A发送过来的信息后，使用 RTCPeerConnection 对象的 setRomoteDescription() 保存。
iOS开发之WebRTC和SIP(转载)
1.SIP概念理解
2.【协议学习】SIP基本场景分析
3.企业开源SIP项目
4.SIP常见问题及处理
5.SIP基础入门
6.我的IOS端SIP电话开发历程
7.我的SIP开发之路
8.SIP协议开源SIP服务器搭建和客户端安装
1.WebRTC官网
2.大佬的笔记
3.WebRTC中文网
4.RTC.Blacker -Android IOS WebRTC
5.iOS下音视频通信-基于WebRTC
6.第六章 Webrtc服务器搭建
7.webrtc学习: 部署stun和turn服务器
8.webrtc编译全过程
9.iOS下WebRTC音视频通话（一）
10.iOS下WebRTC音视频通话（二）-局域网内音视频通话
11.WebRTC样本
12.iOS下音视频通信的实现-基于WebRTC
1. WebRTC简介及其与SIP互通
2.SIP和WebRTC有什么不同？
WebRTC 服务器要干些什么
WebRTC 的服务器大体分为信令服务器和媒体服务器
WebRTC 信令服务器是主要功能是为 WebRTC 通讯搭建一个了解彼此能力的通道, 交换信息, 同步改动.
而媒体服务器就是用来交换媒体，包括对媒体数据的加解密，编解码，带宽和速率控制等功能
不同的 RTP Toplogies 对服务器有不同的要求
WebRTC 或者说多媒体通信一般有如下的几种拓扑结构：
如果是两个人之间的端到端 (P2P) 的通信, 信令服务器的功能很简单
而由于是点对点的通信，媒体服务器也就不需要了。
如果是 SFU(Selective Forward Unit), 那么它的信令服务器除了上述的 SDP 媒体参数协商， ICE 连接地址交换，还有参加 RTP 会话的参加者信息的同步。
多个人之间的会议系统, 信令控制会麻烦很多,除了上述两个基本功能之外, 还要有
在 RFC4575 中有这样的定义
Multiple Control Unit 多点控制单元相比 SFU, 它有着对于媒体流的 Mix 和 translate 功能，可以很好地适配传统的通信设备，在实际应用中，一般我们会以 SFU 为主， MCU 为辅，共同形成一个服务器集群。
在 WebRTC 服务器上，我们一般会维护如下的领域对象
领域对象的具体内容从略，一般有如下的 Command 或 Event
应用层的事件大约可以分为 5 类
具体的有
在一个视频会议中，大家都在向会议室中发布自己的音视频流，也订阅他人的音视频媒体流，所以服务器，特别是 SFU 需要维护这样一个 pub-sub 发布者和订阅者之间的关系
WebRTC介绍
1、 WebRTC是什么？
2、 WebRTC能做什么?
3、 常用API
4、 基本原理
WebRTC全称是Web Real-Time communication，是一种实时音视频通讯技术，通过WebRTC可以使浏览器之间建立点对点的连接，并实时传输数据。
通过上述图片可以看到【浏览器M】和【浏览器L】可以在不依赖于Web服务器的情况下点对点实时传输数据。上图中的Web服务器不是用于数据传输，而是用于协助【浏览器M】和【浏览器L】进行连接，进行协助连接的服务器也叫【信令服务器】。
WebRTC主要分为四部分，分别是信令、建立连接、安全加密、数据传输，下面分别介绍四个步骤。
信令是指通信两端基于交换的数据进行协商。通俗的解释就是在互联网中两个浏览器之间如果要进行点对点的数据传输，连接双方需要交换对方的一些基本信息，基本信息包括对方的地址，带宽，数据的编解码格式，是否支持音视频等等信息。
通信双方的基本信息完成交换后，浏览器双方开始建立连接。在网络中，浏览器双方可能在同一个内网，可能不在同一个内网，中间可能还隔着交换机、路由器，还会存在防火墙。在网络的环境复杂的情况下，通信的双方需要找到一条最佳路径传输数据建立连接。建立连接主要使用的协议就是ICE协议。【ICE协议】又需要依赖【STUN协议】和【TURN协议】。
在WebRTC中，为了保证媒体传输的安全性，引入了【DTLS】作为传输加密协议，DTLS原理和作用类似于SSL/TLS，【DTLS】主要适用于UDP通信过程的加密，SSL/TLS主要适用于TCP通信过程的加密。
在WebRTC中，音视频数据传输是使用RTP协议，然后通过 DTLS 协商出加密密钥之后，RTP 也需要升级为 SRTP，通过密钥加密后进行通信。协议栈如下图所示：
上面说了对数据加密是使用DTLS，传输数据则分为两种情况，一种是传输音视频数据，另一种是传输自定义应用数据。
1、音视频数据传输，主要使用RTP/SRTP、RTCP/SRTCP协议
前面主要对WebRTC做了一个简单介绍，跳过了很多细节，有些地方可能不够严谨，如果有兴趣的读者，可以对技术做进一步研究，比如：
1、信令如何进行协商？
2、传输层用了UDP，UDP本身是不可靠的，那么，音视频数据、自定义用户数据的时序、质量是如何保证的？
3、RTP用来传递音视频数据，为什么还需要有RTCP？
4、SCTP如何从协议层面兼顾传输的效率和质量？如何实现自定义数据的高效传递？
5、ICE协议的完整流程。
6、其他。
