Groupe de travail Réseau	R. Even, Polycom	
Request for Comments : 4587		
RFC rendue obsolète  : 2032	août 2006	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle	

Format de charge utile RTP pour flux vidéo H.261

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é
Le présent mémoire décrit un schéma pour mettre en paquets un flux vidéo H.261 pour un transport utilisant le protocole de transport en temps réel, RTP, avec tout protocole sous-jacent qui porte RTP.

Ce mémoire décrit aussi la syntaxe et la sémantique des paramètres du protocole de description de session (SDP, Session Description Protocol) nécessaires pour prendre en charge le codec vidéo H.261. Un enregistrement de type de support est inclus pour ce format de charge utile.

La présente spécification rend obsolète la RFC 2032.
Table des matières
1. Introduction	1
2. Terminologie	2
3. Structure du flux de paquets	2
3.1 Vue d'ensemble de la Recommandation UIT-T H.261	2
3.2 Considérations de mise en paquets	2
4. Spécification du schéma de mise en paquets	3
4.1 Usage de RTP	3
4.2 Recommandations pour le fonctionnement avec des codecs de matériel	4
5. Problèmes de perte de paquet	5
6 Considérations relatives à l'IANA	5
6.1 Enregistrements de type de supports	5
6.2 Paramètres SDP	6
7. Rétro compatibilité avec la RFC 2032	7
7.1 Paquets de contrôle spécifiques de H.261 facultatifs	7
7.2 Nouveaux paramètres SDP facultatifs	7
8. Considérations sur la sécurité	7
9. Remerciements	8
10. Changements par rapport à la RFC 2032	8
11. Références	8
11.1 Références normatives	8
11.2 Références pour information	8
Adresse de l'auteur	9
Déclaration complète de droits de reproduction	9

 	1.	Introduction

La Recommandation UIT-T H.261 [H.261] spécifie le codage utilisé par les codecs de visioconférence conformes à l'UIT-T. Bien que ce codage ait été à l'origine spécifié pour des circuits du réseau numérique à intégration de services (RNIS) à débits de données fixes, les expériences [INRIA], [MICE] ont montré qu'ils peuvent aussi être utilisés sur des réseaux à commutation de paquets, comme l'Internet.

L'objet de ce mémoire est de spécifier le format de charge utile RTP pour encapsuler les flux vidéo H.261 dans RTP [RFC3550].

Le présent document rend obsolète la RFC 2032 et met à jour le type de support "video/h261" qui était enregistré dans la RFC 3555.

 	2.	Terminologie

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] et indiquent les niveaux d’exigence pour les mises en œuvre RTP conformes..

 	3.	Structure du flux de paquets
 	3.1	Vue d'ensemble de la Recommandation UIT-T H.261
Le codage H.261 est organisé comme hiérarchie de groupements. Le flux vidéo est composé d'une séquence d'images, ou trames, qui sont elles mêmes organisées comme un ensemble de groupes de blocs (GOB, Groups of Blocks). Noter que les "images" H.261 sont appelées des "trames" dans le présent document. Chaque GOB contient un ensemble de trois lignes de onze macroblocs (MB). Chaque MB porte les informations sur un groupe de 16 x 16 pixels : les informations de luminance sont spécifiées pour quatre blocs de 8 x 8 pixels, tandis que les informations de chrominance sont données par deux composants de différence de couleur "rouge" et "bleu" à une résolution de seulement 8 x 8 pixels. Ces composants et les codes représentant leurs valeurs échantillonnées sont définis dans la Recommandation UIT-R [BT.601].

Ce groupement est utilisé pour spécifier les informations à chaque niveau de la hiérarchie :
-	Au niveau de la trame, on spécifie des informations comme le retard par rapport à la trame précédente, le format d'image, et divers indicateurs.
-	Au niveau GOB, on spécifie le numéro de GOB et le quantifiant par défaut qui va être utilisé pour les MB.
-	Au niveau MB, on spécifie quels blocs sont présents et ceux qui n'ont pas changé, et facultativement, un quantifiant et des vecteurs de mouvement.

