Décoder les Flux d'Appels SIP

Le Squelette d'un Appel SIP

Un appel SIP de base, de l'établissement à la fin, suit une séquence logique et standardisée. Le diagramme ci-dessous illustre ce flux entre deux téléphones, Alice et Bob. Nous allons nous y référer tout au long de la leçon pour visualiser l'échange.

Ce flux peut être décomposé en trois phases principales :

1. Établissement de la session : L'appel est initié et la sonnerie est déclenchée.
2. Confirmation et Session Média : L'appel est accepté et la conversation (flux RTP) peut commencer.
3. Terminaison de la session : L'appel est terminé proprement.

Analysons chaque étape en détail.

1. Établissement de la Session : L'Invitation et les Réponses Provisoires

Tout commence lorsqu'un appelant (le User Agent Client ou UAC) souhaite contacter un destinataire (le User Agent Server ou UAS).

• INVITE : C'est la première requête envoyée par l'UAC (Alice) pour initier l'appel. Ce message est fondamental : il contient les en-têtes que nous avons étudiés (From, To, Call-ID, CSeq, Contact, etc.) qui décrivent qui appelle qui, pour quelle session, et où recevoir les réponses. Il contient également dans son corps une description de session SDP (que nous verrons en détail plus tard) proposant les paramètres du média (codecs, ports, etc.).

Une fois l' INVITE envoyé, les serveurs intermédiaires (proxys, SBC) et le destinataire final commencent à répondre. Ces premières réponses sont dites provisoires (classe 1xx), car elles ne terminent pas la transaction ; elles donnent simplement un statut sur sa progression.

• 100 Trying : Dès qu'un serveur proxy ou le SBC reçoit l' INVITE, il répond immédiatement avec un 100 Trying. C'est un simple accusé de réception qui signifie "J'ai bien reçu votre demande, je la traite". Son rôle principal est d'arrêter les retransmissions de l' INVITE par l'UAC, qui pourrait croire que son message s'est perdu.

• 180 Ringing : Lorsque la requête INVITE atteint finalement le téléphone du destinataire (Bob) et que celui-ci commence à sonner, le téléphone de Bob envoie une réponse 180 Ringing. Cette réponse remonte le chemin de la signalisation jusqu'à Alice. Quand le téléphone d'Alice reçoit le 180 Ringing, il sait que le destinataire est alerté et commence généralement à jouer une tonalité de retour d'appel (le "ringback") pour l'utilisatrice.

2. Confirmation et Session Média : Le "Handshake" Final

Lorsque Bob décroche son téléphone, la transaction INVITE se termine par une réponse de succès.

• 200 OK : C'est la réponse de succès finale à la requête INVITE. Elle signifie "Appel accepté". Comme l' INVITE, elle contient un corps SDP, mais cette fois-ci, c'est celui de Bob. Le SDP du 200 OK confirme les paramètres média qui seront utilisés pour la conversation. C'est à ce moment que les deux parties s'accordent sur les codecs et les adresses/ports pour échanger le flux audio.

• ACK (Acknowledge) : La réception du 200 OK doit être confirmée. L'UAC (Alice) envoie alors une dernière requête, ACK, pour accuser réception de la réponse finale. Ceci complète ce qu'on appelle le "three-way handshake" de SIP (INVITE -> 200 OK -> ACK). Il est crucial de comprendre que l'ACK est une requête à part entière, avec son propre CSeq, mais appartenant au même dialogue.

Une fois l' ACK envoyé et reçu, la phase de signalisation pour l'établissement de l'appel est terminée. Les deux téléphones peuvent alors commencer à s'échanger des paquets RTP (Real-time Transport Protocol) directement entre eux, transportant la voix. C'est la "Media Session" montrée dans le diagramme.

3. Terminaison de la Session

Lorsque l'un des participants souhaite mettre fin à l'appel, il initie une nouvelle transaction.

• BYE : Alice ou Bob envoie une requête BYE. Ce message signale l'intention de terminer la session. Comme toute requête, il suit le chemin de signalisation établi au début de l'appel (en utilisant les en-têtes Route que nous avons vus précédemment).

• 200 OK : Le destinataire du BYE répond simplement par un 200 OK pour confirmer qu'il a bien reçu la demande de fin d'appel et que la session est terminée.

L'article suivant décrit ce flux en détail, en l'illustrant avec un modèle de routage via des proxys.

Pour consolider cette compréhension, la vidéo suivante propose une présentation animée du même flux, tout en clarifiant une terminologie importante.

Lien avec la Manipulation sur AudioCodes

Votre objectif est de maîtriser la manipulation SIP sur des SBC AudioCodes. Chaque règle de manipulation que vous créerez commencera par spécifier un Message Type. La connaissance du flux d'appel est donc directement applicable. Par exemple, si vous voulez modifier un en-tête uniquement lorsqu'un appel est accepté, vous ciblerez le message invite.response.200. Si vous voulez agir au moment où la sonnerie se déclenche, vous ciblerez invite.response.180 (ou 18x pour inclure les variantes).

Le tableau ci-dessous, extrait du guide de référence AudioCodes, montre comment ces messages sont désignés. Vous n'avez pas besoin de l'étudier maintenant, mais simplement de constater le lien direct entre la théorie du flux SIP et la pratique de la configuration.

Conclusion

Dans cette leçon, nous avons assemblé les pièces du puzzle pour visualiser le cycle de vie complet d'un appel SIP. Vous devriez maintenant être capable de retracer ce flux et de comprendre le rôle de chaque message :

• INVITE : Lance l'appel et propose les paramètres média.
• 100 Trying : Accuse réception de l'INVITE pour éviter les retransmissions.
• 180 Ringing : Indique que le téléphone du destinataire sonne.
• 200 OK (to INVITE) : Confirme que l'appel est accepté et finalise la négociation média.
• ACK : Confirme la réception du 200 OK et complète le "handshake" d'établissement.
• (Session Média RTP) : La conversation audio/vidéo a lieu.
• BYE : Demande la fin de l'appel.
• 200 OK (to BYE) : Confirme la terminaison de l'appel.

Ce flux est le scénario "nominal". Dans la réalité, beaucoup d'autres choses peuvent se passer : un utilisateur peut être occupé, un numéro peut ne pas exister, un serveur peut être en panne. Chacun de ces cas de figure est géré par des codes de réponse spécifiques.

Dans notre prochaine leçon, nous allons explorer la palette complète des codes de réponse SIP (1xx à 6xx). Cela vous donnera les outils pour interpréter non seulement les appels réussis, mais aussi et surtout les échecs, une compétence indispensable pour le dépannage.