Flux d’appel SIP : guide détaillé de chaque message, étape par étape

Chaque appel VoIP réussi repose sur une courte séquence de messages SIP échangés dans un ordre strict. Lorsque quelque chose dysfonctionne (audio unidirectionnel, absence de tonalité de retour, appels coupés à la quatrième minute, appels aboutissant avec le mauvais codec), la réponse est presque toujours visible dans cette séquence. Savoir lire une trace SIP est une compétence fondamentale pour quiconque conçoit, déploie ou dépanne des réseaux vocaux, et la première étape consiste à comprendre exactement ce que chaque message contient, où il va et ce qu’il transporte.

Cet article détaille chaque message d’un appel SIP typique, du INVITE initial au 200 OK final sur le BYE, en passant par l’offre/réponse SDP qui négocie le chemin audio. Nous couvrons ensuite les scénarios d’échec les plus courants en production (occupé, défi d’authentification, CANCEL pendant la sonnerie) ainsi que les modifications en cours d’appel utilisées pour la mise en attente, le changement de codec et le transfert. Pour un aperçu conceptuel préalable, l’article complémentaire Fondamentaux de la signalisation SIP couvre les rôles du protocole et l’architecture à un niveau supérieur.

Les trois phases d’un appel SIP

Chaque appel SIP passe par trois phases, et chaque message visible dans une trace appartient à l’une d’entre elles. Ces phases sont utiles car elles correspondent directement à ce qui devrait se passer sur le réseau à un instant donné.

L’établissement couvre les messages qui créent le dialogue : INVITE, les réponses provisoires (100, 180, parfois 183 avec de l’audio précoce), le 200 OK final et l’ACK qui clôt la poignée de main. Environ 90 % des problèmes d’appel se manifestent dans cette phase.

L’échange média est la période après l’ACK pendant laquelle les paquets RTP circulent directement entre les terminaux (ou via un B2BUA qui ancre le média). Aucun message SIP n’est échangé durant cette phase, sauf si quelque chose change dans la session.

Le raccordement ferme le dialogue avec un BYE envoyé par l’une ou l’autre partie, suivi d’un 200 OK confirmant la réception. Une fois les deux messages échangés, le dialogue n’existe plus et tout message ultérieur portant le même Call-ID sera rejeté.

Phase 1 : établissement de l’appel, message par message

C’est ici que l’appel naît. Alice (chez company.com) appelle Bob (chez provider.com). Nous examinerons chaque message sur le réseau, en-tête par en-tête, afin que vous puissiez faire correspondre ce que vous voyez dans une trace à ce que le protocole fait réellement.

Étape 1 : le message INVITE

Le téléphone d’Alice construit un INVITE et l’envoie vers le domaine de Bob. La première ligne est la ligne de requête, indiquant la méthode (INVITE), l’URI cible et la version SIP. Les en-têtes qui suivent identifient les parties, le dialogue, le chemin et le corps du message.

INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: "Alice" <sip:[email protected]>;tag=1928301774
To: "Bob" <sip:[email protected]>
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]:5060>
Content-Type: application/sdp
Content-Length: 142

Plusieurs éléments méritent attention. L’en-tête From possède un tag généré par le téléphone d’Alice ; l’en-tête To n’a pas encore de tag car le dialogue n’est pas encore établi (l’UAS de Bob ajoutera un To-tag dans la réponse). Le paramètre branch de l’en-tête Via commence par z9hG4bK, le cookie magique qui identifie le message comme conforme à la RFC 3261. Le Call-ID reste constant pendant toute la durée du dialogue. Le CSeq démarre à un entier arbitraire et s’incrémente à chaque nouvelle méthode de requête au sein du dialogue.

Étape 2 : 100 Trying

