SDP协议分析

川长思鸟来 2022-10-06 12:52 437阅读 0赞

# SDP协议分析 #

--------------------

## 目录 ##

1.  SDP的结构
2.  SDP语法  
    1. 必需字段  
    2. 可选字段  
    3. 字段顺序  
    4. ⼦字段
3.  SDP例子

--------------------

### 1. SDP的结构 ###

1.  SDP（Session Description Protocol）完全是⼀种会话描述格式，它不属于传输协议，它只使⽤于适当的传输协议，包括会话通知协议（SAP）、会话初始协议（SIP）、实时流协议（RTSP）、MIME 扩展协议的电⼦邮件以及超⽂本传输协议（HTTP）。
2.  SDP协议是也是基于⽂本的协议，这样就能保证协议的可扩展性⽐较强，使其具有⼴泛的应⽤范围。
3.  SDP 不⽀持会话内容或媒体编码的协商，所以在流媒体中只⽤来描述媒体信息，媒体协商这⼀块要⽤RTSP来实现。

#### 1. SDP协议格式 ####

1.  SDP描述由许多⽂本⾏组成，⽂本⾏的格式为<类型>=<值>，<类型>是⼀个字⺟，<值>是结构化的⽂本串，其格式依<类型>⽽定。
2.  ＜type＞=<`value`>\[CRLF\]。SDP在4566 中有详细描述。
3.  SDP仅仅提供了描述从会话信息到可能的会话参与者的格式。
4.  ⼀个会话基本上有许多媒体流组成，因此，会话描述包含了许多与每个媒体流相关的参数说明，此外还包括与会话整体相关的通⽤信息。
5.  所以，SDP消息中既包含了会话级参数⼜包括了媒体级参数。
    
    1.  会话级参数包括如下信息，如会话名称、会话发起者以及会话活动时间。
    2.  媒体级参数包括媒体类型、端⼝号、传输协议以及媒体格式。
6.  下图描述了SDP消息的基本结构。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70]
7.  SDP仅仅提供了对会话的描述，没有提供将会话和可能的参与者联系起来的⽅法，所以必须把SDP与其他协议（如SIP协议）联系起来使⽤。SDP协议同SIP协议⼀样基于⽂本的协议，需要使⽤特定的编码集。字段名称只能使⽤US-ASCII字符集，⽂本信息可以使⽤任何语⾔。
8.  由于SDP的ASCII编码⽐⼆进制编码占⽤带宽多，所以SDP采⽤紧凑格式提⾼带宽利⽤率。如v=version，s=session name等等
9.  SDP采⽤多⽂本⾏传递会话信息，每⾏使⽤“字段名=字段值”的格式。字段名只⽤⼀个字符表示（⼤⼩写敏感），字段值可以有多个信息块组成，⽤分号隔开，“=”左右不能有空格

--------------------

### 2. SDP语法 ###

1.  会话级别字段必须放在前⾯，然后才是媒体级参数，会话数据与媒体数据之间的界限就是第⼀个媒体描述字段（m=）的出现，之后的每个媒体描述字段的出现标志着这个会话中⼜⼀个媒体流数据的开始。
2.  SDP字段包括必必需字段与可选字段

#### 1. 必需字段 ####

1.  v=（协议版本号），⼀个会话描述的开始，前⼀个会话结束标志。
2.  o=（会话源或者会话⽣成者，以及会话标识符）
3.  s=（会话名称）这个字段是个⽂本字符串，可以显示给会话参与者。
4.  t=（会话时间）这个字段指明会话开始时间与结束时间。
5.  m=（媒体）该字段⽤来指明媒体类型、数据应该发送到的传输端⼝，传输协议（例如RTP）以及媒体格式（例如RTP负载格式）

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70 1]

#### 2. 可选字段 ####

