Qu’est-ce qu’un proxy SIP ? Architecture, B2BUA vs. proxy et interopérabilité SIP en entreprise

Votre centre de données héberge un PBX Cisco, un centre de contacts Avaya sur un sous-réseau distinct et un opérateur de jonction SIP (SIP trunking) dans le nuage qui parle un dialecte SIP légèrement différent des deux autres. La recherche d’un « proxy SIP » capable de faire communiquer ces systèmes de manière fiable est le point de départ de nombreux déploiements SIP, et c’est souvent là que les ingénieurs découvrent qu’un proxy SIP allégé n’est pas le bon outil.

Un proxy SIP, au sens strict de la RFC 3261, est un serveur qui achemine les requêtes SIP vers leur destination sans terminer la session d’appel. Il s’insère dans le chemin de signalisation, décide où router les requêtes et les transmet ; il ne renégocie pas la configuration de l’appel, ne réécrit pas les en-têtes pour assurer la compatibilité entre vendeurs, et ne contrôle pas le chemin des médias. Dans un environnement homogène à fournisseur unique, cette transparence est précisément ce dont vous avez besoin. Dans les environnements multi-vendeurs et multi-opérateurs qui caractérisent la plupart des déploiements en entreprise et chez les opérateurs, il vous faut un équipement capable d’intervenir réellement.

Cette page couvre l’architecture des proxy SIP, les différences fondamentales entre un proxy et un Back-to-Back User Agent (B2BUA), la place de chacun dans un réseau réel, et pourquoi la majorité des interconnexions opérateurs et des déploiements SIP en entreprise nécessitent les capacités complètes d’un contrôleur de session en bordure (SBC).

Fonctionnement d’un proxy SIP

Un proxy SIP est un intermédiaire réseau qui achemine les messages de signalisation SIP entre les agents utilisateurs (UA : téléphones, softclients, systèmes PBX et tout terminal SIP). Sa mission principale consiste à résoudre un URI SIP en adresse réseau et à transmettre la requête un saut plus près de la destination.

Le proxy ajoute un en-tête Via à chaque requête SIP qu’il traverse, en enregistrant son adresse dans le chemin de signalisation. Les réponses de l’appelé remontent la même chaîne d’en-têtes Via, chaque proxy supprimant sa propre entrée au passage. Cela crée un chemin de signalisation traçable et réversible, sans que le proxy n’ait à maintenir d’état sur l’appel lui-même.

Proxy sans état et proxy avec état

Un proxy sans état traite chaque message SIP de façon isolée. Il lit l’URI de requête, applique la logique de routage, transmet le message et l’oublie. Il n’y a pas d’état de transaction, pas d’enregistrement d’appel, pas de corrélation entre une requête et sa réponse. Les proxy sans état sont rapides et scalables horizontalement, mais incapables d’accomplir quoi que ce soit nécessitant une vision globale de l’appel : ni forking, ni authentification, ni routage de secours.

Un proxy avec état suit les transactions SIP (l’échange complet d’une requête et de ses réponses) et, optionnellement, le dialogue (l’intégralité de l’appel de l’INVITE au BYE). Cela lui permet d’effectuer du forking parallèle (envoi d’un INVITE vers plusieurs destinations simultanément), un reroutage authentifié et une répartition de charge rudimentaire. La plupart des infrastructures SIP en production utilisent des proxy avec état lorsque des proxy sont employés.

Ce que ni les proxy sans état ni les proxy avec état ne peuvent faire : modifier le corps SDP pour changer les préférences de codecs, réécrire les en-têtes SIP pour pallier les incompatibilités entre vendeurs, terminer le chemin des médias pour appliquer le chiffrement, ou masquer la topologie du réseau interne vis-à-vis des parties externes.

Flux d’appel d’un proxy SIP : la signalisation transite par le proxy via les en-têtes Via, tandis que les médias RTP circulent directement entre les terminaux. Le proxy ne touche pas au chemin des médias.

Le modèle de transmission : Via, Route et Record-Route

Trois en-têtes SIP définissent la participation des proxy à une session :

Via est le mécanisme de traçage. Chaque proxy ajoute son adresse (et un paramètre de branche unique) à l’en-tête Via à l’aller ; les réponses suppriment les entrées Via dans l’ordre inverse. C’est ainsi qu’une réponse sait où aller.

Route est une instruction de routage préchargée : une liste d’adresses de proxy que la requête doit traverser, consommée une à une.