Le prochain saut répond presque immédiatement avec une réponse provisoire 100 Trying. Il s’agit d’un acquittement saut par saut, et non de bout en bout, dont le seul but est d’empêcher le téléphone d’Alice de retransmettre l’INVITE pendant que le prochain saut effectue son traitement.

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK776asdhds
From: "Alice" <sip:[email protected]>;tag=1928301774
To: "Bob" <sip:[email protected]>
Call-ID: [email protected]
CSeq: 314159 INVITE
Content-Length: 0

Remarquez que les en-têtes Via, From, To, Call-ID et CSeq sont copiés depuis la requête. Le routage SIP repose sur cette cohérence : la réponse revient par la même chaîne Via en sens inverse, et les en-têtes correspondants rattachent la réponse à la requête qu’elle concerne. Un 100 Trying n’atteint jamais l’écran de l’appelant, et il n’y a pas d’ACK pour les réponses 1xx.

Étape 3 : 180 Ringing

Une fois que l’INVITE atteint le téléphone de Bob, l’appareil commence à alerter (le téléphone sonne) et renvoie un 180 Ringing. C’est le message qui déclenche la tonalité de retour du côté d’Alice.

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK776asdhds
From: "Alice" <sip:[email protected]>;tag=1928301774
To: "Bob" <sip:[email protected]>;tag=314259
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]:5060>
Content-Length: 0

L’en-tête To possède désormais un tag ajouté par l’UAS de Bob (tag=314259). À partir de ce moment, la combinaison Call-ID, From-tag et To-tag identifie le dialogue de manière unique. Une variante de cette étape est le 183 Session Progress, qui transporte une réponse SDP et sert à délivrer de l’audio précoce (tonalité de retour in-band ou annonces du réseau avant le décrochage).

Étape 4 : 200 OK

Lorsque Bob décroche, son téléphone envoie un 200 OK avec sa propre réponse SDP. C’est le message le plus important de tout le flux : il accepte l’appel et verrouille les paramètres média.

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK776asdhds
From: "Alice" <sip:[email protected]>;tag=1928301774
To: "Bob" <sip:[email protected]>;tag=314259
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]:5060>
Content-Type: application/sdp
Content-Length: 139

v=0
o=bob 2890844527 2890844527 IN IP4 198.51.100.20
s=-
c=IN IP4 198.51.100.20
t=0 0
m=audio 49170 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000

Le corps après la ligne vide est le SDP. La ligne m=audio déclare que Bob recevra l’audio sur le port UDP 49170 et prend en charge les codecs 0 (PCMU) et 8 (PCMA). La ligne c= fournit l’adresse IP. Le téléphone d’Alice commencera à envoyer du RTP vers 198.51.100.20:49170 dès qu’il aura traité ce message.

Étape 5 : ACK

Le téléphone d’Alice confirme le 200 OK avec une requête ACK. L’ACK est unique dans SIP car c’est une requête qui clôt une transaction plutôt que d’en ouvrir une.

ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK4321
Max-Forwards: 70
From: "Alice" <sip:[email protected]>;tag=1928301774
To: "Bob" <sip:[email protected]>;tag=314259
Call-ID: [email protected]
CSeq: 314159 ACK
Content-Length: 0

Deux détails méritent d’être soulignés. Le numéro CSeq reste à 314159 (il correspond à l’INVITE), mais la méthode passe à ACK. Le Request-URI est désormais l’adresse Contact de Bob provenant du 200 OK, et non plus le sip:[email protected] d’origine, car l’ACK va directement au terminal de Bob, contournant les proxys qui pouvaient se trouver sur le chemin initial. Le dialogue est désormais pleinement établi.

Le modèle offre/réponse SDP

SIP ne fait que négocier l’appel. Le média réel utilise RTP, et les paramètres de cette session RTP sont négociés dans les corps SDP transportés par les messages SIP. Ce mécanisme s’appelle offre/réponse, défini dans la RFC 3264.

L’INVITE d’Alice transporte une offre SDP listant tous les codecs pris en charge par son téléphone, par ordre de préférence. Le 200 OK de Bob transporte une réponse SDP listant uniquement les codecs qu’il est disposé à utiliser, dans l’ordre qu’il préfère, plus l’adresse IP et le port où il souhaite recevoir le RTP. L’intersection de ces deux listes détermine le codec effectivement utilisé pour l’appel.

