实时传输协议：RTP、RTCP、RTSP介绍

http://blog.csdn.net/heanyu/article/details/6202500

RTP(Real Time Transport Protocol) 

      RTP是针对Internet上多媒体数据流的一个传输协议, 由IETF(Internet工程任务组)作为RFC1889发布。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP或ATM等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。

  RTP工作机制 
威胁多媒体数据传输的一个尖锐的问题就是不可预料数据到达时间。但是流媒体的传输是需要数据的适时的到达用以播放和回放。rtp协议就是提供了时间标签,序列号以及其它的结构用于控制适时数据的流放。在流的概念中”时间标签”是最重要的信息。发送端依照即时的采样在数据包里隐蔽的设置了时间标签。在接受端收到数据包后,就依照时间标签按照正确的速率恢复成原始的适时的数据。不同的媒体格式调时属性是不一样的。但是rtp本身并不负责同步，rtp只是传输层协议，为了简化运输层处理，提高该层的效率。将部分运输层协议功能（比如流量控制）上移到应用层完成。同步就是属于应用层协议完成的。它没有运输层协议的完整功能，不提供任何机制来保证实时地传输数据，不支持资源预留，也不保证服务质量。rtp报文甚至不包括长度和报文边界的描述。同时rtp协议的数据报文和控制报文的使用相邻的不同端口，这样大大提高了协议的灵活性和处理的简单性。 
  rtp协议和udp二者共同完成运输层协议功能。udp协议只是传输数据包，不管数据包传输的时间顺序。 rtp的协议数据单元是用udp分组来承载的。在承载rtp数据包的时候，有时候一帧数据被分割成几个包具有相同的时间标签，则可以知道时间标签并不是必须的。而udp的多路复用让rtp协议利用支持显式的多点投递，可以满足多媒体会话的需求。 
  rtp协议虽然是传输层协议但是它没有作为osi体系结构中单独的一层来实现。rtp协议通常根据一个具体的应用来提供服务，rtp只提供协议框架，开发者可以根据应用的具体要求对协议进行充分的扩展。 
  RTP协议的报文结构 
     RTP头格式：

开始12个八进制出现在每个RTP包中，而CSRC标识列表仅出现在混合器插入时。各段含义如下： 
①版本（V） 
version (V): 2 bits   2位，标识RTP版本,协议初始版本为0，RFC3550中规定的版本号为2。。 
②填充标识（P） 
padding (P): 1 bit   1位，如设置填充位，在包末尾包含了额外的附加信息，它不属于有效载荷。附加信息的最后一个字节表示额外附加信息的长度（包含该字节本身）。该字段之所以存在是因为某些加密算法需要固定大小的填充字，或为在底层协议数据单元中携带几个RTP包。 
③扩展（X） 
extension (X): 1 bit           1位，如果该位被设置，则在固定的头部后存在一个扩展头部，格式定义在RFC3550 5.3.1节。 
④CSRC计数（CC） 
CSRC count (CC): 4 bits    4位，CSRC计数包括紧接在固定头后标识CSRC个数。 
⑤标记（M） 
marker (M): 1 bit               1位，标记解释由设置定义，目的在于允许重要事件在包流中标记出来。设置可定义其他标示位，或通过改变位数量来指定没有标记位，该位的功能依赖于profile的定义。profile可以改变该位的长度，但是要保持marker和payload type总长度不变（一共是8 bit）。。 
⑥载荷类型（PT） 
payload type (PT): 7 bits   7位，记录后面资料使用哪种 Codec ， receiver 端找出相应的 decoder 解碼出來，该位标记着RTP packet所携带信息的类型，标准类型列出在RFC3551中。如果接收方不能识别该类型，必须忽略该packet。 
⑦系列号 
sequence number:16 bits  16位，系列号随每个RTP数据包发送后而增加1，接收方可以根据该序列号重新排列数据包顺序，或者探测包损失。系列号初值是随机的，使对加密的文本攻击更加困难。 
⑧时标 
timestamp: 32 bits             32位，时标反映RTP数据包中第一个八进制数的采样时刻，采样时刻必须从单调、线性增加的时钟导出，以允许同步与抖动计算。时标可以让receiver端知道在正确的时间将资料播放出来。 

   由上图可知，如果只有系列号，并不能完整按照顺序的将data播放出来，因为如果data中间有一段是没有资料的，只有系列号的话会造成错误，需搭配上让它知道在哪个时间将data正确播放出来，如此我们才能播放出正确无误的信息。 
