RTSP 認証ループ: 401 未承認、ダイジェスト認証、およびカメラのログイン失敗の修正

RTSP 401 不正ループ、ダイジェスト認証、基本認証、古いノンス応答、間違ったカメラ ユーザー、および URL 認証情報の問題に関する実践的なガイド。

rtsp認証, 401 無許可, ダイジェスト認証, IPカメラログイン, rtsp 診断

最も一般的な RTSP カメラの問題の 1 つは、一見単純に見えます。クライアントは接続し、カメラは応答しますが、ストリームが開始されません。ログに「401 Unauthorized」が繰り返され、視聴者が再度パスワードを要求するか、ユーザー名とパスワードが正しいように見えてもアプリケーションが RTSP URL が間違っていると表示します。

これは RTSP 認証ループです。これは、カメラがクライアントにチャレンジし、クライアントが認証情報を送信し、カメラがそれを拒否するか、再度要求するときに発生します。根本的な原因は不正なパスワードである可能性がありますが、ダイジェスト認証の不一致、古いノンス処理、アカウントのアクセス許可、URL 内の特殊文字、間違ったストリーム パス、または「DESCRIBE」、「SETUP」、および「PLAY」で個別に認証を必要とするカメラである可能性もあります。

重要な証拠は RTSP 制御交換にあるため、ここでは RTSP Inspector が役立ちます。メディア プレーヤーでは、1 つのログイン エラーの背後にチャレンジと再試行の詳細が隠蔽されることがよくあります。プロトコル診断ビューでは、エラーが「OPTIONS」、「DESCRIBE」、「SETUP」、または「PLAY」で発生したかどうか、およびカメラが「WWW-Authenticate」、「stale=true」、または反復されたレルム チャレンジを返したかどうかを表示できます。

RTSP 401 Unauthorized 応答の意味

RTSP では、「401 Unauthorized」は通常、「サーバーにアクセスできない」というよりも「認証が必要である」ことを意味します。カメラは、次のように未認証リクエストに応答できます。

RTSP/1.0 401 Unauthorized
CSeq: 2
WWW-Authenticate: Digest realm="IP Camera", nonce="abc123"

Basic authentication vs Digest authentication

Special characters in RTSP URL credentials

Credentials in an RTSP URL can break when the password contains characters such as @, :, /, ?, #, %, or &.

A URL like this is ambiguous:

rtsp://admin:pa@ss@192.168.1.50:554/stream1
rtsp://admin:pa%40ss@192.168.1.50:554/stream1

Account permissions can block RTSP even when web login works

Wrong stream path can look like wrong credentials

That means a 401 does not prove the URL path is valid.

Common RTSP path patterns include:

  • /stream1
  • /stream2
  • /live
  • /h264
  • /h265
  • /cam/realmonitor?channel=1&subtype=0
  • /Streaming/Channels/101
  • /profile1/media.smp

Stale nonce and repeated Digest challenges

The camera may respond with:

WWW-Authenticate: Digest realm="IP Camera", nonce="new-value", stale=true

正しいクライアントは、新しい nonce を使用して再試行する必要があります。クライアントが古いノンス処理を理解していない場合、ストリームは認証を超えて進むことができない可能性があります。

この問題は、プロキシ、NVR リレー レイヤー、またはダイジェスト認証を緩やかに実装するファームウェアの背後にあるカメラで特によく発生します。また、クライアントが古い RTSP セッションを積極的に再利用した場合にも発生することがあります。

DESCRIBE、SETUP、PLAYでの認証

一部のカメラは、最初の「DESCRIBE」リクエストのみに挑戦します。複数の方法に挑戦する人もいます。ストリームは次のように失敗する可能性があります。

  1. 認証後、DESCRIBE は成功します。
  2. 「SETUP」は別の「401 Unauthorized」を受け取ります。
  3. クライアントは「SETUP」の資格情報を再送信しません。
  4. 再生が始まりません。

「PLAY」でも同じことが起こります。カメラは、すべての保護されたリクエストに「Authorization」ヘッダーを必要とする場合があります。クライアントが最初のリクエストのみを認証する場合、認証エラーではなく、紛らわしい「ストリームを再生できません」エラーが表示されることがあります。

RTSP Inspector は RTSP メソッド シーケンスを第一級の証拠として扱うため、これを確認しやすくします。問題は「ログインは機能しましたか?」ということだけではありません。しかし、「どのメソッドが挑戦され、クライアントは正しく答えましたか?」

RTSP 401 認証ループのチェックリスト

