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 établir une session, et c’est aussi le message que les ingénieurs consultent le plus souvent lorsque quelque chose ne fonctionne pas. Un INVITE transporte les identités de l’appelant et de l’appelé, le parcours de routage emprunté jusqu’à présent, 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’identifiant 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 une vue d’ensemble du fonctionnement de SIP en tant que protocole, consultez Les fondamentaux de la signalisation SIP.

Les trois sections d’un INVITE

La 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 décrivant 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 syntaxique sait que les en-têtes sont terminés. L’absence de ce CRLF 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 METHOD 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 l’action à effectuer. INVITE signifie « établir une session ». Les autres méthodes partageant 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 pour créer un dialogue. D’autres méthodes comme SUBSCRIBE peuvent également établir des dialogues selon l’extension utilisée.

Le Request-URI indique la destination actuelle de la requête. Ce n’est pas nécessairement la destination d’origine. Lorsque l’INVITE traverse des proxys et des 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é en 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 fréquentes lors de la lecture d’une trace ; le Request-URI répond à « où cela va-t-il en ce moment », tandis que l’en-tête To répond à « à qui cela était-il originellement destiné ».

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

Les en-têtes obligatoires

La 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 ultérieures 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 emprunté par la requête. Chaque saut qui transfère un INVITE ajoute un nouveau Via en haut. 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. La 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 prévient les boucles de routage. Défini à 70 par défaut, décrémenté à chaque saut, rejeté avec le code 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. Le 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 le UA appelant. L’URI From représente ce que l’appelant prétend être, ce qui n’est pas identique à ce qu’un fournisseur en amont a authentifié (cela correspond au P-Asserted-Identity).

Call-ID

Un identifiant globalement unique 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é à chaque nouvelle requête dans un dialogue ; réutilisé pour les retransmissions.

Contact

La cible de routage direct pour les requêtes intra-dialogue telles que BYE et re-INVITE, généralement utilisée 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 de 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 correspond à 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 ligne, les en-têtes obligatoires et optionnels suivent, la ligne vide marque la fin du bloc d’en-têtes, et l’offre SDP constitue le corps. Les valeurs sont illustratives ; les INVITE en production varient dans l’ordre des champs et l’ensemble exact des en-têtes optionnels, mais chaque INVITE conforme comporte 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é la RFC 4566 en 2021). Lignes clés :

• v= version du protocole (toujours 0)
• o= origine : identifiant de session + adresse de l’émetteur
• s= nom de session
• c= connexion : adresse IP où l’émetteur 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 payload-type
• a= attributs : rtpmap, fmtp, sendrecv/sendonly/recvonly/inactive, crypto (SDES), fingerprint (DTLS-SRTP)

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 clés SDES doit protéger le chemin de signalisation avec TLS, sinon les clés maîtres 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é en même temps. La référence complète des en-têtes SIP couvre chaque en-tête champ par champ ; nous nous concentrons ici sur ceux qui affectent spécifiquement le traitement de l’INVITE.

Négociation de capacités : Allow énumère les méthodes prises en charge par le UA, Supported liste les extensions qu’il comprend, et Require liste les extensions que le côté distant doit supporter 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 traversera ; Record-Route marque les intermédiaires souhaitant rester dans le dialogue pour les requêtes ultérieures. Un SBC en mode B2BUA supprime les deux et génère un nouveau routage sur la branche sortante.

Identité de l’appelant : P-Asserted-Identity (RFC 3325) transporte l’identité de l’appelant certifiée par l’opérateur, P-Preferred-Identity correspond à ce que le 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 les éléments masqués en aval.

Historique de transfert d’appel : Diversion et History-Info (RFC 4244) transportent l’historique de redirection lorsqu’un appel a été transféré. Deux standards concurrents ; les fournisseurs préfèrent 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 prévient les sessions fantômes à moitié fermées. User-Agent identifie le logiciel appelant, utile pour la corrélation de traces.

De l’INVITE au dialogue

Un INVITE atteignant 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é décroche. L’appelant acquitte avec ACK, et le dialogue est entièrement confirmé.

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 contrôleur de session en bordure (SBC) en mode B2BUA termine l’INVITE entrant et construit un nouvel INVITE sortant sur l’autre branche. Chaque en-tête du message sortant est reconstruit à partir de zéro, ce qui permet au SBC de supprimer les champs propriétaires, de réécrire les en-têtes d’identité, de normaliser Diversion vers History-Info (ou inversement), d’injecter l’en-tête Identity STIR/SHAKEN depuis un service de signature externe, et de réécrire Contact et Via pour masquer la topologie interne de l’émetteur. La mécanique de ces réécritures est couverte dans Manipulation des en-têtes SIP ; la raison architecturale pour laquelle un proxy ne peut pas faire la même chose est expliquée dans Proxy SIP vs SBC.

Foire aux questions

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

L’en-tête From transporte l’identité déclarée par l’appelant. Le PAI transporte l’identité que le fournisseur en amont est prêt à certifier 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 (elle change au fil des transferts par les proxys et SBC). L’en-tête To représente la destination logique d’origine (elle ne change pas en transit).

Un INVITE peut-il ne pas avoir de corps ?

Oui. Un INVITE en « offre différée » ne contient pas de SDP. L’appelé répond avec son offre SDP dans le 200 OK ; l’ACK de l’appelant contient la réponse. Peu courant dans les déploiements d’opérateurs modernes, mais encore observé dans certains scénarios click-to-call hérités.

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

Convention de la 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 transaction SIP unique à un saut donné. Chaque saut insère un nouveau branch lors du transfert. Les valeurs branch conformes à SIP/2.0 doivent commencer par z9hG4bK.