⑨SSRC 
SSRC: 32 bits                     32位，SSRC段标识同步源。此标识不是随机选择的，目的在于使同一RTP包连接中没有两个同步源有相同的SSRC标识，也就是在一个RTP Session其间每个数据流都应该有一个不同的SSRC。尽管多个源选择同一个标识的概率很低，所有RTP实现都必须探测并解决冲突。如源改变源传输地址，也必须选择一个新SSRC标识以避免插入成环行源。 
⑩CSRC列表 
CSRC list: 0 to 15 items     bits0到15项，每项32位。CSRC列表表示包内的对载荷起作用的源。标识数量由CC段给出。如超出15个作用源，也仅标识15个。CSRC标识由混合器插入，采用作用源的SSRC标识。只有存在Mixer的时候才有效。如一个将多声道的语音流合并成一个单声道的语音流，在这里就列出原来每个声道的SSRC。

RTCP(Real Time Contorl Protocol) 

      RTCP负责管理传输质量在当前应用进程之间交换控制信息。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。 
RTCP工作机制 
当应用程序开始一个rtp会话时将使用两个端口：一个给rtp，一个给rtcp。rtp本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠rtcp提供这些服务。在rtp的会话之间周期的发放一些rtcp包以用来传监听服务质量和交换会话用户信息等功能。rtcp包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。rtp和rtcp配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。根据用户间的数据传输反馈信息，可以制定流量控制的策略，而会话用户信息的交互，可以制定会话控制的策略。 
     RTCP协议将控制包周期发送给所有连接者，应用与数据包相同的分布机制。低层协议提供数据与控制包的复用，如使用单独的UDP端口号。RTCP执行下列四大功能： 
    主要是提供数据发布的质量反馈。是作为RTP传输协议的一部分，与其他传输协议的流和阻塞控制有关。反馈对自适应编码控制直接起作用，但IP组播经验表明，从发送者收到反馈对诊断发送错误是致关重要的。给所有参加者发送接收反馈报告允许问题观察者估计那些问题是局部的，还是全局的。诸如IP组播等发布机制使网络服务提供商类团体可能接收反馈信息，充当第三方监控者来诊断网络问题。反馈功能由RTCP发送者和接收者报告执行。 
     RTCP带有称作规范名字（CNAME）的RTP源持久传输层标识。如发现冲突，或程序重新启动，既然SSRC标识可改变，接收者需要CNAME跟踪参加者。接收者也需要CNAME 与相关RTP连接中给定的几个数据流联系 
     前两种功能要求所有参加者发送RTCP包，因此，为了RTP扩展到大规模数量，速率必须受到控制。让每个参加者给其它参加者发送控制包，就大独立观察参加者数量。该数量用语计算包发送的速率。 
     第四个可选功能是传送最小连接控制信息，如参加者辨识。最可能用在"松散控制"连接，那里参加者自由进入或离开，没有成员控制或参数协调，RTCP充当通往所有参加者的方便通道，但不必支持应用的所有控制通讯要求。在IP组播场合应用RTP时，前3个功能是必须的，推荐用于所有情形。RTP应用设计人员必须避免使用仅在单播模式下工作的机制，那将导致无法扩展规模。

RTCP数据报 
在RTCP通信控制中，RTCP协议的功能是通过不同的RTCP数据报来实现的，主要有如下几种类型： 
①SR:发送端报告，所谓发送端是指发出RTP数据报的应用程序或者终端，发送端同时也可以是接收端。 
②RR:接收端报告，所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。 
③SDES:源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。 
④BYE:通知离开，主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。 
⑤APP:由应用程序自己定义，解决了RTCP的扩展性问题，并且为协议的实现者提供了很大的灵活性。

