RDP ( Reliable Data Protocol )

RFC908 - Reliable Data Protocol
http://www.ietf.org/rfc/rfc0908.txt?number=908

RFC1151 - Version 2 of the Reliable Data Protocol (RDP)
http://www.ietf.org/rfc/rfc1151.txt?number=1151

可靠数据协议 RDP 是一种面向连接的传输协议，其主要设计来为主机监控应用程序如下载 / 上传以及远程调试进行有效的大批数据传输。RDP 尝试只提供那些必需的服务，达到操作有效、尺度小的效果。其主要功能如下：

• RDP 为每个传输层连接端口提供一个全双工通信信道；
• RDP 尝试可靠发送所有用户信息，一旦发送失败，将向用户报告错误。RDP 扩展 IP 数据报服务使之能够可靠发送；
• RDP 尝试侦测并删除所有损坏的和重复的数据段，它在数据段头使用校验码及序列号实现这一过程；
• RDP 随意地提供数据段序列发送，必须在连接建立时就指定数据段的序列发送；
• RDP 会响应确认序列之外的数据段，这会释放发送端的资源。

与 TCP 相比，RDP 所支持的功能更为简单。RDP 的流控制，缓冲以及连接管理模式都是相当简单的。RDP 的目标就是能够简单有效地执行并能适合一系列的应用程序。

RDP 函数集也可能是子集从而进一步减小特殊执行的大小。例如，一台向其它主机请求下载的目标处理器可能执行一个仅支持默认的开放式函数和单连接的 RDP 模块。这个模块也可能选择不执行非顺序响应确认。

协议结构

RDP 第二版协议头结构如下：

1	2	3	4	5	6	8	16bit
SYN	ACK	EAK	RST	NUL	0	Ver No	Header Length
SourcePort
DestinationPort
Data Length
Sequence Number
Acknowledgement Number
Checksum
Variable header area …

Control flags ― 8个控制位划分如下：

• SYN：SYN 位表示当前为同步段。
• ACK：ACK 位表示协议头有效的承认序号。
• EACK：EACK 位表示当前为扩展承认字段。.
• RST：RST 位表示该数据包为复位字段。
• NUL：NUL 位表示该数据包为空字段。
• 0：表示该字段的值必须设置为0。
• Ver no：版本号，当前版本号为2。

Header length ― RDP 协议头长度。

Source Ports ― 源地址，识别通信发生的过程。网络访问协议头中，源地址和目标地址的端口标识符的结合完全限定了连接并形成连接标识符。如此 RDP 可用于区分两台主机间的多连接。

Destination Ports ― 目标地址，识别通信中的目标过程。

Data Length ― 该字段中的数据长度（八位），该数据长度不包括 RDP 协议头。

Sequence number ― 该字段的序列号。

Acknowledgement number ― 如果 ACK 位设置在协议头部，这就是字段序列号，即该字段发送端最后正确按序列接收的顺序。一旦连接成功，就应该发送该字段。

Checksum ― 检验和确保完整性。

Variable Header Area ― 用于传输 SYN 和 EACK 字段的参数。

DHCP+

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
IP 宽带接入网中的几种认证技术：

PPPoE技术
PPPoE（PPP over Ethernet）为IETF RFC2516标准协议，是从基于ATM的窄带网引入到宽带以太网的，实现在Ethernet上传输封装PPP报文，由于IP包和PPP报文不兼容，必须有专门的设备终结PPP报文并转换为IP报文，这种设备就是BRAS。用户与BRAS设备之间PPPoE通信过程包含两个阶段：PPPoE发现阶段和PPP会话阶段，发现阶段是无状态的Client/Server模式，目的是获得PPPoE终结端的以太网MAC地址，并建立一个唯一的PPPoE SESSION_ID。发现阶段结束后，就进入标准的PPP会话阶段。一旦PPPoE会话开始，PPP数据就可以像其它的PPP封装形式一样发送。

802.1X技术
802.1X为IEEE Std 802.1X-2001基于端口的访问控制协议，可以克服PPPoE方式带来的诸多问题，并避免引入宽带接入服务器所带来的巨大投资。802.1X协议限制未经授权的用户/设备通过接入端口访问LAN/WAN。在获得交换机或LAN提供的各种业务之前，802.1x对连接到交换机端口上的用户进行认证。在认证通过之前，802.1x只允许EAPoL(基于局域网的扩展认证协议)数据通过设备连接的交换机端口；认证通过以后，正常的数据可以顺利地通过以太网端口。

