webrtc中SDP解释

WebRTC SDP 的协议解释。

全局描述

o=- 4611731400430051336 2 IN IP4 127.0.0.1

• 第一个数字4611731400430051336是会话唯一标志
• 第二个数字2是会话的版本，当会话有新的协商或者应答时，例如（例如保持，编解码器更改，添加删除媒体轨道）的时候
• IN IP4 127.0.0.1这段描述的是创建SDP的网络IP和类型，与协商无关

s=-

• 这个是文本会话的名称，不常用

t=0 0

• 开始和结束时间。 都设置成0，这意味着会话不受限于特定的时间

a=group:BUNDLE audio video

• BUNDLE 分组建立了包括在SDP中的多个媒体线路，通常是音频和视频之间的关系。 在WebRTC中，它用于相同的RTP会话中复用多个媒体流。 在这种情况下，浏览器提供多路复用音频和视频，但是还必须由另一方支持和接受。

a=msid-semantic：WMS lgsCFqt9kN2fVKw5wg3NKqGdATQoltEwOdMS

• 此行给出了在PeerConnection生命期间WebRTC媒体流（WMS）的唯一标识符。 此标识符将用于属于特定媒体流（在我们的例子中为音频和视频m行）的每个m行的a = msid属性中。 这意味着RTP媒体流（由每个RTP分组中存在的SSRC字段标识）属于该媒体流，并且它是该媒体流的轨道。 它是单个RTP媒体流到MediaStream WebRTC对象的显式关联。 有关这方面的更多信息，请参阅draft-ietf-mmusic-msid

音频

m=audio 58779 UDP / TLS / RTP / SAVPF 111 103 104 9 0 8 106 105 13 126

• m意味着它是一个媒体行 - 它收集了很多关于流媒体属性的信息。按照这个顺序，它告诉我们：音频 - 媒体类型将用于会话（媒体类型在IANA注册），
  54278
  RTP / SAVPF-传输协议将用于会话，最后但并非最不重要
  111 103 104 0 8 106 105 13 126-浏览器支持媒体格式描述以发送和接收媒体。
  RTP / SAVPF在RFC5124中定义。简而言之，它需要使用SRTP和SRTCP和RTCP反馈数据包。
  媒体格式描述，具有协议RTP / SAVPF，给出将要用于不同格式的RTP有效载荷数。低于96的有效负载数由IANA映射到编码格式。在我们的SDP0地图到G711U和8到G711A。大于95的格式号是动态的，并且有一个= rtpmap：属性从RTP有效载荷类型编号映射到介质编码名称。还有alsoa = fmtp：attributes指定格式参数

c=IN IP4 217.130.243.155

• c是连接行。 此行给出您希望发送和接收实时流量的IP。 因为ICE在WebRTC中是强制性的，所以c线中的IP将不被使用。

ICE Candidates

重点来了

a=candidate:1467250027 1 udp 2122260223 192.168.0.196 46243 typ host generation 0
a=candidate:1467250027 2 udp 2122260222 192.168.0.196 56280 typ host generation 0

• UDP上的RTP的主机候选 - 在这个ICE线路中，浏览器给出它的主机候选 - 浏览器在计算机上侦听的接口的IP。浏览器可以在该IP上接收/发送SRTP和SRTCP，以防有远程对等体的一些候选者的IP可见性。例如，如果其他计算机在同一LAN上，将使用主机候选。udp后面的数字 - 2122260223 - 是候选者的优先级。注意，主机候选者的优先级高于其他候选者，因为使用主机候选者在资源使用方面更有效。第一行（component = 1）用于RTP，第二行（component = 2）用于RTCP

a=candidate:435653019 1 tcp 1845501695 192.168.0.196 0 typ host tcptype active generation 0
a=candidate:435653019 2 tcp 1845501695 192.168.0.196 0 typ host tcptype active generation 0

• RTP over TCP的主机候选 - 这些线路与之前的两个ICE线路相同，但只是TCP传输。 请注意，优先级是较低的 - 因为TCP不是实时媒体传输的最佳选择。
• RTCP over TCP的主机候选。

a=candidate:1853887674 1 udp 1518280447 47.61.61.61 36768 typ srflx raddr 192.168.0.196 rport 36768 generation 0
a=candidate:1853887674 2 udp 1518280447 47.61.61.61 36768 typ srflx raddr 192.168.0.196 rport 36768 generation 0

• 反射候选RTP over UDP - 这里我们有服务器反思候选人。 请注意，它们的优先级低于主机候选。
• 反射候选人RTCP over UDP - 这里我们有服务器反思候选人。 请注意，它们的优先级低于主机候选。

a=candidate:750991856 2 udp 25108222 237.30.30.30 51472 typ relay raddr 47.61.61.61 rport 54763 generation 0
a=candidate:750991856 1 udp 25108223 237.30.30.30 58779 typ relay raddr 47.61.61.61 rport 54761 generation 0

• RTP over UDP中继候选 - 接下来我们有中继候选。这些候选者从TURN服务器获得，当创建对等连接时，TURN服务器必须被提供。注意，这里的优先级低于主机和反射候选者（25108222更高），因此仅当主机和反射候选者之间没有IP连接时，才使用中继。

• RTCP over UDP的中继候选。

ICE Parameters

a=ice-ufrag:Oyef7uvBlwafI3hT
a=ice-pwd:T0teqPLNQQOf+5W+ls+P2p16

• 一旦ICE候选者被交换，验证过程开始，其中两个浏览器试图使用所提供的候选者连接。 在该过程中使用ice-ufrag和ice-pwd凭证，为了避免被攻击，未经验证的连接无法建立会话。

a=fingerprint:sha-256 49:66:12:17:0D:1C:91:AE:57:4C:C6:36:DD:D5:97:D2:7D:62:C9:9A:7F:B9:A3:F4:70:03:E7:43:91:73:23:5E

• 该指纹是在DTLS-SRTP协商中使用的证书的散列函数（在这种情况下使用sha-256）的结果。 此行在信令（假定是信任的）和在DTLS中使用的证书之间创建绑定，如果指纹不匹配，则应该拒绝会话。

a=sendrecv

• 这一行说，浏览器愿意在这个会话中发送和接收音频。 其他值可以是sendonly，recvonly和inactive，用于实现不同的场景，如将呼叫保持。

a=setup:actpass

a=setup 主要是表示dtls的协商过程中角色的问题，谁是客户端，谁是服务器

• a=setup:actpass 既可以是客户端，也可以是服务器
• a=setup:active 客户端
• a=setup:passive 服务器

a=rtpmap:96 VP8/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=rtpmap:97 rtx/90000
a=fmtp:97 apt=96

视频描述信息：payload type 96的是VP8， 支持goog-remb transport-cc fir nack pli，RTX payload type为97