在這裡并不講解rtp/rtcp、rtsp、264等協定，隻是分析記錄一下rtsp流程封包，也不對封包進行過多的解析，因為已經被Wireshark分析的很徹底了。
本文更多的是做一個備忘錄使用，圖檔堆疊而成。
1.基本描述
一個攝像頭IPC，ip 192.168.1.88
PC的ip 192.168.1.2
PC上VLC軟體，在網絡串流輸入：
然後Wireshark抓封包來分析吧。
- 首先當然是TCP的三次握手建連接配接了
- 然後開始rtsp的互動流程，從Option到Play
- 然後開始rtp傳音視訊資料，rtcp做控制
- 最後VLC上停止播放，也就是發個TearDown，停止傳輸，RTCP的goodbye，還有TCP的斷開連接配接
2.RTSP細節 下面開始具體分析一下RTSP具體流程：
Opiton---Describe--Setup-Play--------.............-------Teardown
C表示RTSP用戶端即PC，S表示RTSP服務端即攝像頭
2.1 Option
C->S: OPTION request //詢問S有哪些方法可用
S->C: OPTION response //S回應資訊中包括提供的所有可用方法
這裡提供的方法有如上。
2.2 Describe
C->S: DESCRIBE request //要求得到S提供的媒體初始化描述資訊
S->C: DESCRIBE response //S回應媒體初始化描述資訊，主要是sdp，這裡面有個簡單的SDP協定
2.3 Setup
C->S: SETUP request //設定會話屬性，以及傳輸模式，提醒S建立會話
S->C: SETUP response //S建立會話，傳回會話辨別符及會話相關資訊
這裡的setup有兩個，即分别對應前面的trackID=1、trackID=2，也就是Describe中的視訊與音頻了。
2.4 Play
C->S: PLAY request //C請求播放
S->C: PLAY response //S回應請求資訊
2.5 發送資料
S->C: 發送流媒體資料
在上面的play指令後将開始流傳輸，這塊與rtp/rtcp相關，單獨摘出來在後面介紹。
2.6 Teardown
C->S: TEARDOWN request //C請求關閉會話
S->C: TEARDOWN response //S回應請求
這之後還會有：rtcp發送goodbye、tcp斷開連接配接。
2.6 其他
在這裡補充一個get_parameter：
3.流傳輸
在上面RTSP細節第4步攝像頭回應了Play Response後，将會開始傳輸流資料，這裡包括了視訊流與音頻流，在Describe中看到為：
3.1視訊傳輸
在H264協定裡定義了三種幀，完整編碼的幀叫I幀，參考之前的I幀生成的隻包含差異部分編碼的幀叫P幀，還有一種參考前後的幀編碼的幀叫B幀，對定義的了解以及264的處理方法可以在網上進一步了解。
于是剛開始傳輸的是第一個I幀，而I幀資料前會有一個參數集傳輸：
這三條具體為：
根據本RTP荷載規範, 大于00的NRI值訓示相對傳輸優先級, 象編碼器決定的一樣。 MANE可以使用本資訊保護更重要的NAL單元。最高的傳輸優先級是11, 依次是 10, 01;00 最低。H.264編碼器必須根據H.264規範設定NRI值(subclause 7.4.1)當nal_unit_type 範圍的是1到12. 特别是, H.264規範要求對于nal_unit_type為6，9，10，11，12的NAL單元的NRI的值應該為0。對于nal_unit_type等于7，8 (訓示順序參數集或圖像參數集)的NAL單元,H.264編碼器應該設定NRI為11 (二進制格式）對于nal_unit_type等于5的主編碼圖像的編碼片NAL單元(訓示編碼片屬于一個IDR圖像), H.264編碼器應設定NRI為11。這也就對上面做出了解釋。
後面開始真正的圖像資料傳輸，I幀分片傳輸，P幀分片傳輸。
I幀的第一片：
I幀的中間片：
I幀的最後一片：
然後開始P幀，同樣列舉開始中間結尾三片：
再看第一幀與第二幀，也就是上面提到的第一個I幀，和緊跟其後的第一個P幀，這兩幀的Timestamp相差360，也就是9000/25。
随後圖像大變動後會有新的一個I幀開始，然後再尾随一串P幀：
3.2音頻傳輸
3.2 RTCP控制