DHCP+技术

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

DHCP+接入认证技术是一种基于DHCP协议通过控制终端用户的IP地址分配实现控制用户接入的认证鉴权技术，DHCP+目前尚处于发展初期阶段，尚未推出正式的标准。常见于PPPoE接入认证方式受限的场合，例如BTV业务应用场合。

DHCP协议是DHCP+接入认证技术的基础，它是RFC组织定义的一种标准，采用客户机－服务器工作机制，实现客户机向服务器请求分配IP地址的流程。 为了解决对用户进行有效的接入认证控制问题和提高接入网络的安全性，DHCP+接入认证技术在网络安全、网络监控以及用户控制和终端识别等方面对DHCP 协议进行了扩展。

网络安全方面，在报文入接口通过对报文匹配DHCP Snooping绑定表项，防止了IP盗用、用户私接、DHCP Server仿冒、IP/MAC Spoofing攻击、DoS（Deny of Service）攻击，规避了DHCP协议的安全缺陷。

网络监控方面，通过对丢弃的非法报文分别计数，在网管系统的配合下，实现针对各种攻击的阀值告警分别输出，提高运维部门的故障定位和解决效率，以降低运营成本。

用户控制方面，DHCP PS（DHCP Policy Server）通过建立基于用户物理位置信息的本地数据库，对用户进行认证控制。所谓用户物理位置信息就是标识用户所在的设备、端口以及QinQ双层标签 信息，当然，所谓用户是用一个或多个MAC地址来识别的。用这种方法限制了私拉盗接和用户串用等问题，从而减轻了运维压力，保护了合法用户的权益，为营运 增收提供可能。

此外，可在DHCP+报文中引入多个灵活的Option字段，满足不同场合的用户需求。例如对于存在多个终端同时使用DHCP的场合，在DHCP +报文中引入Option60以区分终端类型。DHCP PS通过识别Option60选项实现对不同的终端分配不同的地址空间功能。

图-1显示了DHCP+用于城域网接入认证的应用场景。在此解决方案中，Internet业务以原有PPPoE方式通过BRAS设备接入， VoIP、VoD、BTV等业务以DHCP+认证方式接入用户。我们以BTV业务为例，分析一下DHCP+接入认证技术是如何实现在认证和安全方面的上述 功能的。

基于DHCP+接入认证技术的BTV组播接入过程

首先我们了解一下城域网中针对BTV业务的配置情况，自家庭网关传送到DSLAM上的BTV组播业务的PVC，在DSLAM设备上全部映射到组播VLAN 中，在UPE上终结IGMP报文，然后在UPE和NPE以及核心层部署组播路由协议PIM-SSM或者PIM-SM/DM。在UPE设备上配置DHCP Relay功能、DHCP Snooping功能、Option82功能以及相应的报文检查功能，在DSLAM设备上如果功能支持也可以配置DHCP Snooping功能、Option82功能。

客户享受组播服务之前，STB通过两次握手，向DHCP PS申请IP地址的过程：

1、客户端广播DHCP Discover报文，以发现DHCP PS，UPE依据DHCP Snooping功能捕获此报文，并插入Option82，然后把报文中继到DHCP PS。Option82是DHCP报文中的一个选项字段，它携带了DHCP请求报文入端口信息、QinQ双层标签以及UPE设备名称等信息，此选项内容因 生产厂家而略异。如果DSLAM设备配置上述功能，Option82在DSLAM设备插入，则在UPE上通过配置可以重新插入自己的Option82信 息，也可以直接透传DSLAM设备上的Option82信息。

2、DHCP PS收到报文后，通过读取Option82信息分离出其中的设备端口信息、QinQ双层标签等标识用户物理位置的信息，然后将此信息与DHCP PS上的用户数据库相应信息比较。不一致，则DHCP PS不做任何响应；一致，则DHCP PS回送一个DHCP Offer报文。其中含有一个IP地址和携带原有Option82信息，其中的数据库信息是运营商开户时根据用户所在设备端口、QinQ双层标签信息录入 的，供DHCP PS认证用户的数据。

3、此报文通过UPE时，被剥离Option82，从相应的Vlan和端口送出，STB收到后，广播DHCP Request报文，以通知其它未选中的DHCP PS和询问被选中的DHCP PS其它的配置选项，如DNS、网关地址等。

