前段時間由於工作需要做了一個視頻直播/智能家居類的應用。算是對iOS音視頻專欄中流媒體處理做了一次小結。這里想把整個開發流程紀錄下來，一方面是和大家共同探討學習，另一方面也可以方便自己以后查漏補缺。
整個開發沒有借助任何第三方框架，所有流媒體協議都是一行行敲上去的，為什么呢？呵呵 授之以魚不如授之以漁！
下面開始先了解下整個軟件的架構。
前端我們在IOS audio&video 專欄中已經介紹的非常詳細了，包括攝像頭、音視頻的各種處理都做了詳細的分析。后端我們也在IOS audio&video 專欄的FFmpeg中、高級使用中也做了詳細的介紹，這里也不再討論。下面就網絡部分做詳細的分析。
（1）RTCP
RTCP：RTP Control Protocol，實時傳輸控制協議，一般和RTP配合使用，主要用於數據傳輸的監視，控制功能。同時RTCP是基於UDP傳輸的。RTCP傳輸的這些信息非常重要，主要包括：時間戳（用於同步）、序列號（用於丟包和重排序檢測）、以及負載格式（用於說明數據的編碼格式）。簡單概括一下，就是用於QoS反饋和同步媒體流。與RTP比較而言，其帶寬一半占用只有RTP的5%左右。非常小。
根據不同的使用狀態，RTCP分為下面幾種情況：
直播、智能家居類項目只要用到發送端報告，這里我們會在后面的代碼中詳細分析。
（2）RTP
Real-time Transport Protocol,實時傳輸協議，一般用於多媒體數據的傳輸。音視頻主要通過這個協議傳輸，它是建立在UDP協議上的，效率更高但允許丟包。所以在媒體重組時需要做不少工作。RTP協議包格式如下：
（3）SDP
我們先來看看抓包的網絡請求過程：
服務器響應數據。我們關心的部分：RTSP
response=RTSP/1.0 200 OK
CSeq: 1
Content-base: rtsp://192.168.36.168/
Date: 2015年7月29日 GMT+8下午2:52:00
Content-Type:application/sdp
Content-Length:424
SDP部分：
v=0
o=-1804289383 1804289383 IN IP4 192.168.36.168
s=Livestream from iOS
c=INIP4 0.0.0.0
t=00
a=control:*
m=video0 RTP/AVP 96
b=TIAS:85528
a=maxprate:9.0000
a=control:streamid=1
a=rtpmap:96H264/90000
a=mimetype:string;"video/H264"
a=framesize:96720-480
a=Width:integer;720
a=Height:integer;480i
a=fmtp:96packetization-mode=1;profile-level-id=64001e;sprop-parameter-sets=Z2QAHqxWwLQ9pqAgICBA,KO4CPLA=
可以很清晰的看到RTSP協議是包含兩部分的，第一部分為rtsp傳輸協議，另一部分是SDP協議。SDP准確的說其實不能算是傳輸層協議，而要規划到會話層協議部分。SDP（SessionDescription Protocol）是服務器端生成的描述媒體文件的編碼信息以及所在服務器的鏈接等信息的文件，客戶端通過它來設置播放軟件的參數。
（4）RTSP
有了以上的分析，我們基本了解了整個結構，那么還剩下最后一部分，RTSP協議。實時流傳輸協議，是TCP/IP協議體系中的一個應用層協議。和Http協議類似。至於協議的具體結構我們放在后面和代碼一起講。
下面看看一個RTSP流媒體交互的簡單過程：這是一個比較典型的請求過程：
1. Client->Server:OPTION request //詢問S有哪些方法可用
1. Server->Client:OPTION response //S回應信息中包括提供的所有可用方法
2. Client->Server:DESCRIBE request //要求得到S提供的媒體初始化描述信息
2. Server->Client:DESCRIBE response //S回應媒體初始化描述信息，主要是sdp
3. Client->Server:SETUP request //設置會話的屬性，以及傳輸模式，提醒S建立會話
3. Server->Client:SETUP response //S建立會話，返回會話標識符，以及會話相關信息
4. Client->Server:PLAY request //C請求播放
4. Server->Client:PLAY response //S回應該請求的信息
Server->Client:發送流媒體數據
5. Client->Server:TEARDOWN request //C請求關閉會話
5. Server->Client:TEARDOWN response //S回應該請求