技術共有

[オーディオとビデオ RTSP] RTSP プロトコルの詳細な説明とパケット キャプチャの例の分析 (詳細は省略します)

2024-07-08

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

😁博客主页😁:🚀https://blog.csdn.net/wkd_007🚀
🤑博客内容🤑:🍭嵌入式开发、Linux、C语言、C 、数据结构、音视频🍭
🤣本文内容🤣:🍭介绍RTSP协议 🍭
😎金句分享😎:🍭你不能选择最好的,但最好的会来选择你——泰戈尔🍭
⏰リリース時間⏰: 2024-07-06 12:22:00

この記事を許可なく転送することはできません。 ! !


ここに画像の説明を挿入します

🎄一、概述

RTSP、フルネーム Real Time Streaming Protocolリアルタイム ストリーミング プロトコルは、TCP/IP プロトコル システムのアプリケーション層プロトコルで、コロンビア大学、Netscape、および RealNetworks によって提出された IETF RFC 標準です。

RTSP プロトコルに関する公式文書は RFC2326 です (文書リンク:)RFC2326-リアルタイムストリーミングプロトコル (RTSP)

RTSPプロトコルの構文と動作を参照します。 HTTP/1.1は、ISO10646 文字セットと UTF-8 エンコーディングを使用するテキストベースのプロトコルで、RTSP を伝送するトランスポート層プロトコルです。TCP、デフォルトのポート554; RTSP-over-HTTP トンネリングの場合、デフォルトの TCP ポートは 8080 で、通常は RTP/RTCP プロトコルと組み合わせて使用​​され、RTP プロトコルはリアルタイム ストリーム データを送信し、RTCP プロトコルはデータ ストリームの送信を完了します。制御コマンド。

ここに画像の説明を挿入します

RTPプロトコル: フルネームReal-time Transport Protocolリアルタイム伝送プロトコルは、1996 年に IETF のマルチメディア伝送ワーキング グループによって RFC 1889 で発表されました。 RTP プロトコルは、インターネット経由でオーディオとビデオを配信するための標準パケット形式を詳しく説明します。 UDP プロトコルに基づいて構築されています。

RTCPプロトコル: フルネームReal-time Transport Control Protocol , RTP で使用されるリアルタイム トランスポート コントロール プロトコル。 RTP は偶数番号の UDP ポートを使用し、RTCP は RTP の次のポートである奇数番号のポートを使用します。 RTCP と RTP は連携して動作し、RTP は実際のデータの送信を実装し、RTCP はセッション内の全員に制御パケットを送信します。その主な機能は、RTP によって提供されるサービスの品質に関するフィードバックを提供することです。

RTSP プロトコルと HTTP プロトコルの違い:
RTSP はステートフルであり、そのコマンドは常に順番に送信され、あるコマンドは常に別のコマンドの前に送信される必要がある場合があります。 HTTP はステートレスであり、プロトコルがコマンドを送信した後、接続は切断され、コマンド間に依存関係はありません。
rtsp プロトコルはポート 554 を使用し、http はポート 80 を使用します。
RTSP リクエストはサーバーとクライアントの両方から送信できますが、HTTP リクエストはクライアントからのみ送信できます。


ここに画像の説明を挿入します

🎄二、RTSP 方法