デバッグ時には次の順序を使用します。

  1. 既知のカメラ アカウントを使用して正確なユーザー名とパスワードを確認します。
  2. RTSP URL 内の特殊文字を URL エンコードします。
  3. カメラにダイジェスト認証または基本認証が必要かどうかをテストします。
  4. 「WWW-Authenticate」ヘッダーでレルム、ノンス、アルゴリズム、および古いフラグを調べます。
  5. クライアントが DESCRIBESETUP、および PLAYAuthorization を送信するかどうかを確認します。
  6. アカウントに Web UI 権限だけでなく、RTSP およびチャネル権限があることを確認します。
  7. メインストリームパスとサブストリームパスを個別にテストします。
  8. RTSP リクエストで使用される URI と、ダイジェスト応答の計算で使用される URI を比較します。
  9. カメラのファームウェアが認証動作を変更したかどうかを確認します。
  10. RTSP 認証が実際に完了するまでは、メディア コーデックの診断を避けてください。

Google 検索が通常意味するもの

「RTSP 401 Unauthorized IP カメラ」を検索する場合、通常は資格情報が間違っているかどうかを知る必要があります。 「RTSP ダイジェスト認証ループ」を検索する場合、通常はすでにパスワードを試しており、プロトコルの証拠が必要です。 「カメラ RTSP がパスワードを繰り返し要求する」を検索する場合、チャレンジと再試行のシーケンスを検査する必要があります。

役に立つ答えは、単に「パスワードをリセットする」というだけではありません。役に立つ答えは次のとおりです。

  • カメラはその要求に異議を唱えましたか?
  • クライアントは期待された認証方式で応答しましたか?
  • カメラは答えを受け入れましたか?
  • その後の RTSP メソッドが再び失敗しましたか?
  • ログイン後にストリーム パスまたはアカウントの権限が失敗しましたか?

この種の問題については、プレーヤーのみのテストよりもプロトコル指向のツールの方が優れているのはこのためです。

最終診断

RTSP 認証ループは、資格情報、URL エンコード、認証スキーム、リクエスト URI、アカウント許可、およびメソッドレベルの認可動作を照合することによって解決されます。トレースに、ノンスが変化する「401 Unauthorized」応答が繰り返し表示される場合は、ダイジェスト処理を調べてください。認証の成功に続いてストリーム エラーが表示された場合は、URL パス、SDP、トランスポート、RTP、およびコーデックの診断に進みます。

RTSP Inspector は証拠優先のワークフロー向けに設計されており、カメラ、プレーヤー、コーデック、またはネットワークに障害があると想定する前に RTSP 制御パスを確認します。

<!-- rtsp-localized-evidence-foundation-v1:start -->

「RTSP 認証ループ: 401 未承認、ダイジェスト認証、およびカメラのログイン失敗の修正」を再現可能に検証する手順

結論から言うと、黒画面や一つのステータスコードだけでは障害の所在を証明できません。信頼できる診断では、RTSP の要求と応答、合意した Transport、有効な Session、その後の RTP シーケンス番号、タイムスタンプ、RTCP の証拠を一つの時系列につなげます。「RTSP 認証ループ: 401 未承認、ダイジェスト認証、およびカメラのログイン失敗の修正」では表示症状に近い層から調べますが、制御、ネットワーク、デコーダーの問題を混同しないよう同じ記録時刻を使います。

カメラ、ファイアウォール、VMS の設定を変える前に、小さな基準テストを作ります。パスワードを除いた RTSP URL、時刻、パス、要求した Transport、サーバー応答、最初のメディアパケット到着時刻を記録してください。機器が対応する場合は UDP と TCP interleaved を別々に試します。パス、認証情報、Transport を同時に変えると、二回目の成功がどの変更によるものか分かりません。

確認層 保存する証拠 判断する質問
RTSP メソッド、状態、ヘッダー、CSeq、Session サーバーはその操作を受理したか
SDP control、payload type、clock rate、codec 期待するトラックが記述されているか
Transport client_port、server_port、interleaved 両端が同じ経路を使うか
RTP SSRC、sequence、timestamp、marker メディア単位が説明可能な順序で届くか
RTCP sender report、CNAME、BYE 時計、識別子、終了を追跡できるか
Decoder SPS/PPS/VPS、packetization mode 受信 payload で初期化できるか

「メディアが届かない」と「届くが復号できない」を分けます。SETUP と PLAY が成功しても RTP がなければ、UDP 経路、NAT、ファイアウォール、Transport 応答を調べます。シーケンスの穴は損失または並べ替えを示します。連続した RTP があるのに映像がなければ、payload type、clock rate、フレーム境界、H.264 または H.265 のパラメーターへ進みます。この境界はプレーヤーの一般的なエラーより有用です。

