Comprendre les en-têtes SIP : référence complète

Les en-têtes SIP transportent chaque élément de métadonnées dont une session voix ou vidéo a besoin. L’origine de l’appel, sa destination, les codecs proposés dans le corps SDP, l’identité déclarée de l’appelant, l’état d’authentification de la liaison, la durée de validité de la session. Le protocole de signalisation transmet tout cela sous forme d’une pile de champs nommés à l’intérieur de chaque message SIP, et la valeur de chaque champ contrôle un comportement spécifique au prochain saut. Savoir lire et interpréter ces champs fait la différence entre une interconnexion fonctionnelle et un après-midi passé à déchiffrer des traces.

Cette page constitue la référence champ par champ. Elle regroupe les en-têtes que vous rencontrerez en catégories pratiques, présente la syntaxe de chacun et explique son rôle concret sur le réseau. Pour une vue d’ensemble conceptuelle du fonctionnement de SIP au niveau protocolaire, l’article complémentaire Fondamentaux de la signalisation SIP couvre les rôles et l’architecture ; Flux d’appel SIP expliqué étape par étape détaille chaque message d’un appel type dans l’ordre. Cette page est celle que vous consultez lorsque vous connaissez déjà le flux et que vous avez besoin de comprendre les champs.

Anatomie d’un message SIP

Chaque message SIP se compose de trois parties : une ligne de début, un bloc de champs d’en-tête et un corps optionnel séparé des en-têtes par une seule ligne vide. La ligne de début est soit une ligne de requête (par exemple, INVITE sip:[email protected] SIP/2.0), soit une ligne de statut (par exemple, SIP/2.0 200 OK). Le bloc d’en-têtes est une séquence de lignes Field-Name: field-value, une par en-tête logique. Le corps, lorsqu’il est présent, est décrit par les en-têtes de contenu (le plus souvent SDP pour la négociation média).

Quelques règles mécaniques s’appliquent à l’ensemble du bloc d’en-têtes. Les noms de champs ne sont pas sensibles à la casse : From, FROM et from désignent le même en-tête. De nombreux en-têtes possèdent également une forme compacte d’une seule lettre pour les transports à espace limité ; f équivaut à From, t à To, v à Via, m à Contact, i à Call-ID, l à Content-Length et c à Content-Type. Les valeurs d’en-tête peuvent s’étendre sur plusieurs lignes en commençant la continuation par un espace, et plusieurs valeurs pour le même en-tête peuvent être envoyées sous forme d’un seul en-tête avec des valeurs séparées par des virgules ou sous forme de plusieurs en-têtes distincts portant le même nom.

L’ordre des en-têtes n’affecte généralement pas le comportement du protocole. L’ordre des paramètres au sein d’une valeur d’en-tête unique peut en revanche avoir de l’importance, en particulier pour Via, Route et Record-Route. De nombreux terminaux et intermédiaires s’attendent à un ordre typique lors de l’analyse, c’est pourquoi une implémentation robuste tolère tout ordre mais produit un ordre familier.

En-têtes de dialogue et d’adressage

Ces en-têtes identifient les parties impliquées dans l’appel, le dialogue lui-même, et indiquent à chaque partie où envoyer les messages suivants.

From identifie l’initiateur logique de la requête. La valeur est un nom d’affichage suivi d’un SIP URI entre chevrons, avec un paramètre tag obligatoire qui identifie de manière unique ce côté du dialogue : From: "Alice" <sip:[email protected]>;tag=1928301774. Le From-tag reste constant pour chaque requête et réponse dans le dialogue. Notez que From ne représente pas nécessairement l’appelant réel ; dans de nombreuses topologies d’entreprise et d’opérateur, il est réécrit ou asserté séparément via P-Asserted-Identity (décrit plus bas).

To désigne le destinataire logique de la requête et suit la même syntaxe que From : To: "Bob" <sip:[email protected]>. Le côté initiateur envoie la requête sans tag ; le destinataire ajoute un To-tag sur la première réponse non-100 et, à partir de ce point, le To-tag fait partie de l’identifiant du dialogue. Le Request-URI dans la ligne de début peut différer de l’URI du To au fur et à mesure du routage de la requête.

Call-ID est une chaîne globalement unique qui, combinée au From-tag et au To-tag, identifie un seul dialogue SIP à travers chaque message qu’il produit : Call-ID: [email protected]. Il est généré par le terminal initiateur et ne change jamais pendant la durée du dialogue. Un B2BUA produit deux Call-ID distincts, un par segment, car il exploite deux dialogues indépendants.

Contact indique à l’autre partie où envoyer les futures requêtes intra-dialogue pour cette session : Contact: <sip:[email protected]:5060>. La valeur est normalement l’adresse de transport réelle du terminal, et non un nom de domaine, car le routage doit atteindre une instance spécifique après l’établissement initial. Les SBC réécrivent fréquemment le Contact lors du masquage de topologie, remplaçant l’adresse interne par l’adresse publique du SBC.

