音视频流媒体涉及协议

不管是视频还是语音，不管以哪种方式：实时、回放... 都离不开4步

1. 采集数据码
2. 编码
3. 传输打包
4. 解码打包
5. 视声渲染

硬件或是软件的支持在前后又大体分为两类：美化、增强

美化例如声卡、回声消除、美颜等等，增强则针对视频或是声音的码率变向的优化提高

在这些步骤中，音视频协议始终是贯彻接收或是发送的核心

音视频协议

大致分为二种，传输控制报文和传输音视频媒体数据

SIP协议

多用于语音通话设备，像各类设备上基于网络的语音对接功能，几乎可以无脑选用该协议进行通讯

SIP（Session Initiation Protocol，会话初始协议）是由IETF（Internet Engineering Task Force，因特网工程任务组）制定的多媒体通信协议。

通讯机制得力于互联网的IP语音会话控制协议，会话的概念使其灵活、容易实现、便于扩展。

建立SIP会话的逻辑采取了握手确认策略，即必须一问一答后最终建立通讯会话，简略步骤如下：

1. 呼叫方请求服务器发送INVITE信号
2. 服务器接收后，立马返回100 Trying确认信号
3. 同时，服务器向被呼叫方转发INVITE信号
4. 被呼叫方收到后，立马返回180 Ringing响铃信号，该信号直接由服务器转发至呼叫方
5. 被呼叫方同意本次会话连接后，返回 200 OK信号给服务器，同时服务器转发至呼叫方
6. 呼叫方接收到第一个200 OK信号后确认ACK信号响应给被呼叫方，两端开始会话通讯
7. 通过RTP/RTCP协议对话
8. 通话结束，发送Bye 信号对对方，断开本次连接

来自网上的图简：

SIP协议灵活的关键，是因为他作为一个应用层的会话协议，还可同时支持多种传统的传输协议，比如：UDP、TCP、TLS

因此过去的大多视频需求也是通过SIP协议实现，不过现在基本都被RTMP取代了，现在的适用点仅在语音对讲上。

RTMP协议

RTMP(Real Time Messaging Protocol, 实时消息传输协议）Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输 开发的开放协议。RTMP是基于TCP协议的一个协议族，包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种，主要用来在 Flash/AIR 平台和支持 RTMP 协议的流媒体/交互服务器之间进行音视频和数据通信。

选用RTMP协议主要多用来解决多媒体数据传输流的多路复用和分包的问题。并且由于协议设计上的低延时性，音视频同步，复用网络的特点，是目前直播推流的实时场景主流的传输协议之一。

他的协议组成大致分为三块：

1. 握手阶段
2. 消息传输
3. 块传输

握手阶段和大多协议一样，是客户端与服务端确认连接的不可缺少的组成，其工作原理为以下步骤：

1. 客户端与服务器建立TCP连接。
2. 双方通过握手过程确认协议版本及交换随机数等信息。
3. 客户端发送连接命令（connect）到服务器。
4. 服务器响应连接命令，返回连接结果。
5. 客户端与服务器建立流（stream）进行音视频数据传输。
6. 在传输过程中，双方可以发送控制命令，如播放（play）、暂停（pause）等。
7. 当连接关闭时，双方结束消息传输并断开连接。

网络图简：

块传输

RTMP在收发数据的时候并不是以Message为单位的，而是把Message拆分成Chunk发送，而且必须在一个Chunk发送完成之后才能开始发送下一个Chunk。每个

Chunk中带有MessageID代表属于哪个Message，接受端也会按照这个id来将chunk组装成Message，和UDP的打包传输相似。

RTSP协议

RTSP(Real Time Streaming Protocol):实时流媒体协议,是由Real network 和 Netscape共同提出的如何有效地在IP网络上传输流媒体数据的应用层协议，RTSP提供一种可扩展的框架，使能够提供能控制的，按需传输实时数据，如音频流、视频流、metadata; 遵循规范IETF RFC 2326,4567,6064，其语法和操作参考了HTTP/1.1，基于文本的协议，采用ISO10646字符集，使用UTF-8编码；承载RTSP的传输层协议为TCP，默认端口554；如果是RTSP-over-HTTP tunneling，则默认TCP端口为8080；实时流数据由不同的协议传输，比如RTP/RTCP完成数据流和控制命令的传输。

目前主要作为视声功能的协议，因为自带客户端指定时间点查询的回放功能，以及其丰富的控制功能和实时性。是智能安防，监控，MP4等场景下最优的协议解决方案。

不过他的局限性基于他的协议设计，对网络环境有较大的稳定依赖，因此对网络功能性的场景不太支持，比如直播。

其设计的交互细节，大致如下：

1. 客户端询问（OPTIONS）服务器目前有哪些方法。
2. 服务器提供所有可用的方法。
3. 客户端请求（DESCRIBE）服务器提供SDP（媒体初始化描述信息）。
4. 服务器提供SDP（媒体初始化描述信息）
5. 设置（SETUP）音视频的会话属性，以及传输模式，提醒服务器建立会话。
6. 服务器建立会话，返回会话描述标识符以及会话的相关信息。
7. 客户端请求播放（PLAY）。
8. 服务器响应请求。
9. 服务求发送（RTP/RTCP）流媒体数据。
10. 客户端请求关闭（TEARDOWN）会话。
11. 服务器响应关闭请求。

网络图简：

总结

基于当前JAVA的工作环境很难在工作上接触到流媒体协议相关内容，不过因为和设备端同事对接相近功能时，总会好奇这些协议，与我认知中的传统协议UDP\TCP的区别，因此记录下这篇科普笔记。

总结：不管是什么协议都离不开握手连接这一核心理念，各个协议使用差距巨大的原因无非就是这几点：

• 网络占宽
• 内存KB
• 通讯效率
• 消息传输
• ...