h发送数据报应用的协议是什么

h发送数据报应用的是什么 篇一:数据包概念 RTP/RTCP RTP/RTCP协议简介 实时传输协议RTP(Realtime Transport Protocol):是针对Internet上多媒体数据流的一个传输协议, 由IETF(Internet工程任务组)作为RFC1889发布。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP或ATM等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。 实时传输控制协议RTCP(Realtime Transport Control Protocol):负责管理传输质量在当前应用进程之间交换控制信息。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速 1 率，甚至改变有效载荷类型。RTP和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。 RTCP主要有4个功能: (1)用反馈信息的方法来提供分配数据的传送质量，这种反馈可以用来进行流量的拥塞控制，也可以用来监视网络和用来诊断网络中的问题; (2)为RTP源提供一个永久性的CNAME(规范性名字)的传送层标志，因为在发现冲突或者程序更新重启时SSRC(同步源标识)会变，需要一个运作痕迹，在一组相关的会话中接收方也要用CNAME来从一个指定的与会者得到相联系的数据流(如音频和视频); (3)根据与会者的数量来调整RTCP包的发送率; (4)传送会话控制信息，如可在用户接口显示与会者的标识，这是可选功能。RTP/RTCP工作过程 工作时，RTP协议从上层接收流媒体信息码流(如H.263)，装配成RTP数据包发送给下层，下层协议提供RTP和RTCP的分流。如在UDP中，RTP使用一个偶数号端口，则相应的RTCP使用其后的奇数号端口。RTP数据包没有长度限制，它的最大包长只受下层协议的限制。 RTP会话和流的两级分用 一个RTP会话(Session)包括传给某个 2 指定目的地对(Destination Pair)的所有通信量，发送方可能包括多个。而从同一个同步源发出的RTP分组序列称为流(Stream),一个RTP会话可能包含多个RTP流。一个RTP分组在服务器端发送出去的时候总是要指定属于哪个会话和流，在接收时也需要进行两级分用，即会话分用和流分用。只有当RTP使用同步源标识(SSRC)和分组类型(PTYPE)把同一个流中的分组组合起来，才能够使用序列号(Sequence Number)和时间戳(Timestamp)对分组进行排序和正确回放。 由于实时数据的独有性，不同实时客户可以共用一个RTP实时服务线程和一个RTCP实时服务线程，这样可以大大减小服务器的负担，而每个文件客户由于请求的文件不同，相应地对速度和开始时间的要求都可能不同，所以需要有自己独有的RTP文件服务线程和RTCP文件服务线程。 RTP服务线程负责把实时数据流发送给客户，RTCP服务线程根据RTP线程的统计数据，产生发送方报告给客户。RTP线程和RTCP线程之间通过一段共享内存交互统计数据，对共享内存必须设置互斥体进行保护，防止出现错误读写。在这种方式下，服务器可以根据每个用户的不同请求和具体情况方便地提供不同的服务。 RTP 时间戳的处理 时间戳字段是RTP首部中数据包时间的同步信息，是数据能以正确的时间顺序恢复的关键。时间戳的值给出了 3 分组中数据的第一个字节的采样时间(Sampling Instant)，要求发送方时间戳的时钟是连续、单调增长的，即使在没有数据输入或发送数据时也是如此。在 静默时，发送方不必发送数据，保持时间戳的增长，在接收端，由于接收到的数据分组的序号没有丢失，就知道没有发生数据丢失，而且只要比较前后分组的时间戳的差异，就可以确定输出的时间间隔。 RTP一次会话的初始时间戳必须随机选择，但协议没有规定时间戳的单位，也没有规定该值的精确解释，而是由负载类型来确定时钟的颗粒，这样各种应用类型可以根据需要选择合适的输出计时精度。 在RTP传输音频数据时，一般选定逻辑时间戳速率与采样速率相同，但是在传输视频数据时，必须使时间戳速率大于每帧的一个滴答。如果数据是在同一时刻采样的，协议标准还允许多个分组具有相同的时间戳值。 RTP协议没有规定RTP分组的长度和发送数据的速度，因而需要根据具体情况调整服务器端发送媒体数据的速度。对来自设备的实时数据可以采取等时间间隔访问设备缓冲区，在有新数据输入时发送数据的方式，时间戳的设置相对容易。对已经录制好的本地硬盘上的媒体文件，以H.263格式的文件为例，由于文件本身不包含帧率信息，所以需要知道录制时的帧率或者设置一个初始值，在发送数据的时候找 4 出发送数据中的帧数目，根据帧率和预置值来计算时延，以适当的速度发送数据并设置时间戳信息。 RTCP的一个关键作用就是能让接收方同步多个RTP流，例如:当音频与视频一起传输的时候，由于编码的不同，RTP使用两个流分别进行传输，这样两个流的时间戳以不同的速率运行，接收方必须同步两个流，以保证声音与影像的一致。为能进行流同步，RTCP要求发送方给每个传送一个唯一的标识数据源的规范名(Canonical Name)，尽管由一个数据源发出的不同的流具有不同的同步源标识(SSRC)，但具有相同的规范名，这样接收方就知道哪些流是有关联的。而发送方报告报文所包含的信息可被接收方用于协调两个流中的时间戳值。发送方报告中含有一个以网络时间协议 NTP(Network Time Protocol)格式表示的绝对时间值，接着RTCP报告中给出一个RTP时间戳值，产生该值的时钟就是产生RTP分组中的TimeStamp字段的那个时钟。由于发送方发出的所有流和发送方报告都使用同一个绝对时钟，接收方就可以比较来自同一数据源的两个流的绝对时间，从而确定如何将一个流中的时间戳值映射为另一个流中的时间戳值。 RTP ?实时传送协议(Real-time Transport Protocol或简写RTP)是一个网络传输协议，它是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的。 5 RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。它一开始被为一个多播协议，但后来被用在很多单播应用中。RTP协议常用于流媒体系统(配合RTCP协议)，视频会议和一键通(Push to Talk)系统(配合H.323或SIP)，使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用，而且它是建立在用户数据报协议上的。 它作为因特网标准在RFC 3550(该文档的旧版本是RFC 1889)有详细说明。RFC 3551(STD 65，旧版本是RFC 1890)详细描述了使用最小控制的音频和视频会议。 RTP 本身并没有提供按时发送机制或其它服务质量(QoS)保证，它依赖于低层服务去实现这一过程。 RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。 RTP 实行有序传送， RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如:在视频解码中，就不需要顺序解码。 RTP 由两个紧密链接部分组成: RTP , 传送具有实时属性的数据; RTP 控制协议(RTCP) , 监控服务质量并传送正在进行的会话参与者的相关信息。RTCP 第二方面的功能对于―松散受控‖会话是足够的，也就是说，在没有明确的成员控制和组织的情况下，它并不非得用来支持一个应用程序的所 6 有控制通信请求。 协议结构 1 2 3 8 9 16bit V P X CSRC Count M Payload Type Sequence number Timestamp SSRC CSRC (variable 0 – 15 items 32bits each) V , 版本。识别 RTP 版本。 P , 间隙(Padding)。设置时，数据包包含一个或多个附加间隙位组，其中这部分不属于有效载荷。 X , 扩展位。设置时，在固定头后面，根据指定格式设置一个扩展头。 CSRC Count , 包含 CSRC 标识符(在固定头后)的编号。 M , 标记。标记由 Profile 文件定义。允许重要事件如帧边界在数据包流中进行标记。 Payload Type , 识别 RTP 有效载荷的格式，并通过应用程序决定其解释。Profile 文件规定了从 Payload 编码到 Payload 格式的缺省静态映射。另外的 Payload Type 编码可能通过非 RTP 方法实现动态定义。 Sequence Number , 每发送一个 RTP 数据包，序列号增加1。接收方可以依次检测数据包的丢失并恢复数据包序列。 7 Timestamp , 反映 RTP 数据包中的第一个八位组的采样时间。采样时间必须通过时钟及时提供线性无变化增量获取，以支持同步和抖动计算。 SSRC , 同步源。该标识符随机选择，旨在确保在同一个 RTP 会话中不存在两个同步源具有相同的 SSRC 标识符。 CSRC , 贡献源标识符。识别该数据包中的有效载荷的贡献源。 可靠传输协议 Reliable Transport Protocol-----RTP 应用于EIGRP中，是它的组件 UDP(User Datagram Protocol) 用户数据报协议 用户数据报协议(UDP)是 OSI 参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务。是一个简单的面向数据报的传输层协议，IETF RFC 768是UDP的正式规范。 UDP 协议基本上是 IP 协议与上层协议的接口。 UDP 协议适用端口分别运行在同一台设备上的多个应用程序。 由于大多数网络应用程序都在同一台机器上运行，计算机上必须能够确保目的地机器上的软件程序能从源地址机器处获得数据包，以及源计算机能收到正确的回复。这是通过使用 UDP 的―端口号‖完成的。例如，如果一个工作站希望在工作站 128.1.123.1 上使用域名服务系统，它就会给数据 8 包一个目的地址 128.1.123.1 ，并在 UDP 头插入目标端口号 53 。源端口号标识了请求域名服务的本地机的应用程序，同时需要将所有由目的站生成的响应包都指定到源主机的这个端口上。 UDP 端口的详细介绍可以参照相关文章。 与 TCP 不同， UDP 并不提供对 IP 协议的可靠机制、流控制以及错误恢复功能等。由于 UDP 比较简单， UDP 头包含很少的字节，比 TCP 负载消耗少。 UDP 适用于不需要 TCP 可靠机制的情形，比如，当高层协议或应用程序提供错误和流控制功能的时候。 UDP 是传输层协议，服务于很多知名应用层协议，包括网络文件系统(NFS)、简单网络管理协议(SNMP)、域名系统(DNS)以及简单文件传输系统(TFTP)、动态主机配置协议(DHCP)、路由信息协议(RIP)和某些影音串流服务等等。 协议结构 Source Port — 16位。源端口是可选字段。当使用时，它表示发送程序的端口，同时它还被认为是没有其它信息的情况下需要被寻址的答复端口。如果不使用，设置值为0。 Destination Port — 16位。目标端口在特殊因特网目标地址的情况下具有意义。 Length — 16位。该用户数据报的八位长度，包括协议头和数据。长度最小值为8。 Checksum — 16位。IP 协议头、UDP 协议头和数据位，最后用0填补的信息假协议头总和。如果必要的话，可以由两个八位复合而 9 成。 Data — 包含上层数据信息。 UDP协议有如下的特点: 1、UDP传送数据前并不与对方建立连接，即UDP是无连接的，在传输数据前，发送方和接收方相互交换信息使双方同步。 2、UDP不对收到的数据进行排序，在UDP报文的首部中并没有关于数据顺序的信息(如TCP所采用的序号)，而且报文不一定按顺序到达的，所以接收端无从排起。 3、UDP对接收到的数据报不发送确认信号，发送端不知道数据是否被正确接收，也不会重发数据。 4、UDP传送数据较TCP快速，系统开销也少。 5、由于缺乏拥塞控制(congestion control)，需要基于网络的机制来减小因失控和高速UDP流量负荷而导致的拥塞崩溃效应。换句话说，因为UDP发送者不能够检测拥塞，所以像使用包队列和丢弃技术的路由器这样的网络基本设备往往就成为降低UDP过大通信量的有效工具。数据报拥塞控制协议(DCCP)设计成通过在诸如流媒体类型的高速率UDP流中增加主机拥塞控制来减小这个潜在的问题。 从以上特点可知，UDP提供的是无连接的、不可靠的数据传送方式，是一种尽力而为的数据交付服务。 rtcp RTCP:RTP 控制协议 (RTCP:RTP Control 10 Protocol) RTP 控制协议(RTCP)采用与数据包相同的分发机制，将控制包周期性传输到所有会话参与者中。底层协议必须提供数据和控制包的多路发送，例如使用不同的 UDP 端口号。 RTCP 提供数据分发质量反馈信息。这是 RTP 作为传输协议的部分功能并且它涉及到了其它传输协议的流控制和拥塞控制。 RTCP 为 RTP 源携带一个持久性传输层标识符，称为规范名或 CNAME 。由于一旦发现冲突或程序重启时， SSRC 标识符会随之改变，所以接收方需要 CNAME 来跟踪每一个参与者。同时接收方还要求 CNAME 能够与一组相关 RTP 会话中来自于给定参与者的多重数据流相关联，例如同步视频和音频。 上述前两个功能要求所有的参与者都要发送 RTCP 包，因此必须控制速率以便 RTP 按比例增加大量的参与者。通过每一个参与者发送各自的控制包给其它所有参与者，每一个参与者能够独立观察到参与者数量，该数量可用来计算控制包的发送速率。 OPTIONAL 功能用于传送最少会话控制信息，例如在用户界面显示参与者标识。这对于―松散受控‖会话(在没有成员控制或阐述协商的情况下，参与者可以加入或退出该 11 会话)是非常有用的。 上述功能 1 , 3 适用于所有环境，尤其是 IP 组播环境。 RTP 应用程序设计者应该避免设计只能工作于单播模式并且不能增加到大量数量的机制。在某些情况下如单向链接中，不可能有来自接收方的反馈，所以 RTCP 的传输就可能由发送方和接收方分别独立控制。 协议结构 2 3 8 16 bit Version P RC Packet type Length Version , 识别 RTP 版本。 RTP 数据包中的该值与 RTCP 数据包中的一样。 当前规范定义的版本值为 2 。 P , 间隙(Padding)。设置时， RTCP 数据包包含一些其它 padding 八位位组，它们不属于控制信息。 Padding 的最后八位是用于计算应该忽略多少间隙八位位组。一些加密算法中需要计算固定块大小时也可能需要使用 Padding 字段。在一个复合 RTCP 数据包中，只有最后的个别数据包中才需要使用 padding ，这是因为复合数据包是作为一个整体来加密的。 RC , 接收方报告计数。包含在该数据包中的接收方报告块的数量，有效值为 0 。 Packet type , 包括常量 200 ，识别这是一个 RTCP SR 数据包。 12 Length , RTCP 数据包的大小(32 位字减去 1)，包含 头和任意间隙 (偏移量的引入使得 0 成为有效值，并避免 了扫描复合 RTCP 数据包过程中的无限循环现象，而采用 32 位字计数方法则避免了对 4 的倍数的有效性校验)。 篇二:H.323协议手册 U-SYS SoftX3000 软交换系统 技术手册 信令与协议分 册 目 录 目 录 第4章 H.323协 议 ................................................................................................. ................... 4-1 4.1 概 述 ................................................................................................. ................................... 4-1 4.1.1 基本概 念 ................................................................................................. ................. 4-1 4.1.2 相关术 语 ................................................................................................. ................. 4-1 4.1.3 协议栈结 13 构 .............................................................................................................. 4-4 4.1.4 H.323协议的应 用 .................................................................................................... 4-6 4.2 RAS协 议 ............................................................................................................................ 4-8 4.2.1 概 述 ......................................................................................................................... 4-8 4.2.2 协议消 息 .................................................................................................................. 4-9 4.2.3 基本消息流 程 ......................................................................................................... 4-16 4.3 H.225.0呼叫信令协 议 ...................................................................................................... 4-18 4.3.1 概 述 ................................................................................................. 14 ...................... 4-18 4.3.2 协议消 息 ................................................................................................................ 4-18 4.3.3 基本消息流 程 ......................................................................................................... 4-26 4.4 H.245协 议 ....................................................................................................................... 4-28 4.4.1 概 述 ....................................................................................................................... 4-28 4.4.2 协议消 息 ................................................................................................................ 4-31 4.4.3 基本消息流 程 ......................................................................................................... 4-40 4.5 H.323呼叫流 程 ................................................................................................................ 4-42 15 4.5.1 成功的H.323用户呼叫流程(正常启动) ............................................................. 4-42 4.5.2 成功的H.323用户呼叫流程(快速启动) ............................................................. 4-70 4.5.3 成功的H.323中继呼叫流 程 .................................................................................. 4-71 第4章 H.323协议 4.1 概述 4.1.1 基本概念 H.323是由ITU制定的通信控制协议，用于在分组交换网中提供多媒体业务。呼叫控制是其中的重要组成部分，它可用来建立点到点的媒体会话和多点间媒体会议。目前最新的H.323版本是V4。 H.323定义了介于电路交换网和分组交换网之间的H.323网关(Gateway)、用于地址翻译和访问控制的网守(GateKeeper)、提供多点控制的多点会议控制器(MC)、提供多点会议媒体流混合的多点处理器(MP)，以及多点会议控制单元(MCU)等实体。 4.1.2 相关术语 1. AAA 认证、授权和计费 AAA是Authentication、Authorization and Accounting的缩写。认证即检验使用者是否具有一定的权限;授权是给合 16 法的使用者适当的权限，允许其对网络上的一定资源进行访问;计费是对被授权者提供服务时，记录一些必要的信息，以供产生帐单之用。 2. H.323实体 H.323系统的组成部件称为H.323实体(entity)，它包括终端、网关、网守、多点控制器(MC)、多点处理器(MP)、多点控制单元MCU(Multipoint Control Unit)。其中，终端、网关和MCU统称为端点，端点可以发起呼叫也可以接受呼叫，媒体信息流就在端点生成或终结。 3. H.323终端 H.323终端是在基于分组的网络PBN(Packet-Based Network)上遵从H.323建议标准进行实时通信的端点设备，它可以集成在个人计算机中，也可以是一个独立的设备，如以太网电话机或可视电话机。 H.323终端主要实现直接与用户交互、发起或接受呼叫、媒体流处理等功能。 4. Gatekeeper 网守(GK) 网守是网络的管理点，一个网守管理的所有终端、网关和MCU的集合称之为一个管理区(Zone)。一个管理区至少包含一个终端，可以有也可以没有MCU或网关，但必须有且仅有一个网守。 网守为H.323端点提供以下服务: 17 ? ? ? ? ? ? 接入认证:网络资源使用许可，身份验证; 地址解析:别名和网络地址之间的翻译; 带宽管理:初始带宽申请，带宽改变控制; 计费管理:提供计费信道; 区域管理:下辖设备的管理; 呼叫控制:提供各种补充业务。 5. Gateway 网关(GW) 网关是在H.323终端和广域网上其它ITU终端之间提供实时二方通信的端点设备。从概念上讲，网关的作用是完成两项转换功能:媒体信息编码的转换和信令的转换。对于后者来说，如果把网关视为原来网络的一个终端，则网关需完成的是用户信令至H.323控制协议的转换;如果网关两侧分别连接不同的网络，如PBN和SCN，则需完成其它网络信令至H.323协议的转换。 H.323网关主要实现异种网络互通、信令消息格式和内容转换、通信协议流程转换和媒体流格式转换等功能。 6. 多点通信 多点通信功能部件包括MC、MP和MCU，用于会议通信。 18 MC提供多点会议的控制功能。它和参加会议的每个端点执行―能力交换‖过程，指示信息可发送的操作模式。当有终端加入或离开此会议时，MC可能会调整向各终端发送的能力集信息。 MP接收来自各参会端点的音频、视频和数据信号流，经处理后回送各端点。因此，MP应能执行各种媒体信息的编解码算法。 MC和MP只是功能实体，并非物理实体。 MCU是会议通信的重要设备，主要实现多点会议管理和控制、与会终端的管理、媒体流控制、混音、多画面等功能。它包含多点控制(MC)和多点处理(MP)两部分。 多点会议可以分为: (1) 集中式会议 混合多点会议是集中式与分散式混合组网的多点会议。其组网示意图如图4-2所示。 7. RADIUS 拨入用户的远程认证服务 Remote Authentication Dial-In User Service的缩写，是当前流行的AAA协议。该协议规定了RADIUS服务器和RADIUS客户端认证、授权和计费信息的交互格式。 4.1.3 协议栈结构 H.323协议栈结构如图4-4所示。其下三层为PBN的底层协议，如在LAN中，可为物理媒体,,MAC-IPX;在IP 19 网络中，其网络层就是IP。传输层有两类协议:不可靠传送协议，如UDP，用于传送实时声像信号和终端至网守的登记协议;可靠传送协议，如TCP，用于传送数据信号及呼叫信令和媒体控制协议。 篇三:H264媒体和数据传输介绍 H264媒体简单说明 一、 H264简介 H264分层结构由五层组成: 序列参数集(sps) 图像参数集(pps) 片(slice) 宏块、 子块 其中后面层应用前面层(或则说从属关系);其中序列的第一个帧叫做IDR帧，用于清空参考帧队列，避免错误累积。 H264 nalu包RTP传输 一般分为三种情况: 单一nalu模式，一般nalu<mtu 组合封包模式，多个nalu组成一个RTP包 分片封包模式，一般nalumtu 二、 H264的文件存储和传输区别 H264的文件存储: 每一个NALU包前都会多一个00 00 01 or 00 00 00 01的起始头，作为NALU包之间的分隔标识;并通过给非起始头 20 的00 00后插入0x03来避免标识冲突。取数据后，起始头需要丢掉，0x03数据也需要去除。 依据不同帧的情况来实现不同打包，代码可参考 NALU打包demo H264的文件传输: NALU包属于传输包的自然分割，不需要加起始头。 包格式一般是: x串+h264nalu头+h264data 比如RTP传输，x串往往就是RTP头(一般12字节) 三、 H264和MP4关系 是ITU-T与ISO/IEC两个组织联合进行开发的视频编解码方案。 ITU-T命名为H264 ISO/IEC命名为MPEG-4 AVC是 MPEG-4标准的第10部分 其中 标准H264格式的文件存储不是国际标准格式 相关传输协议简单说明(本次使用到) 一、 RTP/RTCP、RTSP、SIP等 RTP/RTCP是传输层的传输和控制协议，是一个传输子层，运行在TCP/UDP之上 RTSP/SIP是更上一层的传输协议 SIP运行在RTP之上 RTSP直接在TCP/UDP上运行 二、 RTP包头 音频和视频采用不同端口，初期先考虑仅H264视频 21 三、 RTCP 在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。分为五类: 200 SR 发送端报告 主要考虑 201 RR 接收端报告 202 SDES 源点描述 203 BYE 结束传输 204 APP 特定应用 SR主要包括:相应的RTP流的SSRC(丢失率、累计丢包数、接收抖动、上次SR以来的延时等)、RTP流中最新产生的RTP分组时间戳和NTP、RTP流包含的分组数、字节数。 详情参见附录三 RTCP包结构说明 RTP发往对端UDP的偶数端口N，RTCP发往对端UDP的奇数端口N+1 发送周期(限制RTCP占RTP会话量的一小部分,通常不超过5%)，计算起来比较麻烦 暂时先简化 试试:每20个RTP包发送一个RTCP SR and RR包,小文件传输测试时，先不发RTCP包，看能不能找到个demo来编程参考，这部分很繁杂 RTCP执行下列四大功能: 主要是提供数据发布的质量反馈。是作为RTP传输协议的一部分，与其他传输协议的流和阻塞控制有关。反馈对自适应编码控制直接起作用，但IP组播经验表明，从发送者 22 收到反馈对诊断发送错误是致关重要的。 RTCP带有称作规范名字(CNAME)的RTP源持久传输层标识。如发现冲突，或程序重新启动，既然SSRC标识可改变，接收者需要CNAME跟踪参加者。接收者也需要CNAME 与 相关RTP连接中给定的几个数据流联系 前两种功能要求所有参加者发送RTCP包，因此，为了RTP扩展到大规模数量，速率必须受到控制。让每个参加者给其它参加者发送控制包，就大独立观察参加者数量。该数量用语计算包发送的速率。 第四个可选功能是传送最小连接控制信息，如参加者辨识。最可能用在松散控制连接，那里参加者自由进入或离开，没有成员控制或参数协调，RTCP充当通往所有参加者的方便通道，但不必支持应用的所有控制通讯要求。在IP组播场合应用RTP时，前3个功能是必须的，推荐用于所有情形。RTP应用设计人员必须避免使用仅在单播模式下工作的机制，那将导致无法扩展规模。 四、 RTSP 是一个多媒体播放控制协议，通过TCP传输 RTSP分为请求消息和响应消息，常用方法如下: a. OPTION，得到服务器提供的可用方法 b. DESCRIBE，得到服务器的会话描述信息(SDP) c. 23 SETUP，提醒服务器建立会话，并确定传输模式 d. PLAY，发送播放请求 e. TEARDOWN，发起关闭请求 f. 其他如GET/SET_PARAMETER、PAUSE、REDIRECT等 使用朗驰摄像头实现思科视频对接过程注意内容 一、 思科视频数据要求 基于SIP协议，使用RTP传输协议 RTP包格式: RTP包头(一般12字节) + h264 nalu头 + h264nalu data 二、 朗驰摄像头数据源输入: 可以有两种方式: A模式，作为客户端通过RTSP方式获得数据 B模式，调用SDK获得数据 两者都可以通过UDP传输三、 数据解析说明(目前无朗驰提供格式说明，以下数据仅通过抓包直接解析获得，不排除低概率 的特殊内容出现) A模式 X头(12字节)+h264 nalu头+h264nalu data 和RTP头差别，X头中时间戳为0 ;抓包工具不识别，播放软件可忽略该数据。 需要进行RTSP协议会话、UDP解包(修改时间戳)、转发包、增加RTCP消息 B模式，两种情况 UDP头(8字节) + a模式(x串+起始码(00 00 00 24 01)+h264nalu头+h264data) x串 00 00 01…一直到00 00 00 01 之前结束(共28/26字节，如:00 00 00 01 61(28字节)，00 00 00 01 f0 00(26字节))，存在个别情况x串和00 00 00 01 67之间又增加了一个朗驰说明数据(tcp数据通过UDP传输了,)，鉴别方法，00 00 01~00 00 00 01处理即可 UDP头(8字节) + b模式(h264data，上一个起始码(00 00 00 01)内容的的后续数据)没有x串 需要解包(去除不需要内容)、重新打包、增加RTP包头、增加RTCP 相对而言，采用A模式更简明，与PTSP的会话参见下面的附录一和附录二 相关热词搜索:发送 协议 数据 数据保密协议 数据链路层协议 25