3. SDP 定义

3.1. Profile 定义

RFC 3551 [2], RFC 4585 [3] 和 RFC 3711 [4] 中定义的 AV profiles, 在例如 Session Description Protocol (SDP) [3] 的上下文中分别称为 "AVP", "AVPF" 和 "SAVP". 本文档规定的组合 profile 称为 "SAVPF".

3.2. 属性定义

用于协商 SAVP sessions 的 SDP attributes 在 RFC 4567 [7] 和 RFC 4568 [8] 中定义. 这些 attributes 也可以与 SAVPF 一起使用. [7] 和 [8] 中定义的规则适用.

用于协商 AVPF sessions 的 SDP attributes 在 RFC 4585 [3] 中定义. 这些 attributes 也可以与 SAVPF 一起使用. [3] 中定义的规则适用.

3.3. Profile 协商

RTP sessions 的 session descriptions 可以通过专用于多媒体通信的协议传递, 例如与 Session Initiation Protocol (SIP) [15] 一起使用的 SDP offer/answer model (RFC 3264, [9]), Real Time Streaming Protocol (RTSP) [10], 或 Session Announcement Protocol (SAP) [11]; 也可以通过电子邮件, NetNews, Web 页面等方式分发.

offer/answer model 允许使用 RFC 4567 [7] 和 RFC 4568 [8] 中定义的 SDP attributes 来协商最终的 session parameters. 以下小节从 offer/answer model 的角度描述协商过程.

随后讨论不使用 offer/answer model 的情况: 如第 3.3.2 节所述, RTSP 专用的协商支持由 RFC 4567 [7] 提供; 第 3.3.3 节讨论对 SAP announcements (完全没有协商) 的支持.

3.3.1. 基于 Offer/Answer 的 Session Descriptions 协商

协商 (例如 RTP profiles, codecs, transport addresses 等的协商) 按 media session 逐一执行 (例如 SDP 中每条 m= line). 如果某个 media session 的协商失败, 其他 media sessions 仍可以成功.

不同 media sessions 可以使用不同 RTP profiles. 对于一个 media description 的协商, AVP, AVPF, SAVP 和 SAVPF 这四个 profiles 彼此互斥. 但需要注意, SAVP 和 SAVPF 实体可以混合在单个 RTP session 中 (见第 4 节). 此外, offer/answer 机制可以用于为同一 media session 提供多个替代项, 并允许 answerer 从中选择一个 profile.

如果用于提供替代 security profiles 的机制可用 (目前正在开发中 [14]), 那么对于某个 media session 能够支持多个这类 profiles 的 offerer, 应该始终提供在特定情形下可接受的所有替代项. 这些替代项应该按偏好顺序列出, 且 offerer 应该优先选择安全 profiles 而非非安全 profiles. 同一 offer 不应该同时包含安全替代项 (SAVP 和 SAVPF) 与不安全替代项 (例如 AVP 和 AVPF), 因为这可能导致 bidding down 和其他攻击. 因此, 如果同时提供安全和非安全 RTP profiles (例如用于 best-effort SRTP [14]), 协商信令必须受到适当保护以避免此类攻击.

如果 offer 包含多个替代 profiles, answerer 应该优先选择安全 profile (如果支持), 而不是非安全 profile. 在安全或非安全 profiles 的集合内部, answerer 应该选择第一个可接受的替代项, 以尊重 offerer 的偏好.

如果 offer 中的 media description 使用 SAVPF, 而 answerer 不支持 SAVPF, 则必须拒绝该 media session.

如果 offer 中的 media description 未使用 SAVPF, 但 answerer 希望使用 SAVPF, 则 answerer 必须拒绝该 media session. answerer 可以在随后发起的 offer/answer 交换中提供 counter-offer, 其中的 media description 指明 SAVPF.

3.3.2. 基于 RTSP 的 Session Descriptions 协商

RTSP [10] 不支持 offer/answer model. 但是, RTSP 支持通过 Transport header 交换 media session parameters (包括 profile 和 address information). RFC 4567 [7] 中定义的基于 SDP 的密钥管理增加了一个 RTSP header (KeyMgmt), 用于支持传递密钥管理协议 (包括 keying material).