4、此报文在UPE上同样做Option82插入处理并向DHCP PS中继，DHCP PS收到此报文后，将回送一个DHCP ACK报文，其中包括用户IP、网关、DNS等配置信息以及IP租约信息，并携带Option82信息。

5、UPE收到此报文，剥离Option82信息后向STB转发此报文，同时根据报文内容和Option82完成建立DHCP+ Snooping绑定表项。STB收到DHCP ACK报文后，广播一个免费ARP报文，确认自己使用的IP地址没有与其它用户冲突后，开始使用此IP地址，与此同时在DHCP PS上根据配置决定是否将该用户的MAC地址和其用户数据库信息绑定，作为用户再次接入的认证条件。

至此用户与DHCP PS的报文交互完成，客户终端开始发送IGMP请求报文，申请加入组播组，加入成功后，组播业务流开始接入到BTV客户终端。

另外，DHCP+接入认证技术也可以用于运营商的园区网和大客户接入场合，组网模式如图-2所示，其中核心设备可以是三层或者二层交换机，接入过程和原理 与上述相同。用户认证接入之后通过防火墙NAT功能访问Internet和享受其它服务，用于满足小区宽带业务经营者需求、集团用户的个性化需求，也给用 户接入和安全互访带来便利。

DHCP PS对接入用户的控制

DHCP PS在收到自客户终端的DHCP Discover报文后，将依据报文中Option82描述的UPE设备、所在端口、QinQ双层标签信息与开户时录入的用户物理位置数据库信息对照，根 据结果进行下一动作，用户再次认证上线时，DHCP PS将根据用户MAC和录入的用户物理位置数据库信息唯一标识用户。DHCP PS用这种方法对用户做接入权限认证，防止用户私接盗用问题，增强用户控制。如图-1中红色箭头所示，同一个用户从UPE/DSLAM/LAN设备的不同 Vlan接口接入被拒绝分配IP地址，不同的用户从相同UPE/DSLAM/LAN设备Vlan接口接入也被拒绝分配IP地址。

在UPE/LAN上建立DHCP+ Snooping绑定表项内容如表-1所示（各厂家内容略有不同）。其中接口信息正是分析DHCP+ ACK报文中Option82获取的。

Mac addr	IP addr	Lense（s）	Type	Outside-Vlan	Inside-Vlan	Interface
00:02:98:F4:D2:C1	10.110.98.75	060820-1050	STATIC	100	1100	Ethernet4/0/0

表-1 DHCP+ Snooping绑定表

DHCP+接入认证技术应对攻击策略

在采用传统DHCP协议时，用户和服务器可能面临各种各样的攻击和仿冒，DHCP+接入认证技术根据不同攻击类型，提供不同应对策略，见表-2。

攻击类型	DHCP+接入认证技术防攻击策略
DHCP Server仿冒者攻击	端口上设置信任(Trusted)和不信任(Untrusted)工作模式
中间人攻击	通过DHCP Snooping绑定表对攻击报文匹配过滤
IP/MAC Spoofing攻击	通过DHCP Snooping绑定表对攻击报文匹配过滤
改变CHADDR值的DoS攻击	检查DHCP报文的CHADDR字段

表-2 攻击类型与防攻击策略对应表

所谓DHCP Server仿冒攻击，就是DHCP Server仿冒者通过UPE的其它业务端口发送DHCP Responses （offer、ack、nak）报文给DHCP Client，使其获取错误的IP、网关地址等，达到DoS（Deny of Service）的目的。DHCP+接入认证技术通过仅在接到DHCP PS方向的接口上设置DHCP Snooping“信任”模式，对于“不信任”端口上收到的DHCP Responses报文将直接丢弃，以此达到隔离DHCP Server仿冒者的目的。

中间人攻击是指中间人向客户端发带有自己MAC和服务器IP的报文，又同时向服务器发带有自己MAC和客户端IP的报文，最终使客户端和服务器分别学到自 己的IP和MAC，使服务器发到客户端的报文都会经过中间人。IP/MAC Spoofing攻击是指攻击者向服务器发送带有合法用户IP和MAC的报文，使服务器误以为已经学到这个合法用户的IP和MAC，但真正的合法用户不能 从服务器获得服务。为隔离中间人攻击与IP/MAC Spoofing攻击，DHCP+接入认证技术使用UPE设备上生成的DHCP Snooping绑定表对接口收到的报文进行检查。如果接口收到ARP或者IP报文，就用报文中的“源IP+源MAC”去匹配DHCP Snooping绑定表，如果绑定表中没有匹配项就丢弃该报文，否则正常转发，通过这样匹配方式，不仅可以防止上述攻击，也防止了设置静态IP的用户和 IP盗用者。