Une offre simple pourrait ressembler à ceci :

m=audio 49172 RTP/AVP 0 8 9 18
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:18 G729/8000
a=sendrecv

Alice propose G.711 µ-law (0), G.711 A-law (8), G.722 (9) et G.729 (18). La réponse de Bob réduit cette liste à un seul codec, généralement l’option de plus haute priorité dans la liste de préférence de Bob qui figure aussi dans l’offre d’Alice. L’attribut a=sendrecv indique que le média est bidirectionnel ; les autres valeurs incluent sendonly, recvonly et inactive, qui deviennent importantes lors de la mise en attente.

Deux problèmes courants résident dans le SDP. Le premier est l’absence de chevauchement entre les listes de codecs proposées, ce qui produit une réponse 488 Not Acceptable Here et l’appel n’aboutit jamais. Le second est un problème de traversée de NAT où l’adresse c= dans le SDP est une IP privée que l’autre côté ne peut pas atteindre, produisant un appel connecté sans audio dans une ou les deux directions. Un SBC corrige ces deux problèmes en normalisant le SDP avant de le transmettre.

Phase 2 : flux média sur RTP

Une fois l’ACK envoyé, le dialogue SIP se tait et le RTP prend le relais. Les paquets RTP sont de petits datagrammes UDP transportant chacun 20 ms d’audio encodé, circulant toutes les 20 ms dans chaque direction. Pour un appel établi de 30 minutes sans modification, vous pouvez vous attendre à environ 180 000 paquets RTP au total et zéro message SIP.

RTP fonctionne en parallèle avec RTCP (RTP Control Protocol), qui transporte des rapports de qualité sur un port séparé (généralement le port RTP + 1). Les paquets RTCP permettent aux terminaux d’échanger des statistiques de gigue, de perte de paquets et de délai aller-retour. De nombreux SBC utilisent les données RTCP pour calculer des scores MOS et générer des alertes de qualité d’appel, même s’ils ne génèrent pas eux-mêmes l’audio.

Un point qui surprend souvent les ingénieurs débutants est que le RTP ne transporte que le média et n’a aucune connaissance du dialogue SIP. Si un téléphone cesse de recevoir du RTP, il n’a aucun moyen au niveau SIP de savoir si l’autre partie a raccroché, s’est figée ou a simplement perdu sa connectivité réseau. C’est pourquoi la plupart des agents utilisateurs implémentent un minuteur de session (RFC 4028) : ils envoient périodiquement un re-INVITE ou un UPDATE pendant les appels longs pour confirmer que le dialogue est toujours actif. Si le rafraîchissement échoue, le côté qui détecte la défaillance termine l’appel par un BYE.

Phase 3 : raccordement de l’appel avec BYE

Lorsque l’une des parties raccroche, elle envoie un BYE au sein du même dialogue.

BYE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK998
Max-Forwards: 70
From: "Alice" <sip:[email protected]>;tag=1928301774
To: "Bob" <sip:[email protected]>;tag=314259
Call-ID: [email protected]
CSeq: 314160 BYE
Content-Length: 0

Le CSeq a avancé d’une unité (désormais 314160) car le BYE est une nouvelle requête au sein du dialogue. L’autre partie répond avec un 200 OK confirmant le BYE. Le RTP s’arrête dans les deux directions et l’état du dialogue est détruit sur les deux terminaux. Tout message SIP ultérieur portant ce Call-ID produira un 481 Call/Transaction Does Not Exist.

Cliquez pour agrandir.

Quand l’appel n’aboutit pas : scénarios d’échec

La plupart des appels réels aboutissent, mais lorsqu’ils échouent, le mode de défaillance correspond généralement à l’un de quatre schémas courants. Reconnaître le code de réponse sur le réseau vous indique immédiatement où chercher.

