第7讲 多媒体网络 本讲概述: 本讲目标: 多媒体的网络应用 了解多媒体网络的应用要求 存储式音频/视频流 交互式的实时应用 第7讲 多媒体网络 本讲概述: 多媒体的网络应用 存储式音频/视频流 RTSP 交互式的实时应用 IP电话举例 RTP H.323 and SIP 在尽力而为的基础上发展 调度和策略的实施 集成服务 区别服务 本讲目标: 了解多媒体网络的应用要求 延迟 带宽 数据丢失 学习如何将因特网所提供的尽力而为的服务用到极致 学习因特网将如何进化以便更好的支持多媒体应用 第7讲 多媒体网络

网络中的多媒体 基本特征: 一般对延迟敏感. 但可以容忍部分数据的丢失: 偶尔发生的数据丢失会产生轻微的干扰，可以忽略. 数据资料的传输(程序, 银行信息, etc.), 却正好相反，可以容忍延迟，但不能容忍数据的丢失. 多媒体也称 “连续媒体（continuous media）/流媒体” 多媒体应用的分类: 存储式的 audio/video流媒体 直播式的audio/video流媒体 实时交互式的audio/video 第7讲 多媒体网络

网络中的多媒体 (2) 存储式流媒体 实况转播（单向实时） : 客户端从服务器请求audio/video文件，以流水方式从网络上进行接收并显示 交互: 用户可进行操作 (如同操作录像机: 暂停, 恢复播放, 快进, 回退, etc.) 延迟: 从客户端发出请求到开始播出为1～10秒 实况转播（单向实时） : 如同 TV 和无线广播, 但是从因特网上传送 非交互, 只是收视/收听 实时交互 : 电话或视频会议 由于实时特性，比流媒体点播和实况转播要求更为严格 Video: < 150 ms尚可 Audio: < 150 ms比较好, <400 ms可以接受 第7讲 多媒体网络

网络中的多媒体 (3): 挑战 TCP/UDP/IP 协议族提供的是尽力而为,无延迟或延迟变动承诺的服务. 流媒体的应用有 5-10的延迟今天看来十分普遍,但当链路(越洋线路)拥塞时，情况会急剧恶化 实时交互应用对分组延时和抖动（ jitter）具有严格的限制. 抖动（Jitter）是指在同一分组流传输过程中发生的分组延时变化. 如果在因特网中能分出服务级别，那么多媒体应用的设计将要容易的多. 但是在公共因特网中,所有分组所受到的服务完全是相等的. 包含实时交互audio和video 数据分组在网络中所受到的待遇,和其他分组完全一样. 目前对在因特网中提供区别对待的服务的研究一直在进行之中. 第7讲 多媒体网络

网络中的多媒体 (4): 将尽力而为的服务用到极致 网络中的多媒体 (4): 将尽力而为的服务用到极致 为减少“尽力而为”的因特网的服务原则的影响，我们可以: 使用UDP来避免TCP和它的慢启动过程… 在客户端缓存部分内容和控制回放来弥补传输抖动造成的影响 我们可以给分组加上时间戳来提醒接收端及时回放该分组. 选择压缩等级来适配可用带宽 我们还可以发送冗余的分组来减少分组丢失所造成的影响。  我们将讨论这些 “雕虫小技” 第7讲 多媒体网络

因特网应如何进化才能更好的支持多媒体? 区别服务（Diffserv）的哲学: 集成服务（Intserv）的哲学: 改变因特网协议以便应用程序能够预定端对端的带宽 需要部署协议来预留带宽 必须修改路由器的调度策略来响应带宽预留 应用程序必须体为网络提供信息流量的描述,并进而遵循这样的描述. 在主机和路由器中开发新的更复杂的软件 区别服务（Diffserv）的哲学: 对因特网的基础结构进行改造,使其可以提供分级的服务. 分组要加标记 用户为高级别的服务付出更多的费用. ISP为骨干网络收发高级别的分组付出更多的费用. 第7讲 多媒体网络

