9. Considérations RTSP
Le Real Time Streaming Protocol (RTSP), RFC 2326 [7], est un protocole de niveau application pour le contrôle de la livraison de données aux propriétés temps réel. La présente section examine les questions liées au contrôle des sessions RTP qui utilisent des retransmissions.
9.1. Contrôle RTSP avec multiplexage par SSRC
En cas de multiplexage par SSRC, la ligne « m » inclut les types de charge utile d'origine et de retransmission et possède un seul attribut RTSP « control ». Le récepteur utilise la ligne « m » pour demander SETUP et TEARDOWN de l'ensemble de la session média. Le profil RTP contenu dans l'en-tête Transport MUST être le profil AVPF ou un autre profil approprié autorisant le retour étendu. Si la valeur SSRC est incluse dans l'en-tête Transport de la réponse SETUP, elle MUST être celle du flux d'origine.
Afin de contrôler l'envoi du flux média d'origine de la session, le récepteur envoie comme d'habitude des requêtes PLAY et PAUSE à l'émetteur pour la session. L'en-tête RTP-info utilisé pour fixer les paramètres spécifiques RTP dans la réponse PLAY MUST être réglé selon les informations RTP du flux d'origine.
Lorsque le récepteur commence à recevoir le flux d'origine, il peut alors demander la retransmission via des NACK RTCP sans signalisation RTSP supplémentaire.
9.2. Contrôle RTSP avec multiplexage par session
En cas de multiplexage par session, chaque ligne « m » SDP a un attribut RTSP « control ». Ainsi, lorsque la retransmission est utilisée, la session d'origine et la session de retransmission ont chacune leurs attributs « control ». Le récepteur peut associer la session d'origine et la session de retransmission via la sémantique FID comme spécifié à la section 8.
Les flux d'origine et de retransmission sont établis et démontés séparément via leur attribut média « control » respectif. Le profil RTP contenu dans l'en-tête Transport MUST être le profil AVPF ou un autre profil approprié autorisant le retour étendu pour les sessions d'origine et de retransmission.
La présentation RTSP SHOULD prendre en charge le contrôle agrégé et SHOULD contenir une URL RTSP de niveau session. Le récepteur SHOULD utiliser le contrôle agrégé pour une session d'origine et sa session de retransmission associée. Sinon, il faudrait deux valeurs « session-id » différentes, c'est-à-dire des valeurs distinctes pour les sessions d'origine et de retransmission, et l'émetteur ne saurait pas comment les associer.
L'attribut « control » de niveau session est alors utilisé comme d'habitude pour contrôler la lecture du flux d'origine. Lorsque le récepteur commence à recevoir le flux d'origine, il peut alors demander des retransmissions via RTCP sans signalisation RTSP supplémentaire.
9.3. Contrôle RTSP du flux de retransmission
En raison de la nature des retransmissions, l'envoi des paquets de retransmission SHOULD NOT être contrôlé par des requêtes RTSP PLAY et PAUSE. Les requêtes PLAY et PAUSE SHOULD NOT affecter le flux de retransmission. Les paquets de retransmission sont envoyés sur demande du récepteur dans le flux RTCP d'origine, quel que soit l'état.
9.4. Contrôle du cache
Les flux de retransmission SHOULD NOT être mis en cache.
En cas de multiplexage par session, l'en-tête « Cache-Control » SHOULD être réglé sur « no-cache » pour le flux de retransmission.
En cas de multiplexage par SSRC, RTSP ne peut pas spécifier une mise en cache indépendante pour le flux de retransmission, car il n'y a qu'une seule ligne « m » dans SDP. L'implémenteur doit donc tenir compte de ce fait lorsqu'il décide ou non de mettre en cache une session multiplexée par SSRC.