引用できる短い回答はどう書きますか

三文で、最後に成功した操作、最初に失敗した証拠、二つの原因を分ける次の試験を書きます。例は「DESCRIBE、SETUP、PLAY は成功した。通知されたクライアントポートに RTP が届かない。TCP interleaved の再試験で UDP 遮断とメディアパス誤りを分ける」です。応答やパケットなしにカメラやネットワーク全体を原因と断定しません。

再現に必要な最小情報は何ですか

OPTIONS、DESCRIBE、SETUP、PLAY、SDP、Transport 応答、秘密を除いた Session を保存します。RTP は SSRC、最初と最後のシーケンス、clock rate、欠落数、収録時間を記録します。VLC や別 VMS の成否は差分試験として有用ですが、成功したクライアントが全規則を正しく扱う証明ではありません。

サーバーとクライアントのどちらを調べますか

メソッド拒否、存在しない control URL、不一致 Transport、説明のない SSRC や時計変更はサーバー側を調べます。期限切れ nonce の再利用、Session 欠落、ポートを開かない UDP 要求、各 NAL 終端を access unit 終端とみなす処理はクライアント側を調べます。中間経路の問題では、各結論にパケットと時刻を添えます。

報告前に何を確認しますか

新しい接続で再試験し、二つの時系列を最初の相違点まで比較します。パスワードと完全な Authorization 値を削除し、結論を CSeq、sequence、timestamp に結び付けます。関連する RTSP ガイドで周辺手順を確認し、RTSP Inspectorで RTSP ストリームをローカルに試験してください。カメラ映像を公開サービスへアップロードする必要はありません。

<!-- rtsp-localized-evidence-foundation-v1:end --><!-- multilingual-blog-closeout:start -->

直接回答と受け入れ境界

「RTSP 認証ループ: 401 未承認、ダイジェスト認証、およびカメラのログイン失敗の修正」への短い答えは次のとおりです。RTSP 401 不正ループ、ダイジェスト認証、基本認証、古いノンス応答、間違ったカメラ ユーザー、および URL 認証情報の問題に関する実践的なガイド。 この文は、すべての入力、デバイス、プロジェクト、環境に対する保証ではなく、検証すべき結果として扱います。完了した結果には、開始状態、正確な操作、目に見える出力、RTSP Inspector で作業が終わったと判断する条件が記録されています。

証拠を起点にした操作手順

プロジェクト全体を変更する前に、小さく再現可能なケースから始めます。アプリのバージョン、OS、入力またはデバイスの識別情報、重要な設定、期待結果を記録します。一つの操作だけを実行し、最初の予期しない変化を保存し、可能なら既知の正常ケースと比較します。複数の設定を同時に変えると、問題を作った条件や直した条件が分からなくなります。

確認点 1:RTSP 認証ループ: 401 未承認、ダイジェスト認証、およびカメラのログイン失敗の修正

「RTSP 認証ループ: 401 未承認、ダイジェスト認証、およびカメラのログイン失敗の修正」は、保存、書き出し、または再度開いた結果が観察した状態と一致してから完了にします。一時的な UI 表示も役立ちますが、再利用できる証拠の方が強い判断材料です。残る制限も記録します。

確認点 2:RTSP 401 不正ループ、ダイジェスト認証、基本認証、古いノンス応答、間違ったカメラ ユーザー、および URL 認証情報の問題に関する実践的なガイド。

「RTSP 401 不正ループ、ダイジェスト認証、基本認証、古いノンス応答、間違ったカメラ ユーザー、および URL 認証情報の問題に関する実践的なガイド。」では、製品の判断と、OS、ハードウェア、元ファイル、権限、作業手順の境界を分けます。原因を決める前に、どの層が証拠を出したか確認します。近くで起きた症状だけを根本原因として報告しないためです。

確認点 3:RTSP 401 Unauthorized 応答の意味

「RTSP 401 Unauthorized 応答の意味」は、保存、書き出し、または再度開いた結果が観察した状態と一致してから完了にします。一時的な UI 表示も役立ちますが、再利用できる証拠の方が強い判断材料です。残る制限も記録します。

確認点 4:Basic authentication vs Digest authentication

「Basic authentication vs Digest authentication」では、製品の判断と、OS、ハードウェア、元ファイル、権限、作業手順の境界を分けます。原因を決める前に、どの層が証拠を出したか確認します。近くで起きた症状だけを根本原因として報告しないためです。

確認点 5:Special characters in RTSP URL credentials

