王辰生

上一期介紹了IP系統中PTP同步測量的相關要點，今天繼續和大家分享IP測量的內容。本期主要針對流特性的檢測，涉及到的標準包含ST 2110-10的一部分，以及ST 2110-20，-30，-40標準。

圖54 本期主要內容-紅框部分

本期主要內容點有：

RTP包的檢測，RTP header中哪些信息是有用的?

SDP中都包含什么信息，SDP描述錯誤會出現什么問題

流特性常規指標Protocol和Frequency

測量中數據流的帶寬和標準值有出入，這有什么問題么?

流定時能夠反映出哪些信息，測量它有什么意義?

一、ST2110-10中RTP和SDP的相關檢測

首先，我們再次回顧下ST2110-10標準，ST2110-10全名是：Professional Media Over ManagedIP Networks：System Timing and Definitions 系統定時及定義，主要包括以下幾個方面：

定義IP流使用RTP(實時傳輸協議-RFC3550)，可通過UDP傳輸實時媒體數據。

說明了ST2059 PTP同步如何在ST2110系統中使用。

定義如何描述IP流，即SDP(Session Description Protocol)，由控制系統分發(ST2110-10未定義其分發)。

IP流的具體格式等信息在ST2110系列協議的其他部分介紹。

所以在該標準中我們需要關注的測量重點呼之欲出：即RTP/PTP/SDP。PTP之前我們進行過詳細介紹，下面我們來介紹RTP以及SDP的檢測內容。

1、RTP Header

實時傳輸協議(Real-timeTransport Protocol或簡寫RTP)是一個網絡傳輸協議，它是由IETF的多媒體傳輸工作小組1996年在RFC1889中公布的，RTP基于UDP之上運行。

圖55 RTP協議解析

RTP作為網絡媒體傳輸協議，其包頭攜帶了很多媒體流的關鍵信息，RTP Header可以直接反映RTP包的主要信息，可作為RTP包是否正確的重要依據。利用示波器或者Wireshark軟件可以分析RTP包的包頭，其中Telestream示波器測量該參數的菜單被稱為IP SESSION-VIDEO/AUDIO/DATA。如圖55所示，可以看到包頭各個字段的詳細信息：

圖56 Telestream示波器VIDEO信號的RTP包頭分析

Leader示波器測量該參數的菜單被稱為IP MENU，如圖56所示，可以看到包頭各個字段的詳細信息：

圖57 Leader示波器VIDEO信號的RTP包頭分析

這里簡單給大家介紹下各個項的主要意義，詳細解釋說明可以查看下面兩個鏈接的標準文件：

https://www.ietf.org/rfc/rfc3550.txt

https://www.ietf.org/rfc/rfc3551.txt

圖58 RTPheader 構成

Version

RTP包頭最開始的兩個字節定義了 RTP的版本。這里默認的版本都是 2。0和1都已被使用。

Padding

這一字節表示是否存在填充字節。如果顯示false，則表示在RTP數據包的末尾沒有額外的填充字節。如果顯示true，則表示在RTP數據包中加入了不屬于有效載荷的填充字節。

Extension

這一字節表示是否存在一個擴展。false表示不存在擴展。true表示存在一個擴展。

CSRC

這里表示合并的數據流中各個源數據流的ID。我們的系統中此項值應為0。

Marker

這一字節用來標記數據流中的重要的事件，例如幀邊界。

RTP Payload Type

RTP Payload Type用來描述此RTP流傳輸的媒體類型，目前在協議RFC3551中，未規定組播流的Payload Type，只劃分了96-127可供使用。ST2110流的payload type也應在96-127的范圍內，具體使用數值可以自定義，目前我們常規設置是將視頻流定義為96，音頻流定義為97，輔助數據流定義為100。

發送端和接收端對于一類IP流Payload Type必須一致，若不一致則往往會導致收端無法正常解析IP流。

圖59 通過示波器讀取Payload Type

如圖59所示，讀取到Payload Type為96時，即可認為該信號是一個視頻信號;若一個音頻信號Payload Type是98，接收設備對應音頻的Payload Type為97，即需要對發端的相應參數做修改，以免接收端無法解析IP流。我們在項目中也遇到過這種情況，這個時候示波器就將這個流識別成了2022-6的流，而系統內的IPG無法接收到這個音頻流，很顯然這是不對的。

Sequence number

RTP序列的計數器，每發送一個RTP數據包這個數值都會順序增加，在示波器上，可以看到這項值往往應該是隨時間增長的。

RTP Timestamp

RTP Timestamp即RTP時間戳，記錄了該包中數據的第一個字節的采樣時刻。在一次會話開始時，時間戳初始化成一個初始值，即使在沒有信號發送時，時間戳的數值也要隨時間而不斷地增加，時間戳是去除抖動和實現同步不可缺少的。幾個連續的RTP包如果是同時產生的，則擁有相同的時間戳，如：屬于視頻同一幀的RTP包，將有相同的RTP時間戳。

圖 60 通過示波器讀取Timestamp

SSRC

這些字節用來識別同步源，SSRC隨機生成，以保證系統中的RTP通訊里任意的兩個同步源的SSRC是不同的，避免相同的SSRC被當成環路。

RTP header中的信息很多，但是由于很多信息相對比較固定，我們只需要注意幾個重要的參數，例如payload type，RTP Timestamp的情況，確保Sequence number是順序增長的。RTP提供時間戳和序列號是用來檢測RTP包的時間問題和數據包是否丟失，它無法糾正數據包丟失時的錯誤。RTP payload type雖然無明確規定，但是目前2110系統中是以96，97和100用來分別表示視頻流，音頻流和輔助數據流。

2、SDP

