G.711 vs G.729 : comparaison de codecs VoIP

Pratiquement chaque négociation de jonction SIP (SIP trunking), chaque configuration IP-PBX et chaque interconnexion d’opérateur finit tôt ou tard par imposer la même décision : G.711 ou G.729. Ces deux codecs sont les choix par défaut pour la voix numérique sur IP, et ils ont été conçus pour des contextes radicalement opposés. G.711 transporte la voix à une qualité proche du PSTN et consomme 64 kbps par appel avant tout en-tête réseau. G.729 compresse la même parole à 8 kbps grâce à un algorithme prédictif agressif, au prix d’une certaine perte de qualité, d’une charge CPU accrue et d’un long historique de complications liées aux licences.

Cet article propose une comparaison directe : calcul de bande passante, qualité vocale, coût CPU et licences, compatibilité fax et DTMF, et un cadre décisionnel clair pour choisir l’un ou l’autre sur chaque segment d’un réseau réel. Pour le panorama plus large des codecs incluant Opus et AMR, le pilier jonction SIP couvre le contexte élargi. Pour les mécanismes de conversion entre codecs lorsque les deux se retrouvent sur le même appel, l’article Transcodage SBC AMR vers G.711 détaille le plan de transcodage.

La différence d’ingénierie

G.711 et G.729 se situent aux extrémités opposées du compromis bande passante/qualité, et les raisons techniques remontent à l’époque de conception de chaque codec.

G.711 date des années 1970 et a été conçu pour la téléphonie numérique filaire. Il échantillonne la parole à 8 kHz, applique une simple compression logarithmique (A-law ou µ-law) à chaque échantillon et produit un flux constant de 64 kbps. Le calcul est presque trivial : un processeur x86 peut encoder et décoder des milliers de flux G.711 simultanés sans effort, et la conversion entre A-law et µ-law se fait par une simple table de correspondance. La qualité vocale est essentiellement celle d’un appel PSTN filaire.

G.729 date du milieu des années 1990, lorsque la VoIP d’entreprise était acheminée sur des liaisons WAN de 64 kbps ou 128 kbps qui devaient aussi transporter des données. Il échantillonne à la même fréquence de 8 kHz, mais compresse chaque trame de 10 ms en 80 bits grâce à CS-ACELP, pour un débit de 8 kbps. Le codec analyse de courtes fenêtres de parole, modélise le conduit vocal du locuteur sous forme de coefficients de filtre et transmet ces coefficients plus un indice d’excitation au lieu de la forme d’onde elle-même. Le récepteur synthétise la parole à partir de ces paramètres. La compression fonctionne bien pour la voix humaine et mal pour tout le reste, c’est pourquoi G.729 ne peut pas transporter de manière fiable les tonalités de modem fax, la musique d’attente ou le DTMF intrabande.

La référence côté signalisation pour la manière dont chaque codec est proposé et accepté se trouve dans le corps SDP de l’INVITE SIP, défini dans la RFC 4566. La liste des codecs et leur ordre de priorité constituent la base de la négociation, et un SBC a une visibilité complète sur les deux côtés.

Bande passante : les chiffres réels

Le chiffre 64 kbps contre 8 kbps souvent cité ne concerne que la charge utile du codec. La bande passante réelle par appel sur le réseau est plus élevée des deux côtés, car chaque paquet RTP transporte des en-têtes RTP, UDP, IP et Ethernet qui ajoutent le même nombre d’octets quel que soit le volume d’audio contenu.

Avec un ptime typique de 20 ms, le calcul se présente approximativement ainsi. G.711 génère 50 paquets par seconde, chacun transportant 160 octets d’audio plus environ 54 octets d’en-têtes RTP/UDP/IP/Ethernet, pour un total d’environ 85 à 87 kbps par direction. G.729 génère les mêmes 50 paquets par seconde, chacun transportant 20 octets d’audio plus les mêmes 54 octets d’en-têtes, pour un total d’environ 31 kbps par direction. Le ratio de compression de la charge utile est de 8 pour 1, mais sur le réseau il se réduit à environ 2,8 pour 1.

Trois implications en découlent. Premièrement, des valeurs de ptime plus élevées (30 ou 40 ms) réduisent la surcharge d’en-têtes et améliorent le ratio pour les deux codecs, mais elles augmentent aussi le délai de bout en bout en cas de perte de paquet, ce qui compte davantage pour les codecs à faible débit qui disposent de moins de redondance. Deuxièmement, le VAD avec G.729b réduit davantage le débit moyen pendant les silences (souvent de 30 à 50 pour cent), ce qui aide sur les liaisons partagées mais perturbe le fax et certaines invites IVR. Troisièmement, les économies de bande passante de G.729 ne comptent que lorsque la liaison est réellement contrainte. À l’intérieur d’un LAN géré, sur une jonction SIP dédiée correctement dimensionnée, ou sur toute liaison prévue pour la vidéo HD, la différence entre 87 kbps et 31 kbps par appel est rarement le facteur décisif.

