Qu’est-ce que SIP ? Le Session Initiation Protocol expliqué pour les ingénieurs réseau voix

Chaque appel voix IP que vous avez passé, chaque déploiement Microsoft Teams Direct Routing et chaque jonction SIP (SIP trunking) qui a remplacé un ancien circuit PRI repose sur le même protocole. Pourtant, la plupart des explications sur « qu’est-ce que SIP » sont rédigées pour des développeurs d’applications ou des dirigeants, pas pour l’ingénieur qui doit acheminer, sécuriser et dépanner les appels en production. Cet article est la version pour cet ingénieur.

SIP, le Session Initiation Protocol, est le protocole de signalisation qui établit, modifie et libère les sessions de communication en temps réel sur les réseaux IP. C’est le langage que deux téléphones, deux opérateurs ou un téléphone et une plateforme cloud utilisent pour s’accorder sur un appel avant que l’audio ne circule. Dans cet article, nous verrons ce que SIP signifie, d’où il vient, où il se situe par rapport au média, comment SIP identifie les utilisateurs, les composants d’un réseau SIP, et comment les téléphones SIP et les fournisseurs SIP que vous utilisez au quotidien s’intègrent dans l’ensemble.

Que signifie SIP ? Définition du Session Initiation Protocol

SIP signifie Session Initiation Protocol. C’est un protocole de couche applicative, textuel, de type requête-réponse, standardisé par l’IETF dans la RFC 3261. Si vous avez déjà lu un échange HTTP, SIP vous semblera familier : les requêtes ont des méthodes et des en-têtes, les réponses ont des codes de statut numériques, et l’ensemble de la conversation est du texte brut lisible par un humain. Cette conception était délibérée, car les auteurs de SIP l’ont modélisé sur HTTP et SMTP plutôt que sur la signalisation téléphonique traditionnelle.

Le point le plus utile à comprendre d’emblée est ce que SIP ne fait pas. SIP négocie la session, il ne transporte pas la voix. L’audio circule dans un flux média séparé via le Real-time Transport Protocol (RTP), et les détails de ce flux média sont décrits par le Session Description Protocol (SDP) transporté dans les messages SIP. SIP est le plan de contrôle, et RTP est le plan média. Retenez cette distinction, car elle explique presque tout le reste de la construction des réseaux voix.

Deux courts exemples montrent à quoi ressemblent ces messages sur le fil. Un REGISTER lie un utilisateur à l’appareil qu’il utilise actuellement :

REGISTER sip:registrar.biloxi.com SIP/2.0
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Bob <sip:[email protected]>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:[email protected]>
Expires: 7200
Content-Length: 0

Un INVITE démarre une session et propose le média via SDP :

INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 142

Une session SIP est pilotée par un petit ensemble de méthodes de requête. Vous n’avez pas besoin de la séquence complète d’un appel pour comprendre le protocole, juste le vocabulaire :

Les réponses reprennent le modèle HTTP et se répartissent en six classes numériques : 1xx provisoires, 2xx positives et 3xx–6xx négatives. Pour voir comment ces messages s’enchaînent dans un appel réel, consultez notre décryptage du flux d’appel SIP, et pour comprendre la signification pratique de chaque classe de statut, consultez le guide des codes de réponse SIP. Ici, l’essentiel est simplement que SIP est un langage compact de requêtes et réponses avec une poignée de verbes.

Brève histoire de SIP et pourquoi il a remplacé H.323

SIP est apparu comme brouillon IETF à la fin des années 1990, atteignant sa première forme publiée en tant que RFC 2543 en 1999 et sa définition actuelle en tant que RFC 3261 en 2002. À l’époque, le standard dominant pour le multimédia sur IP était H.323, une spécification complète de l’UIT empruntée au monde de la vidéoconférence.

H.323 fonctionnait, mais il était lourd. Il utilisait un encodage binaire illisible sur le fil, il embarquait une pile importante de sous-protocoles, et son extension était lente. SIP a pris le chemin inverse. Parce qu’il était textuel et lisible par un humain, un ingénieur pouvait le déboguer à l’œil nu. Parce qu’il empruntait le modèle requête-réponse de HTTP, il était simple à implémenter et facile à étendre avec de nouveaux en-têtes et de nouvelles méthodes. Parce qu’il utilisait l’adressage de type internet, il s’intégrait naturellement dans un monde déjà bâti sur DNS et IP. Ces propriétés (lisibilité, extensibilité et conception native internet) expliquent pourquoi le protocole SIP est devenu le standard de la VoIP et pourquoi H.323 a rejoint le statut d’héritage.

