webrtc sdp协议介绍

Session Description Protocol(会话描述协议)

RFC定义SDP的协议有两个:

RFC3264: An Offer/Answer Model with the session Description Protocol(SDP),用来概述一个请求/响应模型
RFC2327: SDP:Session Description Protocol,描述数据格式.

1.RFC2327

1.1.概述

SDP 完全是一种会话描述格式 ― 它不属于传输协议 ― 它只使用不同的适当的传输协议，包括会话通知协议（SAP）、会话初始协议（SIP）、实时流协议（RTSP）、MIME 扩展协议的电子邮件以及超文本传输协议（HTTP）。SDP协议是也是基于文本的协议，这样就能保证协议的可扩展性比较强，这样就使其具有广泛的应用范围。SDP 不支持会话内容或媒体编码的协商，所以在流媒体中只用来描述媒体信息。媒体协商这一块要用RTSP来实现．
SDP包括以下一些方面：

会话的名称和目的
会话存活时间
包含在会话中的媒体信息，包括：
- 媒体类型(video, audio, etc)
- 传输协议(RTP/UDP/IP, H.320, etc)
- 媒体格式(H.261 video, MPEG video, etc)
- 多播或远端（单播）地址和端口
为接收媒体而需的信息(addresses, ports, formats and so on)
使用的带宽信息
可信赖的接洽信息（Contact information）

1.2.SDP协议格式

SDP描述由许多文本行组成，文本行的格式为<类型>=<值>，<类型>是一个字母，<值>是结构化的文本串，其格式依<类型>而定。
＜type＞=<value>[CRLF]

1.2.1.fields分类

Seeesion Description
v(Protocol Version),mnd,The current protocol version.Always "0" using RFC4566
o(Origin),Mnd,The session originator's name and session identifiers.
s(Session Name), Mnd,The textural session Name
i(Session Information), opt,Textural information about the session
u(Uri),opt, A pointer to supplemental session Information
e(Email Address), opt, Email contract information for the person responsible.
P(phone Address),opt,Phone contract information for the person responsible
c(Connection Data),C,The connection type and Address
b(Bandwidth),opt,Proposed bandwidth limits.
z(Time Zones), opt, Accounts for daylight saving information
k(Encryption Keys),opt,A simple mechanism for exchanging keys, Rarely used.
Timing Description
t(Timing),mnd, start and end times.
r(Repeat Times),opt, Specified the duration and intervals for any session repeats.
Media Description
m(Media Description),mnd, Media definitions including media type(e.g."audio"),transport details and formats.
i(Session Information),opt
c(Connection Data),c
b(Bandwidth):opt
k( Encryption keys),opt
a(Attributes),opt

1.2.2.典型格式

Session description
   v=  (protocol version)
   o=  (owner/creator 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)

带"*"号的是可选的,其余的是必须的。一般顺序也按照上面的顺序来排列。

1.2.3.各type对应值的结构化文本串