一般的に使用される RTSP メソッドには、OPTIONS、DESCRIBE、SETUP、PLAY、PAUSE、TEARDOWN、ANNOUNCE、GET_PARAMETER、SET_PARAMETER などがあります。詳細な使用手順は次のとおりです。

  • OPTIONS : クライアントは、サーバーがサポートするメソッドをサーバーから取得します。サーバーの状態には影響しません。
  • DESCRIBE: クライアントは、URL で指定されたメディア オブジェクトの説明をサーバーから取得します。Acceptこのフィールドは説明形式を指定します。
  • SETUP : クライアントはサーバーにセッションを確立して送信の準備を要求します。リクエスト情報には主に送信プロトコルとクライアントのポート番号が含まれます。
  • PLAY : クライアントは、SETUP で指定されたメカニズムを使用してデータの送信を開始するようにサーバーに能動的に通知します。でRangeこのフィールドは、再生の開始時刻と終了時刻を指定します (リアルタイム ストリームの範囲は通常、Range: npt=0.000-)、複数の PLAY リクエストが到着すると、サーバーは PLAY リクエストをキューに入れ、順番に実行します。つまり、2 番目の PLAY メッセージの処理を続ける前に、最初の PLAY 時間が完了するまで待機する必要があります。
  • PAUSE : クライアントは、サーバーのメディア ストリーミングを一時的に停止するように要求します。通過できるRangeパラメーターは指定した時点で一時停止します。または、一時停止するストリームを指定することもできます。たとえば、一時停止するオーディオ ストリームを指定すると、再生は無音になります。
  • RECORD : RECORD は、クライアントが前述の説明に従ってメディア データの記録を開始することをサーバーに通知します。 でtimestamp フィールドには開始時刻と終了時刻 (UTC) が反映されます。このフィールドが存在しない場合は、メディアの説明の開始時刻または終了時刻が使用されます。 セッションがすでに開始されている場合は、すぐに録音が開始されます。
    サーバーは、ログデータを保存するかどうかを決定します。request-URI 次の URI または別の URI。 サーバーがリクエスト URI を使用しない場合、応答は 201 (作成済み) であり、リクエストのステータスを記述し、新しいリソースを参照する Entity ヘッダーと Location ヘッダーが含まれている必要があります。
  • TEARDOWN: クライアントは、指定された URL ストリームの送信を停止し、関連リソースを解放するように要求します。
  • REDIRECT : リクエストをリダイレクトするには、サーバーは別のサーバーの場所に接続する必要があることをクライアントに通知します。 これには、クライアントがこの URL に対してリクエストを行う必要があることを示す必須の Location ヘッダーが含まれています。 これには、リダイレクトがいつ有効になるかを示すパラメーター Range が含まれる場合があります。 クライアントがこの URI に対してメディアの送受信を継続したい場合、クライアントは、指定されたホスト上で現在のセッションに対して TEARDOWN リクエストを発行し、新しいセッションに対して SETUP リクエストを発行する必要があります。
  • ANNOUNCE: クライアントがサーバーに送信するときは、リクエスト URL によって識別されるプレゼンテーションの説明またはメディア オブジェクトをサーバーに送信することを意味します。
    サーバーがクライアントに送信すると、クライアントにセッション情報を更新するように通知することになります。
  • GET_PARAMETER :GET_PARAMETER URI で指定された表現またはストリームのパラメーター値を取得するリクエスト。 返信や応答の内容は実装に委ねられます。 エンティティ本体のない GET_PARAMETER は、クライアントまたはサーバーの稼働状態 (「ping」) をテストするために使用できます。
  • SET_PARAMETER : このメソッドは、デモまたは URL 指定ストリームのパラメータ値の設定を要求します。リクエストにはパラメータを 1 つだけ含めて、特定のリクエストが失敗した理由をクライアントが判断できるようにする必要があります。リクエストに複数のパラメータが含まれている場合、すべてのパラメータを正常に設定でき、サーバーはこのリクエストに対してのみ動作する必要があります。サーバーは、パラメータを同じ値に繰り返し設定できるようにする必要がありますが、パラメータ値を変更することはできません。注: メディア ストリーミング パラメータは、SETUP コマンドを使用して設定する必要があります。ファイアウォールにとって、セットアップ転送パラメータを SETUP に制限することは有益です。

上記では合計 11 の RTSP メソッドが紹介されています。SETUPPLAYTEARDOWN RTSP プロセスでは 3 つのコマンドが必要であり、他のメソッドは必要ありません。そしてANNOUNCEGET_PARAMETERSET_PARAMETER3 つのコマンドはクライアントからサーバーに送信することも、サーバーからクライアントに送信することもできます。他のコマンドはクライアントからサーバーに送信されます。


ここに画像の説明を挿入します

🎄三、RTSP 的 请求报文 与 响应报文

