5.1 Unicast Streams (单播流)
5.1 Unicast Streams (单播流)
若提议方仅希望经某条流向对等端发送媒体, 则必须使用 a=sendonly 属性将该流标记为仅发送 (sendonly). 若方向属性作为媒体流属性或会话属性出现, 则称该流被标记为某一方向. 若提议方仅希望从对等端接收媒体, 则必须将该流标记为仅接收 (recvonly). 若提议方希望通信, 但此时既不想发送也不想接收媒体, 则必须使用 a=inactive 属性将该流标记为非活动 (inactive). 非活动方向属性在 RFC 3108 [3] 中规定. 注意, 对实时传输协议 (Real Time Transport Protocol, RTP) [4] 而言, 对 sendonly, recvonly 与 inactive 的流仍会发送和接收 RTCP (RTP Control Protocol). 即, 媒体流的方向性不影响 RTCP 的使用. 若提议方希望与对等端同时发送和接收媒体, 则可以包含 a=sendrecv 属性, 也可以省略它, 因为 sendrecv 为默认情况.
对 recvonly 与 sendrecv 的流, 提议中的端口号与地址表示提议方希望接收该媒体流的位置. 对 sendonly 的 RTP 流, 地址与端口号间接表示提议方希望接收 RTCP 报告的位置. 除非另有明确说明, 报告发送到比所示端口号大一的端口. 提议中出现的 IP 地址与端口并不表示提议方将发送的 RTP 与 RTCP 分组的源 IP 地址与源端口. 提议中端口号为零表示提供了该流但绝对不能使用. 这在初始提议中没有实用语义, 但为完整性允许出现, 因为应答中可以包含零端口表示拒绝的流 (第 6 节). 此外, 可将端口设为零以终止现有流 (第 8 节). 一般而言, 端口号为零表示不期望该媒体流.
每条媒体流的媒体格式列表传达两类信息: 一是提议方能够发送和/或接收 (取决于方向属性) 的格式集合 (对 RTP 而言为编解码器及与该编解码器关联的任何参数), 二是对 RTP 而言用于标识这些格式的 RTP 净荷类型 (payload type) 编号. 若列出多种格式, 表示提议方能够在会话期间使用其中任意一种格式. 换言之, 应答方可以在会话中途更换格式, 使用所列任意一种格式, 而无需发送新提议. 对 sendonly 的流, 提议应指出提议方愿意为该流发送的格式. 对 recvonly 的流, 提议应指出提议方愿意接收的格式. 对 sendrecv 的流, 提议应指出提议方愿意同时发送和接收的编解码器.
对 recvonly 的 RTP 流, 净荷类型编号表示提议方期望为该编解码器接收的 RTP 分组中净荷类型字段的值. 对 sendonly 的 RTP 流, 净荷类型编号表示提议方计划为该编解码器发送的 RTP 分组中净荷类型字段的值. 对 sendrecv 的 RTP 流, 净荷类型编号表示提议方期望接收并更愿意发送的净荷类型字段的值. 但是, 对 sendonly 与 sendrecv 的流, 应答可能对相同编解码器给出不同的净荷类型编号; 此时, 提议方必须使用应答中的净荷类型编号进行发送.
由于与 H.323 的互操作性考虑, 两个方向可能需要不同的净荷类型编号.
按照 RFC 2327, 可以出现 fmtp 参数以提供媒体格式的附加参数.
对 RTP 流, 所有媒体描述应包含 a=rtpmap, 将 RTP 净荷类型映射到编码. 若没有 a=rtpmap, 应使用当前所用配置文件 (例如 RFC 1890 [5]) 定义的默认净荷类型映射.
这样便于从静态净荷类型迁移.
在所有情况下, m= 行中的格式必须按偏好顺序列出, 第一种格式为最受偏好. 此处的偏好是指, 提议的接收方应使用对其可接受且偏好最高的格式.
若某流存在 ptime 属性, 表示提议方希望接收的期望分组化间隔 (packetization interval). ptime 属性必须大于零.
若某流存在带宽 (bandwidth) 属性, 表示提议方希望接收的期望带宽. 允许值为零, 但不鼓励. 它表示不应发送媒体. 对 RTP 而言, 也会禁用所有 RTCP.
若存在多种不同类型的媒体流, 表示提议方希望同时使用这些流. 典型情形是视频会议中的音频与视频流.
若提议中存在多条相同类型的媒体流, 表示提议方希望同时发送 (和/或接收) 多条该类型的流. 发送多条同类型流时, 如何将各媒体源 (例如视频情形下的摄像机与录像机) 映射到各条流属于本地策略. 当用户对某媒体类型只有一个源时, 只有一种策略合理: 将该源发送到每条同类型流. 各流可以使用不同编码. 接收多条同类型流时, 如何将各流映射到该类型的各媒体宿 (sink) (例如音频情形下的扬声器或录音设备) 属于本地策略. 然而, 策略须满足若干约束. 首先, 接收多条同类型流时, 每条流必须至少映射到一个用于向用户呈现的宿. 换言之, 接收多条同类型流的意图是并行呈现它们, 而不是只选其一. 另一约束是, 当多条流被接收并送到同一宿时, 必须以某种与媒体相关的方式合并. 例如, 两条音频流的接收媒体都可能映射到扬声器, 此时合并操作是混音. 对多条即时消息流, 若宿为屏幕, 合并操作是在用户界面上全部呈现. 第三项约束是, 若多个源映射到同一条流, 在发送到该流之前必须以某种与媒体相关的方式合并这些源. 尽管超出这些约束的策略可以灵活, 代理通常不会希望把媒体从宿复制到源, 除非它是会议服务器 (即, 不要把一条流上接收的媒体复制到另一条流).
同类型多条媒体流的典型用例是预付费电话卡应用: 用户在通话中可随时长按井号 ("#") 键挂断并用同一张卡发起新呼叫. 这需要将来自用户的媒体送往两个目的地: 远端网关, 以及监听井号的 DTMF 处理应用. 这可以用两条媒体流实现: 一条对网关为 sendrecv, 另一条 (从用户角度) 对 DTMF 应用为 sendonly.
提议方发出提议后, 必须准备好接收该提议所描述的任意 recvonly 流的媒体. 必须准备好对提议中任意 sendrecv 流同时发送和接收媒体, 并对任意 sendonly 流发送媒体 (当然, 在对等端提供带有所需地址与端口信息的应答之前, 实际上无法发送). 对 RTP 而言, 即使可能在应答到达之前收到媒体, 在应答到达之前仍无法发送 RTCP 接收方报告.