Le protocole SIP, colonne vertébrale de la téléphonie IP en entreprise
Dès qu'une entreprise dépasse quelques dizaines de postes, la question n'est plus de savoir si elle utilise le protocole SIP, mais si elle comprend ce qu'il fait réellement sur son réseau. Le protocole SIP (Session Initiation Protocol) est le mécanisme de signalisation qui établit, modifie et termine chaque appel sur une infrastructure de téléphonie IP.
Dès qu’une entreprise dépasse quelques dizaines de postes, la question n’est plus de savoir si elle utilise le protocole SIP, mais si elle comprend ce qu’il fait réellement sur son réseau. Le protocole SIP (Session Initiation Protocol) est le mécanisme de signalisation qui établit, modifie et termine chaque appel sur une infrastructure de téléphonie IP. Il ne transporte pas la voix (c’est le rôle de RTP et RTCP), mais sans lui, aucun appel ne démarre, aucune session vidéo ne se négocie, aucun transfert ne s’exécute. Comprendre SIP, c’est comprendre le chef d’orchestre silencieux de toute communication unifiée sur réseau IP.
Ce que fait le protocole SIP dans une architecture VoIP
SIP est un protocole de la couche application du modèle OSI, standardisé par l’IETF dans la RFC 3261. Sa fonction est strictement limitée à la signalisation, c’est-à-dire à tout ce qui entoure un échange média sans être le média lui-même. Concrètement, SIP gère la localisation du destinataire sur le réseau, la vérification de sa disponibilité, la négociation des paramètres techniques de la session (codecs audio/vidéo, bande passante), le déclenchement de la sonnerie, puis le maintien et la clôture de la communication.
Cette séparation nette entre signalisation et transport média est ce qui distingue SIP des anciens protocoles monolithiques. Dans une architecture VoIP d’entreprise, SIP s’occupe de la signalisation tandis que RTP achemine les flux voix et vidéo entre les terminaux. Les deux protocoles travaillent en tandem, mais sur des canaux différents, ce qui permet de les sécuriser, de les prioriser et de les router indépendamment.
Le fonctionnement de SIP s’appuie sur un modèle requête/réponse très proche de HTTP, un choix de conception qui explique sa simplicité d’intégration avec les infrastructures web existantes. Les messages SIP sont des paquets texte lisibles (INVITE, ACK, BYE, REGISTER, OPTIONS, CANCEL), transportés par défaut en UDP sur le port 5060 ou en TCP lorsque la fiabilité du transport l’exige. Ce fonctionnement textuel, hérité du protocole HTTP/TCP-IP, facilite le débogage et l’analyse de trafic par les équipes réseau.
La signalisation SIP étape par étape, du INVITE au BYE
Le mécanisme d’établissement d’un appel SIP suit une séquence précise que les administrateurs réseau appellent le handshake SIP. Quand un utilisateur compose un numéro depuis son softphone ou son téléphone IP, son terminal (le User Agent Client) envoie un message INVITE au serveur SIP. Ce message contient l’identité de l’appelant, l’adresse du destinataire et une offre SDP décrivant les capacités média du terminal.
Le serveur SIP répond d’abord par un message 100 Trying, qui signale à l’appelant que la requête est en cours de traitement. Il localise ensuite le destinataire via le Registrar, puis lui transmet l’INVITE. Si le poste du destinataire est disponible, il renvoie un 180 Ringing (c’est la sonnerie), suivi d’un 200 OK lorsque l’utilisateur décroche. L’appelant confirme alors par un ACK, et le flux média RTP s’établit directement entre les deux terminaux.
Le handshake SIP complet (INVITE, 100 Trying, 180 Ringing, 200 OK, ACK) se joue en quelques centaines de millisecondes sur un réseau correctement dimensionné. La fin de la communication est signalée par un message BYE envoyé par l’une des deux parties, suivi d’un 200 OK de confirmation. Toute cette séquence est indépendante du contenu de l’appel, ce qui signifie que le même mécanisme s’applique qu’il s’agisse d’un appel vocal, d’une visioconférence ou d’un partage de documents.
Le tableau ci-dessous récapitule chaque étape du handshake SIP avec le rôle de chaque message.
| Message SIP | Émetteur | Fonction |
|---|---|---|
| INVITE | Appelant (UAC) | Demande d’ouverture de session, contient l’offre SDP |
| 100 Trying | Serveur SIP | Accuse réception, traitement en cours |
| 180 Ringing | Destinataire (UAS) | Le terminal sonne, l’utilisateur est alerté |
| 200 OK | Destinataire (UAS) | L’utilisateur décroche, session acceptée |
| ACK | Appelant (UAC) | Confirmation finale, le flux RTP démarre |
| BYE | L’une des parties | Demande de fin de session |
| 200 OK (final) | Partie opposée | Confirmation de la clôture |
SDP et négociation des codecs entre les terminaux
SIP ne transporte pas seul les paramètres d’un appel. Il s’appuie sur SDP (Session Description Protocol) pour décrire les caractéristiques techniques de la session. Chaque message INVITE embarque un corps SDP qui liste les codecs audio et vidéo supportés par l’appelant (G.711, G.729, Opus, H.264 selon les cas), l’adresse IP et le port RTP sur lesquels le terminal attend le flux média.
Le destinataire répond avec son propre SDP dans le 200 OK, en sélectionnant les codecs communs aux deux parties. Cette négociation SDP/SIP détermine directement la qualité audio de l’appel, car un codec comme G.711 offre une qualité HD mais consomme 87 kbit/s par sens, tandis que G.729 compresse le flux à 32 kbit/s au prix d’une légère dégradation perceptible sur les conférences longues. Le choix du codec a des implications directes sur le dimensionnement de la bande passante et sur les règles de QoS appliquées au réseau.
La compréhension de ce mécanisme SDP est importante pour les équipes qui déploient un système IPBX ou un Centrex, car une incompatibilité de codecs entre le trunk SIP opérateur et les terminaux internes est l’une des causes les plus fréquentes d’appels sans audio (le fameux “one-way audio”).
Les composants d’un serveur SIP et leur rôle dans le réseau
L’expression « serveur SIP » recouvre en réalité plusieurs composants logiques distincts qui peuvent être hébergés sur un même équipement ou distribués à travers le réseau. Chaque composant remplit une fonction précise dans le traitement des requêtes SIP, et la manière dont ils sont agencés détermine la robustesse et l’évolutivité de l’architecture téléphonique.
Le tableau suivant détaille le rôle de chaque composant SIP et sa position dans l’architecture.
| Composant | Rôle | Cas d’usage typique en entreprise |
|---|---|---|
| User Agent (UA) | Terminal qui émet ou reçoit les requêtes SIP, agit comme client (UAC) quand il appelle ou comme serveur (UAS) quand il reçoit | Téléphone IP de bureau, softphone, application mobile |
| Proxy Server | Relaie les requêtes SIP entre les UA, applique les politiques de routage et d’authentification | Routage des appels internes et externes dans un IPBX |
| Registrar Server | Associe l’identité SIP (URI) de chaque terminal à son adresse IP courante via les messages REGISTER | Gestion de la mobilité des postes, hot-desking |
| Redirect Server | Renvoie à l’appelant l’adresse de contact du destinataire sans relayer la requête lui-même | Répartition de charge entre plusieurs sites |
| B2BUA (Back-to-Back User Agent) | Scinde une session SIP en deux appels distincts, ce qui permet un contrôle total sur la signalisation et le média | Session Border Controller (SBC) en bordure de réseau, enregistrement d’appels |
Dans une architecture de téléphonie d’entreprise, le Proxy et le Registrar sont presque toujours intégrés au sein de l’IPBX ou du Centrex cloud, tandis que le B2BUA se retrouve dans les SBC placés en frontière entre le réseau interne et le trunk SIP opérateur. La distinction entre ces composants n’est pas académique : elle conditionne les choix d’architecture, la politique de sécurité et la capacité de l’entreprise à changer d’opérateur sans reconfigurer l’ensemble de son parc.
Port SIP, traversée NAT et configuration réseau
La configuration réseau est le terrain sur lequel la plupart des problèmes SIP se manifestent en entreprise. Un protocole de signalisation qui fonctionne parfaitement en laboratoire peut devenir inutilisable une fois confronté aux pare-feu, aux traducteurs d’adresses (NAT) et aux politiques de filtrage qui protègent le réseau de production.
Port 5060, port 5061 et choix du transport UDP, TCP ou TLS
SIP utilise par défaut le port 5060 pour les échanges en clair (UDP ou TCP) et le port 5061 pour les échanges chiffrés via TLS. Le choix du protocole de transport n’est pas anodin. UDP est le transport historique de SIP parce qu’il est léger et rapide, mais il ne garantit ni la livraison ni l’ordre des paquets. TCP apporte cette fiabilité au prix d’une latence légèrement supérieure lors de l’établissement de la connexion. TLS ajoute le chiffrement de la signalisation, ce qui empêche un attaquant d’intercepter ou de modifier les messages INVITE, REGISTER ou BYE en transit.
En pratique, les déploiements de téléphonie SIP en entreprise privilégient de plus en plus TLS sur le port 5061 pour la signalisation, combiné à SRTP pour le chiffrement du flux média. Cette combinaison est devenue un prérequis dès lors que les communications transitent par l’Internet public, notamment dans les architectures Centrex cloud ou les déploiements multi-sites connectés par VPN.
Le firewall d’entreprise doit être configuré pour autoriser le trafic SIP sur les ports 5060 et/ou 5061 ainsi que la plage de ports RTP utilisée par les terminaux (généralement entre 10000 et 20000). Un filtrage trop restrictif est la première cause de dysfonctionnement SIP après un changement de pare-feu.
Traversée des pare-feu avec STUN, TURN et ICE
Le protocole SIP embarque les adresses IP des terminaux dans le corps de ses messages (via le SDP). Quand un terminal se trouve derrière un NAT (ce qui est le cas de la quasi-totalité des postes en entreprise), l’adresse IP privée qu’il annonce dans le SDP est injoignable depuis l’extérieur. Le flux RTP ne peut alors pas s’établir, et l’appel est muet.
Trois mécanismes complémentaires résolvent ce problème. STUN (Session Traversal Utilities for NAT) permet au terminal de découvrir son adresse IP publique en interrogeant un serveur externe. TURN (Traversal Using Relays around NAT) va plus loin en relayant le flux média à travers un serveur intermédiaire lorsque le NAT est trop restrictif pour un échange direct. ICE (Interactive Connectivity Establishment) orchestre les deux en testant plusieurs chemins de connexion et en sélectionnant le plus efficace.
Un déploiement SIP en entreprise qui ne prévoit pas de mécanisme de traversée NAT, qu’il s’agisse de STUN/TURN/ICE ou d’un SBC en bordure de réseau, produira inévitablement des appels sans audio ou des coupures aléatoires. C’est l’un des premiers points à vérifier lors d’un audit de qualité vocale.
Sécuriser les communications SIP en entreprise
La sécurité SIP se traite sur deux couches distinctes. La signalisation (les messages SIP eux-mêmes) et le média (les flux voix et vidéo transportés par RTP). Protéger l’une sans l’autre revient à verrouiller la porte d’entrée en laissant les fenêtres ouvertes.
TLS (Transport Layer Security) chiffre la signalisation SIP et empêche un attaquant positionné sur le réseau d’intercepter les messages INVITE, de détourner un enregistrement REGISTER ou de modifier un appel en cours. TLS authentifie également le serveur SIP auprès du terminal, ce qui bloque les attaques par usurpation de registrar (SIP spoofing).
SRTP (Secure Real-time Transport Protocol) chiffre les flux média et garantit que le contenu de la conversation reste confidentiel même si un tiers parvient à capturer les paquets RTP. SRTP ajoute aussi un mécanisme d’authentification et de protection contre le rejeu, ce qui empêche la reconstitution d’une conversation à partir de paquets interceptés.
Les deux protocoles fonctionnent ensemble : TLS protège l’échange des clés de chiffrement SRTP qui a lieu dans la signalisation SIP/SDP, puis SRTP prend le relais pour le flux média. Sans TLS, les clés SRTP transitent en clair et le chiffrement du média perd son utilité. Toute architecture de téléphonie d’entreprise qui fait transiter des appels SIP sur Internet ou entre sites distants devrait implémenter TLS + SRTP, et non l’un ou l’autre séparément.
Au-delà du chiffrement, la sécurisation SIP passe aussi par la segmentation réseau avec un VLAN dédié à la voix, le déploiement d’un SBC en bordure pour filtrer les requêtes SIP malformées ou les tentatives de brute-force sur les comptes REGISTER, et une politique de QoS qui isole les flux de signalisation et de média des autres trafics. Une vue d’ensemble de ces mécanismes est détaillée dans notre analyse de la sécurisation de la téléphonie IP.
SIP et téléphonie d’entreprise, du trunk SIP au Centrex cloud
Le protocole SIP est devenu le standard de fait pour toute la téléphonie d’entreprise qui a remplacé les lignes analogiques RTC. Que l’entreprise opère un IPBX sur site, un Centrex hébergé chez l’opérateur ou une téléphonie intégrée à Microsoft Teams, c’est SIP qui assure la signalisation des appels entre l’infrastructure interne et le réseau opérateur.
Le trunk SIP comme passerelle entre l’IPBX et le réseau opérateur
Le trunk SIP est la liaison logique qui connecte le système téléphonique de l’entreprise (IPBX, Centrex) au réseau de l’opérateur télécom. Il remplace les anciennes liaisons T0/T2 Numéris par des canaux SIP qui transitent sur la connexion Internet ou sur un lien dédié. Le trunk SIP dimensionne le nombre d’appels simultanés d’une entreprise, et contrairement aux accès Numéris, ce nombre est ajustable sans intervention physique sur le câblage.
L’avantage opérationnel est direct. Une entreprise qui disposait de deux accès T2 (60 canaux) avec un opérateur unique peut migrer vers un trunk SIP de capacité équivalente, voire supérieure, tout en conservant ses numéros existants par portabilité. Le trunk SIP permet aussi de connecter le système à plusieurs opérateurs simultanément pour la redondance, ou de répartir les appels entre un opérateur principal et un opérateur de secours.
C’est sur ce trunk que le protocole SIP joue pleinement son rôle d’intermédiaire. Chaque appel sortant génère un INVITE qui traverse le SBC de l’entreprise, est authentifié par le trunk SIP opérateur, puis routé vers le réseau public. Chaque appel entrant suit le chemin inverse. La qualité de cette liaison dépend directement de la configuration SIP (codecs négociés, politique de failover, gestion des re-INVITE pour les transferts) et de la capacité du lien réseau sous-jacent, qu’il s’agisse d’une fibre dédiée FTTO ou d’une connexion Internet pro avec QoS.
SIP forwarding et portabilité des numéros vers un nouveau système
Le SIP forwarding (transfert SIP) désigne la capacité d’un terminal ou d’un serveur SIP à rediriger un appel entrant vers une autre destination. Ce mécanisme s’appuie sur les codes de réponse 3xx du protocole (301 Moved Permanently, 302 Moved Temporarily) et sur la fonction de Redirect Server décrite plus haut.
En contexte d’entreprise, le SIP forwarding est utilisé pour la portabilité des numéros lors d’une migration téléphonique, pour le renvoi d’appel vers un mobile ou un softphone, ou encore pour distribuer les appels entre plusieurs sites via un serveur vocal interactif (SVI). La flexibilité du transfert SIP permet à une entreprise de changer de système téléphonique ou d’opérateur sans perdre ses numéros ni interrompre son accueil téléphonique, à condition que la configuration du trunk SIP et du SBC soit correctement planifiée en amont.
Le protocole SIP va en effet bien au-delà de la simple signalisation d’appel. Il permet de gérer des services avancés comme la mise en attente, le transfert accompagné, la conférence à trois ou la supervision de présence, autant de fonctions qui alimentent les solutions de communication unifiées déployées en PME et ETI.
Ce qui distingue le protocole SIP de H.323 et des autres protocoles de signalisation
SIP n’est pas le seul protocole capable de gérer la signalisation d’un appel VoIP. Le protocole H.323, normalisé par l’UIT-T, a longtemps été le standard dominant dans les systèmes de visioconférence et les premiers déploiements de téléphonie IP. La comparaison entre les deux éclaire les raisons pour lesquelles SIP s’est imposé dans la quasi-totalité des architectures modernes.
| Critère | SIP (IETF, RFC 3261) | H.323 (UIT-T) |
|---|---|---|
| Format des messages | Texte (similaire à HTTP), lisible et facile à déboguer | Binaire (ASN.1), compact mais opaque |
| Architecture | Modulaire, chaque composant est indépendant | Monolithique, le gatekeeper centralise les fonctions |
| Négociation média | SDP embarqué dans les messages SIP | Protocole H.245 séparé pour la négociation |
| Extensibilité | Headers personnalisables, intégration native avec les services web | Extension possible mais complexe et rigide |
| NAT traversal | STUN/TURN/ICE, mécanismes standardisés | Traversée NAT plus complexe, nécessite souvent un proxy H.323 |
| Adoption actuelle | Standard de fait pour la téléphonie IP, le Centrex, les trunks opérateurs | Encore présent dans certains systèmes de visioconférence hérités |
Le protocole SIP a supplanté H.323 dans les déploiements de téléphonie d’entreprise en raison de sa légèreté, de sa lisibilité et de sa compatibilité native avec les infrastructures Internet. H.323 reste cependant actif dans certains environnements hospitaliers, industriels ou de vidéosurveillance où des équipements anciens n’ont pas été remplacés. Les entreprises qui opèrent les deux protocoles en parallèle utilisent un SBC pour assurer l’interopérabilité entre les flux SIP et H.323.
La question de l’interopérabilité ne se limite d’ailleurs pas au choix entre SIP et H.323. Au sein même de l’écosystème SIP, les implémentations varient d’un fabricant à l’autre. Un téléphone Yealink et un IPBX Mitel peuvent tous deux se conformer à la RFC 3261 tout en interprétant différemment certains mécanismes comme les re-INVITE, les timers de session ou la gestion des codecs. Tester l’interopérabilité SIP entre les équipements du parc et le trunk SIP opérateur avant la mise en production est une étape que les équipes réseau ne devraient jamais raccourcir.
Protocole SIP, ports, sécurité et téléphonie
Qu’est-ce que le protocole SIP et à quoi sert-il ?
Le protocole SIP (Session Initiation Protocol) est un protocole de signalisation qui établit, modifie et termine les sessions de communication sur un réseau IP. Il gère l’ensemble de la logistique d’un appel VoIP, de la localisation du destinataire à la négociation des codecs, en passant par le déclenchement de la sonnerie, le transfert et le raccroché, sans transporter lui-même la voix, qui est prise en charge par le protocole RTP. SIP est le standard de signalisation utilisé par la quasi-totalité des systèmes de téléphonie IP modernes, des IPBX d’entreprise aux solutions Centrex cloud.
Quel port utilise le protocole SIP ?
SIP utilise le port 5060 pour les communications en clair (UDP ou TCP) et le port 5061 pour les communications chiffrées via TLS. En complément, les flux média RTP empruntent une plage de ports distincte, généralement comprise entre 10000 et 20000, qu’il faut également ouvrir sur le pare-feu. Une erreur fréquente consiste à n’ouvrir que le port 5060 en oubliant les ports RTP, ce qui produit des appels qui se connectent (la signalisation passe) mais sans audio (le média est bloqué).
Quelle est la différence entre SIP et VoIP ?
SIP est un protocole de signalisation, tandis que VoIP désigne l’ensemble des technologies qui permettent de transporter la voix sur un réseau IP. SIP fait partie de l’écosystème VoIP mais n’en est qu’une brique : il gère l’établissement des appels, pas le transport du son. D’autres protocoles comme RTP (transport média), SDP (négociation des paramètres) et SRTP (chiffrement média) complètent SIP dans une architecture VoIP d’entreprise.
Qu’est-ce qu’un serveur SIP ?
Un serveur SIP est un composant réseau qui traite les requêtes de signalisation SIP émises par les terminaux. Il peut remplir plusieurs rôles selon sa configuration : Proxy (routage des requêtes), Registrar (association entre l’identité SIP et l’adresse IP d’un terminal), Redirect (redirection d’appels) ou B2BUA (contrôle avancé des sessions). Dans un environnement d’entreprise, ces fonctions sont généralement intégrées dans l’IPBX ou dans la plateforme Centrex de l’opérateur.
Comment fonctionne un appel SIP ?
Un appel SIP suit une séquence de signalisation appelée handshake : l’appelant envoie un INVITE, reçoit un 100 Trying puis un 180 Ringing, et l’appel s’établit avec le 200 OK suivi d’un ACK. Le flux voix (RTP) ne démarre qu’après cette séquence complète. La fin de l’appel est signalée par un message BYE. L’ensemble du handshake prend quelques centaines de millisecondes sur un réseau d’entreprise correctement dimensionné, ce qui explique pourquoi les appels SIP semblent aussi instantanés que les appels sur ligne fixe classique.
Qu’est-ce qu’un téléphone SIP ?
Un téléphone SIP est un terminal, matériel ou logiciel, qui utilise le protocole SIP pour passer et recevoir des appels sur un réseau IP. Les téléphones SIP matériels (Yealink, Poly, Mitel) se branchent sur le réseau Ethernet de l’entreprise et s’enregistrent auprès du serveur SIP pour recevoir des appels. Les softphones sont la version logicielle de ces terminaux et fonctionnent sur ordinateur ou smartphone. Tous les téléphones SIP partagent le même mécanisme REGISTER/INVITE décrit dans cet article.
Le protocole SIP est-il sécurisé ?
SIP n’est pas chiffré par défaut, mais il le devient lorsqu’il est combiné à TLS pour la signalisation et à SRTP pour le média. Sans ces couches de chiffrement, les messages SIP transitent en clair sur le réseau, ce qui expose les appels à l’interception, au détournement de session et au vol d’identifiants SIP. Les déploiements qui font transiter SIP sur Internet, notamment les trunks SIP opérateurs et les solutions Centrex, devraient systématiquement activer TLS sur le port 5061 et SRTP sur les flux média.
Quelle est la différence entre SIP et H.323 ?
SIP est un protocole texte, modulaire et extensible, tandis que H.323 est un protocole binaire, monolithique et plus rigide. SIP s’est imposé comme le standard de la téléphonie IP d’entreprise grâce à sa simplicité d’intégration avec les infrastructures web et sa capacité d’extension. H.323 reste présent dans certains systèmes hérités, notamment en visioconférence industrielle, mais les nouveaux déploiements l’adoptent rarement. L’interopérabilité entre les deux protocoles est gérée par un SBC en bordure de réseau.