Groupe de travail Réseau	J. Rey, Panasonic	
Request for Comments : 4588	D. Leon, consultant	
Catégorie : Sur la voie de la normalisation	A. Miyazaki, Panasonic	
Traduction Claude Brière de L'Isle	V. Varsa, Nokia	
	juillet 2006	

Format de charge utile de retransmission RTP

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de Copyright
Copyright (C) The Internet Society (2006).

Résumé
La retransmission RTP est une technique efficace de récupération de perte de paquet pour les applications en temps réel avec des limites de délai lâches. Le présent document décrit un format de charge utile RTP pour effectuer des retransmissions. Les paquets RTP retransmis sont envoyés dans un flux séparé du flux RTP d'origine. On suppose que des rétroactions des receveurs aux envoyeurs sont disponibles. En particulier, on suppose dans le présent mémoire que la rétroaction du protocole de contrôle de transport en temps réel (RTCP, Real-time Transport Control Protocol) comme définie dans le profil étendu RTP pour rétroaction fondée sur RTCP (notée RTP/AVPF) est disponible.
Table des matières
1. Introduction	2
2. Terminologie	2
3. Exigences et raisons de la conception pour un schéma de retransmission	3
3.1 Choix d'un schéma de multiplexage	4
4. Format de charge utile de retransmission	4
5. Association de la retransmission et des flux originaux	6
5.1 Partage de session de retransmission	6
5.2 Utilisation de CNAME	6
5.3 Association chez le receveur	6
6. Utilisation avec le profil RTP étendu pour rétroaction fondée sur RTCP	6
6.1 RTCP chez l'envoyeur	7
6.2 Rapports RTCP du receveur	7
6.3 Demandes de retransmission	7
6.4 Règles de temps	8
7. Contrôle d'encombrement	8
8. Enregistrement de type MIME de format de charge utile de retransmission	9
8.1 Introduction	9
8.2 Enregistrement de audio/rtx	9
8.3 Enregistrement de video/rtx	10
8.4 Enregistrement de text/rtx	10
8.5 Enregistrement de application/rtx	10
8.6 Transposition en SDP	11
8.7 Description SDP avec multiplexage de session	11
8.8 Description SDP avec multiplexage SSRC	12
9. Considérations sur RTSP	12
9.1 Contrôle RTSP avec multiplexage de SSRC	12
9.2 Contrôle RTSP avec multiplexage de session	13
9.3 Contrôle RTSP du flux de retransmission	13
9.4 Contrôle d'antémémoire	13
10. Exemples de mise en œuvre	13
10.1 Exemple de mise en œuvre minimale de receveur	13
10.2 Retransmission de supports codés en couches en diffusion groupée	14
11. Considérations relatives à l'IANA	14
12. Considérations sur la sécurité	15
13. Remerciements	15
14. Références	15
14.1 Références normatives	15
14.2 Références pour information	16
Appendice A. Comment contrôler le nombre de retransmissions par paquet	16
A.1 Scénarios et hypothèses	16
A.2 But	17
A.3 Solution	17
A.4 Nombres	18
Adresse des auteurs	19
Déclaration complète de droits de reproduction	20

 	1.	Introduction

Les pertes de paquet entre un envoyeur et un receveur RTP peuvent significativement dégrader la qualité des supports reçus. Plusieurs techniques, comme la correction d'erreur directe (FEC, forward error correction), les retransmissions, ou l'entrelacement, peuvent être envisagées pour augmenter la résilience à la perte de paquet. La [RFC2354] discute les différentes options.

Quand on choisit une technique de réparation pour une certaine application, la latence tolérable de l'application doit être prise en compte. Dans le cas des conférences multimédia, le délai de bout en bout doit être au plus de quelques dixièmes de secondes afin de garantir l'interactivité, qui exclut généralement l'utilisation de la retransmission.

Avec une latence suffisante, l'efficacité du schéma de réparation peut être augmentée. L'envoyeur peut utiliser la rétroaction du receveur afin de réagir aux pertes avant leur moment d'exécution chez le receveur.

Dans le cas de flux directs multimédia, l'utilisateur peut tolérer une latence initiale au titre de l'établissement de session et donc un délai de bout en bout de plusieurs secondes peut être acceptable. La retransmission RTP comme définie dans le présent document est ciblée sur de telles applications.

De plus, la méthode de retransmission RTP définie ici est applicable à l'envoi individuel et aux groupes (petits) de diffusion groupée. Le présent document définit un format de charge utile pour les paquets RTP retransmis et fournit les règles de protocole pour l'envoyeur et le receveur impliqués dans les retransmissions.

Ce format de charge utile de retransmission a été conçu pour l'usage avec le profil RTP étendu pour les rétroactions fondées sur RTCP, AVPF [RFC4585]. Il peut aussi être utilisé avec d'autres profils RTP qui seraient définis à l'avenir.

Le profil AVPF permet une rétroaction plus fréquente et une rétroaction précoce. Il définit un message de rétroaction général, c'est-à-dire, NACK, ainsi que des messages de rétroaction spécifiques du codec et de l'application. Voir les détails dans la [RFC4585].

 	2.	Terminologie

Les termes suivants sont utilisés dans le présent document :

CSRC (contributing source)  : source contributive. Voir la [RFC3550].

paquet d'origine : paquet RTP qui porte des données d'utilisateur envoyées pour la première fois par un envoyeur RTP.

flux d'origine : le flux RTP des paquets d'origine. 

paquet de retransmission : paquet RTP qui est à utiliser par le receveur à la place d'un paquet d'origine perdu. Un tel paquet de retransmission est dit être associé au paquet RTP d'origine.

demande de retransmission : moyen par lequel un receveur RTP est capable de demander que l'envoyeur RTP devrait envoyer un paquet de retransmission pour un certain paquet d'origine. Généralement un paquet RTCP NACK comme spécifié dans la [RFC4585] est utilisé comme demande de retransmission des paquets perdus.

flux de retransmission : flux des paquets de retransmission associé à un flux d'origine.

multiplexage de session : schéma par lequel le flux d'origine et le flux de retransmission associé sont envoyés dans deux sessions RTP différentes.

SSRC (synchronization source)  : source de synchronisation. Voir la [RFC3550].

multiplexage de SSRC : schéma par lequel le flux d'origine et le flux de retransmission sont envoyés dans la même session RTP avec des valeurs de SSRC différentes.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	3.	Exigences et raisons de la conception pour un schéma de retransmission

L'utilisation des retransmissions dans RTP comme méthode de réparation pour les supports de flux directs est appropriée dans les scénarios qui ont des limites de délai lâches et où une fiabilité complète n'est pas exigée. Plus précisément, la retransmission RTP permet un compromis entre fiabilité et délai ; c'est-à-dire que les points d'extrémité peuvent abandonner la retransmission d'un paquet perdu après l'écoulement d'un certain temps de mise en mémoire tampon. À la différence de TCP, il n'y a pas de blocage de tête de ligne causé par les retransmissions RTP. Une mise en œuvre devrait être consciente que dans les cas où une fiabilité complète est requise ou si des délais et une gigue plus grands peuvent être tolérés, TCP ou d'autres options de transport devraient ê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 casser les mécanismes généraux de RTP et RTCP.
2. Il doit être convenable pour l'envoi individuel et les petits groupes de diffusion groupée.
3. Il doit fonctionner avec des mixeurs et des traducteurs.
4. Il doit fonctionner avec tous les types de charge utile connus.
5. Il ne doit pas empêcher l'utilisation 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 receveur RTP doit être capable de déduire combien de paquets RTP ont été perdus, et lesquels, par suite d'un trou dans les numéros de séquence RTP reçus. Cette exigence est appelée la préservation du numéro de séquence. Sans une telle exigence, il serait impossible d'utiliser la retransmission avec des formats de charge utile, comme la conversation textuelle [RFC4103] ou la plupart des applications de flux directs audio/vidéo, qui utilisent le numéro de séquence RTP pour détecter les paquets perdus.

Pour concevoir une solution pour la retransmission RTP, plusieurs approches peuvent être considérées pour le multiplexage des paquets RTP d'origine et des paquets RTP retransmis.

Une approche peut être de retransmettre le paquet RTP avec son numéro de séquence d'origine et d'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, avec le même en-tête (et donc le même numéro de séquence) et la même charge utile. Cependant, cette approche n'est pas acceptable parce que elle corromprait les statistiques de 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é de un.