「Special characters in RTSP URL credentials」は、保存、書き出し、または再度開いた結果が観察した状態と一致してから完了にします。一時的な UI 表示も役立ちますが、再利用できる証拠の方が強い判断材料です。残る制限も記録します。

確認点 6:Account permissions can block RTSP even when web login works

「Account permissions can block RTSP even when web login works」では、製品の判断と、OS、ハードウェア、元ファイル、権限、作業手順の境界を分けます。原因を決める前に、どの層が証拠を出したか確認します。近くで起きた症状だけを根本原因として報告しないためです。

確認点 7:Wrong stream path can look like wrong credentials

「Wrong stream path can look like wrong credentials」は、保存、書き出し、または再度開いた結果が観察した状態と一致してから完了にします。一時的な UI 表示も役立ちますが、再利用できる証拠の方が強い判断材料です。残る制限も記録します。

確認点 8:Stale nonce and repeated Digest challenges

「Stale nonce and repeated Digest challenges」では、製品の判断と、OS、ハードウェア、元ファイル、権限、作業手順の境界を分けます。原因を決める前に、どの層が証拠を出したか確認します。近くで起きた症状だけを根本原因として報告しないためです。

確認点 9:DESCRIBE、SETUP、PLAYでの認証

「DESCRIBE、SETUP、PLAYでの認証」は、保存、書き出し、または再度開いた結果が観察した状態と一致してから完了にします。一時的な UI 表示も役立ちますが、再利用できる証拠の方が強い判断材料です。残る制限も記録します。

確認点 10:RTSP 401 認証ループのチェックリスト

「RTSP 401 認証ループのチェックリスト」では、製品の判断と、OS、ハードウェア、元ファイル、権限、作業手順の境界を分けます。原因を決める前に、どの層が証拠を出したか確認します。近くで起きた症状だけを根本原因として報告しないためです。

受け入れマトリクス

確認点 残す証拠 合格条件
RTSP 認証ループ: 401 未承認、ダイジェスト認証、およびカメラのログイン失敗の修正 開始状態、一つの操作、結果状態 別の担当者が同じ結果を再現できる
RTSP 401 不正ループ、ダイジェスト認証、基本認証、古いノンス応答、間違ったカメラ ユーザー、および URL 認証情報の問題に関する実践的なガイド。 開始状態、一つの操作、結果状態 別の担当者が同じ結果を再現できる
RTSP 401 Unauthorized 応答の意味 開始状態、一つの操作、結果状態 別の担当者が同じ結果を再現できる
Basic authentication vs Digest authentication 開始状態、一つの操作、結果状態 別の担当者が同じ結果を再現できる
Special characters in RTSP URL credentials 開始状態、一つの操作、結果状態 別の担当者が同じ結果を再現できる
Account permissions can block RTSP even when web login works 開始状態、一つの操作、結果状態 別の担当者が同じ結果を再現できる

失敗の分離、復旧、引き継ぎ

最初に失敗した境界で停止します。元データ、プロジェクト、セッション、キャプチャを保存し、破壊的な編集前に複製し、一回の実験では一つの変数だけを変えます。複数変更後に全手順をやり直して結果が変わっても、理由は説明できません。

証拠がないことと、存在しない証拠を分けます。空の画面は、入力、範囲、フィルター、権限、デバイス、時間帯、プロジェクト状態の誤りでも起こります。decoder、編集、レポート、書き出しを解釈する前に、取得または読み込み経路を証明します。

引き継ぎ前に成果物を再度開き、先頭、判断点、末尾を確認します。バージョン、環境、設定、期待、観察、最小再現手順を記録します。機密情報を削除またはマスクし、受取人に権限があることも確認します。

質問と回答

最も速く信頼できる開始方法は何ですか?

最小で代表的なケースを使い、期待結果を書き、一つの変数だけを変えます。フィルター、エフェクト、編集、自動化、大きな入力を加える前に、基本経路を確認します。

どの証拠を保存すべきですか?

入力の識別情報、バージョン、環境、設定、正確な操作、最初の異常な変化、最終出力を残します。プロジェクト、セッション、レポート、書き出しは閉じて開き直します。

いつ手順を繰り返しますか?

アプリ、OS、driver、firmware、モデル、入力、手順の変更が結果に影響し得る場合です。以前に合格したケースを変更せず、比較基準として残します。

いつ引き継ぎ可能になりますか?

権限のある別の人が入力を特定し、操作を繰り返し、同じ結果を確認し、残る制限を理解し、未記録のローカル状態なしで成果物を開ける時です。

関連ガイド

次の同一言語ページは、このトピックの正規所有者を変えずに隣接する工程を説明します。

<!-- multilingual-blog-closeout:end -->