对于DHCP饿死攻击（所谓饿死攻击是指攻击者通过不断变换用户物理地址，尝试申请DHCP域中所有的IP地址，以耗尽DHCP Server地址池资源，导致其他正常用户无法获得地址，达到DoS的目的。），我们可以在DSLAM/LAN端口上设置MAC Limit数量来限制此类攻击。但攻击者倘若改变的不是数据帧头部的源MAC，而是改变DHCP报文中的CHADDR（Client Hardware Address）值来不断申请IP地址。那么“MAC地址限制”方案显然是行不通的。为保证业务的安全性，DHCP+接入认证技术检查DHCP Request报文中CHADDR字段。如果该字段跟数据帧头部的源MAC相匹配，便转发报文；否则，丢弃报文，有效阻止这类攻击。

DHCP+接入认证技术的客观局限性

DHCP+接入认证技术优势主要体现在其组播支持方面。众所周知，组播复制点越接近用户越能节省带宽，而组播复制点一般部署在二层和三层网络的分界线。这 就意味着DHCP+接入认证技术组播优势要充分体现，城域网络必须是三层路由到边缘的组网模式。倘若将来视频分发以P2P技术为主，其组播优势便无用武之 地。

DHCP+接入认证技术尚处于其发展初期阶段，协议相关标准还没有最终制定，厂家之间的实现标准尚不统一，使其进一步发展完善受限。DHCP+接入认证技 术目前仅仅适用于包月制收费方式，很难做到根据流量和时长进行计费，从而对用户的不可控因素较多，Internet业务的Wholesale销售模式也难 以进行，这些都是任何运营商所不愿看到的。而且由于其开放性特点，其接入的安全性尚需接受更多的验证和考验。

因而这种接入方式有很大局限性，目前阶段仅适用于小规模部署的部分业务，例如利用傻终端接入的BTV业务，并不能取代PPPoE实现其它业务类型的接入管理。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

DHCP+ 解决了PPPoE认证中的PPP包封装和隧道问题，适应IPTV等流媒体业务组播复制的需要。

组播复制问题实际上是组播复制点的选择问题。组播复制点即用户IGMP请求的终结点。在组播复制点，网络设备根据端口是否有IGMP请求向端口 复制组播流。组播复制点越接近用户越能节省网络带宽。由于传统的PPPoE的接入方式，使得组播复制点最低只能在BRAS设备上，在某些地市的城域网中， BRAS往往在汇聚层的层次位置，并下联了几千数量级的用户，这样高层次的组播复制点必然带来大量的重复流量，这本身是与组播协议的初衷相悖的。同时，虽 然BRAS经过多年的发展，性能上已经得到了长足的进步，但是如果需要BRAS设备能够支持到上千组播流的复制还是一个重大的挑战。因此，目前各运营商和 厂商均不推荐PPPoE+BRAS，这种方式已经不适合在IPTV承载网络上作为接入认证技术；而在IPTV的应用场景下以DHCP为基础扩展为接入认证 方式在IPTV的承载网络上显示出了蓬勃的生命力，并越来越被运营商普遍认可和接受。

RTSP

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
RFC2326 - Real Time Streaming Protocol (RTSP)
http://www.ietf.org/rfc/rfc2326.txt?number=2326

RFC2327 - SDP: Session Description Protocol
http://www.ietf.org/rfc/rfc2327.txt?number=2327

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

RTSP是由Real network 和Netscape共同提出的如何有效地在IP网络上传输流媒体数据的应用层协议。 实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体，如音频和视频。尽管连续媒体流与控制流交叉是可能的，RTSP 本身并不发送连续媒体流。换言之，RTSP 充当多媒体服务器的网络远程控制。RTSP 提供了一个可扩展框架，实现实时数据（如音频与视频）的受控、按需传送。数据源包括实况数据与存储的剪辑。RTSP 用于控制多个数据发送会话，提供了选择发送通道（如 UDP、组播 UDP 与 TCP 等）的方式，并提供了选择基于 RTP 的发送机制的方法。

目前还没有 RTSP 连接的概念；服务器维护由识别符标识的会话。RTSP 会话不会绑定到传输层连接，如 TCP。在 RTSP 会话期间，RTSP 客户端可打开或关闭多个对服务器的可靠传输连接以发出 RTSP 请求。它也可选择使用无连接传输协议，如 UDP。