RTSP には、リクエスト メッセージとレスポンス メッセージの 2 種類のメッセージがあります。リクエストメッセージはクライアントからサーバーに送信されるリクエストメッセージを指し、レスポンスメッセージはサーバーからクライアントへの応答を指します。

✨3.1、RTSPリクエストメッセージ

RTSP リクエスト メッセージは、リクエスト ライン、リクエスト ヘッダー、リクエスト本文の 3 つの部分で構成されます。このうち、リクエスト行は必須ですが、リクエストヘッダーとリクエストボディは特定の状況に応じてオプションです。
ここに画像の説明を挿入します

  • リクエスト行: リクエスト行は、スペースで区切られ、CRLF が前に付くメソッド、リクエスト URI、およびプロトコル バージョンで構成されます (例:rn)仕上げる。
    方法 :上で紹介したRTSP方式です。オプション、説明、セットアップ、再生、一時停止、ティアダウンなどが含まれます。
    请求URI: 操作するメディア リソースを通常は rtsp://example.com/path/to/stream の形式で指定します。
    协议版本: リクエストが従う RTSP プロトコルのバージョンを示します。通常はRTSP/1.0またはRTSP/2.0
    完全なリクエスト行の例を次に示します。
    OPTIONS rtsp://192.168.3.225:554/wbc RTSP/1.0
    
  • リクエスト ヘッダー: リクエスト ヘッダーには、CSeq (リクエストの識別に使用されるシーケンス番号)、セッション ID (セッション識別子)、トランスポート (トランスポート プロトコル) などの追加情報が含まれています。各ヘッダー フィールドはフィールド名、コロン、およびフィールド値で構成され、各ヘッダー フィールドは CRLF で区切られます。
    完全なリクエスト ヘッダーの例を次に示します。
    CSeq: 2
    User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)
    
  • リクエストボディ: リクエストボディは追加データを送信するために使用されます。リクエスト本文の具体的な内容は、リクエスト行で使用される RTSP メソッドによって異なります。注: リクエスト ヘッダーの後に、リクエスト ヘッダーとリクエスト本文を区別するために空行 (CRLF) を挿入する必要があります。ほとんどのリクエスト メッセージにはリクエスト本文がありません。

✨3.2、RTSP応答メッセージ

RTSP リクエスト メッセージは、ステータス行、応答ヘッダー、応答本文の 3 つの部分で構成されます。このうちステータス行は必須ですが、応答ヘッダーと応答本文は特定の状況に応じてオプションです。
ここに画像の説明を挿入します

  • ステータス行: ステータス行には、プロトコル バージョン、ステータス コード、およびステータス テキストがスペースで区切られ、CRLF (つまり、「rn」) で終了します。
    协议版本: 応答が従う RTSP プロトコルのバージョンを示します。通常は RTSP/1.0 または RTSP/2.0 です。
    状态码 : リクエストの処理結果を示すために使用される 3 桁の数字 (200、401、500 など)。最初の数字は応答カテゴリを表します。2xx は成功を示し、4xx はクライアント エラーを示し、5xx はサーバー エラーを示します。
    状态文本: OK、未承認など、対応するステータス コードの具体的な意味を説明する短いテキスト説明。
    応答行の例を次に示します。
    RTSP/1.0 200 OK
    
  • 応答ヘッダー: 応答ヘッダーには、CSeq (要求を識別するために使用されるシーケンス番号)、セッション ID (セッション識別子)、トランスポート (トランスポート プロトコル) など、要求ヘッダーと同様の情報が含まれます。各応答ヘッダー フィールドの形式は要求ヘッダーの形式と同じであるため、ここでは詳細には説明しません。
    CSeq: 2
    Date: Wed, Feb 04 1970 03:25:10 GMT
    Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER
    
  • 応答本文: 一部の RTSP 応答 (DESCRIBE など) には、追加データを送信するための応答本文が含まれる場合があります。注: 応答ヘッダーの後に、空白行 (CRLF) を挿入する必要があります。応答ヘッダーと応答本文を区別する
    以下は完全な応答本文の例です。
    v=0
    o=- 8913478 1 IN IP4 192.168.3.91
    s=LIVE555 Streaming Media v2016.07.19
    i=1080
    t=0 0
    a=tool:LIVE555 Streaming Media v2016.07.19
    a=type:broadcast
    a=control:*
    a=range:npt=0-
    a=x-qt-text-nam:LIVE555 Streaming Media v2016.07.19
    a=x-qt-text-inf:1080
    m=video 0 RTP/AVP 96
    c=IN IP4 0.0.0.0
    b=AS:5000
    a=rtpmap:96 H264/90000
    a=fmtp:96 packetization-mode=1;profile-level-id=64002A;sprop-parameter-sets=Z2QAKq2EAQwgCGEAQwgCGEAQwgCEO1A8ARPyoA==,aO48sA==
    a=control:track1
    m=audio 0 RTP/AVP 97
    c=IN IP4 0.0.0.0
    b=AS:768
    a=rtpmap:97 PCMA/48000/2
    a=control:track2
    

