Le chiffre que tout le monde cite pour un appel est le débit du codec : 64 kilobits par seconde pour le G.711, 8 pour le G.729. Ni l’un ni l’autre n’est ce que l’appel coûte sur un lien. Chaque paquet transporte aussi un en-tête RTP, un en-tête UDP, un en-tête IP et un en-tête de couche 2, et ceux-là se paient par paquet plutôt que par seconde : plus vous coupez les paquets court, plus vous payez de surcharge. Un appel G.711 en paquets de 20 millisecondes sur Ethernet fait 87,2 kilobits par seconde, pas 64. Environ le quart n’est pas de la voix.
Faites le calcul pour vous
Ce qui transforme la parole en bits. Le débit entre parenthèses est celui du codec, et ce n’est pas ce que l’appel coûte sur un lien.
Des paquets plus courts, ce sont plus de paquets par seconde, et les en-têtes se paient sur chacun d’eux. 20 ms est le réglage habituel.
Fait passer 40 octets par paquet à 2. C’est une technique pour un lien point à point entre deux routeurs ; ne la présumez pas sur une connexion Internet ordinaire.
Pas des appels par jour. Le plus grand nombre d’appels en cours au même moment, souvent le nombre de personnes qui répondent.
Facultatif, et rien n’est deviné. Laissez l’un ou l’autre vide et l’outil n’en dira rien.
Vos chiffres restent dans votre navigateur. Rien n’est téléversé et rien n’est conservé.
Ce que les appels demandent
- Téléversement nécessaire
- 0,35 Mbit/s
- Téléchargement nécessaire
- 0,35 Mbit/s
- Un appel, dans chaque sens
- 87,2 kbit/s
- Le débit propre du codec
- 64 kbit/s
- En-têtes, par appel dans chaque sens
- 23,2 kbit/s
- Part du lien qui est de la voix
- 73,4 %
- Paquets par seconde, par appel
- 50
- Voix dans un paquet
- 160 octets
- En-têtes sur un paquet
- 58 octets
- Un paquet sur le lien
- 218 octets (1 744 bits)
Les deux sens sont de même taille, parce qu’une conversation envoie un flux dans chaque direction. Ils sont indiqués séparément parce que presque personne n’achète un lien au même débit dans les deux sens, et c’est le téléversement qui manque en premier.
Ceci est un calcul fondé sur une norme publiée. Rien ici n’a touché à votre réseau, et un calcul ne peut pas vous dire si votre connexion suffit. Il vous dit la place que prendraient les appels sur un lien où il n’y a rien d’autre.
Ce que ceci ne fait pas
Cette page ne teste rien. Elle n’envoie aucun paquet, n’ouvre aucune connexion et ne mesure ni délai, ni gigue, ni perte. Les gens qui cherchent un test VoIP veulent en général un verdict sur leur connexion, et ce n’est pas cela. C’est l’autre moitié de la question : la place dont les appels ont besoin, calculée à partir d’une norme publiée, avec l’arithmétique visible pour que vous puissiez la vérifier.
La capacité n’est pas la qualité. Un lien qui a de la place peut quand même produire des appels hachés, parce que ce qui gâche un appel n’est en général pas la quantité de bande passante. C’est le délai, la variation de ce délai, et les paquets qui arrivent en retard ou pas du tout. Deux connexions annoncées au même débit se comportent très différemment dès que le reste du réseau s’en sert.
Les chiffres sont un plancher, sur un lien vide. Ils décrivent l’audio et rien d’autre : ni l’établissement de l’appel, ni la vidéo, ni le partage d’écran, ni tout ce qu’un bureau fait de sa connexion en même temps. Prenez la réponse comme le minimum que les appels demanderaient s’ils avaient la ligne pour eux seuls, et gardez de la marge au-dessus.
Et une mesure courte ne trancherait pas davantage. Même un vrai test ne décrirait que le chemin qu’il a pris, l’appareil sur lequel il a tourné et la minute où il a tourné. Il ne pourrait pas promettre le même résultat sur un autre portable, sur le Wi-Fi du bureau plutôt que sur un câble, ou à votre heure de pointe un mardi. Quiconque affiche une pastille verte disant que votre réseau convient aux appels affirme quelque chose qu’il ne peut pas savoir.
D’où viennent les chiffres
La méthode vient de Cisco, et les tailles d’en-tête aussi. IP, UDP et RTP font ensemble 40 octets par paquet, ou 2 lorsque la compression RTP est en service sur un lien point à point. En dessous se trouve un en-tête de couche 2 dont la taille dépend de ce qui porte le paquet : 18 octets sur Ethernet, séquence de contrôle de trame de quatre octets comprise, et 7 octets sur Multilink PPP ou FRF.12, soit un en-tête de six octets plus le fanion de fin de trame d’un octet.
Ensuite, trois lignes. Additionnez l’en-tête de couche 2, les en-têtes IP, UDP et RTP et la charge utile de voix pour obtenir la taille d’un paquet. Divisez mille par l’intervalle de paquétisation en millisecondes pour savoir combien de ces paquets partent chaque seconde. Multipliez la taille du paquet en bits par ce nombre : voilà un appel, un sens.
Un calculateur faux d’un seul octet d’en-tête rend un nombre parfaitement plausible ; la seule affirmation utile est donc celle que vous pouvez vérifier. Le tableau ci-dessous est celui que la source publie, et à côté de chaque chiffre publié se trouve ce que cette page calcule à partir des tailles ci-dessus. La même comparaison est une série d’assertions dans npm run check:bandwidth : le tableau ne peut donc pas cesser d’être vrai en silence.
| Codec | Audio par paquet | Charge utile | Paquets par seconde | MP ou FRF.12 | Avec cRTP | Ethernet |
|---|---|---|---|---|---|---|
| G.711 (64 Kbps) | 20 ms | 160 / 160 octets | 50 / 50 | 82,8 / 82,8 | 67,6 / 67,6 | 87,2 / 87,2 |
| G.729 (8 Kbps) | 20 ms | 20 / 20 octets | 50 / 50 | 26,8 / 26,8 | 11,6 / 11,6 | 31,2 / 31,2 |
| G.723.1 (6.3 Kbps) | 30 ms | 24 / 24 octets | 33,3 / 33,3 | 18,9 / 18,9 | 8,8 / 8,8 | 21,9 / 21,9 |
| G.723.1 (5.3 Kbps) | 30 ms | 20 / 20 octets | 33,3 / 33,3 | 17,9 / 17,9 | 7,7 / 7,7 | 20,8 / 20,8 |
| G.726 (32 Kbps) | 20 ms | 80 / 80 octets | 50 / 50 | 50,8 / 50,8 | 35,6 / 35,6 | 55,2 / 55,2 |
| G.726 (24 Kbps) | 20 ms | non imprimé / 60 octets | 50 / 50 | 42,8 / 42,8 | 27,6 / 27,6 | 47,2 / 47,2 |
| G.728 (16 Kbps) | 30 ms | 60 / 60 octets | 33,3 / 33,3 | 28,5 / 28,5 | 18,4 / 18,4 | 31,5 / 31,5 |
| G722_64k (64 Kbps) | 20 ms | 160 / 160 octets | 50 / 50 | 82,8 / 82,8 | 67,6 / 67,6 | 87,2 / 87,2 |
| iLBC mode 20 (15.2 Kbps) | 20 ms | 38 / 38 octets | 50 / 50 | 34 / 34 | 18,8 / 18,8 | 38,4 / 38,4 |
| iLBC mode 30 (13.33 Kbps) | 30 ms | 50 / 50 octets | 33,3 / 33,3 | 25,867 / 25,867 | 15,73 / 15,73 | 28,8 / 28,8 |
Source : Voice Over IP: Per Call Bandwidth Consumption, Cisco, lue le 2026-09-07. La source laisse vide la cellule de charge utile de la ligne G.726 à 24 kbit/s ; le chiffre à côté est déduit de la taille de trame de ce codec, et ses trois cellules de débit publiées sont ce qui le confirme. La note de preuve derrière ce tableau est docs/seo/tools/bandwidth-evidence.md.
L’exemple détaillé, étape par étape
La source imprime un calcul en entier : un appel G.729 à en-têtes comprimés sur Multilink PPP. Six octets d’en-tête de couche 2, deux octets d’IP, UDP et RTP comprimés et une charge utile de vingt octets font 28 octets, soit 224 bits. À 50 paquets par seconde, cela donne 11,2 kilobits par seconde par appel. Cette page reproduit chaque ligne du calcul, pas seulement la réponse : une vérification portant sur le dernier nombre seul passerait pour une implémentation arrivée là par le mauvais chemin.
Une chose vaut la peine d’être sue à propos de cet exemple : il additionne l’en-tête de six octets et laisse de côté le fanion de fin de trame d’un octet que la même page énumère à part, alors que chaque cellule de son propre tableau compte les deux. L’exemple arrive donc à 11,2 kilobits par seconde et la cellule correspondante du tableau dit 11,6. Les deux sont reproduits ci-dessus et les deux sont vérifiés par le script. Choisir l’un des deux et déclarer la source cohérente aurait été la facilité, et une erreur.
Ce qui tourne en dessous
Un paquet contient un nombre entier de trames du codec, et c’est pourquoi la charge utile n’est pas simplement le débit multiplié par le temps. Le G.723.1 à 6,3 kilobits par seconde sur 30 millisecondes donne 23,625 octets ; le codec émet une trame de 24 octets, et c’est elle qui entre dans le paquet. Arrondir le raccourci mettrait cette page en désaccord avec la norme qu’elle prétend reproduire sur deux lignes, et le script de vérification contient une assertion dont le seul rôle est d’échouer le jour où quelqu’un essaiera.
C’est aussi pourquoi la durée de paquet est une liste et non un champ libre. Un codec à trame de 30 millisecondes ne peut pas remplir un paquet de 20 millisecondes : l’outil n’offre donc que les durées que le codec choisi peut réellement produire, et changer de codec déplace la durée vers la valeur offerte la plus proche plutôt que de vous montrer une erreur pour un choix que vous n’avez pas fait.
Le téléversement et le téléchargement sont présentés en deux lignes même si les deux nombres sont identiques. Une conversation envoie un flux dans chaque sens, donc ils le seront toujours. La raison de les garder distincts est que presque personne n’achète une connexion au même débit dans les deux sens : le même besoin est une petite part du téléchargement et une grande part du téléversement, et c’est ce dernier qui plafonne le nombre d’appels simultanés.
Une saisie absurde est nommée plutôt que calculée. Zéro appel a une réponse arithmétique, et imprimer « 0 kilobit par seconde » sous un titre qui dit « ce que les appels demandent » serait vrai et inutile. Un intervalle de paquétisation de zéro donne une infinité de paquets par seconde, et la forme honnête de cela est une phrase plutôt qu’un nombre. Ni l’un ni l’autre n’atteint jamais l’écran sous forme de chiffre.
Tout cela tourne dans votre navigateur, en quelques dizaines d’opérations. Il n’y a aucun point de terminaison derrière cette page, aucun téléversement et aucune requête vers quoi que ce soit : les codecs que vous envisagez et le nombre d’appels de votre entreprise ne nous regardent pas.
Questions
Combien de bande passante demande un appel VoIP ?
Sur un réseau de bureau ordinaire, un appel G.711 en paquets de 20 millisecondes demande environ 87 kilobits par seconde dans chaque sens, et un appel G.729 en demande environ 31. Ce sont les chiffres en-têtes comptés, ce qui explique qu'ils dépassent les 64 et les 8 qui donnent leur nom aux codecs. Multipliez par le nombre d'appels en cours au même moment, et rappelez-vous qu'il en faut autant à la montée qu'à la descente.
Pourquoi un appel G.711 fait-il 87 kbit/s et non 64 ?
Parce que 64 kilobits par seconde est le débit auquel le codec transforme la parole en bits, et que l'appel doit aussi transporter des en-têtes. Chaque paquet reçoit 12 octets de RTP, 8 d'UDP et 20 d'IP, plus un en-tête de couche 2 qui dépend de ce sur quoi le paquet voyage : 18 octets sur Ethernet. À 50 paquets par seconde, cela fait 58 octets supplémentaires cinquante fois, soit 23,2 kilobits par seconde par-dessus les 64. Environ le quart de ce que l'appel consomme n'est pas de la voix.
Est-ce que ceci teste ma connexion Internet ?
Non. Rien sur cette page ne touche à votre réseau. C'est un calcul fondé sur une norme publiée, et il vous dit la place qu'un nombre donné d'appels prendrait sur un lien où il n'y a rien d'autre. Que votre connexion les porte bien dépend du délai, de la régularité de ce délai, des paquets qui se perdent et de ce qui utilise la ligne à seize heures, et un calcul ne peut rien savoir de tout cela.
Est-ce le téléversement ou le téléchargement qui manque en premier ?
Le téléversement, presque toujours. Une conversation envoie un flux dans chaque sens : les deux besoins sont donc identiques en taille. Ce qui n'est pas identique, c'est ce que vous avez acheté. Une connexion d'affaires typique porte beaucoup moins vers l'extérieur que vers l'intérieur, et c'est donc le chiffre de téléversement qui plafonne le nombre d'appels simultanés. Dimensionnez sur le téléversement et le reste suit.
Quelle durée de paquet choisir ?
20 millisecondes, sauf indication contraire de votre installation : c'est le réglage par défaut de presque tout. Le compromis est simple. Des paquets plus courts ajoutent moins de délai quand l'un d'eux se perd, et coûtent plus cher, parce que les en-têtes se paient par paquet et non par seconde. Passer de 20 à 10 millisecondes double la surcharge. Aller vers 30 économise de la bande passante et laisse un trou plus grand dans l'audio quand un paquet manque.
Combien d'appels ma connexion portera-t-elle ?
Divisez votre débit de téléversement par le chiffre par appel et vous avez une réponse arithmétique, que la feuille ci-dessus vous donnera. Prenez-la comme un plafond, pas comme un plan. La voix partage la ligne avec tout le reste de l'immeuble, et un appel qui a tout juste la place quand rien d'autre ne se passe est un appel qui se hache dès que quelqu'un lance un gros envoi. Gardez de la marge, et vérifiez la vraie chose après le changement plutôt que de vous fier à un chiffre d'avant.
Une fois le chiffre connu
La capacité est la moitié facile. Ce qui décide de l’expérience d’un appelant, c’est ce qui arrive à l’appel une fois arrivé : qui il atteint, ce qu’il entend en attendant, et où il va quand personne n’est libre. Si vous préparez un changement, le raisonnement complet est dans la bande passante que demande la VoIP, et nous regardons volontiers votre situation avec vous.