RTSP 控制的流可能用到 RTP，但 RTSP 操作并不依赖用于传输连续媒体的传输机制。RTSP 在语法和操作上与 HTTP/1.1 类似，因此 HTTP 的扩展机制在多数情况下可加入 RTSP。然而，在很多重要方面 RTSP 仍不同于 HTTP ：

• RTSP 引入了大量新方法并具有一个不同的协议标识符：
• 在大多数情况下，RTSP 服务器需要保持缺省状态，与 HTTP 的无状态相对；
• RTSP 中客户端和服务器都可以发出请求；
• 在多数情况下，数据由不同的协议传输；
• RTSP 使用 ISO 10646 （UTF-8）而并非 ISO 8859-1，与当前的国际标准 HTML 相一致；
• URI 请求总是包含绝对 URI。为了与过去的错误相互兼容，HTTP/1.1 只在请求过程中传送绝对路径并将主机名置于另外的头字段。

该协议支持如下操作：

• 从媒体服务器上检索媒体：用户可通过 HTTP 或其它方法提交一个演示描述请求；
• 媒体服务器邀请进入会议： 媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录部分或全部演示；
• 将新媒体加到现有演示中：如服务器能告诉客户端接下来可用的媒体内容，对现场直播显得尤其有用。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

协议结构

RTSP 是一种文本协议，采用 UTF-8 编码中的 ISO 10646 字符集。一行可通过 CRLF 终止，但接收端需要做好解释 CR 和 LF 作为一行终止符的准备。关于头字段概述如下：

Header	Type	Support	Methods
Accept	R	opt.	entity
Accept-Encoding	R	opt.	entity
Accept-Language	R	opt.	all
Allow	R	opt.	all
Authorization	R	opt.	all
Bandwidth	R	opt.	all
Blocksize	R	opt.	All but OPTIONS, TEARDOWN
Cache-Control	G	opt.	SETUP
Conference	R	opt.	SETUP
Connection	G	req.	all
Content-Base	E	opt.	entity
Content-Encoding	E	req.	SET_PARAMETER
Content-Encoding	E	req.	DESCRIBE, ANNOUNCE
Content-Language	E	req.	DESCRIBE, ANNOUNCE
Content-Length	E	req.	SET_PARAMETER, ANNOUNCE
Content-Length	E	req.	entity
Content-Location	E	opt.	entity
Content-Type	E	req.	SET_PARAMETER, ANNOUNCE
Content-Type	R	req.	entity
CSeq	G	req.	all
Date	G	opt.	all
Expires	E	opt.	DESCRIBE, ANNOUNCE
From	R	opt.	all
If-Modified-Since	R	opt.	DESCRIBE, SETUP
Last-Modified	E	opt.	entity
Proxy-Authenticate
Proxy-Require	R	req.	all
Public	R	opt.	all
Range	R	opt.	PLAY, PAUSE, RECORD
Range	R	opt.	PLAY, PAUSE, RECORD
Referer	R	opt.	all
Require	R	req.	all
Retry-After	R	opt.	all
RTP-Info	R	req.	PLAY
Scale	Rr	opt.	PLAY, RECORD
Session	Rr	req.	All but SETUP, OPTIONS
Server	R	opt.	all
Speed	Rr	opt.	PLAY
Transport	Rr	req.	SETUP
Unsupported	R	req.	all
User-Agent	R	opt.	all
Via	G	opt.	all
WWW-Authenticate	R	opt.	all

类型 "g" 表示请求和响应中的通用请求头；类型 "R" 表示请求头；类型 "r" 表示响应头；类型 "e" 表示实体头字段。在 "support" 一栏中 标有 "req." 的字段 必须由接收者以特殊的方法实现；而 "opt." 的字段是可选的。注意，不是所有 "req." 字段在该类型的每个请求中都会被发送。 "req." 只表示客户机（支持响应头）和服务器（支持请求头）必须执行该字段。最后一栏列出了关于头字段产生作用的方法；其中 "entity" 针对于返回一个信息主体的所有方法。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

RTSP消息格式:

RTSP的消息有两大类 --- 请求消息(request), 回应消息(response)。

请求消息：
方法 URI RTSP版本 CR LF
消息头 CR LF CR LF
消息体 CR LF

其中方法包括OPTION回应中所有的命令,URI是接受方的地址,例如:rtsp://192.168.20.136。RTSP版本一般都是 RTSP/1.0。每行后面的CR LF表示回车换行，需要接受端有相应的解析，最后一个消息头需要有两个CR LF

