Webrtc 基础传输技术架构： 
媒体流的传输到对等端，涉及到媒体信息协商、网络建连协商、网络传输技术。
RTP(Real-time Transport Protocol）通过IP网络实时传输音频和视频。遵循RFC3550。
大多数RTP应用都是基于UDP构建的，并额外提供抖动补偿，包丢失检测和无序传递检测功能。RTP也支持TCP，但应用的少，因为TCP更注重可靠性而不是实时性。
RTP主要特点：
*）具有较低的延时
*）对端接收到RTP数据包后，需要根据数据包的序列号和时间戳进行重新组合
*）支持多播（multicast）
*）可用于音视频通话之外的场景，如实时数据流，状态实时更新，控制信息传输等连续数据传输场景
RTP本身并没有提供服务质量保障功能(Quality of Service,Qos),所以，在WRBRTC中，RTP需要结合RTCP使用。
RTP会为每个媒体流建立一个会话，即音频和视频流使用单独的RTP会话，这样接收端能选择性地接收媒体流。RTP使用的端口号为偶数，每个关联的RTCP为下一个较高的奇数，端口范围为1024~65535.
1.RTP 配置文件于载荷
RTP标头数据中不包含媒体信息，而是在单独的RTP配置文件（profile）和有效载荷（payload）格式中提供。RTP对每类应用（音频或者视频）都定义了一个配置文件和至少一个有效的载荷格式。
| 载荷类型 |
名称 |
类型 |
通道数 |
频率 |
默认包 |
参考规范 |
| 0 |
PCMU |
audio |
1 |
8000 |
20 |
RFC3551 |
| 8 |
PCMA |
audio |
1 |
8000 |
20 |
RFC3551 |
| 9 |
G722 |
audio |
1 |
8000 |
20 |
RFC3551 |
| 26 |
JPEG |
video |
9000 |
RFC2435 |
RTP 的配置文件包括以下3种：
*）音频和视频会议的RTP配置文件。该配置文件定义了一组静态有效载荷类型分配以及使用会话描述协议（SDP）在有效载荷格式和PT值之间进行映射的动态机制。
*）SRTP(RFC 3711)定义了一个RTP配置文件，改配置文件提供用于传输有效载荷数据的加密服务，Webrtc 使用的就是SRTP
*)用于机器对机器通信的RTP(RTP/CDP)实验性控制数据配置文件。
P （Padding）：表示RTP数据包末尾是否有额外的Padding 字节。
X( 扩展名):，表示在标头和有效载荷数据之间是否存在扩展标头。
CC(CSRC计数）:表示包含CSRC标识符的数量。
M（标识）:表示在应用程序级别使用的信令。
PT(有效载荷类型，7）：表示有效载荷的格式，从而确定应用程序对其的解释，其值是特定于配置文件的，可以动态分配。
序列号（16位）：RTP数据包的序列号。每发送一个RTP数据包，序列号都会递增，接收方将使用该序列号检测包丢失并适应无序交付。为了提升RTP的安全性，序列号的初始值应随机分配。
时间戳（32位）：RTP数据包的时间标识。接收端以此在适当的时间播放接收到的样本。当存在几个媒体流时，每个流的时间戳都是独立的。时间的粒度特定于应用程序， 如音频应用程序常见的采样率是125us对数据进行一次采样，换算成时钟频率为8kHz，而视频应用程序通常使用90kHz时钟频率。时间戳反映了发送者采样RTP报文的时刻，接受者使用时间戳计算延迟和延迟抖动，并进行同步控制。
SSRC（32位）：表示RTP数据包的同步源，用于标识媒体源。同一RTP会话中的同步源是唯一的。
CSRC(32位）:表示RTP数据包的贡献源，同一RTP会话可以包含多个贡献源。
标头扩展名：可选项，由扩展名字段决定是否存在。每一个32位字包含一个特定于配置文件的标识符（16位）和一个长度说明符（16位）。
SDP
SDP(Session Description Protocol）是用于描述媒体信息的协议，以文本格式描述终端功能和首选项。建立连接的双方通过交互SDP获取彼此的分辨率、编码格式、加密算法等媒体信息。SDP广泛用于会话启动协议(SIP)、RTP和实时流协议（RSP）。
SDP包含一下内容：
*）会话内容
*）会话活动时间
*）媒体编解码
*）媒体地址和端口信息
*）网络带宽的信息。
| 字段 |
含义 |
格式 |
| v = |
SDP版本 |
v =0 |
| o = |
会话发起人和标识信息 |
o =<username> <sessionid><version><network type> <address Type><address> |
| s = |
会话名称 |
s = <seesion name> |
| i = * |
会话信息 |
i = <seesion descrption> |
| u = * |
描述的URI |
u = <URI> |
| e = * |
Email 地址 |
e =<email address> |
| p = * |
电话号码 |
p = <phone number> |
| c = * |
连接信息 |
c = <network type><address type><connection addess> |
| b = * |
带宽信息 |
b = <modifier <bandwidth-value> |
| z = * |
时区校正 |
Z = <adjustment time><offset> |
| k = * |
密钥 |
K =<method><encryption key> |
| a = * |
会话属性 |
a = <attribute><value> |
| t = |
会话有效时间 |
t=<start time> <stop time> |
| r = * |
重复次数 |
r = <repeat interval> <active duration><list of offsets from start-time> |
| m = |
媒体名称和传输地址 |
m =<media><port><transport><fmt list> |
| i = |
标题 |
I = <media or session title> |
ICE:
当通信双方尝试建立P2P连接时，如果有一方位于NAT内部，则直接建立P2P会失败，这时候必须有一种能够突破NAT限制的技术，这个技术就是ICE协议。
ICE技术建立网络连接的步骤如下：
1）第一次尝试：ICE首先尝试使用本地网卡与对方建立P2P连接，此地址通常为内网地址。
2）如果第一次尝试失败，则ICE将使用STUN服务器获取NAT设备的公网IP地址以及映射端口，并尝试使用该IP地址建立连接。对于只有一方位于NAT网络内部，或者双方都位于非对称NAT 网络内部的情况，连接通常会建立。
3）第三次尝试，如果第二次尝试失败，这时候需要通过一个中介进行数据中转，这个中介就是TURN 服务器。可以说，第三次尝试是直接与TURN服务器建立连接，而随后的媒体流数据流将通过TURN中继服务器进行转发。
顺序如下：
使用内网IP地址。
使用STUN发现公网IP地址。
使用TURN作为网络中继。
1)全锥形NAT
2)地址受限锥形NAT
只接收曾经发送到对端IP地址的数据包。任意外部主机（hostAddr:any)都能通过ip2:port2发送到ip1:port1，但前提是ip1:port之前有向hostAddr:any 发送过包，any表示端口不受限制。
3）端口受限锥形NAT(Port-Restricted cone NAT)
一个外部主机（hostAddr:port3)能够发包到ip1:port1的前提是ip1:port1之前有向hostAddr:port3发送过包。
4）对称NAT
对于锥形NAT，无论与哪一个外网主机通信，都不会改变所分配的端口号，而对于对称NAT，同一内网主机，同一端口号，每一次与不同的外网主机通信，就重新分配一个端口号。
使用STUN建立的是P2P的网络模型，网络直接建立在通信两端，没有中间服务器介入，而使用TRUN建立的是流量中继的网络模型，用户两端都与TRUN服务器建立连接，用户的网络数据包通过TURN服务器进行转发。