Inspecteur RTSP logo Inspecteur RTSP Diagnostic vidéo RTSP

2026-06-02

Transport RTSP sans correspondance dans la réponse du serveur : débogage des réponses de configuration de la caméra et incompatibilité du mode RTP

Comment déboguer les erreurs de transport RTSP non correspondantes lorsque la caméra répond avec un mode de transport RTP différent, des canaux entrelacés incorrects, des ports manquants ou une réponse SETUP incompatible.

Certains échecs RTSP ne renvoient pas de message « 461 Unsupported Transport » propre. Au lieu de cela, le client signale « transport non correspondant dans la réponse du serveur », « en-tête de transport invalide », « le serveur a répondu avec un transport différent » ou « incompatibilité de transport RTP ». Cela se produit souvent lorsqu'une caméra accepte « SETUP » mais répond avec un en-tête « Transport » qui ne correspond pas à ce que le client a demandé ou à ce que le client peut analyser.

Les utilisateurs recherchent « Transport sans correspondance RTSP dans la réponse du serveur », « Transport sans correspondance ffmpeg », « Incompatibilité de transport RTSP SETUP » et « En-tête de transport de caméra invalide », car le flux peut fonctionner dans un lecteur et échouer dans un autre. La caméra n’est pas simplement inaccessible. La négociation de transport RTSP est incohérente.

RTSP Inspector est utile car les en-têtes de demande et de réponse doivent être comparés directement.

À quoi ressemble un échange SETUP correspondant

Le client demande TCP entrelacé :

Transport: RTP/AVP/TCP;unicast;interleaved=0-1

Server replies with compatible TCP interleaved transport:

Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=12345678

Le client demande UDP :

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

Server replies with UDP ports:

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

Si le serveur change de mode de transport, omet les champs obligatoires ou renvoie des valeurs mal formées, les clients stricts peuvent échouer.

Cas de non-concordance courants

Les exemples courants incluent :

  • Le client demande TCP, le serveur répond UDP.
  • Le client demande UDP, le serveur répond TCP.
  • Le serveur omet interleaved=.
  • Le serveur renvoie les mauvais numéros de canal.
  • Le serveur renvoie des valeurs client_port différentes de la requête.
  • Le serveur omet server_port pour UDP.
  • Le serveur renvoie la multidiffusion lorsque le client a demandé la monodiffusion.
  • Le serveur renvoie plusieurs alternatives de transport dans un format non pris en charge.
  • Le proxy réécrit la demande mais pas la réponse.

Certains clients tolèrent ces bizarreries. D'autres les rejettent.

Pourquoi un joueur fonctionne et un autre échoue

Les implémentations RTSP varient. Un joueur tolérant peut accepter une réponse de transport mal formée ou inattendue et continuer. Un outil plus strict peut échouer parce que la réponse ne respecte pas ses attentes.

Cela ne signifie pas automatiquement que le client strict a tort. Cela signifie que le comportement de la caméra ou du proxy doit être inspecté.

Pour un diagnostic professionnel, conservez :

  • L’en-tête Transport demandé.
  • La réponse de transport du serveur.
  • Suivre l'URL.
  • ID de session.
  • Si les paquets RTP arrivent ensuite.

Réécriture de proxy et de relais

Les relais compatibles RTSP peuvent réécrire les en-têtes de transport pour relier les chemins UDP et TCP. Si la réécriture est incomplète, le client en aval voit une réponse qui ne correspond pas à sa demande.

Exemples :

  • Le client demande TCP au relais.
  • Le relais demande UDP à la caméra.
  • Le relais transmet accidentellement la réponse de transport UDP de la caméra en aval.

Le client signale un transport non correspondant même si la caméra et le relais ont chacun fait quelque chose de partiellement valide.

Liste de contrôle de débogage

Utilisez ce processus :

  1. Capturez la requête SETUP.
  2. Capturez la réponse « SETUP ».
  3. Comparez les protocoles de transport : UDP, TCP entrelacé, multicast.
  4. Comparez la monodiffusion/la multidiffusion.
  5. Comparez les ports client, les ports serveur et les canaux entrelacés.
  6. Vérifiez si un proxy/restreamer se trouve dans le chemin.
  7. Vérifiez si les paquets RTP ultérieurs suivent le mappage de réponse.
  8. Comparez un joueur tolérant et un client strict en utilisant des preuves par paquets.
  9. Testez l’URL directe de la caméra si possible.
  10. Signalez la paire de transport exacte au vendeur.

Diagnostic final

"Transport sans correspondance dans la réponse du serveur" signifie que la négociation SETUP a produit une réponse de transport incompatible ou mal formée. La caméra ou le relais peut changer de mode RTP, omettre des champs ou renvoyer des valeurs que le client ne peut pas utiliser en toute sécurité.

RTSP Inspector aide en rendant visible la paire demande/réponse de transport, ce qui est le seul moyen fiable de diagnostiquer cette classe de défaillance RTSP.

Flux de travail connexes