SDP
一SDP介绍
1. SDP的核心功能
- 会话描述：定义会话的名称、创建者、时间范围、连接地址等全局信息。
- 媒体协商：明确媒体流的类型（如音频、视频）、传输协议（如RTP/UDP）、编码格式（如H.264、Opus）及端口信息。
- 网络参数：指定单播或多播地址、带宽限制、加密密钥等网络相关配置。
- 兼容性支持：通过文本格式的灵活扩展，适配不同传输协议（如SIP、RTSP、WebRTC）。
2. SDP的协议结构
SDP由会话级描述 和媒体级描述 两部分组成，采用<type>=<value>的文本格式，每行以单个字母表示类型，如v（版本）、m（媒体）等。
（1）会话级描述（Session-Level）
- 必选字段 ：
v=：协议版本（固定为v=0）。o=：会话创建者信息，格式为o=<用户名> <会话ID> <版本号> <网络类型> <地址类型> <地址>。s=：会话名称，若未命名则用-占位。t=：会话的起止时间（NTP时间戳）。
- 可选字段 ：
c=：连接信息（如c=IN IP4 192.168.1.1）。b=：带宽限制（如b=AS:500表示单媒体最大带宽500kbps）。a=：扩展属性（如加密方式a=crypto:1 AES_CM_128_HMAC_SHA1_80）。
（2）媒体级描述（Media-Level）
每个媒体流以m=行开头，描述具体参数：
- 必选字段 ：
m=：媒体类型（如audio/video）、端口、传输协议、负载类型列表（如m=audio 5004 RTP/AVP 96）。
- 关键属性 ：
a=rtpmap：动态负载类型与编码格式的映射（如a=rtpmap:96 H264/90000）。a=fmtp：编码参数的详细配置（如a=fmtp:96 profile-level-id=42801f）。a=sendrecv：媒体流方向（sendonly/recvonly/inactive）。
3. SDP在流媒体中的应用场景
-
实时通信（WebRTC）
在WebRTC中，SDP通过Offer/Answer模型交换双方的媒体能力（如支持的编解码器），并配合ICE协议完成网络穿透。
-
视频会议与直播
描述多路音视频流的传输参数，支持多播地址分配和分层编码（如H.264的分辨率适配）。
-
流媒体传输（RTSP）
RTSP协议通过SDP在
DESCRIBE响应中传递媒体信息（如文件格式、时间范围），客户端据此发起播放请求。 -
网络电话（VoIP）
协商音频编码格式（如G.711、Opus）和传输地址，确保通话双方兼容。
4. SDP的示例与解析
以下是一个简化的SDP示例：
plaintext
v=0
o=- 123456789 2 IN IP4 192.168.1.1
s=Example Session
c=IN IP4 192.168.1.1
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 OPUS/48000/2
a=sendrecv
m=video 5006 RTP/AVP 97
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01f- 会话级：定义版本、创建者IP和会话名称。
- 音频流：使用Opus编码，采样率48kHz，双向传输。
- 视频流：H.264编码，支持特定分辨率配置。
5. SDP的局限性
- 无协商能力：仅描述媒体信息，编码协商需依赖RTSP等协议。
- 静态配置：不支持动态调整参数（如带宽自适应），需结合其他协议实现。
二 会话管理 与SDP
1. RTSP（Real Time Streaming Protocol
(1) 是否需要建立会话？
- 需要显式会话 。
RTSP 是基于会话的协议，客户端与服务端通过SETUP、PLAY、TEARDOWN等命令明确控制会话生命周期。- 会话标识 ：通过
Session头字段维护会话状态（如Session: 12345678）。
- 会话标识 ：通过
(2) 是否需要 SDP？
-
需要 SDP 。
RTSP 使用 SDP（Session Description Protocol）在DESCRIBE响应中描述媒体流的详细信息：sdpm=video 0 RTP/AVP 96 a=rtpmap:96 H264/90000 a=control:track1- 作用：定义媒体类型（视频/音频）、编码格式、传输协议（RTP）、控制路径等。
2. RTMP（Real-Time Messaging Protocol）
(1) 是否需要建立会话？
- 通过隐式连接管理会话 。
RTMP 不显式声明会话，但通过以下机制维护逻辑会话：- NetConnection：客户端与服务端建立持久 TCP 连接（类似会话）。
- NetStream ：在连接内创建多个流通道（如
stream ID=1），每个流独立传输数据。
(2) 是否需要 SDP？
- 不需要 SDP 。
RTMP 通过以下方式传递媒体参数：-
元数据（onMetaData） ：客户端在发布流时发送元数据（分辨率、编码格式等）。
actionscript> onMetaData: { width: 1280, height: 720, videocodecid: 7 (H.264) } -
编码协商 ：客户端在
connect命令中声明支持的编解码能力（如videoCodecs: 128）。
-
3. HTTP流媒体（如HLS、DASH）
(1) 是否需要建立会话？
- 无显式会话 。
HTTP流媒体基于无状态的HTTP协议，通过请求-响应模式获取媒体分片：- HLS ：客户端通过HTTP GET请求获取
.m3u8索引文件和.ts分片。 - DASH ：客户端获取
.mpd清单文件并请求.m4s分片。
- HLS ：客户端通过HTTP GET请求获取
(2) 是否需要 SDP？
- 不需要 SDP 。
媒体参数通过以下方式描述：-
清单文件 ：如HLS的
.m3u8或DASH的.mpd，包含码率、分辨率、分片URL等信息。m3u8#EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360 stream_360p.ts
-
对比总结
| 协议 | 会话管理 | 媒体描述方式 | 典型场景 |
|---|---|---|---|
| RTSP | 显式会话（SETUP/PLAY） |
SDP（DESCRIBE响应） |
视频监控、IPTV |
| RTMP | 隐式会话（NetConnection） | 元数据（onMetaData） |
直播推流、低延迟交互 |
| HTTP流媒体 | 无会话（无状态HTTP） | 清单文件（m3u8/mpd） | 自适应流（HLS/DASH） |
关键区别解释
1. 会话管理
- RTSP：需要显式控制会话状态（如播放、暂停），适合需要精细控制的场景。
- RTMP：通过长连接维护隐式会话，适合持续流传输（如直播）。
- HTTP流媒体：无会话，每次请求独立，适合CDN分发和自适应码率。
2. 媒体参数传递
- RTSP：依赖SDP标准化描述，确保跨平台兼容性。
- RTMP：通过私有元数据和命令协商参数，灵活性高但标准化较弱。
- HTTP流媒体：通过清单文件静态描述，支持动态切换码率。
适用场景建议
- 低延迟控制：RTMP（1-3秒）或 RTSP（配合RTP）。
- 高兼容性分发：HTTP（HLS/DASH）。
- 设备控制：RTSP（如摄像头PTZ控制）。