v=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
其中：nettype是IN,代表internet,addrtype是IP4或IP6。unicast-address任务创建计算机的地址。
整个这个属性，是唯一表示一个任务。
e=123@126.com 或 p=+1 616 555-6011
对于一个任务只能两者之中的一个，表示会议控制者的联系方式。邮件地址可以是[email]j.doe@example.com[/email] (Jane Doe)形式，括号里面的是描述联系人的名称，或者Jane Doe <[email]j.doe@example.com[/email]>，前面的是联系人的名称。
c=<nettype> <addrtype> <connection-address>
这个连接数据，可以是传话级别的连接数据，或者是单独一个媒体数据的连接数据。在是多播时，connection-address就该是一个多播组地址，当是单播时，connection-address就该是一个单播地址。对于addrtype是IP4的情况下，connection-address不仅包含IP地址，并且还要包含a time to live value(TTL 0-255)，如：c=IN IP4 224.2.36.42/128，IP6没有这个TTL值。还允许象这样的<base multicast address>[/<ttl>]/<number of addresses>格式的connection-address。如：c=IN IP4 224.2.1.1/127/3等同于包含c=IN IP4 224.2.1.1/127, c=IN IP4 224.2.1.2/127, c=IN IP4 224.2.1.3/127三行内容。
b=<bwtype>:<bandwidth> bwtype可以是CT或AS，CT方式是设置整个会议的带宽，AS是设置单个会话的带宽。缺省带宽是千比特每秒。
t=<start-time> <stop-time>，这个可以有行，指定多个不规则时间段，如果是规则的时间段，则r=属性可以使用。start-time和stop- time都遵从NTP(Network Time Protocol),是以秒为单位，自从1900以来的时间。要转换为UNIX时间，减去2208988800。如果stop-time设置为0,则会话没有时间限制。如果start-time也设置为0，则会话被认为是永久的。
b=<bwtype>:<bandwidth> bwtype可以是CT或AS，CT方式是设置整个会议的带宽，AS是设置单个会话的带宽。缺省带宽是千比特每秒。
t=<start-time> <stop-time>，这个可以有行，指定多个不规则时间段，如果是规则的时间段，则r=属性可以使用。start-time和stop- time都遵从NTP(Network Time Protocol),是以秒为单位，自从1900以来的时间。要转换为UNIX时间，减去2208988800。如果stop-time设置为0,则会话没有时间限制。如果start-time也设置为0，则会话被认为是永久的。
r=<repeat-interval> <active duration> <offsets from start-time>重复次数在时间表示里面可以如下表示：
d - days (86400 seconds)
h - hours (3600 seconds)
m - minutes (60 seconds)
s - seconds (allowed for completeness)
z=<adjustment time> <offset> <adjustment time> <offset> ....
k=<method>
k=<method>:<encryption key>
a=<attribute>
a=<attribute>:<value>
m=<media> <port> <proto> <fmt> ...
m=<media> <port>/<number of ports> <proto> <fmt> ...
a=cat:<category>分类，根据分类接收者隔离相应的会话
a=keywds:<keywords>关键字，根据关键字隔离相应的会话
a=tool:<name and version of tool>创建任务描述的工具的名称及版本号
a=ptime:<packet time>在一个包里面的以毫秒为单位的媒体长度
a=maxptime:<maximum packet time>以毫秒为单位，能够压缩进一个包的媒体量。
a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding parameters>]
a=recvonly
a=sendrecv
a=sendonly
a=inactive，
a=orient:<orientation>其可能的值，"portrait", "landscape" and "seascape" 。
a=type:<conference type>,建议值是，"broadcast", "meeting", "moderated", "test" and "H332"。
a=charset:<character set>
a=sdplang:<language tag>指定会话或者是媒体级别使用的语言
a=framerate:<frame rate>设置最大视频帧速率
a=quality:<quality>值是0-10

a=fmtp:<format> <format specific parameters>
在SIP协议的包含的内容是SDP时，应该把Content-Type设置成application/sdp。

1.3.SDP协议例子

1.3.1.helix流媒体服务器的RTSP协议中的SDP协议:

