SDP协议用来在SIP终端之间交换媒体信息,WebRTC标准中同样选用了
SDP协议来交换媒体信息.
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中的
在前言里我们看到，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），长度也是不固定的。
WebRTC被称为开源网络发展的又一大里程碑，被看作为近些年对Web标准的最重要的创新。WebRTC允许开发者在网页应用中添加音视频，并且折不需要复杂的代码和昂贵的其他的基础设备。现在有Chrome、Firfox和Opera都已经支持了WebRTC，并将有更多的浏览器也将会支持，数十亿的设备已经支持了。
然而，WebRTC也被称为城市神话(很多人都相信但实际上并不真实的故事)：WebRTC仅仅可以应用在浏览器上。事实上，WebRTC最重要的一个特征是它允许nativ和web app之间的互操作(跨平台)的。很少有人利用这一个特征优势。
这篇Blog将介绍给你如何在你的Android应用中集成WebRTC，使用了WebRTC提供的本地库，提供者:WebRTC Initiative。我们不会强调通过signalling建立连接，而是强调Android和浏览器间的相似和差异。正如你将看到的，将包含一些连接到Web的APIs，如果你想看到更多的基本的关于WebRTC的介绍，请看：Sam Dutton’s Getting started with WebRTC。
WebRTC被誉为是web长期开源开发的一个新启元，是近年来web开发的最重要创新。WebRTC允许Web开发者在其web应用中添加视频聊天或者点对点数据传输，不需要复杂的代码或者昂贵的配置。目前支持Chrome、Firefox和Opera，后续会支持更多的浏览器，它有能力达到数十亿的设备。
然而，WebRTC一直被误解为仅适合于浏览器。事实上，WebRTC最重要的一个特征是允许本地和web应用间的互操作，自然也可以在Android应用中植入WebRTC 。
WebRTC Android端的大体实现过程如下：（在不考虑播放本地视频的情况下）
RTSP（实时流协议）
RTSP中使用会话概念代替连接，由于它本身不与传输层绑定，因此RTSP会话在传输层支持TCP与UDP协议发送请求。RTSP客户机和服务器都可以发出请求，本身并不携带传输的媒体数据，而是控制RTP协议进行媒体数据传输。由于RTSP控制通过单独协议发送流，与控制通道无关，因此RTSP会话状态标记了服务器流资源的分配情况，如果对数据进行提取数据，需要同时进行流媒体数据传输协议（RTP协议）的解析。
Stun服务器 : 服务器用于获取设备的外部网络地址 Turn服务器 : 服务器是在点对点失败后用于通信中继 信令服务器 : 负责端到端的连接。两端在连接之初，需要交换信令，如sdp、candidate等，都是通过信令服务器 进行转发交换的。iOS PC BroswerMediaStream：通过MediaStream的API能够通过设备的摄像头及话筒获得视频、音频的同步流RTCPeerConnection：RTCPeerConnection是WebRTC用于构建点对点之间稳定、高效的流传输的组件RTCDataChannel：RTCDataChannel使得浏览器之间（点对点）建立一个高吞吐量、低延时的信道，用于传输任意数据。 其中RTCPeerConnection是我们WebRTC的核心组件。