Message SIP INVITE : structure et en-têtes

Chaque appel SIP commence par un INVITE. C’est la requête qu’un agent utilisateur appelant envoie pour démarrer une session, et c’est aussi le message que les ingénieurs passent le plus de temps à lire lorsque quelque chose ne fonctionne pas. Un INVITE transporte les identités de l’appelant et de l’appelé, le parcours de routage que l’appel a emprunté jusqu’ici, les codecs et paramètres de transport proposés par l’appelant, ainsi qu’une longue liste de champs optionnels qui influencent tout, de l’affichage de l’identité de l’appelant à l’attestation STIR/SHAKEN.

Cet article est une référence structurelle du message INVITE lui-même. Il parcourt les trois sections du message, chaque en-tête obligatoire qu’un INVITE doit contenir, le corps SDP, et les en-têtes optionnels les plus fréquents dans les traces de production. Pour un aperçu plus large du fonctionnement de SIP en tant que protocole, consultez les fondamentaux de la signalisation SIP.

Les trois sections d’un INVITE

Le RFC 3261 définit un message SIP en trois parties séparées par des séquences retour chariot/saut de ligne : une ligne de début, un ensemble de champs d’en-tête et un corps optionnel. La ligne de début d’un INVITE est la ligne de requête. Les en-têtes transportent les informations de routage, d’identité et de capacité. Le corps, s’il est présent, contient l’offre SDP qui décrit le média que l’appelant souhaite négocier.

La ligne vide entre le dernier en-tête et le corps est structurelle. C’est ainsi qu’un analyseur sait que les en-têtes sont terminés. Un CRLF manquant à cet endroit est l’une des raisons les plus courantes pour lesquelles un INVITE malformé est rejeté par une pile SIP stricte avant même d’atteindre la logique de routage.

La ligne de requête

La ligne de requête est une seule ligne sous la forme MÉTHODE Request-URI SIP-Version. Pour un INVITE, elle commence toujours par le mot littéral INVITE, suivi du Request-URI, puis de SIP/2.0.

La méthode indique à la pile réceptrice ce qu’elle doit faire. INVITE signifie « établir une session ». Les autres méthodes qui partagent la plupart de la même structure d’en-têtes incluent ACK, BYE, CANCEL, OPTIONS, REGISTER, REFER, NOTIFY, SUBSCRIBE, UPDATE, INFO, MESSAGE et PRACK. INVITE est la méthode SIP la plus courante qui crée un dialogue. D’autres méthodes comme SUBSCRIBE peuvent également établir des dialogues selon l’extension utilisée.

Le Request-URI indique où la requête est actuellement envoyée. Ce n’est pas nécessairement la destination d’origine. Au fur et à mesure que l’INVITE traverse les proxies et les SBC, le Request-URI peut être réécrit pour que le prochain saut sache où transférer. L’en-tête To représente l’identité de destination logique de l’appel et est normalement préservé pendant le transit, même lorsque le Request-URI est réécrit à des fins de routage. Confondre le Request-URI avec l’en-tête To est l’une des erreurs les plus courantes lors de la lecture d’une trace ; le Request-URI répond à la question « où cela va-t-il en ce moment », tandis que l’en-tête To répond à « à qui cela était-il destiné à l’origine ».

La version SIP est SIP/2.0 depuis la publication du RFC 3261 en 2002. Il n’existe pas de SIP/3.0 en production.

Les en-têtes obligatoires

Le RFC 3261 exige six en-têtes pour chaque requête SIP : Via, Max-Forwards, To, From, Call-ID et CSeq. Les requêtes INVITE incluent presque toujours Contact, car il fournit la cible pour les requêtes intra-dialogue subséquentes telles que BYE et re-INVITE. Lorsque le message contient un corps, Content-Type et Content-Length deviennent également obligatoires.

Via

L’en-tête Via enregistre le chemin réseau que la requête a parcouru. Chaque saut qui transfère un INVITE ajoute un nouveau Via en haut de la liste. Les réponses suivent la chaîne Via en ordre inverse pour revenir vers l’expéditeur. Le paramètre branch à l’intérieur de chaque Via identifie de manière unique cette transaction à ce saut. Le RFC 3261 impose que les valeurs branch commencent par le cookie magique z9hG4bK.