回应消息：
RTSP版本 状态码 解释 CR LF
消息头 CR LF CR LF
消息体 CR LF

其中RTSP版本一般都是RTSP/1.0, 状态码是一个数值, 200表示成功, 解释是与状态码对应的文本解释.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

简单的rtsp交互过程:

C表示rtsp客户端, S表示rtsp服务端

1. C->S:OPTION request //询问S有哪些方法可用
1. S->C:OPTION response //S回应信息中包括提供的所有可用方法

2. C->S:DESCRIBE request //要求得到S提供的媒体初始化描述信息
2. S->C:DESCRIBE response //S回应媒体初始化描述信息，主要是sdp

3. C->S:SETUP request //设置会话的属性，以及传输模式，提醒S建立会话
3. S->C:SETUP response //S建立会话，返回会话标识符，以及会话相关信息

4. C->S:PLAY request //C请求播放
4. S->C:PLAY response //S回应该请求的信息

S->C:发送流媒体数据

5. C->S:TEARDOWN request //C请求关闭会话
5. S->C:TEARDOWN response //S回应该请求

上述的过程是标准的、友好的rtsp流程，但实际的需求中并不一定按部就班来。 其 中第3和4步是必需的！第一步，只要服务器客户端约定好，有哪些方法可用，则option请求可以不要。第二步，如果我们有其他途径得到媒体初始化描述信 息（比如http请求等等），则我们也不需要通过rtsp中的describe请求来完成。第五步，可以根据系统需求的设计来决定是否需要。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

rtsp中常用方法:

1. OPTION
目的是得到服务器提供的可用方法:
OPTIONS rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 1 //每个消息都有序号来标记，第一个包通常是option请求消息
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)

服务器的回应信息包括提供的一些方法,例如:
RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 1 //每个回应消息的cseq数值和请求消息的cseq相对应
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SCALE,GET_PARAMETER //服务器提供的可用的方法

2. DESCRIBE
C向S发起DESCRIBE请求,为了得到会话描述信息(SDP):
DESCRIBE rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 2
token:
Accept: application/sdp
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)

服务器回应一些对此会话的描述信息(sdp):
RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 2
x-prev-url: rtsp://192.168.20.136:5000
x-next-url: rtsp://192.168.20.136:5000
x-Accept-Retransmit: our-retransmit
x-Accept-Dynamic-Rate: 1
Cache-Control: must-revalidate
Last-Modified: Fri, 10 Nov 2006 12:34:38 GMT
Date: Fri, 10 Nov 2006 12:34:38 GMT
Expires: Fri, 10 Nov 2006 12:34:38 GMT
Content-Base: rtsp://192.168.20.136:5000/xxx666/
Content-Length: 344
Content-Type: application/sdp

v=0 //以下都是sdp信息
o=OnewaveUServerNG 1451516402 1025358037 IN IP4 192.168.20.136
s=/xxx666
u=http:///
e=admin@
c=IN IP4 0.0.0.0
t=0 0
a=isma-compliance:1,1.0,1

a=range:npt=0-
m=video 0 RTP/AVP 96 //m表示媒体描述，下面是对会话中视频通道的媒体描述
a=rtpmap:96 MP4V-ES/90000
a=fmtp:96 profile-level-id=245;config=000001B0F5000001B509000001000000012000C888B0E0E0FA62D089028307 a=control:trackID=0 //trackID＝0表示视频流用的是通道0

3.SETUP
客户端提醒服务器建立会话,并确定传输模式:
SETUP rtsp://192.168.20.136:5000/xxx666/trackID=0 RTSP/1.0
CSeq: 3
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)
//uri中 带有trackID＝0，表示对该通道进行设置。Transport参数设置了传输模式，包的结构。接下来的数据包头部第二个字节位置就是 interleaved，它的值是每个通道都不同的，trackID＝0的interleaved值有两个0或1，0表示rtp包，1表示rtcp包，接 受端根据interleaved的值来区别是哪种数据包。

服务器回应信息:
RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 3
Session: 6310936469860791894 //服务器回应的会话标识符
Cache-Control: no-cache
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=6B8B4567

4.PLAY
客户端发送播放请求:
PLAY rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 4
Session: 6310936469860791894
Range: npt=0.000- //设置播放时间的范围
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)