Reply-To indique une adresse alternative à utiliser pour toute réponse que l’appelant souhaite diriger ailleurs que vers l’URI du From. Cet en-tête est rare en pratique et essentiellement indicatif.

En-têtes de routage

Les en-têtes de routage définissent le chemin explicite qu’une requête doit emprunter à travers le réseau et garantissent que les réponses peuvent retracer précisément ce même chemin.

Via enregistre chaque saut qu’une requête a traversé. Chaque proxy ajoute un en-tête Via avant de transférer la requête. Un B2BUA génère une nouvelle requête avec sa propre chaîne Via indépendante sur le segment sortant. Les réponses parcourent les Via en ordre inverse pour atteindre l’initiateur. Un Via typique ressemble à Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK776asdhds. Le paramètre branch est l’identifiant de transaction ; les valeurs commençant par z9hG4bK sont conformes au RFC 3261. Plusieurs en-têtes Via apparaissent empilés lorsque plusieurs intermédiaires se trouvent sur le chemin.

Max-Forwards limite le nombre de sauts qu’une requête peut effectuer avant d’être rejetée : Max-Forwards: 70. Chaque proxy décrémente la valeur de un et rejette la requête lorsqu’elle atteint zéro, en renvoyant 483 Too Many Hops.

Route contient une liste explicite d’intermédiaires qu’une requête doit traverser. Le terminal initiateur écrit un en-tête Route pour chaque saut qui lui a été indiqué, et chaque saut retire sa propre entrée du sommet avant de transférer. C’est ainsi que le routage souple (loose routing) fonctionne en pratique et que les SBC dirigent le trafic qui, autrement, choisirait librement son propre chemin.

Record-Route fonctionne dans la direction opposée : un proxy ou B2BUA qui souhaite que les requêtes intra-dialogue suivantes empruntent le même chemin s’insère dans le Record-Route de la requête initiale. Chaque terminal copie ensuite la liste Record-Route dans les en-têtes Route des requêtes suivantes, ancrant le dialogue sur ce chemin. Record-Route est essentiel pour tout intermédiaire qui doit rester dans la signalisation pour la comptabilité, l’ancrage média ou l’application de politiques après l’établissement de l’appel.

En-têtes de transaction et de séquencement

SIP superpose un modèle transactionnel aux transports non fiables, et un petit ensemble d’en-têtes et de paramètres assure la correspondance correcte entre requêtes et réponses.

CSeq contient un numéro de séquence suivi d’un nom de méthode : CSeq: 314159 INVITE. Le numéro s’incrémente de un pour chaque nouvelle requête envoyée par l’initiateur au sein du dialogue, et la méthode correspond à la requête envoyée (ou à la requête d’origine, dans le cas d’ACK, qui conserve le numéro CSeq de l’INVITE mais change la méthode). CSeq permet à un terminal récepteur d’associer un 200 OK à la bonne INVITE lorsque plusieurs sont en cours, et de distinguer un re-INVITE (nouvelle requête) d’une retransmission d’une ancienne.

Le paramètre tag sur From et To identifie de manière unique un côté du dialogue. Le From-tag est généré par l’initiateur au moment de l’INVITE ; le To-tag est généré par le destinataire sur la première réponse non-100. Les deux tags plus le Call-ID forment ensemble l’identifiant du dialogue ; toute requête portant ces trois valeurs est traitée comme intra-dialogue.

Le paramètre branch sur Via identifie une seule transaction. Chaque requête reçoit une nouvelle valeur branch, et la réponse correspondante copie le branch en retour pour que l’initiateur puisse l’associer.

En-têtes de contenu

Lorsqu’un message SIP contient un corps, les en-têtes de contenu le décrivent. Le corps est le plus souvent au format SDP pour la négociation média, mais SIP peut transporter tout type MIME, y compris text/plain, application/pidf+xml pour la présence, multipart/mixed pour plusieurs corps dans un même message, et image/jpeg ou message/sipfrag pour des usages moins courants.

Content-Type déclare le type MIME du corps : Content-Type: application/sdp. Pour les corps multipart, le type inclut également un paramètre boundary qui sépare les parties.

Content-Length indique la taille du corps en octets : Content-Length: 142. Un Content-Length incorrect sur un transport en flux continu brise le cadrage des messages.

Content-Disposition indique au destinataire comment traiter le corps. Des valeurs comme session (le corps décrit la session, valeur par défaut pour SDP), render (afficher au destinataire) et signal (un corps qui affecte la signalisation, comme un URI de transfert) aident les terminaux à diriger les contenus multipart vers le bon sous-système.

Content-Encoding décrit tout encodage (compression, typiquement gzip) appliqué au corps. Le destinataire inverse l’encodage avant l’analyse.