RTSP Transport header 可以用于确定 media session 的 profile. 从概念上讲, 第 3.3.1 节中定义的规则相应适用. 具体操作如下: SDP description (例如通过 DESCRIBE 从 RTSP server 获取) 包含特定 RTSP resource 的 media streams 描述.

RTSP client 必须为其希望接收的每个 media stream 精确选择一个 profile. 它必须在 SETUP request 中完成此操作. RTSP client 必须在 SETUP request 所含的 Transport header 中指明 profile 和完整 server transport address (IP 地址和端口号), 以表示所选择的 RTP profile. RTSP server 对 client SETUP message 的响应必须确认此 profile 选择, 或拒绝 SETUP request (后者在最初提供这些 profiles 后不应该发生).

注意: 若要更改正在使用的任何 profile, client 需要使用 TEARDOWN method 拆除该 media stream (并且可能拆除整个 RTSP session), 然后使用 SETUP 重新建立. 一旦规定了 media updating (类似 SIP UPDATE 或 re-INVITE), 这一点可能会改变.

使用 SDP key management [7] 时, 如果选择了安全 profile, 则相应 RTSP messages 中必须包含 KeyMgmt header. 如果 SDP description 中提供了不同的安全 profiles (例如 SAVP 和 SAVPF), 并且为这些 profiles 提供了不同 keying material, 则在 SETUP message 中选择一个 profile 后, 必须只提供所选 profile 对应的 KeyMgmt header. RFC 4567 [7] 中关于将 KeyMgmt headers 与 media streams 匹配的规则适用.

3.3.3. 通告 Session Descriptions

不允许交互式协商 session descriptions 的协议 (例如 SAP [11], 发布在 Web 页面上的描述或通过邮件发送的描述), 会把确保 media sessions 具备适当访问条件的责任置于 session initiator.

initiator 应该在应用和 session 目的可接受的范围内, 为多个 RTP profiles 提供替代 session descriptions. 如果需要安全性, 可以提供 SAVP 作为 SAVPF 的替代项 -- 但除非采用了不依赖 SRTP 的其他安全手段, 否则不应该通告 AVP 或 AVPF sessions.

RFC 4567 [7] 和 RFC 4568 [8] 中定义的 SDP attributes 也可以用于已通告 session descriptions 的安全参数分发.

RFC 4568 [8] 中定义的 security scheme description 要求使用安全通信信道, 以防止第三方窃听和篡改 keying parameters. 因此, 应该使用 SAP security (如 RFC 2974 [11] 所定义), S/MIME [12], HTTPS [13], 或其他适当机制来分发或访问这些 session descriptions.

3.3.4. 描述替代 Session Profiles

SAVP 和 SAVPF 实体可以混合在同一 RTP session 中 (另见第 4 节), AVP 和 AVPF 实体也可以如此. 其他组合 -- 即同一 RTP session 中安全 profiles 与非安全 profiles 的组合 -- 互不兼容, 不得一起使用.

如果相关 peers 之间可以协商 (例如第 3.3.1 节的 offer/answer model 或第 3.3.2 节的 RTSP), 则一个实体 (例如 offerer) 可以指定替代的 (安全和非安全) profiles, 另一个实体必须从中选择一个 profile. 如果无法进行这种协商 (例如第 3.3.3 节所述的 SAP), 则不得将不兼容 profiles 指定为替代项.

替代 profiles 的协商有待进一步研究.

RTP profiles 可以在不同 RTP sessions 之间任意混合.

3.4. 示例

本节包含使用 SDP 协商安全和非安全配置文件的示例. 根据所使用的密钥机制及其参数化方式, SDP 消息通常需要完整性保护, 对某些机制还需要机密性保护. 例如, 可以说 Datagram Transport Layer Security - Secure Real-time Transport Protocol (DTLS-SRTP) [16] 的 a=fingerprint 需要完整性保护, 而 RFC 4568 [8] (Security Descriptions) 的 a=crypto 需要机密性保护.