Record-Route permet à un proxy avec état de s’insérer dans le dialogue en cours. En s’ajoutant à l’en-tête Record-Route, le proxy s’assure qu’il verra toutes les requêtes ultérieures du même dialogue, restant ainsi dans le chemin de signalisation pour toute la durée de l’appel. Un proxy qui n’ajoute pas Record-Route ne verra que l’INVITE initial, pas les re-INVITE en cours d’appel ni le BYE.

Aucun de ces mécanismes ne donne au proxy la capacité de modifier le contenu des requêtes. Ils gouvernent le routage, pas le contenu.

B2BUA vs. proxy SIP : différences architecturales fondamentales

Un Back-to-Back User Agent adopte une approche fondamentalement différente. Plutôt que de transmettre les requêtes, un B2BUA termine le dialogue SIP en provenance de l’appelant en agissant comme User Agent Server (UAS), puis crée un nouveau dialogue SIP vers l’appelé en agissant comme User Agent Client (UAC). Les deux branches sont entièrement indépendantes. Le B2BUA peut tout modifier : les en-têtes SIP, l’offre SDP, la liste de codecs, le protocole de transport, le chemin des médias.

Cette différence architecturale a des conséquences importantes sur ce que l’équipement peut ou ne peut pas faire.

Ce qu’un B2BUA peut faire qu’un proxy ne peut pas

Parce qu’un B2BUA termine et recrée les sessions, il dispose d’une visibilité et d’un contrôle complets sur les deux branches de signalisation. Cela permet :

La manipulation d’en-têtes SIP couvre l’ajout, la modification ou la suppression de tout champ d’en-tête SIP. En pratique, cela signifie normaliser des implémentations incompatibles entre vendeurs : convertir un format d’en-tête SIP propre à Cisco en un format accepté par un système Avaya, ou supprimer des en-têtes propriétaires qu’une jonction SIP opérateur rejette.

Le masquage de la topologie s’applique ainsi : dans un proxy SIP, les en-têtes de l’appelant reflètent les adresses réseau internes réelles. Un B2BUA remplace toutes les adresses internes par sa propre adresse externe, dissimulant entièrement la topologie interne. C’est une exigence de sécurité pour tout déploiement face à un opérateur ou à Internet.

La renégociation de codecs intervient lorsque deux terminaux proposent des listes de codecs incompatibles dans leur SDP. Le B2BUA peut modifier l’échange offre/réponse SDP pour négocier un codec accepté des deux côtés, ou déclencher le transcodage si aucun codec commun n’existe.

L’ancrage des médias permet au B2BUA de se placer dans le chemin des médias, en acceptant et en retransmettant les paquets RTP. Cela rend possible le chiffrement/déchiffrement SRTP, la conversion RTP vers SRTP, l’enregistrement des médias et le scoring de qualité MOS.

Le compromis : complexité contre contrôle

Un proxy SIP est plus simple à déployer et génère une charge de traitement moindre par appel, ce qui le rend adapté au routage interne à fort volume dans un environnement homogène. Un B2BUA implique une charge de traitement et un état supplémentaires par appel, ainsi qu’une configuration plus étendue. En contrepartie, il fournit la surface de contrôle nécessaire pour faire fonctionner des réseaux SIP hétérogènes.

Pour tout déploiement exposé à Internet ou à un opérateur, le modèle B2BUA n’est pas optionnel. Le modèle proxy ne peut tout simplement pas satisfaire aux exigences de sécurité et d’interopérabilité.

Normalisation SIP : le problème qu’un proxy ne peut pas résoudre

La norme SIP (RFC 3261 et ses compléments) définit le protocole. Elle n’impose pas à chaque vendeur d’implémenter chaque fonctionnalité de la même façon. En pratique, deux systèmes se réclamant tous deux de la conformité SIP seront fréquemment en désaccord sur le formatage des en-têtes, l’ordre des codecs dans le SDP, la méthode de signalisation DTMF, le comportement UPDATE vs. re-INVITE, la gestion des temporisateurs de session, et des dizaines d’autres détails.

Incompatibilités SIP courantes en environnement multi-vendeurs

Les problèmes d’interopérabilité suivants sont rencontrés dans des réseaux voix en production :

Signalisation DTMF. Certains terminaux envoient les chiffres DTMF en audio intrabande (RFC 2833 / RFC 4733 dans le flux RTP). D’autres utilisent des messages SIP INFO. D’autres encore recourent à une signalisation hors bande via le format telephone-event du SDP. Lorsque deux systèmes utilisent des méthodes différentes, les tonalités DTMF sont perdues, ce qui détruit les fonctionnalités IVR, l’accès à la messagerie vocale et la conférence.