Défi d’authentification : 401 ou 407

Si le prochain saut exige une authentification (un fournisseur de trunks SIP, un PBX d’entreprise avec exigence d’enregistrement), il répond au premier INVITE par un 401 Unauthorized (lorsque le terminal lui-même lance le défi) ou un 407 Proxy Authentication Required (lorsqu’un proxy intermédiaire lance le défi). Le défi inclut un en-tête WWW-Authenticate ou Proxy-Authenticate contenant un realm et un nonce.

L’agent utilisateur de l’appelant envoie alors un second INVITE avec le même Call-ID mais un CSeq incrémenté, portant un en-tête Authorization contenant un condensat calculé à partir du nonce, de l’URI et du secret partagé. Si le condensat est validé, le flux se poursuit normalement avec 100 Trying, 180 Ringing et 200 OK. En cas d’échec, un 403 Forbidden met fin au dialogue. Les incohérences de chaîne de realm entre le SBC et le fournisseur en amont sont l’une des causes les plus fréquentes de tickets « l’enregistrement fonctionne mais les appels échouent ».

Occupé : 486

Un 486 Busy Here signifie que le terminal appelé est déjà en communication et ne peut pas accepter cet appel. Le dialogue se termine immédiatement, et l’agent utilisateur de l’appelant génère généralement une tonalité d’occupation. Un 600 Busy Everywhere indique que l’utilisateur est globalement indisponible, ce qui termine les tentatives de forking sur tout proxy de renvoi.

Pas de réponse : 408 ou 480

Si Bob ne décroche jamais, l’appel se termine de deux façons. Un 480 Temporarily Unavailable est envoyé par le téléphone de Bob lorsque le minuteur de sonnerie expire (souvent après 30 à 60 secondes). Un 408 Request Timeout est généré par le réseau si aucune réponse d’aucune sorte ne revient dans le délai du Timer B (32 secondes par défaut en UDP). Chacun raconte une histoire différente : 480 signifie que l’appel a atteint le terminal et a été rejeté par la politique du terminal ; 408 signifie que l’appel n’a jamais obtenu de réponse utilisable de quoi que ce soit en aval.

CANCEL : l’appelant raccroche pendant la sonnerie

Si Alice raccroche alors qu’elle entend encore la tonalité de retour (avant que le téléphone de Bob ne réponde), son agent utilisateur envoie un CANCEL référençant le même paramètre branch que l’INVITE original. CANCEL est une requête, pas une réponse. Le côté de Bob répond avec deux messages : un 200 OK pour le CANCEL lui-même, et un 487 Request Terminated pour l’INVITE original. L’agent utilisateur d’Alice acquitte le 487 avec un ACK, et le dialogue est détruit avant d’avoir été pleinement établi. Confondre un flux CANCEL avec un appel échoué est une source fréquente de métriques ASR incorrectes dans l’analyse brute des CDR.

Modifications en cours d’appel : re-INVITE, UPDATE et REFER

Une fois le dialogue établi, l’appel n’est pas figé. L’une ou l’autre partie peut envoyer une nouvelle requête au sein du dialogue existant pour modifier la session. Trois méthodes assurent l’essentiel du travail.

Le re-INVITE est l’outil principal. Il utilise les mêmes Call-ID, From-tag et To-tag que l’INVITE original, mais transporte une nouvelle offre SDP. L’utilisation la plus courante est la mise en attente : la partie qui met en attente envoie un re-INVITE avec la ligne média modifiée (a=sendonly, ou l’IP de connexion définie à 0.0.0.0 dans les implémentations plus anciennes), la partie mise en attente renvoie un 200 OK avec la réponse correspondante, et l’audio s’arrête dans une direction jusqu’à ce qu’un second re-INVITE le restaure. Les re-INVITE sont également utilisés pour la renégociation de codec (passage de G.711 à G.729 lorsque les conditions réseau se dégradent) et pour le basculement SIP de la voix vers T.38 lors de la détection d’un fax.

