webrtc-RTPRTSPRTCP的概念

在不同的网络环境(带有摄像头/麦克风多媒体设备)中，为两个浏览器实现点对点实时视频/语音通信有什么困难

1、了解对方的媒体格式、支持的最大分辨率和其他媒体信息？

2、要了解彼此的网络，就有可能找到一条通信链路？

3、两个终端还没有建立连接时,如何交换“媒体信息”和“网络信息”呢
为了保证两端都有正确的编码和解码，最简单的方法就是取它们的交集H264

注:有一种特殊的协议叫做Session Description protocol (SDP)，可以用来描述上述信息 。

在webrtc中，参与视频通信的双方必须首先交换SDP信息，这样双方才能了解基本的SDP交换过程。
同样，在复杂的网络环境中，要在两端之间建立连接，必须有一个双方都可以访问的链路。
从图中可以看出，他们可以使用公用网段192沟通。

在web brtc通信过程中，这些与网络相关的信息也必须进行交换，以找到共同的交集。这个过程也被称为“网络协商”。
两个终端还没有建立连接时,如何交换“媒体信息”和“网络信息”呢

此时，所谓信号服务器信号服务器应该出现:
如上图所示,两个浏览器可以抽象的上层一层信令服务器(可以是一个或多个,根据实际的应用程序中,如果两个浏览器可以访问公共网络环境,如公共如果没有公共网络环境中,您可以设置一组服务器两端,即信号服务器A和信号服务器B，但这两套信令服务器必须能够相互通信)，在信令服务器的帮助下，可以实现上述SDP信息和网络信息的交换。
交换SDP的过程大致如图所示:
1 Amy(假设一个人的名字)通过setLocalDescription方法保存自己的SDP信息，然后通过offer方法发送给信令服务器。

2 信息服务器将Amy的SDP转发给另一端的Bob(另一个虚构的名字)，Bob将首先调用setremotedescription来保存Amy的SDP。

3然后Bob调用setLocalDescription方法来保存他的SDP，然后使用answer方法通过信令服务器将他的SDP发送给Amy

4 Amy收到Bob的SDP后，调用setRemoteDescription进行保存，双方完成SDP交换，找到交集。如果他们能达成协议，他们就可以建立一个p2p连接并开始通信。
但现实往往是残酷的。在中国的网络环境下，据统计，至少有一半的网络不能直接连接。我个人认为根本原因是:在互联网发展的早期，绝大多数IP4地址资源都被国外所占据。当轮到中国等发展中国家使用IP地址时，大多数计算机没有公网IP地址，只能通过路由器和交换机进行NAT转换，相当一部分NAT是对称的。基本上，没有办法播放它。在这种情况下，您只能使用前一节提到的转向服务器进行转移。此外，在视频对话框中，通常会有房间(或组)的概念，用来隔离一些服务。这部分逻辑也在信号服务器中实现。对端、信令服务器、stun/转接服务器后，整个1对1实时视频通信顺序图如下:
主要流程如下:

1 双方首先调用getUserMedia打开本地摄像头

2 向信令服务器发送apply_join请求以加入房间

3信令服务器通知我成功加入(joined)，同时向其他人广播加入消息(other_joined)

4 第二个端开始创建peerConnection连接

5 PeerB创建报价，同时将SDP保存到本地机器(setLocalDescription)，并通过信令服务器将SDP传递给peerA

6 在setLocalDescription之后，PeerB将异步触发“候选网络链接”的集合，这大致决定了它自己所有的NAT映射通过Stun退出。如果Stun返回的NAT是“对称的”，它将基本上无法穿透。再次通过Turn得到中继应答地址，并通过信令服务器将网络候选链接信息发送给peerA(即:启动网络协商)

7 peerA收到peerB的SDP后，开始响应(createAnswer)，仍然通过信令服务器将SDP发送给peerB

8 同时，peerA也会开始收集网络候选链路，并通过信令服务器(即网络协商)将自己的网络信息发送给peerB。

通过这种方式，peerA和peerB相互交换了媒体信息和网络信息。如果他们能达成一致(即找到交叉点)，他们就能开始沟通。

WebRTC（Web Real-Time Communication）也被称为网络实时通信，是由 Google、Mozilla 和其他公司推动的一个开源项目，它通过 Javascript API 实现无插件的实时通信，以及在不需要中介的情况下在浏览器之间交换任意数据。

WebRTC的优点：

WebRTC技术的诞生，有一个很重要的原因在于，在浏览器实现实时音视频通话，需要依赖相关插件或程序，而插件安全漏洞问题则更为关键。浏览器开发人员无法控制这些插件以及更新，因此插件带来的安全风险也相对较大。

在WebRTC诞生之前，开发实时音视频应用的成本是非常高，需要考虑的技术问题很多，如音视频的编解码，数据传输延时、丢包、网络抖动、回音处理和消除等，如果要兼容浏览器端的实时音视频通信，还需要额外安装插件。当然，可以考虑使用第三方成熟技术，比如当时世界顶级的互联网音视频方案GIPS(Global IP Solutions)，支付相应的费用就行。很多知名的应用或者软件服务商也都在用GIPS，如Yahoo，AOL，IBM，SKYPE，QQ等。

WebRTC项目的愿景：实时通信web化，让WebRTC成为互联网音视频实时通信的规范，让开发者基于此规范快速开发出安全、可靠的应用。未来的音视频实时通信，必定是现代化生产活动中极其重要的板块。以下是WebRTC的部分应用场景：

两个不同网络环境的（具备摄像头/麦克风多媒体设备的）客户端（浏览器或APP），要实现点对点的实时音视频对话，难点在哪里？

要实现P2P通信，首先需要了解彼此是否都支持相同的媒体能力，WebRTC默认使用V8编解码器，如果要连接的对方不支持V8解码，如果没有媒体协商过程。那么即使连接成功，把视频数据发给对方，对方也无法播放
比如：Peer-A端可支持VP8、H264多种编码格式，而Peer-B端支持VP9、H264，要保证二端都正确的编解码，最简单的办法就是取它们的交集H264
有一个专门的协议 ，称为Session Description Protocol (SDP)，可用于描述上述这类信息，在WebRTC中，参与视频通讯的双方必须先交换SDP信息，这样双方才能知根知底，而交换SDP的过程，也称为"媒体协商"。

交换数据会通过一个中间服务来完成，在这里，我们称之为信令服务器
在建立P2P连接时，需要交换的信息有：

最理想的场景

然而，在大多数情况下，两个对等端都是各自处于某个局域网之中，相互之间隔着NAT与防火墙

NAT(Network Address Translation)即为网路地址转换协议

局域网-->公网

公网-->局域网

可以借助STUN服务器，穿越NAT

在NAT四种主要类型中有三种是可以使用STUN穿透：完全圆锥型NAT、受限圆锥型NAT和端口受限圆锥型NAT。但大型公司网络中经常采用的对称型 NAT（又称为双向NAT）则不能使用STUN穿透，这类路由器会透过 NAT 布署所谓的「Symmetric NAT」限制。也就是说，路由器只会接受之前连线过的节点所建立的连线。

可以点对点连接的情况与需要中转的情况（数据来源于Google）

不过在国内大部分局域网无法穿越。

WebRTC目前已经比较成熟了，播放也比较稳定，协议也已经成为了RFC，相应的开源项目也比较多。当然我觉得WebRTC还缺一个高性能简单易用的服务器，之前也分析过现有的服务器，有各种问题，SRS很有机会解决这些问题。

目前SRS对WebRTC的支持进度如下：

相关Wiki：

在线演示，RTMP推流，>