Une autre approche peut être de multiplexer les paquets RTP d'origine et de retransmission dans le même flux RTP en utilisant différentes valeurs de type de charge utile. Avec cette approche, les paquets d'origine et de retransmission vont partager le même espace de numéros de séquence. Par suite, le receveur RTP ne sera pas capable de déduire 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 du numéro de séquence (exigence 6). Ceci implique que l'exigence 4 ne va pas être satisfaite. L'interopérabilité avec les mixeurs et traducteurs va aussi être plus difficile si ils ne comprennent pas ce nouveau type de charge utile de retransmission dans un flux d'envoyeur RTP. Pour ces raisons, une solution fondée sur le multiplexage des types de charge utile des paquets d'origine et de retransmission dans le même flux RTP est exclue.

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

Les mixeurs et traducteurs peuvent traiter le flux d'origine et simplement éliminer le flux de retransmission si ils sont incapables de l'utiliser.

Par ailleurs, envoyer les paquets d'origine et de retransmission dans deux flux séparés ne permet pas à lui seul de satisfaire les exigences 1 et 6. Pour cela, le présent document inclut le numéro de séquence d'origine dans les paquets retransmis.

De cette manière, utiliser deux flux séparés satisfait toutes les exigences de cette section.

 	3.1	Choix d'un schéma de multiplexage
Le multiplexage de session et le multiplexage de SSRC ont des avantages et inconvénients différents :

Le multiplexage de session se fonde sur l'envoi du flux de retransmission dans une session RTP différente (comme défini dans RTP [RFC3550]) de celle du flux d'origine ; c'est-à-dire que le flux d'origine et le flux de retransmission sont envoyés à des adresses et/ou numéros d'accès réseau différents. Avoir des sessions séparées permet plus de souplesse. En diffusion groupée, utiliser deux sessions séparées pour le flux d'origine et le flux de retransmission permet à un receveur de choisir si il s'abonne ou non à la session RTP qui porte le flux de retransmission. La session d'origine peut aussi être une diffusion groupée d'une seule source tandis que des sessions en envoi individuel séparées sont utilisées pour convoyer les retransmissions à chaque receveur, qui par suite vont recevoir seulement les paquets de retransmission qu'ils demandent.

L'utilisation de sessions séparées facilite aussi un traitement différentiel par le réseau et peut simplifier le traitement dans les mixeurs, traducteurs, et antémémoires de paquets.

Avec le multiplexage de SSRC, une seule session est nécessaire pour le flux d'origine et le flux de retransmission. Cela permet aux serveurs et boîtiers de médiation de flux de direct qui sont impliqués dans un grand nombre de sessions concurrentes de minimiser l'usage de leurs accès.

Ce format de charge utile de retransmission permet le multiplexage de session et le multiplexage de SSRC pour les sessions en envoi individuel. Du point de vue d'une mise en œuvre, il y a peu de différence entre les deux approches. Donc, afin de maximiser l'interopérabilité, les deux approches de multiplexage DEVRAIENT être prises en charge par les envoyeurs et receveurs. Pour les sessions en diffusion groupée, le multiplexage de session DOIT être utilisé parce que l'association du flux d'origine et du flux de retransmission est problématique si le multiplexage de SSRC est utilisé avec des sessions de diffusion groupée (voir les motifs au paragraphe 5.3).

 	4.	Format de charge utile de retransmission

Le format d'un paquet de retransmission est montré ci-dessous :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        En-tête RTP                            |
+---------------+---------------+---------------+---------------+
|  Numéro de séquence d'origine |                               |
+---------------+---------------+                               |
|               Charge utile de paquet RTP d'origine            |
|                                                               |
+---------------+---------------+---------------+---------------+

L'utilisation de l'en-tête RTP est la suivante :

Dans le cas de multiplexage de session, la même valeur de SSRC DOIT être utilisée pour le flux d'origine et le flux de retransmission. Dans le cas d'une collision de SSRC dans la session d'origine ou dans la session de retransmission, la spécification RTP exige qu'un paquet RTCP BYE soit envoyé dans la session où la collision s'est produite. De plus, un paquet RTCP BYE DOIT aussi être envoyé pour le flux associé dans sa propre session. Après l'obtention d'un nouvel identifiant de SSRC, le SSRC des deux flux DOIT être réglé à cette valeur.

Dans le cas de multiplexage de SSRC, deux valeurs différentes de SSRC DOIVENT être utilisées pour le flux original et le flux de retransmission comme exigé par RTP. Si une collision de SSRC est détectée pour le flux original ou le flux de retransmission, la spécification RTP exige qu'un paquet RTCP BYE DOIT être envoyé pour ce flux. Un paquet RTCP BYE NE DOIT PAS être envoyé pour le flux associé. Donc, seul le flux qui a subi la collision de SSRC DOIT choisir une nouvelle valeur de SSRC. Voir au paragraphe 5.3 les implications sur l'association de SSRC de flux original et de flux de retransmission chez le receveur.

Pour l'un et l'autre schéma de multiplexage, le numéro de séquence a la définition standard ; c'est-à-dire, il DOIT être supérieur de un au numéro de séquence du paquet précédent envoyé dans le flux de retransmission.

L'horodatage du paquet de retransmission DOIT être réglé à l'horodatage original, c'est-à-dire, à l'horodatage du paquet original. Par conséquent, l'horodatage initial RTP pour le premier paquet du flux de retransmission n'est pas aléatoire mais égal à l'horodatage original du premier paquet qui est retransmis. Voir dans la section Considérations de sécurité du présent document les implications sur la sécurité.

Les mises en œuvre devraient avoir conscience que la valeur de gigue RTCP pour le flux de retransmission ne reflète pas la gigue réelle du réseau car il pourrait y avoir peu de corrélation entre l'heure de retransmission d'un paquet et son horodatage original.

Le type de charge utile est dynamique. Si plusieurs types de charge utile qui utilisent la retransmission sont présents dans le flux original, alors pour chacun d'eux, un type de charge utile dynamique DOIT être transposé en le format de retransmission de charge utile. Voir au paragraphe 8.1 la spécification de la transposition entre le type original et le type de retransmission de charge utile avec le protocole de description de session (SDP, Session Description Protocol).

Comme l'horodatage du paquet de retransmission porte l'horodatage du support original, le débit d'horloge de l'horodatage utilisé par le type de charge utile de retransmission DOIT être le même que celui utilisé par le type de charge utile original associé. Donc, si un flux RTP porte des types de charge utile de débits d'horloge différents, cela va aussi être le cas pour le flux de retransmission associé. Noter qu'un flux RTP ne porte généralement pas des types de charge utile de débits d'horloge différents.

La charge utile du paquet de retransmission RTP comporte l'en-tête de charge utile de retransmission suivi par la charge utile du paquet RTP original. La longueur de l'en-tête de charge utile de retransmission est 2 octets. Cet en-tête de charge utile contient seulement un champ, OSN (numéro de séquence original) qui DOIT être réglé au numéro de séquence du paquet RTP original associé. La charge utile du paquet RTP original, incluant tous les en-têtes de charge utile possibles spécifiques du type de charge utile originale, DOIT être placée juste après l'en-tête de charge utile de retransmission.

Pour les formats de charge utile qui prennent en charge le codage à plusieurs débits, au lieu de retransmettre la même charge utile que le paquet RTP original, l'envoyeur PEUT retransmettre les mêmes données codées à un débit inférieur. Cela vise à limiter l'usage de bande passante du flux de retransmission. En faisant ainsi, l'envoyeur DOIT s'assurer que le receveur va encore être capable de décoder la charge utile des paquets originaux déjà envoyés qui pourraient avoir été codés sur la base de la charge utile du paquet original perdu. De plus, si l'envoyeur choisit de retransmettre à un plus bas débit, les valeurs dans l'en-tête de charge utile du paquet RTP original peuvent ne plus s'appliquer au paquet de retransmission et peuvent devoir être modifiées dans le paquet de retransmission pour refléter le changement de débit. L'envoyeur DEVRAIT faire un compromis entre la diminution d'usage de bande passante et la diminution de qualité causée par l'envoi à un plus faible débit.

Si l'en-tête RTP original portait des extensions spécifiques du profil, le paquet de retransmission DEVRAIT inclure les mêmes extensions suivant immédiatement l'en-tête fixe RTP comme attendu par les applications qui fonctionnent avec ce profil. Dans ce cas, l'en-tête de charge utile de retransmission DOIT être placé après les extensions spécifiques du profil

Si l'en-tête RTP original portait une extension d'en-tête RTP, le paquet de retransmission DEVRAIT porter la même extension d'en-tête. Cette extension d'en-tête DOIT être placée juste après l'en-tête fixe RTP, comme spécifié dans la [RFC3550]. Dans ce cas, l'en-tête de charge utile de retransmission DOIT être placé après l'extension d'en-tête.

