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

你可能感兴趣的:(webrtc中SDP解释)