Freebox Player (Revolution / V6)

  • État À investiguer
  • Type de tâche Anomalie
  • Catégorie Lecteur multimédia → Serveur de rendu UPnP/DLNA
  • Assignée à Benoît Rouits (brouits)
  • Système d'exploitation Tous
  • Sévérité Basse
  • Priorité Normale
  • Basée sur la version 1.3.18
  • Due pour la version Non décidé
  • Date d'échéance Non décidé
Concerne le projet: Freebox Player (Revolution / V6)
Ouverte par _FrnchFrgg_ (frnchfrgg) - 09/02/2014
Dernière édition par Benoît Rouits (brouits) - 12/05/2014

FS#14263 - L'accès RTSP demande un Transport: non standard

Le Player demande le transport FBXRTP/AVP au lieu de RTP/AVP dans la méthode SETUP, ce qui casse l’interopérabilité avec la plupart des serveurs RTSP. Je vois quatre solutions:

1) Considérer le support RTSP comme purement interne à la Freebox, pour la TV ou le replay (vu dans le debug que c’est du RTP), et cesser d’annoncer rtsp-rtp-udp comme un protocole reconnu pour upnp/av

2) Une variante, continuer d’annoncer le support mais précéder le SETUP par un appel à la méthode OPTIONS:
OPTIONS * RTSP/1.0
CSeq: 6
Require: fbxrtp-transport

Comme ça le but est totalement clair. Voir http://tools.ietf.org/html/rfc2326#page-30

À noter que le Player spamme le serveur rtsp avec des appels à OPTIONS sans payload, je ne vois pas bien à quoi c’est sensé servir.

3) Remplacer la demande FBXRTP/AVP par un réel RTP/AVP

4) Faire un premier SETUP avec Transport: FBXRTP/AVP;... et si la réponse est “461 Unsupported Transport” réessayer en mode “compatible” avec RTP/AVP; une alternative est de détecter le support FBXRTP avec la méthode OPTIONS et choisir après quel transport demander.

Je ne pense pas que les solutions 1) et 2) soient intéressantes hormis qu’elles sont celles qui demandent le moins de travail/maintenance de la part des dev freebox. La 3 est la plus correcte niveau interopérabilité, mais si vous avez un FBXRTP c’est probablement pour avoir des fonctions ad-hoc dedans auquelles vous ne pouvez peut-être pas renoncer.
La 4 représente le meilleur compromis IMHO, avec un système inchangé pour les utilisations existantes (donc pas de maintainance nightmare sur la TV ou autre) et une interopérabilité accrue dans les autres cas.

Cette tache ne dépend pas d'autre tache

_FrnchFrgg_ (frnchfrgg)
dimanche 9 février, 2014 18:23:59

Désolé, j'ai validé avant d'avoir fini (il faudrait peut-être désactiver la validation par "Entrée" dans le champ "Titre de la tâche"...), le composant aurait dû être UPNP/AV.

Chargement...