RTSP と UDP: RTSP は接続できるのにビデオが真っ暗になる理由 — RTP がファイアウォール、NAT、および VPN によってブロックされる

最も重大な RTSP 問題の 1 つは、説明するのは簡単です。カメラは接続されていますが、ビデオが表示されません。多くの場合、RTSP 制御は TCP 上で機能しますが、UDP RTP メディア パケットはクライアントに到達しません。ユーザーにはログインの成功、SDP、さらには「PLAY 200 OK」が表示され、その後タイムアウトが表示されます。 「RTSP は接続されるがビデオが表示されない」、「RTP UDP がブロックされたファイアウォール」、「RTSP は VPN 経由ではなく LAN 上で動作する」、「カメラ RTSP NAT ビデオなし」、「RTSP TCP インターリーブ修正」などの検索はすべて、このレイヤー分割を示しています。

RTSP は 1 つのデータ ストリームではありません。コントロール チャネルとメディア チャネルは、異なるトランスポート パスを使用できます。コントロール チャネルが機能していてもメディア パスに障害が発生すると、プレーヤーにコーデックの障害と同じ黒い画面が表示されることがあります。パケット証拠は異なります。

RTSP Inspector は、RTSP 制御の成功と RTP メディア配信を区別するため便利です。

コントロールが機能するからといってメディアが機能するわけではない

通常の UDP RTP フローは次のようになります。

1. クライアントはカメラ ポート 554 への RTSP TCP 接続を開きます。
2. クライアントは「DESCRIBE」を送信します。
3. カメラは SDP を返します。
4. クライアントは UDP クライアント ポートを使用して「SETUP」を送信します。
5. カメラは UDP サーバー ポートを返します。
6. クライアントは「PLAY」を送信します。
7. カメラは RTP パケットをクライアントの UDP ポートに送信します。

手順 1 ～ 6 が成功し、手順 7 が失敗した場合、ストリームは RTSP ログインの問題ではありません。メディアパスの問題です。

トランスポートヘッダーによりポート計画が明らかになります

「SETUP」リクエストには以下が含まれる場合があります。

Transport: RTP/AVP;unicast;client_port=50000-50001

The camera may answer:

Transport: RTP/AVP;unicast;client_port=50000-50001;server_port=6970-6971

カメラはクライアントの UDP ポートに RTP/RTCP を送信する必要があります。ファイアウォールはそのトラフィックを許可する必要があります。 NAT デバイスはそれを正しくマッピングする必要があります。 VPN はそれを実行する必要があります。そうでない場合、メディアが沈黙している間、RTSP 制御は正常に見える可能性があります。

一般的なファイアウォールと NAT の障害

一般的な原因は次のとおりです。

• ファイアウォールは TCP 554 を許可しますが、UDP RTP ポート範囲をブロックします。
• NAT は RTSP ポートを転送しますが、RTP ポートは転送しません。
• カメラが予期しない送信元ポートから RTP を送信します。
• クライアントは、カメラから到達できないプライベート UDP ポートをアドバタイズします。
• VPN は TCP を許可しますが、UDP をドロップします。
• 企業のファイアウォールが高頻度の UDP ポートをブロックします。
• カメラは二重 NAT の背後にあります。
• RTP パケットが間違ったインターフェイスに返されます。

多くの場合、目に見える症状は「PLAY 後にビデオが表示されない」です。

TCP インターリーブがよく機能する理由

RTSP over TCP インターリーブは、RTSP TCP 接続内で RTP と RTCP を伝送します。これにより、個別の UDP ピンホールが回避されます。

UDP モードが失敗し、TCP インターリーブが機能する場合、それはコーデックとカメラがおそらく正常であるという強力な証拠です。問題はおそらく UDP メディア トランスポートです。

ただし、TCP インターリーブには、チャネル マッピングを含む独自の解析要件があります。これは UDP パスの問題の回避策であり、すべてのレイヤーが正常であることを証明するものではありません。

RTCP はパスの証明に役立ちます

RTP がブロックされているが RTCP が到着している場合、またはその逆の場合は、ポート ペアを検査します。一部のファイアウォールは 2 つの方向を異なる方法で処理します。 RTCP 受信レポートには、メディアが部分的に到着した場合のパケット損失とジッターも表示される場合があります。

記録：

• RTP パケット数。
• RTCP パケット数。
• RTP 送信元 IP とポート。
• RTP 宛先 IP とポート。
• シーケンス番号のギャップ。
• 「PLAY」から最初のパケットまでの時間。

デバッグチェックリスト

このワークフローを使用します。

1. RTSP DESCRIBE、SETUP、および PLAY が成功したことを確認します。
2. 「トランスポート」ヘッダーとクライアント/サーバーの UDP ポートを検査します。
3. 「PLAY」後にRTPパケットが到着するかどうかを確認します。
4. RTCPパケットが到着するかどうかを確認します。
5. LAN テストと VPN/WAN テストを比較します。
6. TCP インターリーブ トランスポートをテストします。
7. UDP RTP ポート範囲のファイアウォール ルールを確認してください。
8. NAT ポート転送と送信元ポートの動作を確認します。
9. クライアントがアドバタイズした到達可能な UDP ポートを確認します。
10. RTP ペイロードが実際に到着するまで、コーデックをデバッグしないでください。

最終診断

RTSP は接続しているが UDP RTP がブロックされている場合、メディアが到着しない間もカメラに完全に到達できます。修正は、UDP ポートの到達可能性、NAT の動作、ファイアウォール ポリシー、VPN ルール、または TCP インターリーブへの切り替えにあります。

RTSP Inspector は、RTSP 制御シーケンスと RTP パケットの証拠を一緒に表示することで役立ち、「ビデオなし」が具体的なトランスポート診断になります。