Ce long parcours mérite d’être respecté lorsque vous construisez une infrastructure voix. TelcoBridges possède plus de 20 ans d’expérience en déploiement SIP derrière ses produits, et la leçon récurrente au fil du temps est que la flexibilité de SIP est aussi sa complication : la même extensibilité qui l’a fait gagner signifie qu’aucun fournisseur ne l’implémente de manière identique.

Où SIP se situe dans la pile : signalisation, SDP et média

Trois protocoles assurent le fonctionnement d’un seul appel voix, et les distinguer clairement est le fondement de tout le reste.

SIP est la signalisation. Il localise l’extrémité distante, la fait sonner, négocie l’appel et le libère. SDP, le Session Description Protocol défini dans la RFC 4566, est transporté dans le corps des messages SIP et décrit le média proposé : quels codecs chaque partie supporte, et les adresses IP et ports où l’audio doit être envoyé. RTP, le Real-time Transport Protocol défini dans la RFC 3550, est le flux qui transporte effectivement la voix numérisée une fois que les deux parties se sont entendues.

Le plan de contrôle (signalisation SIP) et le plan média (audio RTP) circulent en flux séparés. Cliquez pour agrandir.

SIP fonctionne sur UDP ou TCP, conventionnellement sur le port 5060, et sur TLS pour la signalisation chiffrée sur le port 5061. Le média circule en RTP, ou dans sa forme chiffrée SRTP. Parce que signalisation et média sont séparés, un intermédiaire peut lire, acheminer et réécrire le SIP sans jamais toucher à l’audio, ce qui est précisément le rôle des proxys et des contrôleurs de session en bordure (SBC). Les mécanismes de cette séparation, y compris le modèle B2BUA, sont couverts dans notre approfondissement sur les fondamentaux de la signalisation SIP.

Comment SIP identifie les utilisateurs : URI SIP et adresses

SIP emprunte son schéma d’adressage à l’email, c’est pourquoi une adresse SIP y ressemble. Un SIP URI prend la forme sip:[email protected], où la partie avant le @ identifie l’utilisateur et la partie après identifie le domaine ou l’hôte responsable. La variante sécurisée, sips:[email protected], indique que la requête doit circuler sur TLS.

Cette adresse est logique, pas physique. sip:[email protected] indique qui vous essayez de joindre, pas quel appareil ou quelle IP cette personne utilise en ce moment. Le mappage d’une adresse logique vers un emplacement réel est géré par l’enregistrement : un appareil envoie une requête REGISTER à un registrar, liant l’adresse de référence de l’utilisateur à l’adresse de contact actuelle de l’appareil. Lorsqu’un tiers appelle ensuite cet URI, le réseau recherche la liaison et achemine l’appel vers l’endroit où l’utilisateur s’est enregistré. C’est le mécanisme qui vous permet de conserver un seul numéro de téléphone tout en passant d’un téléphone de bureau à un ordinateur portable et à une application mobile.

DNS joue également un rôle important dans l’identification des utilisateurs, car la résolution DNS est ce qui transforme le domaine d’un SIP URI en adresse IP vers laquelle une requête est effectivement envoyée.

Les composants d’un réseau SIP

Un déploiement SIP fonctionnel se compose d’une poignée de rôles coopérants. Vous les construisez rarement tous vous-même, mais vous devez reconnaître chacun d’entre eux lorsque vous lisez un diagramme réseau ou une trace.

Les agents utilisateurs sont les points de terminaison. Le côté qui envoie une requête agit en tant que User Agent Client (UAC) ; le côté qui répond est le User Agent Server (UAS). Un même appareil bascule entre les deux rôles à chaque requête envoyée ou reçue.

Les téléphones SIP et les softphones sont les agents utilisateurs les plus courants. Un téléphone SIP est un appareil matériel de bureau qui parle SIP nativement, tandis qu’un softphone exécute la même logique en tant que client logiciel sur un ordinateur ou un appareil mobile. Les deux s’enregistrent auprès d’un PBX ou d’un fournisseur, puis passent et reçoivent des appels en tant qu’agents utilisateurs SIP ordinaires.

Les registrars et services de localisation suivent l’emplacement actuel de chaque utilisateur, en utilisant le mécanisme REGISTER décrit précédemment.

Les proxys SIP acheminent les requêtes vers leur destination sans terminer la session, en transférant les messages et en consultant la logique de routage en cours de route. Pour une explication ciblée, consultez ce qu’est un proxy SIP.

