La VoIP en pratique : protocoles, débit et pannes courantes

La VoIP (Voice over IP) transporte la voix sous forme de paquets IP : un protocole de signalisation, SIP dans la plupart des déploiements, monte et démonte l'appel, pendant qu'un flux RTP transporte l'audio numérisé. Presque tout ce qui se passe ensuite, qualité, pannes, fraude, découle de cette séparation entre le canal de commande et le canal audio.

Deux flux, pas un : SIP d’un côté, RTP de l’autre

Un poste qui appelle envoie un INVITE à son serveur, avec dans le corps du message une description SDP (RFC 4566) qui annonce « je sais parler G.711 et G.722, envoie-moi l'audio sur 192.168.1.42 port 16384 ». Le serveur répond 100 Trying, puis 180 Ringing quand ça sonne, puis 200 OK avec la description SDP de l'appelé. L'appelant confirme par un ACK. À cet instant seulement, les deux extrémités commencent à s'envoyer des paquets RTP, généralement toutes les 20 millisecondes. Le BYE en fin d'appel ferme la session SIP, pas le flux audio, qui s'arrête simplement faute d'émetteur.

SIP et RTP ne suivent pas forcément le même chemin dans le réseau.

C'est ce détail d'architecture qui explique la panne la plus fréquente en VoIP : un appel qui sonne, qui décroche, et où personne n'entend rien. La signalisation a transité par le proxy de l'opérateur sans problème, le flux audio a essayé de partir en direct vers une adresse privée injoignable. Deux problèmes indépendants, deux diagnostics différents.

SIP est défini par la RFC 3261 (juin 2002), RTP par la RFC 3550. Les ports à connaître avant d'ouvrir un pare-feu :

Protocole	Port par défaut	Rôle	Référence
SIP	5060 UDP et TCP	signalisation en clair	RFC 3261
SIP sur TLS	5061 TCP	signalisation chiffrée	RFC 3261
RTP	UDP dynamique, 10000-20000 par défaut sur Asterisk	transport de l'audio	RFC 3550
RTCP	port RTP + 1 (impair)	statistiques de gigue et de perte	RFC 3550
SRTP	mêmes ports que RTP	audio chiffré en AES	RFC 3711
IAX2	4569 UDP	signalisation et média sur un port unique	RFC 5456
H.323 / Q.931	1720 TCP	signalisation historique, en voie d'extinction	UIT-T H.323
T.38	UDP négocié dans le SDP	fax sur IP	RFC 3362

Ce qu’un appel coûte réellement en bande passante

Prenez un appel en G.711, le codec par défaut de la quasi-totalité des opérateurs français. Le codec produit 64 kbit/s d'audio utile. Avec une paquetisation de 20 ms, chaque paquet transporte 160 octets d'audio, auxquels s'ajoutent 12 octets d'en-tête RTP, 8 octets UDP et 20 octets IPv4, soit 200 octets envoyés 50 fois par seconde : 80 kbit/s au niveau IP. En comptant l'en-tête Ethernet et le FCS (18 octets), vous arrivez à 87,2 kbit/s. Par sens, et par appel.

Autrement dit, l'en-tête pèse un quart du paquet.

Cette proportion devient absurde avec les codecs compressés : en G.729, les 20 octets d'audio voyagent sous 40 octets d'en-têtes. Deux conséquences pratiques : en IPv6, l'en-tête passe de 20 à 40 octets et chaque appel consomme 8 kbit/s de plus ; dans un tunnel VPN, comptez 15 à 25 % de surcoût selon l'encapsulation.

Le RTP-header compression (cRTP, RFC 2508) réduit les 40 octets à 2 ou 4 sur une liaison point à point, mais il ne s'applique pas à un accès internet grand public.

Codec	Débit utile	Sur Ethernet (paquets de 20 ms)	Bande audio	Remarque
G.711 (PCMA en Europe)	64 kbit/s	87,2 kbit/s	300-3400 Hz	MOS de l'ordre de 4,4 en conditions idéales
G.729	8 kbit/s	31,2 kbit/s	300-3400 Hz	MOS plafonné vers 4,0, tolère mal la perte
G.722	64 kbit/s	87,2 kbit/s	50-7000 Hz	la « HD voice » des postes SIP
Opus (RFC 6716)	6 à 510 kbit/s, 24 typiques en voix	environ 47 kbit/s à 24 kbit/s utiles	jusqu'à 20 kHz	débit variable, résiste bien à la perte

Latence, gigue, perte : les trois chiffres qui décident de la qualité

La recommandation UIT-T G.114 fixe le repère : au-delà de 150 ms de latence bouche-à-oreille dans un sens, la conversation devient inconfortable, et au-delà de 400 ms elle n'est plus tenable. Les interlocuteurs commencent à se couper la parole bien avant de s'en rendre compte.