Les blocs qui ont changé sont codés en calculant la transformation en cosinus discret (DCT, discrete cosine transform) de leurs coefficients, qui sont alors quantifiés et codés selon le codage Huffman (codes de longueur variable).

Le codage Huffman de H.261 inclut un schéma spécial de "début de GOB", qui est un mot de 16 bits, 0000 0000 0000 0001. Ce schéma est inclus au début de chaque en-tête de GOB (et aussi au début de chaque en-tête de trame) pour marquer la séparation entre deux GOB et est en fait utilisé comme indicateur que le GOB actuel est terminé. Le codage inclut aussi un schéma de bourrage, composé de sept bits de zéros suivis par quatre bits de valeur un ; ce schéma de bourrage peut seulement être entré entre le codage des MB, ou juste avant le séparateur de GOB.

 	3.2	Considérations de mise en paquets
Les codecs H.261 conçus pour fonctionner sur des circuits RNIS produisent un flux binaire composé de plusieurs niveaux de codage spécifiés par H.261 et les Recommandations qui l'accompagnent. Les bits résultant du codage Huffman sont arrangés en trames de 512 bits, contenant 2 bits de synchronisation, 492 bits de données et 18 bits de code de correction d'erreur. Les trames de 512 bits sont alors entrelacées avec un flux audio et transmises sur des circuits px 64 kbit/s conformément à la Recommandation [H.221].

Pour la transmission sur l'Internet, on va considérer directement le résultat du codage Huffman. Tous les bits produits par l'étape de codage Huffman vont être inclus dans le paquet. On ne va pas porter les trames de 512 bits, car la protection contre les erreurs binaires peut être obtenue par d'autres moyens. De même, on ne va pas tenter de multiplexer les signaux audio et vidéo dans les mêmes paquets, car UDP et RTP fournissent une façon beaucoup plus convenable pour réaliser le multiplexage.

Transmettre directement le résultar du codage Huffman sur un flux non fiable de datagrammes UDP aurait cependant de mauvaises caractéristiques de résistance à l'erreur. Le résultat de la structure hiérarchique du flux binaire H.261 est qu'on a besoin de recevoir les informations présentes dans l'en-tête de trame pour décoder les GOB, ainsi que les informations présentes dans l'en-tête de GOB pour décoder les MB. Sans précautions, cela signifierait qu'il faut avoir reçu tous les paquets qui portent une image pour décoder correctement ses composants.

Si chaque image pouvait être portée dans un seul paquet, cette exigence ne poserait pas de problème. Cependant, une image vidéo ou même un GOB par lui-même peut parfois être trop gros pour tenir dans un seul paquet.

Donc, le MB est pris comme unité de fragmentation. Les paquets doivent commencer et se terminer sur une limite de MB ; c'est-à-dire qu'un MB ne peut pas être partagé entre plusieurs paquets. Plusieurs MB peuvent être portés dans un seul paquet quand ils vont tenir dans la taille maximale de paquet admise. Cette pratique est recommandée pour réduire le taux d'envoi de paquets et les frais généraux par paquet.

Pour permettre que chaque paquet soit traité indépendamment pour une resynchronisation efficace en présence des pertes de paquets, des informations d'état provenant de l'en-tête de trame et de l'en-tête de GOB sont portées avec chaque paquet pour permettre de décoder les MB de ce paquet. Ces informations d'état incluent le nombre de GOB en effet au début du paquet, le prédicteur d'adresse de macrobloc (c'est-à-dire, la dernière adresse de macrobloc (MBA, last macroblock address) codé dans le précédent paquet) la valeur de quantificateur en effet avant le début de ce paquet (GQUANT, MQUANT, ou zéro dans le cas du début du GOB) et les données du vecteur de mouvement (MVD, motion vector data) de référence pour calculer les vrais MVD contenus dans ce paquet. Le flux binaire ne peut pas être fragmenté entre un en-tête de GOB et le MB 1 de ce GOB.

