流媒体协议RTSP初篇（一）

72 阅读 0 评论 48 点赞

我是靠谱客的博主火星上夏天，最近开发中收集的这篇文章主要介绍流媒体协议RTSP初篇（一），觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

今日天气微凉，小雨稀稀拉拉的落下，写写文章开心一点。

一、前情提要之工作流程
RTSP、RTP、RTCP、SDP四个协议一般是打包使用的，各司其职完成传输媒体流的使命。大致流程如下：
身份卡：
老板： RTSP
秘书： SDP
RTCP : 质量经理
RTP : 小工
小剧场：
老板A: 有媒体资源
老板B：有播放平台
某天A和B坐在一起聊天喝茶。
老板A：我把我的资源推给你，你来推广，整不？
老板B：来谈谈，让俺看你有啥资源。
然后A的秘书就带着各种资料出场介绍。
秘书A: 我们的资源有xxx,您看看可以不
老板B: 嗯~ 俺可以。
此时老板A就派出了质量经理和小工，让经理出具质量报告，小工负责搬运媒体流。
搬运过程中，老板B手下的质量经理也会提出各种意见，指出小工偷懒等问题。
最终，A和B说这次合作很愉快，下次再见。

二、RTSP与小弟们的关系

1.网络层次上划分

RTSP和SDP只能基于TCP协议进行传输，RTP和RTCP则两者皆可。通过TCP的传输是为了保证不丢包，UDP则是更能适应网络环境。在UDP的时候就需要考虑丢包，以及乱序重排等问题。
在这里插入图片描述
2.各协议职责上划分
RTSP：负责会话的建立，即谈成这笔生意
SDP : 负责数据的格式以及有哪些数据（音频流、视频流）的告知
RTCP : 负责检测数据的质量
RTP : 负责传输数据
（大致意思是老板只管谈生意，秘书整理公司的物资清单，老板不会管小弟怎么做，做的好不好，只有质量经理可以了解）

三、RTSP会话流程 — 老板间的谈话

1.拉流：客户端向服务端请求流量（与推流不同的地方已经标粗），配图为基于TCP的RTP

c->s : Client 发送option request向Server询问，有哪些操作是允许的。
option：会携带请求的 url
Cseq：每次请求和回复的标记，例 client的Option的请求和 server的 option 响应的 Cseq值是一样的。
authoriuzation : 记录登录信息，例如用户名密码
s->c : Server 回复允许的操作记录在public字段中
server: 服务器的名字
public : 允许的操作，例如暂停（pause）,关闭会话(teardown)
c->s : Client 发送 descirbe 请求获得Server的媒体流信息
accept: 告诉服务器，请发个sdp格式的消息过来，别的消息不接受的
s->c : Server 回复 sdp
content-type : 携带的消息类型是sdp的, 报文最下面就会携带sdp的消息（SDP会在中篇进行阐述）
c->s : Client 发送setup ,请求建立会话，此时会将传输的方式以及端口等放在 transport字段中
transport ：告知Server以什么形式来传输流量，RTP/AVP — UDP方式， RTP/AVP/TCP — TCP方式，udp中还会告知本端重新建立流量通道的端口。
user_agent : 表示本端使用的应用名称
s->c : Server 回复同样通过transport字段携带传输信息
transport ：告知Client中传输rtp的ssrc（即媒体流的编号），udp中还会告知本端重新建立流量通道的端口。
c->s : Client 发送play , 询问服务器是否可以开始传输数据了。
s->c : Server 回复允许并会携带 url 在 RTP-info中,且此时会携带range:npt 数据以记录流的播放时间
s->c : Server 通过RTP发送数据
c->s : Client 发送teardown 表示关闭会话
s->c : Server 回复 bye