基于RTP协议的实时语音传输研究与实现_杨黎明
实时控制传输通讯协议RealTime Control and Translate Protocol
RCTP实时控制/传输通讯协议 RCTP协议(RealTime Control and Translate Protocol)为自定义实时控制/传输通讯协议。 1、基本帧格式 1.1帧结构 typedef struct { uchar head; //帧头 uchar length; //帧长度 uchar length_rep; //帧长度重复 uchar head_rep; //帧头重复 uchar source_id; //发送设备号 uchar directory_id; //接收设备号 uchar handle; //帧与操作类型 uchar parameter[frame_data_size]; //帧参数域buf uchar AccVal; //累加和校验 uchar stop; //结束符 } struct_frame; 1.2开始符的判断 条件：if(struct_frame.head == struct_frame.head_rep) && (struct_frame.length == struct_frame.length_rep)成立。 1.3帧与操作类型 1.3.1 数据帧的操作类型定义 1.3.2 命令帧的操作类型定义
1.4 校验和 校验和为：0-N的累加值，1字节。 2、基于RCTP的LED数码管数据采集通讯协议: RCTP-Ⅰ协议 RCTP-Ⅰ协议是基于RCTP的LED数码管数据采集通讯协议，物理上基于RS-485口，通过屏蔽双绞线实现通讯。RCTP-Ⅰ协议是一种主-从协议。主站设备发送要求到从站设备，从站设备响应，从站不能主动发出信息。 波特率代码表： 在默认状态下通信的设置速率一般是9600、无效验、8数据位、1个停止位。
RTP协议分析
RTP协议分析 第1章. RTP概述 1.1. RTP是什么 RTP全名是Real-time Transport Protocol（实时传输协议）。它是IETF提出的一个标准，对应的RFC文档为RFC3550（RFC1889为其过期版本）。RFC3550不仅定义了RTP，而且定义了配套的相关协议RTCP（Real-time Transport Control Protocol，即实时传输控制协议）。RTP用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。RTP为Internet上端到端的实时传输提供时间信息和流同步，但并不保证服务质量，服务质量由RTCP来提供。 1.2. RTP的应用环境 RTP用于在单播或多播网络中传送实时数据。它们典型的应用场合有如下几个。 简单的多播音频会议。语音通信通过一个多播地址和一对端口来实现。一个用于音频数据（RTP），另一个用于控制包（RTCP）。 音频和视频会议。如果在一次会议中同时使用了音频和视频会议，这两种媒体将分别在不同的RTP会话中传送，每一个会话使用不同的传输地址（IP地址＋端口）。如果一个用户同时使用了两个会话，则每个会话对应的RTCP包都使用规范化名字CNAME（Canonical Name）。与会者可以根据RTCP包中的CNAME来获取相关联的音频和视频，然后根据RTCP 包中的计时信息(Network time protocol)来实现音频和视频的同步。 翻译器和混合器。翻译器和混合器都是RTP级的中继系统。翻译器用在通过IP多播不能直接到达的用户区，例如发送者和接收者之间存在防火墙。当与会者能接收的音频编码格式不一样，比如有一个与会者通过一条低速链路接入到高速会议，这时就要使用混合器。在进入音频数据格式需要变化的网络前，混合器将来自一个源或多个源的音频包进行重构，并把重构后的多个音频合并，采用另一种音频编码进行编码后，再转发这个新的RTP包。从一个混合器出来的所有数据包要用混合器作为它们的同步源（SSRC，见RTP的封装）来识别，可以通过贡献源列表（CSRC表，见RTP的封装）可以确认谈话者。 1.3. 相关概念 1.3.1. 流媒体 流媒体是指Internet上使用流式传输技术的连续时基媒体。当前在Internet上传输音频和视频等信息主要有两种方式：下载和流式传输两种方式。 下载情况下，用户需要先下载整个媒体文件到本地，然后才能播放媒体文件。在视频直播等应用场合，由于生成整个媒体文件要等直播结束，也就是用户至少要在直播结束后才能看到直播节目，所以用下载方式不能实现直播。 流式传输是实现流媒体的关键技术。使用流式传输可以边下载边观看流媒体节目。由于Internet是基于分组传输的，所以接收端收到的数据包往往有延迟和乱序（流式传输构建在UDP上）。要实现流式传输，就是要从降低延迟和恢复数据包时序入手。在发送端，为降低延迟，往往对传输数据进行预处理（降低质量和高效压缩）。在接收端为了恢复时序，采用了接收缓冲；而为了实现媒体的流畅播放，则采用了播放缓冲。
实时传输协议RTP
实时传输协议RTP 1.RTP协议： RTP（ Real-time Transport Protocol）协议最初是在70年代为了尝试传输声音文件，把包分 成几部分用来传输语音，时间标志和队列号。经过一系列发展，RTP第一版本在 1991年8月由美国的一个实验室发布了。到本世纪1996年形成了标准的的版本。很多著名的公司如Netscape ,就宣称“Netscape LiveMedia”是基于RTP协议的。Microsoft 也宣称他们的“NetMeeting”也是支持RTP协议. RTP被定义为传输音频、视频、模拟数据等实时数据的传输协议。最初设计是为了数据传输的多播，但是它也用于单播的。与传统的注重的高可靠的数据传输的运输层协议相比，它更加侧重 的数据传输的实时性。此协议提供的服务包括时间载量标识、数据序列、时戳、传输控制等。RTP与辅助控制协议RTCP一起得到数据传输的一些相关的控制信息。 2．RTP协议的工作原理： 如上所说明的，影响多媒体数据传输的一个尖锐的问题就是不可预料数据到达时间。但是流媒体的传输是需要数据的适时的到达用以播放和回放。RTP协议就是提供了时间标签,序列号以及 其它的结构用于控制适时数据的流放。 在流的概念中‘时间标签’是最重要的信息。发送端依照即时的采样在数据包里隐蔽的设置了时间标签。在接受端收到数据包后,就依照时间标签按照正确的速率恢复成原始的适时的数据。不同的媒体格式调时属性是不一样的。但是RTP本身并不负责同步，RTP只是传输层协议，为了 简化了运输层处理，提高该层的效率。将部分运输层协议功能（比如流量控制）上移到应用层 完成。同步就是属于应用层协议完成的。它没有运输层协议的完整功能，不提供任何机制来保 证实时地传输数据，不支持资源预留，也不保证服务质量。RTP报文甚至不包括长度和报文边界的描述。同时RTP协议的数据报文和控制报文的使用相邻的不同端口，这样大大提高了协议的灵活性和处理的简单性。 RTP协议和UDP二者共同完成运输层协议功能。UDP协议只是传输数据包，是不管数据包传输的时间顺序。RTP的协议数据单元是用UDP分组来承载的。在承载RTP数据包的时候，有时候一帧数据被分割成几个包具有相同的时间标签，则可以知道时间标签并不是必须的。而UDP的多路复用让RTP协议利用支持显式的多点投递，可以满足多媒体会话的需求。 RTP协议虽然是传输层协议但是它没有作为OSI体系结构中单独的一层来实现。RTP协议通常根据一个具体的应用来提供服务， RTP只提供协议框架，开发者可以根据应用的具体要求对协议进行充分的扩展。目前，RTP的设计和研究主要是用来满足多用户的多媒体会议的需要，另外它也适用于连续数据的存储，交互式分布仿真和一些控制、测量的应用中。基于RTP的实验和商业产品也层出不穷。最常用的协议是RTMP(Real Time Messaging Protocol，实时消息传送协议)，RTMP是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。还有RTSP,HLS等。 实时传输控制协议RTCP协议 1. RTCP协议： RTCP（Real-time Transpor、Control Protocol）是设计和RTP一起使用的进行流量控制和拥塞控制的服务控制协议。 2. RTCP协议如何工作： 当应用程序开始一个RTP会话时将使用两个端口：一个给RTP，一个给RTCP。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。在RTP的会话之间周期的发放一些RTCP包以用来传监听服务质量和交换会话用户信息等功能。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利 用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。根据用户间的数
(完整版)RTP协议分析
RTP协议分析 一．RTP协议背景 (2) 二．RTP协议原理及工作机制 (2) 2．1 RTP协议原理 (3) 2．1．1 RTP协议原理 (3) 2．1．2 RTCP协议原理 (3) 2．2 RTP数据包格式 (4) 2．2．1 RTP数据包格式 (4) 2．2．2 RTCP数据包格式 (6) 2．3 RTP工作机制 (9) 2．3．1 RTP工作机制 (9) 2．3．2 RTCP工作机制 (9) 三．RTP协议关键技术指标 (10) 3．1 时间戳 (10) 3．2时延 (10) 3．3 抖动 (11) 3．4丢包率 (11) 3．5 会话和流两级分用 (11) 3．6 多种流同步控制 (12) 四．RTP协议应用方案 (12) 4．1 RTP协议应用方案之单播 (12) 4．2 RTP协议应用方案之广播 (12) 4．3 RTP协议应用方案之组播 (13) 4．3.1 RTP协议组播方案总体概述 (13) 4．3.2 RTP协议组播方案服务器端实现 (14) 4．3. 3RTP协议组播方案客户端实现 (14) 4．3. 4RTP协议视频帧率和质量调整策略 (15) 五．RTP协议移植计划 (16) 六．RTP协议安全方面考虑 (16)
一．RTP协议背景 流（Streaming）是近年在Internet上出现的新概念，其定义非常广泛，主要是指通过网络传输多媒体数据的技术总称。流媒体包含广义和狭义两种内涵：广义上的流媒体指的是使音频和视频形成稳定和连续的传输流和回放流的一系列技术、方法和协议的总称，即流媒体技术；狭义上的流媒体是相对于传统的下载-回放方式而言的，指的是一种从Internet上获取音频和视频等多媒体数据的新方法，它能够支持多媒体数据流的实时传输和实时播放。通过运用流媒体技术，服务器能够向客户机发送稳定和连续的多媒体数据流，客户机在接收数据的同时以一个稳定的速率回放，而不用等数据全部下载完之后再进行回放。 流式传输有顺序流式传输(Progressive Streaming)和实时流式传输(Realtime Streaming)两种方式。实时流式传输是实时传送，特别适合现场事件，实时流式传输必须匹配连接带宽，这意味着图像质量会因网络速度降低而变差，以减少对传输带宽的需求。“实时”的概念是指在一个应用中数据的交付必须与数据的产生保持精确的时间关系，这需要相应的协议支持，这样RTP和RTCP就相应的出现了。 实时传输协议RTP（Realtime Transport Protocol）：是针对Internet上多媒体数据流的一个传输协议, 由IETF作为RFC1889发布，现在最新的为RFC3550。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。 实时传输控制协议RTCP（Realtime Transport Control Protocol）：负责管理传输质量,在当前应用进程之间交换控制信息，提供流量控制和拥塞控制服务。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP 和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。 二．RTP协议原理及工作机制 让我们先看一下RTP和RTCP在网络层次中的位置，以便我们更加清楚的了解该协议，如下图1-1所示：
即时通讯软件性能测试_UDP协议
一.UDP和Socket通信步骤 1.UDP Server程序 1、编写UDP Server程序的步骤 (1)使用socket()来建立一个UDP socket，第二个参数为SOCK_DGRAM。 (2)初始化sockaddr_in结构的变量，并赋值。sockaddr_in结构定义： struct sockaddr_in { uint8_t sin_len; sa_family_t sin_family; in_port_t sin_port; struct in_addr sin_addr; char sin_zero[8]; }; 这里使用“08”作为服务程序的端口，使用“INADDR_ANY”作为绑定的IP地址即任何主机上的地址。 (3)使用bind()把上面的socket和定义的IP地址和端口绑定。这里检查bind()是否执行成功，如果有错误就退出。这样可以防止服务程序重复运行的问题。(4)进入无限循环程序，使用recvfrom()进入等待状态，直到接收到客户程序发送的数据，就处理收到的数据，并向客户程序发送反馈。这里是直接把收到的数据发回给客户程序。 2、udpserv.c程序内容： #include
RTP协议全解(H264码流和PS流)-2015-4-22
RTP协议全解（H264码流和PS流） 写在前面：RTP的解析，网上找了很多资料，但是都不全，所以我力图整理出一个比较全面的解析， 其中借鉴了很多文章，我都列在了文章最后，在此表示感谢。 互联网的发展离不开大家的无私奉献，我决定从我做起，希望大家支持。 原创不易，转载请附上链接，谢谢https://www.wendangku.net/doc/3715570807.html,/chen495810242/article/details/39207305 1、RTP Header解析 图1 1) V：RTP协议的版本号，占2位，当前协议版本号为2 2) P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。 3) X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头
4) CC：CSRC计数器，占4位，指示CSRC 标识符的个数 5) M: 标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。 6) PT: 有效荷载类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM图像等,在流媒体中大部分是用来区分音频流和视频流的，这样便于客户端进行解析。 7) 序列号：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。这个字段当下层的承载协议用UDP的时候，网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序，序列号的初始值是随机的，同时音频包和视频包的sequence是分别记数的。 8) 时戳(Timestamp)：占32位，必须使用90 kHz 时钟频率。时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。 9) 同步信源(SSRC)标识符：占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。 10) 特约信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。 注：基本的RTP说明并不定义任何头扩展本身，如果遇到X=1，需要特殊处理 取一段码流如下： 80 e0 00 1e 00 00 d2 f0 00 00 00 0041 9b 6b 49 €?....??....A?kI e1 0f 26 53 02 1a ff06 59 97 1d d2 2e 8c 50 01 ?.&S....Y?.?.?P. cc 13 ec 52 77 4e e50e 7b fd 16 11 66 27 7c b4 ?.?RwN?.{?..f'|? f6 e1 29 d5 d6 a4 ef3e 12 d8 fd 6c 97 51 e7 e9 ??)????>.??l?Q?? cfc7 5e c8 a9 51 f6 82 65 d6 48 5a 86 b0 e0 8c ??^??Q??e?HZ???? 其中，
RTP协议中文版
RFC3550 RTP：实时应用程序传输协议 摘要 本文描述RTP（real-time transport protocol），实时传输协议。RTP在多点传送（多播）或单点传送（单播）的网络服务上，提供端对端的网络传输功能，适合应用程序传输实时数据，如：音频，视频或者仿真数据。RTP没有为实时服务提供资源预留的功能，也不能保证QoS（服务质量）。数据传输功能由一个控制协议（RTCP）来扩展，通过扩展，可以用一种方式对数据传输进行监测控制，该协议（RTCP）可以升级到大型的多点传送（多播）网络，并提供最小限度的控制和鉴别功能。RTP和RTCP被设计成和下面的传输层和网络层无关。协议支持RTP标准的转换器和混合器的使用。 本文的大多数内容和旧版的RFC1889相同。在线路里传输的数据包格式没有改变，唯一的改变是使用协议的规则和控制算法。为了最小化传输，发送RTCP数据包时超过了设定的速率，而在这时，很多的参与者同时加入了一个会话，在这样的情况下，一个新加入到（用于计算的可升级的）计时器算法中的元素是最大的改变。 目录（Table of Contents） 1. 引言（Introduction） 1 1 术语（Terminology） 2 RTP使用场景（RTP Use Scenarios） 2 1 简单多播音频会议（Simple Multicast Audio Conference） 2 2 音频和视频会议（Audio and Video Conference） 2 3 混频器和转换器（Mixers and Translators） 2 4 分层编码（Layered Encodings） 3 定义（Definitions） 4 字节序，校正和时间格式（Byte Order, Alignment, and Time Format） 5 RTP数据传输协议（RTP Data Transfer Protocol） 5 1 RTP固定头域（RTP Fixed Header Fields） 5 2 多路复用RTP会话（Multiplexing RTP Sessions） 5 3 RTP头的配置文件详细变更（Profile-Specific Modifications to the RTP Header） 5 3 1 RTP报头扩展（RTP Header Extension） 6 RTP控制协议（RTP Control Protocol）-- RTCP 6 1 RTCP包格式（RTCP Packet Format） 6 2 RTCP传输间隔（RTCP Transmission Interval） 6 2 1 维护会话成员数目（Maintaining the number of session members） 6 3 RTCP包的发送与接收规则（RTCP Packet Send and Receive Rules） 6 3 1 计算RTCP传输间隔（Computing the RTCP Transmission Interval） 6 3 2 初始化（Initialization） 6 3 3 接收RTP或RTCP（非BYE)包（Receiving an RTP or Non-BYE RTCP Packet） 6 3 4 接收RTCP（BYE）包（Receiving an RTCP BYE Packet） 6 3 5 SSRC计时失效（Timing Out an SSRC）
基于TCP协议的简单即时通信软件的设计与实现
基于TCP协议的网络通信系统的设计与实现 摘要:网络通信，由于其具有实时性、跨平台性、成本低、效率高等优点而受到广泛的使用。设计并实现一个能够处理多用户进行实时、安全的即时通信系统具有较强的现实意义。即时通信的底层通信是通过SOCKET套接字接口实现的。当前的主流UNIX系统和微软的WINDOWS系统都在内核提供了对SOCKET字接口的支持。使用这个统一的接口，可以编写一个可移植的TCP/IP通信程序。使信息能够在INTERNET上可靠的传输。 本文设计并实现了基于局域网内的简单即时通信系统，系统采用C/S模式，底层通信通过SOCKET套接字接口实现，服务器负责客户端的登录验证，好友信息的保存和心跳报文的发送。客户端采用P2P方式实现消息传递，并能实现文件的传输。本文首先讨论了同步套接字，异步套接字，多线程并发执行任务等；然后阐述了客户端、服务器如何使用XML序列化的消息进行通信。 关键词：即时通信；文件传输；套接字；TCP协议 Abstract :Instant messages have several advantages such as real-time, cross-platform, cheap and efficient. To design a Multi-user IM (instant message) architecture is very i mportant in both theory and realism. Instant message based on TCP/IP protocol that is realized by socket interface. Almost all UNIX operation systems and Microsoft's win dows operation systems provide support of socket in the kernel. Using the uniform int erface, we can develop a portable program of TCP/IP, which help us transfer informati on in Internet safely and credibly. The system uses the client/server(C/S) mode. The server takes the responsibility of th e login message of client, the saving of friend message and Message heartbeat. The tra nsmission of the basic messages of the customer end will be designed on P2P architec ture. This thesis explains how the client and server communicate via serializing XML message. Key words: Instant Message; File Transfer; Socket; TCP protocol
RTP-RTCP协议
Southwest university of science and technology 视频信息处理与传输 实验报告 报告名称RTP-RTCP协议 专业班级电子1002班 学生姓名 学号 指导教师
实验四RTP-RTCP协议 一、实验目的 1、了解实时传输协议RTP和实时传输控制协议RTCP的基本原理； 2、学习使用RTP数据报发送实时数据，并接收重组； 3、学会使用Wireshark进行抓包，并分析数据。 二、实验内容 1、RTP协议报文段的说明语句 RTP（Real-time Transport Protocol，实时传输协议）是一个网络传输协议。RTP报文由两部分组成：报头和有效载荷。RTP报头格式如图1所示，其中： 图1 RTP报头格式 V：RTP协议的版本号，占2位，当前协议版本号为2。 P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。 X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头。 CC：CSRC计数器，占4位，指示CSRC 标识符的个数。 M: 标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。 PT: 有效载荷类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM 音频、JPEM图像等。 序列号：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。接收者通过序列号来检测报文丢失情况，重新排序报文，恢复数据。 时戳(Timestamp)：占32位，时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。 同步信源(SSRC)标识符：占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。 特约信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。 2、RTCP协议报文段的说明语句 RTCP（RTP Control Protocol,控制协议）——监控服务质量并传送正在进行的会话参与者的相关信息。RTCP包括五种数据包类型（RFC3550 Page69）：
实时视频传输与控制协议-v2
全球眼 实时视频传输和控制协议v2 修改历史 复审人
一、说明 这份协议描述了视频服务器与流媒体分发服务器、视频服务器与企业客户端之间传输实时视频的方法。文档中没有针对媒体分发服务器与企业客户端（第三方播放器）之间的通信方法，但是媒体分发服务器与企业客户端（第三方播放器）之间的通信方法尊守RTC1889和RPC2326定义的规范。 在这篇文档里我们把象视频服务器这样能够给观看者提供视频数据的设备称为逻辑上的服务端角色（也就是视频源），象企业客户端这样播放视频的终端设备称为逻辑上的客户端角色（也就是接收者或观看者）。流媒体分发服务器同时具有两种角色。 交互流程中列出了两种模式，我们当前要先实现接模式。推模式是为了视频服务器在私网环境时也可以通过流媒体发服务器向用户提供视频服务。推模式暂不实现。 协议中没有提及RTCP协议，但并不影响视频通信质量，而且目前很难实现有效的编解码之间返馈的处理方法，所以现在，以及将来的一段时间都不会考虑RTCP协议，除非出现有效的视频质量控制机制。 本文参考RFC 1889、1890、2326、3550完成，如有不符合标准的、或者不完善的陈述，请提出来，发电子邮件到piaoxichuang@。如果您有更好的想法也可以通过邮件进行交流。 二、协议 通信方式使用RTP over TCP方式。（RTC1889、RFC2326） 1、一个完整的包 网络字节顺序
2、RTP包的封装（RTP over TCP） 网络字节顺序 Channel Identifier：取值0。因为只有一个流在一个TCP连接中传递，同时不使用RTCP协议。参见RFC 2326 [10.12]节。 Lenth：取值为RTP包的大小，包括RTP头部，但不包含本身的4个字节，以BYTE为单位。 3、RTP 12字节头部 网络字节顺序 V：版本，取值2。[可能会使用0值，还没想清楚，可能的使用情况是为了实现防火墙穿透] P：附加数据，取值为0。 X：扩展头，取值为1。 CC：CSRC列表数量，取值为0。 M：记号，取值0或1。关于M字段的取值：如果扩展头中T字段为1，则当一个包（RTP Packet）是一个帧（Sample）的最后一个包时取值1，否则取值0；扩展头中T字段为1时，由于指令长度较小，一个RTP就可以传输完成，所以取值为1。除非要使用多个RTP包传输，最后一个RTP包取值为1，前面的包取值为0。 PT：负载类型，动态，取值96。参见RFC 1890 [7]节。 Sequence Number：RTP包的序号，初始值是随机的，不是0。 Timestamp：以视频编码算法提供者的需要填写或单调增长的时间戳。[将来可能把这个值也传递给视频解码算法中去。] SSRC：随机数，用于在同一个会话中区分不同的流。建议使用MD32。 UINT Y[4] If Y = MD5(X) Then MD32(X) = Y[1] ^ Y[2] ^ Y[3] ^ Y[4] 注：RTP包大小最大值为2048。（因为DSS支持的最大包为2048Bytes）
几种安全的网络传输协议
几种安全的网络传输协议 ·从URL谈起（可以直接跳到第4页看FTPS，HTTPS） 当我们想浏览一个网站的时候，只要在浏览器的地址栏里输入网站的地址就可以了，这个网站地址，术语叫做URL（Uniform Resource Locator)，译成中文即“统一资源定位符”。就像每家每户都有一个门牌地址一样，每个网页也都有一个互联网地址。当你在浏览器的地址框中输入一个URL或是单击一个超级链接时，URL就确定了要浏览的地址。 ·超文本传输协议HTTP 大家一定注意到，在输入网站地址时，http://这一部分通常不用输入，系统软件会自动补上，所有网页地址都少不了它。那么，http 究竟是个什么含义呢？ HTTP 是“超文本传输协议（Hypertext Transfer Protocol）”的意思。 简单地讲，HTTP协议是用于从WWW服务器传输超文本到本地浏览器的传送协议。浏览器通过超文本传输协议(HTTP)，将Web服务器上站点的网页代码提取出来，并翻译成漂亮的网页。 它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示(如文本先于图形)等。这就是你为什么在浏览器中看到的网页地址都是以http://开头的原因。 基于HTTP协议的通讯的基本工作过程如下： 由于HTTP协议是基于请求/响应范式的（相当于客户机/服务器）。一个客户机与服务器建立连接后，发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是MIME信息，包括请求修饰符、客户机信息和可能的内容。服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。 在互联网上，HTTP通讯通常发生在TCP/IP连接之上。缺省端口是TCP 80，但其它的端口也是可用的。HTTP只预示着一个可靠的传输。它并不特别指明网络传输媒介，HTTP传输可以在互联网上完成，也可以在其它网络的其它协议之上完成。 在WWW中，“客户机”与”服务器”是一个相对的概念，只存在于一个特定的连接期间，即在某个连接中的客户机在另一个连接中可能作为服务器。基于HTTP协议的客户机/服务器模式的信息交换过程，它分四个过程：建立连接、发送请求信息、发送响应信息、关闭连接。 任何服务器除了包括HTML文件以外，还有一个HTTP驻留程序，用于响应用户请求。你的浏览器是HTTP客户机，向服务器发送请求，当浏览器中输入了一个开始文件或点击了一个超级链接时，浏览器就向服务器发送了HTTP请求，此请求被送往由IP地址指定的URL。服务器的驻留程序接收到请求，在进行必要的操作后回送所要求的文件。在这一过程中，根据TCP/IP协议的规定，在网络上发送和接收的数据被分成一个或多个数据包（packet），每个数据包包括：要传送的数据；控制信息，即告诉网络怎样处理数据包。TCP/IP协议决定了每个数据包的格式。传输完成后的这些数据包再重新组合，还原为数据信息。从网络层次模型的角度讲，HTTP协议以及下面将要讲述的几种互联网传输协议都属于TCP/IP模型最上层的应用层协议。
RTP RTCP协议简介
即時傳輸協議RTP（Realtime Transport Protocol）：是針對Internet上多媒體資料 流程的一個傳輸協定, 由IETF(Internet工程任務組)作為RFC1889發佈。RTP被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時間資訊和實現流同步。RTP的典型應用建立在UDP上，但也可以在TCP或ATM等其他協議之上工作。RTP本身只保證即時資料的傳輸，並不能為按順序傳送資料包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。 即時傳輸控制協議RTCP（Realtime Transport Control Protocol）：負責管理傳輸品 質在當前應用進程之間交換控制資訊。在RTP會話期間，各參與者週期性地傳送RTCP包，包中含有已發送的資料包的數量、丟失的資料包的數量等統計資料， 因此，伺服器可以利用這些資訊動態地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，能以有效的回饋和最小的開銷使傳輸效率最佳化，故特 別適合傳送網上的即時資料。 RTCP主要有4個功能: （1）用回饋資訊的方法來提供分配資料的傳送品質，這種回饋可以用來進行流量的擁塞控制，也可以用來監視網路和用來診斷網路中的問題； （2）為RTP源提供一個永久性的CNAME（規範性名字）的傳送層標誌，因為在發現衝突或者程式更新重啟時SSRC(同步源標識)會變，需要一個運作痕跡，在一組相關的會話中接收方也要用CNAME來從一個指定的與會者得到相聯繫的資料流程（如音頻和視頻）； （3）根據與會者的數量來調整RTCP包的發送率； （4）傳送會話控制資訊，如可在用戶介面顯示與會者的標識，這是可選功能。 4.2 RTP/RTCP工作過程 工作時，RTP協議從上層接收流媒體資訊碼流（如H.263），裝配成RTP資料包發送給下層，下層協定提供RTP和RTCP的分流。如在UDP中，RTP使用一個偶 數號埠，則相應的RTCP使用其後的奇數號埠。RTP資料包沒有長度限制，它的 最大包長只受下層協議的限制。 4.3 伺服器的演算法 伺服器軟體模型主要有兩種，即併發伺服器和迴圈伺服器。迴圈伺服器(Iterative
实时传输协议(RTP)和实时控制协议(RTCP
公告：2010年SD2.0大会即将在上海召开了～历届参会网友精彩心得集锦[意见反馈][官方博客] 实时传输协议（RTP）和实时控制协议（RTCP）收藏 RTP是一种提供端对端传输服务的实时传输协议，用来支持在单目标广播和多目标广播网络服务中传输实时数据，而实时数据的传输则由RTCP协议来监视和控制。 RTP定义在RFC 使用RTP协议的应用程序运行在RTP之上，而执行RTP的程序运行在UDP的上层，目的 、
从应用开发人员的角度来看，可把RTP执行程序看成是应用程序的一部分，因为开发人员必需把RTP集成到应用程序中。在发送端，开发人员必需把执行RTP协议的程序写入到创建RTP信息包的应用程序中，然后应用程序把RTP信息包发送到UDP的套接接口(socket interface)，如图16-13所示；同样，在接收端，RTP信息包通过UDP套接接口输入到应用程序，因此开发人员必需把执行RTP协议的程序写入到从RTP信息包中抽出媒体数据的应用程序。 图16-13 RTP和UDP之间的接口
现以用RTP传输声音为例来说明它的工作过程。假设音源的声音是64 kb/s的PCM编码声音，并假设应用程序取20毫秒的编码数据为一个数据块(chunk)，即在一个数据块中有160个字节的声音数据。应用程序需要为这块声音数据添加RTP标题生成RTP信息包，这个标题包括声音数据的类型、顺序号和时间戳。然后RTP信息包被送到UDP套接接口，在那里再被封装在UDP信息包中。在接收端，应用程序从套接接口处接收RTP信息包，并从RTP 信息包中抽出声音数据块，然后使用RTP信息包的标题域中的信息正确地译码和播放声音。 如果应用程序不使用专有的方案来提供有效载荷类型(payload type)、顺序号或者时间戳，而是使用标准的RTP协议，应用程序就更容易与其他的网络应用程序配合运行，这是大家都
RTP协议介绍
3.1. RTP协议分析 3.1.1. RTP是什么 RTP全名是Real-time Transport Protocol（实时传输协议）。它是IETF提出的一个标准，对应的RFC文档为RFC3550（RFC1889为其过期版本）。RFC3550不仅定义了RTP，而且定义了配套的相关协议RTCP（Real-time Transport Control Protocol，即实时传输控制协议）。RTP用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。RTP为Internet上端到端的实时传输提供时间信息和流同步，但并不保证服务质量，服务质量由RTCP 来提供。 3.1.2. RTP的协议层次 ——传输层的子层 RTP被划分在传输层，它建立在UDP上。同UDP协议一样，为了实现其实时传输功能，RTP也有固定的封装形式。RTP用来为端到端的实时传输提供时间信息和流同步，但并不保证服务质量。服务质量由RTCP来提供。
3.1.3. RTP协议原理 RTP协议原理比较简单，负责对流媒体数据进行封包并实现媒体流的实时传输，即它按照RPT数据包格式来封装流媒体数据，并利用与它绑定的协议进行数据包的传输，具体见本文2.2.1RTP数据格式；RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。 3.1.3.1. RTP的封装 版本号（V）：2比特，用来标志使用的RTP版本。 填充位（P）：1比特，如果该位置位，则该RTP包的尾部就包含附加的填充字节。 扩展位（X）：1比特，如果该位置位的话，RTP固定头部后面就跟有一个扩
英文文献和中文翻译{RTP-实时软件传输协议}
RTP: A Transport Protocol for Real-Time Applications 1 Introduction This memorandum specifies the real-time transport protocol (RTP), which provides end-to-end delivery services for data with real-time characteristics, such as interactive audio and video. Those services include payload type identification, sequence numbering, times tamping and delivery monitoring. Applications typically run RTP on top of UDP to make use of its multiplexing and checksum services; both protocols contribute parts of the transport protocol functionality. However, RTP may be used with other suitable underlying network or transport protocols (see Section 10). RTP supports data transfer to multiple destinations using multicast distribution if provided by the underlying network. Note that RTP itself does not provide any mechanism to ensure timely delivery or provide other quality-of-service guarantees, but relies on lower-layer services to do so. It does not guarantee delivery or prevent out-of-order delivery, nor does it assume that the underlying network is reliable and delivers packets in sequence. The sequence numbers included in RTP allow the receiver to reconstruct the sender's packet sequence, but sequence numbers might also be used to determine the proper location of a packet, for example in video decoding, without necessarily decoding packets in sequence. While RTP is primarily designed to satisfy the needs of multi- participant multimedia conferences, it is not limited to that particular application. Storage of continuous data, interactive distributed simulation, active badge, and control and measurement applications may also find RTP applicable.