De plus, comme le MB compressé peut ne pas remplir un nombre entier d'octets, l'en-tête de données contient deux entiers de 3 bits, SBIT et EBIT, pour indiquer le nombre de bits inutilisés dans, respectivement, le premier et le dernier octet des données H.261.

 	4.	Spécification du schéma de mise en paquets
 	4.1	Usage de RTP
Chaque paquet RTP commence par un en-tête RTP fixe, comme expliqué dans la [RFC3550]. Les champs suivants de l'en-tête fixe RTP utilisé pour les flux vidéo H.261 sont développés ci-dessous :

-	Type de charge utile. L'allocation d'un type de charge utile RTP pour ce format de paquet sort du domaine d'application du présent document et n'est pas spécifiée ici. Il est prévu que le profil RTP d'une classe d'applications particulières va allouer un type de chage utile pour ce codage, ou, si ce n'est pas fait, un type de charge utile devra être choisi dans la gamme dynamique.

-	L'horodatage RTP code l'instant d'échantillonnage de la première image vidéo contenue dans le paquet de données RTP.  Si une image vidéo occupe plus d'un paquet, l'horodatage DEVRA être le même sur tous ces paquets. Les paquets provenant de différentes images vidéo DOIVENT avoir un horodatage différent afin que ces trames puissent être distinguées par l'horodatage. Pour les flux vidéo H.261, l'horodatage RTP se fonde sur une horloge à 90 kHz. Ce débit d'horloge est un multiple du débit de trame naturel de H.261 (c'est-à-dire, 30000/1001 ou approximativement 29,97 Hz).  De cette façon, pour chaque heure de trame, l'horloge est juste incrémentée par le multiple, et cela supprime l'imprécision dans le calcul de l'horodatage. De plus, la valeur initiale de l'horodatage DOIT être aléatoire (imprévisible) pour rendre plus difficiles les attaques sur le chiffrement de texte en clair connu ; voir RTP [RFC3550]. Noter que si plusieurs trames sont codées dans un paquet (par exemple, quand il y a très peu de changements entre deux images) il est nécessaire de calculer les heures d'affichage pour les trames après la première, en utilisant les informations horaires de l'en-tête de trame H.261. Ceci est exigé parce que l'horodatage RTP donne seulement l'heure d'affichage de la première trame du paquet.

-	Le bit marqueur de l'en-tête RTP DOIT être réglé à un dans le dernier paquet d'une trame vidéo ; autrement, il DOIT être zéro. Donc, il n'est pas nécessaire d'attendre un paquet suivant (qui contient le code de début qui termine la trame courante) pour détecter qu'une nouvelle trame devrait être affichée.

Les données H.261 DEVRONT suivre l'en-tête RTP, comme dans ce qui suit :

 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                          .
.                                                               .
+---------------+---------------+---------------+---------------+
|                          En-tête H.261                        |
+---------------+---------------+---------------+---------------+
|                           Flux H.261  ...                     .
+---------------+---------------+---------------+---------------+

L'en-tête H.261 est défini comme suit :

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SBIT |EBIT |I|V| GOBN  |   MBAP  |  QUANT  |  HMVD   |  VMVD   |
+-----+-----+-+-+-------+-------+-+---------+---+-----+---------+

Les champs dans l'en-tête H.261 ont la signification suivante :

SBIT (Start bit position) : 3 bits. Position du bit de départ, nombre de bits de poids fort qui devraient être ignorés dans le premier octet de données.

EBIT (End bit position) : 3 bits. Position du bit de fin, nombre de bits de moindre poids qui devraient être ignorés dans le dernier octet de données.

I (données codées Intra trame ) : 1 bit. Réglé à 1 si ce flux contient seulement des blocs codés intra trame. Réglé à 0 si ce flux peut ou non contenir des blocs codés intra-trame. La signification de ce bit ne devrait pas être changée durant le cours de la session RTP.

V (fanion de vecteur de mouvement) : 1 bit. Réglé à 0 si un vecteur de mouvement n'est pas utilisé dans ce flux. Réglé à 1 si des vecteurs de mouvement peuvent ou non être utilisés dans ce flux. La signification de ce bit ne devrait pas être changée durant le cours de la session.

GOBN (nombre de GOB) : 4 bits. Code le nombre de GOB en effet au démarrage du paquet. Réglé à 0 si le paquet commence par un en-tête de GOB.

MBAP (MacroBlock Address Predictor) : 5 bits. Prédicteur d'adresse de MB, code le prédicteur d'adresse de macrobloc (c'est-à-dire, le dernier MBA codé dans le paquet précédentt). Ce prédicteur est dans la gamme de 0 à 32 (pour prédire les MBA valides de 1 à 33) mais parce que le flux de bits ne peut pas être fragmenté entre un en-tête de GOB et le MB 1, le prédicteur au démarrage du paquet ne doit pas être 0. Donc, la gamme est de 1 à 32, qui est biaisée par -1 pour tenir dans 5  bits. Par exemple, si MBAP est 0, la valeur du prédicteur de MBA est 1. Réglé à 0 si le paquet commence par un en-tête de GOB.

QUANT (Quantificateur) : 5 bits. La valeur de quantificateur (MQUANT ou GQUANT) en effet avant le démarrage de ce paquet. Réglé à 0 si le paquet commence par un en-tête de GOB.

HMVD (Horizontal Motion Vector Data) : 5 bits. Données du vecteur de mouvement horizontal de référence (MVD, motion vector data). Réglé à 0 si le fanion V est 0 ou si le paquet commence par un en-tête de GOB, ou quand le MTYPE du dernier MB codé dans le précédent paquet n'avait pas de compensation de mouvement (MC, motion compensation). HMVD est codé comme nombre de complément à deux, et "10000" correspondant à la valeur -16 est interdit (les champs de vecteur de mouvement sont dans la gamme +/-15).

VMVD (Vertical motion vector data) : 5 bits. Données de vecteur de mouvement vertical de référence. Réglé à 0 si le fanion V est 0 ou si le paquet commence par un en-tête de GOB, ou quand le MTYPE du dernier MB codé dans le précédent paquet n'était pas MC. VMVD est codé comme nombre de complément à deux, et "10000" correspondant à la valeur -16 NE DEVRA PAS être utilisé (les champs de vecteur de mouvement sont dans la gamme +/-15).

Noter que les fanions I et V sont des fanions d'indication ; c'est-à-dire, ils peuvent être déduits du flux de bits. Ils sont inclus pour permettre aux décodeurs de faire des optimisations qui ne seraient pas possibles si ces conseils n'étaient pas fournis avant le décodage du flux de bits. Donc, ces bits ne peuvent pas changer pour la durée du flux. Une mise en œuvre conforme peut toujours régler V=1 et I=0.

Le flux H.261 DEVRA être utilisé sans correction d'erreur BCH et sans tramage de correction d'erreur.

 	4.2	Recommandations pour le fonctionnement avec des codecs matériels
Les paquetiseurs pour codecs matériels peuvent facilement imaginer les limites de GOB, en utilisant le schéma de début de GOB inclus dans les données H.261. (Noter que les codeurs logiciels connaissent déjà les limites.) La mise en œuvre la moins coûteuse de mise en paquets est de mettre en paquets au niveau du GOB tous les GOB qui tiennent dans un paquet. Mais quand un GOB est trop gros, le paquetiseur doit l'analyser pour faire la fragmentation du MB. (Noter que seul le codage Huffman doit être analysé et qu'il n'est pas nécessaire de décompresser complètement le flux, de sorte que cela n'exige que relativement peu de traitement ; des exemples de mises en œuvre peuvent être trouvés dans certains codecs publics H.261, comme IVS [IVS] et VIC [VIC].) Il est recommandé que la fragmentation au niveau MB soit utilisée quand c'est faisable afin d'obtenir une mise en paquet plus efficace. Utiliser ce schéma de fragmentation réduit le débit de sortie de paquets et donc réduit les frais généraux.

Chez le receveur, le flux de données peut être dépaquetisé et dirigé sur une entrée de codec matériel. Si le décodeur matériel opère à un débit binaire fixe, la synchronisation peut être conservée en insérant le schéma de bourrage entre les MB (c'est-à-dire, entre les paquets) quand le taux d'arrivée de paquets est plus lent que le débit de bits.

 	5.	Problèmes de perte de paquet

Sur l'Internet, la plupart des pertes de paquet sont dues à l'encombrement du réseau plutôt qu'à des erreurs de transmission. Avec UDP, aucun mécanisme n'est disponible pour que l'envoyeur sache si un paquet a bien été reçu. Il appartient à l'application (c'est-à-dire, au codeur et décodeur) de traiter la perte de paquet. Chaque paquet RTP inclut un champ de numéro de séquence qui peut être utilisé pour détecter la perte de paquet.

H.261 utilise la redondance temporelle de la vidéo pour effectuer la compression. Ce codage différentiel (ou codage INTER-trame) est sensible à la perte de paquet. Après une perte de paquet, des parties de l'image peuvent rester corrompues jusqu'à ce que les MB correspondants aient été codés dans le mode INTRA-trame (c'est-à-dire, codés indépendamment des trames passées). Il y a plusieurs moyens d'atténuer la perte de paquet:

(1)	Une façon est d'utiliser seulement le codage INTRA-trame et le remplissage conditionnel au niveau MB. C'est-à-dire, seuls les MB qui changent (au delà d'un certain seuil) sont transmis.

(2)	Une autre façon est d'ajuster le taux de rafraîchissement de codage INTRA-trame en accord avec la perte de paquet observée par les receveurs. La Recommandation H.261 spécifie qu'un MB soit codé INTRA-trame au moins toutes les 132 fois qu'il est transmis. Cependant, le taux de rafraîchissement INTRA-trame peut être relevé afin d'accélérer la récupération quand le taux de pertes mesuré est significatif.

(3)	La façon la plus rapide de réparer une image corrompue est de demander un rafraîchissement d'image codée INTRA-trame après la déection d'une perte de paquet. Un moyen de le faire est que le décodeur envoie au codeur une liste des paquets perdus. Le codeur peut décider de coder chaque MB de chaque GOB de la trame vidéo suivante comme mode INTRA-trame (c'est-à-dire, complètement codé en INTRA-trame). Si le codeur peut déduire des numéros de séquence des paquets quels MB sont affectés par la perte, il peut économiser de la bande passante en envoyant seulement ces MB en mode INTRA-trame. Ce mode est particulièrement efficace dans les connexions en point à point ou quand le nombre de décodeurs est faible.

Les paquets de contrôle FIR et NACK spécifiques de H.261, comme décrits dans la RFC 2032, NE DEVRONT PAS être utilisés pour demander un rafraîchissement d'image. Les anciennes mises en œuvre sont encouragées à utiliser les méthodes décrites dans cette section. Le rafraîchissement d'image peut être nécessaire à cause de pertes de paquets ou des exigences de l'application. Un exemple d'exigence d'application peut être le changement de l'orateur dans une conférence vidéo multipoint avec activation de la voix. Deux méthodes peuvent être utilisées pour demander le rafraîchissement de l'image. La première est d'utiliser le profil étendu RTP pour rétroactions fondées sur RTCP et d'envoyer des paquets de contrôle RTCP génériques, comme décrit dans la [RFC4585]. La seconde méthode est d'utiliser des commandes d'application spécifiques du protocole, comme FastUpdateRequest de [H.245].

 	6	Considérations relatives à l'IANA

Cette Section met à jour le type de support H.261 décrit dans la [RFC3555].

Elle spécifie les paramètres facultatifs qui PEUVENT être utilisés pour choisir des caractéristiques facultatives du format de charge utile. Les paramètres sont spécifiés ici au titre de l'enregistrement de sous type MIME pour le codec UIT-T H.261. Une transposition des paramètres en protocole de description de session (SDP) [RFC4566] est aussi fournie pour les applications qui utilisent SDP. Plusieurs paramètres DEVRAIENT être exprimés comme une chaîne de types de supports, sous la forme d'une liste de paramètres séparés par des points-virgules.

 	6.1	Enregistrements de type de supports
Ce paragraphe décrit les types de supports et les noms associés à ce format de charge utile. Il met à jour la précédente version enregistrée dans la [RFC3555]. Cet enregistrement utilise le gabarit défini dans la [RFC4288]

 	6.1.1	Enregistrement du type de support MIME video/H261
Nom de type de support MIME : video
Nom de sous type MIME : H261
Paramètres exigés : aucun
Paramètres facultatifs :
CIF. Ce paramètre a le format paramètre=valeur. Il décrit le taux maximum de trame accepté pour la résolution de CIF. Les valeurs permises sont des entiers de 1 à 4, et il signifie que le taux maximum est la valeur spécifiée 29.97/.

QCIF. Ce paramètre a le format paramètre=valeur. Il décrit le taux maximum de trame accepté pour la résolution de QCIF. Les valeurs permises sont des entiers de 1 à 4, et il signifie que le taux maximum est la valeur spécifiée 29.97/.

D. Spécifie la prise en charge d'image fixes graphiques en accord avec l'annexe D de H.261. Si c'est pris en charge, la valeur du paramètre DEVRA être "1". Sinon, le paramètre NE DEVRAIT PAS être utilisé ou DEVRA avoir la valeur "0".

Considérations de codage : ce type de support est tramé et binaire, voir le paragraphe 4.8 de la [RFC4288].

Considérations de sécurité : voir la Section 8.

Considérations d'interopérabilité : ce sont des options du receveur; les mises en œuvre actuelles ne sont envoyer aucun paramètre facultatif dans leur SDP. Elles vont ignorer les paramètres facultatifs et vont coder le flux H.261 sans l'annexe D.  La plupart des décodeurs prennent en charge au moins les résolutions QCIF, et elles sont supposées disponibles dans presque toutes les applications de vidéo fondées sur H.261.

Spécification publiée : RFC 4587

Applications qui utilisent ce type de support : flux directs audio et video et applications de conférences.

Informations supplémentaires : aucune

Adresse de la personne à contacter pour plus d'informations : Roni Even : roni.even@polycom.co.il

Usage prévu : COMMUN

Restrictions d'usage : ce type de support dépend du tramage RTP et n'est donc défini que pour le transfert via RTP [RFC3550]. Le transport avec d'autres protocoles de tramage n'est pas défini pour l'instant.

Auteur : Roni Even

Contrôleur des changements : groupe de travail IETF Audio/Video, sur délégation de l'IESG.

 	6.2	Paramètres SDP
La chaîne type de support MIME video/H261 est transposée en champs dans le protocole de description de session (SDP) comme suit :
o	Le nom de support dans la ligne "m=" de SDP DOIT être video.
o	Le nom de codage dans la ligne "a=rtpmap" de SDP DOIT être H261 (le sous type MIME).
o	Le débit d'horloge dans la ligne "a=rtpmap" DOIT être 90000.
o	Les paramètres facultatifs "CIF", "QCIF", et "D", si il en est, DEVRONT être inclus dans la ligne "a=fmtp" de SDP. Ces paramètres sont exprimés comme une chaîne de type de support MIME, sous la forme d'une liste de paramètres séparés par des points-virgules.

 	6.2.1	Usage avec le modèle d'offre-réponse de SDP
Quand H.261 est offert sur RTP en utilisant SDP dans un modèle d'offre/réponse [RFC3264] les considérations suivantes sont nécessaires.

Options de codec : (D) cette option NE DOIT apparaître que si l'envoyeur de ce message SDP est capable de décoder cette option. Cette option DEVRA être considérée comme une capacité du receveur même quand elle est envoyée dans une offre "sendonly" (envoi seulement).

Tailles d'images et MPI : Les tailles d'image prises en charge et leurs informations correspondantes d'intervalle minimum d'image (MPI, Minimum Picture Interval) pour H.261 peuvent être combinées. Toutes les tailles d'image peuvent être annoncées à l'autre partie, ou seulement un sous ensemble. En utilisant l'attribut de direction recvonly ou sendrev, un terminal DEVRAIT annoncer les tailles d'image (avec leurs MPI) qu'il accepte de recevoir. Par exemple, CIF=2 signifie que le receveur peut recevoir une image CIF et que le taux de trame DEVRA être moins de 15 trames par seconde.

Quand l'attribut de direction est sendonly, les paramètres décrivent les capacités du flux que l'envoyeur peut produire.

Les mises en œuvre qui suivent la présente spécification DEVRONT spécifier au moins une taille d'image prise en charge.

Si le receveur ne spécifie pas la taille d'image ou le paramètre MPI, il est alors sûr de supposer que c'est une mise en œuvre qui suit la RFC 2032. Dans ce cas, il est RECOMMANDÉ de supposer que ce receveur est capable de prendre en charge la réception de la résolution QCIF avec MPI=1.

Les paramètres offerts en premier sont le mode d'image préféré à recevoir.

Un exemple de représentation de supports dans SDP est comme suit  : CIF à 15 trames par seconde, QCIF à 30 trames par seconde et annexe D

m=video 49170/2 RTP/AVP 31
a=rtpmap:31 H261/90000
a=fmtp:31 CIF=2;QCIF=1;D=1

Cela signifie que l'envoyeur de ce message peut décoder un flux de bits H.261 avec les options et paramètres suivants : la résolution préférée est CIF (son MPI est 2) mais si ce n'est pas possible, alors la taille QCIF est aussi acceptée. Une image fixe utilisant l'annexe D PEUT être utilisée.

 	7.	Rétro compatibilité avec la RFC 2032

Le présent document remplace la RFC 2032. Cette Section traite des problèmes majeurs de rétro compatibilité.

 	7.1	Paquets de contrôle spécifiques de H.261 facultatifs
La RFC 2032 définissait deux paquets de contrôle RTCP spécifiques de H.261, "Demande INTRA-trame complète" et "Accusé de réception négatif". La prise en charge de ces paquets de contrôle était facultative. Les paquets de contrôle spécifiques de H.261 diffèrent des paquets RTCP normaux en ce qu'ils ne sont pas transmis à l'adresse normale de destination de transport RTCP pour la session RTP (qui est souvent une adresse de diffusion groupée). À la place, ces paquets de contrôle sont envoyés directement via envoi individuel du décodeur au codeur. L'accès de destination pour ces paquets de contrôle est le même que celui qu'utilise le codeur comme accès de source pour transmettre les paquets RTP (de données). Donc, ces paquets peuvent être considérés comme des paquets de contrôle "inverses". Le présent mémoire suggère des méthodes génériques pour satifaire la même exigence. Les auteurs de ce document ne connaissent pas de produits qui prennent en charge ces paquets de contrôle. Comme ce sont des caractéristiques facultatives, les nouvelles mises en œuvre DEVRONT les ignorer, et elles NE DEVRONT PAS être utilisées par les nouvelles mises en œuvre.

 	7.2	Nouveaux paramètres SDP facultatifs
Le document ajoute de nouveaux paramètres facultatifs au type de charge utile H.261. Comme ce sont des paramètres facultatifs, on s'attend à ce que les anciennes mises en œuvre ignorent ces paramètres, tandis que les nouvelles mises en œuvre qui reçoivent des capacités de type de charge utile H.261 sans paramètre vont supposer que c'est une ancienne mise en œuvre et vont envoyer H.261 à la résolution QCIF et 30 trames par seconde.

 	8.	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 sur la sécurité discutées dans la spécification RTP [RFC3550], et dans tout profil RTP approprié (par exemple, [RFC3551]). Cela implique que la confidentialité du flux de supports est réalisée par le chiffrement. SRTP [RFC3711] peut être utilisé pour fournir à la fois le chiffrement et la protection de l'intégrité du flux RTP. Parce que la compression de données utilisée avec ce format de charge utile est appliquée de bout en bout, le chiffrement va être effectué après la compression, de sorte qu'il n'y a pas de conflit entre les deux opérations.

Une menace potentielle de déni de service existe pour le codage de données utilisant des techniques de compression qui ont une charge de calcul non uniforme du côté du receveur. L'attaquant peut injecter des datagrammes pathologiques dans le flux, qui sont complexes à décoder et causent la surcharge du receveur. L'usage de l'authentification d'au moins le paquet RTP est RECOMMANDÉE. H.261 est vulnérable à de telles attaques parce que il est possible à un attaquant de générer des paquets RTP contenant des trames qui affectent le processus de décodage des trames futures. Donc, l'usage de l'authentification de l'origine des données et la protection de l'intégrité des données d'au moins le paquet RTP est RECOMMANDÉE ; par exemple, avec SRTP.

Noter que le mécanisme approprié pour assurer la confidentialité et l'intégrité des paquets RTP et de leur charge utile dépend beaucoup de l'application et des protocoles de transport et de signalisation employés. Donc, bien que SRTP soit donné en exemple ci-dessus, d'autre choix possibles existent.

 	9.	Remerciements

Nos remerciements aux auteurs de la RFC 2032, Thierry Turletti et Christian Huitema. Des remerciements particuliers sont dus au travail fait par Petri Koskelainen de Nokia et Nermeen Ismail de Cisco, qui ont aidé à rédiger le texte pour les nouveaux types MIME.

 	10.	Changements par rapport à la RFC 2032

Les changements par rapport à la RFC 2032 sont :
1. Le type MIME H.261 est maintenant la spécification de charge utile.
2. Ajout de paramètres facultatifs au type MIME H.261.
3. Les paquets de contrôle spécifiques de H.261 sont maintenant déconseillés.
4. Changements rédactionnels pour alignement sur les procédures d'édition des RFC.

 	11.	Références
 	11.1	Références normatives
[H.261]	Recommandation UIT-T H.261, "Codec vidéo pour services audiovisuels à px 64 kbit/s", mars 1993.

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

[RFC3264]	J. Rosenberg et H. Schulzrinne, "Modèle d'offre/réponse avec le protocole de description de session (SDP)", juin 2002. (P.S.  ; MàJ par  RFC8843)

[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)

[RFC3551]	H. Schulzrinne et S. Casner, "Profil RTP pour conférences audio et vidéo avec contrôle minimal", STD 65, juillet 2003. (MàJ par RFC8860)

[RFC3555]	S. Casner et P. Hoschka, "Enregistrement de type MIME pour les types de charge utile RTP", juillet 2003.

[RFC4566]	M. Handley, V. Jacobson et C. Perkins, "SDP : Protocole de description de session", juillet 2006. (P.S.  ; remplacée par RFC8866)

 	11.2	Références pour information

[BT.601]	Recommendation UIT-R BT.601-5, "Paramètre de codage en studio de télévision numérique pour le standard 4:3 et les ratios d'aspect d'écran large en 16:9",  octobre 1995.

[H.221]	Recommandation UIT-T H.221, "Structure de trame pour canal de 64 à 1920 kbit/s dans les téléservices audiovisuels", mai 1999.

[H.245]	Recommandation UIT-T H.245, "Protocole de contrôle pour communications multimédia", mai 2006.

[INRIA]	Turletti, T., "H.261 software codec for videoconferencing over the Internet", INRIA Research Report 1834, janvier 1993.

[IVS]	Turletti, T., "INRIA Videoconferencing tool (IVS)", disponible par FTP anonyme à zenon.inria.fr dans le répertoire "rodeo/ivs/last_version". Voir aussi l'URL < http://www.inria.fr/rodeo/ivs.html >.

[MICE]	Sasse, MA., Bilting, U., Schultz, CD., and T.  Turletti, "Remote Seminars through MultiMedia Conferencing: Experiences from the MICE project", Proc. INET'94/JENC5, Prague pp. 251/1-251/8, juin 1994.

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

[RFC4288]	N. Freed et J. Klensin, "Spécifications du type de support et procédures d'enregistrement", BCP 13, décembre  2005.

[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)

[VIC]	MacCanne, S., "VIC Videoconferencing tool", disponible par FTP anonyme à ee.lbl.gov dans le répertoire "conferencing/vic".

 	Adresse de l'auteur

Roni Even
Polycom
94 Derech Em Hamoshavot
Petach Tikva  49130
Israel

mél : roni.even@polycom.co.il 

 	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.