ここに画像の説明を挿入します

🎄四、RTSP 报文的常用字段

RTSP メッセージの応答ヘッダーには、一般的に使用されるいくつかのフィールドが含まれます。

  • 受け入れる : クライアントがサーバーに受け入れるように通知するエンティティ データ構造のタイプを指定するために使用されます。例: Accept: application/sdp の場合、サーバーは Content-Type フィールドを通じてエンティティ データ構造タイプを返します。
  • Accept-Encoding: 受け入れ可能なデータ圧縮形式をサーバーに通知するためにクライアントによって使用されます。例: Accept-Encoding: gzip、compress、br サーバーは、Content-Encoding フィールドを通じて選択した形式をクライアントに通知します。 。
  • Accept-Language: クライアントが理解できる言語とその受け入れをサーバーに通知するために使用されます。例: Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q =0.7, *; q=0.5、その後、サーバーはコンテンツ言語フィールドを介してクライアントに選択を通知します。
  • 認可: クライアント要求ヘッダーには、サーバーがユーザー エージェントを認証するために使用する資格情報が含まれています。
  • 帯域幅: クライアントが利用できる帯域幅の値を記述するために使用されます。例: 帯域幅: 4000
  • ブロックサイズ: このフィールドは、サーバーに特定のメディア パケット サイズを要求するために、クライアントからメディア サーバーに送信されます。サーバーは、要求されたブロック サイズよりも小さいブロック サイズを自由に使用できます。 このパケット サイズには、IP、UDP、RTP などの低レベル ヘッダーは含まれません。
  • CSeq : RTSP 要求応答のシーケンス番号を指定します。サーバーが要求を正しく識別して処理できるように、各 RTSP 要求には一意の CSeq 値が含まれている必要があります。このシーケンス番号はリクエスト メッセージごとに増加します。サーバー応答には、どの要求に応答するかを示す CSeq 値が含まれている必要があります。
  • キャッシュ制御: 命令を指定してキャッシュ メカニズムを実装します。キャッシュ ディレクティブは一方向です。つまり、リクエストに設定されたディレクティブが必ずしも応答に含まれるわけではありません。
  • 会議: 同じ RTSP セッションの会議 ID を変更してはならないことをサーバーに通知します。
  • 接続: このフィールドは、現在のトランザクションが完了した後にネットワーク接続を閉じるかどうかを決定します。値が「keep-alive」の場合、ネットワーク接続は永続的で閉じられないため、同じサーバーへのリクエストは接続または Connection: close で引き続き完了できます。
  • コンテンツの長さ : このフィールドは、RTSP プロトコルの最後のヘッダーに続く 2 つの CRLF の後のコンテンツの長さを示します。たとえば、サーバー応答の DESCRIBE で、SDP 情報の長さを指定します。
  • コンテンツタイプ: 返される実際のコンテンツのコンテンツ タイプをクライアントに伝えます。
  • 日付 : サーバーが応答を生成した日時を提供します。これは、クライアントが応答の鮮度を判断したり、時刻同期を実行したりするのに役立ちます。 Date フィールドの形式は RFC 1123 に準拠しています (例: Sat, 06 Apr 2024 11:15:00 GMT)。
  • ユーザーエージェント: このフィールドは、ネットワーク プロトコルのピアが、アプリケーションの種類、オペレーティング システム、ソフトウェア開発者、および要求を開始したユーザー エージェント ソフトウェアのバージョン番号を識別できるようにするために使用されます。
  • Expires: 有効期限を指定します。
  • ラン: 時間範囲を指定するために使用され、SMPTE、NTP、またはクロック時間単位を使用できます。
  • セッション :セッション ヘッダー フィールドは RTSP セッションを識別します。 セッションIDはサーバーによって決定されます。SETUP応答で選択すると、クライアントがセッション ID を取得すると、そのセッションの今後の操作要求メッセージにセッション ID が含まれます。例: Session: 4581E0AE;
  • 輸送 : トランスポート ヘッダー フィールドには、トランスポート プロトコル、アドレス ポート、TTL など、クライアントが受け入れ可能なトランスポート オプションのリストが含まれます。サーバーは、このヘッダー フィールドを通じて実際に選択された特定のオプションも返します。例: トランスポート: RTP/AVP/TCPunicast;destination=192.168.31.222;source=192.168.31.222;interleaved=0-1