v=0 //SDP version
// o field定义的源的一些信息。其格式为：o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
o=- 1271659412 1271659412 IN IP4 10.56.136.37 s=<No title>
i=<No author> <No copyright>  //session的信息
c=IN IP4 0.0.0.0 //connect 的信息，分别描述了：网络协议，地址的类型，连接地址。
c=IN IP4 0.0.0.0
t=0 0 //时间信息，分别表示开始的时间和结束的时间，一般在流媒体的直播的时移中见的比较多。
a=SdpplinVersion:1610641560 //描述性的信息
a=StreamCount:integer;2 //用来描述媒体流的信息，表示有两个媒体流。integer表示信息的格式为整数。
a=control:*
a=DefaultLicenseValue:integer;0 //License信息
a=FileType:string;"MPEG4" ////用来描述媒体流的信息说明当前协商的文件是mpeg4格式的文件
a=LicenseKey:string;"license.Summary.Datatypes.RealMPEG4.Enabled"
a=range:npt=0-72.080000  //用来表示媒体流的长度
m=audio 0 RTP/AVP 96 //做为媒体描述信息的重要组成部分描述了媒体信息的详细内容：表示session的audio是通过RTP来格式传送的，其payload值为96传送的端口还没有定。
b=as:24 //audio 的bitrate
b=RR:1800
b=RS:600
a=control:streamid=1  //通过媒体流1来发送音频
a=range:npt=0-72.080000 //说明媒体流的长度。
a=length:npt=72.080000
a=rtpmap:96 MPEG4-GENERIC/32000/2 //rtpmap的信息，表示音频为AAC的其sample为32000
a=fmtp:96 profile-level-id=15;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1210 //config为AAC的详细格式信息
a=mimetype:string;"audio/MPEG4-GENERIC"
a=Helix-Adaptation-Support:1
a=AvgBitRate:integer;48000
a=HasOutOfOrderTS:integer;1
a=MaxBitRate:integer;48000
a=Preroll:integer;1000
a=OpaqueData:buffer;"A4CAgCIAAAAEgICAFEAVABgAAAC7gAAAu4AFgICAAhKIBoCAgAEC"
a=StreamName:string;"Audio Track"
下面是video的信息基本和audio的信息相对称，这里就不再说了。
m=video 0 RTP/AVP 97
b=as:150
b=RR:11250
b=RS:3750
a=control:streamid=2
a=range:npt=0-72.080000
a=length:npt=72.080000
a=rtpmap:97 MP4V-ES/2500
a=fmtp:97 profile-level-id=1;
a=mimetype:string;"video/MP4V-ES"
a=Helix-Adaptation-Support:1
a=AvgBitRate:integer;300000
a=HasOutOfOrderTS:integer;1
a=Height:integer;240 //影片的长度
a=MaxBitRate:integer;300000
a=MaxPacketSize:integer;1400
a=Preroll:integer;1000
a=Width:integer;320  //影片的宽度
a=OpaqueData:buffer;"AzcAAB8ELyARAbd0AAST4AAEk+AFIAAAAbDzAAABtQ7gQMDPAAABAAAAASAAhED6KFAg8KIfBgEC"
a=StreamName:string;"Video Track"

1.3.2.Webrtc SDP示例

v=0
o=- 0 0 IN IP4 127.0.0.1
s=WX-RTC-SERVER
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS ryODEhTpFz
m=audio 1 UDP/TLS/RTP/SAVPF 0 126
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=candidate:1 1 udp 2013266431 192.168.0.68 42739 typ host generation 0
a=ice-ufrag:T+0c
a=ice-pwd:FzV1T/5PiBI78s630cwSb6
a=fingerprint:sha-256 2D:38:ED:09:73:36:F9:18:A6:CB:BC:ED:FB:C5:60:B3:F1:6C:FC:BD:97:57:AD:A6:38:11:9D:D4:8F:77:D6:C3
a=setup:active
a=recvonly
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=mid:audio
a=rtcp-mux
a=rtpmap:0 PCMU/8000
a=rtpmap:126 telephone-event/8000
m=video 1 UDP/TLS/RTP/SAVPF 124 125 96
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=candidate:1 1 udp 2013266431 192.168.0.68 42739 typ host generation 0
a=ice-ufrag:T+0c
a=ice-pwd:FzV1T/5PiBI78s630cwSb6
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:3gpp:video-orientation
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=fingerprint:sha-256 2D:38:ED:09:73:36:F9:18:A6:CB:BC:ED:FB:C5:60:B3:F1:6C:FC:BD:97:57:AD:A6:38:11:9D:D4:8F:77:D6:C3
a=setup:active
a=recvonly
a=mid:video
a=rtcp-mux
a=rtpmap:124 H264/90000
a=rtcp-fb:124 ccm fir
a=rtcp-fb:124 nack
a=rtcp-fb:124 nack pli
a=rtcp-fb:124 goog-remb
a=fmtp:124 x-google-max-bitrate=800;x-google-min-bitrate=150;x-google-start-bitrate=300
a=rtpmap:125 H264/90000
a=rtcp-fb:125 ccm fir
a=rtcp-fb:125 nack
a=rtcp-fb:125 nack pli
a=rtcp-fb:125 goog-remb
a=fmtp:125 x-google-max-bitrate=800;x-google-min-bitrate=150;x-google-start-bitrate=300
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 goog-remb

2.RFC3264

An Offer/Answer Model with the Session Description Protocol (SDP)

