Groupe de travail Réseau	D. Singer, Apple Computer Inc.
Request for Comments : 5450	H. Desineni, Qualcomm
Catégorie : Sur la voie de la normalisation	mars 2009
Traduction Claude Brière de L'Isle

Décalages de temps de transmission dans les flux RTP

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la 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 droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document.

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.

Résumé
Le présent document décrit une méthode pour informer les clients du protocole de transport en temps réel (RTP, Real-time Transport Protocol) quand des paquets RTP sont transmis à un instant autre que celui de leur temps de transmission "nominal". Il fournit aussi un mécanisme de rapports améliorés de gigue inter arrivées provenant des clients, qui prend en compte les temps de transmission rapportés.
Table des matières
1. Introduction	1
2. Notation des exigences	2
3. Décalage de transmission	2
4. Rapports de gigue étendus	4
5. Informations de signalisation (établissement)	4
6. Considérations sur la sécurité	4
7. Considérations relatives à l’IANA	4
8. Remerciements	5
9. Références normatives	5
Adresse des auteurs	5

 	1.	Introduction

Dans la spécification du protocole de transport en temps réel (RTP, Real-time Transport Protocol) [RFC3550], les calculs de la gigue du réseau sont fondés sur l'hypothèse que les paquets sont transmis essentiellement en accord avec leur horodatage RTP. Cela doit être vrai, bien sûr, en moyenne sur de longs intervalles de temps, car le client exécute les paquets conformément à ces horodatages. Cependant, pour les paquets individuels, cela peut n'être pas vrai dans certaines circonstances, comme :

o	Quand le débit de données du flux est saccadé, comme avec de la vidéo où des trames I peuvent être significativement plus grandes que des trames P ou B, un lissage de trafic peut devoir être appliqué pour maintenir un taux de données approprié.

o	Dans une vidéo qui a des dépendances au décodage vers l'avant, des trames peuvent devoir être transmises dans l'ordre du décodage (l'ordre des numéros de séquence) mais bien sûr, avec les horodatages de présentation. Dans ces circonstances, l'heure de transmission d'une trame envoyée plus tôt dans la séquence ne correspond pas à son horodatage RTP.

o	Quand des retransmissions sont envoyées, le paquet retransmis a clairement une heure de transmission réelle différente de celle de l'original, même si ils portent le même horodatage.

Dans certaines circonstances, cela peut aider le receveur, ou des éléments de réseau intermédiaires, de connaître l'heure de transmission réelle du paquet. Le présent élément d'extension d'en-tête RTP permet la communication de cette information.

La spécification RTP ne définit pas d'horodatage de transmission, pas plus que la présente spécification. Elle fournit simplement des informations sur la relation entre les temps de transmission relatifs et les horodatage RTP relatifs.

La présente spécification permet à l'émetteur d'indiquer au receveur toute variation connue entre l'espacement des temps de transmission et l'espacement des horodatages RTP ; toute variation non rapportée introduite à ce point de mesure ou après l'instant de transmission sera traitée comme de la gigue du réseau par le receveur. La définition du point où l'heure de transmission est mesurée ou définie est laissée à l'émetteur, bien qu'elle devrait bien sûr être cohérente d'un paquet à l'autre.

Cette information peut aussi être utilisée pour rapporter la gigue inter-arrivées causée par le réseau, excluant celle introduite par la source. Un nouveau paquet du protocole de contrôle RTP (RTCP, RTP Control Protocol) est défini pour permettre ce rapport.

 	2.	Notation des exigences

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.	Décalage de transmission

Classiquement, une paire de paquets RTP avec des horodatages S2 et S1 sont transmis avec un intervalle entre eux de (S2 - S1). La présente spécification permet l'envoi d'une valeur de décalage O dans chaque paquet, O1 et O2. Une caractéristique de ces décalages est que l'intervalle de transmission original peut être déduit comme étant (S2 + O2) - (S1 + O1).

Plus précisément, le décalage est défini comme suit (avec la fonction RtoN qui convertit de RTP en temps du protocole de l'heure du réseau (NTP, Network Time Protocol) et NtoR qui fait l'inverse) :

o	On prend un flux RTP qui a un récent rapport d'envoyeur RTCP mettant en rapport d'horodatage RTP S0 avec l'horodatage NTP N0 ;

o	Considérons un paquet envoyé après cela avec l'horodatage RTP S1. Nominalement, il est envoyé à N1 = (N0 + RtoN(S1 - S0)) ;

o	Si il a en fait été envoyé à un instant différent, Na, alors la valeur de décalage O1 est O1 = NtoR(Na - N1).

L'heure de transmission est signalée au receveur dans la bande en utilisant le mécanisme général pour les extensions d'en-tête RTP [RFC5285]. La charge utile de cette extension (la valeur transmise) est un entier signé de 24 bits. Quand elle est ajoutée à l'horodatage RTP du paquet, elle représenté l'heure "effective" de transmission RTP du paquet, sur l'échelle des temps de RTP. L'heure de transmission rapportée T1 d'un paquet avec l'horodatage S1 et un décalage de O1, d'après les équations ci-dessus, est T1 = S1+O1 (bien que les valeurs de temps de transmission n'aient de signification que quand deux ou plus sont comparées).