Si le paquet RTP original contenait un bourrage RTP, ce bourrage DOIT être retiré avant de construire le paquet de retransmission. Si le bourrage du paquet de retransmission est nécessaire, ce bourrage DOIT être effectué comme avec tout paquet RTP et le bit de bourrage DOIT être établi.

Le bit marqueur (M), le compte de CSRC (CC), et la liste de CSRC de l'en-tête original RTP DOIVENT être copiés "tels quels" dans l'en-tête RTP du paquet de retransmission.

 	5.	Association de la retransmission et des flux originaux
 	5.1	Partage de session de retransmission
Dans le cas de multiplexage de session, une session de retransmission DOIT se transposer en exactement une session d'origine ; c'est-à-dire, la même session de retransmission ne peut pas être utilisée pour différentes sessions originales.

Si le partage de session de retransmission était permis, cela poserait un problème aux receveurs, car ils recevraient des retransmissions pour des sessions originales auxquelles ils pourraient ne s'être pas joints. Par exemple, un receveur souhaitant recevoir seulement de l'audio pourrait recevoir aussi des paquets vidéo retransmis si une session audio et une session vidéo partageaient la même session de retransmission.

 	5.2	Utilisation de CNAME
Dans les deux cas de multiplexage de session et de multiplexage de SSRC, un envoyeur DOIT utiliser le même RTCP CNAME [RFC3550] pour un flux original et son flux de retransmission associé.

 	5.3	Association chez le receveur
Un receveur qui reçoit plusieurs flux originaux et de retransmission a besoin d'associer chaque flux de retransmission avec son flux original. L'association est faite différemment selon que est utilisé le multiplexage de session ou de SSRC.

Si le multiplexage de session est utilisé, le receveur associe les deux flux qui ont le même SSRC dans les deux sessions. Noter que le champ Type de charge utile ne peut pas être utilisé pour effectuer l'association car plusieurs flux de supports peuvent avoir la même valeur de type de charge utile. Les deux sessions sont elles mêmes associées hors bande. Voir à la Section 8 comment le groupage de deux sessions est fait avec SDP.

Si le multiplexage de SSRC est utilisé, le receveur devrait tout d'abord chercher deux flux qui ont le même CNAME dans la session. Dans certains cas, le CNAME peut n'être pas suffisant pour déterminer l'association car plusieurs flux originaux dans la même session peuvent partager le même CNAME. Par exemple, il peut y avoir dans la même session vidéo plusieurs flux vidéo qui se transposent en différentes SSRC et utilisent pourtant le même CNAME et éventuellement les mêmes valeurs de type de charge utile. Chacun (ou certains) de ces flux peut avoir un flux de retransmission associé.

Dans ce cas, afin de découvrir l'association entre flux original et de retransmission avec le même CNAME, le receveur DEVRAIT se comporter comme suit.

L'association peut généralement se résoudre quand le receveur reçoit un paquet de retransmission qui correspond à une demande de retransmission envoyée antérieurement. À réception d'un paquet de retransmission dont le numéro de séquence original avait été précédemment demandé, le receveur peut déduire que la SSRC du paquet de retransmission est associée à la SSRC de l'envoyeur de qui le paquet a été demandé.

Cependant, ce mécanisme peut échouer si il y a deux demandes en instance pour le même numéro de séquence de paquet dans deux flux originaux différents de la session. Noter que comme les numéros de séquence de paquet initial sont aléatoires, la probabilité d'avoir deux demandes en instance pour le même numéro de séquence de paquet va être très faible. Néanmoins, afin d'éviter des ambiguïtés dans le cas d'envoi individuel, le receveur NE DOIT PAS avoir deux demandes en instance pour le même numéro de séquence de paquet dans deux flux originaux différents avant la résolution de l’association. En diffusion groupée, cette ambiguïté ne peut pas être complètement évitée, parce que un autre receveur peut avoir demandé le même numéro de séquence d'un autre flux. Donc, le multiplexage de SSRC NE DOIT PAS être utilisé dans les sessions de diffusion groupée.

Si le receveur découvre que deux envoyeurs utilisent la même SSRC ou si il reçoit un paquet RTCP BYE, il DOIT arrêter de demander des retransmissions pour cette SSRC. À réception des paquets RTP originaux avec une nouvelle SSRC, le receveur DOIT effectuer à nouveau l'association de SSRC comme décrit dans cette section.

 	6.	Utilisation avec le profil RTP étendu pour rétroaction fondée sur RTCP

Cette section donne des indications générales pour l'usage de ce format de charge utile avec le profil RTP étendu pour les rétroactions fondées sur RTCP, notées des AVPF [RFC4585]. Noter que les règles générales RTCP d'envoi et de réception et du format de paquet RTCP comme spécifié dans RTP s'appliquent, sauf pour les changements introduits par le profil AVPF. En bref, le profil AVPF relâche les règles de rythme de RTCP et spécifie des messages supplémentaires de rétroaction RTCP d'utilisation générale. Voir les détails dans la [RFC4585].

 	6.1	RTCP chez l'envoyeur
Dans le cas de multiplexage de session, des paquets Rapport d'envoyeur (SR, Sender Report) pour le flux original sont envoyés dans la session d'origine et les paquets SR pour le flux de retransmission sont envoyés dans la session de retransmission conformément aux règles de RTP.

Dans le cas de multiplexage de SSRC, les paquets SR pour les deux flux original et de retransmission sont envoyés dans la même session conformément aux règles de RTP. Le flux original et le flux de retransmission sont vus, pour ce qui concerne le calcul de la bande passante RTCP, comme des envoyeurs indépendants qui appartiennent à la même session RTP et partagent donc également la bande passante RTCP allouée aux envoyeurs.

Noter que dans les deux cas, multiplexage de session et de SSRC, les paquets BYE DOIVENT toujours être envoyés pour les deux flux comme spécifié dans RTP. En d'autres termes, il ne suffit pas d'envoyer des paquets BYE seulement pour le flux original.

 	6.2	Rapports RTCP du receveur
Dans le cas de multiplexage de session, le receveur va envoyer des blocs de rapport pour le flux original et le flux de retransmission dans des paquets séparés de rapport de receveur (RR, Receiver Report) appartenant à des sessions RTP séparées. Les paquets RR qui rapportent sur le flux original sont envoyés dans la session RTP originale tandis que les paquets RR rapportant sur le flux de retransmission sont envoyés dans la session de retransmission. La bande passante RTCP pour ces deux sessions peut être choisie indépendamment (par exemple, par des modificateurs de bande passante RTCP [RFC3556]).

Dans le cas de multiplexage de SSRC, le receveur envoie des blocs de rapport pour le flux original et le flux de retransmission dans le même paquet RR car il y a une seule session.

 	6.3	Demandes de retransmission
Le format de message de rétroaction NACK défini dans le profil AVPF DEVRAIT être utilisé par les receveurs pour envoyer les demandes de retransmission. Le choix d'un receveur de demander ou non un paquet est une question de mise en œuvre. Une mise en œuvre réelle de receveur devrait tenir compte de facteurs comme le délai d'application tolérable, l'environnement du réseau, et le type du support.

Le receveur devrait généralement affirmer si le paquet retransmis va encore être utile au moment de sa réception. L'horodatage du paquet manquant peut être estimé d'après l'horodatage des paquets précédant et/ou suivant le trou de numéros de séquence causé par le paquet manquant dans le flux original. Dans la plupart des cas, une forme d'estimation linéaire de l'horodatage suffit.

De plus, un receveur devrait calculer une estimation du délai d'aller-retour (RTT, round-trip time) à l'envoyeur. Cela peut être fait, par exemple, en mesurant le délai de retransmission pour recevoir un paquet de retransmission après l'envoi d'un NACK pour ce paquet. Cette estimation peut aussi être obtenue d'observations du passé, du délai d'aller-retour de rapport RTCP si disponible, ou de tout autre moyen. Un mécanisme standard pour le receveur pour estimer le RTT est spécifié dans "Rapports étendus du protocole de contrôle de RTP (RTCP XR)" [RFC3611].

Le receveur ne devrait pas envoyer de demande de retransmission aussitôt qu'il détecte un numéro de séquence manquant mais devrait ajouter un délai supplémentaire pour compenser le réarrangement de paquet. Ce délai supplémentaire peut, par exemple, être fondé sur des observations passées du réarrangement de paquet subi. On devrait noter que, dans les environnements où le réarrangement de paquet est rare ou n'a pas lieu, par exemple, si la couche de liaison des données sous-jacente permet une livraison ordonnée, le délai peut être extrêmement faible ou même prendre la valeur de zéro. Dans ces cas, un algorithme appropriée de "délai de réarrangement" ne peut pas réellement être fondé sur un temporisateur, mais fondé sur le paquet. Par exemple, si un nombre n de paquets sont reçus après la détection d'un trou, on peut alors supposer que le paquet est vraiment perdu plutôt que déclassé. Il peut se révéler beaucoup plus facile de le coder sur certaines plates-formes comme une mémoire tampon de paquets FIFO à très court délai plutôt que le mécanisme fondé sur le temporisateur.