Ordre des codecs. Une offre SDP liste les codecs par ordre de priorité. Certains vendeurs exigent que le premier codec de la liste soit celui qu’ils préfèrent ; d’autres choisissent le codec commun de meilleure qualité quelle que soit sa position. Un désaccord sur l’ordre des codecs peut entraîner la sélection d’un codec sous-optimal, dégradant la qualité des appels d’une manière difficile à diagnostiquer.

Formatage des en-têtes Via et Contact. Certains PBX ajoutent des paramètres supplémentaires dans les en-têtes Via ou Contact que les jonctions SIP opérateurs rejettent comme malformés. D’autres suppriment des paramètres requis. Dans les deux cas, les appels échouent, ou échouent de façon intermittente selon le chemin emprunté.

Temporisateurs de session. La RFC 4028 définit des temporisateurs de session pour détecter les appels bloqués. Tous les terminaux ne les prennent pas en charge, et les différentes implémentations des valeurs Session-Expires entrent en conflit. Un B2BUA peut normaliser le comportement des temporisateurs sur les deux branches.

En-têtes P-Asserted-Identity (PAI). Les en-têtes d’identité de l’appelant varient considérablement selon les vendeurs et les opérateurs. Un B2BUA peut les normaliser pour assurer la compatibilité STIR/SHAKEN, en veillant à ce que les informations d’identité correctes soient présentées au niveau de l’attestation.

Moteur de manipulation d’en-têtes SIP

La solution aux problèmes ci-dessus est un moteur de manipulation d’en-têtes SIP : un système à base de règles qui définit, pour chaque branche d’appel ou groupe de jonctions, exactement quels en-têtes sont ajoutés, modifiés ou supprimés au passage des appels. Les règles de manipulation s’appliquent indépendamment aux messages SIP entrants et sortants, permettant des traitements spécifiques à chaque vendeur de chaque côté du B2BUA.

C’est la fonction de normalisation centrale qui fait d’un SBC B2BUA l’équipement adapté aux environnements multi-vendeurs. Sans elle, chaque incompatibilité entre vendeurs nécessite un contournement par règle de pare-feu, une modification de configuration sur le système du vendeur, ou un appel qui ne fonctionne tout simplement pas.

Normalisation B2BUA par un SBC : le trafic de la jonction SIP opérateur est entièrement terminé et recréé, avec réécriture des en-têtes, normalisation des codecs et masquage de la topologie appliqués avant la livraison aux terminaux d’entreprise.

Les proxy SIP dans les architectures opérateurs et entreprises

En pratique, les proxy SIP apparaissent dans les réseaux en production, mais dans des rôles spécifiques où leurs limites sont acceptables.

Cas d’usage des proxy SIP :

• En tant que frontal de registrar SIP, distribuant les requêtes REGISTER vers un pool de serveurs d’enregistrement
• En tant qu’équilibreurs de charge internes entre un cluster de serveurs d’application identiques dans une plateforme homogène (tous exécutant le même logiciel, le même vendeur, le même profil de codecs)
• En tant que couches de résolution DNS SIP dans les plateformes opérateurs à grande échelle, où la décision de routage est une pure translation d’adresse sans modification de contenu

Limites des proxy SIP :

• Toute interconnexion opérateur-entreprise, où la jonction SIP opérateur parle un dialecte SIP différent du PBX d’entreprise
• Tout déploiement exigeant TLS pour la signalisation SIP, ce qui requiert de terminer la session TLS et d’en recréer une, exactement ce qu’un proxy ne fait pas
• Tout déploiement nécessitant le chiffrement des médias SRTP, qui exige l’ancrage des médias
• Tout déploiement exposé aux attaques DoS/DDoS : un proxy sans état n’offre aucune protection et transmet le trafic d’inondation aussi volontiers que le trafic légitime

Le contrôleur de session en bordure est la classe d’équipements définie spécifiquement pour répondre à ces exigences en bordure de réseau. Un SBC utilise l’architecture B2BUA en interne et y ajoute des couches de sécurité, de contrôle d’accès, de gestion de la topologie et de normalisation.

Pour une présentation détaillée de la façon dont les SBC se connectent aux jonctions opérateurs, consultez le guide SBC et jonction SIP. Pour approfondir les capacités de sécurité au niveau de la couche SIP, rendez-vous sur le pilier Sécurité VoIP.

Enregistrement SIP et authentification

Les proxy SIP et les SBC gèrent l’enregistrement SIP différemment, et cette différence a des implications importantes pour la sécurité et l’exploitation.

