目前为止已经有几个减少端口使用的策略:
- rtp/rtcp复用端口的方案rtcp-mux.
- 音视频的boundle, 可以让音视频复用连接通道.
- 包括后面出现的多路流复用单peerconnection的plan b和unified plan方案, 最新的webrtc标准都已经转向了unified plan.
这些策略都在不断的在消减端口的使用, 但即使上面的这些策略全部开启, 单个用户还是要占用最少一个端口, 如果一个WebRTC服务器要服务1000个用户, 就要开启1000个端口.
WebRTC 媒体服务器中使用单端口
2020-06-23 08:42:46WebRTC网关服务器单端口方案实现
2020-06-22 14:50:21标准WebRTC连接建立流程
这里描述的是Trickle ICE过程，并且省略了通话发起与接受的信令部分。流程如下：
1） WebRTC A通过Signal Server转发SDP OFFER到WebRTC B。WebRTC B做完本地处理以后，通过 Signal Server转发SDP ANSWER到A。
2）A、B同时向STUN Server发送Binding request请求自身的外网地址，并从STUN Server回包的MAPPED-ADDRESS中得到各自的外网地址；
3）A、B收集完内外网ICE Candidate，并通过Signal Server发送给对方；
4）双方开始做NAT穿越，互相给对方的ICE Candidate发送STUN Binding Request；
5）NAT穿越成功，A、B之间的P2P连接建立，进入媒体互通阶段。在这个过程中，我们看到了有三个核心的部分，SDP协商、ICE Candidate交换、Stun Binding Req/Res的连通性检查。
WebRTC 开发实践：如何实现 SFU 服务器
2020-06-22 14:08:081 什么是 SFU ？
首先，我们再看一次 SFU 服务器的定义，什么是 SFU ？
SFU 的全称是：Selective Forwarding Unit，是一种路由和转发 WebRTC 客户端音视频数据流的服务端程序。
webrtc sfu实现原理
2020-06-22 14:07:19High-performance WebRTC SFU
基于WebRTC的SFU多人音视频通话（服务端+客户端）
--------------------------------------------------------------------------------
SFU(Selective Forwarding Unit)，如果不太了解自行谷歌。
SFU服务器起到了router的作用，已占用较小的cpu和内存实现更为灵活的多方通话，这个特
性有别于MCU。
本系统包含基于WebRTC开发的SFU服务器，以及windows端基于webrtc实现的客户端；
使用方法
--------------------------------------------------------------------------------
1、启动SFU服务器(Server.exe)，默认端口是6666。不建议修改端口，客户端不支持设置端口。
记住SFU服务器的IP地址，如：192.168.1.101。
2、分别在不同的机器上启动客户端Client.exe。然后点击加入频道，输入服务器IP地址，以及
房间号（房间号可以自己随意填写），房间号相同的人会进入相同的房间；同理，房间号不
同的人会进入不同的房间。
特性
--------------------------------------------------------------------------------
1、多个会议室、多人参与。
2、用到的协议ICE / DTLS / RTP / RTCP等协议。
3、支持IPv6。
4、高效率 (使用c++编码，考虑到内存和性能)。
5、支持录制，或者加载媒体文件分享给伙伴（未完成）
WebRTC网关服务器搭建：开源技术 vs 自行研发
2020-06-22 09:12:00大家好，我是黄开宁，来自即构科技，从事音视频开发已经超过10年了，虽然如此，在技术迅速更新迭代的时代，我们还是需要时刻保持学习的状态。今天，我主要跟大家介绍以下四个方面的内容：
● 为什么需要WebRTC网关？对于即构来说，目前所使用的系统已经较为成熟且经过了市场的检验，为什么还要在如此成熟的商用系统中加入WebRTC？
● WebRTC通信模型的对比，分析不同的模型对应的适用场景，以便大家在选型时能结合自己的需求匹配对应的场景。
● 开源VS自研，主要介绍市面上的开源系统及其特点，另外还会分析即构自行研发系统的目的和出发点。
● Zego-Gateway架构的实践，分享即构在开发过程中遇到的一些难题和解决方法。
为什么需要WebRTC网关
在WebRTC 1.0标准还没有定稿之前，这个标准只具备雏形，在很多方面都有缺陷。而随着1.0标准的定稿，WebRTC逐渐完善，到现在已经可以在网页端使用，换句话说，已经有基于WebRTC的实际应用。下面主要结合不同的应用场景来说明为什么需要WebRTC网关。
即构自研WebRTC网关服务器架构实践
2020-06-22 09:06:03Zego-Gateway架构的改进
在加入WebRTC网关之前，即构自研系统架构如下图所示，主要分成两部分，左边是低延时用户，而右边是围观用户。低延时用户主要是通过ZEGO的实时传输网络进行推拉流。
聊聊WebRTC网关服务器4：QoS方案分析
2020-06-22 09:01:43《聊聊WebRTC网关服务器》系列文章系由WebRTCon2018中网易云信音视频技术专家的分享内容《从零开始构建音视频网关服务器》整理而成，该系列文章将和大家分享网易NRTC在WebRTC网关项目的自研过程中遇到的一些问题，以及我们最终的解决方法。
大家都知道音视频应用中的QoS策略是非常重要的部分，这里我简单为大家介绍一下WebRTC网关服务端的QoS内容，因为篇幅问题，具体的算法细节这里就不作阐述了。
本篇文章分享的内容会涉及：NACK、PLI、RTT、GCC算法、REMB与Transport-CC，ULP-FEC。
WebRTC的QoS是一个非常大的门类，也是非常重要的方向，它里面涵盖的内容非常多。有大量的QoS策略是在客户端上实现的。而对于Web来说，那些客户端侧的策略你是没办法修改的，只能通过SDP里面的配置项，来选择需要开启的策略。
聊聊WebRTC网关服务器3：如何优化Server的线程方案？
2020-06-22 08:59:51《聊聊WebRTC网关服务器》系列文章系由WebRTCon2018中网易云信音视频技术专家的分享内容《从零开始构建音视频网关服务器》整理而成，该系列文章将和大家分享网易NRTC在WebRTC网关项目的自研过程中遇到的一些问题，以及我们最终的解决方法。
在分享完端口方案与PeerConnection的方案后，本篇文章我们将讲解如何优化WebRTC网关服务器的线程方案。这个也是网关服务器架构设计的核心部分。
我们做WebRTC网关服务器的时候，不仅要考虑功能可用，还要考虑并发性能。有三种方案可以选择：
- 第一种方案是一种多线程的方案，就是为每一个client或者是每一个PeerConnection建立一个独立的线程去做收发。这个方案的劣势很明显，它跨线程的流程就会很多，效率也不高。但是，这确实是某些开源服务器的方案；
- 第二种方案是单线程的方案，所有用户的I/O以及业务操作都在服务端的一个线程里做完，在用户量不大或者服务端硬件资源可以隔离的情况下，它是一个比较好的方案。但是这种方案也有劣势，当我们使用物理机作为服务器时，单线程是没有办法利用多核优势的；如果同时启动多个进程，则需要多个外网端口和域名，维护的成本也会比较高；
- 第三种方案是多线程优化方案，也是网关一期实现的方案，I/O单独在一个线程来做，同一个通话的用户在同一个业务逻辑线程做业务操作，同时创建一组业务逻辑线程为所有用户服务。
我们看一下这个方案具体是怎么做的？
聊聊WebRTC网关服务器2：如何选择PeerConnection方案？
2020-06-22 08:49:13《聊聊WebRTC网关服务器》系列文章系由WebRTCon2018中网易云信音视频技术专家的分享内容《从零开始构建音视频网关服务器》整理而成，该系列文章将和大家分享网易NRTC在WebRTC网关项目的自研过程中遇到的一些问题，以及我们最终的解决方法。
《聊聊WebRTC网关服务器》第二篇文章将和大家分享如何选择PeerConnection方案。
ICE概要
2020-06-22 08:43:21ICE概要
一、ICE产生的背景
基于信令协议的多媒体传输是一个两段式传输。首先，通过信令协议（如SIP）建立一个会话连接，通过该连接，会话双方（Agent）通过SIP交互所承载的SDP消息彼此学习传输媒体时所必须的信息，针对媒体传输机制达成共识。然后，通常采用RTP协议进行媒体传输。
基于传输效率的考虑，通常在完成第一阶段的交互之后，通信双方另外建立一条直接的连接传输媒体。这样就会减少传输时延、降低丢包率并减少开销。这样，用于SIP传输的链路就不再用于传输媒体。现在，问题出现了，由于不采用原来的链路，当传输双方中任一方位于NAT之后，新的传输链接必须考虑NAT穿越问题。
通常有四种形式的NAT，对于每一中NAT方式，都有相应的解决方案。然而，每一种NAT穿越解决方案都局限于穿越对应得NAT方式，对于复杂的网络环境来说，将会出现无法进行媒体传输的情况，同时这些方案给整个系统带来了在不同程度上的脆弱性和复杂性。
在这种背景下，Interactive Connectivity Establishment（交互式连通建立方式）也即ICE解决方案应运而生。ICE方式能够在不增加整个系统的复杂性和脆弱性的情况下，实现对各种形式的NAT进行穿越，使得媒体流在通信双方顺利传输。