如前文所述，SDP即會話描述協議，在ST2110系統內實現對ST2110 IP流的描述，在SDP文件中的媒體部分，對ST 2110-20、30、40等流的媒體類型參數進行了描述，例如采樣率、位深度、畫面的寬和高、色彩空間等。

如圖63所示，可以在示波器中對SDP文件內部信息進行查看，也可以使用SDPoker開源軟件讀取SDP數據。

圖63 通過示波器讀取NMOS服務器及SDP描述

圖64 示波器讀取到的SDP文件內容

如圖64，即為我們在項目中使用示波器讀取到的SDP文件，可以通過SDP讀取到IP流端口號，組播地址，設備信息，以及格式等信息。

此外，在項目中還常碰見一種情況，某些設備需要手寫SDP的方式收取IP流，此時需檢查SDP文件內的格式、組播地址、IP地址等信息，否則會導致接收端無法收流。

二、ST2110-20/30/40中描述

的數據流相關指標測量

圖65 ST2110系列標準

ST2110-20即非壓縮活動視頻，對于一個視頻信號，首先需關注的自然是圖像的畫面、顏色、質量、有無畫面異常等信息，這也是傳統測量常關注的一點，這里就不再贅述。

ST2110-30/40即為音頻、輔助數據，對于音頻同樣需要關注聲音質量，有無聲音異常等情況;輔助數據信號目前更多需關注其攜帶的格式信息是否正常。

在2110系統中，如前文ST2110-10中RTP/SDP的介紹，首先需要測量該IP流的RTP Header是否正常，SDP文件描述是否正常。此外，對于ST2110 IP數據流來說還有一些其他需要關注的要點，我們來一一介紹。

1、Protocol

這里會展示接收到的流使用的協議情況，ST2110系統中對應的流會有相應的protocol，如果被識別成ST2022-6，那么需要檢查發端設備的設置是否正確。

圖66 示波器Protocol狀態截圖

2、Frequency

我們需要確保收到的數據流頻率和發端設置一致，在prism中可以看marker bit frequency這項參數，在leader中直接會在圖像的格式中查看該值。

圖67 Frequency截圖

3、Packing mode

ST2110-20標準介紹了兩種打包模式，分別是GPM(General Packing Mode)和BPM(Block Packing Mode)，其中GPM是遵循RFC 4175的開放打包方式，而BPM是基于180字節，無論格式如何，都能使數據包大小保持一致(利于網絡配置和故障排查)

圖61 不同采樣率和位深度的BPM包大小

在索尼的系統一般都采用GPM的打包方式，這一點我們可以在示波器上看到。

圖62 示波器顯示Packing mode截圖

4、Bitrate

IP系統中不管是業務流，還是控制數據，在網絡中都是以比特(bit)作為最小的信息度量單位進行傳輸，IP流的帶寬就是用比特率來衡量的——比特率是指單位時間內傳送的比特數。對于視頻系統而言，單位一般采用Gbps(又作Gb/s，bps=bitsper second);音頻和輔助數據則分別采用Mbps和Kbps作為單位。

帶寬的計算方法和詳解可參照本公眾號之前的文章，ST 2110數據封裝策略和媒體流帶寬計算。

不同格式的信號帶寬也不一樣，如下圖即為ST2110各個格式信號帶寬的典型值：

圖68 ST2110各格式信號帶寬典型值

在示波器上也可測量IP流帶寬：

圖69 Telestream 示波器測量信號帶寬

圖70 Leader示波器測量信號帶寬

一般來說，在實際系統中我們需要關注同一格式信號的帶寬不應超過或低于典型值過多。由于各家設備數據打包方式不盡相同，發送器類型不同，導致帶寬也略有出入，測量結果與IP流帶寬典型值(圖68)接近即可。

5、Stream RTP/PTP offset

ST2110 IP流均采用RTP協議進行傳輸，而如上文所述，RTP協議頭部攜帶有IP包的時間戳，我們通過測量接收到的視頻、音頻和數據相對于嵌入的RTP時間戳的計時，來比較其相對于RTP時間的延時，并通過它了解各類數據在網絡中傳輸后到達接收端是否有較大抖動。

利用示波器可以測量該參數，不同示波器參數名稱也略有不同，如Telestream示波器測量菜單被稱為Stream Timing：

圖71 Telestream 示波器測量IP流定時

如圖72所示，Leader示波器該選項被稱為TimingComparison：

圖 72 Leader 示波器測量包到達間隔

暫未有標準規定該項數值的取值范圍，在實際系統中測量此數據時一般認為數據保持穩定即可。流定時描述整個網絡的延遲情況，其具體數值取決于網絡的負載情況。同時流定時也可以反映當前狀態下音頻/視頻，數據/視頻等之間的相對延遲。

總結

RTP header需要重點關注payload type，時間戳和序列號這幾項數值，其中時間戳和序列號是用來檢測RTP包的時間問題和數據包是否丟失，而不是糾錯的手段。

SDP中的格式信息需要和實際數據流的格式一致，否則可能導致無法解析到正確的流。實際的系統中，數據流的帶寬往往和標準值有一定出入，這是因為不同設備的打包方式，發送器類型各不相同，只要和典型值相差不大，我們就可以認為其正常。在穩定的網絡環境中測量到的流定時應該也是穩定的數值，流定時出現波動時，很可能網絡中出現了不穩定的因素，需要立刻檢查。

本期的內容就介紹到這里，我們將流特性的檢查項梳理了一遍，希望對您有所幫助。下期我們將介紹傳輸特性和NMOS的檢查項，期待和大家多多交流。

原文標題：IP測量探索(五)——流特性的檢測

文章出處：【微信公眾號：索尼中國專業】歡迎添加關注!文章轉載請注明出處。

審核編輯：湯梓紅