1.  SDP可选字段中，⼀些只能应⽤于会话级，⼀些只能应⽤于媒体级，还有⼀些可以应⽤于两种级别。
2.  对于应⽤于两种级别的字段，在某个具体媒体上，应⽤于媒体级的字段会覆盖应⽤于会话级的字段值。
    
    1.  例如，某个字段其会话级的字段值为X,媒体1的该字段值为Y，那么值X应⽤于会话中除媒体类型1之外的所有媒体，⽽媒体1应⽤值Y
3.  可选字段如下：
    
    1.  i=（会话信息）对字段的⽂本描述，提供了⽐会话名称更多的信息。该字段既可以⽤于会话级也可以⽤于媒体级。
    2.  u=（描述的URI地址）URI信息，通过这个地址可以获取更多会话相关信息。例如，⼀个会议可能公布在WEB⻚⾯上，所以需要该WEB的URI。每个会话只能提供⼀个URI
    3.  E=（E-mail地址）负责会话个体的E-mail地址，可以有多个。只能⽤于会话级别。
    4.  p=（电话号码）同email⼀样，多个，会话级别。
    5.  c=（连接信息）该字段提供连接数据，包括连接类型、⽹络类型和连接地址。可应⽤于会话级也可以⽤于媒体级。
    6.  b=（带宽信息）指明带宽需求，单位kbit/s, 可⽤于两个级别
    7.  r=（重复次数）如果是有规律的⽇程安排活动，这个字段⽤来指明会话重复频次和时间。
    8.  z=（时区调整）⽤于按⽇程安排的有规律活动会话。会话可能会夸时区，避免时区变更造成的混乱。
    9.  k=（加密密钥）为了对媒体加密、解密，该字段提供了⼀个加密密钥或者规定了⼀个获取密钥的机制。
4.  可⽤于两个级别。
    
    1.  a=（属性）⽤于描述会话或者某个媒体的额外属性
5.  可选字段中，连接信息字段是特别与条件相关的。因为该字段定义了数据应发送到的⽹络地址，所以必须被包含进会话描述中的某个地⽅。

#### 3. 字段顺序 ####

1.  因为有些字段既可以应⽤于会话级⼜可以⽤于媒体级，所以字段顺序对于避免含义模糊特别重要。SDP所要求的字段顺序如下：

会话级
    协议版本号（v）
    会话源（o）
    会话名称（s）
    会话信息（i）（可选）
    URI（u）（可选）
    E-mail地址（e）（可选）
    电话号码（p）（可选）
    连接信息（c）（可选）
    带宽信息（b）（可选）
    时间描述（t）
    重复信息（r）（可选）
    时区调整（z）（可选）
    加密密钥（k）（可选）
    属性（a）（可选）
    
    媒体级
    媒体描述（m）
    媒体信息（i）（可选）
    连接信息（c）（会话级进⾏了规定，这⾥可选）
    带宽信息（b）（可选）
    加密密钥（k）（可选）
    属性（a）（可选）

#### 4. ⼦字段 ####

1.  在SDP中许多字段采⽤多个⼦字段的形式，此时，这些字段值由多个以空格符间隔的多个值组成。格式如下：
2.  字段 名称=<⼦字段1的值> <⼦字段2的值> <⼦字段3的值>
3.  下⾯举例说明⽐较重要的字段

##### 1. 会话源（o） #####

1.  有6个⼦字段：⽤户名、会话ID、版本、⽹络类型、地址类型、地址。

##### 2. 连接信息 #####

1.  连接数据有3个⼦字段：⽹络类型、地址类型和连接地址。同会话源中含义不同，他们表示需要接收媒体数据的⽹络和地址，⽽不是⽣成会话的⽹络和地址。

##### 3. 媒体信息 #####

媒体信息（m）有四个⼦字段：媒体类型、端⼝、传输协议、格式。

##### 4. m描叙⾏ #####