SDES: 源描述RTCP包 
SDES 包为三层结构，由头与数据块组成，数据块可以没有，也可有多个，组成项描述块所表明的源。项描述如下： 
版本（V）、填充（P）、长度： 如SR包中所描述。 
包类型（PT）： 8位，包含常数202，识别RTCP SDES包。 
源计数（SC）： 5位，包含在SDES包中的SSRC/CSRC块数量，零值有效，但没有意义。 
源描述项内容如下： 
CNAME: 规范终端标识SDES项 CNAME标识属性如下： 
        如发生冲突或重启程序，由于随机分配的SSRC标识可能发生变化，需要CNAME项提供从SSRC标识到仍为常量的源标识的绑定。 象SSRC标识，CNAME标识在RTP连接的所有参加者中应是唯一的。 为了提供一套相关RTP连接中某个参加者所采用的跨多媒体工具间的绑定，CNAME应固定为那个参加者。 为方便第三方监控，CNAME应适合程序或人员定位源。 
NAME：用户名称SDES项 
BYE：断开RTCP包 
     如混合器接收到一个BYE包，混合器转发BYE包，而不改变SSRC/CSRC 标识。如混合器关闭，它也应该发出一个BYE包，列出它所处理的所有源，而不只是自己的SSRC标识。作为可选项，BYE包可包括一个8位八进制计数，后跟很多八进制文本，表示离开原因，如："camera malfunction"或"RTP loop detected"。字符串具有同样的编码，如在SDES 中所描述的。如字符串填充包至下32位边界，字符串就不以空结尾；否则，BYE包以空八进制填充。 
APP：定义应用的RTCP包 
APP包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识别名称的APP包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA注册子类型和名称段。

RTSP（Real Time Streaming Protocol）

协议特点：

● 可扩展性：新方法和参数很容易加入RTSP。 
● 易解析：RTSP可由标准 HTTP或MIME解析器解析。 
● 安全：RTSP使用网页安全机制。 
● 独立于传输：RTSP传输通道，可使用不可靠数据包协议（UDP）或可靠数据包协议（RDP），如要实现应用级可靠，可使用诸如TCP的可靠流协议。 
● 记录设备控制：协议可控制记录和回放设备。 
● 适合专业应用：通过SMPTE 时标，RTSP支持帧级精度，允许远程数字编辑。 
● 演示描述中立：协议未强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少需包含一个RTSP URI。 
● 代理与防火墙友好：协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个“缺口”。 
● 适当的服务器控制：如用户启动一个流，则也可以停止一个流。 
● 传输协调：实际处理连续媒体流前，用户可协调传输方法。 
● 性能协调：如基本特征无效，则必须有一些清理机制让用户决定那种方法不生效。这允许用户提出适合自己的界面。 

同其他协议的关系：

       RTSP在功能上与HTTP有重叠，最明显的交叉是在流媒体内容的发布上——----大多是通过网页进行的。目前的协议规范同时允许网页服务器和流媒体服务器支持RTSP实现。例如，演示描述可通过HTTP或RTSP获取，这样减少了基于浏览器情况下的往返传递时间，同时也支持独立的RTSP 服务器与不依赖HTTP的客户端通信。 
      但是，RTSP与HTTP 的本质差别在于以下五个方面 
● RTSP和HTTP是两个不同的协议，它们采用不同的方法和协议标志符。 
● RTSP协议的数据发送不占用协议带宽，并且以不同的协议发送。 
● HTTP是一个不对称协议，客户端发出请求，服务器应答。在RTSP中，客户端和服务器都可发出请求，且请求是有状态的。 
● HTTP是一个无状态协议，而RTSP在任何情况下，必须保持一定状态，以便在请求确认后的很长时间内，仍可设置参数，控制媒体流。 
● RTSP使用ISO 10646（UTF-8）定义，而不使用ISO 8859-1定义，保持与当前的HTML一致。 
       虽然大多数实时媒体采用RTP作为传输协议，但RTSP并不绑定RTP。重用HTTP的功能至少在两个方面有好处:安全和代理。由于要求非常接近，因此在缓存、代理和授权上采用HTTP功能是有价值的。

