SIP et voix pour les équipes de messagerie

Le protocole SIP (Session Initiation Protocol, RFC 3261 ) est le protocole de signalisation de la couche application qui crée, modifie et met fin aux sessions multimédias en temps réel sur IP , généralement pour la voix et la vidéo. Point essentiel, SIP ne transporte pas le flux multimédia lui-même : il négocie et contrôle la session, et l’audio ou la vidéo transite ensuite séparément via RTP .

Sa conception s'inspire délibérément du protocole HTTP — messages texte lisibles, méthodes de requête, codes de réponse à trois chiffres et adressage URI (sip:alice@example.com) —, ce qui la rend accessible aux équipes maîtrisant déjà les protocoles web. C'est pourquoi la voix s'intègre naturellement à la messagerie dans une plateforme CPaaS : il s'agit d'un autre canal piloté API , reposant sur une structure requête/réponse familière.

Les principaux acteurs sont les agents utilisateurs (un agent utilisateur qui envoie des requêtes et un agent utilisateur qui y répond), ainsi que l'infrastructure : les serveurs d'enregistrement enregistrent où un utilisateur est joignable et les serveurs proxy acheminent les requêtes vers lui. Pour une équipe de messagerie, la voix est le plus souvent le canal de secours pour les mots de passe à OTP et le canal d'alerte urgente ; comprendre SIP revient donc à comprendre comment ce canal est réellement établi.

SIP définit un ensemble restreint de méthodes de requête. INVITE initie ou modifie une session, ACK confirme la réponse finale à une INVITE et BYE met fin à un appel établi. REGISTER indique à un serveur d'enregistrement où un utilisateur est joignable, CANCEL annule une requête en cours et OPTIONS interroge les capacités. Des RFC ultérieures ajoutent des méthodes telles que INFO, MESSAGE, SUBSCRIBE/NOTIFY et UPDATE.

Les réponses reflètent le schéma à trois chiffres du HTTP , organisé en six classes. Les réponses 1xx sont provisoires (100 Trying, 180 Ringing) ; les réponses 2xx réussissent (200 OK) ; les réponses 3xx redirigent ; les réponses 4xx signalent des erreurs client (404 Not Found, 486 Busy Here, 407 Proxy Authentication Required) ; les réponses 5xx signalent des erreurs serveur ; et les réponses 6xx signalent des échecs globaux (603 Decline). Pour diagnostiquer rapidement un appel ayant échoué, il est conseillé de commencer par analyser la classe, puis le code.

Il est essentiel de comprendre la particularité classique de la procédure d'établissement d'appel en trois étapes : INVITE , suivie d'une réponse 200 OK, puis d'un accusé de réception (ACK) distinct. Contrairement à la plupart des protocoles requête/réponse, l'ACK d'une requête INVITE constitue une transaction à part entière. Une mauvaise gestion de cet ACK est l'une des causes les plus fréquentes d'appels qui sonnent sans jamais aboutir.

Le SIP ne transmettant que des signaux, les paramètres multimédias proprement dits sont décrits par SDP (Session Description Protocol, SDP 4566), véhiculé dans le corps des messages SIP . Chaque extrémité y indique les codecs qu'elle prend en charge, l'adresse IP et le port de réception des données multimédias, ainsi que d'autres attributs multimédias.

SIP utilise un modèle offre/réponse (RFC 3264) : l’ INVITE de l’appelant contient une offre SDP listant ses capacités, et la réponse de l’appelé contient une réponse SDP sélectionnant le sous-ensemble commun. Cette négociation permet aux deux terminaux de s’accorder sur un codec et un chemin média avant toute transmission audio.

Le flux multimédia négocié transite ensuite via RTP (Real-time Transport Protocol), qui transporte les paquets audio/vidéo avec leurs numéros de séquence et horodatages, parallèlement à RTCP pour le contrôle qualité. Lorsque la confidentialité du flux est requise, SRTP (Secure RTP ) chiffre et authentifie ces paquets. En résumé : SIP et SDP établissent l’appel, RTP / SRTP le transportent — deux chemins distincts pouvant même emprunter des routes différentes sur le réseau.

Suivez le déroulement d'un appel simple. L'UAC de l'appelant envoie INVITE (avec une offre SDP ) au destinataire, éventuellement via un ou plusieurs proxys. Le destinataire répond par 100 Trying, puis par 180 Ringing pendant que son téléphone émet une notification, et enfin par 200 OK contenant la réponse SDP une fois qu'il a accepté.

L'appelant répond par ACK, et la session est alors établie : le flux multimédia RTP circule directement entre les points de terminaison conformément au SDP négocié, indépendamment des proxys qui établissent l'appel. Les modifications en cours d'appel (mise en attente, ajout de vidéo, changement de codec) utilisent une nouvelle requête INVITE ou UPDATE contenant SDP mis à jour.

L'un ou l'autre des interlocuteurs met fin à l'appel en envoyant BYE , auquel il est répondu par un code 200 OK, ce qui interrompt la session et coupe le flux multimédia. En cas d'échec, le flux est court-circuité : une erreur 486 (Occupé ici) ou 408 (Délai d'attente de la requête dépassé) au lieu d'un code 200 OK signifie que l'appel n'atteint jamais l'étape d'accusé de réception (ACK). C'est en visualisant l'intégralité de cette séquence que les journaux SIP deviennent lisibles en cas de dysfonctionnement d'un appel.

Une liaison SIP est une connexion basée sur SIP entre un système téléphonique privé (PBX) ou une application et un opérateur. Elle remplace les liaisons physiques traditionnelles et achemine les appels vers et depuis le réseau public via IP . C'est ainsi que la voix programmatique atteint le PSTN à grande échelle.

À la frontière du réseau se trouve le contrôleur de frontière de session ( SBC ), l'élément qui sécurise et contrôle SIP en périphérie. Il assure le masquage de la topologie, le franchissement des NAT, l'interopérabilité et la normalisation des protocoles entre les différents dialectes SIP , le contrôle d'admission et la limitation du débit, et souvent l'ancrage et le transcodage des médias. Le SBC est au SIP ce que le pare-feu de signalisation est au SS7 / Diameter : le point de contrôle essentiel à la limite de confiance.

VoLTE (Voice over LTE ) est une voix acheminée via le réseau de données LTE en tant que service IMS . Son contrôle d'appel repose sur le SIP exécuté au sein IMS — le même protocole que vous venez d'apprendre, encadré par les interfaces Cx / HSS et de stratégie du cœur de réseau mobile. Ainsi, le protocole SIP utilisé par une équipe de messagerie pour la voix programmable et SIP qui contrôle un appel VoLTE sont identiques ; la différence réside dans le réseau environnant, et non dans la signalisation elle-même.