Accept annonce les types de corps que l’expéditeur acceptera dans une réponse. Accept-Encoding et Accept-Language remplissent les rôles de négociation correspondants. Ces en-têtes comptent surtout pour la découverte de capacités via OPTIONS.

En-têtes de capacité

Les en-têtes de capacité permettent à chaque partie de décrire ce qu’elle peut faire et ce qu’elle exige de l’autre. C’est ainsi que les extensions SIP restent rétrocompatibles.

Allow liste les méthodes SIP prises en charge par l’expéditeur : Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REFER, NOTIFY, UPDATE. Publié dans les réponses OPTIONS, les réponses 405 et le 200 OK qui établit un dialogue.

Supported annonce les extensions SIP optionnelles que l’expéditeur comprend par leur nom (par ex., timer, 100rel, replaces), permettant aux équipements en aval d’activer dynamiquement ces fonctionnalités pour la session.

Require va plus loin en exigeant que le destinataire comprenne une extension nommée. Si le destinataire ne la comprend pas, il répond avec 420 Bad Extension et liste les options non reconnues dans Unsupported.

Unsupported apparaît uniquement dans les réponses 420 et liste les extensions nommées dans Require que le destinataire ne peut pas honorer.

User-Agent identifie le logiciel ou l’équipement à l’origine de la requête. Server remplit le même rôle dans les réponses. Les deux sont informatifs.

En-têtes d’identité de l’appelant et de confidentialité

L’identité en SIP fonctionne par couches. L’en-tête From représente ce que l’appelant déclare ; les en-têtes de cette section sont ce que les intermédiaires affirment au sujet de l’appelant, qui est autorisé à voir ces informations, et quel traitement historique a été effectué au fil du parcours. Ces champs déterminent l’affichage de l’identification de l’appelant, le comportement d’interconnexion des opérateurs et l’attestation STIR/SHAKEN, et ils sont les cibles les plus courantes de la manipulation des en-têtes SIP en bordure de réseau (SBC).

P-Asserted-Identity (PAI) transmet l’identité de l’appelant telle qu’assertée par un intermédiaire de confiance, généralement l’opérateur d’origine : P-Asserted-Identity: <sip:[email protected]>. De nombreux PBX récepteurs lisent l’identification de l’appelant depuis PAI plutôt que depuis From lorsque les deux sont présents.

P-Preferred-Identity (PPI) est le pendant côté requête de cette même relation. Un terminal disposant de plusieurs identités valides envoie PPI pour indiquer laquelle il souhaite que le réseau affirme.

Privacy demande la dissimulation des informations d’identité. Les valeurs courantes sont id (retirer PAI des messages qui quittent le domaine de confiance), header (retirer les en-têtes révélant l’identité de l’utilisateur) et none.

Diversion indique que l’appel a été redirigé, en nommant la destination d’origine et la raison : Diversion: <sip:[email protected]>;reason=no-answer.

History-Info remplit le même rôle que Diversion mais constitue le remplacement normalisé, avec une gestion structurée des chaînes de redirection multi-étapes. Les deux coexistent dans les réseaux de production actuels.

Remote-Party-ID précède PAI et transportait à la fois les informations d’identité et de confidentialité dans un seul en-tête. On le rencontre encore dans les déploiements hérités ; les interconnexions modernes utilisent PAI associé à Privacy.

En-têtes d’authentification

L’authentification SIP utilise HTTP Digest, avec une paire d’en-têtes pour les contestations de terminal et une paire parallèle pour les contestations de proxy.

WWW-Authenticate apparaît dans une réponse 401 Unauthorized et conteste le demandeur de s’authentifier. Il contient un realm, un nonce et un algorithme.

Authorization porte la réponse sur la requête retransmise. Le terminal calcule un hachage digest à partir du nonce, de l’URI de la requête, de la méthode et de son secret partagé.

Proxy-Authenticate et Proxy-Authorization fonctionnent de manière identique mais sont utilisés lorsqu’un proxy SIP émet la contestation avec 407 Proxy Authentication Required.

En-têtes de minuterie de session, d’abonnement et de notification

Ces en-têtes régissent la durée de validité d’une session ou d’un abonnement et ce que chaque partie fait à l’approche de l’expiration.

Session-Expires définit la durée de vie maximale d’une session établie : Session-Expires: 1800;refresher=uac. Le paramètre refresher indique quel côté enverra le rafraîchissement.

Min-SE indique l’intervalle de session minimum acceptable. Un destinataire recevant un Session-Expires inférieur à son propre Min-SE le rejette avec 422 Session Interval Too Small.

Expires apparaît sur REGISTER, SUBSCRIBE et parfois sur INVITE. Les valeurs sont des entiers en secondes.

Event nomme le package d’événement sur SUBSCRIBE et NOTIFY (presence, message-summary, refer).