2.1情态动词

定义在RFC2119:

"MUST"，必须、一定要；
"MUST NOT"，禁止；
"REQUIRED"，需要；
"SHALL"、"SHOULD"，应该；
"SHALL NOT"、"SHOULD NOT"，不应该；
"RECOMMENDED"，推荐；
"MAY"，可以
2.2术语
媒体流（Media Stream），或称为媒体类型（Media Type），即我们通常所说的音频流、视频流等，所有通信实体要进行媒体交互之前都必须进行媒体注的协商
媒体格式（Media Format），每种媒体流都有不同的编码格式，像音频有G711、G712编码，视频有H261、H264等，像现在所谓的高清视频采用是720P、1070P等。
单一会话（Unitcast Session）
多会话（Multicast Sessions）
单一媒体流（Unitcast Streams）
多媒体流（Multicast Streams）
2.3offer/answer
rfc3264协议[1]主要概述一个请求/响应模型（offer/answer，以下叙述采用英文），包括请求/响应的实体和不同阶段的操作行为，如初始协商过程和重协商过程，并简单介绍消息中各种参数的含义。具体各个参数的详细说明见rfc2327协议[2]
![[8.Attachments/image/a5176ce3d80586e017f4de08f5e03140_MD5.png]]
2.3.1.实体,消息
Offer/Answer模型包括两个实体，一个是请求主体Offerer，另外一个是响应实体Answerer，两个实体只是在逻辑上进行区分，在一定条件可以转换。例如，手机A发起媒体协商请求，那么A就是Offerer，反之如果A为接收请求则为Offerer。
Offerer发给Answerer的请求消息称为请求offer，内容包括媒体流类型、各个媒体流使用的编码集，以及将要用于接收媒体流的IP和端口。
Answerer收到offer之后，回复给Offerer的消息称为响应，内容包括要使用的媒体编码，是否接收该媒体流以及告诉Offerer其用于接收媒体流的IP和端口。
2.3.2.SDP各个参数简单介绍
下面示例摘自3264协议[1]
v=0
o=carol 28908764872 28908764872 IN IP4 100.3.6.6 //会话ID号和版本
s=- //用于传递会话主题
t=0 0 //会话时间，一般由其它信令消息控制，因此填0
c=IN IP4 192.0.2.4 //描述本端将用于传输媒体流的IP
m=audio 0 RTP/AVP 0 1 3 //媒体类型端口号本端媒体使用的编码标识（Payload）集
a=rtpmap:0 PCMU/8000 //rtpmap映射表，各种编码详细描述参数，包括使用带宽（bandwidth）
a=rtpmap:1 1016/8000
a=rtpmap:3 GSM/8000
a=sendonly //说明本端媒体流的方向，取值包括sendonly/recvonly/sendrecv/inactive
a=ptime:20 //说明媒体流打包时长
m=video 0 RTP/AVP 31 34
a=rtpmap:31 H261/90000
a=rtpmap:34 H263/90000
2.3.3.实体行为、操作过程
2.3.3.1.初始协商的Offer请求
实体A <-> 实体B，实体首先发起Offer请求，内容如2节所示，对于作何一个媒体流/媒体通道，这时实体A必须：
如果媒体流方向标为recvonly/sendrecv，即a=recvonly或a=sendrecv，则A必须（MUST）准备好在这个IP和端口上接收实体B发来的媒体流；
如果媒体流方向标为sendonly/inactive，即a=recvonly或a=sendrecv，则A不需要进行准备。
2.3.3.1.Answer响应
实体B收到A的请求offer后，根据自身支持的媒体类型和编码策略，回复响应。
如果实体B回复的响应中的媒体流数量和顺序必须（MUST）和请求offer一致，以便实体A进行甄别和决策。即m行的数量和顺序必须一致，B不能（MUST NOT）擅自增加或删除媒体流。如果B不支持某个媒体流，可以在对应的端口置0，但不能不带这个m行描述。
对于某种媒体，实体B必须（MUST）从请求offer中选出A支持且自己也支持的该媒体的编码标识集，并且可以（MAY）附带自己支持的其它类型编码。
对于响应消息中各个媒体的方向：
- 如果请求某媒体流的方向为sendonly，那么响应中对应媒体的方向必须为recvonly；
- 如果请求某媒体流的方向为recvonly，那么响应中对应媒体的方向必须为sendonly；
- 如果请求某媒体流的方向为sendrecv，那么响应中对应媒体的方向可以为sendrecv/sendonly/recvonly/inactive中的一种；
- 如果请求某媒体流的方向为inactive，那么响应中对应媒体的方向必须为inactive；
响应answer里提供IP和端口，指示Offerer本端期望用于接收媒体流的IP和端口，一旦响应发出之后，Offerer必须（MUST）准备好在这个IP和端口上接收实体A发来的媒体流。
如果请求offer中带了ptime（媒体流打包间隔）的a行或带宽的a行，则响应answer也应该（SHOULD）相应的携带。
实体B Offerer应该（SHOULD）使用实体A比较期望的编码生成媒体流发送。一般来说对于m行，如m=video 0 RTP/AVP 31 34，排充越靠前的编码表示该实体越希望以这个编码作为载体，这里示例31(H261)，34（H263）中H261为A更期望使用的编码类型。同理，当实体A收到响应answer后也是这样理解的。
2.3.3.2.实体收到响应后的处理
当实体A收到B回复的响应后，可以（MAY）开始发送媒体流，如果媒体流方向为sendonly/sendrecv，
必须（MUST）使用answer列举的媒体类型/编码生成媒体发送；
应该（SHOULD）使用answer中的ptime和bandwidth来打包发送媒体流；
可以（MAY）立即停止监听端口，该端口为offer支持answer不支持的媒体所使用的端口。