Un registrar SIP est l’entité qui accepte les requêtes REGISTER et mappe un AOR SIP (Address of Record, un URI SIP de la forme [email protected]) à une adresse de contact (l’adresse IP actuelle du terminal). Dans les déploiements classiques, le registrar est une fonction serveur distincte, souvent colocalisée avec un proxy.

Un SBC à architecture B2BUA peut effectuer le transfert d’enregistrement SIP : accepter les requêtes REGISTER des terminaux, les transmettre en amont vers le registrar de l’opérateur et maintenir localement le mappage d’enregistrement. Le SBC dispose ainsi d’une visibilité complète sur l’état d’enregistrement de chaque terminal derrière lui, sans modification du registrar amont.

Plus important encore, un SBC peut assurer la protection contre le balayage d’enregistrement SIP : détecter les attaques par inondation d’enregistrements, les tentatives automatisées de force brute sur les identifiants par envoi massif de requêtes REGISTER, et les bloquer à la frontière avant qu’elles n’atteignent le registrar ou le PBX. Un proxy SIP allégé n’a aucun mécanisme pour distinguer une inondation d’enregistrements du trafic légitime ; il transmet les deux sans distinction.

Ces exigences ne sont pas des cas limites. Le balayage d’enregistrement SIP est l’un des vecteurs d’attaque les plus courants contre les infrastructures SIP exposées à Internet. Tout équipement situé en bordure de réseau doit s’en protéger activement.

Proxy SIP dans le contexte de Microsoft Teams Direct Routing

Microsoft Teams Direct Routing est le mécanisme qui connecte les utilisateurs de Teams Phone au réseau téléphonique commuté public (PSTN) via une jonction SIP gérée par le client. Microsoft impose que l’équipement raccordant Teams à la jonction SIP soit un contrôleur de session en bordure certifié, non un proxy SIP.

Les raisons sont directes. Teams exige :

• TLS pour la signalisation SIP sur les deux branches, côté Teams et côté opérateur. Terminer une session TLS suppose que l’équipement agisse comme point de terminaison TLS, ce qu’un proxy transparent ne peut pas faire. Un SBC B2BUA termine TLS sur les deux branches de façon indépendante.
• SRTP pour le chiffrement des médias sur la branche Teams. Cela requiert l’ancrage des médias, uniquement possible avec un B2BUA.
• La normalisation SIP entre le dialecte SIP de Teams et celui de la jonction SIP opérateur. L’implémentation SIP de Teams comporte des exigences spécifiques en matière d’en-têtes que la plupart des jonctions SIP opérateurs ne satisfont pas nativement.
• La traversée NAT et le masquage de la topologie, pour que les adresses réseau internes ne soient pas divulguées dans le chemin de signalisation Teams.

Un proxy SIP ne satisfait aucune de ces exigences. Microsoft teste les SBC sur l’ensemble des exigences SIP de Teams : gestion des en-têtes, support des codecs, DTMF, comportement d’enregistrement et conformité TLS/SRTP. Pour en savoir plus sur la façon dont ProSBC se connecte à Microsoft Teams Direct Routing, consultez notre page produit.

Questions fréquentes

Quelle est la différence entre un proxy SIP et un contrôleur de session en bordure ?

Un proxy SIP transmet les requêtes SIP sans terminer la session d’appel. Il ne peut pas modifier les en-têtes SIP pour la normalisation entre vendeurs, appliquer le chiffrement des médias ni masquer la topologie du réseau interne. Un contrôleur de session en bordure (SBC) utilise une architecture B2BUA pour terminer et recréer entièrement les branches de signalisation et de médias. Cela lui confère un contrôle complet sur la manipulation d’en-têtes, la négociation de codecs, le chiffrement des médias (SRTP), le masquage de la topologie, la protection DoS/DDoS et le contrôle d’accès, autant d’exigences obligatoires à toute interface opérateur ou en bordure d’un réseau multi-vendeurs.

Un proxy SIP peut-il gérer l’interopérabilité SIP multi-vendeurs ?

Les proxy SIP allégés conviennent aux environnements homogènes à fournisseur unique. L’interopérabilité multi-vendeurs (où un PBX Cisco, un système Avaya et une jonction SIP opérateur implémentent différemment les en-têtes SIP, le DTMF et la négociation de codecs) exige un SBC B2BUA doté d’un moteur de manipulation d’en-têtes SIP capable de normaliser le trafic de chaque vendeur indépendamment.

Microsoft Teams Direct Routing nécessite-t-il un SBC ou un proxy SIP ?

