1、nack协商
m=video 9 RTP/AVPF 96 97 98 99 100 101127 122 108 109 123
a=rtpmap:96 H264/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=fmtp:96 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
video协商为h264(payload type=96)
从sdp可得到：
1）profile-level-id=42001f
Profile: 66(hex: 42)
Level: 3.1(hex:1f)转成十进制，再除以10
2）packetization-mode=1
表示I帧会拆分成多个rtp包发送，对于264来说，rtppayload的第一个字节（0x7C）的低5bit为(11100)，十进制为28，代表此nalutype为FU-A，多包封装类型。
3）RTP/AVPF
AVPF中的F表示支持RTCP的传输层保护，S表示安全保护（SRTP）
4) a=fmtp:97 apt=96
表示96类型的rtp包的重传包采用97的payloadtype的rtx包保护，rtx包的rtp header中的sequence num与rtp不一致，但timestamp一致。
Rtx包的payload的前两个字节为原重传rtp包的rtp sequencenum
2、webrtcpeerconnection_client项目修改项
1）去掉srtp
a) peerconnectionFactory的setOption接口关闭 encryption选项
webrtc::PeerConnectionFactoryInterface::Optionsoptions;
options.disable_encryption=true;
peer_connection_factory_->SetOptions(options);
b) peer_connection_factory_->CreatePeerConnection接口关闭dtls srtp选项
webrtc::PeerConnectionInterface::RTCConfigurationconfig;
config.sdp_semantics = webrtc::SdpSemantics::kUnifiedPlan;
config.enable_dtls_srtp= false;
2）去掉FEC
增加关闭FEC的参数
webrtc::field_trial::InitFieldTrialsFromString(FLAG_force_fieldtrials)
FLAG_force_fieldtrials = WebRTC-DisableUlpFecExperiment/Enabled/
3、wireshark抓包分析
1）rtx_rtp.pcapng为20%随机丢包下的webrtc p2p抓包
过滤条件：(ip.src==10.25.8.112 and(rtp.p_type==96 or rtp.p_type==97)) or (rtcp and ip.dst==10.25.8.112 andrtcp.rtpfb.fmt == 1)
rtcp.rtpfb.fmt == 1代表nack报文
2）nack报文结构
81 cd 00 03 a5 1f d8 4a 52 5e 1a 85 34 0f 00 00
a) rtcp header 4bytes(81 cd 00 03)
100 00001 (81)第一个字节
高2 bit（10）为vesion应为2
1bit表示rtcp是否补齐（padding） 0为不需要补齐，为1时，rtcp payload的最后一个字节的值为 paddingsize
5bit表示rtcp feedback message type(fmt)值为1
11001101 (cd)第二个字节
第二个字节表示packet type，值为205
Packet type（205）和fmt（1）确定此报文为nack报文
（00 03）第三、四字节
第三个字节表示rtcp的长度（不包括rtcp header的4 bytes）nack报文长度恒为16(3*4+4)
b) Nack payload(a5 1f d8 4a 52 5e 1a 8534 0f 00 00)
4 bytes sender SSRC（a5 1f d8 4a），发送RTCP的track的rtp ssrc，如果为（recvonly），此值为0
4 bytes media source SSRC（52 5e 1a 85）,请求重传包对应的rtp ssrc
2 bytes rtcp transport feedback nack pid（34 0f）,确定丢包的起始rtp sequenceNum（13327）
2 bytes rtcp transport feedback nack bitmask（0000）,由起始pid开始的16个包组的丢包情况，此值是转成binary的掩码，bit为1表示丢包，00 00表示只有pid对应的包丢失。
3）rtx重传包
Rtx原理：重发的包封装到RTX包里发送，RTX包与原RTP有不同的SSRC，不同的rtpseq，但是timestamp与丢失包的时间戳相同。
Rtx优势：rtp重传包在带宽估计时不计入运算，使用rtx比较方便，不使用rtx统计丢包率有时会出现负值
Rtxpayload：前两个字节代表丢失包的rtp seq，因此rtx包比丢失的rtp包多2个字节
4）webrtc中rtp发送端处理RTCP NACK报文过程见“发送端处理RTCPNACK报文过程.pdf”
5）webrtc中rtp接收端发现丢包，并发送nack请求过程见“rtp接收端发送nack过程.pdf”
文档资料和抓包如果需要的话，可留邮箱。