La gigue est plus sournoise. Elle mesure la variation du délai entre paquets : si vos paquets partent régulièrement toutes les 20 ms mais arrivent à 18, 25, 12 puis 40 ms, le récepteur doit les stocker le temps de reconstituer un flux régulier. Ce tampon de gigue ajoute sa propre latence, typiquement 20 à 60 ms en mode adaptatif. Quand la gigue dépasse la taille du tampon, les paquets en retard sont jetés purement et simplement, et vous entendez des trous, des mots hachés, une voix métallique.

Un lien qui affiche 2 % de perte à un test ping n'est pas utilisable pour de la voix.

Pour objectiver tout ça plutôt que de discuter à l'oreille : capturez l'appel, ouvrez le fichier dans Wireshark, puis Telephony > RTP > RTP Stream Analysis. Vous obtenez la gigue moyenne et maximale, le nombre de paquets perdus et les séquences hors ordre, flux par flux et par sens. C'est le seul moyen de savoir si le problème vient de l'aller ou du retour.

• Marquage QoS de l'audio : DSCP EF, valeur décimale 46 (RFC 3246), configuré sur le poste ou le commutateur d'accès.
• Marquage de la signalisation : CS3 (24) ou AF31 (26), pour éviter qu'un REGISTER perdu ne déconnecte le poste pendant la congestion.
• Ces marquages ne valent que dans un réseau que vous maîtrisez : entre deux opérateurs sur l'internet public, le DSCP est souvent remis à zéro.
• En entreprise, un VLAN voix séparé (802.1Q, annoncé au poste par LLDP-MED ou par l'option DHCP 132) évite qu'un transfert de fichier depuis le PC branché derrière le téléphone ne noie l'audio.

Le NAT, cause numéro un des appels sans son

Le routeur qui fait du NAT réécrit les adresses dans les en-têtes IP et UDP. Il ne touche pas au corps du message SIP. Résultat : votre poste annonce dans son SDP l'adresse 192.168.1.42, l'opérateur la lit, et envoie consciencieusement l'audio vers une adresse privée qui n'existe pas chez lui. Le RTP part dans le vide, tandis que le sens inverse fonctionne parfaitement puisque vos paquets sortants ont ouvert une association NAT au passage. D'où le symptôme classique : vous entendez, on ne vous entend pas.

La fonction SIP ALG de la box est censée corriger ça en réécrivant le SDP à la volée. Dans la pratique, elle casse plus d'appels qu'elle n'en répare, surtout avec plusieurs postes derrière la même IP publique, et la première recommandation de la plupart des opérateurs SIP est de la désactiver.

Les vraies solutions, par ordre de robustesse :

• Déclarer l'adresse publique côté serveur : externip et localnet sur Asterisk, external_media_address sur PJSIP. Le serveur réécrit alors lui-même le SDP.
• Symmetric RTP, aussi appelé comedia : le serveur ignore l'adresse annoncée et renvoie l'audio vers l'adresse source réelle des paquets reçus.
• STUN (RFC 8489) pour découvrir l'IP publique, TURN (RFC 8656) pour relayer quand le NAT est symétrique, ICE (RFC 8445) pour choisir automatiquement le meilleur chemin. C'est ce que fait WebRTC de série.
• Un SBC en frontal, qui force tous les flux à passer par un point unique et connu.
• Maintenir l'association NAT ouverte : beaucoup de box expirent une association UDP inactive au bout de 30 à 120 secondes, là où la RFC 4787 recommande au moins deux minutes. Un REGISTER avec expires à 120 s, ou un OPTIONS toutes les 30 s, évite que les appels entrants ne se perdent.

Sécurité : le scan du port 5060 et la facture du lundi matin

Exposez un port 5060 sur une IP publique et vous verrez arriver les premières requêtes dans l'heure. L'outil le plus courant, SIPVICIOUS, laisse une trace lisible : un en-tête User-Agent contenant « friendly-scanner ». Le scénario est toujours le même. L'attaquant énumère les extensions, teste des mots de passe faibles (l'extension 200 avec le secret 200, ça existe encore), puis lance des centaines d'appels vers des numéros surtaxés étrangers un vendredi soir. La consommation est détectée le lundi, quand la facture arrive.

Les mesures qui tiennent :