Les contrôleurs de session en bordure (SBC) se placent à la frontière entre les réseaux, par exemple entre votre réseau et celui d’un opérateur. Un SBC est le point de contrôle qui sécurise, achemine et normalise le SIP lorsqu’il franchit cette frontière, c’est pourquoi il est central dans la voix multi-fournisseurs.

SIP en pratique : jonctions SIP, fournisseurs SIP et téléphones SIP

Dans les déploiements réels, SIP apparaît à trois endroits sur lesquels les ingénieurs posent constamment des questions.

Une jonction SIP est une connexion virtuelle qui transporte les appels SIP entre votre système téléphonique et un fournisseur, remplaçant les circuits physiques PRI ou PSTN de l’ère TDM. Une jonction peut transporter de nombreux appels simultanés, dimensionnée par le nombre de sessions achetées plutôt que par des lignes physiques. L’architecture et la sécurité du SIP trunking font l’objet du guide SIP Trunking et interopérabilité multi-fournisseurs.

Les fournisseurs SIP, également appelés fournisseurs de services de téléphonie internet (ITSP), sont les entreprises qui vendent ces jonctions ainsi que des numéros de téléphone (DID) et la terminaison et l’origination d’appels vers le réseau public. Lorsque vous en évaluez un, les questions qui comptent pour un ingénieur voix sont pratiques : quels codecs sont supportés, si la signalisation et le média chiffrés sont proposés, comment STIR/SHAKEN est géré pour l’authentification des appels, et dans quelle mesure leur implémentation SIP interopère proprement avec votre équipement. Ce dernier point est là où de nombreuses intégrations calent.

Les téléphones SIP en production doivent s’enregistrer, traverser le NAT et idéalement chiffrer leur trafic, en particulier pour les travailleurs à distance connectés depuis l’extérieur du réseau de l’entreprise. Ce sont des problèmes bien compris, mais ce sont des problèmes, et ils sont généralement résolus en périphérie de réseau plutôt que sur le téléphone lui-même.

La raison pour laquelle le SIP multi-fournisseurs fonctionne rarement « tel quel » est que l’extensibilité de SIP joue dans les deux sens. Un fournisseur inclut un en-tête qu’un autre n’attend pas ; un troisième ordonne les en-têtes d’une manière qui casse le parseur d’un quatrième. Différents scénarios SIP existent pour gérer des opérations comme le transfert d’appel, et toutes les implémentations ne supportent pas la gamme complète de ces variantes. Certains fournisseurs exigent également des fonctionnalités DNS avancées qui ne font pas partie de la pile de base. Concilier ces différences s’appelle la normalisation SIP, et c’est le travail quotidien d’un SBC. L’article sur la manipulation des en-têtes SIP explique comment cette normalisation fonctionne au niveau du message.

SIP par rapport aux termes apparentés

Deux comparaisons dissipent la plupart des confusions autour du protocole.

SIP vs VoIP. Voice over IP (VoIP) est le terme générique pour le transport de la voix sur les réseaux IP, et SIP est l’un des protocoles de signalisation qui rend la VoIP possible, de loin le plus courant aujourd’hui. Dire qu’un réseau « utilise la VoIP » décrit ce qu’il fait ; dire qu’il « utilise SIP » décrit comment il établit les appels.

SIP vs VoLTE. VoLTE (Voice over LTE) désigne les appels voix transportés sur un réseau radio 4G/LTE, par opposition à l’ancienne technologie mobile 2G/3G.

SIP vs RTP. C’est à nouveau la distinction contrôle-média : SIP négocie et contrôle la session, tandis que RTP transporte l’audio une fois la session établie. Ils circulent en flux séparés, souvent sur des chemins réseau différents.

Si vous vous intéressez à la communication en temps réel via navigateur, la comparaison connexe est SIP vs WebRTC, qui explique où chaque protocole s’intègre.

Foire aux questions

Conclusion

SIP est le langage de signalisation de la voix sur IP. Il établit, modifie et termine les sessions à l’aide d’un ensemble compact de requêtes et réponses textuelles, tandis que RTP transporte l’audio et SDP décrit le média dans les messages SIP. Autour de ce protocole gravite un petit nombre de rôles coopérants (agents utilisateurs et téléphones SIP, registrars, proxys et contrôleurs de session en bordure) qui ensemble font fonctionner les appels à travers les appareils, les fournisseurs et les opérateurs. Une fois que vous percevez SIP comme le plan de contrôle et que vous reconnaissez ces rôles sur un diagramme, le reste du réseau voix cesse d’être une boîte noire.

Le défi récurrent est que chaque fournisseur parle SIP avec un accent légèrement différent, et concilier ces accents de manière fiable est ce qui transforme une intégration fragile en un réseau de production.