- État Fermée
- Pourcentage achevé
- Type Anomalie
- Catégorie Télévision
- Assignée à Personne
- Système d'exploitation Tous
- Sévérité Moyenne
- Priorité Très Basse
- Basée sur la version 2.1.2
- Due pour la version Non décidée
-
Échéance
Non décidée
- Votes
- Privée
Ouverte par vjamoull - 28/06/2014
Dernière modification par mbizon - 18/07/2014
FS#15232 - Multiposte, rtsp negocie un RTP udp port incorrect
Bonjour,
petit nouveau chez free j essaye deseperement de faire fonctionner le multiposte a travers mon firewall. Que je branche la box en bridge ou routeur rien n y fait car il y a un probleme de gestion du RTSP/RTP.
voici le descriptif du bug:
lors de la connexion rtsp, la freebox et mon client negocie les ports RTP: RTP/AVP;unicast;mode=play;destination=192.168.0.1;client_port=60438-60439;server_port=32782-32783
les ports serveur sont evidement fournis par la box et non pas par mon client. avec ca mon RTSP helper situe sur mon firewall attend un flux rdp d un src port 32782-3 ce qui n arrive jamais car la box n utilise pas les port qu elle declare. j ai a la place un rtp avec le flux: User Datagram Protocol, Src Port: 59823 (59823), Dst Port: 60438 (60438). Cela a pour effect de ne pas passer mon firewall et tout ca car la rfc n est pas respectee.
Je n ai pas du tout envie de configurer des port nat pour chacun des pc/tab de ma maison, et puis franchement a quoi sert un helper, a solutionner ce genre de probleme! Maintenant si le protocol n est pas respecte le helper ne sert a rien et on es tous un peu dans la m...
Serait t il possible de corriger ce bug pour que les server_port declare par la box soit effectivement utilise? Si vous avez un workaround pour moi sans devoir mettre mon firewall en mode passoir je suis preneur?
Merci,
v
Ps : pour moi la rfc 2326 est clair:
server_port:
This parameter provides the unicast RTP/RTCP port pair on
which the server has chosen to receive media data and control
information. It is specified as a range, e.g.,
server_port=3456-3457.
Maintenant si vous ne l utiliser pas bon ben y a rien qui marche. en plus je ne comprend vraiment pas car je m attendais a trouver dans tous les forum une discussion sur ce probleme et le seul truc que je vois c du monde qui discute comment bypasser ce probleme box en ouvrant des port partout sur les FW. Peut etre que je n ai pas bien regarde mais franchement si vous pouviez solutionner ce bug cela m aiderait bcp et je suis sur bcp d autre personne qui pour le moment n utilisent pas leurs helper a cause de ce serveur-port incorrect.
Chargement...
Activer les raccourcis clavier
- Alt + ⇧ Shift + l Se connecter/Se déconnecter
- Alt + ⇧ Shift + a Ouvrir une tâche
- Alt + ⇧ Shift + m Mes recherches
- Alt + ⇧ Shift + t Rechercher par ID de tâche
Liste des tâches
- o Ouvrir la tâche sélectionnée
- j Déplacer le curseur vers le bas
- k Déplacer le curseur vers le haut
Détails de la tâche
- n Tâche suivante
- p Tâche précédente
- Alt + ⇧ Shift + e ↵ Enter Modifier cette tâche
- Alt + ⇧ Shift + w Surveiller
- Alt + ⇧ Shift + y Fermer cette tâche
Édition de la tâche
- Alt + ⇧ Shift + s Enregistrer la tâche
non vous avez mal compris à quoi sert server_port:
http://www.universfreebox.com/article/826/Le-multiposte-et-les-routeurs
Merci Maxime,
j ai surement ete trop vite dans ma lecture de la rfc.
je regarderais cela ce wk.
merci,
v
Bonjour Maxime, all
J ai enfin eu un peu de temps pour relire la RFC et je ne pense pas m etre trompe en decrivant ce comportement comme un bug. les deux ports definit en Server-port sont pour le premier le port RTP et le second le rtcp. Le streaming server devrait ouvrir une connection RTP (RTP/AVP;unicast;mode=play;destination=192.168.0.1;client_port=60438-60439;server_port=32782-32783) du src port 32782 vers le destination port 60438 et il ne le fait pas car sont src port ne suit pas ce que lui meme definit.
Maintenant que le conntrack du linux le permette pour moi cela aussi est un bug car il ne prend pas en compte le src port (trop ouvert pour un helper, ca resemble a du cone nat). Dans mon cas j utilise un fortigate et celui ci ouvre une pinhole session pour le rtp et le rtcp qui correspond au port negocie. si je prend un des free streaming rtsp disponible sur l internet je n ai aucun probleme car le pinhole fonctione tres bien et les serveurs autre que le multiposte respecte le protocol (server port et client port sont utilise pour le rtp).
Je n ai pas vraiment envie de changer de firewall qui lui fonctionne tres bien, j ai l impression que free fait du nat sur sont flux RTP en ne preservant pas le src port ce qui me creer tous les problemes que j ai depuis mon arrivee chez free.
Est il possible de caracteriser ce probleme comme un bug, y a t il un workaround pour que le flux respecte la negociation des ports? cela peut il etre corrige?
Merci,
v
non, les ports sont ouverts des 2 cotés car le trafic est bidirectionnel
1) Le serveur (freebox) envoie du rtp vers le client (PC)
2) Le client (PC) envoie du rtcp vers le server (Freebox)
client_port=60438-60439 ⇒ le PC écoute en RTP sur 60438 et RTCP sur 60439
server_port=32782-32783 ⇒ la freebox écoute en RTP sur 32782 et RTCP sur 32783
cool je pense qu on y es presque (presque a ce comprendre).
On es d accord de dire que le protocol est bi-dir et la RFC prend ca en compte, donc le client peut etre un emeteur et un recepteur pareil pour le serveur et c pour cela que vous avez un minimum de deux ports de chaque cote. donc dans l exemple donne le client peu recevoir du rtp sur 60438 et du rtcp sur 60439 et le serveur peu recevoir du rtp sur 32782 et du rtcp sur 32783. que le client balance du rtp ou pas n est pas le probleme dans le cas de la freebox on ne le fait pas mais le protocol prevois cela.
en resume et pour le RTP la communication prevue par le protocol est entre 60438 et 32782 bi-dir prevu par le rtsp, de nouveau qu il soit envoye ou pas n est pas le probleme, le protocol le prevoit c tout. comme le proto le prevoit mon helper ouvre c port en pinhole ce qui est logique, ce que free fait cependant c de dire que n importe quel src peut aller en RTP sur le destination 60438 ce qui casse le concept du protocol et de la rfc qui elle prevoit un bi-dir channel RTP entre la src et le serveur. Par la meme occasion cela casse aussi mon helper qui bloque tout ce qui n est pas du udp entre 60438 et 32782.
exemple prenez un pcap du free multibox et comparez la au pcap de ceci http://www.iptv-player.com/index.php?fdb=1&title=%20Discovery+Science%20%20&stream=rtsp%3A%2F%2F211.79.36.213%2Fdiscoveryscience_gphone.sdp vous verrez que dans le cas du freeplayer il y a un comportement anormal par contre dans le second cas vous aurez effectivement un flux RTP entre les deux premier port pair (server et client). Vous verrez aussi que dans le premier cas wireshark ne reconnais pas vos flux comme du RTP par contre dans le deuxieme il seront reconnu. Wireshark fait comme mon helper il regarde la partie transport et si il reconnais le flux il associe automatiquement le decodeur. Dans le cas de free wireshark est paume car le protocol n est pas respecte dans le second cas par contre il n y a aucun probleme.
Maintenant pour moi la discussion est juste autour du fait de definir cela comme un bug ou pas, si la RFC est respectee le comportement n est pas celui d un bug et je vais me retourner contre fortinet pour qu il change leur RTSP helper. Si ce comportement est un bug j ai toujour une chance qu il soit corrige et que un jour je puisse faire du xbmc avec le freeplayer sans pour cela devoir ouvrir completement mon firewall.
Merci bcp pour cette discussion, que j y arrive ou pas n es pas le probleme au moins j ai qq un a qui parler.
v
pour simplifier la discussion je vous ai pris deux printscreen de mon wireshark + commentaire (cas de la box et cas discovery).
https://www.dropbox.com/l/ulavtB7hXnIMwgPw9qGwps?
Rgs,
v
rfc2326, section Transport:
server_port: This parameter provides the unicast RTP/RTCP port pair on which the server has chosen to receive media data and control information. It is specified as a range, e.g., server_port=3456-3457.nul part il n'est dit que le server_port est aussi le port source du flux
d'ailleurs:
source: If the source address for the stream is different than can be derived from the RTSP endpoint address (the server in playback or the client in recording), the source MAY be specified.il est donc prévu que le flux puisse avoir une autre IP source que celle du serveur. Dans ce cas le client enverrait toujours le RTCP au serveur sur server_port.
Bref server_port et port source du flux n'ont pour moi aucun lien.
Bonjour Maxime,
J ai eu bcp de boulot cette semaine je n ai donc pas pu repondre avant. J ai ouvert un ticket chez fortinet demendant de changer leur helper pour qu il prenne en compte la variabilite du src port.
La RFC est ambigue pour moi car vous avez aussi cette phrase: The Transport header is restricted to describing a single RTP stream. L exemple d ou cette phrase est tiree n a pas de server-port mais cela ne change rien a son sens qui dans ce cas voudrait dire une session bi-dir. vous pouvez avoir plusieurs sessions managee par un RTSP flow mais vous devriez des lors aussi avoir plusieurs setup et transport (ou sdp).
La logique/l usage voudrait qu effectivement le src port server soit utilise pour le RTP maintenant je ne trouve aucun MUST dans cette RFC et je ne peu que me rabatre sur votre conclusion qui est qu un variable src port est acceptable. J ai donc demande un changement du FGT helper (je verrais bien si cela passe).
Merci pour cet echange, je vous souhaite une bonne journee,
v
ps: je ne devrais pas pose cette question ici mais parler a un expert fait gagner bcp de tmp. avant d arriver chez free il y a qque semaines j etais chez sfr et sfr avait une application de streaming tv disponible sur tab et tel qui fonctionait de n importe quel point d entree (wifi/3g/etc). Il me semble que le streaming free n est disponible que via le reseau local avec un debit minimum de 2mbps ce qui est trop lourd pour mon upstream (pour reforwarder le flux si je ne suis pas a la maison). Pour garder ce service qui etait dispo chez SFR j ai monte une solution vpn + vodobox sur mon local lan. Existe t il une meilleur solution, le streaming est t il disponible apres auth sur des serveurs free le but etant de m afranchir de la limite up? je comprendrais parfaitement que vous ne vouliez pas repondre ici, ce ticket etant specific au rtsp et pas la question.
Rgs,
v