RTP-RTCP协议
RTP_RTCP协议分析
RTP/RTCP协议分析摘要本文主要介绍了RTP/RTCP协议组成，在详细了解和分析RFC3550协议和阅读目前国内外在RTP协议研究成果上给出了使用协议的要求及使用过程中需要注意的问题。
前言RTP/RTCP协议是IETF的音视频传输工作组提出的在Internet和现有局域网上传输实时信息的一个新型协议，是实现实时通信不可缺少的协议。
该协议是专门为交互的音频、视频等实时性数据而设计的。
RTP/RTCP协议由实时传输协议RTP和实时传输控制协议RTCP两部分组成。
RTP负责实时性数据的传输，它工作于UDP和IP多点传送的顶层，用于处理IP网上的视频和音频流。
每个UDP 包均加上一个包含时间标志和符号化方式识别码后发送出去，接收端配以适当的缓冲区，它就可以利用时间标志和序号信息“复原再生”数据包、记录顺序、同步音频、视频和数据以及改善接收端连接重放效果。
RTCP监测数据传输并管理控制信息，它监视迟滞和带宽，并将其通知发送端。
一旦可用带宽变窄，RTCP 立刻将该信息通知发送端，发送端根据此信息，变更符号化方式识别码，继续进行多媒体通信。
RTP/RTCP充分考虑所给定的网络，实现传送质量与给定网络相适应的多媒体通信。
协议提供端到端的实时数据流传输业务，可以满足实时通信的基本要求，但协议本身并不提供对实时应用的服务质量标准，需要有下层的协议提供服务支持。
RTP/RTCP可以满足实时通信的基本要求，但如果要想保证实时应用的带宽，还需要利用RSVP协议。
RSVP装在端系统和路由器中，用以确保端对端的传输带宽。
它能够在数据网络上为实时性音频和视频业务实现带宽预留并设置队列管理方法，尽量减少实时通信中的时间延迟和延时抖动。
使用RTP/RTCP协议之前要对协议进行说明，以符合各种不同的要求，对RTP/RTCP的说明随应用程序而不同，但至少应包括以下两个文件：框架文件：定义净荷类型的代码，并将这些代码映射到净荷的格式之中;定义对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包，包中含有已發送的資料包的數量、丟失的資料包的數量等統計資料，因此，伺服器可以利用這些資訊動態地改變傳輸速率，甚至改變有效載荷類型。
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和RTCP
会话控制技术
by
通信1502 黄奕锋
CONTENTS
01. 多媒体通信协议简介 02. RTP协议和RTCP协议 03. RTP协议应用方案
01. 多媒体通信协议简介
01
概念：
多媒体通信技术是计算机技术、电视技术和通信技术
相互渗透、相互影响的结果。因此，它具有计算机的交互
性、声音和视频的实时性以及通信系统的分布性。
02
用来使接收端周期性地向所有的点用多播方式进行报告。接收端每收到一 个RTP流(一次会话包含有许多的RTP流)就产生一个接收端报告分组RR。
RR分组的内容有：所收到的RTP流的SSRC；该RTP流的分组丢失率(若 分组丢失率太高，发送端就应当适当降低发送分组的速率)；在该RTP流中 的最后一个RTP分组的序号;分组到达时间间隔的抖动等。
(6)参与源数 占4位
这个字段给出后面的参与源标识符的数目。
(7)版本
占2位
当前使用的是版本2。
02
(8)填充P 占1位
在某些特殊情况下需要对应用数据块加密，这往往要求每一个数据块有 确定的长度。如不满足这种长度要求，就需要进行填充。这时就把P位置1， 表示这个RTP分组的数据有若干填充字节。在数据部分的最后一个字节用来 表示所填充的字节数。
02
➢ 实时运输控制协议RTCP (RTP Control Protocol)是与RTP配合使用 的协议，实际上，RTCP协议也是RTP协议不可分割的部分。
➢ RTCP分组也使用UDP来传送，但RTCP并不对音频/视频分组进行 封装。由于RTCP分组很短，因此可把多个RTCP分组封装在一个 UDP用户数据报中。
RTP支持的有效载荷类型有：
实时传输协议(RTP)和实时控制协议(RTCP)
图16-12 RTP是传输层上的协议从应用开发人员的角度来看，可把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合并到他们的产品中，这样就有希望：使用不同公司电话软件的用户之间能够进行通信。
这里需要强调的是，RTP本身不提供任何机制来确保把数据及时递送到接收端或者确保其他的服务质量，它也不担保在递送过程中不丢失信息包或者防止信息包的次序不被打乱。
的确，RTP的封装只是在系统端才能看到，中间的路由器并不区分那个IP数据报是运载RTP信息包的。
RTP允许给每个媒体源分配一个单独的RTP信息包流，例如，摄像机或者麦克风。
RTP与RTCP协议介绍
RTP与RTCP协议介绍转⾃：/113473/25481/本⽂主要介绍RTP与RTCP协议。
author: ZJ 06-11-17Blog:1．流媒体( Streaming Media)1.1流媒体概念流媒体技术是⽹络技术和多媒体技术发展到⼀定阶段的产物。
术语流媒体既可以指在⽹上传输连续时基媒体的流式技术,也可以指使⽤流式技术的连续时基媒体本⾝。
在⽹上传输⾳频、视频等多媒体信息⽬前主要有两种⽅式:下载和流式传输。
采⽤下载⽅式,⽤户需要先下载整个媒体⽂件,然后才能进⾏播放。
由于⽹络带宽的限制,下载常常要花很长时间,所以这种处理⽅式延迟很⼤。
⽽流媒体实现的关键技术是流式传输。
传输之前⾸先对多媒体进⾏预处理(降低质量和⾼效压缩) ,然后使⽤缓存系统来保证数据连续正确地进⾏传输。
使⽤流式传输⽅式,⽤户不必像采⽤下载⽅式那样要等到整个⽂件全部下载完毕,⽽是只需经过⼏秒到⼏⼗秒的启动延时即可在客户端进⾏播放和观看。
此时媒体⽂件的剩余部分将在后台继续下载。
与单纯的下载⽅式相⽐,这种对多媒体⽂件边下载边播放的流式传输⽅式不仅使启动延时⼤幅度地缩短,⽽且对系统缓存容量的需求也⼤⼤降低。
使⽤流式传输的另⼀个好处是使传输那些事先不知道或⽆法知道⼤⼩的媒体数据(如⽹上直播、视频会议等) 成为可能。
到⽬前为⽌,Internet 上使⽤较多的流式视频格式主要有以下三种:RealNetworks 公司的RealMedia ,Apple 公司的QuickTime 以及Microsoft 公司的Advanced Streaming Format (ASF) 。
1.2⽀持流媒体的协议多媒体应⽤的⼀个显著特点是数据量⼤,并且许多应⽤对实时性要求⽐较⾼。
传统的TCP 协议是⼀个⾯向连接的协议,它的重传机制和拥塞控制机制都是不适⽤于实时多媒体传输的。
RTP 是⼀个应⽤型的传输层协议,它并不提供任何传输可靠性的保证和流量的拥塞控制机制。
RTP 位于UDP(User Datagram Protocol) 之上。
RTPRTCP协议学习总结
RTP、RTCP协议学习总结RTP、RTCP与其他协议的关系：从上图中可以看出，RTP被划分在传输层，建立于UDP上。
一、RTP协议：RTP协议是实时传输协议，主要用于VOIP、视频等实时媒体传输的协议，为这些实时媒体数据提供端到端的传送服务。
但是RTP协议没有提供任何确保按时传送数据的机制，也没有提供任何质量保证的机制，因而要实现服务质量必须由下层网络来提供保证。
也就是说RTP协议只管传输，不管传输的视频或者语音质量是否良好也不管对端是否收到。
那么传输的视频质量和语音质量由谁来控制呢？？这就要用到和RTP 协议关系非常密切的子协议，RTCP协议。
RTP数据报文每一个RTP数据报文都由头部和负载两个部分组成，其中头部前12个字节的含义是固定的，而负载则可以是音频或者视频数据。
RTP报头的报文格式各字段的含义如下：版本（V）：2 个比特，表示RTP 的版本号。
填充（P）：1 个比特，置“1”表示用户数据最后加有填充位，用户数据中最后一个字节是填充位计数，它表示一共加了多少个填充位。
在两种情况下可能需要填充，一是某些加密算法要求数据块大小固定；二是在一个低层协议数据包中装载多个RTP 分组。
扩展（X）：1 个比特，置“1”表示RTP 报头后紧随一个扩展报头。
CSRC 计数（CC）：4 个比特，表示CSRC 标识符的数量。
CSRC标识紧跟在RTP固定头部之后，用来表示RTP数据包的来源；RTP协议允许在同一个会话中存在多个数据源，它们可以通过RTP混合器合并为一个数据源。
标记（M）：1 个比特，其具体解释由应用文档来定义。
例如，对于视频流，它表示一帧的结束，而对于音频，则表示一次谈话的开始。
载荷类别（PT）：7 个比特，标明RTP负载的格式，包括所采用的编码算法、采样频率、承载通道等。
序列号（SN）：2 个字节，每发送一个RTP 数据包该序号增加1。
用来为接收方提供探测数据丢失的方法，但是如何处理丢失的数据则是应用程序自己的事情，RTP协议本身并不负责数据的重传。
RTP与RTCP协议在实时音视频传输中的作用与优化策略
RTP与RTCP协议在实时音视频传输中的作用与优化策略实时音视频传输（Real-time Audio and Video Transport）是指通过网络传输实时音频和视频数据的过程。
在这个过程中，RTP（Real-time Transport Protocol）和RTCP（Real-time Transport Control Protocol）这两个协议起到了重要的作用。
本文将探讨RTP与RTCP协议在实时音视频传输中的作用，并提出一些优化策略。
一、RTP协议的作用与优化策略RTP协议是实时音视频传输的关键组件，它负责将音频和视频数据进行分组，并在传输过程中提供时序和同步的功能。
RTP协议的作用主要包括以下几个方面：1.数据分组：RTP将音频和视频数据按照一定的策略进行分组，每个数据包都包含了一个序列号和时间戳。
这些信息可以帮助接收方对数据进行重组和同步。
2.时序与同步：RTP协议通过序列号和时间戳等机制，确保接收方可以按照正确的顺序和时间播放音频和视频数据，从而保持音视频的同步性。
3.传输控制：RTP协议可以通过调整传输速率和丢包恢复等机制，控制音视频数据在网络上的传输质量。
这对于实时音视频传输来说非常关键，可以保证音视频的流畅性和稳定性。
为了优化RTP协议的性能和传输效果，可以采取以下策略：1.选择合适的编解码算法：不同的音频和视频编解码算法对传输带宽的要求不同。
选择适合网络条件的编解码算法可以降低传输延迟，提高数据传输效率。
2.优化数据分组策略：合理设置RTP数据包的大小和分组方式，可以降低网络传输的延迟和丢包率。
例如，将音频和视频数据进行合理的拆分和分组，避免大的数据包对网络传输造成的负担。
3.动态调整传输速率：根据网络带宽和质量的变化，采用自适应的传输速率控制策略。
例如，可以根据网络拥塞程度和接收端的缓冲状态来调整传输速率，以达到最优的传输效果。
二、RTCP协议的作用与优化策略RTCP协议是RTP协议的补充，主要用于实现音视频传输过程中的控制和反馈。
RTPRTCP协议
Southwest university of science and technology视频信息处置与传输实验报告报告名称RTP-RTCP协议专业班级电子1002班学生姓名学号指导教师实验四RTP-RTCP协议一、实验目的一、了解实时传输协议RTP和实时传输操纵协议RTCP的大体原理；二、学习利用RTP数据报发送实时数据，并接收重组；3、学会利用Wireshark进行抓包，并分析数据。
二、实验内容一、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报文有效载荷中的所有特约信源。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
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）：表1 RTCP的五种分组类型第二部分是长度为20个字节的发送端信息，每个SR都含有这部分信息。
它对发送端传输的数据进行计数。
每个字段的含义如下：NTP时间标志：64位。
表示SR的发送时间。
它与从接收端返回的时间标志配合用来计算在发送端和接收端间的数据传输时间。
RTP时间标志：32位。
与NTP时间标志对应的时间值。
它用于同步与NTP 时间标志同步的数据源。
也可用于接收端估算RTP时钟频率。
发送端数据包计数：32位。
从开始传输到产生SR数据包这段时间内由发送端发送的RTP数据包。
发送端改变其SSRC标识符时重新设置该计数值。
第三部分是0个或多个RR数据块。
数据块的数量由接收最后一个报告以来该发送端所收听的其它数据源的数量确定。
每个RR数据块通过接收来自单同步源的RTP数据包传输统计信息。
由于冲突而使数据源改变其SSRC标识符时，接收端不改变其统计信息。
统计信息有：SSRC_n(数据源标识符)：32位。
SSRC标识符，在RR数据块中与数据源有关的信息。
丢失率：8位。
发送前一个SR或RR数据包后来自数据源SSRC_ n的RTP三、实验过程1、完成RTP报文段的说明语句struct RTP_PDU {unsigned short Version:2; /* protocol version */unsigned short P:1; /* padding flag */unsigned short X:1; /* header extension flag */unsigned short CC:4; /* CSRC count */unsigned short M:1; /* marker bit */unsigned short PT:7; /* payload type */u_int16 SEQ; /* sequence number */u_int32 TS; /* timestamp */u_int32 SSRC; /* synchronization source */u_int32 CSRC[1]; /* optional CSRC list */}2、完成RTCP报文段的说明语句struct RTCP_PUD {unsigned short Version:2; /* protocol version */unsigned short P:1; /* padding flag */unsigned short Count:5; /* varies by packet type */unsigned short PT:8; /* RTCP packet type */u_int16 Length; /* pkt len in words, w/o this word */ }3、用Wireshark软件抓取视频和音频网络数据报，并给出RTP和RTCP数据报的分析结果。
在用Wireshark进行抓包实验中，首先是对其进行软件设置。
我在实验过程中的设置如图2。
图2 软件设置在Capture Options的设置中，将Interface设置为图上所示。
该字段指定我想用于进行捕捉的接口。
一次只能使用一个接口。
我的IP address是：192.168.0.100。
Capture Filter是捕捉过滤器，我只是选择抓取UDP的包。
进行简单的设置之后，点击开始进行抓包，等待几秒后，停止抓包，得到如图3所示。
图3 抓包四、数据结果分析整个窗口被分成三个部分：最上面为数据包列表，用来显示截获的每个数据包的总结性信息；中间为协议树，用来显示选定的数据包所属的协议信息；最下边是以十六进制形式表示的数据包内容，用来显示数据包在物理层上传输时的最终形式。
使用Wireshark可以很方便地对截获的数据包进行分析，包括该数据包的源地址、目的地址、所属协议等。
选取第一个包进行分析：帧号时间源地址目的地址高层协议包内信息概况No. Time Source Destination Protocol Info1 0.000000 218.0.156.24 192.168.0.100 UDP 62 Source port: 31843 Destination port:64512 源端口目的端口以下为物理层的数据帧概况,如图4所示：图4 物理层的数据帧Frame 1: (62 bytes on wire, 62 bytes captured) 1号帧，线路62字节，实际捕获62字节Arrival Time: NOV 11, 2013 09:49:10.062652000 捕获日期和时间Epoch Time: 1384134550.062652000 seconds 捕获时间[Time delta from previous captured frame:0.00000 seconds]此包与前1个捕获帧的时间间隔[Time delta from previous displayed frame:0.00000 seconds] 此包与前1个显示帧的时间间隔[Time since reference or first frame: 0.00 seconds]此包与第1帧的间隔时间Frame Number: 1 帧序号Packet Length: 62 bytes 帧长度Capture Length: 62 bytes 捕获长度[Frame is marked: False] 此帧是否做了标记：否[Protocols in frame: eth:ip:udp:data] 帧内封装的协议层次结构以下为数据链路层以太网帧头部信息,如图5所示：图5 数据链路层Ethernet II, Src: Tp-LinKT_6d:05:86 (00:21:27:6d: 05:86), Dst: ControlR _00: d2:16 (00:e0:80:00:d2:16)以太网协议版本II，源地址：厂名_序号（网卡地址），目的：厂名_序号（网卡地址）Destination: ControlR_00:d2:16(00:e0:80:00:d2:16)目的：厂名_序号（网卡地址）Source: Tp-LinKT_6d:05:86 (00:21:27:6d:05:86) 源：厂名_序号（网卡地址）Type: IP (0x0800) 帧内封装的上层协议类型为IP（十六进制码0800）以下为互联网层IP包头部信息，如图6所示：图6 互联网层IP包Internet Protocol, Src: 218.30.118.189 (192.168.0.100) , Dst: 192.168.0.100(192.168.0.100) 互联网协议，源IP地址，目的IP地址Version: 4 互联网协议IPv4Header length: 20 bytes IP包头部长度Differentiated Services Field:0x00(DSCP 0x00:Default;ECN:0x00)差分服务字段Total Length: 48 IP包的总长度Identification:0xb7cd (47051) 标志字段Flags:0x00 记字段Fragment offset: 0 分段偏移量（将一个IP包分段后传输时，本段的标识）Time to live: 52 生存期TTLProtocol: UDP (17) 此包内封装的上层协议为UDPHeader checksum:0x97cc[correct] 头部数据的校验[正确的] Source: 218.30.118.189 (192.168.0.100) 源IP地址Destination: 192.168.0.100(192.168.0.100) 目的IP地址以下为传输层TCP数据段头部信息,如图7所示:图7User Datagram Protocol, Src Port: 31843 (31843), Dst Port:64512(64512) 传输控制协议UDP的内容Source port: 31843 (31843) 源端口名称（端口号）Destination port: 64512(64512) 目的端口名称（端口号）Length: 28 长度Checksum: 0x0000 UDP数据段的校验和(由于选取的第一个目的地址是本机)Data: (20 bytes) 可选项五、实验中遇到的问题本次实验的主要问题在于文献的阅读和软件的使用，由于知识面的限制，对RTP和RTCP协议的了解和认识比较浅显，对于文献的阅读能力还需进一步提高；另外对于软件的使用和数据的分析，还是需要熟读协议的手册，对照抓包软件抓到数据进行分析和理解。