一、什么是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 文本信息包括：会话名称和意图； 会话持续时间； 构成会话的媒体； 有关接收媒体的信息（地址等）。
WebRTC学习进阶之路 --- 七、WebRTC核心之SDP详解、媒体协商
2020-06-20 16:03:32RTP协议全解析（H264码流和PS流）
2020-06-20 16:02:07写在前面：RTP的解析，网上找了很多资料，但是都不全，所以我力图整理出一个比较全面的解析，
其中借鉴了很多文章，我都列在了文章最后，在此表示感谢。
互联网的发展离不开大家的无私奉献，我决定从我做起，希望大家支持。
WebRTC学习进阶之路
2020-06-20 15:50:33目录：
一、 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学习进阶之路 --- 源码分析之视频采集和视频数据的流水线分析
WebRTC56版本SDP详细解析
2020-06-20 15:47:58WebRTC SDP协议
2020-06-20 15:47:30SDP协议用来在SIP终端之间交换媒体信息,WebRTC标准中同样选用了
SDP协议来交换媒体信息.
Android WebRTC简介
2020-06-09 08:47:41WebRTC名称源自网页实时通信(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中的
P2P通信标准协议之STUN
2020-06-03 13:53:06STUN简介
在前言里我们看到，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 CDN 实现
2020-06-03 13:51:57WebRTC应用可能出现的网络错误
2020-05-29 10:16:07
Android上WebRTC介绍
2020-01-09 09:31:39WebRTC被称为开源网络发展的又一大里程碑，被看作为近些年对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。