RTSP協議媒體資料發包相關的細節

標籤：des   http   io   sp   on   資料   問題   時間   工作   

最近完成了一RTSP代理網關，這是第二次開發做RTSP協議相關的開發工作了，相比11年的簡單粗糙的版本，這次在底層TCP/IP通訊和RTSP協議上都有了一些新的積累，這裡記錄一下。基本的RTSP協議互動流程去讀rfc2326就可以了，這裡就不贅述了。這裡說一些實際用VLC/MPlayer進行測試時，發現的與媒體資料收發相關的細節問題，如下

1，SETUP請求之後，播放器會向在SETUP請求中協商的通訊連接埠發送NAT穿透UDP訊息（模式UDP作為底層傳輸協議時），其作用如下

當播放器與伺服器之間隔有路由器是，這些訊息可以觸發這些路由器在NAT表中增加對應SNAT表項，實現打洞，服務端在接受到這些訊息時，應該從UDP訊息中取出對應NAT映射後的連接埠作為實際媒體資料發送目標連接埠，如此的話媒體資料包即可沿著剛才這些訊息打的洞，逐級的返回到原始的播放器，否則由於NAT代理的原因，在外部是無法直接將媒體資料包發給路由器後面的播放器的。

2,Transport頭：本身的作用是用於用戶端與服務的協商通訊參數的，其中訊息中的destination/source分別只是了本條訊息的目的IP和源IP，若服務端在Transport中指定了IP，那麼後續NAT穿透包即以此處指定的IP作為目的地。如果Server也是在在路由器後面，通過連接埠映射的方式對外提供服務，而在SETUP相應中，直接通過getsockname()擷取服務介面的IP，那麼對應擷取到的是服務主機在內網的IP，若將此IP填入到Transport的source中，那麼播放器後續會以此IP作為目的IP發送NAT穿透訊息，這樣自然是錯誤的。

解決方案是在SETUP響應中Transport頭中可以不包含source欄位播放器，會參考Content-Base頭中的IP，或以RTSP連結的目的IP作為NAT穿透訊息發送目的IP

3，Content-Base頭：本身是用於制定相對路徑的base路徑，實際完整的路徑是Content-Base制訂的url+給定的相對路徑組成的，這個在rfc2068-http 14.11節中有描述，但這也會影響播放器發送NAT穿透訊息時的目標地址。見上面Transport頭中描述的內容

4，採用UDP作為媒體資料發送資料時，最好也簡單實現一個類似於TCP慢啟動的機制，否則在non-block fd上短時間內快速的發送大量的資料時，會很容易出現EWOULDBLOCK的錯誤。其中原因請參考TCP慢啟動相關的資料。

～～end

RTSP協議媒體資料發包相關的細節