7a-1主讲人,西安交通大学 程向前 第 7讲 多媒体网络
第 7讲 多媒体网络
本讲目标,
? 了解多媒体网络的应用要
求
? 延迟
? 带宽
? 数据丢失
? 学习如何将因特网所提供
的尽力而为的服务用到极
致
? 学习因特网将如何进化以
便更好的支持多媒体应用
本讲概述,
? 多媒体的网络应用
? 存储式音频 /视频流
? RTSP
? 交互式的实时应用
? IP电话举例
? RTP
? H.323 and SIP
? 在尽力而为的基础上发展
? 调度和策略的实施
? 集成服务
? 区别服务
7a-2主讲人,西安交通大学 程向前 第 7讲 多媒体网络
网络中的多媒体
基本特征,
? 一般对延迟敏感,
? 但可以容忍部分数据的丢失,
偶尔发生的数据丢失会产生
轻微的干扰，可以忽略,
? 数据资料的传输 (程序,银行
信息,etc.),却正好相反，
可以容忍延迟，但不能容忍
数据的丢失,
? 多媒体也称,连续媒体（
continuous media） /流媒体
”
多媒体应用的分类,
? 存储式的 audio/video流媒体
? 直播式的 audio/video流媒体
? 实时交互式的 audio/video
7a-3主讲人,西安交通大学 程向前 第 7讲 多媒体网络
网络中的多媒体 (2)
存储式流媒体
? 客户端从服务器请求
audio/video文件，以流水方
式从网络上进行接收并显示
? 交互, 用户可进行操作 (如同
操作录像机, 暂停,恢复播放
,快进,回退,etc.)
? 延迟, 从客户端发出请求到
开始播出为 1～ 10秒
实况转播（单向实时）,
? 如同 TV 和无线广播,但是从
因特网上传送
? 非交互,只是收视 /收听
实时交互,
? 电话或视频会议
? 由于实时特性，比流媒体点播和
实况转播要求更为严格
? Video,< 150 ms尚可
? Audio,< 150 ms比较好,
<400 ms可以接受
7a-4主讲人,西安交通大学 程向前 第 7讲 多媒体网络
网络中的多媒体 (3),挑战
? TCP/UDP/IP 协议族提供的
是尽力而为,无延迟或延迟变
动承诺的服务,
? 流媒体的应用有 5-10的延
迟今天看来十分普遍,但当链
路 (越洋线路 )拥塞时，情况
会急剧恶化
? 实时交互应用对分组延时和
抖动（ jitter） 具有严格的
限制,
? 抖动（ Jitter）是指在同一
分组流传输过程中发生的分
组延时变化,
? 如果在因特网中能分出服务
级别，那么多媒体应用的设
计将要容易的多,
? 但是在公共因特网中,所有分
组所受到的服务完全是相等
的,
? 包含实时交互 audio和 video
数据分组在网络中所受到的
待遇,和其他分组完全一样,
? 目前对在因特网中提供区别
对待的服务的研究一直在进
行之中,
7a-5主讲人,西安交通大学 程向前 第 7讲 多媒体网络
网络中的多媒体 (4),
将尽力而为的服务用到极致
为减少“尽力而为”的因特网的
服务原则的影响，我们可以,
? 使用 UDP来避免 TCP和它的慢
启动过程 …
? 在客户端缓存部分内容和控
制回放来弥补传输抖动造成
的影响
? 我们可以给分组加上时间戳
来提醒接收端及时回放该分
组,
? 选择压缩等级来适配可用贷
款
? 我们还可以发送冗余的分组
来减少分组丢失所造成的影
响。
? 我们将讨论这些,雕虫小技
”
7a-6主讲人,西安交通大学 程向前 第 7讲 多媒体网络
因特网应如何进化才能更好的支持多媒体?
集成服务（ Intserv） 的哲学,
? 改变因特网协议以便应用程序
能够预定端对端的带宽
? 需要部署协议来预留带宽
? 必须修改路由器的调度策略来
响应带宽预留
? 应用程序必须体为网络提供信
息流量的描述,并进而遵循这
样的描述,
? 在主机和路由器中开发新的更
复杂的软件
区别服务（ Diffserv） 的哲学,
? 对因特网的基础结构进行改
造,使其可以提供分级的服务
.
? 分组要加标记
? 用户为高级别的服务付出更
多的费用,
? ISP为骨干网络收发高级别的
分组付出更多的费用,
7a-7主讲人,西安交通大学 程向前 第 7讲 多媒体网络
因特网应如何进化才能更好的支持多媒体?(续 )
自由放任 ( Laissez-faire )哲学
? 没有带宽预定,不搞分组标记
? 只要需求增加,供应更多的带
宽
? 将存储内容置于网络的边缘,
? ISP和主干上增加缓存
? 内容提供商将内容置于
CDN 结点
? P2P,选择临近的存储有内容
的对等结点
虚拟专网 (VPN)
? 为企业保留永久性的带宽域 (
blocks of bandwidth）,
? 路由器可以根据 IP 地址来识
别 VPN的信息流
? 路由器使用特殊的调度策略
来提供预留的带宽,
7a-8主讲人,西安交通大学 程向前 第 7讲 多媒体网络
存储式 Audio & Video流
存储式流媒体,
? Audio/video 文件存储在服
务器上
? 用户根据需求调用
audio/video 文件,
? Audio/video 在请求的 10秒
以内提供,
? 提供交互性 (暂停,重新定位
等,etc.).
媒体播放器（ Media player）,
? 消除抖动
? 解压缩
? 错误校正
? 提供图形交互界面进行控制
? 可以使用插件（ Plug-in）将
媒体播放器植入浏览器窗口,
7a-9主讲人,西安交通大学 程向前 第 7讲 多媒体网络
从 Web服务器调用流媒体 (1)
? Audio和 video文件存储在
Web服务器上
最原始的方法
? 浏览器使用 HTTP请求报文从
Web服务器访问流媒体文件
? Web服务器用 HTTP响应报文
发送文件
? content-type 首部行描述了
audio/video的编码
? 浏览器启动媒体播放器,并将
文件传递给它
? 媒体播放器解读该文件
? 主要缺点,
媒体播放器通过浏览器作为中介
与 Web 服务器交互
7a-10主讲人,西安交通大学 程向前 第 7讲 多媒体网络
从 Web服务器调用流媒体 (2)
改进, 在服务器和播放器之间建
立连接
? 浏览器请求和接收元文件（
meta file ） (用来描述对象
的文件）而不是接收文件本
身 ) ;
? Content-type首部说明是特
定的 audio/video应用
? 浏览器启动媒体播放器并将
元文件传递给它
? 播放器与服务器建立 TCP 连
接并发送 HTTP请求,
问题讨论,
? 媒体播放器使用 HTTP通信,
没有 pause,ff,rwnd 功能
? 可以考虑使用 UDP通信
7a-11主讲人,西安交通大学 程向前 第 7讲 多媒体网络
从流媒体服务器调用流媒体
? 该结构可以使用非 HTTP协议
进行通信在服务器和流媒体
播放器之间进行通信
? 可以使用 UDP来替代 TCP.
7a-12主讲人,西安交通大学 程向前 第 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 互
相向对方发送控制信息
7a-13主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTSP,带外控制 -out of band control
FTP 使用了,带外”的控制通道,
? 文件传输通过一个通道
? 控制信息 (cd,rm,mv,
etc.) 则通过分离的 TCP连接
发送,
?,带外,和,带内, 通道使用
不同的端口号,
RTSP 报文也使用带外通道传送
:
? RTSP控制报文使用的端
口号与媒体流使用的不
同，所以是带外传递,
? 流媒体的分组结构不是
由 RTPS定义的，因此被
认为是在“带内”传输
的,
? 如果 RTSP报文使用与流媒体
相同的端口号,RTSP将与流
媒体一起“间隔”传送,
7a-14主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTSP 启动和控制传递
? 首先客户端获取多媒体的表示方式描述,
这可以由若干媒体流组成,
? 浏览器个根据表示方式所描述的内容类型调用媒体播放器 (辅助的应用程序 -
helper application).
? 表示描述中使用 URL方法 rtsp:// 将媒
体流包含在内
? 播放器发送 RTSP SETUP请求 ; 服务器
发送 RTSP SETUP响应,
? 播放器发送 RTSP PLAY 请求 ;服务器
发送 RTSP PLAY 响应,
? 媒体服务器“泵出”流媒体,
? 播放器发送 RTSP PAUSE请求 ;服务器
发送 RTSP PAUSE响应,
? 播放器发送 RTSP TEARDOWN请求 ;
服务器发送 RTSP TEARDOWN响应,
HT T P G E T
S E T UP
P L A Y
m e d ia strea m
P A USE
T E A RD OW N
me dia
pla y e r
W e b
s e rv e r
me dia
s e rv e r
W e b
brow s e r
c li e nt s e rv e r
p rese n ta tio n d e sc.
7a-15主讲人,西安交通大学 程向前 第 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">
<track type=audio
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>
7a-16主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTSP会话
? 每次 RTSP 都会有由服务器
选择的会话定义符,
? 当客户端用 SETUP请求启动
会话，服务器就会使用定义
符来进行响应,
? 在随后的过程中，客户端反
复在每个请求中都使用该定
义符,直到客户端使用
TEARDOWN请求来结束会
话,
? RTSP 端口号为 554.
? RTSP 报文可以通过 UDP或 TCP
发送, 每个 RTSP 报文可以通过
一个分离的 TCP 连接进行,
7a-17主讲人,西安交通大学 程向前 第 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
Session,4231
Range,npt=37
C,TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi
RTSP/1.0
Session,4231
S,200 3 OK
7a-18主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTSP,流媒体的缓存
? 对 RTSP响应报文的缓存没有
太大的意义,
? 但希望将媒体流缓存在客户
端的邻近处,
? 大部分 HTTP/1.1的缓存控
制机制也被 RTSP采用,
? 缓存的控制首部可以用于
RTSP SETUP 请求和相
应,
? If-modified-since,
,Expires:,Via:,
Cache-Control,
? 对给定的流媒体来说代理缓
存只能按数据段的形式保持,
? 代理缓存可以从本地缓存
中取出部分数据进行服务
,而然后必须同原始服务
器连接来填充部分丢失的
资料,但愿不要在客户端
造成传输中断,
? 从原始服务器传回的流媒体
将通过代理传到客户端,代
理可以使用 TCP来获取流媒体; 但代理服务器还是把 RTSP
控制报文发给了原始服务器,
7a-19主讲人,西安交通大学 程向前 第 7讲 多媒体网络
实时交互式应用
? PC-2-PC phone
? PC-2-phone
? Dialpad
? Net2phone
? 视频会议
? Webcams
? 现在来研究 PC-2-PC IP 电话的
案例
7a-20主讲人,西安交通大学 程向前 第 7讲 多媒体网络
使用“尽力而为服务”的 IP电话 (1)
Best effort model
? packet delay,loss and
jitter
IP 电话举例
? 现在对分组延迟、丢失、和
抖动对电话内容所造成的影
响进行分析,
? IP 电话应用程序在对话期间
产生分组
? 谈话期间的数据产生的速率
为 64 kb/s
? 在交谈期间,每 20 ms应用
程序将产生 160字节 (
8 kB/s * 20 ms )的数据块
? 数据块加上首部 ; 然后封装
入 UDP分组并发送
? 某些分组的丢失和延迟会给
传输造成“起伏
(fluctuate)”.
? 受话方必须确定何时将数据
块进行播放，如何处理缺失
的数据块
7a-21主讲人,西安交通大学 程向前 第 7讲 多媒体网络
IP 电话 (2)
分组丢失
? UDP 段封装在 IP 分组中
? 分组在路由器队列中可能溢
出
? TCP 虽然可以消除数据丢失,
但是
? 重发会增加延迟
? TCP 的拥塞控制会降低速率
? 增加冗余分组会有帮助
端对端的延迟
? 为发送、传播、排队延迟的
总和
? 端对端的延迟一旦超过 400
ms将严重影响交互性 ; 这种
延迟越小越好
延迟抖动 (delay jitter)
? 考虑交谈期间两个连续的语
音分组
? 在发送端初始间隔为 20 ms,
但到达受话方时，间隔可能
发生变化 (>20ms;<20ms)
消除抖动 (removing jitter)
? 编顺序号码
? 时间戳 (timestamps)
? 延迟播出 (delaying playout)
7a-22主讲人,西安交通大学 程向前 第 7讲 多媒体网络
IP电话 (3),固定的播放延迟
? 受话方试图在数据块产生的 q
ms后播出,
? 如果数据块有时间戳 t,受
话方将在 t+q以后将数据播
出
? 如果数据块在 t+q以后到达,
受话方将予以丢弃,
? 顺序编号没有必要,
? 对丢失的分组需要采取策略,
? Q的取值问题,
? large q,分组丢失较少
? small q,较好的交互性能
7a-23主讲人,西安交通大学 程向前 第 7讲 多媒体网络
IP 电话 (4):固定的播放延迟
? 发送方在交谈期间每隔 20 ms产生分组,
? 首个分组在时间 r到达
? 第一种播放策略, 在 p点开始
? 第二种播放策略：在 p’ 点开始
pac k et s
t im e
pac k e ts
gene ra ted
pac k e ts
re c e iv e d
los s
r
p p'
pla y out s c hedule
p - r
pla y out s c hedule
p' - r
7a-24主讲人,西安交通大学 程向前 第 7讲 多媒体网络
从数据丢失中恢复 (1)
? 数据丢失, 分组没有到达或比
其计划中播出时间迟到
前向纠错 ( forward error
correction, FEC),简单机
制
? 以 n个数据块为一组，为每一
组创建一个冗余块，该块的形
成是通过对这 n个原始块的异
或（ xor）而得
? 发送这 n+1 个块（ chunks）,
增加了 1/n的带宽,
? 如果从该 n+1块里丢失的块最
多只有一个的话，该块可以重
新构建
? 播出延迟必须限定在这对 n+1
分组的接收时间里
? 折衷,
? 加大 n,带宽浪费较小些
? 加大 n,较长的播出延迟
? 加大 n,出现 2个或 2个以上
分组丢失的概率增加
7a-25主讲人,西安交通大学 程向前 第 7讲 多媒体网络
从数据丢失中恢复 (2)
第二种 FEC 机制
?,捎带低品质流媒体,
? 发送低分辨率的媒体流
作为冗余信息
? 例如,一般流媒体的音
频的 PCM 为 64 kb/s而冗
余的 GSM为 13 kb/s.
? 发送端从正常流媒体的
第 n个数据块与（ n-1）数
据块中创建冗余流媒体附
加上一起发送,
? 只要数据丢失不是连续的，受话端可以对数据丢失
进行补偿,
? 在开始播放前只要收到两个分组即可开始
? 为应付连续的数据丢失，也可以附加 (n-1)和 (n-2)
的冗余数据块
7a-26主讲人,西安交通大学 程向前 第 7讲 多媒体网络
从数据丢失中恢复 (3)
交错（ interleave ）
? 数据块被分割成较小的单元
? 例如,4～ 5 ms一个数据块
? 将数据块如图交错传送
? 分组将携带来自不同数据块
的较小的数据单元
? 在受话方重新装配数据块
? 如果分组丢失,但大部分数
据块仍然存在
7a-27主讲人,西安交通大学 程向前 第 7讲 多媒体网络
从数据丢失中恢复 (4)
在受话方对受损的音频流进行修
复
? 产生一个类似原始替代数据
来替代丢失的分组
? 重复：对于较小的分组 (4-40
ms)和低丢失率可表现出良好
的性能
7a-28主讲人,西安交通大学 程向前 第 7讲 多媒体网络
实时协议 ( Real-Time Protocol,RTP)
? RTP定义了携带 audio /
video数据的分组结构, RFC
1889.
? RTP 分组提供
? 负荷类型定义
? 分组顺序编号
? 时间戳
? RTP 在端系统中运行,
? RTP 分组被封装在 UDP数据
段中
? 互操作性（ Interoperability
）, 如果 两个 IP 电话应用程
序都运行 RTP,那么它们就有
可能一起工作
7a-29主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTP 运行在 UDP之上
RTP 库提供了传输层接口来扩展 UDP,
?端口号,IP地址
?跨段的错误校验
?负荷类型标记
?分组顺序编号
?时间戳
7a-30主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTP 举例
? 回顾发送 64 kb/s PCM-编
码的语音通过 RTP,
? 应用程序采集已经编码的数
据块,e.g.,每 20 ms = 160
字节的数据块,
? 音频 数据块和 RTP首部形成
RTP 分组,被封装入 UDP数
据段,
? RTP首部说明每个分组的音
频类型 ; 发送端可以在会议
期间改变编码, RTP首部同样
包含了顺序号和时间戳,
7a-31主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTP 和 QoS
? RTP 不承诺提供任何实时传
递和 服务质量 保证,
? RTP 封装仅仅可以在端系统
进行 –与中间的路由器没有
关系,
? 路由器的作用还是完成传统
的尽力而为的服务，而对
RTP分组的传递没有任何实
时性促进的作用,
? 要为应用程序提供 QoS,因
特网必须要提供其他 的机制
,例如 RSVP,为 应用程序预
留网络资源,
7a-32主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTP 媒体流
? RTP 允许每个信源 (例如,一
台摄像机或一个麦克风 )赋以
各自的独立的 RTP分组流,
? 例如,对有两个参与者的得视
讯会议,要打开 4个 RTP流,
两个用于传输音频 (一个方
向一个 ) 和两个视频流 (同
样,一个方向一个 ),
? 但是,一些常用的编码技术 –
包括 MPEG1和 MPEG2 – 在
编码过程中将音频和视频合
成一个流媒体, 这种情况下
，在每个方向上只需一个
RTP流,
? 对于一场 many-to-many的
组播会话来说,所有的发送
方和信源一般将 RTP流依据
同样的组播地址送入同一组
播树
7a-33主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTP 首部
Payload Type (7 bits),说明传输分组的编码类型,
如果在会议过程中发送端改变编码类型，则通过 payload type字段通知接受端,
?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分组递增,可用于
测试数据丢失和恢复失序的分组,
7a-34主讲人,西安交通大学 程向前 第 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.
7a-35主讲人,西安交通大学 程向前 第 7讲 多媒体网络
实时控制协议 (Real-Time Control Protocol
,RTCP)
? 与 RTP协同工作,
? 每个在某个 RTP会话中的参
与者都要周期性的传输 RTCP
控制分组给所有其它所有的
参与者, 每个 RTCP分组都包
含了发送端和 /或接收端的统
计报告，对应用层有用
? 统计数据包括分组发送数量
、分组丢失数量、分组到达
的间歇抖动等,
? 这种反馈信息可用于控制应
用程序的性能和进行诊断,
? 发送方可根据反馈信息修改
传输参数（ The sender
may modify its
transmissions based on
the feedback）,
7a-36主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTCP – (续 )
- 一般典型的 RTP会话都有一个组播 (multicast)地址 ; 所有的 RTP
和 RTCP 分组只要同属该会话，就是使用该组播地址,
- RTP 和 RTCP分组可使用不同的端口号来相互区别,
- 为限制数据流量,当参与者增加时，每各与会者都会减少 RTCP数据的发送,
7a-37主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTCP 分组
接收端报告分组,
? 丢包比率,最后收到的分组,
平均间隔的抖动,
发送端报告分组,
? RTP流中的 SSRC,当前时间
,已经发送的分组数量,和发
送的字节数量,
信源描述分组,
? 发送端的 e-mail地址,发送端
的名称,相关 RTP流的 SSRC
,分组提供了 SSRC和用户 /
主机间的 映射,
7a-38主讲人,西安交通大学 程向前 第 7讲 多媒体网络
流媒体的同步问题
? RTCP可以协调同一会话中的
不同流的同步,
? 考虑一下视讯会议，应用程
序对视频流和音频流分别产
生一个 RTP数据流,
? 在两个媒体流中都携有时间
戳是来自采样时钟，而不是
来自墙上的挂钟 (i.e.,to
real time),
? 每个 RTCP发送端报告分组包
括,在相关 RTP流中最近产生
的分组中,RTP分组的时间戳
和分组创建的真实时间, 这
样 RTCP发送端报告分组将
采样时钟和真实时间联系在
一起,
? 接收端可以依据这种联系来
同步音频和视频播出,
7a-39主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTCP带宽分配 (Bandwidth Scaling)
? RTCP试图将其占用的带宽
限制在 5%的会话带宽以下,
? 例如,假设一个发送端以 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分组的传输周期
,
7a-40主讲人,西安交通大学 程向前 第 7讲 多媒体网络
H.323
?概述
?H.323 终端
?H,323 编码
?网守 (Gatekeeper)
?网关 (Gateway)
?Audio 编码机制
?Video 编码机制
7a-41主讲人,西安交通大学 程向前 第 7讲 多媒体网络
概述 (1)
? 在 IP网络上进行音频和
视频会议的基础,
? 定位于实时通信 (而不是
存储式流媒体 )
? 兼顾 ITU的通信标准,
? 覆盖的范围,
?独立设备 (如,Web
电话,Web 电视 )
?PC应用程序
?点对点和多点视讯会
议
? H.323 定义包括,
? 终端如何启动 /接受呼叫
? 终端间如何使用通用
audio/video编码,
? Audio和 video数据如何进
行封装和发送,
? Audio和 video如何同步
(lip-sync).
? 终端如何同各自的网守程
序（ gatekeeper） 通信
? IP电话如何与 PSTN
/ISDN 电话通信,
7a-42主讲人,西安交通大学 程向前 第 7讲 多媒体网络
概述 (2)
? Telephone calls
? Video calls
? Conferences
? Whiteboards
所有支持 H.323的终端
I n te r n e t
" E t h e r n e t" p h o n e
M S N e t m e e t in g
N e tS p e a k W e b P h o n e
7a-43主讲人,西安交通大学 程向前 第 7讲 多媒体网络
概述 (3)
H.323 SS7,Inband
I n te r n e t P ST N
G at ew a y
G at ek ee p er
7a-44主讲人,西安交通大学 程向前 第 7讲 多媒体网络
H.323端接点必须支持,
?G.711 - ITU 语音
压缩标准
?RTP – 将媒体数据块
封装成分组的协议
?H.245 -,带外” 控
制协议用于控制
H.323终端 间的流媒
体传输,
?Q.931 – 用于建立 /
结束连接的信令协议
?RAS (Registration/
Admission/Status)
信道协议 – 与网守
程序进行通信的协议
(如果存在网守 -
gatekeeper)
7a-45主讲人,西安交通大学 程向前 第 7讲 多媒体网络
H.323 终端
7a-46主讲人,西安交通大学 程向前 第 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的整
倍数,
7a-47主讲人,西安交通大学 程向前 第 7讲 多媒体网络
产生 H.323中的音频数据流
Audio
Source
Encoding:
e.g.,G.711
or G.723.1
RTP packet
encapsulation
UDP
socket Internet orGatekeeper
7a-48主讲人,西安交通大学 程向前 第 7讲 多媒体网络
H.245控制通道
?H.323 媒体流可以
包含若干信道来传输
不同类型的媒体数据
?每个 H.323会话有一
个 H.245 控制信道
?H.245 控制信道是
一个可靠的 (TCP)
信道
?主要任务,
?开闭媒体信道
?能力信息交换,在
发送流媒体之前,
通信终端对它们之
间的编码 /算法协
商一致
7a-49主讲人,西安交通大学 程向前 第 7讲 多媒体网络
信息流
H, 3 2 3
T e r m i n a l
H, 3 2 3
T e r m i n a l
M e d i a C h a n n e l
1
M e d i a C o n t r o l
C h a n n e l
M e d i a C h a n n e l
2
C a l l S i g n a l i n g
C h a n n e l
C a l l C o n t r o l
C h a n n e l
H, 3 2 3
G a t e k e e p e rR A S C h a n n e l
TC P
U D P
7a-50主讲人,西安交通大学 程向前 第 7讲 多媒体网络
网守 (Gatekeeper) 1/2
?网守 是任选的 H.323模块 /设备,可以给端点提供,
?负责,别名,与 IP地址的转换
?带宽管理, 可以限制实时会议所消耗的带宽
? 作为可选功能,H.323呼叫可以被引导通过 网守,对计费有用,
? RAS协议 (over TCP)负责端点 -网守 间的通信
H.
32
3 t
erm
ina
ls
Gatekeeper
Router
Internet
LAN =,H.323 Zone”
RAS
7a-51主讲人,西安交通大学 程向前 第 7讲 多媒体网络
网守 (Gatekeeper) 2/2
? H.323终端必须在网守
的辖区内注册,
?当 H.323 应用程序
在终端上调用时,该
终端使用 RAS 给网
守发送其 IP地址和 (
用户提供的 )别名,
? 如果区内有网守存在,
每个区内的终端必须与
网守联系并获取呼叫许
可,
? 一旦获得许可,终端将
给网守发送电子邮件地
址、别名字符串或电话
分机,网守将别名翻译成
IP 地址
?如有必要,网守将轮
询其他辖区中的网守
以解决 IP地址的解析
问题,处理过程如同
DNS,但具体做法因
厂商而异
7a-52主讲人,西安交通大学 程向前 第 7讲 多媒体网络
H.323 网关 (Gateway)
H.
32
3 t
erm
ina
ls
Gatekeeper
Router Internet
LAN =,H.323 Zone”
RAS
Gateway
PSTN
?是 IP区和 PSTN (or ISDN) 网络之间的桥梁,
?终端使用 H.245和 Q.931与网关进行通信
7a-53主讲人,西安交通大学 程向前 第 7讲 多媒体网络
Audio编码机制
Cod ec Ba n d w idt h
[kb it/s ]
M O S Com p le xi ty
[MIP S ]
P ac ke tiz ation
(f r ame si z e)
[m s]
G,7 11 64 4,5 - -
G,7 21 (A DP CM ) 32 4,4 6,5 -
G S M 13 3,8 4 20
G,7 29 8 4,1 15 10
G,7 23 6,4/ 5,3 4,0 20 30
T ol l q u al ity
r ec o gn iz e s p ea k e r
int el lig ibl e
int el lig ibi lity p r o b,
5
4
3
2
1
M O S ( M ea n O p ini o n S c or e )
MOS (Mean Opinion Score)
7a-54主讲人,西安交通大学 程向前 第 7讲 多媒体网络
Video编码机制
(128 x 96)
(176 x 144)
(352 x 288)
(704 x 576)
(1408 x 1152)
SQCIF
QCIF
CIF
4CIF
16CIF
? H.261 (p x 64 kb/s)
– ISDN上的视频流
– 分辨率, QCIF,CIF
? H.263 (< 64 kbit/s)
– 低传输速率通信
– 分辨率, SQCIF,QCIF,CIF,4CIF,
16CIF
第 7讲 多媒体网络
本讲目标,
? 了解多媒体网络的应用要
求
? 延迟
? 带宽
? 数据丢失
? 学习如何将因特网所提供
的尽力而为的服务用到极
致
? 学习因特网将如何进化以
便更好的支持多媒体应用
本讲概述,
? 多媒体的网络应用
? 存储式音频 /视频流
? RTSP
? 交互式的实时应用
? IP电话举例
? RTP
? H.323 and SIP
? 在尽力而为的基础上发展
? 调度和策略的实施
? 集成服务
? 区别服务
7a-2主讲人,西安交通大学 程向前 第 7讲 多媒体网络
网络中的多媒体
基本特征,
? 一般对延迟敏感,
? 但可以容忍部分数据的丢失,
偶尔发生的数据丢失会产生
轻微的干扰，可以忽略,
? 数据资料的传输 (程序,银行
信息,etc.),却正好相反，
可以容忍延迟，但不能容忍
数据的丢失,
? 多媒体也称,连续媒体（
continuous media） /流媒体
”
多媒体应用的分类,
? 存储式的 audio/video流媒体
? 直播式的 audio/video流媒体
? 实时交互式的 audio/video
7a-3主讲人,西安交通大学 程向前 第 7讲 多媒体网络
网络中的多媒体 (2)
存储式流媒体
? 客户端从服务器请求
audio/video文件，以流水方
式从网络上进行接收并显示
? 交互, 用户可进行操作 (如同
操作录像机, 暂停,恢复播放
,快进,回退,etc.)
? 延迟, 从客户端发出请求到
开始播出为 1～ 10秒
实况转播（单向实时）,
? 如同 TV 和无线广播,但是从
因特网上传送
? 非交互,只是收视 /收听
实时交互,
? 电话或视频会议
? 由于实时特性，比流媒体点播和
实况转播要求更为严格
? Video,< 150 ms尚可
? Audio,< 150 ms比较好,
<400 ms可以接受
7a-4主讲人,西安交通大学 程向前 第 7讲 多媒体网络
网络中的多媒体 (3),挑战
? TCP/UDP/IP 协议族提供的
是尽力而为,无延迟或延迟变
动承诺的服务,
? 流媒体的应用有 5-10的延
迟今天看来十分普遍,但当链
路 (越洋线路 )拥塞时，情况
会急剧恶化
? 实时交互应用对分组延时和
抖动（ jitter） 具有严格的
限制,
? 抖动（ Jitter）是指在同一
分组流传输过程中发生的分
组延时变化,
? 如果在因特网中能分出服务
级别，那么多媒体应用的设
计将要容易的多,
? 但是在公共因特网中,所有分
组所受到的服务完全是相等
的,
? 包含实时交互 audio和 video
数据分组在网络中所受到的
待遇,和其他分组完全一样,
? 目前对在因特网中提供区别
对待的服务的研究一直在进
行之中,
7a-5主讲人,西安交通大学 程向前 第 7讲 多媒体网络
网络中的多媒体 (4),
将尽力而为的服务用到极致
为减少“尽力而为”的因特网的
服务原则的影响，我们可以,
? 使用 UDP来避免 TCP和它的慢
启动过程 …
? 在客户端缓存部分内容和控
制回放来弥补传输抖动造成
的影响
? 我们可以给分组加上时间戳
来提醒接收端及时回放该分
组,
? 选择压缩等级来适配可用贷
款
? 我们还可以发送冗余的分组
来减少分组丢失所造成的影
响。
? 我们将讨论这些,雕虫小技
”
7a-6主讲人,西安交通大学 程向前 第 7讲 多媒体网络
因特网应如何进化才能更好的支持多媒体?
集成服务（ Intserv） 的哲学,
? 改变因特网协议以便应用程序
能够预定端对端的带宽
? 需要部署协议来预留带宽
? 必须修改路由器的调度策略来
响应带宽预留
? 应用程序必须体为网络提供信
息流量的描述,并进而遵循这
样的描述,
? 在主机和路由器中开发新的更
复杂的软件
区别服务（ Diffserv） 的哲学,
? 对因特网的基础结构进行改
造,使其可以提供分级的服务
.
? 分组要加标记
? 用户为高级别的服务付出更
多的费用,
? ISP为骨干网络收发高级别的
分组付出更多的费用,
7a-7主讲人,西安交通大学 程向前 第 7讲 多媒体网络
因特网应如何进化才能更好的支持多媒体?(续 )
自由放任 ( Laissez-faire )哲学
? 没有带宽预定,不搞分组标记
? 只要需求增加,供应更多的带
宽
? 将存储内容置于网络的边缘,
? ISP和主干上增加缓存
? 内容提供商将内容置于
CDN 结点
? P2P,选择临近的存储有内容
的对等结点
虚拟专网 (VPN)
? 为企业保留永久性的带宽域 (
blocks of bandwidth）,
? 路由器可以根据 IP 地址来识
别 VPN的信息流
? 路由器使用特殊的调度策略
来提供预留的带宽,
7a-8主讲人,西安交通大学 程向前 第 7讲 多媒体网络
存储式 Audio & Video流
存储式流媒体,
? Audio/video 文件存储在服
务器上
? 用户根据需求调用
audio/video 文件,
? Audio/video 在请求的 10秒
以内提供,
? 提供交互性 (暂停,重新定位
等,etc.).
媒体播放器（ Media player）,
? 消除抖动
? 解压缩
? 错误校正
? 提供图形交互界面进行控制
? 可以使用插件（ Plug-in）将
媒体播放器植入浏览器窗口,
7a-9主讲人,西安交通大学 程向前 第 7讲 多媒体网络
从 Web服务器调用流媒体 (1)
? Audio和 video文件存储在
Web服务器上
最原始的方法
? 浏览器使用 HTTP请求报文从
Web服务器访问流媒体文件
? Web服务器用 HTTP响应报文
发送文件
? content-type 首部行描述了
audio/video的编码
? 浏览器启动媒体播放器,并将
文件传递给它
? 媒体播放器解读该文件
? 主要缺点,
媒体播放器通过浏览器作为中介
与 Web 服务器交互
7a-10主讲人,西安交通大学 程向前 第 7讲 多媒体网络
从 Web服务器调用流媒体 (2)
改进, 在服务器和播放器之间建
立连接
? 浏览器请求和接收元文件（
meta file ） (用来描述对象
的文件）而不是接收文件本
身 ) ;
? Content-type首部说明是特
定的 audio/video应用
? 浏览器启动媒体播放器并将
元文件传递给它
? 播放器与服务器建立 TCP 连
接并发送 HTTP请求,
问题讨论,
? 媒体播放器使用 HTTP通信,
没有 pause,ff,rwnd 功能
? 可以考虑使用 UDP通信
7a-11主讲人,西安交通大学 程向前 第 7讲 多媒体网络
从流媒体服务器调用流媒体
? 该结构可以使用非 HTTP协议
进行通信在服务器和流媒体
播放器之间进行通信
? 可以使用 UDP来替代 TCP.
7a-12主讲人,西安交通大学 程向前 第 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 互
相向对方发送控制信息
7a-13主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTSP,带外控制 -out of band control
FTP 使用了,带外”的控制通道,
? 文件传输通过一个通道
? 控制信息 (cd,rm,mv,
etc.) 则通过分离的 TCP连接
发送,
?,带外,和,带内, 通道使用
不同的端口号,
RTSP 报文也使用带外通道传送
:
? RTSP控制报文使用的端
口号与媒体流使用的不
同，所以是带外传递,
? 流媒体的分组结构不是
由 RTPS定义的，因此被
认为是在“带内”传输
的,
? 如果 RTSP报文使用与流媒体
相同的端口号,RTSP将与流
媒体一起“间隔”传送,
7a-14主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTSP 启动和控制传递
? 首先客户端获取多媒体的表示方式描述,
这可以由若干媒体流组成,
? 浏览器个根据表示方式所描述的内容类型调用媒体播放器 (辅助的应用程序 -
helper application).
? 表示描述中使用 URL方法 rtsp:// 将媒
体流包含在内
? 播放器发送 RTSP SETUP请求 ; 服务器
发送 RTSP SETUP响应,
? 播放器发送 RTSP PLAY 请求 ;服务器
发送 RTSP PLAY 响应,
? 媒体服务器“泵出”流媒体,
? 播放器发送 RTSP PAUSE请求 ;服务器
发送 RTSP PAUSE响应,
? 播放器发送 RTSP TEARDOWN请求 ;
服务器发送 RTSP TEARDOWN响应,
HT T P G E T
S E T UP
P L A Y
m e d ia strea m
P A USE
T E A RD OW N
me dia
pla y e r
W e b
s e rv e r
me dia
s e rv e r
W e b
brow s e r
c li e nt s e rv e r
p rese n ta tio n d e sc.
7a-15主讲人,西安交通大学 程向前 第 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">
<track type=audio
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>
7a-16主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTSP会话
? 每次 RTSP 都会有由服务器
选择的会话定义符,
? 当客户端用 SETUP请求启动
会话，服务器就会使用定义
符来进行响应,
? 在随后的过程中，客户端反
复在每个请求中都使用该定
义符,直到客户端使用
TEARDOWN请求来结束会
话,
? RTSP 端口号为 554.
? RTSP 报文可以通过 UDP或 TCP
发送, 每个 RTSP 报文可以通过
一个分离的 TCP 连接进行,
7a-17主讲人,西安交通大学 程向前 第 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
Session,4231
Range,npt=37
C,TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi
RTSP/1.0
Session,4231
S,200 3 OK
7a-18主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTSP,流媒体的缓存
? 对 RTSP响应报文的缓存没有
太大的意义,
? 但希望将媒体流缓存在客户
端的邻近处,
? 大部分 HTTP/1.1的缓存控
制机制也被 RTSP采用,
? 缓存的控制首部可以用于
RTSP SETUP 请求和相
应,
? If-modified-since,
,Expires:,Via:,
Cache-Control,
? 对给定的流媒体来说代理缓
存只能按数据段的形式保持,
? 代理缓存可以从本地缓存
中取出部分数据进行服务
,而然后必须同原始服务
器连接来填充部分丢失的
资料,但愿不要在客户端
造成传输中断,
? 从原始服务器传回的流媒体
将通过代理传到客户端,代
理可以使用 TCP来获取流媒体; 但代理服务器还是把 RTSP
控制报文发给了原始服务器,
7a-19主讲人,西安交通大学 程向前 第 7讲 多媒体网络
实时交互式应用
? PC-2-PC phone
? PC-2-phone
? Dialpad
? Net2phone
? 视频会议
? Webcams
? 现在来研究 PC-2-PC IP 电话的
案例
7a-20主讲人,西安交通大学 程向前 第 7讲 多媒体网络
使用“尽力而为服务”的 IP电话 (1)
Best effort model
? packet delay,loss and
jitter
IP 电话举例
? 现在对分组延迟、丢失、和
抖动对电话内容所造成的影
响进行分析,
? IP 电话应用程序在对话期间
产生分组
? 谈话期间的数据产生的速率
为 64 kb/s
? 在交谈期间,每 20 ms应用
程序将产生 160字节 (
8 kB/s * 20 ms )的数据块
? 数据块加上首部 ; 然后封装
入 UDP分组并发送
? 某些分组的丢失和延迟会给
传输造成“起伏
(fluctuate)”.
? 受话方必须确定何时将数据
块进行播放，如何处理缺失
的数据块
7a-21主讲人,西安交通大学 程向前 第 7讲 多媒体网络
IP 电话 (2)
分组丢失
? UDP 段封装在 IP 分组中
? 分组在路由器队列中可能溢
出
? TCP 虽然可以消除数据丢失,
但是
? 重发会增加延迟
? TCP 的拥塞控制会降低速率
? 增加冗余分组会有帮助
端对端的延迟
? 为发送、传播、排队延迟的
总和
? 端对端的延迟一旦超过 400
ms将严重影响交互性 ; 这种
延迟越小越好
延迟抖动 (delay jitter)
? 考虑交谈期间两个连续的语
音分组
? 在发送端初始间隔为 20 ms,
但到达受话方时，间隔可能
发生变化 (>20ms;<20ms)
消除抖动 (removing jitter)
? 编顺序号码
? 时间戳 (timestamps)
? 延迟播出 (delaying playout)
7a-22主讲人,西安交通大学 程向前 第 7讲 多媒体网络
IP电话 (3),固定的播放延迟
? 受话方试图在数据块产生的 q
ms后播出,
? 如果数据块有时间戳 t,受
话方将在 t+q以后将数据播
出
? 如果数据块在 t+q以后到达,
受话方将予以丢弃,
? 顺序编号没有必要,
? 对丢失的分组需要采取策略,
? Q的取值问题,
? large q,分组丢失较少
? small q,较好的交互性能
7a-23主讲人,西安交通大学 程向前 第 7讲 多媒体网络
IP 电话 (4):固定的播放延迟
? 发送方在交谈期间每隔 20 ms产生分组,
? 首个分组在时间 r到达
? 第一种播放策略, 在 p点开始
? 第二种播放策略：在 p’ 点开始
pac k et s
t im e
pac k e ts
gene ra ted
pac k e ts
re c e iv e d
los s
r
p p'
pla y out s c hedule
p - r
pla y out s c hedule
p' - r
7a-24主讲人,西安交通大学 程向前 第 7讲 多媒体网络
从数据丢失中恢复 (1)
? 数据丢失, 分组没有到达或比
其计划中播出时间迟到
前向纠错 ( forward error
correction, FEC),简单机
制
? 以 n个数据块为一组，为每一
组创建一个冗余块，该块的形
成是通过对这 n个原始块的异
或（ xor）而得
? 发送这 n+1 个块（ chunks）,
增加了 1/n的带宽,
? 如果从该 n+1块里丢失的块最
多只有一个的话，该块可以重
新构建
? 播出延迟必须限定在这对 n+1
分组的接收时间里
? 折衷,
? 加大 n,带宽浪费较小些
? 加大 n,较长的播出延迟
? 加大 n,出现 2个或 2个以上
分组丢失的概率增加
7a-25主讲人,西安交通大学 程向前 第 7讲 多媒体网络
从数据丢失中恢复 (2)
第二种 FEC 机制
?,捎带低品质流媒体,
? 发送低分辨率的媒体流
作为冗余信息
? 例如,一般流媒体的音
频的 PCM 为 64 kb/s而冗
余的 GSM为 13 kb/s.
? 发送端从正常流媒体的
第 n个数据块与（ n-1）数
据块中创建冗余流媒体附
加上一起发送,
? 只要数据丢失不是连续的，受话端可以对数据丢失
进行补偿,
? 在开始播放前只要收到两个分组即可开始
? 为应付连续的数据丢失，也可以附加 (n-1)和 (n-2)
的冗余数据块
7a-26主讲人,西安交通大学 程向前 第 7讲 多媒体网络
从数据丢失中恢复 (3)
交错（ interleave ）
? 数据块被分割成较小的单元
? 例如,4～ 5 ms一个数据块
? 将数据块如图交错传送
? 分组将携带来自不同数据块
的较小的数据单元
? 在受话方重新装配数据块
? 如果分组丢失,但大部分数
据块仍然存在
7a-27主讲人,西安交通大学 程向前 第 7讲 多媒体网络
从数据丢失中恢复 (4)
在受话方对受损的音频流进行修
复
? 产生一个类似原始替代数据
来替代丢失的分组
? 重复：对于较小的分组 (4-40
ms)和低丢失率可表现出良好
的性能
7a-28主讲人,西安交通大学 程向前 第 7讲 多媒体网络
实时协议 ( Real-Time Protocol,RTP)
? RTP定义了携带 audio /
video数据的分组结构, RFC
1889.
? RTP 分组提供
? 负荷类型定义
? 分组顺序编号
? 时间戳
? RTP 在端系统中运行,
? RTP 分组被封装在 UDP数据
段中
? 互操作性（ Interoperability
）, 如果 两个 IP 电话应用程
序都运行 RTP,那么它们就有
可能一起工作
7a-29主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTP 运行在 UDP之上
RTP 库提供了传输层接口来扩展 UDP,
?端口号,IP地址
?跨段的错误校验
?负荷类型标记
?分组顺序编号
?时间戳
7a-30主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTP 举例
? 回顾发送 64 kb/s PCM-编
码的语音通过 RTP,
? 应用程序采集已经编码的数
据块,e.g.,每 20 ms = 160
字节的数据块,
? 音频 数据块和 RTP首部形成
RTP 分组,被封装入 UDP数
据段,
? RTP首部说明每个分组的音
频类型 ; 发送端可以在会议
期间改变编码, RTP首部同样
包含了顺序号和时间戳,
7a-31主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTP 和 QoS
? RTP 不承诺提供任何实时传
递和 服务质量 保证,
? RTP 封装仅仅可以在端系统
进行 –与中间的路由器没有
关系,
? 路由器的作用还是完成传统
的尽力而为的服务，而对
RTP分组的传递没有任何实
时性促进的作用,
? 要为应用程序提供 QoS,因
特网必须要提供其他 的机制
,例如 RSVP,为 应用程序预
留网络资源,
7a-32主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTP 媒体流
? RTP 允许每个信源 (例如,一
台摄像机或一个麦克风 )赋以
各自的独立的 RTP分组流,
? 例如,对有两个参与者的得视
讯会议,要打开 4个 RTP流,
两个用于传输音频 (一个方
向一个 ) 和两个视频流 (同
样,一个方向一个 ),
? 但是,一些常用的编码技术 –
包括 MPEG1和 MPEG2 – 在
编码过程中将音频和视频合
成一个流媒体, 这种情况下
，在每个方向上只需一个
RTP流,
? 对于一场 many-to-many的
组播会话来说,所有的发送
方和信源一般将 RTP流依据
同样的组播地址送入同一组
播树
7a-33主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTP 首部
Payload Type (7 bits),说明传输分组的编码类型,
如果在会议过程中发送端改变编码类型，则通过 payload type字段通知接受端,
?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分组递增,可用于
测试数据丢失和恢复失序的分组,
7a-34主讲人,西安交通大学 程向前 第 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.
7a-35主讲人,西安交通大学 程向前 第 7讲 多媒体网络
实时控制协议 (Real-Time Control Protocol
,RTCP)
? 与 RTP协同工作,
? 每个在某个 RTP会话中的参
与者都要周期性的传输 RTCP
控制分组给所有其它所有的
参与者, 每个 RTCP分组都包
含了发送端和 /或接收端的统
计报告，对应用层有用
? 统计数据包括分组发送数量
、分组丢失数量、分组到达
的间歇抖动等,
? 这种反馈信息可用于控制应
用程序的性能和进行诊断,
? 发送方可根据反馈信息修改
传输参数（ The sender
may modify its
transmissions based on
the feedback）,
7a-36主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTCP – (续 )
- 一般典型的 RTP会话都有一个组播 (multicast)地址 ; 所有的 RTP
和 RTCP 分组只要同属该会话，就是使用该组播地址,
- RTP 和 RTCP分组可使用不同的端口号来相互区别,
- 为限制数据流量,当参与者增加时，每各与会者都会减少 RTCP数据的发送,
7a-37主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTCP 分组
接收端报告分组,
? 丢包比率,最后收到的分组,
平均间隔的抖动,
发送端报告分组,
? RTP流中的 SSRC,当前时间
,已经发送的分组数量,和发
送的字节数量,
信源描述分组,
? 发送端的 e-mail地址,发送端
的名称,相关 RTP流的 SSRC
,分组提供了 SSRC和用户 /
主机间的 映射,
7a-38主讲人,西安交通大学 程向前 第 7讲 多媒体网络
流媒体的同步问题
? RTCP可以协调同一会话中的
不同流的同步,
? 考虑一下视讯会议，应用程
序对视频流和音频流分别产
生一个 RTP数据流,
? 在两个媒体流中都携有时间
戳是来自采样时钟，而不是
来自墙上的挂钟 (i.e.,to
real time),
? 每个 RTCP发送端报告分组包
括,在相关 RTP流中最近产生
的分组中,RTP分组的时间戳
和分组创建的真实时间, 这
样 RTCP发送端报告分组将
采样时钟和真实时间联系在
一起,
? 接收端可以依据这种联系来
同步音频和视频播出,
7a-39主讲人,西安交通大学 程向前 第 7讲 多媒体网络
RTCP带宽分配 (Bandwidth Scaling)
? RTCP试图将其占用的带宽
限制在 5%的会话带宽以下,
? 例如,假设一个发送端以 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分组的传输周期
,
7a-40主讲人,西安交通大学 程向前 第 7讲 多媒体网络
H.323
?概述
?H.323 终端
?H,323 编码
?网守 (Gatekeeper)
?网关 (Gateway)
?Audio 编码机制
?Video 编码机制
7a-41主讲人,西安交通大学 程向前 第 7讲 多媒体网络
概述 (1)
? 在 IP网络上进行音频和
视频会议的基础,
? 定位于实时通信 (而不是
存储式流媒体 )
? 兼顾 ITU的通信标准,
? 覆盖的范围,
?独立设备 (如,Web
电话,Web 电视 )
?PC应用程序
?点对点和多点视讯会
议
? H.323 定义包括,
? 终端如何启动 /接受呼叫
? 终端间如何使用通用
audio/video编码,
? Audio和 video数据如何进
行封装和发送,
? Audio和 video如何同步
(lip-sync).
? 终端如何同各自的网守程
序（ gatekeeper） 通信
? IP电话如何与 PSTN
/ISDN 电话通信,
7a-42主讲人,西安交通大学 程向前 第 7讲 多媒体网络
概述 (2)
? Telephone calls
? Video calls
? Conferences
? Whiteboards
所有支持 H.323的终端
I n te r n e t
" E t h e r n e t" p h o n e
M S N e t m e e t in g
N e tS p e a k W e b P h o n e
7a-43主讲人,西安交通大学 程向前 第 7讲 多媒体网络
概述 (3)
H.323 SS7,Inband
I n te r n e t P ST N
G at ew a y
G at ek ee p er
7a-44主讲人,西安交通大学 程向前 第 7讲 多媒体网络
H.323端接点必须支持,
?G.711 - ITU 语音
压缩标准
?RTP – 将媒体数据块
封装成分组的协议
?H.245 -,带外” 控
制协议用于控制
H.323终端 间的流媒
体传输,
?Q.931 – 用于建立 /
结束连接的信令协议
?RAS (Registration/
Admission/Status)
信道协议 – 与网守
程序进行通信的协议
(如果存在网守 -
gatekeeper)
7a-45主讲人,西安交通大学 程向前 第 7讲 多媒体网络
H.323 终端
7a-46主讲人,西安交通大学 程向前 第 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的整
倍数,
7a-47主讲人,西安交通大学 程向前 第 7讲 多媒体网络
产生 H.323中的音频数据流
Audio
Source
Encoding:
e.g.,G.711
or G.723.1
RTP packet
encapsulation
UDP
socket Internet orGatekeeper
7a-48主讲人,西安交通大学 程向前 第 7讲 多媒体网络
H.245控制通道
?H.323 媒体流可以
包含若干信道来传输
不同类型的媒体数据
?每个 H.323会话有一
个 H.245 控制信道
?H.245 控制信道是
一个可靠的 (TCP)
信道
?主要任务,
?开闭媒体信道
?能力信息交换,在
发送流媒体之前,
通信终端对它们之
间的编码 /算法协
商一致
7a-49主讲人,西安交通大学 程向前 第 7讲 多媒体网络
信息流
H, 3 2 3
T e r m i n a l
H, 3 2 3
T e r m i n a l
M e d i a C h a n n e l
1
M e d i a C o n t r o l
C h a n n e l
M e d i a C h a n n e l
2
C a l l S i g n a l i n g
C h a n n e l
C a l l C o n t r o l
C h a n n e l
H, 3 2 3
G a t e k e e p e rR A S C h a n n e l
TC P
U D P
7a-50主讲人,西安交通大学 程向前 第 7讲 多媒体网络
网守 (Gatekeeper) 1/2
?网守 是任选的 H.323模块 /设备,可以给端点提供,
?负责,别名,与 IP地址的转换
?带宽管理, 可以限制实时会议所消耗的带宽
? 作为可选功能,H.323呼叫可以被引导通过 网守,对计费有用,
? RAS协议 (over TCP)负责端点 -网守 间的通信
H.
32
3 t
erm
ina
ls
Gatekeeper
Router
Internet
LAN =,H.323 Zone”
RAS
7a-51主讲人,西安交通大学 程向前 第 7讲 多媒体网络
网守 (Gatekeeper) 2/2
? H.323终端必须在网守
的辖区内注册,
?当 H.323 应用程序
在终端上调用时,该
终端使用 RAS 给网
守发送其 IP地址和 (
用户提供的 )别名,
? 如果区内有网守存在,
每个区内的终端必须与
网守联系并获取呼叫许
可,
? 一旦获得许可,终端将
给网守发送电子邮件地
址、别名字符串或电话
分机,网守将别名翻译成
IP 地址
?如有必要,网守将轮
询其他辖区中的网守
以解决 IP地址的解析
问题,处理过程如同
DNS,但具体做法因
厂商而异
7a-52主讲人,西安交通大学 程向前 第 7讲 多媒体网络
H.323 网关 (Gateway)
H.
32
3 t
erm
ina
ls
Gatekeeper
Router Internet
LAN =,H.323 Zone”
RAS
Gateway
PSTN
?是 IP区和 PSTN (or ISDN) 网络之间的桥梁,
?终端使用 H.245和 Q.931与网关进行通信
7a-53主讲人,西安交通大学 程向前 第 7讲 多媒体网络
Audio编码机制
Cod ec Ba n d w idt h
[kb it/s ]
M O S Com p le xi ty
[MIP S ]
P ac ke tiz ation
(f r ame si z e)
[m s]
G,7 11 64 4,5 - -
G,7 21 (A DP CM ) 32 4,4 6,5 -
G S M 13 3,8 4 20
G,7 29 8 4,1 15 10
G,7 23 6,4/ 5,3 4,0 20 30
T ol l q u al ity
r ec o gn iz e s p ea k e r
int el lig ibl e
int el lig ibi lity p r o b,
5
4
3
2
1
M O S ( M ea n O p ini o n S c or e )
MOS (Mean Opinion Score)
7a-54主讲人,西安交通大学 程向前 第 7讲 多媒体网络
Video编码机制
(128 x 96)
(176 x 144)
(352 x 288)
(704 x 576)
(1408 x 1152)
SQCIF
QCIF
CIF
4CIF
16CIF
? H.261 (p x 64 kb/s)
– ISDN上的视频流
– 分辨率, QCIF,CIF
? H.263 (< 64 kbit/s)
– 低传输速率通信
– 分辨率, SQCIF,QCIF,CIF,4CIF,
16CIF