La forme du bloc d'extension de décalage de transmission est 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  ID   | lon=2 |            Décalage de transmission           |
+-------+-------+---------------+---------------+---------------+

Le champ longueur prend la valeur 2 pour indiquer que 3 octets suivent.

Le signe de la valeur de décalage dépend largement du choix de la transposition initiale des temps RTP en temps NTP. En général, sans examen d'un flux entier, il n'est pas possible de s'assurer que cette transposition va garder tous les décalages positifs ; donc, la présente spécification permet des valeurs négatives.

Imaginons un flux avec les horodatages et tailles suivantes (en ko) :

200    2 ko
300    4 ko
400    2 ko
500   12 ko
600   ... fin effective du flux

Il y a 20 ko étalés sur 400 unités de temps, c'est-à-dire, en moyenne, 1 ko par 20 unités de temps. On lisse le trafic, et on établit que étant donné un temps de transmission de x pour le premier paquet, on va transmettre les paquets suivants aux intervalles suivants :

x + 000   2 ko
x + 040   4 ko
x + 120   2 ko
x + 160  12 ko
x + 400 ... fin effective du flux

Le choix de x est essentiellement arbitraire : seules les valeurs relatives des horodatages importent. Maintenant, disons que le premier paquet est sorti *à* son horodatage RTP, c'est-à-dire, avec un décalage de 0, signifiant que x est 200. Ensuite, les valeurs de décalage sont :

0
- 60
- 80
- 140

C'est parce que dans ce cas, on lisse le trafic en envoyant conceptuellement "plus tôt" les petits paquets. Mais comme seules les valeurs relatives sont significatives, il est tout aussi valide de dire que x est 400, d'où les valeurs de décalage sont  :

200
140
120
60

Dans un flux où la présente extension n'est pas utilisée (c'est-à-dire, ni déclarée ni négociée) le décalage de transmission réel est donc inconnu. Cependant, quand l'extension est activée pour le flux, il PEUT être omis dans les paquets pour lesquels le décalage est 0 (zéro) ; c'est-à-dire, les paquets envoyés à leur temps nominal n'ont pas besoin de cela pour être étiquetés avec cette extension. Donc, l'heure de transmission impliquée pour un paquet RTP non étiqueté dépend de si l'extension est effective pour le flux (et donc que le décalage de transmission est 0) ou non (cas où le décalage de transmission est inconnu).

Les calculs de gigue effectués par un client RTP NE DOIVENT PAS utiliser ces décalages de transmission. En général, l'envoyeur (ou les éléments de réseau intermédiaires qui font l'analyse RTP) ne peuvent pas toujours savoir si les décalages ont été pris en compte ou non. Donc, pour la cohérence, le calcul de gigue devrait continuer de se faire sur les heures de réception "brutes". Cependant, voir à la Section 4 la question des rapports de gigue étendus.

Il n'y a pas d'attribut d'extension défini pour cette extension.

Il est structurellement possible d'avoir plus d'une extension pour le même type dans un paquet. Cependant, cette extension n'est définie que pour la source à rapporter. Les nœuds intermédiaires du réseau qui ne sont pas la source de la session RTP NE DOIVENT PAS ajouter cette extension (qu'elle ait ou non été présente précédemment) et NE DOIVENT PAS altérer la valeur existante de décalage de transmission dans un paquet, si l'extension est déjà présente.

(Bien sûr, il est clair que les éléments de réseau qui terminent un flux RTP, et sont la source d'un nouveau flux RTP, peuvent ajouter un en-tête d'extension de décalage de transmission aux paquets RTP du nouveau flux, si ils le désirent.)

 	4.	Rapports de gigue étendus