1. 实时流协议RTSP

      RTSP[3]协 议以客户服务器方式工作，它是一个多媒体播放控制协议，用来使用户在播放从因特网下载的实时数据（音频和视频流）时能够进行控制，如：暂停/继 续、后退、前进等。因此 RTSP 又称为“因特网录像机遥控协议”。

1.1. RTSP协 议简介

      要实现 RTSP 的控制功能，不仅要有协议，而且要有专门的媒体播放器(media player)和 媒体服务器(media server)。媒体服务器与媒体播放器的关系是服务器与客户的关系。媒体服务器与普通的万维网服务器的最大区别就是媒体服务器支持流式音频和视频的传送，因而在客户端的媒体播放器可以边下载边播放（需要先缓存一小段时间的节 目）。但从普通万维网服务器下载多媒体节目时，是先将整个文件下载完毕，然后再进行播放。RTSP 仅仅是使媒体播放器能控制多媒体流的传送。因此，RTSP 又称为带外协议，而多媒体流是使用 RTP 在带内传送的。

图1 RTSP与RTP和RTCP的关系

1.2. RTSP的 报文结构

      RTSP有两类报文：请求报文和响应报文。 
      请求报文是指从客户向服务器发送请求报文，响应报文是指从服务器到客户的回答。由于RTSP是面向正文的(text-oriented)，因此在报文中的每一个字段都是一些 ASCII 码串，因而每个字段的长度都是不确定的。RTSP报文由三部分组成，即开始行、首部行和实体主体。在请求报文中，开始行就是请求行，RTSP请求报文的结构如图2所 示。