Qualité vocale

G.711 offre une qualité vocale proche de la téléphonie filaire avec un MOS d’environ 4,2, ce qui se situe dans la même plage qu’un appel PSTN filaire. G.729 se situe à environ 3,9, ce que la plupart des auditeurs perçoivent comme « bon mais légèrement compressé ». Les consonnes chuchotées perdent en définition, les sibilantes s’adoucissent et la sensation de présence diminue. Personne ne confondra l’appel avec de l’audio haute fidélité, mais la parole conversationnelle reste intelligible.

L’écart compte dans trois situations précises. La première est le transcodage en cascade. Chaque fois qu’un appel est transcodé de G.729 vers G.711 puis inversement, le MOS baisse davantage car la compression avec perte se cumule. Deux passages G.729 vers G.711 dans le même chemin d’appel poussent la qualité perçue nettement en dessous de l’un ou l’autre codec seul, c’est pourquoi les architectes réseau cherchent à minimiser le nombre de points de transcodage sur un itinéraire donné. La deuxième est l’audio large bande. G.729 limite l’appel à un échantillonnage de 8 kHz quel que soit ce dont chaque terminal est capable, de sorte qu’un client Microsoft Teams ou WebRTC qui pourrait autrement offrir du Opus large bande sonnera en bande étroite à travers un segment G.729. La troisième concerne la parole bruitée ou sous contrainte. CS-ACELP est optimisé pour la voix propre ; le bruit de fond, les locuteurs simultanés et la parole émotionnelle ou criée se dégradent plus fortement avec G.729 qu’avec G.711.

Si la qualité vocale est le KPI principal d’un déploiement (conférences de direction, enregistrement en centre de contact, analyse d’appels commerciaux), G.711 l’emporte par défaut. Si la bande passante est la contrainte déterminante, la baisse de MOS avec G.729 est un compromis connu et gérable.

CPU, licences et où se cache le coût

G.711 est effectivement gratuit tant en termes de CPU que de licences. Le codec est une recommandation publique de l’UIT-T sans encombrement de brevets, chaque PBX et SBC commercial le prend en charge nativement, et un processeur moderne encode des milliers de flux simultanés sans dépasser 5 pour cent d’utilisation.

G.729 a une histoire plus complexe. Le codec a été protégé par des brevets pendant des années, avec des redevances dues à Sipro Lab Telecom et d’autres détenteurs. Les brevets ont commencé à expirer en 2017 et le codec est devenu effectivement libre de redevances, ce qui a incité plusieurs projets open source à ajouter la prise en charge native de G.729. La réalité commerciale n’a pas entièrement suivi. De nombreux fournisseurs de PBX d’entreprise (Cisco, Avaya, et d’autres) facturent toujours des licences G.729 par canal, en partie comme revenus hérités et en partie parce que les cartes DSP matérielles conservent des conditions de licence par canal. Le résultat est que le coût par appel de G.729 sur un déploiement PBX géré est souvent dominé par la licence, et non par le CPU ou la bande passante.

Le coût CPU du codec lui-même est réel mais modeste sur du matériel moderne. L’encodage/décodage G.729 purement logiciel est viable pour des centaines de flux simultanés sur un cœur x86 standard. À l’échelle opérateur, cependant, l’accélération DSP matérielle reste le choix par défaut car une latence prévisible par canal compte davantage que le débit de pointe. ProSBC s’associe à TSBC-HW-TRANS pour le transcodage G.729 accéléré matériellement lorsqu’un déploiement nécessite le codec à grande échelle ; le transcodage logiciel G.729 au sein de ProSBC est prévu dans la feuille de route produit pour fin 2026.

Fax, DTMF et compatibilité modem

La manière la plus claire de résumer cette section est que G.711 est compatible avec le fax et G.729 est fatal pour le fax. CS-ACELP modélise la parole, pas les tonalités de signalisation, et dès qu’une poignée de main T.30 de fax atteint un codec G.729, les tonalités modem sont irrécupérables. Tout chemin d’appel transportant du fax doit soit rester en G.711 de bout en bout avec les conditions de passthrough respectées (annulation d’écho désactivée, VAD désactivé, perte de paquets quasi nulle), soit basculer vers le relais T.38 au niveau du SBC. L’article Fax sur IP et T.38 couvre les mécanismes de relais en détail.