因特网应如何进化才能更好的支持多媒体?(续) 自由放任( Laissez-faire )哲学 没有带宽预定,不搞分组标记 只要需求增加,供应更多的带宽 将存储内容置于网络的边缘: ISP和主干上增加缓存 内容提供商将内容置于 CDN 结点 P2P: 选择临近的存储有内容的对等结点 虚拟专网 (VPN) 为企业保留永久性的带宽域( blocks of bandwidth）. 路由器可以根据IP 地址来识别VPN的信息流 路由器使用特殊的调度策略来提供预留的带宽. 第7讲 多媒体网络

存储式Audio & Video流 存储式流媒体: 媒体播放器（Media player）: Audio/video 文件存储在服务器上 提供交互性 (暂停, 重新定位等, etc.). 媒体播放器（Media player）: 消除抖动 解压缩 错误校正 提供图形交互界面进行控制 可以使用插件（Plug-in）将媒体播放器植入浏览器窗口. 第7讲 多媒体网络

从Web服务器调用流媒体 (1) Audio和 video文件存储在 Web服务器上 最原始的方法 浏览器使用HTTP请求报文从Web服务器访问流媒体文件 Web服务器用HTTP响应报文发送文件 content-type 首部行描述了 audio/video的编码 浏览器启动媒体播放器,并将文件传递给它 媒体播放器解读该文件 主要缺点: 媒体播放器通过浏览器作为中介 与Web 服务器交互 第7讲 多媒体网络

从Web服务器调用流媒体(2) 改进: 在服务器和播放器之间建立连接 浏览器请求和接收元文件（ meta file ）(用来描述对象的文件）而不是接收文件本身) ; Content-type首部说明是特定的audio/video应用 浏览器启动媒体播放器并将元文件传递给它 播放器与服务器建立TCP 连接并发送 HTTP请求. 问题讨论: 媒体播放器使用HTTP通信, 没有 pause, ff, rwnd 功能 可以考虑使用 UDP通信 第7讲 多媒体网络

从流媒体服务器调用流媒体 该结构可以使用非HTTP协议进行通信在服务器和流媒体播放器之间进行通信 可以使用UDP来替代 TCP. 第7讲 多媒体网络

实时流媒体协议（Real Time Streaming Protocol）: RTSP HTTP HTTP所服务的媒体已经定型: HTML, images, applets, etc. HTTP 的设计没有考虑流媒体 (i.e., audio, video, etc.) RTSP: RFC 2326 客户端-服务器应用层协议. 可为用户提供播出控制: rewind, fast forward, pause, resume, repositioning, etc… 它所不能做到的: 没有流媒体传递过程中的audio/video数据的封装 不限制流媒体的传递方式; 既可以用 UDP也可以用TCP 没有定义流媒体播放器如何对 audio/video数据进行缓存 RealNetworks 服务器和播放器使用RTSP 互相向对方发送控制信息 第7讲 多媒体网络

RTSP: 带外控制-out of band control FTP 使用了 “带外”的控制通道: 文件传输通过一个通道 控制信息 (cd, rm, mv, etc.) 则通过分离的TCP连接发送 . “带外”和 “带内” 通道使用不同的端口号. RTSP 报文也使用带外通道传送: RTSP控制报文使用的端口号与媒体流使用的不同，所以是带外传递. 流媒体的分组结构不是由RTPS定义的，因此被认为是在“带内”传输的. 如果RTSP报文使用与流媒体相同的端口号，RTSP将与流媒体一起“间隔”传送. 第7讲 多媒体网络

RTSP 启动和控制传递 首先客户端获取多媒体的表示方式描述, 这可以由若干媒体流组成. 浏览器个根据表示方式所描述的内容类型调用媒体播放器 (辅助的应用程序-helper application). 表示描述中使用URL方法 rtsp:// 将媒体流包含在内 播放器发送 RTSP SETUP请求; 服务器发送 RTSP SETUP响应. 播放器发送 RTSP PLAY 请求;服务器发送 RTSP PLAY 响应. 媒体服务器“泵出”流媒体. 播放器发送 RTSP PAUSE请求;服务器发送 RTSP PAUSE响应. 播放器发送 RTSP TEARDOWN请求;服务器发送 RTSP TEARDOWN响应. 第7讲 多媒体网络

元文件举例 <title>Twister</title> <session> <group language=en lipsync> <switch> <track type=audio e="PCMU/8000/1" src = "rtsp://audio.example.com/twister/audio.en/lofi"> e="DVI4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audio.example.com/twister/audio.en/hifi"> </switch> <track type="video/jpeg" src="rtsp://video.example.com/twister/video"> </group> </session> 第7讲 多媒体网络

RTSP会话 每次RTSP 都会有由服务器选择的会话定义符. 当客户端用SETUP请求启动会话，服务器就会使用定义符来进行响应. 在随后的过程中，客户端反复在每个请求中都使用该定义符,直到客户端使用 TEARDOWN请求来结束会话. RTSP 端口号为 554. RTSP 报文可以通过 UDP或TCP发送. 每个 RTSP 报文可以通过一个分离的TCP 连接进行. 第7讲 多媒体网络

RTSP: 交换实例 C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY S: RTSP/1.0 200 1 OK Session 4231 C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0- C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Range: npt=37 C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 S: 200 3 OK 第7讲 多媒体网络

RTSP: 流媒体的缓存 对RTSP响应报文的缓存没有太大的意义. 但希望将媒体流缓存在客户端的邻近处. 大部分 HTTP/1.1的缓存控制机制也被RTSP采用. 缓存的控制首部可以用于RTSP SETUP 请求和相应: If-modified-since: , Expires: , Via: , Cache-Control: 对给定的流媒体来说代理缓存只能按数据段的形式保持. 代理缓存可以从本地缓存 中取出部分数据进行服务,而然后必须同原始服务器连接来填充部分丢失的资料, 但愿不要在客户端造成传输中断 . 从原始服务器传回的流媒体将通过代理传到客户端, 代理可以使用TCP来获取流媒体; 但代理服务器还是把RTSP控制报文发给了原始服务器. 第7讲 多媒体网络

实时交互式应用 PC-2-PC phone 现在来研究PC-2-PC IP 电话的案例 PC-2-phone 视频会议 Webcams Dialpad Net2phone 视频会议 Webcams 现在来研究PC-2-PC IP 电话的案例 第7讲 多媒体网络

使用“尽力而为服务”的IP电话 (1) Best effort model packet delay, loss and jitter 现在对分组延迟、丢失、和抖动对电话内容所造成的影响进行分析. IP 电话应用程序在对话期间产生分组 谈话期间的数据产生的速率为64 kb/s 在交谈期间, 每 20 ms应用程序将产生160字节 ( 8 kB/s * 20 ms )的数据块 数据块加上首部; 然后封装入UDP分组并发送 某些分组的丢失和延迟会给传输造成“起伏 (fluctuate)”. 受话方必须确定何时将数据块进行播放，如何处理缺失的数据块 第7讲 多媒体网络

IP 电话 (2) 分组丢失 UDP 段封装在 IP 分组中 分组在路由器队列中可能溢出 TCP 虽然可以消除数据丢失, 但是 重发会增加延迟 TCP 的拥塞控制会降低速率 增加冗余分组会有帮助 端对端的延迟 为发送、传播、排队延迟的总和 端对端的延迟一旦超过400 ms将严重影响交互性; 这种延迟越小越好 延迟抖动(delay jitter) 考虑交谈期间两个连续的语音分组 在发送端初始间隔为20 ms, 但到达受话方时，间隔可能发生变化(>20ms;<20ms) 消除抖动(removing jitter) 编顺序号码 时间戳(timestamps) 延迟播出(delaying playout) 第7讲 多媒体网络

IP电话 (3): 固定的播放延迟 受话方试图在数据块产生的q ms后播出. 顺序编号没有必要. 对丢失的分组需要采取策略. Q的取值问题: 如果数据块有时间戳 t, 受话方将在t+q以后将数据播出 如果数据块在t+q以后到达, 受话方将予以丢弃. 顺序编号没有必要. 对丢失的分组需要采取策略. Q的取值问题: large q: 分组丢失较少 small q: 较好的交互性能 第7讲 多媒体网络

IP 电话 (4):固定的播放延迟 发送方在交谈期间每隔20 ms产生分组. 首个分组在时间r到达 第一种播放策略: 在p点开始 第7讲 多媒体网络

从数据丢失中恢复 (1) 数据丢失: 分组没有到达或比其计划中播出时间迟到 前向纠错( forward error correction ，FEC): 简单机制 以n个数据块为一组，为每一组创建一个冗余块，该块的形成是通过对这n个原始块的异或（xor）而得 发送这 n+1 个块（chunks）,增加了1/n的带宽. 如果从该n+1块里丢失的块最多只有一个的话，该块可以重新构建 播出延迟必须限定在这对n+1 分组的接收时间里 折衷: 加大 n, 带宽浪费较小些 加大 n, 较长的播出延迟 加大 n, 出现2个或2个以上分组丢失的概率增加 第7讲 多媒体网络

从数据丢失中恢复(2) 第二种 FEC 机制 “捎带低品质流媒体” 发送低分辨率的媒体流 作为冗余信息 例如, 一般流媒体的音 频的 PCM 为64 kb/s而冗 余的GSM为 13 kb/s. 发送端从正常流媒体的 第n个数据块与（n-1）数 据块中创建冗余流媒体附 加上一起发送. 只要数据丢失不是连续的，受话端可以对数据丢失 进行补偿. 在开始播放前只要收到两个分组即可开始 为应付连续的数据丢失，也可以附加 (n-1)和 (n-2) 的冗余数据块 第7讲 多媒体网络

从数据丢失中恢复(3) 交错（ interleave ） 数据块被分割成较小的单元 例如, 4～5 ms一个数据块 将数据块如图交错传送 分组将携带来自不同数据块的较小的数据单元 在受话方重新装配数据块 如果分组丢失, 但大部分数据块仍然存在 第7讲 多媒体网络

从数据丢失中恢复(4) 在受话方对受损的音频流进行修复 产生一个类似原始替代数据来替代丢失的分组 重复：对于较小的分组(4-40 ms)和低丢失率可表现出良好的性能 第7讲 多媒体网络

实时协议( Real-Time Protocol,RTP) RTP定义了携带 audio / video数据的分组结构 : RFC 1889. RTP 分组提供 负荷类型定义 分组顺序编号 时间戳 RTP 在端系统中运行 . RTP 分组被封装在UDP数据段中 互操作性（Interoperability）: 如果 两个IP 电话应用程序都运行RTP, 那么它们就有 可能一起工作 第7讲 多媒体网络

RTP 运行在 UDP之上 RTP 库提供了传输层接口来扩展 UDP: 端口号, IP地址 跨段的错误校验 负荷类型标记 分组顺序编号 时间戳 第7讲 多媒体网络

RTP 举例 回顾发送 64 kb/s PCM-编码的语音通过RTP. 应用程序采集已经编码的数据块, e.g., 每20 ms = 160 字节的数据块. 音频 数据块和 RTP首部形成 RTP 分组, 被封装入 UDP数据段. RTP首部说明每个分组的音频类型; 发送端可以在会议期间改变编码. RTP首部同样包含了顺序号和时间戳. 第7讲 多媒体网络

RTP 和 QoS RTP 不承诺提供任何实时传递和 服务质量 保证. RTP 封装仅仅可以在端系统 进行 –与中间的路由器没有关系. 要为应用程序提供 QoS, 因特网必须要提供其他 的机制, 例如 RSVP,为 应用程序预留网络资源. 第7讲 多媒体网络

RTP 媒体流 但是, 一些常用的编码技术 – 包括 MPEG1和 MPEG2 – 在编码过程中将音频和视频合成一个流媒体. 这种情况下，在每个方向上只需一个 RTP流. 对于一场 many-to-many的组播会话来说, 所有的发送方和信源一般将RTP流依据同样的组播地址送入同一组播树 RTP 允许每个信源 (例如,一台摄像机或一个麦克风)赋以 各自的独立的 RTP分组流. 例如,对有两个参与者的得视讯会议, 要打开4个RTP流: 两个用于传输音频 (一个方向一个) 和两个视频流 (同样, 一个方向一个). 第7讲 多媒体网络

RTP 首部 Payload Type (7 bits): 说明传输分组的编码类型. Payload type 0: PCM mu-law, 64 Kbps Payload type 3, GSM, 13 Kbps Payload type 7, LPC, 2.4 Kbps Payload type 26, Motion JPEG Payload type 31. H.261 Payload type 33, MPEG2 video Sequence Number (16 bits): 该序号按所发送的RTP分组递增 ，可用于 测试数据丢失和恢复失序的分组 . 第7讲 多媒体网络

RTP 首部 (2) Timestamp field (32 bytes long). 表示RTP数据分组中首个字节的采样瞬间. 在 接受端 可使用该字段消除抖动和提供同步播出. 该时间戳是由发送端的采样时钟提供的. 例如, 音频的时间戳每个采样周期递增一次 (for example, each 125 usecs for a 8 KHz sampling clock); 如果音频应用程序产生的数据块包括了160 个 已编码采样，在信源激活期间，每个RTP分组的时间戳的增量为160. 只要信源处于激活状态，时间戳时钟就以恒定的速率递增. SSRC field (32 bits long). 定义信源的 RTP流. 在一个RTP会话中，每个流都必须有一个独特的 SSRC. 第7讲 多媒体网络

实时控制协议(Real-Time Control Protocol ,RTCP) 与RTP协同工作. 每个在某个RTP会话中的参与者都要周期性的传输RTCP控制分组给所有其它所有的参与者. 每个RTCP分组都包含了发送端和/或接收端的统计报告，对应用层有用 统计数据包括分组发送数量、分组丢失数量、分组到达的间歇抖动等. 这种反馈信息可用于控制应用程序的性能和进行诊断. 发送方可根据反馈信息修改传输参数（The sender may modify its transmissions based on the feedback）. 第7讲 多媒体网络

RTCP – (续) - 一般典型的RTP会话都有一个组播(multicast)地址; 所有的RTP 和 RTCP 分组只要同属该会话，就是使用该组播地址. - RTP 和RTCP分组可使用不同的端口号来相互区别. - 为限制数据流量, 当参与者增加时，每各与会者都会减少 RTCP数据的发送. 第7讲 多媒体网络

RTCP 分组 接收端报告分组: 丢包比率, 最后收到的分组,平均间隔的抖动. 发送端报告分组: RTP流中的 SSRC, 当前时间, 已经发送的分组数量, 和发送的字节数量. 信源描述分组: 发送端的e-mail地址,发送端的名称, 相关RTP流的 SSRC . 分组提供了SSRC和用户/主机间的 映射. 第7讲 多媒体网络

流媒体的同步问题 RTCP可以协调同一会话中的不同流的同步. 考虑一下视讯会议，应用程序对视频流和音频流分别产生一个 RTP数据流. 在两个媒体流中都携有时间戳是来自采样时钟，而不是来自墙上的挂钟 (i.e., to real time). 每个RTCP发送端报告分组包括, 在相关RTP流中最近产生的分组中, RTP分组的时间戳和分组创建的真实时间. 这样 RTCP发送端报告分组将采样时钟和真实时间联系在一起. 接收端可以依据这种联系来同步音频和视频播出. 第7讲 多媒体网络

RTCP带宽分配(Bandwidth Scaling) 例如, 假设一个发送端以2 Mb/s速率发送视频数据. 那么RTCP的信息流量限制在 100 Kb/s. 协议规定把其中 75%（ 75 kb/s）的速率留给接收端, 其余的 25% 或 25 kb/s, 给发送端. 分配给接收端的75 kb/s在接收端之间进行平均分配，假设有R 个接收端，每个接收端分得 75/R kb/s而发送端则以25kb/s 发送 RTCP信息 . 一个会话参与者 (一个接收端或一个发送端) 在动态计算平均RTCP分组大小(across the entire session)的基础上确定RTCP分组的传输周期. 第7讲 多媒体网络

H.323 概述 H.323 终端 H. 323 编码 网守(Gatekeeper) 网关(Gateway) Audio 编码机制 Video 编码机制 第7讲 多媒体网络

概述 (1) 在IP网络上进行音频和视频会议的基础 . 定位于实时通信(而不是存储式流媒体) 兼顾 ITU的通信标准. 覆盖的范围: 独立设备 (如：Web 电话，Web 电视) PC应用程序 点对点和多点视讯会议 H.323 定义包括: 终端如何启动/接受呼叫 终端间如何使用通用 audio/video编码 . Audio和video数据如何进行封装和发送. Audio和video如何同步 (lip-sync). 终端如何同各自的网守程序（gatekeeper）通信 IP电话如何与 PSTN /ISDN 电话通信. 第7讲 多媒体网络

概述 (2) Telephone calls Video calls Conferences Whiteboards 第7讲 多媒体网络

概述 (3) H.323 SS7, Inband 第7讲 多媒体网络

H.323端接点必须支持: G.711 - ITU 语音压缩标准 RTP – 将媒体数据块封装成分组的协议 H.245 - “带外” 控制协议用于控制H.323终端间的流媒体传输 . Q.931 – 用于建立/结束连接的信令协议 RAS (Registration/ Admission/Status) 信道协议 – 与网守程序进行通信的协议 (如果存在网守-gatekeeper) 第7讲 多媒体网络

H.323 终端 第7讲 多媒体网络

H.323 编码 Audio: H.323终端必须支持 G.711 标准进行语音压缩. G.711 以 56～64 kb/s的速率传输语音. H.323 正在考虑使用 G.723 = G.723.1, 该标准以 5.3～6.3 kb/s的速率操作（来支持低速链路）. Optional: G.722, G.728, G.729 Video 对 H.323终端来说，视频能力为可选项. 任何可视化的 H.323终端必须支持 QCIF H.261 (176x144 pixels). 也可以选择其他的H.261机制: CIF, 4CIF and 16CIF. H.261所使用的信道带宽必须是64 kb/s的整倍数. 第7讲 多媒体网络

产生H.323中的音频数据流 Audio Source Encoding: e.g., G.711 or G.723.1 RTP packet encapsulation UDP socket Internet or Gatekeeper 第7讲 多媒体网络

H.245控制通道 主要任务: H.323 媒体流可以包含若干信道来传输不同类型的媒体数据 开闭媒体信道 能力信息交换:在发送流媒体之前,通信终端对它们之间的编码/算法协商一致 H.323 媒体流可以包含若干信道来传输不同类型的媒体数据 每个H.323会话有一个 H.245 控制信道 H.245 控制信道是 一个可靠的 (TCP) 信道 第7讲 多媒体网络

信息流 第7讲 多媒体网络

网守(Gatekeeper) 1/2 网守是任选的H.323模块/设备, 可以给端点提供: 负责”别名”与IP地址的转换 H.323 terminals Gatekeeper Router Internet LAN = “H.323 Zone” RAS 网守是任选的H.323模块/设备, 可以给端点提供: 负责”别名”与IP地址的转换 带宽管理: 可以限制实时会议所消耗的带宽 作为可选功能, H.323呼叫可以被引导通过网守, 对计费有用. RAS协议 (over TCP)负责端点-网守间的通信 第7讲 多媒体网络

网守(Gatekeeper) 2/2 H.323终端必须在网守的辖区内注册. 当 H.323 应用程序在终端上调用时,该终端使用 RAS 给网守发送其 IP地址和(用户提供的)别名. 如果区内有网守存在, 每个区内的终端必须与网守联系并获取呼叫许可. 一旦获得许可, 终端将给网守发送电子邮件地址、别名字符串或电话分机.网守将别名翻译成 IP 地址 如有必要,网守将轮询其他辖区中的网守以解决IP地址的解析问题.处理过程如同DNS,但具体做法因厂商而异 第7讲 多媒体网络

H.323 网关(Gateway) 是IP区和PSTN (or ISDN) 网络之间的桥梁. H.323 terminals Router Internet RAS Gatekeeper LAN = “H.323 Zone” 是IP区和PSTN (or ISDN) 网络之间的桥梁. 终端使用 H.245和 Q.931与网关进行通信 第7讲 多媒体网络

Audio编码机制 MOS (Mean Opinion Score) 第7讲 多媒体网络

Video编码机制 H.261 (p x 64 kb/s) H.263 (< 64 kbit/s) ISDN上的视频流 分辨率 : QCIF, CIF H.263 (< 64 kbit/s) 低传输速率通信 分辨率: SQCIF, QCIF, CIF,4CIF, 16CIF (128 x 96) (176 x 144) (352 x 288) (704 x 576) (1408 x 1152) SQCIF QCIF CIF 4CIF 16CIF 第7讲 多媒体网络