ここに画像の説明を挿入します

🎄五、RTSP 流程抓包解析

Wireshark を使用して RTSP ストリーミング メディアのネットワーク パケットをキャプチャすると、一般的なプロセスが次のようになります。
1. クライアントが送信するOPTIONSメソッド、サーバー応答。
2. クライアントが送信するDESCRIBEメソッド、サーバー応答。
3. クライアントが送信するSETUPメソッド、サーバー応答。
2. クライアントが送信するPLAYメソッド、サーバー応答。
2. クライアントが送信するTEARDOWNメソッド、サーバー応答。
ここに画像の説明を挿入します
完全なフロー パケットは次のとおりです。

OPTIONS rtsp://192.168.3.225:554/wbc RTSP/1.0
CSeq: 2
User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)

RTSP/1.0 200 OK
CSeq: 2
Date: Wed, Jul 03 2024 14:42:11 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER

DESCRIBE rtsp://192.168.3.225:554/wbc RTSP/1.0
CSeq: 3
User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)
Accept: application/sdp

RTSP/1.0 200 OK
CSeq: 3
Date: Wed, Jul 03 2024 14:42:11 GMT
Content-Base: rtsp://192.168.3.225/wbc/
Content-Type: application/sdp
Content-Length: 472

v=0
o=- 1720014950032000 1 IN IP4 192.168.3.225
s=LIVE555 Streaming Media v2016.07.19
i=wbc
t=0 0
a=tool:LIVE555 Streaming Media v2016.07.19
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:LIVE555 Streaming Media v2016.07.19
a=x-qt-text-inf:wbc
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:5000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=640029;sprop-parameter-sets=Z2QAKawsaoHgCJ WbgoCCgQ=,aO4xshs=
a=control:track1
SETUP rtsp://192.168.3.225/wbc/track1 RTSP/1.0
CSeq: 4
User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP;unicast;client_port=55320-55321

RTSP/1.0 200 OK
CSeq: 4
Date: Wed, Jul 03 2024 14:42:11 GMT
Transport: RTP/AVP;unicast;destination=192.168.2.180;source=192.168.3.225;client_port=55320-55321;server_port=6970-6971
Session: 4581E0AE;timeout=65

PLAY rtsp://192.168.3.225/wbc/ RTSP/1.0
CSeq: 5
User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)
Session: 4581E0AE
Range: npt=0.000-

RTSP/1.0 200 OK
CSeq: 5
Date: Wed, Jul 03 2024 14:42:11 GMT
Range: npt=0.000-
Session: 4581E0AE
RTP-Info: url=rtsp://192.168.3.225/wbc/track1;seq=7880;rtptime=3548171463

TEARDOWN rtsp://192.168.3.225/wbc/ RTSP/1.0
CSeq: 6
User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)
Session: 4581E0AE

RTSP/1.0 200 OK
CSeq: 6
Date: Wed, Jul 03 2024 14:42:19 GMT

以下では、前のメッセージで使用された各 RTSP メソッドと応答を分析します。

