最近做視頻編解碼部分，傳輸采用RTP協議。對學習做個記錄

　　1、簡介

　　實時傳輸協議（Real-time Transport PRotocol或簡寫RTP）是一個網絡傳輸協議，它是由IETF的多媒體傳輸工作小組1996年在RFC 1889中公布的。RTP被定義為傳輸音頻、視頻、模擬數據等實時數據的傳輸協議，與傳統的注重的高可靠的數據傳輸的運輸層協議相比，它更加側重的數據傳輸的實時性，此協議提供的服務包括數據順序號、時間標記、傳輸控制等。RTP通常與輔助控制協議RTCP一起工作，RTP只負責實時數據的傳輸，RTCP負責對RTP的通信和會話進行帶外管理（如流量控制、擁塞控制、會話源管理等）。RTP和RTCP配合使用，能以有效的反饋和最小的開銷使傳輸效率最佳化，故特別適合傳送網上的實時數據。

　　2、RTP的協議層次

　　可以看出RTP和UDP一樣位于傳輸層，實時語音、視頻數據經過模數轉換和壓縮編碼處理后，先送給RTP封裝成為RTP數據單元，RTP數據單元被封裝為UDP數據報，然后再向下遞交給ip封裝為IP數據包。這里有個地方需要注意：RTP分組只包含RTP數據，而控制是由另一個配套協議RTCP提供。RTP在端口號1025到65535之間選擇一個未使用的偶數UDP端口號，而在同一次會話中的RTCP則使用下一個奇數UDP端口號。RTP通常和RTCP一起工作，在RTP會話期間，各參與者周期的發送RTCP消息。RTCP消息含有已發送數據的丟包統計和網絡擁塞等信息，服務器可以利用這些信息動態的改變傳輸速率，甚至改變凈荷的類型。RTCP消息也被封裝為UDP數據報進行傳輸。

　　3、RTP的協議封裝

version (V): 2 bits

標明RTP版本號。協議初始版本為0，RFC3550中規定的版本號為2。

padding (P): 1 bit

如果該位被設置，則在該packet末尾包含了額外的附加信息，附加信息的最后一個字節表示額外附加信息的長度（包含該字節本身）。該字段之所以存在是因為一些加密機制需要固定長度的數據塊，或者為了在一個底層協議數據單元中傳輸多個RTP packets。

extension (X): 1 bit

如果該位被設置，則在固定的頭部后存在一個擴展頭部，格式定義在RFC3550 5.3.1節。

CSRC count (CC): 4 bits

在固定頭部后存在多少個CSRC標記。

marker (M): 1 bit

該位的功能依賴于profile的定義。profile可以改變該位的長度，但是要保持marker和payload type總長度不變（一共是8 bit）。

payload type (PT): 7 bits

標記著RTP packet所攜帶信息的類型，標準類型列出在RFC3551中。如果接收方不能識別該類型，必須忽略該packet。

sequence number: 16 bits

序列號，每個RTP packet發送后該序列號加1，接收方可以根據該序列號重新排列數據包順序。

timestamp: 32 bits

時間戳。反映RTP packet所攜帶信息包中第一個字節的采樣時間。

SSRC: 32 bits

數據源標識。在一個RTP session其間每個數據流都應該有一個不同的SSRC。

CSRC list: 0 to 15 items, 每個源標識32 bits

貢獻數據源標識。只有存在Mixer的時候才有效。如一個將多聲道的語音流合并成一個單聲道的語音流，在這里就列出原來每個聲道的SSRC。

　　4、關于RTP的類庫。

　　看了網上的一些資料，.NET方面對RTP的封裝看到了一個RTP.NET.DLL。有個人的博客專門介紹了這個DLL，今天只是嘗試接收了一下，發現可以接收到數據。在使用這個DLL的時候，出現了“其他信息: 混合模式程序集是針對“v2.0.50727”版的運行時生成的，在沒有配置其他信息的情況下，無法在 4.0 運行時中加載該程序集。”異常，解決方法很簡單。在APP.Config中configuration下添加

　　<startup useLegacyV2RuntimeActivationPolicy="true">
      　　<supportedRuntime version="v4.0"/>
      </startup>

　　5、總結

　　（1）對RTP理論方面進行了一些學習，覺得現在還能理解能用到的就是上面這一些。

　　（2）初步調用了一下RTP.NET.DLL，能接收到數據

　　（3）發送的數據使用的是VLC media player工具進行測試

　　（4）參考資料有很多，基本也是摘錄。

　　每天記錄一點點，就能進步一點點....