Pour augmenter la robustesse à la perte d'un NACK ou d'un paquet de retransmission, un receveur peut envoyer un nouveau NACK pour le même paquet. Ceci est appelé une retransmission multiple. Avant d'envoyer un nouveau NACK pour un paquet manquant, le receveur devrait s'appuyer sur un temporisateur pour être raisonnablement sûr que la précédente tentative de retransmission a échoué afin d'éviter des retransmissions inutiles. La valeur du temporisateur devra se fonder sur le délai d'aller-retour observé. Une valeur statique ou adaptative PEUT être utilisée. Par exemple, un temporisateur adaptatif pourrait changer sa valeur à chaque nouvelle demande pour le même paquet. Le présent document ne fournit aucune ligne directrice sur la façon dont cette valeur adaptative devrait être calculée parce qu'aucune expérience n'a été faite pour le découvrir.

Les NACK DOIVENT être envoyés seulement pour le flux RTP d'origine. Autrement, si un receveur veut effectuer plusieurs retransmissions en envoyant un NACK dans le flux de retransmission, il ne va pas être capable de savoir le numéro de séquence original et une estimation de l'horodatage du paquet qu'il demande.

L'Appendice A donne des lignes directrices sur le contrôle du nombre de retransmissions.

 	6.4	Règles de temps
Le message de rétroaction NACK peut être envoyé dans un paquet RTCP composé régulier complet ou dans un paquet RTCP précoce, conformément au profil AVPF [RFC4585]. Envoyer un NACK dans un paquet précoce permet de réagir plus rapidement à une perte de paquet. Cependant, dans ce cas, si une nouvelle perte de paquet se produit juste après l'envoi du paquet RTCP précoce, le receveur va alors devoir attendre le prochain paquet RTCP composé régulier après le paquet précoce. Envoyer des NACK seulement dans les composés RTCP réguliers diminue le délai maximum entre la détection d'une perte de paquet original et le moment où on sera capable d'envoyer un NACK pour ce paquet. Les mises en œuvre devraient considérer les possibles implications de ce fait pour l'application utilisée.

De plus, les receveurs peuvent utiliser l'intervalle minimum entre paquets composés RTCP réguliers. Cet intervalle peut être utilisé pour maintenir à un minimum le rapport régulier de receveur, tout en permettant quand même aux receveurs d'envoyer des paquets RTCP précoces durant les périodes qui exigent des rétroactions plus fréquentes, par exemple, les moments de plus fort taux de perte de paquet. Noter que bien que les paquets RTCP puissent être supprimés parce qu'ils ne contiennent pas de NACK, la même bande passante RTCP que si ils étaient envoyés doit être disponible. Voir dans AVPF [RFC4585] les détails sur l'utilisation de l'intervalle minimum.

 	7.	Contrôle d'encombrement

La retransmission RTP fait peser un risque d'augmentation de l'encombrement du réseau. Dans un environnement au mieux, la perte de paquet est causée par l'encombrement. Réagir à la perte par la retransmission d’anciennes données sans diminuer le débit du flux original augmenterait encore l'encombrement. Les mises en œuvre DEVRAIENT suivre les recommandations suivantes afin d'utiliser la retransmission.

Le profil RTP sous lequel le schéma de retransmission est utilisé définit le mécanisme approprié de contrôle d'encombrement dans les différents environnements. Suivant les règles de ce profil, une application RTP peut déterminer son débit binaire acceptable et le débit de paquets afin d'être équitable avec les autres flux TCP ou RTP.

Si une application RTP utilise la retransmission, le débit de paquet et le débit binaire acceptables incluent les données d'origine et retransmises. Cela garantit qu'une application qui utilise la retransmission réalise la même équité que celle qui ne le fait pas. Cette règle va se traduire en pratique par les actions suivantes :

Si le service amélioré est utilisé, on devrait s'assurer que le débit binaire et le débit de paquet total n'excède pas celui du service demandé. On devrait de plus surveiller que les services demandés sont réellement livrés. Dans un environnement au mieux, l'envoyeur NE DEVRAIT PAS envoyer de paquets de retransmission sans réduire le débit de paquet et le débit binaire du flux original (par exemple, en codant les données à un taux inférieur).

De plus, l'envoyeur PEUT retransmettre sélectivement seulement les paquets qu'il estime importants et ignorer les messages NACK pour les autres paquets afin de limiter le débit binaire.

Ces mécanismes de contrôle d'encombrement devraient garder le taux de perte de paquet dans des paramètres acceptables. Dans le contexte du contrôle d'encombrement, la perte de paquet est considérée acceptable si un flux TCP à travers le même chemin de réseau et rencontrant les mêmes conditions de réseau réaliserait, sur une échelle de temps raisonnable, un débit moyen qui ne serait pas inférieur à celui que le flux RTP réalise. Si l'encombrement ne reste pas sous contrôle, la retransmission NE DEVRAIT PAS être utilisée.

Les retransmissions PEUVENT quand même être envoyées dans certains cas, par exemple, dans des liaisons sans fil où les pertes de paquet ne sont pas causées par l'encombrement, si le serveur (ou le client qui fait la demande de retransmission) estime qu'un paquet ou trame particulier est important pour continuer l'exécution, ou si un message RTSP PAUSE a été produit pour permettre le remplissage de la mémoire tampon (le RTSP PAUSE n’affecte pas l'envoi des retransmissions).

Finalement, il peut de plus être nécessaire d'adapter le taux de transmission (ou le nombre de couches souscrites pour une session de diffusion groupée en couches) ou pour arranger le départ du receveur de la session.

 	8.	Enregistrement de type MIME de format de charge utile de retransmission
 	8.1	Introduction
Le nom et les paramètres de sous-type MIME suivants sont introduits dans le présent document : "rtx", "rtx-time", et "apt".

Le lien au numéro de type de charge utile utilisé pour le flux de retransmission est indiqué par un attribut rtpmap. Le nom de sous-type MIME utilisé dans le lien est "rtx".

Le paramètre "apt" (type de charge utile associé) DOIT être utilisé pour transposer le type de charge utile de retransmission au type de charge utile de flux original associé. Si plusieurs types de charge utile originale sont utilisés, alors plusieurs paramètres "apt" DOIVENT être inclus pour transposer chaque type de charge utile originale en un type de charge utile de retransmission différent.

Un paramètre FACULTATIF spécifique du format de charge utile, "rtx-time", indique la durée maximum pendant laquelle un envoyeur va garder un paquet RTP original dans sa mémoire tampon disponible pour retransmission. Ce délai commence à la première transmission du paquet.

La syntaxe est la suivante :

a=fmtp:<numéro> apt=<apt-value>;rtx-time=<rtx-time-val>

où

<numéro> : indique le numéro dynamique de type de charge utile alloué au format de charge utile de retransmission dans un attribut rtpmap.

<apt-value> : est la valeur du type de charge utile de flux original auquel ce type de charge utile de flux de retransmission est associé.

<rtx-time-val> : spécifie le temps en millisecondes (mesuré depuis le moment où un paquet a été envoyé) pendant lequel un envoyeur garde dans sa mémoire tampon un paquet RTP disponible pour retransmission. L'absence du paramètre rtx-time pour un flux de retransmission signifie que l'heure maximum de retransmission n'est pas définie, mais PEUT être négociée par d'autres moyens.

 	8.2	Enregistrement de audio/rtx
