來源 | HaaS技術社群
1、音視訊通信
音視訊通信完整流程有如下幾個環節：采集、編碼、前後處理、傳輸、解碼、緩沖、渲染等。
每一個細分環節，還有更細分的技術子產品。比如，前後處理環節有美顔、濾鏡、回聲消除、噪聲抑制等，采集有麥克風陣列等，編解碼有H.263，H.264、H.265等，傳輸就涉及到了本文重點介紹的RTSP/RTMP/RTP/RTCP等流媒體協定以及相關的信令技術。
2、流媒體協定
流媒體協定一般分成傳輸控制封包的協定和傳輸媒體資料的協定。傳輸控制封包的協定一般用于協商流媒體通信建立的參數等，如SIP，RTSP等協定。傳輸媒體資料封包一般用于傳輸音視訊媒體資料，如RTP/RTCP/SRTP/SRTCP等協定。此外，也有部分協定将控制信令和媒體信令放在一個連接配接裡傳輸的，如RTMP等協定。下面會詳細介紹這些具體的協定。
2.1、SIP協定
SIP（Session Initiation Protocol，會話初始協定）是由IETF（Internet Engineering Task Force，網際網路工程任務組）制定的多媒體通信協定。它是一個基于文本的應用層控制協定，用于建立、修改和釋放一個或多個參與者的會話。SIP 是一種源于網際網路的IP 語音會話控制協定，具有靈活、易于實作、便于擴充等特點。
SIP作為控制信令一般要和RTP/RTCP媒體信令配合起來用在音視訊通話上，整個音視訊互動如上圖所示。互動細節如下：
- Alice發起Invite請求（攜帶SDP，媒體初始化描述資訊），邀請Bob進行音視訊通話。
- 如果Bob線上，伺服器将Alice的請求轉發給Bob。
- Bob收到Alice的請求之後，回180 Ringing振鈴以及200 ok的确認接入音視訊通話。
- Alice收到确認後，使用RTP/RTCP進行音視訊通話。
- Alice發Bye請求，挂斷電話。
- Bob回200 ok，确認挂斷電話。
SIP協定原來比較多的用于視訊會議，現在基本上被RTMP協定取代了。
2.2、RTMP
RTMP(Real Time Messaging Protocol, 實時消息傳輸協定）Adobe Systems公司為Flash播放器和伺服器之間音頻、視訊和資料傳輸 開發的開放協定。RTMP是基于TCP協定的一個協定族，包括RTMP基本協定及RTMPT/RTMPS/RTMPE等多種變種，主要用來在 Flash/AIR 平台和支援 RTMP 協定的流媒體/互動伺服器之間進行音視訊和資料通信。
如上圖所示，RTMP的互動流程中，需要經過握手，建立連接配接，建立流，播放，停止等階段。在播放流媒體之前，需要先建立網絡連接配接（NetConnection）和網絡流（NetStream）。網絡連接配接表示用戶端和伺服器之間的連通關系，而網絡流代表了發送多媒體的通道。是以，用戶端和伺服器之間隻能建立一個網絡連接配接，而基于這個網絡連接配接可以建立很多網絡流。
RTMP 是目前主流的流媒體傳輸協定，廣泛用于直播領域，目前市面上絕大多數的直播産品都采用了這個協定。
2.3、RTSP
RTSP（Real Time Streaming Protocol, 實時流傳輸協定），RFC2326，，是基于TCP或UDP的一個應用層協定，由哥倫比亞大學、網景和RealNetworks公司送出的IETF RFC标準。該協定定義了一對多應用程式如何有效地通過IP網絡傳送多媒體資料。SIP作為控制信令一般要和RTP/RTCP媒體信令配合起來用在音視訊媒體傳輸上。
RTSP的互動流程如上圖所示。其互動細節如下：
- 用戶端詢問（OPTIONS）伺服器目前有哪些方法。
- 伺服器提供所有可用的方法。
- 用戶端請求（DESCRIBE）伺服器提供SDP（媒體初始化描述資訊）。
- 伺服器提供SDP（媒體初始化描述資訊）
- 設定（SETUP）音視訊的會話屬性，以及傳輸模式，提醒伺服器建立會話。
- 伺服器建立會話，傳回會話描述辨別符以及會話的相關資訊。
- 用戶端請求播放（PLAY）。
- 伺服器響應請求。
- 服務求發送（RTP/RTCP）流媒體資料。
- 用戶端請求關閉（TEARDOWN）會話。
- 伺服器響應關閉請求。
和RTMP協定一樣，RTSP也經常用于直播。但RTSP協定一般傳輸的是ts,mp4格式的流，而RTMP協定一般傳輸的是flv，f4v格式流。 RTSP傳輸一般需要2-3個通道，指令和資料通道分離，RTMP一般在TCP一個通道上傳輸指令和資料。目前使用比較多的浏覽器和Flash都不支援rtsp支援。是以，RTSP在直播領域，沒有RTMP使用廣泛。
2.4、RTP/RTCP
RTP（real-time transport protocol, 實時傳輸協定)，在多點傳送（多點傳播）或單點傳送（單點傳播）的網絡服務上，提供端對端的網絡傳輸功能，适合應用程式傳輸實時資料，如：音頻，視訊或者仿真資料。RTP沒有為實時服務提供資源預留的功能，也不能保證QoS（服務品質）。資料傳輸功能由一個控制協定（RTCP）來擴充，通過擴充，可以用一種方式對資料傳輸進行監測控制，該協定（RTCP）可以更新到大型的多點傳送（多點傳播）網絡，并提供最小限度的控制和鑒别功能。RTP和RTCP被設計成和下面的傳輸層和網絡層無關。協定支援RTP标準的轉換器和混合器的使用。
RTP由IETF的多媒體傳輸工作小組1996年在RFC 1889中公布,現行版本為RFC3550，詳見:https://tools.ietf.org/html/rfc3550。
RTCP（Real-time Transport Control Protocol或RTP Control Protocol，實時傳輸控制協定）是實時傳輸協定（RTP）的一個姐妹協定，由RFC 3550定義（取代廢棄的RFC 1889）。RTP 使用一個 偶數 UDP port ；而RTCP 則使用 RTP 的下一個 port，也就是一個奇數 port。RTCP與RTP聯合工作，RTP實施實際資料的傳輸，RTCP則負責将控制包送至電話中的每個人。其主要功能是就RTP正在提供的服務品質做出回報。
RTCP協定處理機根據定義了五種類型的封包：
SR: sender report
RR: receiver report
SDES: source description items.
BYE: indicates end of participation.
APP: application specific functions
SR封包用于發送端報告本端的資料發送統計資訊和資料接收統計資訊，RR封包用于報告本端的資料接收統計資訊，SDES封包用于報告本端的描述性資訊，BYE在本端離開會話時發送，而APP則是特定于應用的資料。
2.5、SRTP/SRTCP
SRTP（Secure Real-time Transport Protocol，安全實時傳輸協定）是在實時傳輸協定RTP基礎上所定義的一個協定，旨在為單點傳播和多點傳播應用程式中的實時傳輸協定的資料提供加密、消息認證、完整性保證和重放保護。它是由David Oran（思科）和Rolf Blom（愛立信）開發的，并最早由IETF于2004年3月作為RFC3711釋出。
由于RTP協定和RTCP協定有着緊密的聯系，SRTP同樣也有一個伴生協定RTCP（Secure RTCP或SRTCP， 安全實時傳輸控制協定）。SRTCP為RTCP提供類似的與安全有關的特性，就像SRTP為RTP提供的那些一樣。
在使用RTP或RTCP時，使不使用SRTP或SRTCP協定是可選的；但即使使用了SRTP或SRTCP，所有它們提供的特性（如加密和認證）也都是可選的，這些特性可以被獨立地使用或禁用。唯一的例外是在使用SRTCP時，必須要用到其消息認證特性。
3、流媒體信令技術
目前主流的音視訊方案商都會提供包括流媒體信令協定在内的音視訊方案SDK，不需要開發者重新移植開發流媒體協定。一般廠商會同步提供端側和雲側的SDK，SDK使用的流媒體協定可能是SIP/RTMP/RTSP/RTCP/SRTP/SRTCP等協定, 也可能是廠商私有自定義的協定，但基本流媒體協定的原理幾乎都是類似的。大多數時候，隻需要在廠商SDK的流媒體協定的基礎上做信令的開發，就可以完成一個完整的流媒體通信。
如上圖所示，設計了一套基于MQTT的SIP協定的信令，目的是為了用這套信令去協商擷取廠商SDK流媒體通信的參數。具體流程如下：
- Alice向伺服器發SIP Invite消息邀請Bob通話。
- 伺服器收到SIP Invite消息請求後，通過廠商SDK，确認Bob是否處于線上狀态。
- 如果Bob不線上，直接傳回異常給Alice，如果Bob線上，将Invite請求轉發給Bob。
- Bob無論同意還是拒絕都發出回複給伺服器，由伺服器轉發給Alice。
- 如果Bob同意接收Alice的視訊通話，伺服器同時向Alice和Bob發送廠商流媒體通信的參數，如聊天房間号等資訊。
- Alice和Bob使用伺服器發送的流媒體通信的參數，配置到內建流媒體通信端側SDK的應用上。Alice和Bob就可以正常進行通信。
- Alice發起SIP bye請求斷開整個通話，伺服器和Bob收到請求後，同步斷開連接配接，并回收對應的資源。
音視訊通信涉及的協定技術，遠遠不止以上這些，包括NAT，TURN，STUN和ICE等很多技術本文并未涉及，未來會進一步深入研究這些技術細節。
開發者支援
如需更多技術支援，可加入釘釘開發者群，或者關注微信公衆号。
更多技術與解決方案介紹，請通路HaaS官方網站
https://haas.iot.aliyun.com。