Exemple : Via: SIP/2.0/UDP 198.51.100.10:5060;branch=z9hG4bK74bf9

Max-Forwards

Un compteur de sauts qui empêche les boucles de routage. Réglé à 70 par défaut, décrémenté à chaque saut, rejeté avec 483 Too Many Hops lorsqu’il atteint zéro.

To

La destination logique de l’appel, exprimée sous forme d’URI. Non modifiée en transit. L’UAS répondant ajoute un To-tag dans la réponse 200 OK, et ce tag lie le dialogue du côté de l’appelé.

From

L’identité déclarée de l’appelant. Contient toujours un tag défini par l’UA appelant. L’URI From est ce que l’appelant prétend être, ce qui n’est pas la même chose que ce qu’un fournisseur en amont a authentifié (cela correspond au P-Asserted-Identity).

Call-ID

Un identifiant unique au niveau mondial pour l’ensemble du dialogue. Chaque requête et réponse au sein du dialogue porte le même Call-ID.

CSeq

Command Sequence : un numéro suivi d’un nom de méthode (par ex. CSeq: 314159 INVITE). Incrémenté pour chaque nouvelle requête dans un dialogue ; réutilisé pour les retransmissions.

Contact

Cible de routage direct pour les requêtes intra-dialogue telles que BYE et re-INVITE, généralement utilisé conjointement avec tout ensemble Route établi par Record-Route. Contient presque toujours l’adresse IP et le port réels du point de terminaison, c’est pourquoi le masquage de topologie au niveau d’un SBC implique presque toujours la réécriture du Contact.

Content-Type et Content-Length

Lorsque l’INVITE contient un corps, les deux sont obligatoires. Content-Type est presque toujours application/sdp ; Content-Length est la taille du corps en octets.

Un INVITE complet en pratique

INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 198.51.100.10:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
To: "Bob" <sip:[email protected]>
From: "Alice" <sip:[email protected]>;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]:5060>
P-Asserted-Identity: <sip:[email protected]>
Identity: eyJhbGciOiJFUzI1NiI...JSON-WEB-SIGNATURE
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REFER, UPDATE
Content-Type: application/sdp
Content-Length: 156

v=0
o=alice 2890844526 2890844526 IN IP4 198.51.100.10
s=SIP Call
c=IN IP4 198.51.100.10
t=0 0
m=audio 49170 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000

La ligne de requête figure sur la première rangée, les en-têtes obligatoires et optionnels suivent, la ligne vide marque la fin du bloc d’en-têtes, et l’offre SDP remplit le corps. Les valeurs sont illustratives ; les INVITE réels varient dans l’ordre des champs et l’ensemble exact d’en-têtes optionnels, mais tout INVITE conforme contient les mêmes champs obligatoires et la même structure en trois sections.

Le corps SDP

Le corps est presque toujours une offre SDP (Session Description Protocol) (RFC 8866, qui a remplacé le RFC 4566 en 2021). Lignes clés :

• v= version du protocole (toujours 0)
• o= origine : identifiant de session + adresse de l’initiateur
• s= nom de la session
• c= connexion : adresse IP où l’initiateur s’attend à recevoir le média
• t= temps (presque toujours 0 0 pour le SIP en temps réel)
• m= ligne média : type, port, transport, liste de types de charge utile
• a= attributs : rtpmap, fmtp, sendrecv/sendonly/recvonly/inactive, crypto (SDES), fingerprint (DTLS-SRTP)

Le SDP suit le modèle offre/réponse (RFC 3264). L’INVITE transporte l’offre ; le 200 OK transporte la réponse. Un déploiement utilisant le SRTP avec un échange de clés SDES doit protéger le chemin de signalisation avec TLS, sinon les clés maîtresses traversent le réseau en clair dans la ligne a=crypto.

En-têtes optionnels importants dans un INVITE

L’INVITE transporte plus d’en-têtes optionnels que tout autre message SIP, car il établit le dialogue, négocie les capacités et affirme l’identité simultanément. La référence complète des en-têtes SIP couvre chaque en-tête champ par champ ; ici, nous nous concentrons sur ceux qui affectent spécifiquement le traitement de l’INVITE.

Négociation des capacités : Allow énumère les méthodes prises en charge par l’UA, Supported liste les extensions qu’il comprend, et Require liste les extensions que le côté distant doit prendre en charge sous peine d’échec de l’INVITE (couramment timer, 100rel, replaces). Ces trois en-têtes déterminent si le dialogue peut être établi.