• Refuser les appels non authentifiés : allowguest=no et alwaysauthreject=yes sur chan_sip, pas d'endpoint anonymous sur PJSIP. Sans alwaysauthreject, le serveur répond différemment selon que l'extension existe ou non, ce qui offre l'énumération gratuitement.
• Des secrets aléatoires d'au moins 16 caractères, jamais dérivés du numéro d'extension.
• fail2ban sur les journaux SIP, qui bannit après quelques échecs d'authentification.
• Une limite de canaux simultanés et une liste blanche de destinations : bloquer par défaut l'international et les préfixes surtaxés change l'ordre de grandeur du préjudice.
• SIP sur TLS (5061) plus SRTP pour l'audio, si votre opérateur les propose. Sinon la conversation circule en clair et un tcpdump suffit à la rejouer.
• Restreindre le port 5060 aux plages IP de l'opérateur quand le trunk est fixe, ce qui élimine d'emblée l'essentiel du bruit.

VoIP, ToIP, SIP trunk, WebRTC, VoLTE : ce qui n’est pas la même chose

Les termes circulent comme des synonymes, ils ne le sont pas.

Le contexte français a accéléré la confusion : Orange a arrêté la commercialisation de nouvelles lignes RTC en novembre 2018, et la fermeture technique des lignes existantes se déroule depuis 2023 par lots géographiques. Beaucoup d'installations sont passées en VoIP sans que personne ne le formule ainsi, en gardant le même numéro et le même poste derrière un adaptateur ATA.

• VoIP : la technique de transport de la voix en paquets IP. Rien de plus.
• ToIP (téléphonie sur IP) : le service complet construit dessus, avec IPBX, messagerie vocale, groupes d'appel, journal, supervision.
• Trunk SIP : le lien entre votre IPBX et l'opérateur, qui remplace les anciens accès T0 et T2. C'est un usage de la VoIP, pas un synonyme.
• WebRTC : la pile temps réel des navigateurs. Elle impose ICE et DTLS-SRTP, et ne définit aucune signalisation, chacun met ce qu'il veut au-dessus. La RFC 7118 permet de faire passer du SIP dans un WebSocket pour relier les deux mondes.
• VoLTE et VoWiFi : de la voix sur IP acheminée dans l'IMS de l'opérateur mobile, avec de la signalisation SIP et une qualité de service dédiée sur le réseau radio. Techniquement de la VoIP, commercialement de la téléphonie mobile.
• Applications OTT (WhatsApp, Teams, Meet) : de la voix sur IP à signalisation propriétaire, non joignables depuis un numéro E.164 sans passerelle dédiée.

Questions fréquentes

Quel débit prévoir pour dix appels simultanés ?

En G.711, dix appels représentent environ 0,9 Mbit/s dans chaque sens, en-têtes compris. Le débit brut est rarement le problème : c'est la voie montante qui sature en premier sur un accès asymétrique, et c'est la gigue générée par les autres usages qui dégrade l'audio bien avant que le lien soit plein. Si les postes sont derrière un VPN, ajoutez 15 à 25 %.

J’entends mon correspondant, il ne m’entend pas. D’où ça vient ?

Neuf fois sur dix, d'une traversée NAT mal gérée sur le flux RTP : votre poste annonce une adresse privée dans son SDP et l'audio entrant part dans le vide. Vérifiez d'abord que le SIP ALG de la box est désactivé, puis que le serveur déclare bien son adresse publique (externip ou external_media_address). Une capture avec sngrep -d eth0 port 5060 montre l'adresse annoncée dans le SDP en quelques secondes.

Peut-on appeler le 112 depuis une ligne VoIP ?

Oui, les opérateurs sont tenus d'acheminer les appels d'urgence. La difficulté porte sur la localisation : ce qui est transmis aux secours est l'adresse d'installation déclarée au contrat. Un softphone utilisé depuis un autre site, ou depuis l'étranger, fait donc partir les secours à la mauvaise adresse. Pour un usage nomade, gardez un mobile comme moyen d'appel d'urgence.

Le fax passe-t-il en VoIP ?

Mal, en mode transparent. Les modems fax tolèrent très peu la perte de paquets et le moindre trou coupe la transmission en cours. La méthode fiable est T.38 (RFC 3362), qui démodule le fax et transporte les données de page dans un flux dédié, à condition qu'il soit activé des deux côtés et chez l'opérateur. En G.711 pass-through, désactivez au minimum la suppression de silence et l'annulation d'écho sur la ligne concernée.

Que se passe-t-il en cas de coupure de courant ?

Le téléphone s'arrête. Sur une ligne RTC classique, le poste était alimenté à 48 V par la paire de cuivre et continuait de fonctionner ; en VoIP, il faut alimenter le poste, le commutateur PoE, le routeur et l'accès. Un onduleur couvrant ces quatre équipements est le minimum si la ligne sert à quelque chose de critique, comme un ascenseur ou une alarme.

Testez vos connaissances

À lire aussi

appels wifi · bande passante · box internet · boucle locale