Type MIME : audio
Sous type MIME : rtx
Paramètres exigés :
rate : le débit d'horloge d'horodatage RTP est égal au débit d'horloge d'horodatage RTP du support qui est retransmis.
apt : type de charge utile associé. La valeur de ce paramètre est le type de charge utile du flux original associé.
Paramètres facultatifs :
rtx-time : indique en millisecondes (mesuré depuis l'heure d'envoi d'un paquet) le temps pendant lequel l'envoyeur garde un paquet RTP disponible pour retransmission dans son antémémoire.
Considérations de codage : ce type n'est défini que pour le transfert via RTP.
Considérations de sécurité : voir la Section 12 de la RFC 4588
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 4588
Applications qui utilisent ce type de support : applications multimédia de flux directs
Informations supplémentaires : aucune
Adresse de messagerie de la personne à contacter pour des informations complémentaires : 
jose.rey@eu.panasonic.com
davidleon123@yahoo.com
avt@ietf.org
Usage prévu : COMMUN
Auteurs : Jose Rey  , David Leon
Contrôleur des changements : groupe de travail AVT de l'IETF sur délégation de l'IESG.

 	8.3	Enregistrement de video/rtx
Type MIME : video
Sous type MIME : rtx
Paramètres exigés :
rate : le débit d'horloge d'horodatage RTP est égal au débit d'horloge d'horodatage RTP du support retransmis.
apt : type de charge utile associé. La valeur de ce paramètre est le type de charge utile du flux original associé.
Paramètres facultatifs :
rtx-time : indique le temps en millisecondes (mesuré d'après l'heure d'envoi du paquet) pendant lequel l'envoyeur garde dans son antémémoire un paquet RTP disponible pour retransmission.
Considérations de codage : ce type n'est défini que pour le transfert via RTP.
Considérations de sécurité : voir la Section 12 de la RFC 4588
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 4588
Applications qui utilisent ce type de support : applications multimédia de flux directs
Informations supplémentaires : aucune
Adresse de messagerie de la personne à contacter pour des informations complémentaires ::
jose.rey@eu.panasonic.com
davidleon123@yahoo.com
avt@ietf.org
Usage prévu : COMMUN
Auteurs : Jose Rey,  David Leon
Contrôleur des changements : groupe de travail AVT de l'IETF sur délégation de l'IESG.

 	8.4	Enregistrement de text/rtx
Type MIME : text
Sous type MIME : rtx
Paramètres exigés :
rate : le débit d'horloge d'horodatage RTP est égal au débit d'horloge d'horodatage RTP du support retransmis.
apt : type de charge utile associée. La valeur de ce paramètre est le type de charge utile du flux original associé.
Paramètres facultatifs :
rtx-time : indique le temps en millisecondes (mesuré d'après l'heure d'envoi du paquet) pendant lequel l'envoyeur garde dans son antémémoire un paquet RTP disponible pour retransmission.
Considérations de codage : ce type n'est défini que pour le transfert via RTP.
Considérations de sécurité : voir la Section 12 de la RFC 4588
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 4588
Applications qui utilisent ce type de support : applications multimédia de flux directs
Informations supplémentaires : aucune
Adresse de messagerie de la personne à contacter pour des informations complémentaires ::
jose.rey@eu.panasonic.com
davidleon123@yahoo.com
avt@ietf.org
Usage prévu : COMMUN
Auteurs : Jose Rey,  David Leon
Contrôleur des changements : groupe de travail AVT de l'IETF sur délégation de l'IESG.

 	8.5	Enregistrement de application/rtx
Type MIME : application
Sous type MIME : rtx
Paramètres exigés :
rate : le débit d'horloge d'horodatage RTP est égal au débit d'horloge d'horodatage RTP du support retransmis.
apt : type de charge utile associée. La valeur de ce paramètre est le type de charge utile du flux original associé.
Paramètres facultatifs :
rtx-time : indique le temps en millisecondes (mesuré d'après l'heure d'envoi du paquet) pendant lequel l'envoyeur garde dans son antémémoire un paquet RTP disponible pour retransmission.
Considérations de codage : ce type n'est défini que pour le transfert via RTP.
Considérations de sécurité : voir la Section 12 de la RFC 4588.
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 4588
Applications qui utilisent ce type de support : applications multimédia de flux directs
Informations supplémentaires : aucune
Adresse de messagerie de la personne à contacter pour des informations complémentaires ::
jose.rey@eu.panasonic.com
davidleon123@yahoo.com
avt@ietf.org
Usage prévu : COMMUN
Auteurs : Jose Rey, David Leon
Contrôleur des changements : groupe de travail AVT de l'IETF sur délégation de l'IESG.

 	8.6	Transposition en SDP
Les informations portées dans la spécification de type de support MIME ont une transposition spécifique en les champs de SDP [RFC2327], qui est couramment utilisé pour décrire les sessions RTP. Quand SDP est utilisé pour spécifier des retransmissions pour un flux RTP, la transposition est faire comme suit :
-	 Les types MIME ("video"), ("audio"), ("text"), et ("application") vont dans la ligne SDP "m=" comme nom de support.
-	Le sous-type MIME ("rtx") va dans la ligne SDP "a=rtpmap" comme nom de codage. Le débit d'horloge RTP dans "a=rtpmap" DOIT être celui du type de charge utile de retransmission. Voir les détails à la Section 4.
-	Les paramètres spécifiques du profil AVPF "ack" et "nack" vont dans la ligne SDP "a=rtcp-fb". Plusieurs lignes SDP "a=rtcp-fb" sont utilisées pour plusieurs types de rétroaction. Voir les détails dans le profil AVPF [RFC4585].
-	Les paramètres spécifiques du format de charge utile de retransmission "apt" et "rtx-time" vont dans la ligne SDP "a=fmtp" comme liste de paires paramètre=valeur séparées par des points-virgules.
-	Tous les paramètres restants vont dans l'attribut SDP "a=fmtp" en les copiant directement de la chaîne de type de support MIME comme liste de paires paramètre=valeur séparées par des points-virgules.

Dans les paragraphes qui suivent, des exemples de descriptions SDP sont présentées. Dans certains de ces exemples, les lignes longues vont à la ligne pour respecter les contraintes de largeur du présent document ; la barre oblique inverse ("\") à la fin d'une ligne et le retour chariot qui suit devraient être ignorés.

 	8.7	Description SDP avec multiplexage de session
Dans le cas de multiplexage de session, la description SDP contient une ligne "m" de spécification par session RTP. Le SDP DOIT fournir le groupage des lignes "m" des sessions originale et de retransmission associées, en utilisant la sémantique d'identification de flux (FID, Flow Identification) définie dans la [RFC3388].

L'exemple suivant spécifie deux sessions originales, AMR et MPEG-4, sur les accès 49170 et 49174 et leurs flux de retransmission correspondants sur les accès 49172 et 49176, respectivement :

v=0
o=mascha 2980675221 2980675778 IN IP4 host.exemple.net
c=IN IP4 192.0.2.0
a=group:FID 1 2
a=group:FID 3 4
m=audio 49170 RTP/AVPF 96
a=rtpmap:96 AMR/8000
a=fmtp:96 octet-align=1
a=rtcp-fb:96 nack
a=mid:1
m=audio 49172 RTP/AVPF 97
a=rtpmap:97 rtx/8000
a=fmtp:97 apt=96;rtx-time=3000
a=mid:2
m=video 49174 RTP/AVPF 98
a=rtpmap:98 MP4V-ES/90000
a=rtcp-fb:98 nack
a=fmtp:98 profile-level-id=8;config=01010000012000884006682C2090A21F
a=mid:3
m=video 49176 RTP/AVPF 99
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98;rtx-time=3000
a=mid:4

Un cas particulier de description SDP est une description qui contient seulement une ligne "m" de session d'origine et une ligne "m" de session de retransmission, le groupage est alors évident et la sémantique de FID PEUT être omise dans ce seul cas particulier.

Ceci est illustré dans l'exemple suivant, qui est une description SDP pour un seul flux original MPEG-4 et sa session de retransmission correspondante :

v=0
o=mascha 2980675221 2980675778 IN IP4 host.exemple.net
c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F
m=video 49172 RTP/AVPF 97
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000

 	8.8	Description SDP avec multiplexage SSRC
Voici un exemple d'une description SDP pour une session RTP vidéo utilisant le multiplexage de SSRC avec des paramètres similaires à ceux de l'exemple de la session seule ci-dessus :

v=0
o=mascha 2980675221 2980675778 IN IP4 host.exemple.net
c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96 97
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000

 	9.	Considérations sur RTSP

Le protocole de flux directs en temps réel (RTSP, Real Time Streaming Protocol) [RFC2326], est un protocole de niveau application pour le contrôle sur la livraison de données avec des propriétés de temps réel. Cette section examine les problèmes posés par le contrôle des sessions RTP qui utilisent les retransmissions.

 	9.1	Contrôle RTSP avec multiplexage de SSRC
Dans le cas de multiplexage de SSRC, la ligne "m" inclut les deux types de charge utile originale et de retransmission et a un seul attribut RTSP "control". Le receveur utilise la ligne "m" pour demander l'établissement (SETUP) et la suppression (TEARDOWN) de la session de supports entière. Le profil RTP contenu dans l'en-tête Transport DOIT être le profil AVPF ou un autre profil convenable permettant un retour étendu. Si la valeur de SSRC est incluse dans l'en-tête Transport de la réponse SETUP, elle DOIT être celle du flux original.

Afin de contrôler l'envoi du flux de supports de la session originale, le receveur envoie les demandes usuelles PLAY et PAUSE à l'envoyeur pour la session. L'en-tête RTP-info qui est utilisé pour régler les paramètres spécifiques de RTP dans la réponse PLAY DOIT être réglé en accord avec les informations RTP du flux original.

Quand le receveur commence à recevoir le flux original, il peut alors demander la retransmission par des NACK RTCP sans autre signalisation RTSP.

 	9.2	Contrôle RTSP avec multiplexage de session
Dans le cas du multiplexage de session, chaque ligne "m" SDP a un attribut RTSP "control". Donc, quand la retransmission est utilisée, les deux sessions d'origine et de retransmission ont leurs propres attributs "control". Le receveur peut associer la session d'origine et la session de retransmission par la sémantique de FID comme spécifié à la Section 8.

Le flux original et flux de retransmission sont établis et supprimés séparément au moyen de leur attribut de support "control" respectif. Le profil RTP contenu dans l'en-tête Transport DOIT être le profil AVPF ou un autre profil convenable permettant des retours étendus pour les deux sessions originale et de retransmission.

La présentation RTSP DEVRAIT prendre en charge le contrôle agrégé et DEVRAIT contenir un URL RTSP de niveau session. Le receveur DEVRAIT utiliser le contrôle agrégé pour une session d'origine et sa session de retransmission associée. Autrement, il y aurait besoin de deux valeurs différentes d'identifiant de session, c'est-à-dire, des valeurs différentes pour la session originale et la session de retransmission, et l'envoyeur ne saurait pas comment les associer.

L'attribut de niveau session "control" est alors utilisé comme d'habitude pour contrôler l'exécution du flux original. Quand le receveur commence à recevoir le flux original, il peut alors demander des retransmissions par RTCP sans signalisation RTSP supplémentaire.

 	9.3	Contrôle RTSP du flux de retransmission
À cause de la nature des retransmissions, l'envoi des paquets de retransmission NE DEVRAIT PAS être contrôlé au moyen des demandes RTSP PLAY et PAUSE. Les demandes PLAY et PAUSE NE DEVRAIENT PAS affecter le flux de retransmission. Les paquets de retransmission sont envoyés à la demande du receveur dans le flux RTCP original, sans considération de l'état.

 	9.4	Contrôle d'antémémoire
Les flux de retransmission NE DEVRAIENT PAS être mis en antémémoire.

Dans le cas de multiplexage de session, l'en-tête "Cache-Control" DEVRAIT être réglé à "no-cache" pour le flux de retransmission.

Dans le cas de multiplexage de SSRC, RTSP ne peut pas spécifier une mise en antémémoire indépendante pour le flux de retransmission, parce que il y a une seule ligne "m" dans SDP. Donc, la mise en œuvre devrait prendre ce fait en compte quand elle décide de mettre ou non en antémémoire une session de multiplexage de SSRC.

 	10.	Exemples de mise en œuvre

Le présent document ne rend obligatoires que les comportements d'envoyeur et receveur qui sont nécessaires pour l'interopérabilité. De plus, certains algorithmes, comme la gestion du contrôle de débit ou de mémoire tampon quand ils sont ciblés sur des environnements spécifiques, peuvent améliorer l'efficacité de la retransmission.

Cette Section donne une vue d'ensemble des différentes options de mise en œuvre permises dans cette spécification.

Le premier exemple décrit une mise en œuvre minimale de receveur. Avec cette mise en œuvre, il est possible de retransmettre les paquets RTP perdus, de détecter efficacement la perte des retransmissions, et d'effectuer plusieurs retransmissions, si nécessaire. La plus grande part du traitement nécessaire est faite au serveur.

Le second exemple montre comment les retransmissions peuvent être utilisées dans des groupes (petits) de diffusion groupée en conjonction avec le codage en couches. Il illustre que les retransmissions et le codage en couches peuvent être des techniques complémentaires.

 	10.1	Exemple de mise en œuvre minimale de receveur
Ce paragraphe donne un exemple d'une mise en œuvre qui prend en charge plusieurs retransmissions. L'envoyeur transmet les données d'origine dans les paquets RTP en utilisant le format de charge utile RTP de vidéo MPEG-4. On suppose que les messages de rétroaction NACK sont utilisés, conformément à la [RFC4585]. Un exemple de description SDP avec multiplexage de SSRC est donné ci-dessous :

v=0
o=mascha 2980675221 2980675778 IN IP4 host.exemple.net
c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96 97
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000

Le paramètre spécifique du format "rtx-time" indique que le serveur va mettre les paquets envoyés dans une mémoire tampon de retransmission pendant 3,0 secondes, après quoi les paquets seront supprimés de la mémoire tampon de retransmission et ne seront plus renvoyés.

Dans cet exemple de mise en œuvre, le traitement exigé du receveur RTP pour traiter la retransmission est gardé au minimum. Le receveur détecte la perte de paquet d'après les trous observés dans les numéros de séquence reçus. Il signale les paquets perdus à l'envoyeur par des NACK comme défini dans le profil AVPF [RFC4585]. Le receveur devrait prendre en compte la longueur de la mémoire tampon de retransmission signalée de l'envoyeur afin de dimensionner sa propre mémoire tampon de réception. Il devrait aussi déduire de la longueur de mémoire tampon le nombre maximum de fois que la retransmission d'un paquet peut être demandée.

L'envoyeur devrait retransmettre les paquets de façon sélective ; c'est-à-dire, il devrait choisir si il retransmet un paquet demandé selon l'importance du paquet, la qualité de service observée, et l'état d'encombrement de la connexion réseau avec le receveur. Évidemment, le traitement de l'envoyeur augmente avec le nombre de receveurs car des informations d'état et une charge de traitement doivent être allouées à chaque receveur.

 	10.2	Retransmission de supports codés en couches en diffusion groupée
Ce paragraphe montre comment combiner les retransmissions avec le codage en couches dans les sessions en diffusion groupée. Noter que le cadre de retransmission n'est offert que pour les petites applications de diffusion groupée. Se reporter à la [RFC2887] pour une discussion des problèmes d'explosion de NACK, d'encombrement sévère causé par le trafic de rétroaction, dans les applications de grands groupes de diffusion groupée fiable.

Les paquets de différente importance sont envoyés dans des sessions RTP différentes. Les flux de retransmission correspondant aux différentes couches peuvent eux-mêmes être vus comme des couches de retransmission différentes. L'importance relative des différents flux de retransmission devrait refléter l'importance relative des différents flux originaux.

En diffusion groupée, le multiplexage de SSRC des flux originaux et de retransmission n'est pas permis conformément au paragraphe 5.3 du présent document. Pour cette raison, le ou les flux de retransmission DOIVENT être envoyés dans des sessions RTP différentes en utilisant le multiplexage de session.

Un exemple de description SDP de retransmissions de diffusion groupée pour un support codé en couches est donné ici :

m=video 8000 RTP/AVPF 98
c=IN IP4 224.2.1.0/127/3
a=rtpmap:98 MP4V-ES/90000
a=rtcp-fb:98 nack
m=video 8000 RTP/AVPF 99
c=IN IP4 224.2.1.3/127/3
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98;rtx-time=3000

Le serveur et le receveur peuvent mettre en œuvre les méthodes de retransmission illustrées dans les exemples précédents. De plus, ils peuvent choisir de demander et retransmettre un paquet perdu selon la couche à laquelle il appartient.

 	11.	Considérations relatives à l'IANA

Un nouveau nom de sous-type MIME, "rtx", a été enregistré pour quatre différents types de supports, comme suit : "video", "audio", "text" et "application". Un paramètre EXIGÉ supplémentaire, "apt", et un paramètre FACULTATIF "rtx-time", sont définis. Voir les détails à la Section 8.

 	12.	Considérations sur la sécurité

Les paquets RTP qui utilisent le format de charge utile défini dans la présente spécification sont soumis aux considérations générales de sécurité discutées dans RTP [RFC3550], Section 9.

Dans les scénarios courants de flux en direct, l'authentification du message, l'intégrité des données, la protection contre la répétition, et la confidentialité sont désirées.

L'absence d'authentification peut permettre des attaques par interposition et en répétition, qui peuvent être très dommageables pour la retransmission RTP. Par exemple, des paquets RTCP altérés peuvent déclencher des retransmissions inappropriées qui réduisent effectivement la part du débit binaire réel allouée aux flux de données d'origine  ; des paquets de retransmission RTP altérés pourraient causer la défaillance du décodeur du client, et des demandes de retransmission altérées peuvent invalider le mécanisme d'association de SSRC décrit à la Section 5 du présent document. Par ailleurs, des paquets répétés pourraient conduire à de faux réarrangements et de fausses mesures de RTT (nécessaires pour la stratégie de demande de retransmission) et peuvent causer le débordement de la mémoire tampon du receveur.

De plus, afin d'assurer la confidentialité des données, les données de charge utile d'origine doivent être chiffrées. Il n'est en fait pas nécessaire de chiffrer les deux octets de l'en-tête de charge utile de retransmission car ils ne donnent aucune indication sur le contenu des données.

De plus, il est RECOMMANDÉ que les mécanismes de chiffrement utilisés pour ce format de charge utile fournissent une protection contre les attaques de texte en clair connu. RTP recommande que l'horodatage initial RTP DEVRAIT être rendu aléatoire pour sécuriser le flux contre les attaques de texte en clair connu. Le présent format de charge utile ne suit pas cette recommandation car l'horodatage initial va être l'horodatage du support du premier paquet retransmis. Cependant, comme l'horodatage initial du flux original est lui-même aléatoire, si le flux original est chiffré, l'horodatage du premier paquet retransmis va aussi être aléatoire pour un attaquant. Donc, la confidentialité ne va pas être compromise.

Si le chiffrement est utilisé pour fournir des services de sécurité sur le flux original, alors les mêmes services, avec une force de chiffrement équivalente, DOIVENT être fournis sur le flux de retransmission. L'utilisation de la même clé pour le flux retransmis et le flux original peut conduire à des problèmes de sécurité, par exemple, de bourrage répété. Voir au paragraphe 9.1 du protocole de transport en temps réel (SRTP) [RFC3711] la discussion des implications des bourrages répétés et comment les éviter.

Au moment de la rédaction du présent document, SRTP ne fournit pas tous les services de sécurité mentionnés. Il y a, au moins, deux raisons à cela : 1) l'occurrence de bourrages répétés et 2) le fait que ce format de charge utile fonctionne normalement sous le profil RTP/AVPF tandis que SRTP prend seulement en charge RTP/AVP. Une variante adaptée de SRTP devra résoudre ces problèmes à l'avenir.

Les considérations de contrôle d'encombrement avec l'utilisation de la retransmission sont traitées à la Section 7 du présent document.

 	13.	Remerciements

Nous tenons à exprimer notre gratitude à Carsten Burmeister pour sa participation au développement du présent document.  Nos remerciements aussi à Koichi Hata, Colin Perkins, Stephen Casner, Magnus Westerlund, Go Hori, et Rahul Agarwal pour leurs utiles commentaires.

 	14.	Références
 	14.1	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC2326]	H. Schulzrinne, A. Rao et R. Lanphier, "Protocole de flux directs en temps réel (RTSP)", avril 1998. (Remplacée par RFC7826)

[RFC2327]	M. Handley et V. Jacobson, "SDP : Protocole de description de session", avril 1998. (Obsolète; voir RFC4566)

[RFC3388]	G. Camarillo, G. Eriksson, J. Holler et H. Schulzrinne, "Groupage des lignes de support dans le protocole de description de session (SDP)", décembre 2002. (Remplacée par RFC5888)

[RFC3550]	H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : un protocole de transport pour les applications en temps réel", STD 64, juillet 2003. (MàJ par RFC7164, RFC7160, RFC8083, RFC8108, RFC8860)

[RFC3556]	S. Casner, "Modificateurs de bande passante du protocole de description de session (SDP) pour la bande passante du protocole de contrôle de RTP (RTCP)", juillet 2003. (P.S.)

[[RFC4585]	J. Ott et autres, "Profil RTP étendu pour rétroaction fondée sur le protocole de contrôle de transport en temps réel (RTCP) (RTP/AVPF)", juillet 2006. (P.S., MàJ par RFC8108)

 	14.2	Références pour information

[RFC2354]	C. Perkins et O. Hodson, "Options pour réparer un support de direct", juin 1998. (Information)

[RFC2887]	M. Handley et autres, "Espace de conception de diffusion groupée fiable pour transfert de données brutes", août 2000. (Info.)

[RFC3611]	T. Friedman, R. Caceres et A. Clark, éditeurs, "Rapports étendus du protocole de contrôle de RTP (RTCP XR)", novembre  2003. (P.S.)

[RFC3711]	M. Baugher et autres, "Protocole de transport sécurisé en temps réel (SRTP)", mars 2004. (P.S.)

[RFC4103]	G. Hellstrom, P. Jones, "Charge utile RTP pour conversation textuelle", juin 2005. (Remplace RFC2793) (P.S.)

 	Appendice A.	Comment contrôler le nombre de retransmissions par paquet

Découvrir le nombre de retransmissions (rtx) par paquet pour réaliser la meilleure transmission possible est une tâche difficile. Bien sûr, le minimum absolu devrait être une (1) ; autrement, on n'utilise pas ce format de charge utile. De plus, à la date de cette publication, les auteurs n'ont pas connaissance d'études sur le nombre de retransmissions par paquet qui devrait être utilisé pour les meilleures performances. Pour aider les mises en œuvre et les chercheurs sur ce point, cette section décrit une estimation du temps de mise en mémoire tampon requis pour réaliser un certain nombre de retransmissions. Une fois ce temps calculé, il peut être communiqué au client via le paramètre SDP "rtx-time", comme défini dans le présent document.

 	A.1	Scénarios et hypothèses
*	Scénario de flux directs avec limites de délai relâchées. Client et serveur sont dotés d'un espace de mémoire tampon indiqué par le paramètre "rtx-time" (temps de retransmission) dans SDP.
*	Profil RTP AVPF utilisé avec le schéma de retransmission de multiplexage de SSRC : 1 SSRC pour les paquets originaux, 1 pour les paquets de retransmission.
*	Part de bande passante RTCP par défaut pour les SR et RR, c'est-à-dire, SR+RR = 0,05. On a des envoyeurs (2) et des receveurs (1). Receveurs et envoyeurs obtiennent également 1/3 de la part de bande passante RTCP parce que la proportion d'envoyeurs est supérieure au 1/4 des membres de la session.
*	La taille moyenne avg-rtcp-size est approximée par 120 octets. C'est une moyenne arrondie de deux SR, un pour chaque SSRC, contenant 40/8/28/32 octets pour IPv6/UDP/SR/SDES avec CNAME, faisant donc 105 octets chacun ; et un RR avec 40/8/64/32 octets pour IPv6/UDP/2*RR/SDES, faisant 157 octets. Comme les envoyeurs et les receveurs partagent également la bande passante RTCP, avg-rtcp-size = (157+105+105)/3 = 117,3 ≈ 120 octets. La caractéristique importante de cette valeur est qu'elle est quelque chose de plus de 100 octets, qui semble être un chiffre représentatif pour les configurations normales.
*	Le profil utilisé est AVPF [RFC4585] et les NACK génériques sont utilisés pour demander les retransmissions. Cela ajoute 16 octets de frais généraux pour 1 NACK et 4 octets de plus pour chaque champ supplémentaire d'informations de contrôle de rétroaction de NACK.
*	On suppose un scénario de plus mauvais cas dans lequel chaque paquet épuise son nombre correspondant de retransmissions disponibles, N, avant qu'il soit reçu. Cela signifie que si un paquet est demandé pour retransmission un maximum de deux fois, le bloc correspondant de rapport générique de NACK demandant ce paquet particulier est envoyé dans deux RTCP composés consécutifs ; de même, si il est demandé pour retransmission 10 fois, le NACK générique est alors envoyé 10 fois. Cette hypothèse fait que la taille de paquet RTCP est approximativement constante après N*RTCP intervalles (en secondes), à savoir que avg-rtcp-size = 120 + (part de bande passante RTCP de receveur)*(12 + 4*N). Dans notre cas, la part de bande passante RTCP de receveur est 1/3 ; donc, avg-rtcp-size = 124 + 4*N/3.
*	Deux paramètres de délai sont difficiles à approximer et peuvent dépendre de la mise en œuvre. Donc, on les donne ici explicitement sans leur allouer de valeur particulière : une est le temps de détection de perte de paquet (T2), et l'autre est le temps de traitement de rétroaction et de mise en file d'attente pour les retransmissions (T5). Les mises en œuvre devront allouer des valeurs appropriées à ces deux paramètres.

Graphiquement, on a :

        Envoyeur
       +-+---------------------------------^-----\-----------------
        \ \                               /       \
         \ \                             |         |
   SN=0   \ \ SN=1                       /         \  RTX(SN=0)
           \ \                          /           \
            X \                        /             \
               `.                     /               \
                 \                   /                 \
                  \                 |                   |
                   \                /                   \    ......
                    \              /                     \
       -------------V----D--------/-----------------------V--------
              T1      T2    T3         T4    T5     T1   ........
        Receveur

Légende :
DL (downlink, liaison descendante) (client->serveur)
UL (uplink, liaison montante) (serveur->client)
L'unité de temps est la seconde, s.
L'unité de débit binaire est le bit par seconde, bit/s.

Temps de transmission DL : T1 = délai physique DL + délai tx DL(=avg-pkt-size/débit binaire DL) + délai de gigue inter arrivées

Temps de détection de perte de paquet : T2 = pkt-loss-detect-time

Temps pour rapporter la perte de paquet : T3 = time-to-next-rtcp-report

Temps de transmission UL : T4 = délai physique UL + délai de transmission UL + délai de gigue inter arrivées

Temps de traitement de retransmissions : T5 = temps de traitement de rétroactions + temps de mise en file d'attente de retransmissions

 	A.2	But
Pour trouver une estimation du temps de mise en antémémoire, T(), qu'un serveur de flux directs devra utiliser afin de permettre un nombre de retransmissions donné pour chaque paquet, N. Ce temps est approximativement égal chez le serveur et chez le client, si on considère que le client commence à mettre en antémémoire T1 secondes plus tard.

 	A.3	Solution
D'abord, on trouve la valeur de l'estimation pour 1 retransmission,T(1)=T : T = T1 + T2 + T3 + T4 + T5

Car T1 + T4 ≈ RTT,

T = RTT + T2 + T3 + T5

Le pire cas pour T3 va être qu'on suppose que le rapport doit attendre un intervalle RTCP complet et que le facteur maximum d'aléation de 1,5 est appliqué. Donc, après application de la compensation suivante pour éviter des salves de trafic (voir l'Appendice A.7 de RTP [RFC3550]) on a T3 = 1,5/1,21828*Intervalle-RTCP. Donc,

T = RTT + 1,2312*Intervalle-RTCP + T2 + T5

Par ailleurs, Intervalle-RTCP = avg-rtcp-size*8*(envoyeurs + receveurs)/(RR+RS). Dans ce scénario, envoyeur + receveurs = 3 ; RR+RS est la part de bande passante de rapport de receveur plus de rapport d'envoyeur, dans ce cas, égal à 5 % par défaut de la bande passante de session, bw. On suppose une taille moyenne de paquet RTCP, avg-rtcp-size = 120  octets. Donc : T = RTT + 1,2312*avg-rtcp-size*8*3/(0,05*bw) + T2 + T5 pour 1 retransmission.

Pour permettre N retransmissions, le temps de mise en antémémoire disponible dans un serveur ou client de flux directs est approximativement : T(N) = N*(RTT+1,2312*avg-rtcp-size*8*3/(0,05*bw) + T2 + T5)

où, conformément à ce qu'on a ci-dessus ,

avg-rtcp-size = 120 + (part de bande passante de receveur RTCP)*(12 + 4*N)
                      = 120 + (1/3)*(12 + 4*N)
                      = 124 + 4*N/3.

 	A.4	Nombres
Si on ignore l'effet de T2 et T5, c'est-à-dire, si on suppose que toutes les pertes sont détectées immédiatement et qu'il n'y a pas de délai supplémentaire dû au traitement des rétroactions ou à la mise en file d'attente de retransmission, on a les temps de mise en antémémoire suivants pour les différentes valeurs de N :

RTCP avec plusieurs NACK génériques ; taille de paquet variable = 124 + 4*N/3 octets

Bande passante RTP	RTT	Valeur de N
	1	2	5	7	10
     64  000	0,05	1,21	2,44	6,28	8,97	13,18
    128  000	0,05	0,63	1,27	3,27	4,66	  6,84
    256  000	0,05	0,34	0,68	1,76	2,50	  3,67
    512  000	0,05	0,19	0,39	1,00	1,43	  2,09
  1  024  000	0,05	0,12	0,25	0,63	0,89	  1,29
  5  000  000	0,05	0,06	0,13	0,33	0,46	  0,66
10  000  000	0,05	0,06	0,11	0,29	0,41	  0,58

     64  000	0,2	1,36	2,74	7,03	10,02	14,68
    128  000	0,2	0,78	1,57	4,02	  5,71	  8,34
    256  000	0,2	0,49	0,98	2,51	  3,55	  5,17
    512  000	0,2	0,34	0,69	1,75	  2,48	  3,59
  1  024  000	0,2	0,27	0,55	1,38	  1,94	  2,79
  5  000  000	0,2	0,21	0,43	1,08	  1,51	  2,16
10  000  000	0,2	0,21	0,41	1,04	  1,46	  2,08

      64  000	1	2,16	4,34	11,03	15,62	22,68
    128  000	1	1,58	3,17	  8,02	11,31	16,34
     256  000	1	1,29	2,58	  6,51	  9,15	13,17
     512  000	1	1,14	2,29	  5,75	  8,08	11,59
  1  024  000	1	1,07	2,15	  5,38	  7,54	10,79
  5  000  000	1	1,01	2,03	  5,08	  7,11	10,16
10  000  000	1	1,01	2,01	  5,04	  7,06	10,08

Pour quantifier l'erreur de ne pas prendre en compte les NACK génériques, on peut prendre les mêmes nombres, mais ignorer la contribution de NACK générique, avg-rtcp-size ≈ 120 octets. Comme on le voit ci-dessous, il peut en résulter une erreur d'estimation d'antémémoire de 1 à 1,5 seconde (5 à 10 %) pour les plus basses valeurs de bande passante et un nombre de retransmissions supérieur. Cet effet est faible dans ce cas. Néanmoins, il devrait être évalué avec soin pour le scénario particulier ; c'est pourquoi la formule l'inclut.

RTCP sans NACK générique, taille de paquet fixe ≈ 120 octets

Bande passante RTP	RTT	Valeur de N
	1	2	5	7	10
     64000	0,05	1,16	2,32	5,79	8,11	11,58
   128000	0,05	0,60	1,21	3,02	4,23	  6,04
   256000	0,05	0,33	0,65	1,64	2,29	  3,27
   512000	0,05	0,19	0,38	0,94	1,32	  1,89
  1024000	0,05	0,12	0,24	0,60	0,83	  1,19
  5000000	0,05	0,06	0,13	0,32	0,45	  0,64
10000000	0,05	0,06	0,11	0,29	0,40	  0,57

     64000	0,2	1,31	2,62	6,54	9,16	13,08
    128000	0,2	0,75	1,51	3,77	5,28	  7,54
    256000	0,2	0,48	0,95	2,39	3,34	  4,77
    512000	0,2	0,34	0,68	1,69	2,37	  3,39
  1024000	0,2	0,27	0,54	1,35	1,88	  2,69
  5000000	0,2	0,21	0,43	1,07	1,50	  2,14
10000000	0,2	0,21	0,41	1,04	1,45	  2,07

    64000	1	2,11	4,22	10,54	14,76	21,08
   128000	1	1,55	3,11	  7,77	10,88	15,54
   256000	1	1,28	2,55	  6,39	  8,94	12,77
   512000	1	1,14	2,28	  5,69	  7,97	11,39
  1024000	1	1,07	2,14	  5,35	  7,48	10,69
  5000000	1	1,01	2,03	  5,07	  7,10	10,14
10000000	1	1,01	2,01	  5,04	  7,05	10,07

 	Adresse des auteurs

Jose Rey	David Leon	Akihiro Miyazaki	
Panasonic GmbH	Consultant	Matsushita Electric Industrial Co., Ltd	
Monzastr. 4c	mél : davidleon123@yahoo.com 	1006, Kadoma, Kadoma City,	
D-63225 Langen, Germany		Osaka, Japan	
téléphone : +49-6103-766-134		téléphone : +81-6-6900-9172	
mél : jose.rey@eu.panasonic.com 		miyazaki.akihiro@jp.panasonic.com 	

Viktor Varsa	Rolf Hakenberg	
Nokia Research Center	Panasonic R&D Center Germany GmbH	
6000 Connection Drive	Monzastr. 4c	
Irving, TX. USA	D-63225 Langen, Germany	
téléphone :  1-972-374-1861	téléphone : +49-6103-766-162	
mél : viktor.varsa@nokia.com 	mél : rolf.hakenberg@eu.panasonic.com 	

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2006).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Remerciement 
Le financement de la fonction d’édition des RFC est fourni par l'activité de soutien administatif (IASA) de l'IETF.