Chemin de routage : Route prédéfinit les sauts que l’INVITE traverse ; Record-Route marque les intermédiaires qui souhaitent rester dans le dialogue pour les requêtes subséquentes. Un SBC B2BUA supprime les deux et regénère un routage neuf sur le tronçon sortant.

Identité de l’appelant : P-Asserted-Identity (RFC 3325) transporte l’identité de l’appelant validée par l’opérateur, P-Preferred-Identity est ce que l’UA demande. L’en-tête Identity STIR/SHAKEN (RFC 8224) ajoute un PASSporT signé liant le numéro de l’appelant à une identité cryptographique. Privacy (RFC 3323) contrôle ce qui est masqué en aval.

Historique de renvoi d’appel : Diversion et History-Info (RFC 4244) transportent l’historique de redirection lorsqu’un appel a été renvoyé. Deux normes concurrentes ; les fournisseurs privilégient des formats différents, et le SBC normalise souvent entre les deux.

Cycle de vie de la session : Session-Expires et Min-SE (RFC 4028) définissent l’intervalle de rafraîchissement qui empêche les sessions fantômes semi-fermées. User-Agent identifie le logiciel appelant, utile pour la corrélation de traces.

De l’INVITE au dialogue

Un INVITE qui atteint la destination déclenche une séquence de réponses : 100 Trying immédiatement, puis une ou plusieurs réponses provisoires 18x (180 Ringing, 183 Session Progress), puis 200 OK avec le To-tag défini lorsque l’appelé répond. L’appelant confirme avec ACK, et le dialogue est pleinement établi.

Les re-INVITE au sein d’un dialogue existant réutilisent le même Call-ID, To-tag et From-tag avec un CSeq supérieur, modifiant la session (changement de codec, mise en attente, transfert). Les codes de réponse provisoires, de succès et d’échec qui complètent la transaction INVITE suivent le même schéma 1xx à 6xx utilisé partout ailleurs dans SIP.

Où les SBC interviennent sur l’INVITE

Un Session Border Controller B2BUA termine l’INVITE entrant et construit un nouvel INVITE sortant sur l’autre tronçon. Chaque en-tête du message sortant est construit à partir de zéro, ce qui signifie qu’un SBC peut supprimer les champs propriétaires, réécrire les en-têtes d’identité, normaliser Diversion vers History-Info (ou inversement), injecter l’en-tête Identity STIR/SHAKEN depuis un service de signature externe, et réécrire Contact et Via pour masquer la topologie interne de l’initiateur. Les mécanismes de ces réécritures sont détaillés dans la manipulation des en-têtes SIP ; la raison architecturale pour laquelle un proxy ne peut pas faire la même chose est traitée dans proxy SIP vs SBC.

Foire aux questions

Pourquoi un INVITE a-t-il à la fois From et P-Asserted-Identity ?

L’en-tête From transporte l’identité que l’appelant déclare. Le PAI transporte l’identité que le fournisseur en amont est prêt à garantir après avoir authentifié l’utilisateur.

Quelle est la différence entre le Request-URI et l’en-tête To ?

Le Request-URI est l’adresse vers laquelle la requête est actuellement dirigée (change au fur et à mesure que les proxies/SBC la transfèrent). L’en-tête To est la destination logique d’origine (ne change pas en transit).

Un INVITE peut-il ne pas avoir de corps ?

Oui. Un INVITE « à offre différée » (delayed offer) n’a pas de SDP. L’appelé répond avec son offre SDP dans le 200 OK ; l’ACK de l’appelant transporte la réponse. Peu courant dans les déploiements opérateur modernes, mais encore observé dans certains scénarios hérités de type click-to-call.

Pourquoi Max-Forwards est-il initialisé à 70 ?

Convention du RFC 3261. Suffisamment élevé pour traverser tout chemin SIP réaliste, suffisamment bas pour que les boucles soient détectées et interrompues rapidement.

À quoi sert le paramètre branch dans l’en-tête Via ?

Il identifie une seule transaction SIP à un seul saut. Chaque saut insère un nouveau branch lorsqu’il transfère le message. Les branches conformes à SIP/2.0 doivent commencer par z9hG4bK.