✨5.1、OPTIONメソッド

サーバーから利用可能なメソッドを取得します。
ここに画像の説明を挿入します
クライアントは OPTIONS メソッドを送信し、CSeq リクエストのシーケンス番号を指定するには、次を使用します。User-Agent 自分自身の代理人を特定する。
サーバーは次を使用してリクエストに応答します。CSeq どのリクエストに応答しているかを示すには、次を使用します。Date日付を指定し、Public提供されるメソッドを指定します。


✨5.2、DESCRIBEメソッド

サーバーから取得rtsp://192.168.3.225:554/wbcメディア オブジェクトの説明。Acceptこのフィールドでは、説明の形式を指定します。

ここに画像の説明を挿入します
クライアントは DESCRIBE メソッドを送信し、CSeq リクエストのシーケンス番号を指定するには、次を使用します。User-Agent エージェントを特定し、Acceptこのフィールドでは、記述形式を SDP として指定します。

サーバーはこのリクエストに次のように応答します。 CSeq どのリクエストに応答しているかを示すには、次を使用します。Date日付を指定し、Content-TypeコンテンツタイプがSDPであることを示します。Content-Lengthコンテンツの長さを指定します。

知らせ
1. ユーザー名とパスワードを必要とするものについては、サーバーは認証のために DESCRIBE メソッドを処理します。 Authorization 認証情報が伝送されない場合、または認証が失敗した場合、サーバーはエラー番号 401 の応答を返します。クライアントは 401 応答を受信すると、既知のユーザー認証情報に基づいて Authorization を生成し、describe を再度送信する必要があります。認証が成功すると、サーバーは SDP を含む応答情報を返します。
2. サーバーから返された SDP 情報は、後の記事で分析されます。


✨5.3、SETUP方法

クライアントはサーバーに対して、セッションを確立して送信の準備をするように要求します。リクエスト情報には主に送信プロトコルとクライアントのポート番号が含まれます。

ここに画像の説明を挿入します
クライアントは SETUP メソッドを送信し、CSeq リクエストのシーケンス番号を指定するには、次を使用します。User-Agent エージェントを特定し、Transportこのフィールドは、許容可能な送信プロトコル RTP/AVP とポートを指定します (ここでは、RTP ポートは 55320、RTCP ポートは 55321)。

サーバーはこのリクエストに次のように応答します。 CSeq どのリクエストに応答しているかを示すには、次を使用します。Date日付を指定し、Transportトランスポート プロトコル RTP/AVP、宛先アドレス、送信元アドレス、クライアント ポート (RTP は 55320、RTCP は 55321)、サーバー ポート (RTP は 6970、RTCP は 6971) を指定します。SessionセッションIDを指定します。

知らせ
この例では、RTP は UDP プロトコルを通じて送信されますが、場合によっては TCP を通じて送信されます。Transportフィールドは異なります。それは次のようなものかもしれません。

客户端请求:Transport: RTP/AVP/TCP;unicast;interleaved=0-1
服务器响应:Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=24e4e500;mode="play"

RTP/AVP/TCPこの値が表示される場合、RTP ストリームが TCP 経由で送信されることを示します。
interleaved=0-1streamid を表し、RTP streamid=0 を識別します。
コード ストリームが TCP 経由で送信される場合、RTSP と TCP リンクを共有するため、RTP、RTCP、および RTSP プロトコルを区別するためにヘッダー識別子を追加する必要はありません。ここでは header フィールドが使用され、tcphead セクションは 4 ワードであり、形式は次のとおりです。

| magic number | channel number | embedded data length | data |

magic number:1バイト固定0x24、キャラクターです$、送信されるデータが rtsp プロトコルではないことを示します。
channel number: 1 バイト、チャネル ID。ストリームのタイプを識別します。これは前述の streamid です。
embedded data length : ストリームの長さを示す 2 バイト
data:RTP/RTCPパケットデータを示します。


✨5.4、PLAYメソッド

クライアントは、SETUP で指定されたメカニズムを使用してデータの送信を開始するようにサーバーに能動的に通知します。