服务器回应信息:
RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 4
Session: 6310936469860791894
Range: npt=0.000000-
RTP-Info: url=trackID=0;seq=17040;rtptime=1467265309
//seq和rtptime都是rtp包中的信息

5.TEARDOWN
客户端发起关闭请求:
TEARDOWN rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 5
Session: 6310936469860791894
User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)

服务器回应:
RTSP/1.0 200 OK
Server: UServer 0.9.7_rc1
Cseq: 5
Session: 6310936469860791894
Connection: Close

以上方法都是交互过程中最为常用的, 其它还有一些重要的方法如get/set_parameter,pause,redirect等等

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

sdp的格式：

v=<version>

o=<username> <session id> <version> <network type> <address type> <address>

s=<session name>

i=<session description>

u=<URI>

e=<email address>
p=<phone number>
c=<network type> <address type> <connection address>

b=<modifier>:<bandwidth-value>

t=<start time> <stop time>

r=<repeat interval> <active duration> <list of offsets from start-time>

z=<adjustment time> <offset> <adjustment time> <offset> ....

k=<method>
k=<method>:<encryption key>

a=<attribute>
a=<attribute>:<value>

m=<media> <port> <transport> <fmt list>

v = （协议版本）

o = （所有者/创建者和会话标识符）

s = （会话名称）

i = * （会话信息）

u = * （URI 描述）

e = * （Email 地址）

p = * （电话号码）

c = * （连接信息）

b = * （带宽信息）

z = * （时间区域调整）

k = * （加密密钥）

a = * （0 个或多个会话属性行）

时间描述：

t = （会话活动时间）

r = * （0或多次重复次数）

媒体描述：

m = （媒体名称和传输地址）

i = * （媒体标题）

c = * （连接信息 — 如果包含在会话层则该字段可选）

b = * （带宽信息）

k = * （加密密钥）

a = * （0 个或多个媒体属性行）

Useful RFCs

RFC3489 - STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)
http://www.ietf.org/rfc/rfc3489.txt?number=3489

RFC1483 - Multiprotocol Encapsulation over ATM Adaptation Layer 5
http://www.ietf.org/rfc/rfc1483.txt?number=1483

RFC1577 - Classical IP and ARP over ATM
http://www.ietf.org/rfc/rfc1577.txt?number=1577

802.1Q 和 ISL

IEEE802.1Q是经过IEEE认证的对数据帧附加VLAN 识别信息的协议。
IEEE802.1Q 所附加的VLAN 识别信息位于数据帧中“发送源MAC 地址”与“类别域（Type Field）”之间。具体内容为2字节的TPID 和2字节的TCI。在数据帧中添加了4字节的内容，那么CRC 值自然也会有所变化。这时数据帧上的CRC是插入TPID、TCI后对包括它们在内的整个数据帧重新计算后所得的值。



而当数据帧离开汇聚链路时，TPID 和TCI 会被去除，这时还会进行一次CRC 的重新计算。TPID的值固定为0x8100 。交换机通过TPID，来确定数据帧内附加了基于IEEE802.1Q 的VLAN 信息，而实质上的VLAN ID是TCI中的12位元，最多可供识别4096 个VLAN。基于IEEE802.1Q 附加的VLAN 信息就像在传递物品时附加的标签。因此，它也被称作“标签型VLAN（Tagging VLAN）”。


ISL是Cisco 产品支持的一种附加VLAN 信息的协议。使用ISL后，每个数据帧头部都会被附加 26字节的ISL包头（ISL Header ），并且在帧尾带上通过对包括ISL 包头在内的整个数据帧进行计算后得到的4字节CRC值，总共增加了30 字节的信息。在使用ISL 的环境下，当数据帧离开汇聚链路时，只要简单地去除ISL包头和新CRC就可以了。由于原先的数据帧及其CRC 都被完整保留，因此无需重新计算CRC。ISL有如用ISL 包头和新CRC 将原数据帧整个包裹起来，因此也被称为封装型VLAN（Encapsulated VLAN）。

MGCP and H.248

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
RFC3435 - Media Gateway Control Protocol (MGCP) Version 1.0
http://www.ietf.org/rfc/rfc3435.txt?number=3435

RFC3660 - Basic Media Gateway Control Protocol (MGCP) Packages
http://www.ietf.org/rfc/rfc3660.txt?number=3660

RFC3661 - Media Gateway Control Protocol (MGCP) Return Code Usage
http://www.ietf.org/rfc/rfc3661.txt?number=3661
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

