WebRTC 的数据交互使用 ICE 进行
(refs: https://www.w3.org/TR/webrtc/#intro)
(refs: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Protocols#ice)
WebRTC（ICE） 的通信由两部分组成：
1. 信令交互
信令主要用来传输媒体交互需要用到的 IP，端口，媒体格式（如分辨率，编码格式等），WebRTC 协议本身只规定了信令数据的格式（SDP），并没有规定如何传输（可以用 TCP 传输，也可以微信或用 U 盘手动拷贝传输，看你喜欢）。
Session description
v= (protocol version)
o= (originator and session identifier)
s= (session name)
i=* (session information)
u=* (URI of description)
e=* (email address)
p=* (phone number)
c=* (connection information -- not required if included in
all media)
b=* (zero or more bandwidth information lines)
One or more time descriptions ("t=" and "r=" lines; see below)
z=* (time zone adjustments)
k=* (encryption key)
a=* (zero or more session attribute lines)
Zero or more media descriptions
Time description
t= (time the session is active)
r=* (zero or more repeat times)
Media description, if present
m= (media name and transport address)
i=* (media title)
c=* (connection information -- optional if included at
session level)
b=* (zero or more bandwidth information lines)
k=* (encryption key)
a=* (zero or more media attribute lines)(refs: https://datatracker.ietf.org/doc/html/rfc4566#section-5)
2. 媒体数据交互
通过信令确认了数据接收的 IP 端口等信息后，就可以开始发送数据，WebRTC 使用 RTP 格式传输媒体数据，一般使用 UDP 协议传输（UDP 无法连通时，也有可能选用 TCP）
WebRTC 交互流程：
1.【发送 offerSdp】发起方生成 sdp ，通过信令服务发送到受邀方，主要用于协商媒体格式。
sdp 里面包含了发起方可以使用的媒体格式，sdp 里面可以包含 candidate
(refs: https://www.rfc-editor.org/rfc/rfc3264#section-10 - SDP Sample)
2.【回复 answerSdp】受邀方收到发起方的 sdp，结合自己可以使用的媒体格式生成一个 answerSdp 回复到发起方，至此双方已经沟通好将要使用的媒体格式。
extmap: SDP 扩展属性
(refs: https://datatracker.ietf.org/doc/html/rfc5285 - SDP extmap)
(refs: https://datatracker.ietf.org/doc/html/draft-ietf-avtext-sdes-hdr-ext-07 - SDP mid)
(refs: https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-msid - SDP msid cname)
fingerprint: SRTP 的 DTLS 加密指纹，refs: https://datatracker.ietf.org/doc/html/rfc5763#section-1
rtcp-fb: RTP Feedback ，RTP 数据流质量控制的相关算法
- goog-remb（Receiver Estimated Max Bitrate，refs: https://datatracker.ietf.org/doc/html/draft-alvestrand-rmcat-remb-03）
- transport-cc（Transport-Wide Congestion Control，refs: https://webrtc.googlesource.com/src/+/refs/heads/main/docs/native-code/rtp-hdrext/transport-wide-cc-02/README.md）
(refs: https://datatracker.ietf.org/doc/html/rfc4585#section-4.2 - SDP rtcp-fb)
3.【交换 candidate】双方开始检测自己可以用于收发媒体数据的地址（IP，端口，协议等），把检测到的可用地址通过信令服务发送到对端
(refs: https://datatracker.ietf.org/doc/html/rfc8445#section-5 - ICE Candidate Gathering and Exchange)
4.【确认 candidate】当收到对方发过来的 candidate 后，把candidate 分别组成 candidate-pair（相同协议，可以用于通讯的两端地址），并对 candidate-pair 进行连通性测试，把可以连通的 candidate-pair 作为数据收发地址。
ICE-Controlling 一方会使用 USE-CANDIDATE 标识来提名使用某一个连通的 candidate-pair，收到对端（ICE-Controlled方）回应确认后，即确定了该 candidate-pair 作为数据收发地址。
(refs: https://datatracker.ietf.org/doc/html/rfc8445#section-6.1.1 - ICE controlling or controlled)
(refs: https://datatracker.ietf.org/doc/html/rfc8445#section-2.2 - Connectivity Checks)
(refs: https://datatracker.ietf.org/doc/html/rfc8445#section-7.2.5.3.4 - USE-CANDIDATE)
5.【发送/接收 RTP 数据】candidate-pair 确认后，RTP 数据流会根据 SDP 里面设定的格式编码开始发送，RTP 的 SSRC 标识也在 SDP 里面得到，SSRC 用于标识数据属于哪条数据流。
(refs: https://datatracker.ietf.org/doc/html/rfc3550#section-3 - RTP Definitions)
（注：上图中 88.44 为 controlling 方，在 No.277 Binding Request 时已经附带 USE-CANDIDATE 标示，该 Binding Response 后，就已经成功建立连接，开始收发数据，No.281 开始发送数据，使用 DTLS 加密发送）
相关资料：
https://datatracker.ietf.org/doc/html/rfc4566 - SDP: Session Description Protocol
https://www.rfc-editor.org/rfc/rfc3264 - An Offer/Answer Model with the Session Description Protocol (SDP)
https://www.w3.org/TR/webrtc - WebRTC 1.0: Real-Time Communication Between Browsers
https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Protocols - MDN Introduction to WebRTC protocols
https://datatracker.ietf.org/doc/html/rfc8445 - ICE
https://datatracker.ietf.org/doc/html/rfc3550 - RTP: A Transport Protocol for Real-Time Applications
作者：骚骚的大卫
链接：https://www.jianshu.com/p/12c524b53b34
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。