ここに画像の説明を挿入します
クライアントは PLAY メソッドを送信し、CSeq リクエストのシーケンス番号を指定するには、次を使用します。User-Agent エージェントを特定し、Sessionフィールドにはセッション ID を指定します。Rangeこのフィールドでは、再生の開始時刻と終了時刻を指定します。

サーバーはこのリクエストに次のように応答します。 CSeq どのリクエストに応答するかを示します。Date日付を指定します。Rangeこのフィールドは、再生の開始時刻と終了時刻を指定します。Sessionこのフィールドはセッション ID を指定します。RTP-Infoこのフィールドには、最初の RTP パケットのシーケンスや rtptime など、送信されるコード ストリームの RTP 情報が記述されます。クライアントはこのフィールドに基づいて逆多重化できます。


✨5.5、分解方法

クライアントは、指定された URL ストリームの送信を停止し、関連リソースを解放するように要求します。
ここに画像の説明を挿入します
クライアントは TEARDOWN メソッドを送信し、CSeq リクエストのシーケンス番号を指定するには、次を使用します。User-Agent エージェントを特定し、Sessionフィールドにはセッション ID を指定します。

サーバーはこのリクエストに次のように応答します。 CSeq どのリクエストに応答するかを示します。Date日付を指定してください。


ここに画像の説明を挿入します

🎄六、RTSP 响应错误码

RTSP の応答コンテンツには通常、3 桁の整数の応答コードと理由フレーズが含まれます。このフレーズの目的は、ステータス コードの短いテキスト説明を提供することです。クライアントは理由フレーズを確認したり表示したりする必要はありません。 レスポンスコードの1桁目の違いにより、以下の5つに分類できます。

  • 1xx: ヒント - リクエストは受信され、処理中です
  • 2xx: 成功 - リクエストは正常に処理されました。
  • 3xx: リダイレクト - リクエストを完了するにはさらにアクションを実行する必要があります
  • 4xx: クライアント エラー - リクエストに不正なパラメータまたは構文が含まれていたため、リクエストを実行できませんでした。
  • 5xx: サーバー エラー - サーバーはクライアントの正しいリクエストを満たすことができませんでした

もちろん、RTSP エラー コードと RTSP メソッドには密接な関係があります。一部のエラーは、特定のメソッドでのみトリガーされる場合があります。詳細なエラー コード情報は次のとおりです。

エラーコード理由のフレーズ応答方法
100続く全て
200成功全て
201作成した記録
250ストレージ容量不足記録
300複数の選択肢全て
301永久に移動全て
302一時的に移動した全て
303その他を見る全て
305プロキシを使う全て
400要求の形式が正しくありません全て
401許可されていない全て
402支払いが必要全て
403禁断全て
404見つかりません全て
405許可されていない方法全て
406受け付けできません全て
407プロキシ認証が必要全て
408リクエストタイムアウト全て
410消えた全て
411必要な長さ全て
412前提条件が失敗しました DESCRIBE設定
413リクエストエンティティが大きすぎます全て
414リクエスト URI が長すぎます全て
415サポートされていないメディアタイプ全て
451無効なパラメーター設定
452不正な会議識別子設定
453帯域幅が足りない設定
454セッションが見つかりません全て
455この状態ではメソッドは無効です全て
456ヘッダーフィールドが無効です全て
457無効な範囲遊ぶ
458パラメータは読み取り専用ですパラメータの設定
459集計操作は許可されていません全て
460集計操作のみ許可全て
461サポートされていないトランスポート全て
462目的地に到達できません全て
500内部サーバーエラー全て
501実装されていません全て
502不正なゲートウェイ全て
503サービスは利用できません全て
504ゲートウェイタイムアウト全て
505RTSP バージョンはサポートされていません全て
551オプションはサポートされていません全て

ここに画像の説明を挿入します
如果文章有帮助的话,点赞👍、收藏⭐,支持一波,谢谢 😁😁😁

参照する:
リアルタイムストリーミングプロトコル—RTSP [詳細説明]
RTSP リクエストとレスポンスを最初からマスターする 1
RTSPストリーミングメディアプロトコルの詳細説明