La gigue inter arrivées calculée comme défini au paragraphe 6.4.1 de la RFC 3550 fournit des rapports de gigue inter arrivées qui incluent toute gigue introduite par la source (décalages de temps de transmission). Si on désire indiquer la gigue réelle du réseau, en excluant la gigue introduite par la source, le nouveau  type de paquet RTCP défini ici peut être utilisé.

Il a le format suivant :

        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|V=2|P|    RC   |   PT=IJ=195   |            Longueur           |
       +---+-+---------+---------------+---------------+---------------+
       |              Gigue inter arrivées                             |
       +---------------+---------------+---------------+---------------+
       .                                                               .
       .              Gigue inter arrivées                             .
       .                                                               .
       |                                                               |
       +---------------+---------------+---------------+---------------+

Si il est présent, ce paquet RTCP doit être placé après un rapport de receveur (dans un paquet RTCOP composé) et DOIT avoir la même valeut pour le compte de rapports de réception (RC, reception report count) que le rapport de receveur. Le contenu est exactement ce nombre de calculs de gigue inter arrivées, calculés en utilisant la même formule que pour les rapports d'envoyeur et de receveur, mais en tenant compte des décalages de transmission pour les flux (si il en est). C'est-à-dire, la formule utilise les valeurs T1=S1+O1, T2, etc., comme défini ci-dessus, au lieu de S1, S2, etc. (Si aucune information de décalage de transmission n'est donnée pour un flux, alors la valeur de la gigue inter arrivées dans ce paquet et dans le rapport de receveur va être identique).

Précisément, l'équation de remplacement de celle de la spécification RTP est comme suit, où Rj est l'heure d'arrivée la plus récente :

D(i,j) = (Rj - Ri) - ((Sj + Oj) - (Si + Oi))
          = (Rj - (Sj + Oj)) - (Ri - (Si + Oi))

 	5.	Informations de signalisation (établissement)

L'URI pour déclarer cette extension d'en-tête dans un attribut extmap est "urn:ietf:params:rtp-hdrext:toffset". Il n'y a pas d'information d'établissement supplémentaire nécessaire pour cette extension (pas d'attribut d'extension).

 	6.	Considérations sur la sécurité

Les décalages de transmission donnés sont seulement pour information, et il est difficile de trouver des problèmes de sécurité dans leur association à des flux de supports.

Les considérations de sécurité sous-jacentes à la [RFC3550] devraient être prises en compte.

Il est possible que des envoyeurs malveillants (ou des systèmes qui altèrent les paquets en transit) puissent envoyer des décalages invraisemblables, créer de la confusion chez le receveur, ou résulter en des valeurs de gigue calculées qui pourraient tromper l'envoyeur. L'envoyeur et le receveur des valeurs de décalage de transmission et de gigue devraient veiller à ce que un tel comportement ne résulte pas en déni de service ou autres problèmes.

 	7.	Considérations relatives à l’IANA

Le type de paquet RTCP utilisé pour la gigue inter arrivées ajustée a été enregistré, en accord avec la Section 15 de la [RFC3550]. L'IANA a ajouté une nouvelle valeur au sous registre des types de paquets de commande RTCP du registre des paramètres du protocole de transport en temps réel (RTP) en accord avec les données suivantes :

Abréviation	Nom	Valeur	Référence
IJ	Rapport étendu de gigue inter arrivées	195	RFC 5450

De plus, l'IANA a enregistré un nouvel URI d'extension au sous registre des extensions d'en-têtescompact RTP du registre des paramètres du protocole de transport en temps réel (RTP) conformément aux données suivantes :

URI d'extension : urn:ietf:params:rtp-hdrext:toffset
Description : décalages d'heure de transmission
Contact : singer@apple.com
Référence : RFC 5450

 	8.	Remerciements

Ron Frederick, Colin Perkins, et Steve Casner ont tous contribué de façon substantielle à ce document, et leur aide et leurs contributions ont permis de faire d'une idée une spécification.

 	9.	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)

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

[RFC5285]	D. Singer, H. Desineni, "Mécanisme général pour les extension d'en-tête RTP", juillet 2008. (P.S. ; remplacée par RFC8285)

 	Adresse des auteurs

David Singer	Harikishan Desineni	
Apple Computer Inc.	Qualcomm	
1 Infinite Loop	5775 Morehouse Drive	
Cupertino, CA  95014	San Diego, CA  92121	
US	US	
téléphone : +1 408 996 1010	téléphone : +1 858 845 8996	
mél : singer@apple.com	mél : hd@qualcomm.com