格式： m=(媒体)（端⼝）（传送层）（格式列表）
    媒体类型：⾳频（audio）,视频(video),应⽤，数据和控制
    端⼝：媒体传送层端⼝
    传送层：ip4上⼤多基于rtp/udp上传送（RTP/AVP）IETF RTP协议，在udp上传输
    格式列表： 对应对应的⾳频负载类型（PT）
    m=video 0 RTP/AVP 96

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70 2]

1.  媒体类型可以是⾳频、视频、应⽤程序、数据或控制，如果是语⾳，媒体类型就是⾳频。
2.  端⼝指明媒体要发送到的端⼝号，端⼝号与所有的连接类型和传输协议有关。例如VoIP，媒体通常在UDP传输协议上采⽤RTP承载，这样端⼝号将是1024和65535之间的⼀个偶数值。相应奇数对应RTCP端⼝号。
3.  格式⼦字段列出了所⽀持的所有不同类型的媒体格式。优先使⽤靠前的格式。
4.  如某个系统准备在端⼝45678接收语⾳，并且只能处理G.711 u编码的语⾳，那么RTP负载类型为0，媒体信息如下：
    
    1.  m=audio 45678 RTP/AVP 0
5.  如果某个系统准备在端⼝45678可以处理⼏种编码的语⾳：G.728编码格式（负载类型为15）、GSM编码格式（负载类型为3）、G.711 u编码格式（负载类型为0），⽽且系统优先采⽤G.728格式，则相应的媒体信息如下所示：
    
    1.  m=audio 45678 RTP/AVP 15 3 0

##### 5. 属性（a） #####

1.  属性可以描述额外信息，可应⽤于会话级，也可⽤于媒体级或者两者兼有
2.  a描叙⾏（⼤部分情况是必须）：

格式：a=rtpmap:（净荷类型）（编码名）/（时钟速率）【/(编码参数)】
    a=control:（⾳/视频连接信息）
    a=control:rtsp://192.168.1.197/h264stream0/trackID=0
    a=rtpmap:96 H264/90000

1.  属性有两种形式，第⼀种是特征属性，第⼆种属于值属性。SDP描述了多个建议属性。
    
    1.  例如a=sendonly: 表明会话描述的发送者只希望发送数据⽽不打算接收数据，端⼝号⽆意义，可以置为0。
    2.  例如a=recvonly: 表明这个会话描述的发送者只想接收数据⽽不打算发送数据。

--------------------

### 3. SDP例子 ###