Subscription-State accompagne chaque NOTIFY et décrit l’état de l’abonnement : active, pending ou terminated avec une raison.

En-têtes de transfert et de référence

Le transfert d’appel en SIP est implémenté via la méthode REFER, qui utilise un petit ensemble d’en-têtes pour désigner la cible et rapporter la progression.

Refer-To désigne la cible d’un transfert dans une requête REFER : Refer-To: <sip:[email protected]>. Pour un transfert supervisé, l’URI contient un paramètre Replaces.

Referred-By enregistre la partie qui a initié le transfert.

Replaces est intégré en tant que paramètre URI échappé dans la chaîne cible du Refer-To, puis élevé en en-tête autonome dans l’INVITE sortant pour signaler le remplacement d’un dialogue existant.

Reason transporte un motif de statut sur BYE ou CANCEL, généralement un code de cause Q.850 ou un statut SIP, expliquant pourquoi le dialogue se termine.

L’en-tête Identity (STIR/SHAKEN)

Identity est l’en-tête qui transporte le PASSporT signé dans le cadre de l’authentification d’appels STIR/SHAKEN. La valeur est un objet PASSporT signé sérialisé sous forme de JSON Web Signature (JWS) accompagné de paramètres désignant l’URL du certificat et le niveau d’attestation revendiqué par le fournisseur d’origine : Identity: eyJhbGciOi...<signature>;info=<https://...cer>;alg=ES256;ppt=shaken.

L’en-tête Identity est volumineux selon les normes SIP (souvent 1 à 2 Ko) et constitue l’une des principales raisons pour lesquelles les interconnexions modernes nécessitent des transports capables de gérer des messages SIP au-delà de la limite de fragmentation UDP habituelle. TCP ou TLS est préféré pour toute liaison qui signe ou vérifie.

En-têtes personnalisés, propriétaires et P-Headers

SIP permet à toute partie d’introduire ses propres en-têtes, et en pratique, la quasi-totalité des fournisseurs le font. Deux conventions de nommage couvrent l’essentiel de ces extensions.

Les P-headers utilisent le préfixe P- et sont destinés à un usage au sein d’un réseau privé ou entre réseaux coopérants sous accord explicite. Plusieurs sont normalisés (P-Asserted-Identity, P-Preferred-Identity, P-Charging-Vector, P-Access-Network-Info).

Les X-headers portent le préfixe X- et signalent une extension propriétaire ou applicative non normalisée. Bien que les X-headers restent courants dans les équipements hérités, l’IETF a officiellement déprécié la convention de préfixe X- dans le RFC 6648 ; les implémentations modernes enregistrent les nouveaux en-têtes directement sous des noms descriptifs (par ex., Company-Header plutôt que X-Company-Header). Tout système qui ne comprend pas un en-tête personnalisé donné l’ignore simplement.

La règle pratique pour les deux catégories est que les en-têtes personnalisés doivent être retirés avant qu’un appel ne quitte l’environnement contrôlé.

Comment les SBC traitent les en-têtes SIP

Un Session Border Controller (SBC) en mode B2BUA exploite deux dialogues SIP reliés par une logique de routage interne, ce qui signifie que les en-têtes du segment entrant ne sont pas les mêmes que ceux du segment sortant. Chaque segment possède son propre Call-ID, sa propre chaîne Via, son propre Contact et son propre compteur CSeq. Le SBC reconstruit chaque en-tête du segment sortant à partir de politiques : ce que le système en amont doit voir, indépendamment de ce qui est arrivé côté entrant.

C’est le fondement de la normalisation SIP. Un opérateur qui transmet l’identité de l’appelant via P-Asserted-Identity peut être appairé avec un PBX qui lit From ; le SBC lit PAI sur le segment entrant et réécrit From sur le segment sortant. L’ensemble de ces traitements est couvert dans Manipulation des en-têtes SIP avec un SBC.

Foire aux questions

Conclusion

Les en-têtes SIP constituent la couche de métadonnées qui fait fonctionner tout le reste de la signalisation vocale. Routage, identité, négociation de capacités, authentification, cycle de vie de session, transfert et STIR/SHAKEN vivent tous sous forme de champs nommés à l’intérieur de messages dont la structure est par ailleurs simple. Maîtriser ces champs transforme une trace SIP, d’un mur de texte illisible, en une séquence de décisions que vous pouvez suivre et analyser. C’est également la base de chaque correction d’interopérabilité, de chaque règle de normalisation et de chaque intégration avec un opérateur.

Les mécanismes conceptuels sont dans Fondamentaux de la signalisation SIP ; le parcours message par message est dans Flux d’appel SIP expliqué étape par étape ; et le moteur à règles qui réécrit les en-têtes en production est dans Manipulation des en-têtes SIP avec un SBC.