旅游景点网站建设在线搜索资源

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在流媒体中的应用场景

1. 实时通信（WebRTC）
   在WebRTC中，SDP通过Offer/Answer模型交换双方的媒体能力（如支持的编解码器），并配合ICE协议完成网络穿透。

2. 视频会议与直播
   描述多路音视频流的传输参数，支持多播地址分配和分层编码（如H.264的分辨率适配）。

3. 流媒体传输（RTSP）
   RTSP协议通过SDP在DESCRIBE响应中传递媒体信息（如文件格式、时间范围），客户端据此发起播放请求。

4. 网络电话（VoIP）
   协商音频编码格式（如G.711、Opus）和传输地址，确保通话双方兼容。

---

4. SDP的示例与解析

以下是一个简化的SDP示例：

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 响应中描述媒体流的详细信息：

  m=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）：客户端在发布流时发送元数据（分辨率、编码格式等）。

    > 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 分片。

(2) 是否需要 SDP？

• 不需要 SDP。
  媒体参数通过以下方式描述：
  • 清单文件：如HLS的 .m3u8 或DASH的 .mpd，包含码率、分辨率、分片URL等信息。

    #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控制）。