Aller au contenu principal

16. Setting Ta and RTO (Définition de Ta et RTO)

Pendant la phase de collecte d'ICE (Section 4.1.1) et pendant qu'ICE effectue des vérifications de connectivité (Section 7), un agent envoie des transactions STUN et TURN. Ces transactions sont cadencées à un taux d'une toutes les Ta millisecondes et utilisent un RTO spécifique. Cette section décrit comment les valeurs de Ta et RTO sont calculées. Ce calcul dépend du fait qu'ICE soit utilisé avec un flux multimédia en temps réel (tel que RTP) ou autre chose. Lorsque ICE est utilisé pour un flux avec une bande passante maximale connue, le calcul de la section 16.1 MAY être suivi pour contrôler le débit des échanges ICE. Pour tous les autres flux, le calcul de la section 16.2 MUST être suivi.

16.1. RTP Media Streams (Flux multimédias RTP)​

Les valeurs de RTO et Ta changent pendant la durée de vie du traitement ICE. Un ensemble de valeurs s'applique pendant la phase de collecte, et l'autre, pour les vérifications de connectivité.

La valeur de Ta SHOULD être configurable et SHOULD avoir une valeur par défaut de :

Pour chaque flux multimédia i :

Ta_i = (stun_packet_size / rtp_packet_size) * rtp_ptime

                       1
 Ta = MAX (20ms, ------------------- )
                       k
                     ----
                     \        1
                      >    ------
                     /       Ta_i
                     ----
                      i=1

où k est le nombre de flux multimédias. Pendant la phase de collecte, Ta est calculé en fonction du nombre de flux multimédias que l'agent a indiqués dans son offre ou sa réponse, et la taille du paquet RTP et le rtp_ptime sont ceux du codec le plus préféré pour chaque flux multimédia. Une fois qu'une offre et une réponse ont été échangées, l'agent recalcule Ta pour cadencer les vérifications de connectivité. Dans ce cas, la valeur de Ta est basée sur le nombre de flux multimédias qui seront réellement utilisés dans la session, et la taille du paquet RTP et le rtp_ptime sont ceux du codec le plus préféré avec lequel l'agent enverra.

De plus, le temporisateur de retransmission pour les transactions STUN, RTO, défini dans [RFC5389], SHOULD être configurable et pendant la phase de collecte, SHOULD avoir une valeur par défaut de :

RTO = MAX (100ms, Ta * (number of pairs))

où number of pairs fait référence au nombre de paires de candidats avec des serveurs STUN ou TURN.

Pour les vérifications de connectivité, RTO SHOULD être configurable et SHOULD avoir une valeur par défaut de :

RTO = MAX (100ms, Ta*N * (Num-Waiting + Num-In-Progress))

où Num-Waiting est le nombre de vérifications dans la liste de vérification à l'état Waiting, et Num-In-Progress est le nombre de vérifications à l'état In-Progress. Notez que le RTO sera différent pour chaque transaction car le nombre de vérifications dans les états Waiting et In-Progress change.

Ces formules visent à ce que les transactions STUN soient cadencées au même rythme que les médias. Cela garantit qu'ICE fonctionnera correctement dans les mêmes conditions de réseau nécessaires pour prendre en charge les médias également. Voir l'annexe B.1 pour une discussion supplémentaire et les motivations. En raison de ce cadencement, il faudra un certain temps pour obtenir tous les candidats server reflexive et relayed. Les implémentations doivent être conscientes du temps nécessaire pour ce faire et, si l'application nécessite un budget temps, limiter le nombre de candidats collectés.

Les formules aboutissent à un comportement par lequel un agent enverra son premier paquet pour chaque vérification de connectivité unique avant d'effectuer une retransmission. Cela peut être vu dans les formules pour le RTO (qui représente l'intervalle de retransmission). Ces formules s'échelonnent avec N, le nombre de vérifications à effectuer. En conséquence, ICE maintient un taux agréablement constant, mais devient plus sensible à la perte de paquets. La perte du premier paquet unique pour toute vérification de connectivité est susceptible de faire prendre beaucoup de temps à cette paire pour être validée, et à la place, une vérification de priorité inférieure (mais pour laquelle il n'y a pas eu de perte de paquet) est beaucoup plus susceptible de se terminer en premier. Cela a pour résultat qu'ICE fonctionne de manière sous-optimale, choisissant des paires de priorité inférieure par rapport aux paires de priorité supérieure. Les implémenteurs doivent être conscients de cette conséquence, mais doivent quand même utiliser les valeurs de temporisateur décrites ici.

16.2. Non-RTP Sessions (Sessions non-RTP)​

Dans les cas où ICE est utilisé pour établir un type de session qui n'est pas en temps réel et n'a pas de débit fixe associé qui est connu pour fonctionner sur le réseau dans lequel ICE est déployé, Ta et RTO reviennent à des valeurs plus conservatrices. Ta SHOULD être configurable, SHOULD avoir une valeur par défaut de 500 ms, et MUST NOT être configurable pour être inférieur à 500 ms.

De plus, le temporisateur de retransmission pour les transactions STUN, RTO, SHOULD être configurable et pendant la phase de collecte, SHOULD avoir une valeur par défaut de :

RTO = MAX (500ms, Ta * (number of pairs))

où number of pairs fait référence au nombre de paires de candidats avec des serveurs STUN ou TURN.

Pour les vérifications de connectivité, RTO SHOULD être configurable et SHOULD avoir une valeur par défaut de :

RTO = MAX (500ms, Ta*N * (Num-Waiting + Num-In-Progress))
Dernière mise à jour le