图2 RTSP请求报文的结构

       RTSP请求报文的方法包括：OPTIONS（获得服务器提供的可用方法）、DESCRIBE（得到会话描述信息）、SETUP（客户端提醒服务器建立会话，并确定传输模式）、TEARDOWN（客户端发起关闭请求）、ANNOUNCE(更新会话描述）、PLAY（客户端发送播放请求）、PAUSE（临时停止流，而不释放服务器资源）、GET_PARAMETER（取得流控制参数，可能某些服务器不支持）和SET_PARAMETER（设置流控制参数，可能某些服务器不支持）。响应报文的开始行是状态行，RTSP响应报文的结构如图3所示。图3 RTSP响应报文的结构

1.3. RTSP交互过程 
C表 示RTSP客户端，S表示RTSP服务端 
① C->S:    OPTION request //询问S有 哪些方法可用 
    S->C:    OPTION response //S回 应信息中包括提供的所有可用方法 
② C->S:    DESCRIBE request //要求得到S提供 的媒体初始化描述信息 
    S->C:    DESCRIBE response //S回 应媒体初始化描述信息，主要是sdp 
③ C->S:    SETUP request //设置会话属性，以及传输模式，提醒S建 立会话 
    S->C:    SETUP response //S建 立会话，返回会话标识符及会话相关信息 
④ C->S:    PLAY request //C请求播放 
    S->C:    PLAY response //S回 应请求信息 
    S->C:    发送流媒体数据 
⑤ C->S:    TEARDOWN request //C请 求关闭会话 
    S->C:    TEARDOWN response //S回应请求 
上述的过程是标准的RTSP流程，其中第3步和第4步是必需的。 

      参考http：和rtsp在功能上有相似重叠的地方，RTSP采用了HTTP/1.1 大多数的状态码，并且增加了RTSP特定的状态码。 
HTTP协议定义了8种可能的请求方法： 
———————————— 
GET                 检索URI中标识资源的一个简单请求 
HEAD               与GET方法相同，服务器只返回状态行和头标，并不返回请求文档 
POST                服务器接受被写入客户端输出流中的数据的请求 
PUT                 服务器保存请求数据作为指定URI新内容的请求 
DELETE            服务器删除URI中命名的资源的请求 
OPTIONS          关于服务器支持的请求方法信息的请求 
TRACE             Web服务器反馈Http请求和其头标的请求 
CONNECT        已文档化但当前未实现的一个方法，预留做隧道处理 
———————————— 
rtsp和http的协议规范分别在RFC2326 和 RFC2616有详细描述 
mms协议为微软的私有协议，未公开协议。采用私有自定义控制结构体来发送命令，而不是像http，rtsp协议采用发送文本命令控制

==================================================================================================

RTP/RTSP/RTCP的区别 用一句简单的话总结：RTSP发起/终结流媒体、RTP传输流媒体数据 、RTCP对RTP进行控制，同步。
之所以以前对这几个有点分不清，是因为CTC标准里没有对RTCP进行要求，因此在标准RTSP的代码中没有看到相关的部分。而在私有RTSP的代码中，有关控制、同步等，是在RTP Header中做扩展定义实现的。
另外，RFC3550可以看作是RFC1889的升级文档，只看RFC3550即可。

• RTP：实时传输协议（Real-time Transport Protocol）
  
  • RTP/RTCP是实际传输数据的协议 
    
  • RTP传输音频/视频数据，如果是PLAY，Server发送到Client端，如果是RECORD，可以由Client发送到Server 
    
  • 整个RTP协议由两个密切相关的部分组成：RTP数据协议和RTP控制协议（即RTCP）
    
• RTSP：实时流协议（Real Time Streaming Protocol，RTSP）
  
  • RTSP的请求主要有DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN,OPTIONS等，顾名思义可以知道起对话和控制作用 
    
  • RTSP的对话过程中SETUP可以确定RTP/RTCP使用的端口，PLAY/PAUSE/TEARDOWN可以开始或者停止RTP的发送，等等
    
• RTCP：
  
  • RTP/RTCP是实际传输数据的协议 
    
  • RTCP包括Sender Report和Receiver Report，用来进行音频/视频的同步以及其他用途，是一种控制协议 
    

以下是每个协议的概要介绍：
一、RTP数据协议 
    RTP数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个RTP数据报都由头部（Header）和负载（Payload）两个部分组成，其中头部前12个字节的含义是固定的，而负载则可以是音频或者视频数据。RTP数据报的头部格式如图1所示：


    其中比较重要的几个域及其意义如下： 

• CSRC记数（CC）：表示CSRC标识的数目。CSRC标识紧跟在RTP固定 头部之后，用来表示RTP数据报的来源，RTP协议允许在同一个会话中存在多个数据源，它们可以通过RTP混合器合并为一个数据源。例如，可以产生一个 CSRC列表来表示一个电话会议，该会议通过一个RTP混合器将所有讲话者的语音数据组合为一个RTP数据源。
• 负载类型（PT）：标明RTP负载的格式，包括所采用的编码算法、采样频率、承载通道等。例如，类型2表明该RTP数据包中承载的是用ITU G.721算法编码的语音数据，采样频率为8000Hz，并且采用单声道。
• 序列号：用来为接收方提供探测数据丢失的方法，但如何处理丢失的数据则是应用程序自己的事情，RTP协议本身并不负责数据的重传。
• 时间戳：记录了负载中第一个字节的采样时间，接收方能够时间戳能够确定数据的到达是否受到了延迟抖动的影响，但具体如何来补偿延迟抖动则是应用程序自己的事情。

    从RTP数据报的格式不难看出，它包含了传输媒体的类型、格式、序列号、时间戳以及是否有附加数据等信息，这些都为实时的流媒体传输提供了相应的基础。RTP协议的目的是提供实时数据（如交互式的音频和视频）的端到端传输服务，因此在RTP中没有连接的概念，它可以建立在底层的面向连接或面向非连接的传输协议之上；RTP也不依赖于特别的网络地址格式，而仅仅只需要底层传输协议支持组帧（Framing）和分段（Segmentation）就足够了；另外RTP本身还不提供任何可靠性机制，这些都要由传输协议或者应用程序自己来保证。在典型的应用场合下，RTP一般是在传输协议之上作为应用程序的一部分加以实现的，如图2所示：



二、RTCP控制协议 
    RTCP控制协议需要与RTP数据协议一起配合使用，当应用程序启动一个RTP会话时将同时占用两个端口，分别供RTP和RTCP使用。RTP本身并不能为按序传输数据包提供可靠的保证，也不提供流量控制和拥塞控制，这些都由RTCP来负责完成。通常RTCP会采用与RTP相同的分发机制，向会话中的所有成员周期性地发送控制信息，应用程序通过接收这些数据，从中获取会话参与者的相关资料，以及网络状况、分组丢失概率等反馈信息，从而能够对服务质量进行控制或者对网络状况进行诊断。 

    RTCP协议的功能是通过不同的RTCP数据报来实现的，主要有如下几种类型： 

• SR：发送端报告，所谓发送端是指发出RTP数据报的应用程序或者终端，发送端同时也可以是接收端。
• RR：接收端报告，所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。
• SDES：源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。
• BYE：通知离开，主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。
• APP：由应用程序自己定义，解决了RTCP的扩展性问题，并且为协议的实现者提供了很大的灵活性。

    RTCP数据报携带有服务质量监控的必要信息，能够对服务质量进行动态的调整，并能够对网络拥塞进行有效的控制。由于RTCP数据报采用的是多播方式，因此会话中的所有成员都可以通过RTCP数据报返回的控制信息，来了解其他参与者的当前情况。
    在一个典型的应用场合下，发送媒体流的应用程序将周期性地产生发送端报告SR，该RTCP数据报含有不同媒体流间的同步信息，以及已经发送的数据报和字节 的计数，接收端根据这些信息可以估计出实际的数据传输速率。另一方面，接收端会向所有已知的发送端发送接收端报告RR，该RTCP数据报含有已接收数据报 的最大序列号、丢失的数据报数目、延时抖动和时间戳等重要信息，发送端应用根据这些信息可以估计出往返时延，并且可以根据数据报丢失概率和时延抖动情况动 态调整发送速率，以改善网络拥塞状况，或者根据网络状况平滑地调整应用程序的服务质量。


三、RTSP实时流协议 
    作为一个应用层协议，RTSP提供了一个可供扩展的框架，它的意义在于使得实时流媒体数据的受控和点播变得可能。总的说来，RTSP是一个流媒体表示协议，主要用来控制具有实时特性的数据发送，但它本身并不传输数据，而是必须依赖于下层传输协议所提供的某些服务。RTSP可以对流媒体提供诸如播放、暂停、快进等操作，它负责定义具体的控制消息、操作方法、状态码等，此外还描述了与RTP间的交互操作（RFC2326）。

    RTSP在制定时较多地参考了HTTP/1.1协议，甚至许多描述与HTTP/1.1完全相同。RTSP之所以特意使用与HTTP/1.1类似的语法和操作，在很大程度上是为了兼容现有的Web基础结构，正因如此，HTTP/1.1的扩展机制大都可以直接引入到RTSP中。
    由RTSP控制的媒体流集合可以用表示描述（Presentation Description）来定义，所谓表示是指流媒体服务器提供给客户机的一个或者多个媒体流的集合，而表示描述则包含了一个表示中各个媒体流的相关信 息，如数据编码/解码算法、网络地址、媒体流的内容等。
    虽然RTSP服务器同样也使用标识符来区别每一流连接会话（Session），但RTSP连接并没有被绑定到传输层连接（如TCP等），也就是说在整个 RTSP连接期间，RTSP用户可打开或者关闭多个对RTSP服务器的可靠传输连接以发出RTSP 请求。此外，RTSP连接也可以基于面向无连接的传输协议（如UDP等）。

    RTSP协议目前支持以下操作： 

• 检索媒体：允许用户通过HTTP或者其它方法向媒体服务器提交一个表示描述。如表示是组播的，则表示描述就包含用于该媒体流的组播地址和端口号；如果表示是单播的，为了安全在表示描述中应该只提供目的地址。
• 邀请加入：媒体服务器可以被邀请参加正在进行的会议，或者在表示中回放媒体，或者在表示中录制全部媒体或其子集，非常适合于分布式教学。
• 添加媒体：通知用户新加入的可利用媒体流，这对现场讲座来讲显得尤其有用。与HTTP/1.1类似，RTSP请求也可以交由代理、通道或者缓存来进行处理。