Le DTMF présente une situation parallèle. Le DTMF intrabande transporté comme audio survit à G.711 mais pas à G.729. La solution est RFC 2833 (désormais RFC 4733), qui transporte le DTMF sous forme d’événements RTP nommés en dehors du flux audio. La plupart des terminaux SIP modernes négocient RFC 2833 par défaut, mais les IVR hérités et certains types de jonctions PBX émettent encore du DTMF intrabande qu’un SBC doit détecter et convertir. Si G.729 est dans le chemin, RFC 2833 est obligatoire.

Le trafic modem et TTY présente la même contrainte. Les données vocales en bande de base de tout type nécessitent G.711, sous peine de ne pas survivre à la compression.

Quand utiliser chacun : un cadre décisionnel

Le choix se fait généralement de lui-même une fois le réseau cartographié honnêtement. Le schéma qui s’applique à la plupart des déploiements est simple.

À l’intérieur d’un LAN géré, sur une jonction SIP dédiée dimensionnée pour la charge d’appels, sur une connexion UCaaS via un WAN sain, ou sur tout segment où la bande passante n’est pas la contrainte déterminante, G.711 est le choix par défaut. La qualité est supérieure, le CPU est moins coûteux, l’interopérabilité fax et DTMF est automatique, et la licence est gratuite. Les économies de bande passante de G.729 ne justifient pas les compromis lorsque le lien est suffisamment large.

G.729 conserve sa place sur trois types de liaisons. Les segments WAN contraints, typiquement des bureaux distants reliés au siège par des circuits partagés de 1 à 4 Mbps où chaque 50 kbps de marge vocale compte ; le backhaul mobile, satellite ou maritime où la bande passante est facturée au volume ou véritablement limitée ; et les interconnexions opérateur héritées où le fournisseur en amont ne propose que G.729 sur une route de terminaison donnée. Dans chacun de ces cas, la bande passante économisée est significative, les problèmes de fax et de DTMF sont gérés avec T.38 et RFC 2833, et la baisse de qualité perceptible est acceptable pour le cas d’usage.

Le terrain intermédiaire plus délicat concerne les plateformes PBX hébergées à haute densité ou les centres de contact où les clients sont répartis sur un mélange de types de réseaux. La bonne réponse dans ce cas est rarement un choix de codec unique pour la plateforme ; c’est une politique de codec par client ou par jonction appliquée au niveau du SBC.

Réseaux mixtes et rôle du SBC

La plupart des réseaux réels utilisent les deux codecs. Un opérateur nord-américain livre du G.711 µ-law à un client, un opérateur européen propose du A-law à un autre, un bureau distant contraint utilise G.729, et un tenant Microsoft Teams Direct Routing négocie Opus ou Silk sur son segment. Le SBC est le seul élément réseau disposant du contrôle média par segment, de la visibilité SDP et des mécanismes de politique nécessaires pour assurer la médiation proprement entre tous.

Trois fonctions du SBC comptent pour la politique de codec. La première est la négociation de codec par segment via la réécriture SDP : le SBC peut proposer un codec à l’opérateur et un autre au PBX, puis faire le pont entre les deux avec du transcodage au milieu. La deuxième est la configuration de codec par NAP, où chaque groupe de jonctions porte sa propre liste de codecs préférés, sa liste de repli et ses règles de mise en paquets, le tout appliqué à la frontière sans que ni l’un ni l’autre terminal n’ait besoin de savoir ce que fait l’autre. La troisième est la capacité de transcodage elle-même. Le transcodage logiciel au sein de ProSBC gère la conversion G.711 A-law vers µ-law en natif, ce qui couvre le cas d’interopérabilité Amérique du Nord/Europe le plus courant. Le transcodage matériel DSP via TSBC-HW-TRANS couvre G.729, AMR et l’ensemble complet des codecs complexes à l’échelle opérateur.

Les mécanismes détaillés de la manière dont un SBC B2BUA négocie et convertit réellement les codecs entre segments sont couverts dans l’article Transcodage SBC AMR vers G.711. La décision qui se pose à l’architecte est de savoir quel codec appliquer sur chaque NAP. Le SBC est le moyen par lequel cette décision devient réalité sur le réseau.

Foire aux questions

Conclusion

La décision G.711 contre G.729 est rarement aussi serrée qu’elle ne le paraît sur le papier. G.711 l’emporte sur la qualité, le CPU, les licences, l’interopérabilité fax et la fiabilité DTMF, et la différence de bande passante (87 kbps contre 31 kbps par appel sur le réseau) ne compte que lorsque la liaison est réellement contrainte. G.729 conserve sa place sur les segments WAN étroits, le backhaul mobile et les interconnexions opérateur héritées où l’économie de bande passante est réelle. Le problème le plus difficile dans la plupart des réseaux n’est pas de choisir un codec, c’est d’appliquer une politique de codec cohérente par segment à travers un réseau où les deux finissent par être en jeu. C’est le rôle du SBC, et la politique par NAP à la frontière est le point où la décision devient opérationnelle.