v=0
    //sdp版本号，一直为0,rfc4566规定
    o=- 7017624586836067756 2 IN IP4 127.0.0.1
    // o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
    //username如何没有使用-代替，7017624586836067756是整个会话的编号，2代表会话版本，如果在会话
    //过程中有改变编码之类的操作，重新生成sdp时,sess-id不变，sess-version加1
    s=-
    //会话名，没有的话使用-代替
    t=0 0
    //两个值分别是会话的起始时间和结束时间，这里都是0代表没有限制
    a=group:BUNDLE audio video data
    //需要共用一个传输通道传输的媒体，如果没有这一行，音视频，数据就会分别单独用一个udp端口来发送
    a=msid-semantic: WMS h1aZ20mbQB0GSsq0YxLfJmiYWE9CBfGch97C
    //WMS是WebRTC Media Stream简称，这一行定义了本客户端支持同时传输多个流，一个流可以包括多个track,
    //一般定义了这个，后面a=ssrc这一行就会有msid,mslabel等属性
    m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
    //m=audio说明本会话包含音频，9代表音频使用端口9来传输，但是在webrtc中一现在一般不使用，如果设置为0，代表不
    //传输音频,UDP/TLS/RTP/SAVPF是表示用户来传输音频支持的协议，udp，tls,rtp代表使用udp来传输rtp包，并使用tls加密
    //SAVPF代表使用srtcp的反馈机制来控制通信过程,后台111 103 104 9 0 8 106 105 13 126表示本会话音频支持的编码，后台几行会有详细补充说明
    c=IN IP4 0.0.0.0
    //这一行表示你要用来接收或者发送音频使用的IP地址，webrtc使用ice传输，不使用这个地址
    a=rtcp:9 IN IP4 0.0.0.0
    //用来传输rtcp地地址和端口，webrtc中不使用
    a=ice-ufrag:khLS
    a=ice-pwd:cxLzteJaJBou3DspNaPsJhlQ
    //以上两行是ice协商过程中的安全验证信息
    a=fingerprint:sha-256 FA:14:42:3B:C7:97:1B:E8:AE:0C2:71:03:05:05:16:8F:B9:C7:98:E9:60:43:4B:5B:2C:28:EE:5C:8F3:17
    //以上这行是dtls协商过程中需要的认证信息
    a=setup:actpass
    //以上这行代表本客户端在dtls协商过程中，可以做客户端也可以做服务端，参考rfc4145 rfc4572
    a=mid:audio
    //在前面BUNDLE这一行中用到的媒体标识
    a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
    //上一行指出我要在rtp头部中加入音量信息，参考 rfc6464
    a=sendrecv
    //上一行指出我是双向通信，另外几种类型是recvonly,sendonly,inactive
    a=rtcp-mux
    //上一行指出rtp,rtcp包使用同一个端口来传输
    //下面几行都是对m=audio这一行的媒体编码补充说明，指出了编码采用的编号，采样率，声道等
    a=rtpmap:111 opus/48000/2
    a=rtcp-fb:111 transport-cc
    //以上这行说明opus编码支持使用rtcp来控制拥塞，参考https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-01
    a=fmtp:111 minptime=10;useinbandfec=1
    //对opus编码可选的补充说明,minptime代表最小打包时长是10ms，useinbandfec=1代表使用opus编码内置fec特性
    a=rtpmap:103 ISAC/16000
    a=rtpmap:104 ISAC/32000
    a=rtpmap:9 G722/8000
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=rtpmap:106 CN/32000
    a=rtpmap:105 CN/16000
    a=rtpmap:13 CN/8000
    a=rtpmap:126 telephone-event/8000
    a=ssrc:18509423 cname:sTjtznXLCNH7nbRw
    //cname用来标识一个数据源，ssrc当发生冲突时可能会发生变化，但是cname不会发生变化，也会出现在rtcp包中SDEC中，
    //用于音视频同步
    a=ssrc:18509423 msid:h1aZ20mbQB0GSsq0YxLfJmiYWE9CBfGch97C 15598a91-caf9-4fff-a28f-3082310b2b7a
    //以上这一行定义了ssrc和WebRTC中的MediaStream,AudioTrack之间的关系，msid后面第一个属性是stream-d,第二个是track-id
    a=ssrc:18509423 mslabel:h1aZ20mbQB0GSsq0YxLfJmiYWE9CBfGch97C
    a=ssrc:18509423 label:15598a91-caf9-4fff-a28f-3082310b2b7a
    m=video 9 UDP/TLS/RTP/SAVPF 100 101 107 116 117 96 97 99 98
    //参考上面m=audio,含义类似
    c=IN IP4 0.0.0.0
    a=rtcp:9 IN IP4 0.0.0.0
    a=ice-ufrag:khLS
    a=ice-pwd:cxLzteJaJBou3DspNaPsJhlQ
    a=fingerprint:sha-256 FA:14:42:3B:C7:97:1B:E8:AE:0C2:71:03:05:05:16:8F:B9:C7:98:E9:60:43:4B:5B:2C:28:EE:5C:8F3:17
    a=setup:actpass
    a=mid:video
    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:5 http://www.ietf.org/id/draft-hol ... de-cc-extensions-01
    a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
    a=sendrecv
    a=rtcp-mux
    a=rtcp-rsize
    a=rtpmap:100 VP8/90000
    a=rtcp-fb:100 ccm fir
    //ccm是codec control using RTCP feedback message简称，意思是支持使用rtcp反馈机制来实现编码控制，fir是Full Intra Request
    //简称，意思是接收方通知发送方发送幅完全帧过来
    a=rtcp-fb:100 nack
    //支持丢包重传，参考rfc4585
    a=rtcp-fb:100 nack pli
    //支持关键帧丢包重传,参考rfc4585
    a=rtcp-fb:100 goog-remb
    //支持使用rtcp包来控制发送方的码流
    a=rtcp-fb:100 transport-cc
    //参考上面opus
    a=rtpmap:101 VP9/90000
    a=rtcp-fb:101 ccm fir
    a=rtcp-fb:101 nack
    a=rtcp-fb:101 nack pli
    a=rtcp-fb:101 goog-remb
    a=rtcp-fb:101 transport-cc
    a=rtpmap:107 H264/90000
    a=rtcp-fb:107 ccm fir
    a=rtcp-fb:107 nack
    a=rtcp-fb:107 nack pli
    a=rtcp-fb:107 goog-remb
    a=rtcp-fb:107 transport-cc
    a=fmtp:107 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
    //h264编码可选的附加说明
    a=rtpmap:116 red/90000
    //fec冗余编码，一般如果sdp中有这一行的话，rtp头部负载类型就是116，否则就是各编码原生负责类型
    a=rtpmap:117 ulpfec/90000
    //支持ULP FEC，参考rfc5109
    a=rtpmap:96 rtx/90000
    a=fmtp:96 apt=100
    //以上两行是VP8编码的重传包rtp类型
    a=rtpmap:97 rtx/90000
    a=fmtp:97 apt=101
    a=rtpmap:99 rtx/90000
    a=fmtp:99 apt=107
    a=rtpmap:98 rtx/90000
    a=fmtp:98 apt=116
    a=ssrc-group:FID 3463951252 1461041037
    //在webrtc中，重传包和正常包ssrc是不同的，上一行中前一个是正常rtp包的ssrc,后一个是重传包的ssrc
    a=ssrc:3463951252 cname:sTjtznXLCNH7nbRw
    a=ssrc:3463951252 msid:h1aZ20mbQB0GSsq0YxLfJmiYWE9CBfGch97C ead4b4e9-b650-4ed5-86f8-6f5f5806346d
    a=ssrc:3463951252 mslabel:h1aZ20mbQB0GSsq0YxLfJmiYWE9CBfGch97C
    a=ssrc:3463951252 label:ead4b4e9-b650-4ed5-86f8-6f5f5806346d
    a=ssrc:1461041037 cname:sTjtznXLCNH7nbRw
    a=ssrc:1461041037 msid:h1aZ20mbQB0GSsq0YxLfJmiYWE9CBfGch97C ead4b4e9-b650-4ed5-86f8-6f5f5806346d
    a=ssrc:1461041037 mslabel:h1aZ20mbQB0GSsq0YxLfJmiYWE9CBfGch97C
    a=ssrc:1461041037 label:ead4b4e9-b650-4ed5-86f8-6f5f5806346d
    m=application 9 DTLS/SCTP 5000
    c=IN IP4 0.0.0.0
    a=ice-ufrag:khLS
    a=ice-pwd:cxLzteJaJBou3DspNaPsJhlQ
    a=fingerprint:sha-256 FA:14:42:3B:C7:97:1B:E8:AE:0C2:71:03:05:05:16:8F:B9:C7:98:E9:60:43:4B:5B:2C:28:EE:5C:8F3:17
    a=setup:actpass
    a=mid:data
    a=sctpmap:5000 webrtc-datachannel 1024

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70]: /images/20221005/6c8ad216cbac4ffd88abc45df7229ee7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70 1]: /images/20221005/be0e980fbad5422b91f3a7d57b1fb508.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkxMDY5NA_size_16_color_FFFFFF_t_70 2]: /images/20221005/4702574cd5164434a4c9e2099c1dbde5.png