Un appel SIP, c’est la couche de signalisation qui permet de lancer, modifier et terminer une communication voix ou vidéo sur IP. En clair, SIP ne transporte pas le son lui-même: il coordonne la session, authentifie les postes et négocie les paramètres qui rendent l’échange possible. Je vais donc expliquer ce que fait réellement ce protocole, comment un appel se construit, où se placent SDP et RTP, puis quels pièges je surveille en priorité sur le terrain.
L’essentiel à retenir sur la téléphonie SIP
- SIP gère la signalisation, pas le flux audio ou vidéo.
- SDP décrit la session en précisant les codecs, les ports et le sens des flux.
- RTP transporte la voix et l’image pendant l’appel.
- Les messages clés sont INVITE, ACK, BYE, CANCEL, REGISTER et OPTIONS.
- Les incidents viennent souvent du NAT, des pare-feu, d’un mauvais codec ou d’une sécurité incomplète.
Ce que recouvre vraiment un appel SIP
Je résume le SIP ainsi: c’est le chef d’orchestre d’une session multimédia. Selon l’IETF, la RFC 3261 décrit SIP comme un protocole de signalisation de couche applicative qui sert à créer, modifier et terminer des sessions de communication. Ces sessions peuvent être vocales, vidéo, ou associer plusieurs services en même temps.
Ce point est essentiel, parce qu’on confond souvent SIP avec la voix sur IP elle-même. En réalité, SIP dit qui appelle qui, quand la communication démarre, quel terminal répond et quand on raccroche. La voix, elle, passe ailleurs. Dans un contexte d’entreprise, je le rencontre dans les IPBX, les trunks opérateurs, les softphones, les passerelles de visioconférence et les solutions de télétravail.
Autrement dit, si vous cherchez à comprendre l’appel SIP, il faut penser en deux temps: d’abord la signalisation, ensuite le transport média. Cette séparation explique presque tous les comportements que l’on observe en production.
Comment se déroule la signalisation d’un appel
Un appel SIP suit une logique assez simple sur le papier, mais très utile à connaître quand on doit dépanner. Dans un environnement réel, je regarde presque toujours la séquence des messages avant de toucher aux codecs ou au réseau.
- REGISTER : le terminal s’enregistre auprès du serveur SIP pour signaler qu’il est disponible et où le joindre.
- INVITE : l’appelant lance la session et propose souvent un premier ensemble de paramètres média via SDP.
- 100 Trying : le serveur indique qu’il traite la demande.
- 180 Ringing ou 183 Session Progress : le correspondant est alerté, ou la session progresse vers l’établissement.
- 200 OK : le destinataire accepte l’appel et renvoie à son tour une description de session.
- ACK : l’appelant confirme la bonne réception de l’acceptation.
- RTP ou SRTP : le flux audio ou vidéo circule réellement entre les deux extrémités.
- BYE : l’une des parties met fin à l’appel.
Si l’appel est annulé avant réponse, c’est le message CANCEL qui prend le relais. Et si quelque chose bloque, SIP retourne des codes d’erreur comme 404, 486 ou 603. Dans un outil de supervision, ces réponses donnent souvent beaucoup plus d’informations qu’un simple “ça ne marche pas”.
À noter aussi: la signalisation SIP passe très souvent sur 5060, et sur 5061 quand on ajoute TLS pour protéger les échanges de contrôle. Cette base est pratique à retenir, mais elle ne suffit pas à elle seule pour garantir un appel stable. C’est là qu’il faut distinguer SIP, SDP et RTP, sinon on mélange vite tout.
Pourquoi SIP, SDP et RTP ne jouent pas le même rôle
J’insiste sur ce trio, parce que c’est là que beaucoup de diagnostics dérapent. L’IETF précise dans la RFC 8866 que SDP n’est qu’un format de description de session: il ne transporte pas la voix, il décrit les paramètres nécessaires pour la faire passer. SIP pilote l’échange, SDP décrit ce que chaque côté accepte, et RTP transporte le média réel.
| Protocole | Rôle principal | Ce qu’il transporte | Problème typique |
|---|---|---|---|
| SIP | Créer, modifier et terminer la session | Messages de signalisation | Authentification, routage, NAT, interopérabilité |
| SDP | Décrire les paramètres média | Codecs, ports, directions de flux | Codec non compatible, mauvais port, mauvaise négociation |
| RTP | Transporter l’audio et la vidéo | Paquets média en temps réel | Jitter, perte de paquets, latence, écho |
| TLS ou SRTP | Protéger la signalisation ou le média | Chiffrement et intégrité | Certificats, compatibilité, configuration plus stricte |
En pratique, si l’appel sonne mais que vous n’entendez rien, le problème n’est souvent pas SIP seul. Il est fréquent que la signalisation passe correctement alors que le flux RTP soit bloqué par un pare-feu, mal routé par le NAT, ou renvoyé vers une adresse qui n’est pas joignable. C’est pour cette raison que je traite toujours la signalisation et le média comme deux couches distinctes.
Une fois cette séparation comprise, on voit mieux pourquoi SIP est devenu si présent dans les infrastructures modernes. La suite logique, c’est de regarder où il apporte une vraie valeur.
Où le SIP s’impose vraiment en entreprise
Dans les environnements professionnels, SIP est surtout utile dès qu’il faut centraliser, faire évoluer ou interconnecter la téléphonie. Je le retrouve dans plusieurs scénarios très concrets:
- Téléphonie d’entreprise : un IPBX interne dialogue avec un opérateur via un trunk SIP pour gérer les appels entrants et sortants.
- Travail hybride : les collaborateurs utilisent des softphones ou des applications mobiles pour rester joignables hors du bureau.
- Centre de contact : le SIP sert de base à la distribution des appels, aux files d’attente et au serveur vocal interactif.
- Visioconférence : le même socle de signalisation peut initier des appels audio/vidéo et coordonner plusieurs participants.
- Interopérabilité : SIP permet de relier des équipements et des services de fournisseurs différents sans enfermer l’entreprise dans une seule solution.
Ce qui fait sa force, ce n’est pas seulement la voix. C’est la possibilité de faire cohabiter plusieurs usages sous un même cadre technique. Pour une PME, cela simplifie souvent l’administration; pour une structure plus grande, cela facilite le multi-site, les redondances et la migration progressive depuis des solutions plus anciennes.
Mais cette souplesse a un revers: plus l’environnement est riche, plus les réglages doivent être propres. Et c’est précisément là que les erreurs les plus classiques apparaissent.
Les erreurs et limites qui font dérailler un déploiement
La plupart des incidents SIP que je vois ne viennent pas d’un “bug SIP” au sens strict. Ils viennent d’un mauvais alignement entre le protocole, le réseau et les règles de sécurité. Les points sensibles reviennent presque toujours.
- NAT mal géré : la signalisation fonctionne, mais le flux audio ne revient pas au bon endroit.
- Pare-feu trop restrictif : le port SIP est ouvert, mais pas la plage de ports RTP nécessaire au média.
- Codec incompatible : les deux extrémités ne s’accordent pas sur un format commun, ou la transcoding n’est pas prévue.
- Signalisation non chiffrée : les identifiants et les métadonnées circulent en clair, ce qui n’est pas acceptable dans tous les contextes.
- Jitter et latence : l’appel passe, mais la qualité se dégrade dès que le réseau est chargé.
- ALG mal configuré : certaines box ou passerelles modifient les paquets SIP à la volée; parfois ça aide, souvent ça complique le diagnostic.
Le symptôme le plus trompeur, c’est le cas où l’appel “sonne” correctement mais où l’audio est absent d’un seul côté. Là, le premier réflexe utile consiste à vérifier le chemin RTP, puis les ports autorisés, puis la correspondance des codecs. Je passe rarement à l’étape suivante avant d’avoir éliminé ces trois causes.
La sécurité mérite aussi une attention particulière. SIP peut être chiffré côté signalisation avec TLS, et le média peut passer en SRTP, mais cela suppose une configuration propre des certificats, des comptes et des équipements intermédiaires. Sans ce travail, on gagne en simplicité apparente et on perd en maîtrise réelle.
Ce que je vérifie avant de basculer une téléphonie sur SIP
Quand je dois valider une migration ou un nouveau déploiement, je ne commence pas par les options avancées. Je regarde d’abord les bases, parce que ce sont elles qui déterminent si la solution sera stable ou pénible à exploiter.
- Compatibilité des codecs : je vérifie que les terminaux, l’opérateur et l’IPBX partagent au moins un codec commun.
- Plan de ports : je confirme que la signalisation et la plage RTP sont autorisées de bout en bout.
- Authentification : je contrôle les identifiants, les mots de passe et les règles de renouvellement des enregistrements.
- Sécurité : j’active TLS pour la signalisation et SRTP pour les flux sensibles dès que le contexte l’impose.
- Qualité réseau : je mesure la latence, la gigue et la perte de paquets avant la mise en production.
- Résilience : je prévois un plan de secours, notamment si l’entreprise dépend fortement des appels entrants.
Dans un environnement à plusieurs sites, j’ajoute presque toujours un SBC, c’est-à-dire un Session Border Controller, pour sécuriser et stabiliser les échanges entre le réseau interne et l’extérieur. Ce n’est pas indispensable dans tous les cas, mais c’est souvent un vrai amortisseur quand on veut éviter les surprises au moment du changement d’opérateur, du télétravail massif ou de l’ouverture vers des usages vidéo plus lourds.
Au fond, le SIP n’est pas compliqué parce qu’il serait opaque; il devient compliqué quand on le traite comme un simple “bout de téléphonie”. Si je devais résumer ma méthode, je dirais qu’il faut d’abord valider la signalisation, ensuite la négociation média, puis la sécurité et la qualité réseau. Quand ces quatre couches sont alignées, la téléphonie IP devient fiable, souple et bien plus facile à faire évoluer.