示例 1: 以下会话描述表示一个用于点对点通信的安全会话, 由音频和双音多频 (DTMF) 组成, 其中 DTMF 流使用 Generic NACK. 指示的密钥管理协议是 MIKEY. 此会话描述 (offer) 可以包含在 SIP INVITE 或 200 OK 消息中, 表明其发送方能够并愿意接收针对其传输的 DTMF 流的反馈. 对应的 answer 可以承载在 200 OK 或 ACK 中. 安全协议参数按 RFC 4567 [7] 定义的 SDP 扩展所述进行协商.

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD...

示例 2: 此示例展示与示例 1 相同的反馈参数, 但使用 security descriptions 语法 [8]. 注意, a=crypto attribute 的密钥部分不受防窃听保护, 因此 session description 需要通过安全通信信道交换.

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
a=crypto:AES_CM_128_HMAC_SHA1_32
  inline:d/16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj/2^20/1
  :32

示例 3: 此示例复制自上面的示例 1, 但展示 offer/answer 交换中 offerer 与 answerer 之间的交互, 同样使用 MIKEY 协商 keying material:

Offer:

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD...
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack

Answer:

v=0
o=alice 3203093521 3203093521 IN IP4 host.another.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.another.example.com
a=key-mgmt:mikey ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD...
m=audio 53012 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack

示例 4: 此示例展示通过 RTSP 控制的视频流交换. client 使用 DESCRIBE 从 server 获取 media description, 并获得一个不含任何 keying parameters 的静态 SDP description, 但该 media description 表明使用 (S)AVPF 的安全和非安全 media sessions 均可用. 一种允许在 session description 中显式标识这些替代项 (即安全和非安全 sessions) 的机制目前正在定义中 [14]. 随后 client 发出 SETUP request, 并通过在 Transport parameter 中包含相应 profile 来指明其选择. 此外, client 包含 KeyMgmt header 来传递其安全参数, server 在响应中以相应的 KeyMgmt header 与之匹配. 由于只选择单个 media session, 聚合 RTSP URI 足以用于标识.

RTSP DESCRIBE request-response pair (可选):

DESCRIBE rtsp://movies.example.org/example RTSP/2.0
CSeq: 314
Accept: application/sdp

200 OK
CSeq: 314
Date: 25 Nov 2005 22:09:35 GMT
Content-Type: application/sdp
Content-Length: 316

v=0
o=alice 3203093520 3203093520 IN IP4 movies.example.com
s=Media with feedback
t=0 0
c=IN IP4 0.0.0.0
m=video 49170 RTP/SAVPF 96
a=rtpmap:96 H263-2000/90000
a=rtcp-fb:96 nack
m=video 49172 RTP/AVPF 96
a=rtpmap:96 H263-2000/90000
a=rtcp-fb:96 nack

RTSP SETUP request-response pair

SETUP rtsp://movies.example.org/example RTSP/2.0
CSeq: 315
Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013"
KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example";
         data="uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnD..."

200 OK
CSeq: 315
Date: 25 Nov 2005 22:09:36 GMT
Session: 4711
Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013";
           src_addr="192.0.2.15:60000"/"192.0.2.15:60001"
KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example";
         data="ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD..."
Accept-Ranges: NPT, SMPTE

示例 5: 以下会话描述表示一个组播音频/视频会话 (音频使用 PCMU, 视频使用 H.261 或 H.263+), 其中视频源接受针对两个编解码器的 Generic NACK, 并接受针对 H.263 的 Reference Picture Selection. 安全协议参数按 RFC 4567 [7] 定义并在会话级使用的 SDP 扩展所述进行协商. 这样的描述可能已通过 Session Announcement Protocol (SAP) 传送.

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multicast video with feedback
t=3203130148 3203137348
a=key-mgmt:mikey uiSDF9sdhs7494ghsd/dhsoKkdOokdo7eWsnDSJD...
m=audio 49170 RTP/SAVP 0
c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/SAVPF 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi