ICE概要

一、ICE产生的背景

基于信令协议的多媒体传输是一个两段式传输。首先，通过信令协议（如SIP）建立一个会话连接，通过该连接，会话双方（Agent）通过SIP交互所承载的SDP消息彼此学习传输媒体时所必须的信息，针对媒体传输机制达成共识。然后，通常采用RTP协议进行媒体传输。

基于传输效率的考虑，通常在完成第一阶段的交互之后，通信双方另外建立一条直接的连接传输媒体。这样就会减少传输时延、降低丢包率并减少开销。这样，用于SIP传输的链路就不再用于传输媒体。现在，问题出现了，由于不采用原来的链路，当传输双方中任一方位于NAT之后，新的传输链接必须考虑NAT穿越问题。

通常有四种形式的NAT，对于每一中NAT方式，都有相应的解决方案。然而，每一种NAT穿越解决方案都局限于穿越对应得NAT方式，对于复杂的网络环境来说，将会出现无法进行媒体传输的情况，同时这些方案给整个系统带来了在不同程度上的脆弱性和复杂性。

在这种背景下，Interactive Connectivity Establishment（交互式连通建立方式）也即ICE解决方案应运而生。ICE方式能够在不增加整个系统的复杂性和脆弱性的情况下，实现对各种形式的NAT进行穿越，使得媒体流在通信双方顺利传输。

More...

导读：疫情期间，视频会议等远程办公产品备受青睐，众多互联网玩家切入视频会议市场，加剧市场竞争。但是，产品虽多，能够带来稳定可靠体验的产品却凤毛麟角，它的难点在哪里？视频会议的门槛到底有多高，又能够做到怎样的极致体验？网易智慧企业流媒体服务器天团将会从0到1，和大家分享如何基于WebRTC来搭建一个视频会议。

入门篇

先请出我们今天的主角 - WebRTC，它是由谷歌推广的实时音视频技术栈，是音视频领域搜索热度最高的技术。它有多重身份，既是W3C的标准，也是一个开源项目，还有一个对应的IETF工作组(RTCWEB)。在WebRTC出现之前，音视频通信是高不可攀的领域，需要大量的专业积累才能入门，而现在，越来越多的开发者通过WebRTC来深入了解RTC技术。

WebRTC技术的本质是构建点对点的实时通信，目前主流的浏览器，包括Chrome, Firefox, Edge等，天然就支持WebRTC协议。对入门开发者来说，选用这几款浏览器，连开发客户端的时间都省了。最简单的Web视频会议，只需要架设一个Web服务器，服务器兼具信令交换的能力(信令服务也可以独立部署)，两个浏览器通过Web Server交换会话信息，就能建立P2P通道来传输媒体流，进行1v1的视频会议。如下图所示。

More...

《聊聊WebRTC网关服务器》第一篇文章将和大家分享如何选择服务端的端口方案。

标准WebRTC连接建立流程

在讨论如何选择服务器端的端口方案前，我们先来看看标准WebRTC的连接建立流程，这为我们理解这篇文章后续内容提供最基础的知识。

More...

一、什么是SDP
        SDP(Session Description Protocol)描述会话协议，它只是一种信息格式的描述标准，本身不属于传输协议，但是可以被其他传输协议用来交换必要的信息，用于两个会话实体之间的媒体协商。
        SDP（Session Description Protocol）是一个用来描述多媒体会话的应用层控制协议，为会话通知、会话邀请和其它形式的多媒体会话初始化等目的提供了多媒体会话描述；它是一个基于文本的协议，这样就能保证协议的可扩展性比较强，这样就使其具有广泛的应用范围；SDP 完全是一种会话描述格式 ― 它不属于传输协议 ― 它只使用不同的适当的传输协议，包括会话通知协议（SAP）、会话初始协议（SIP）、实时流协议（RTSP）、MIME 扩展协议的电子邮件以及超文本传输协议（HTTP）。SDP 不支持会话内容或媒体编码的协商，所以在流媒体中只用来描述媒体信息。媒体协商这一块要用RTSP来实现。
会话目录用于协助多媒体会议的通告，并为会话参与者传送相关设置信息。SDP 即用于将这种信息传输到接收端。在因特网组播骨干网（Mbone）中，会话目录工具被用于通告多媒体会议，并为参与者传送会议地址和参与者所需的会议特定工具信息，这由 SDP 完成。SDP 连接好会话后，传送足够的信息给会话参与者。SDP 信息发送利用了会话通知协议（SAP），它周期性地组播通知数据包到已知组播地址和端口处。这些信息是 UDP 数据包，其中包含 SAP 协议头和文本有效载荷（text payload）。这里文本有效载荷指的是 SDP 会话描述。此外信息也可以通过电子邮件或 WWW （World Wide Web） 进行发送。SDP 文本信息包括：会话名称和意图； 会话持续时间； 构成会话的媒体； 有关接收媒体的信息（地址等）。

More...

写在前面：RTP的解析，网上找了很多资料，但是都不全，所以我力图整理出一个比较全面的解析，

其中借鉴了很多文章，我都列在了文章最后，在此表示感谢。

互联网的发展离不开大家的无私奉献，我决定从我做起，希望大家支持。

More...

目录：
一、   WebRTC学习进阶之路 --- 概述、原理、源码目录结构与整体架构介绍
二、   WebRTC学习进阶之路 --- 网络编程基础、TCP/IP详解
三、   WebRTC学习进阶之路 --- WebRTC网络知识详解(一)(P2P/NAT/STUN/TURN/ICE)
四、   WebRTC学习进阶之路 --- WebRTC网络知识详解(二)(加解密/SSL/OpenSSL/TLS/DTLS/SRTP)
五、   WebRTC学习进阶之路 --- WebRTC网络知识详解(三)(最全流媒体协议(RTP/RTCP/RTSP/RTMP/MMS/HLS/HTTP/ HTTP-FLV(HDL)/SDP)
六、   WebRTC学习进阶之路 --- Web服务器原理、服务器基础编程知识
七、   WebRTC学习进阶之路 --- WebRTC核心之SDP详解、媒体协商
八、   WebRTC学习进阶之路 --- 信令服务器
九、   WebRTC学习进阶之路 --- 设备管理、音视频数据采集
十、   WebRTC学习进阶之路 --- 非音视频数据传输
十一、WebRTC学习进阶之路 --- 异步I/O时间处理、epoll
十二、WebRTC学习进阶之路 --- 下载源码及各操作系统的源码编译详细步骤
十三、WebRTC学习进阶之路 --- 分析源码音视频互动peerconnection-client+server实例
十四、WebRTC学习进阶之路 --- 源码分析之WebRTC中的线程详解-ThreadManager&Thread
十五、WebRTC学习进阶之路 --- 源码分析之WebRTC中的线程详解-MessageQueueManager&MessageQueue&Message&MessageHandler
十六、WebRTC学习进阶之路 --- 源码分析之最核心的内容PeerConnection
十七、WebRTC学习进阶之路 --- 源码分析之WebRTC的数据流水线详解&模块机制核心ProcessThread与ProcessThreadImpl
十八、WebRTC学习进阶之路 --- 源码分析之视频采集和视频数据的流水线分析

More...

More...

SDP协议用来在SIP终端之间交换媒体信息,WebRTC标准中同样选用了
SDP协议来交换媒体信息.

More...

WebRTC名称源自网页实时通信(Web Real-Time Communication)的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的技术，是谷歌2010年以6820万美元收购Global IP Solutions公司而获得的一项技术。Google于2011年6月3日开源的即时通讯项目，旨在使其成为客户端视频通话的标准。其实在Google将WebRTC开源之前，微软和苹果各自的通讯产品已占用很大市场份额（如Skype），Google`也是为了快速扩大市场，所以将他给开源。在行业内得到了广泛的支持和应用，成为下一代视频通话的标准。更多介绍可以去官网上看。

WebRTC被誉为是web长期开源开发的一个新启元，是近年来Web开发的最重要创新。WebRTC允许Web开发者在其web应用中添加视频聊天或者点对点数据传输，不需要复杂的代码或者昂贵的配置。目前支持Chrome、Firefox和Opera，后续会支持更多的浏览器，它有能力达到数十亿的设备。

然而，WebRTC一直被误解为仅适合于浏览器。事实上，WebRTC最重要的一个特征是允许本地和web应用间的互操作，很少有人使用到这个特性。

本文主要以开源项目AndroidRTC为例。
下载后通过Android Studio打开，打开的时候可能会报错，说找不到org.json:json:20090211，这时只要将AndroidRTC/webrtc-client/build.gradle中的

More...

STUN简介

在前言里我们看到，RFC3489和RFC5389的名称都是STUN，但其全称是不同的。在RFC3489里，STUN的全称是Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)， 即穿越NAT的简单UDP传输，是一个轻量级的协议，允许应用程序发现自己和公网之间的中间件类型，同时也能允许应用程序发现自己被NAT分配的公网IP。这个协议在2003年3月被提出，其介绍页面里 说到已经被STUN/RFC5389所替代，后者才是我们要详细介绍的。

RFC5389中，STUN的全称为Session Traversal Utilities for NAT，即NAT环境下的会话传输工具，是一种处理NAT传输的协议，但主要作为一个工具来服务于其他协议。和STUN/RFC3489 类似，可以被终端用来发现其公网IP和端口，同时可以检测端点间的连接性，也可以作为一种保活（keep-alive）协议来维持NAT的绑定。和RFC3489最大的不同点在于，STUN本身不再是一个 完整的NAT传输解决方案，而是在NAT传输环境中作为一个辅助的解决方法，同时也增加了TCP的支持。RFC5389废弃了RFC3489，因此后者通常称为classic STUN，但依旧是后向兼容的。 而完整的NAT传输解决方案则使用STUN的工具性质，ICE就是一个基于offer/answer方法的完整NAT传输方案，如SIP。

STUN是一个C/S架构的协议，支持两种传输类型。一种是请求/响应（request/respond）类型，由客户端给服务器发送请求，并等待服务器返回响应；另一种是指示类型（indication transaction），由服务器或者客户端 发送指示，另一方不产生响应。两种类型的传输都包含一个96位的随机数作为事务ID（transaction ID），对于请求/响应类型，事务ID允许客户端将响应和产生响应的请求连接起来； 对于指示类型，事务ID通常作为debugging aid使用。

所有的STUN报文信息都含有一个固定头部，包含了方法，类和事务ID。方法表示是具体哪一种传输类型（两种传输类型又分了很多具体类型），STUN中只定义了一个方法，即binding（绑定），其他的方法可以由使用者 自行拓展；Binding方法可以用于请求/响应类型和指示类型，用于前者时可以用来确定一个NAT给客户端分配的具体绑定，用于后者时可以保持绑定的激活状态。类表示报文类型是请求/成功响应/错误响应/指示。 在固定头部之后是零个或者多个属性（attribute），长度也是不固定的。

More...