概述
因为设备端只支持H264编码方式接入,这里涉及到webrtc web端要修改默认编码器,而编码器就离不开webrtc 信令中SDP 消息的解读,读懂了 才能知道自己支持编码器的情况下对SDP的信息进行二次修改。
本文主要内容来自该说明文档:https://tools.ietf.org/html/draft-nandakumar-rtcweb-sdp-08
主要涉及到 RFC4566 RFC5888 RFC5761 RFC5245标准文档
文章目录
- 1 简介
- 2 SDP组成结构
- 3 参数通读
- 3 媒体流信息解读及标准文档位置
1 简介
SDP纯粹是会话描述的格式,它不包含传输协议。
WebRTC 会话就是由 SDP 描述的。对于 WebRTC 来说,最重要的是 SDP 中的媒体信息。
媒体类型(视频,音频)
- 传输协议(RTP/UDP/IP,H.320等)
- 媒体格式(H.261视频,MPEG视频等)
如果一上来看到SDP的内容肯定是一脸懵逼的,内容非常多.
典型的基于web的实时多媒体通信会话的特征如下
- 它具有零个或多个仅音频,仅视频或音频/视频RTP会话,可包含零个或多个非媒体数据会话
- 所有会话使用DTLS-SRTP保护
- 使用ICE机制支持NAT遍历
- 提供基于RTCP的反馈机制
- 会话可以是仅基于IPv4,仅基于IPv6,基于双栈的客户端
所以SDP中就为为了解决以上问题,携带实现该方案的组成格式协议。
2 SDP组成结构
借用标准文档中 SDP的构成如下:
+---------------------+
| v= |
+---------------------+
+---------------------+ +---------------------+
==== | Session Metadata | ===== | o= |
| +---------------------+ +----------------------
| +---------------------+
| | t= |
| +---------------------+
|
|
| +---------------------+
| | c= |
| +---------------------+
| +---------------------+
==== | Network Description | =====
| +---------------------+
| +---------------------+
| | a=candidate |
| +---------------------+
|
|
| +---------------------+
| | m= |
| +---------------------+
| +---------------------+ +---------------------+
==== | Stream Description | ===== | a=rtpmap |
| +---------------------+ +----------------------
| +---------------------+
| | a=fmtp |
| +---------------------+
| +---------------------+
| | a=sendrecv.. |
| +---------------------+
+---------------+
| SEMANTIC |
| COMPONENTS OF |
| SDP |
+---------------+
| +---------------------+
| | a=crypto |
| +---------------------+
| +---------------------+ +---------------------+
==== |Security Descriptions| =====| a=ice-frag |
| +---------------------+ +----------------------
| +---------------------+
| | a=ice-pwd |
| +---------------------+
| +---------------------+
| | a=fingerprint |
| +---------------------+
|
|
|
| +---------------------+
| | a=rtcp-fb |
| +---------------------+
| +---------------------+ +---------------------+
==== | Qos,Grouping | | |
| Descriptions | =====| a=group |
+---------------------+ +----------------------
+---------------------+
| a=rtcpmux |
+---------------------+
从上面的组成可以看出来SDP的信息由 五个部分存在:
- Session Metadata
- Network Description
- Stream Description
- Security Descriptions
- Qos,Grouping Descriptions
3 参数通读
这里先给出一份, RTCPeerConnection.createOffer 产生的SDP 并进行解读(rfc4566)
//---------------------- Session Metadata -------------------//
// v = 0 “v =”字段给出SDP的版本,默认为0。
v=0
// o = <username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
// <username> 是用户在始发主机上的登录名
// <sess-id> <sess-id>是一个数字字符串,使得<username><sess-id>nettype><addrtype>和<unicast-address>的元组形成会话的全局唯一标识符。
// <sess-version>是此会话描述的版本号
// <nettype>是一个给出网络类型的文本字符串。 “IN”被定义为具有“Internet”的含义
// <addrtype>是一个文本字符串,给出了后面的地址类型 定义了“IP4”和“IP6”
// <unicast-address>是创建会话的计算机的地址。
o=mozilla...THIS_IS_SDPARTA-67.0.4 7082731800936198286 0 IN IP4 0.0.0.0
// s = <会话名称> “s =”字段是文本会话名称.每个会话描述必须有一个且只有一个“s =”字段。“s =”字段不能为空
s=-
//t =<start-time> <stop-time>“t =”行指定会话的开始和停止时间。如果<stop-time>设置为零,则会话不受限制,但在<start-time>之后才会生效。如果<start-time>也为零,则会话被视为永久会话。
t=0 0
//********************* Session Metadata ********************//
//---------------------- Security Descriptions-------------------//
//a = <attribute>:<value>
//a = <fingerprint> SRIP 所需的DTLS指纹信息
a=fingerprint:sha-256 16:9A:59:1B:25:91:DD:C3:4D:B6:22:AB:36:0E:74:1A:F0:C1:62:0B:7F:7D:D3:08:93:13:83:B0:A9:4D:94:E7
//Negotiating Media Multiplexing Using the Session Description Protocol
//表示需要共用一个传输通道传输的媒体,通过ssrc进行区分不同的流。如果没有这一行,音视频数据就会分别用单独udp端口来发送.
a=group:BUNDLE 0 1 2
//Trickle ICE:Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol
//ICE建立候选时 采用增量设置的方式
a=ice-options:trickle
//WebRTC MediaStream Identification in the Session Description Protocol
//标识SDP中包含MediaStream的标识
a=msid-semantic:WMS *
//********************* Security Descriptions ********************//
//---------------------- Stream Description -------------------//
// m=<media> <port> <proto> <fmt> ...
//<media>是媒体类型 当前定义的媒体 "audio","video", "text", "application", and "message"
//<port>是传输媒体流的传输端口。在相关的“c =”字段中指定,以及在媒体字段的<proto>子字段中定义的传输协议。
//<proto>是传输协议。传输协议的含义取决于相关“c =”字段中的地址类型字段。
//<fmt>是媒体格式描述(编码类型)。第四个和任何后续 如果<proto>子字段是“RTP / AVP”或“RTP / SAVP”,则<fmt> 子字段包含RTP有效载荷类型号。
m=audio 9 UDP/TLS/RTP/SAVPF 109 9 0 8 101
// c=<nettype> <addrtype> <connection-address>
// 会话描述必须包含 每个媒体描述中的至少一个“c =”字段或会话级别的单个“c =”字段
// <nettype> “IN”被定义为具有“Internet”的含义
// <addrtype> 为IP4和IP6时
c=IN IP4 0.0.0.0
//a = sendrecv 这指定应以发送和接收模式启动工具。对于具有默认为仅接收模式的工具的交互式会议,这是必需的。
a=sendrecv
// The URI for declaring this header extension in an extmap attribute is "urn:ietf:params:rtp-hdrext:ssrc-audio-level".
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
//a=fmtp:<format> <format specific parameters> 用于传递特殊参数
// 此属性允许以SDP不必理解的方式传达特定于特定格式的参数。格式必须是为媒体指定的格式之一。格式特定参数可以是SDP要求传达的任何参数集,
a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=fmtp:101 0-15
//---------------------- Security Descriptions-------------------//
a=ice-pwd:141cd92cd90d3f5c446004c3404b13c7
a=ice-ufrag:33748035
a=mid:0
a=msid:{15d330d9-3078-4727-b51e-cdc8a2554dd1} {435405e5-84b9-49bb-85a3-9d06b16970f7}
//********************* Security Descriptions ********************//
//"a = rtcp-mux"属性以指示需要RTP和RTCP多路复用
a=rtcp-mux
//rtpmap:<payload type> <encoding name> / <clock rate> [/ <encoding parameters>]
//<payload type> 此属性从RTP有效内容类型编号(在 “m =”行中使用)映射到表示要使用的有效载荷格式,编码类型 采样率 编码参数
a=rtpmap:109 opus/48000/2
a=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000/1
//DTLS 握手方式 "active" / "passive" / "actpass"/ "holdconn" 'actpass': 连接或启动传出连接。
a=setup:actpass
//同步源(SSRC)标识符识别SDP,将属性与这些来源相关联
//新的SDP媒体级属性“ssrc”,用于标识特定的属性RTP会话中的同步源并充当元数据属性将源级属性信息映射到这些源
a=ssrc:2040182694 cname:{eee1aa1e-411a-47d5-98ad-b26dc639bc67}
m=video 9 UDP/TLS/RTP/SAVPF 120 121 126 97
c=IN IP4 0.0.0.0
a=sendrecv
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:5 urn:ietf:params:rtp-hdrext:toffset
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
a=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:121 max-fs=12288;max-fr=60
//---------------------- Security Descriptions-------------------//
a=ice-pwd:141cd92cd90d3f5c446004c3404b13c7
a=ice-ufrag:33748035
a=mid:1
a=msid:{15d330d9-3078-4727-b51e-cdc8a2554dd1} {47004068-3cac-4ee8-87df-2cdf02ae0921}
//---------------------- Security Descriptions-------------------//
//a = rtcp-fb: RTCP-FB-PT SP RTCP-FB-VAL CRLF
//rtcp-fb-pt是有效负载类型
///rtcp-fb-val定义反馈消息的类型 ack,nack,trr-int和rtcp-fb-id
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 goog-remb
a=rtcp-fb:121 nack
a=rtcp-fb:121 nack pli
a=rtcp-fb:121 ccm fir
a=rtcp-fb:121 goog-remb
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 ccm fir
a=rtcp-fb:126 goog-remb
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 goog-remb
a=rtcp-mux
//rtpmap:<payload type> <encoding name> / <clock rate> [/ <encoding parameters>]
//<payload type> 此属性从RTP有效内容类型编号(在 “m =”行中使用)映射到表示要使用的有效载荷格式,编码类型 采样率 编码参数
//而以下格式的编码的格式要去相应编码格式标准文档中查看 比如H264 就是RFC3984 https://tools.ietf.org/html/rfc3984
a=rtpmap:120 VP8/90000
a=rtpmap:121 VP9/90000
a=rtpmap:126 H264/90000
a=rtpmap:97 H264/90000
a=setup:actpass
a=ssrc:1381656291 cname:{eee1aa1e-411a-47d5-98ad-b26dc639bc67}
//********************* Stream Description ********************//
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=sendrecv
a=ice-pwd:141cd92cd90d3f5c446004c3404b13c7
a=ice-ufrag:33748035
a=mid:2
a=setup:actpass
a=sctp-port:5000
a=max-message-size:1073741823
3 媒体流信息解读及标准文档位置
以下就为截取关于video部分的 SDP 信息。我们下面以120 编码描述符进行举例
m=video 9 UDP/TLS/RTP/SAVPF 120 121 126 97
c=IN IP4 0.0.0.0
a=sendrecv
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:5 urn:ietf:params:rtp-hdrext:toffset
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
a=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:121 max-fs=12288;max-fr=60
a=ice-pwd:141cd92cd90d3f5c446004c3404b13c7
a=ice-ufrag:33748035
a=mid:1
a=msid:{15d330d9-3078-4727-b51e-cdc8a2554dd1} {47004068-3cac-4ee8-87df-2cdf02ae0921}
//a = rtcp-fb: RTCP-FB-PT SP RTCP-FB-VAL CRLF
//rtcp-fb-pt是有效负载类型
///rtcp-fb-val定义反馈消息的类型 ack,nack,trr-int和rtcp-fb-id
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 goog-remb
a=rtcp-fb:121 nack
a=rtcp-fb:121 nack pli
a=rtcp-fb:121 ccm fir
a=rtcp-fb:121 goog-remb
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 ccm fir
a=rtcp-fb:126 goog-remb
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 goog-remb
a=rtcp-mux
//rtpmap:<payload type> <encoding name> / <clock rate> [/ <encoding parameters>]
//<payload type> 此属性从RTP有效内容类型编号(在 “m =”行中使用)映射到表示要使用的有效载荷格式,编码类型 采样率 编码参数
//而以下格式的编码的格式要去相应编码格式标准文档中查看 比如H264 就是RFC3984 https://tools.ietf.org/html/rfc3984
a=rtpmap:120 VP8/90000
a=rtpmap:121 VP9/90000
a=rtpmap:126 H264/90000
a=rtpmap:97 H264/90000
a=setup:actpass
a=ssrc:1381656291 cname:{eee1aa1e-411a-47d5-98ad-b26dc639bc67}
我们以97编码格式举例,可以看到97对应编码格式为H264
97 对应的协议rfc3984(H.264视频的RTP有效载荷格式) https://tools.ietf.org/html/rfc3984
// m=<media> <port> <proto> <fmt> ...
//<media>是媒体类型 当前定义的媒体 "audio","video", "text", "application", and "message"
//<port>是传输媒体流的传输端口。在相关的“c =”字段中指定,以及在媒体字段的<proto>子字段中定义的传输协议。
//<proto>是传输协议。传输协议的含义取决于相关“c =”字段中的地址类型字段。
//<fmt>是媒体格式描述(编码类型)。第四个和任何后续 如果<proto>子字段是“RTP / AVP”或“RTP / SAVP”,则<fmt> 子字段包含RTP有效载荷类型号。
m=video 9 UDP/TLS/RTP/SAVPF 120 121 126 97
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 goog-remb
a=rtpmap:97 H264/90000
m=video: 描述当前支持媒体类型
a=fmtp: 提供了相应编码格式所需要的拓展信息
a=rtcp-fb:rtcp-fb-val定义反馈消息的类型
a=rtpmap:而97则根据协议规定了 SDP的a = rtpmap行中的编码名称必须是H264MIME子类型。a = rtpmap行中的时钟速率必须为90000。
最后
以上就是幸福发卡为你收集整理的Webrtc SDP格式解读1 简介2 SDP组成结构3 参数通读3 媒体流信息解读及标准文档位置的全部内容,希望文章能够帮你解决Webrtc SDP格式解读1 简介2 SDP组成结构3 参数通读3 媒体流信息解读及标准文档位置所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复