1笔呀、nack協(xié)商
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協(xié)商為h264(payload type=96)
從sdp可得到：
1）profile-level-id=42001f
????? Profile: 66(hex: 42)
????? Level: 3.1(hex:1f)轉(zhuǎn)成十進制掘而，再除以10
2）packetization-mode=1
?? 表示I幀會拆分成多個rtp包發(fā)送咧七，對于264來說拆融，rtppayload的第一個字節(jié)（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的前兩個字節(jié)為原重傳rtp包的rtp sequencenum
2掀鹅、webrtcpeerconnection_client項目修改項
1）去掉srtp
??? a) peerconnectionFactory的setOption接口關(guān)閉 encryption選項
???? ?webrtc::PeerConnectionFactoryInterface::Optionsoptions;
?? options.disable_encryption=true;
??peer_connection_factory_->SetOptions(options);
? b) peer_connection_factory_->CreatePeerConnection接口關(guān)閉dtls srtp選項
?webrtc::PeerConnectionInterface::RTCConfigurationconfig;
?config.sdp_semantics = webrtc::SdpSemantics::kUnifiedPlan;
?config.enable_dtls_srtp= false;
2）去掉FEC
增加關(guān)閉FEC的參數(shù)
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報文結(jié)構(gòu)
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)第一個字節(jié)
????? 高2 bit（10）為vesion應(yīng)為2
?? 1bit表示rtcp是否補齊（padding） 0為不需要補齊媒楼，為1時乐尊，rtcp payload的最后一個字節(jié)的值為?paddingsize
??5bit表示rtcp feedback message type(fmt)值為1
???? 11001101 (cd)第二個字節(jié)
?? 第二個字節(jié)表示packet type，值為205
??Packet type（205）和fmt（1）確定此報文為nack報文
?? （00 03）第三划址、四字節(jié)
?? 第三個字節(jié)表示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）扔嵌，發(fā)送RTCP的track的rtp ssrc，如果為（recvonly）夺颤，此值為0
??4 bytes media source SSRC（52 5e 1a 85）,請求重傳包對應(yīng)的rtp ssrc
??2 bytes rtcp transport feedback nack pid（34 0f）,確定丟包的起始rtp sequenceNum（13327）
??2 bytes rtcp transport feedback nack bitmask（0000）,由起始pid開始的16個包組的丟包情況痢缎，此值是轉(zhuǎn)成binary的掩碼，bit為1表示丟包世澜，00 00表示只有pid對應(yīng)的包丟失独旷。
3）rtx重傳包
Rtx原理：重發(fā)的包封裝到RTX包里發(fā)送，RTX包與原RTP有不同的SSRC，不同的rtpseq嵌洼，但是timestamp與丟失包的時間戳相同案疲。
??Rtx優(yōu)勢：rtp重傳包在帶寬估計時不計入運算，使用rtx比較方便麻养，不使用rtx統(tǒng)計丟包率有時會出現(xiàn)負(fù)值
?? Rtxpayload：前兩個字節(jié)代表丟失包的rtp seq褐啡，因此rtx包比丟失的rtp包多2個字節(jié)
4）webrtc中rtp發(fā)送端處理RTCP NACK報文過程見“發(fā)送端處理RTCPNACK報文過程.pdf”
5）webrtc中rtp接收端發(fā)現(xiàn)丟包，并發(fā)送nack請求過程見“rtp接收端發(fā)送nack過程.pdf”
文檔資料和抓包如果需要的話回溺，可留郵箱春贸。