UPDATE est similaire au re-INVITE mais conçu pour modifier la session avant qu’elle ne soit pleinement établie (pendant l’état de dialogue précoce après un 180 Ringing). Il est fortement utilisé par certains opérateurs pour mettre à jour les minuteurs de session et les détails SDP sans attendre le décrochage.

REFER implémente le transfert d’appel. La partie qui transfère envoie un REFER à l’autre partie contenant un en-tête Refer-To désignant la cible du transfert. La partie réceptrice renvoie un NOTIFY au fur et à mesure que le transfert progresse, indiquant si le nouvel appel a abouti. Le transfert accompagné (consultation d’abord, puis transfert) et le transfert aveugle (transfert immédiat) utilisent tous deux REFER ; la différence réside simplement dans le fait que la partie qui transfère a déjà établi ou non un second dialogue avec la cible.

Le rôle du SBC à chaque étape

Un SBC se positionne au milieu de ce flux en tant que B2BUA, ce qui signifie que l’appel visible d’un côté n’est pas le même dialogue SIP que l’appel de l’autre côté. Pour Alice, le SBC ressemble à Bob ; pour Bob, le SBC ressemble à Alice. Deux dialogues indépendants coexistent, chacun avec ses propres Call-ID, From-tag, To-tag et compteur CSeq, reliés par la logique de routage interne du SBC.

Cette architecture modifie ce que chaque message du flux peut accomplir. Sur l’INVITE, le SBC peut réécrire les en-têtes pour correspondre aux attentes du système en aval (c’est là que réside la manipulation des en-têtes SIP), supprimer les adresses IP privées des en-têtes Via et Contact pour le masquage de topologie, et appliquer des règles de limitation de débit ou de lutte contre la fraude avant de transmettre. Sur le 200 OK, le SBC réécrit le SDP pour que le média transite par le SBC plutôt que directement entre les terminaux, ce qui lui permet de transcoder les codecs (G.711 vers G.729, ou AMR vers G.711 en interconnexion mobile-fixe), d’imposer le chiffrement SRTP et d’appliquer un suivi de qualité sur chaque paquet RTP.

Sur les flux d’échec, le SBC peut mapper les codes de réponse entre différents dialectes : un 503 Service Unavailable en aval pourrait être traduit en 486 Busy Here en amont pour maintenir un comportement de réessai raisonnable. Sur les re-INVITE de mise en attente ou de changement de codec, le SBC peut choisir de les transmettre, de les terminer de son côté et d’absorber le changement, ou de déclencher des ajustements de transcodage. Sur un CANCEL, le SBC propage l’annulation en aval pour que la partie appelée cesse d’alerter, puis nettoie les deux segments.

Le résultat pratique est qu’un SBC correctement configuré élimine la majeure partie de la variabilité que vous observeriez autrement entre les implémentations SIP. Deux fournisseurs qui ne peuvent pas s’interconnecter directement le feront à travers le SBC, car celui-ci normalise le flux d’appel de chaque côté pour correspondre aux attentes de ce segment.

Conclusion

Le flux d’appel SIP est court, déterministe et visible. Cinq messages suffisent pour passer de la composition au dialogue (INVITE, 100 Trying, 180 Ringing, 200 OK, ACK), deux messages le terminent (BYE, 200 OK), et une poignée de réponses d’échec couvre la quasi-totalité des problèmes rencontrés en production. À l’intérieur des corps, l’offre/réponse SDP gère la négociation média, et l’audio circule sur RTP via un canal distinct que SIP ne touche jamais.

Savoir ce que chaque message contient, dans quel ordre, et ce qui change entre requête et réponse fait la différence entre deviner face à une trace SIP et la lire. Pour les ingénieurs qui intègrent des trunks SIP, dépannent des défaillances en cours d’appel ou conçoivent des interconnexions multifournisseurs, cette maîtrise est le fondement sur lequel tout le reste repose.