0x00 WebRTC RTP Header Extension 格式说明
在 RTP协议 rfc3550 section 3.5.1 中定义 RTP header extension 结构如下图所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| defined by profile | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extension |
| .... |
o=- 2833773620626745940 2 IN IP4 127.0.0.1
s=-
t=0 0
仅个人理解，如有错误之处，还请指正。
SDP中H264的参数很多，仅介绍总结实际产品中常用到的几个。下面是实际使用中常见的H264参数：
a=fmtp:108 profile-level-id=420014;packetization-mode=1;max-mbps=108000;max-fs=3600;max-fps=3000;max-br=1500;max-dpb=891;level-asymmetry-allowed=1
1.profile-level-id:
profile-level-id是16进制表示的3个字节的整数，按顺序分成3个字节，每个字节分别表示不同的含义。
profile_idc
profile-iop: 前6位分别是constraint_set0_flag, constraint_set1_flag, constraint_set2_flag, constraint_set3_flag, constraint_set4_flag, constraint_set5_flag, 最后两位为保留位
level_idc
接收端默认支持哪种sub-profile由profile_idc和profile-iop中的几个bit共同决定。如下表：
1. 简介
stun协议本身是用来进行NAT穿透使用，其本身实际上是NAT内部设备获取外部IP地址的一种协议。STUN协议在RFC上目前经过三种演变，其中RFC3489上定义的STUN和之后的RFC5389和8489上定义的stun在概念上存在明显区分：
RFC3489定义：Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN)
RFC5389和RFC8489：Session Traversal Utilities for NAT (STUN)
可以看到STUN协议的英文描述本身就已经发生了变化，3489中定义的是通过UDP进行NAT穿越的方式，而在RFC5389上定义的是对于NAT穿越的一整套工具集，这个工具集不在局限于UDP而是同时适用于UDP和TCP协议。
1.RTP实战源码框架
在win上主要是支持qt，使用2015编译器。linux上支持cmake编译。主要是支持跨平台支持。
使用函数int get_annexb_nalu (nalu_t *nalu, FILE *bits)，一开始是读取本地h264文件，解析出不带startcode的nalu，接着是函数static void rtp_h264_pack_get_info(void* pack, uint16_t* seq, uint32_t* timestamp)，经过函数就会得到RTP包，处理RTP包就有2个流程，第一个是通过网络发送出去，然后播放。另外一个流程是通过RTP_unpack去解码，生成nalu，再加上h264的start code，就可以存储在本地文件，然后再播放。框架如下图所示:
随着信息产业的发展，人们对信息资源的要求已经逐渐由文字和图片过渡到音频和视频，并越来越强调获取资源的实时性和互动性。但人们又面临着另外一种不可避免的尴尬，就是在网络上看到生动清晰的媒体演示的同时，不得不为等待传输文件而花费大量时间。为了解决这个矛盾，一种新的媒体技术应运而生，这就是流媒体技术。流媒体由于具有启动时延小、节省客户端存储空间等优势，逐渐成为人们的首选，流媒体网络应用也在全球范围内得到不断的发展。其中实时流传输协议 RTP 详细说明了在互联网上传递音频和视频的标准数据包格式，它与传输控制协议 RTCP 配合使用，成为流媒体技术最普遍采用的协议之一。
H.264/AVC 是ITU-T 视频编码专家组（VCEG）和ISO/IEC 动态图像专家组（MPEG ）联合组成的联合视频组（JVT）共同努力制订的新一代视频编码标准，它最大的优势是具有很高的数据压缩比率，在同等图像质量的条件下，H.264 的压缩比是MPEG-2 的2 倍以上,是 MPEG-4的1.5～2 倍。同时，采用视频编码层（VCL）和网络提取层（NAL ）的分层设计，非常适用于流媒体技术进行实时传输。本文就是基于 RTP 协议，对 H.264 视频进行流式打包传输，实现了一个基本的流媒体服务器功能，同时利用开源播放器VLC 作为接收端，构成一个完整的H.264 视频传输系统。
第1章介绍
1. 为什么要进行视频压缩？
2. 为什么可以压缩
3. 数据压缩分类
完整的C／S架构的基于RTP／RTCP的H．264视频传输方案。此方案中，在服务器端和客户端分别进行了 功能模块设计。 服务器端：RTP封装模块主要是对H．264码流进行打包封装；RTCP分析模块负责产牛和发送RTCP包并分析接收到的RTCP包；QoS反馈控制模块则根据RR报文反馈信息动态的对发送速率进行调整；发送缓冲模块则设置端口发送RTP、RTCP包。 客户端：RTP模块对接收到的RTP包进行解析判断；RTCP模块根据SR报文统计关键信息，产牛并发送RR包。然后，在VC++6．0下用Socket编程，完成基于RTP／UDP／IP的H．264视频传输，并在局域网内运行较好。
基于RTP／UDP／lP的H．264视频传输结构设计
对于H．264视频的实时传输应用来说，TCP的重传机制引入的时延和抖动是无法容忍的，因此我们采用UDP传输协议。但是UDP协议本身是面向无连接的，不能提供质量保证。而基于UDP之上的高层协议RTP／RTCP可以一起提供流量控制和拥塞控制服务。图给出了基于RTP／UDP／IP的H．264视频传输的框架。
H264以NALU（NAL unit）为单位来支持编码数据在基于分组交换技术网络中传输。
NALU定义了可用于基于分组和基于比特流系统的基本格式，同时给出头信息，从而提供了视频编码和外部世界的接口。
H264编码过程中的三种不同的数据形式：
SODB 数据比特串－－＞最原始的编码数据，即VCL数据；
RBSP 原始字节序列载荷－－＞在SODB的后面填加了结尾比特（RBSP trailing bits 一个bit“1”）若干比特“0”,以便字节对齐；
EBSP 扩展字节序列载荷-->在RBSP基础上填加了仿校验字节（0X03）它的原因是： 在NALU加到Annexb上时，需要添加每组NALU之前的开始码StartCodePrefix,如果该NALU对应的slice为一帧的开始则用4位字节表示，ox00000001,否则用3位字节表示ox000001（是一帧的一部分）。另外，为了使NALU主体中不包括与开始码相冲突的，在编码时，每遇到两个字节连续为0，就插入一个字节的0x03。解码时将0x03去掉。也称为脱壳操作。