Microsoft Teams Direct Routing exige un contrôleur de session en bordure certifié. Un proxy SIP ne peut pas terminer des sessions TLS, ancrer des médias SRTP ni effectuer la normalisation SIP entre Teams et les jonctions SIP opérateurs que valide le programme de certification de Microsoft. Microsoft publie une liste de vendeurs de SBC certifiés pour Teams Direct Routing.

Qu’est-ce qu’un B2BUA ?

Un Back-to-Back User Agent (B2BUA) est une entité SIP qui agit à la fois comme User Agent Server (UAS) sur la branche entrante et comme User Agent Client (UAC) sur la branche sortante. Il termine le dialogue SIP de l’appelant et crée un nouveau dialogue vers l’appelé. Contrairement à un proxy SIP, le B2BUA contrôle entièrement les deux branches, ce qui lui permet de réécrire les en-têtes SIP, de renégocier les codecs, d’ancrer les médias et d’appliquer le chiffrement indépendamment de chaque côté.

Quand utiliser un proxy SIP plutôt qu’un SBC ?

Un proxy SIP convient au routage interne dans un environnement à fournisseur unique où tous les terminaux parlent le même dialecte SIP et où les frontières de sécurité, la normalisation des en-têtes, le contrôle des médias et la protection DoS ne sont pas requis. Tout déploiement exposé à Internet, à une jonction SIP opérateur ou à un environnement multi-vendeurs nécessite les capacités B2BUA complètes d’un SBC.

À quoi sert un serveur proxy SIP dans les réseaux d’entreprise ?

Dans les réseaux d’entreprise, un serveur proxy SIP gère le routage d’appels interne entre terminaux partageant la même implémentation SIP. Il résout les URI SIP en adresses réseau, distribue les enregistrements et peut effectuer une répartition de charge basique sur un cluster de serveurs identiques. Il ne fournit pas la normalisation des en-têtes, le chiffrement des médias ni l’application des politiques de sécurité nécessaires aux frontières du réseau. Pour le trafic inter-vendeurs ou face à un opérateur, un SBC remplace ou complète le proxy.

Un proxy SIP est-il la même chose qu’une passerelle SIP ?

Non. Un proxy SIP achemine la signalisation SIP entre terminaux SIP sans conversion de protocole. Une passerelle SIP convertit entre SIP et un protocole ou type de réseau différent, tel que PSTN/TDM, H.323 ou WebRTC. Un SBC combine un routage comparable à celui d’un proxy avec une translation de protocole comparable à celle d’une passerelle, et y ajoute la sécurité au niveau des sessions, ce qui en fait l’équipement de référence aux frontières du réseau où routage et conversion sont tous deux nécessaires.

Un proxy SIP peut-il effectuer de la répartition de charge ?

Un proxy SIP avec état peut distribuer les requêtes INVITE vers plusieurs destinations en utilisant un round-robin, une distribution pondérée ou une sélection par priorité. Il ne peut toutefois pas effectuer de répartition de charge sensible à la session (routage basé sur le nombre d’appels en cours, les métriques de qualité ou l’état de santé des terminaux), car il ne maintient pas d’état de session au-delà du niveau transactionnel. Pour une distribution sensible à la session, le moteur de routage d’un SBC offre un contrôle plus fin.

Conclusion

Les proxy SIP sont un composant fondamental de l’architecture SIP, mais leur rôle est précisément délimité. Ils acheminent des requêtes. Ils ne terminent pas les sessions, ne modifient pas le contenu, ne protègent pas les réseaux et ne normalisent pas des implémentations incompatibles. Dans les environnements où ces limitations n’ont pas d’importance (réseaux internes homogènes, plateformes à fournisseur unique, niveaux de routage pur), ils fonctionnent bien. Dans les environnements qui constituent la majorité des déploiements voix réels, ils ne suffisent pas.

Les interconnexions opérateurs, Microsoft Teams Direct Routing, la voix d’entreprise multi-vendeurs, l’intégration de plateformes CPaaS et tout déploiement soumis à un trafic exposé à Internet nécessitent la surface de contrôle complète d’un contrôleur de session en bordure B2BUA : manipulation d’en-têtes SIP, masquage de la topologie, ancrage et chiffrement des médias, protection DoS/DDoS et contrôle d’accès pour tout appliquer.

Au-delà du rôle de transmission du proxy SIP, le SBC s’étend dans des territoires inaccessibles au modèle proxy : les bordures de réseaux complexes, multi-vendeurs et face aux opérateurs, où normalisation, sécurité et contrôle total des sessions sont obligatoires.