2.3.4.修改媒体流（会话）

修改媒体流的offer-answer操作必须基于之前协商的媒体形式（音频、视频等），不能（MUST NOT）对已有媒体流进行删减。

2.3.4.1.删除媒体流

如果实体认定新的会话不支持之前媒商的某个媒体，新的offer只须对这种媒体所在m行的端口置0，但不能不描述这种媒体，即不带对应m行。当answerer收到响应之后，处理同初始协商一样。

2.3.4.2.增加媒体流

如果实体打算新增媒体流，在offer里只须加上描述即可或者占用之前端口被置0的媒体流，即用新的媒体描述m行替换旧的。当answerer收到offer请求后，发现有新增媒体描述，或者过于端口被置0的媒体行被新的媒体描述替换，即知道当前为新增媒体流，处理同初始协商。

2.3.4.3.修改媒体流

修改媒体注主要是针对初始协商结果，如果有变更即进入修改流程处理，可能的变更包括IP地址、端口，媒体格式（编码），媒体类型（音、视频），媒体属性（ptime，bandwidth，媒体流方向变更等）。

webrtc sdp协议介绍

Session Description Protocol(会话描述协议)

1.RFC2327

1.1.概述

1.2.SDP协议格式

1.2.1.fields分类

1.2.2.典型格式

1.2.3.各type对应值的结构化文本串

1.3.SDP协议例子

1.3.1.helix流媒体服务器的RTSP协议中的SDP协议:

1.3.2.Webrtc SDP示例

2.RFC3264

2.1情态动词

2.2术语

2.3offer/answer

2.3.1.实体,消息

2.3.2.SDP各个参数简单介绍

2.3.3.实体行为、操作过程

2.3.3.1.初始协商的Offer请求

2.3.3.1.Answer响应

2.3.3.2.实体收到响应后的处理

2.3.4.修改媒体流（会话）

2.3.4.1.删除媒体流

2.3.4.2.增加媒体流

2.3.4.3.修改媒体流

轻口味

引用和评论

多媒体技术简介

【翻译】第五章 - [Dan_Ristic]webrtc开发实践

【翻译】第四章 - [Dan_Ristic]webrtc开发实践

FFmpeg开发笔记（五十九）Linux编译ijkplayer的Android平台so库

短剧出海的技术密码：多语言智能翻译加速百亿市场

FFmpeg开发笔记（五十六）使用Media3的Exoplayer播放网络视频

FFmpeg开发笔记（四十八）从0开始搭建直播系统的开源软件架构