3. Exigences et justification de conception d'un schéma de retransmission

L'usage des retransmissions dans RTP comme méthode de réparation pour le média en flux continu convient aux scénarios aux contraintes de délai assouplies où une fiabilité totale n'est pas requise. Plus précisément, la retransmission RTP permet d'arbitrer fiabilité et délai ; les extrémités peuvent abandonner la retransmission d'un paquet perdu après qu'un temps de mise en mémoire tampon donné s'est écoulé. Contrairement à TCP, il n'y a donc pas de blocage en tête de file causé par les retransmissions RTP. L'implémenteur doit être conscient que lorsqu'une fiabilité totale est requise ou que des délais et gigue plus élevés sont tolérables, TCP ou d'autres options de transport doivent être envisagés.

Le schéma de retransmission RTP défini dans le présent document est conçu pour satisfaire l'ensemble d'exigences suivant :

1. Il ne doit pas rompre les mécanismes généraux RTP et RTCP.

2. Il doit convenir à l'unicast et aux petits groupes multicast.

3. Il doit fonctionner avec les mixeurs et les traducteurs.

4. Il doit fonctionner avec tous les types de charge utile connus.

5. Il ne doit pas empêcher l'usage de plusieurs types de charge utile dans une session.

6. Afin de prendre en charge la plus grande variété de formats de charge utile, le récepteur RTP doit pouvoir déduire combien et quels paquets RTP ont été perdus du fait d'une discontinuité dans les numéros de séquence RTP reçus. Cette exigence est appelée préservation des numéros de séquence. Sans une telle exigence, il serait impossible d'utiliser la retransmission avec des formats de charge utile, tels que la conversation textuelle [9] ou la plupart des applications audio/vidéo en flux continu, qui utilisent le numéro de séquence RTP pour détecter les paquets perdus.

Lors de la conception d'une solution pour la retransmission RTP, plusieurs approches peuvent être envisagées pour le multiplexage des paquets RTP d'origine et des paquets RTP retransmis.

Une approche peut consister à retransmettre le paquet RTP avec son numéro de séquence d'origine et à envoyer les paquets d'origine et de retransmission dans le même flux RTP. Le paquet de retransmission serait alors identique au paquet RTP d'origine, c'est-à-dire le même en-tête (et donc le même numéro de séquence) et la même charge utile. Une telle approche n'est toutefois pas acceptable car elle corromprait les statistiques RTCP. Par conséquent, l'exigence 1 ne serait pas satisfaite. Des statistiques RTCP correctes exigent que, pour chaque paquet RTP dans le flux RTP, le numéro de séquence soit augmenté d'une unité.

Une autre approche peut consister à multiplexer les paquets RTP d'origine et les paquets de retransmission dans le même flux RTP en utilisant des valeurs de type de charge utile différentes. Avec une telle approche, les paquets d'origine et les paquets de retransmission partageraient le même espace de numéros de séquence. En conséquence, le récepteur RTP ne pourrait pas inférer combien et quels paquets d'origine (quels numéros de séquence) ont été perdus.

En d'autres termes, cette approche ne satisfait pas l'exigence de préservation des numéros de séquence (exigence 6). Cela implique à son tour que l'exigence 4 ne serait pas satisfaite. L'interopérabilité avec les mixeurs et les traducteurs serait également plus difficile s'ils ne comprenaient pas ce nouveau type de charge utile de retransmission dans un flux RTP d'émetteur. Pour ces raisons, une solution fondée sur le multiplexage par type de charge utile des paquets d'origine et de retransmission dans le même flux RTP est exclue.

Enfin, les paquets d'origine et de retransmission peuvent être envoyés dans deux flux distincts. Ces deux flux peuvent être multiplexés soit en les envoyant dans deux sessions différentes, c'est-à-dire multiplexage par session, soit dans la même session en utilisant des valeurs SSRC différentes, c'est-à-dire multiplexage par SSRC. Comme les paquets d'origine et de retransmission transportent un média du même type, les objections de la section 5.2 de RTP [3] au multiplexage RTP ne s'appliquent pas dans ce cas.

Les mixeurs et les traducteurs peuvent traiter le flux d'origine et simplement rejeter le flux de retransmission s'ils ne peuvent pas l'utiliser.

En revanche, envoyer les paquets d'origine et de retransmission dans deux flux distincts ne suffit pas à lui seul à satisfaire les exigences 1 et 6. À cette fin, le présent document inclut le numéro de séquence d'origine dans les paquets retransmis.

De cette manière, l'usage de deux flux distincts satisfait toutes les exigences énumérées dans la présente section.