http://blog.csdn.net/rosemary4924/archive/2005/03/25/330232.aspx
http://comm.ccidnet.com/art/1522/20041227/194559_1.html

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

媒体网关控制协议 MGCP 是一种 VOIP 协议，应用于多媒体网关单元之间。多媒体网关由包含“智能”呼叫控制的呼叫代理[媒体网关控制器(MGC)]和包含媒体功能的媒体网关(MG)组成，其中的媒体功能诸如由 TDM 语音到 VOIP 的转化。MG在 MGC(或软交换)的控制下，实现跨网媒体业务。

MGCP协 议与 H.323和SIP不同，H.323和SIP提出两套IP电话体系结构，二者完全独立，不能互相兼容，只能互通。MGCP不涉及IP电话的体系结构，只涉 及网关分解问题，因而不仅可用于 H.323 IP电话系统，也可用于SIP IP电话系统。

MGCP 协议定义的连接模型包括端点(endpoint)和连接(connection)两个主要概念。
端点是数据源或数据宿，可以是物理端点，也可以是虚拟端 点。端点类型包括数字通道、模拟线、录音服务器接入点及交互式话音响应接入点。端点标识由端点所在网关域名和网关中的本地名两部分组成。
连接可以是点到点 连接或多点连接。点到点连接是两个互相发送数据的端点之间的一种关联，该关联在两个端点都建立起来后，就可开始传送数据。多点连接的建立是通过连接端点和多点会话而实现的。连接的建立可以在各种承载网络上进行。呼叫代理可要求端点在检测到某些事件(如摘机、挂机、拍叉或拨号)发生时，向其发出通知，也可请求将某些信号(如拨号音、 回铃音、忙音等)加到端点上。事件和信号组合成包，每个包由某一特定端点支持。每个事件(含信号)可用“包名／事件名”表示，每类端点有特定的包，每个包 包含有规律的事件和信号，包名和事件名均用数字字母串表示。

媒体网关包括端点，即呼叫代理能够对之进行创建、修改和删除连接等操作，从而实现建立和控制与其它多媒体端点的媒体会话过程。媒体网关是一种提供电话电路 上的视频信号与因特网或其它网络数据包之间的转换的网络单元。呼叫代理通知端点检查特定事件并生成信号。端点自动地通告呼叫代理其服务状态下的变化。此 外，呼叫代理还可以核查端点及端点连接。

MGCP 采用的是呼叫控制结构，其中的“智能”呼叫控制处于网关外部，并由呼叫代理操作。 MGCP 规定呼叫代理彼此之间需要采用同步方式发送命令和响应给网关，但其并没有为同步呼叫代理设置专门的机制。从本质上来看，MGCP 是一种主从协议，由网关去执行呼叫代理发送的命令。

MGCP 采用文本协议，协议消息分为命令和响应，每个命令需要接收方回送响应，采用三次握手方式证实。命令消息由命令行和若干参数行组成，响应消息带有 3位数字的响应码。MGCP采用会话描述协议(SDP)向网关描述连接参数。为了减小信令传送时延，MGCP采用用户数据报协议(UDP)传送。


MGCP 是基于文本的协议，其中事务的进行由一条命令和强制响应完成。下面提供了几种命令：
CreateConnection：MGC --》 MG
呼叫代理用该命令将某端点与指定的IP地址和UDP端口关联，另外还向远端端点发送创建连接命令，建立两个端点间的连接；通过 SDP 规定参与终点的接收容量。

ModifyConnection：MGC --》 MG
更改连接的属性；与 CreateConnection 命令具有相同的参数。

DeleteConnection：MGC 《--》 MG
终止连接，并在执行连接的过程中收集统计。

NotificationRequest：MGC --》 MG
请求媒体网关用以发送关于端点指定事件的发生通知。

Notify：MGC 《-- MG
一旦观察到事件发生，就通知媒体网关控制器。

AuditEndpoint：MGC --》 MG
决定终点状态。

AuditConnection：MGC --》 MG
检索与连接相关的参数。

RestartInProgress：MGC 《-- MG
信号（指单个端点或端点组）将被带进或带出服务。

EndpointConfiguration：MGC --》 MG
端点配置命令

在 MGCP 模式中，网关主要负责音频信号转换功能，呼叫代理主要处理呼叫信令和呼叫处理功能。因此，呼叫代理实现了 H.323 标准信令层并使其本身充当了 H.323 关守或 H.323 体系的一个或多个H.323 终点。