Dans les épisodes précédents, on a commencé à mettre les doigts dans SIP et Kamailio. Cette fois, on attaque un morceau central de toute plateforme VoIP : le registrar SIP.
Dit comme ça, ça peut sembler un peu austère. En réalité, c’est assez simple : le registrar est l’annuaire qui permet de savoir où joindre un téléphone SIP à un instant donné. Parce que oui, votre téléphone ou votre softphone peut changer d’adresse IP, passer derrière une box, redémarrer, changer de réseau et pourtant il faut bien continuer à lui envoyer les appels.
Dans ce tutoriel Kamailio, on va donc configurer un registrar SIP capable d’accepter des requêtes REGISTER et de stocker les contacts des clients SIP dans sa table location.
Qu’est-ce qu’un registrar SIP ?
Le premier cas d’usage que nous allons étudier dans cette série est celui du registrar. C’est une brique essentielle pour qui veut pouvoir mettre en relation des clients SIP, typiquement des téléphones ou des softphones, dont les adresses IP peuvent changer au fil du temps.
On peut voir le registrar SIP comme un annuaire dynamique.
Dans un annuaire classique, vous cherchez un nom et vous obtenez un numéro de téléphone. Dans un registrar SIP, c’est un peu différent : Kamailio connaît l’identifiant SIP d’un abonné, par exemple sip:0263111111@voip.cyanet.fr, et il sait à quelle adresse IP et sur quel port envoyer les messages SIP pour le joindre.
La nuance importante, c’est que cet annuaire change tout le temps. Un softphone peut passer du Wi-Fi à la 4G, un téléphone peut redémarrer, une box peut renouveler son IP publique, un NAT peut changer le port source. Bref, sans registrar, joindre un abonné SIP devient rapidement comme chercher une aiguille dans une botte de foin.
Quand un téléphone SIP démarre, il ne peut pas simplement attendre les appels dans son coin en espérant que le réseau se débrouille. Il doit d’abord dire au serveur : “Salut, je suis là, voici mon adresse IP, mon port, et voici combien de temps tu peux considérer cette information comme valide”.
C’est exactement le rôle de la requête REGISTER.
AoR, Contact, IP et port : qui fait quoi ?
Un registrar SIP est un composant clé en VoIP qui gère les requêtes REGISTER émises par les clients SIP, aussi appelés UAC pour User Agent Client. Il stocke les informations nécessaires pour joindre ces clients, notamment leur Address of Record, souvent abrégée en AoR.
L’AoR est une URI SIP publique, par exemple sip:0262799974@voip.cyanet.fr. C’est l’identité SIP stable de l’abonné. Le registrar associe ensuite cette identité à une adresse de contact réelle : adresse IP, port, protocole de transport, durée de validité, parfois le User-Agent, et d’autres informations utiles.
En gros, le registrar SIP, c’est le carnet d’adresses vivant de votre plateforme VoIP.
Lorsqu’un abonné envoie plus tard une requête INVITE vers un autre abonné, le proxy SIP peut interroger la table location pour savoir où envoyer l’appel. Si l’AoR du destinataire est enregistré, Kamailio peut transférer la requête vers le bon contact. Sinon, on peut par exemple retourner une erreur ou envoyer l’appel vers une destination par défaut, comme un trunk opérateur.
Petite précision importante : dans ce tutoriel, nous allons uniquement mettre en place la partie registrar. La configuration présentée plus bas ne route pas encore les appels entre deux abonnés. Les requêtes INVITE seront volontairement rejetées avec une erreur 480 Temporarily Unavailable. On construit brique par brique, tranquillement.
À quoi ressemble un annuaire SIP ?
Lorsque vous utilisez un téléphone fixe SIP, un softphone ou même certains services mobiles modernes comme la VoLTE, le terminal se signale auprès d’un registrar. Celui-ci sauvegarde son identifiant, son adresse IP et le port sur lequel il écoute afin de permettre ensuite la réception des appels.
On peut imaginer le registrar comme un annuaire contenant le numéro de téléphone, l’AoR, l’adresse IP, le port et la durée d’enregistrement.
| Numéro de téléphone | AoR | Adresse IP | Port | Expire (s) |
| 0262 799 974 | sip:0262799974@voip.cyanet.fr | 102.215.220.11 | 4758 | 3600 |
| 0263 111 111 | sip:0263111111@voip.cyanet.fr | 100.64.24.16 | 6050 | 1800 |
| 0263 222 222 | sip:0263222222@voip.cyanet.fr | 80.67.167.84 | 64974 | 1800 |
La colonne Expire est importante : un enregistrement SIP n’est pas éternel. Le client indique une durée de validité, souvent via l’en-tête Expires ou via un paramètre expires dans le contact. Avant la fin de ce délai, le téléphone doit renouveler son enregistrement avec une nouvelle requête REGISTER.
S’il ne le fait pas, le contact expire et Kamailio considère que l’abonné n’est plus joignable.
Autre détail intéressant : un même AoR peut avoir plusieurs contacts. Par exemple, un utilisateur peut être connecté à la fois depuis un téléphone SIP de bureau et depuis un softphone mobile. Kamailio peut conserver plusieurs contacts pour le même abonné, selon la configuration utilisée.
Exemple simple : un abonné appelle un autre abonné
Imaginons que 0263 111 111 souhaite appeler 0263 222 222 et que ces deux abonnés sont bien enregistrés sur Kamailio.
- 0263 111 111 envoie une requête
INVITEà Kamailio. - Kamailio identifie le numéro cible.
- Kamailio recherche l’AoR du destinataire dans sa table
location. - Si le destinataire est enregistré, Kamailio transfère la requête
INVITEvers son adresse IP et son port. - Le téléphone de 0263 222 222 sonne.
Avec ce simple exemple, vous avez déjà une bonne intuition du fonctionnement d’une grande partie des applications qui proposent des appels, que ce soit FaceTime, Signal, WhatsApp ou d’autres services du même genre. Le principe général reste le même : le service doit savoir où joindre votre terminal à un instant donné.
Évidemment, dans la vraie vie, il y a un peu plus d’ingénierie derrière : chiffrement, notifications push, NAT traversal, relais média, authentification, haute disponibilité, anti-abus, etc. Mais pour comprendre le rôle du registrar, on va rester simple.
La différence entre registrar et proxy SIP
Petite précision importante : un registrar SIP ne passe pas forcément les appels. Son rôle principal est de gérer les enregistrements des clients SIP.
Dans une architecture classique, Kamailio peut cumuler plusieurs rôles :
- registrar SIP : il reçoit les requêtes
REGISTER; - proxy SIP : il route les requêtes
INVITE,ACK,BYE, etc. ; - serveur d’authentification : il vérifie que l’abonné a le droit de s’enregistrer ;
- frontal SIP : il protège et expose l’infrastructure VoIP ;
- point d’entrée opérateur : il peut relayer les appels vers un trunk SIP ou une plateforme cœur de réseau.
Dans ce tutoriel, on se concentre volontairement sur la partie registrar. Les INVITE sont rejetés avec une erreur 480 Temporarily Unavailable, afin de garder une configuration minimale et facile à comprendre.
Configurer Kamailio comme registrar SIP
Maintenant que nous avons vu ce qu’est un registrar SIP, nous allons en programmer un avec Kamailio. Je me répète, mais c’est important : Kamailio ne fait rien “magiquement” par défaut. Il faut lui dire précisément quoi faire quand il reçoit une requête SIP.
Le scénario est donc le suivant :
- Le softphone démarre.
- Il envoie une requête
REGISTERà Kamailio. - Kamailio extrait l’AoR, l’adresse de contact, l’adresse IP, le port et la durée d’expiration.
- Kamailio sauvegarde ces informations dans sa table
location. - Le softphone reçoit une réponse
200 OK. - Tant que l’enregistrement est valide, Kamailio sait où joindre ce client SIP.
Les modules Kamailio utilisés
Derrière la simple instruction save("location"), Kamailio utilise principalement deux modules :
registrar: fournit la logique de traitement des requêtesREGISTER;usrloc: stocke les contacts SIP dans une table appeléelocation.
Dans notre exemple, la table location est gardée en mémoire vive. C’est parfait pour un labo, un tutoriel ou un premier test. Pour une plateforme de production, il faudra probablement stocker ces informations dans une base externe comme MariaDB, Redis ou MongoDB.
Voici un extrait minimaliste des modules utiles à charger dans votre configuration Kamailio :
loadmodule "sl.so"
loadmodule "registrar.so"
loadmodule "usrloc.so"
# Stockage des contacts en mémoire vive
modparam("usrloc", "db_mode", 0)Selon votre configuration complète, vous aurez évidemment d’autres modules chargés. Ici, l’idée est simplement de mettre en avant ceux qui sont nécessaires pour comprendre le rôle de registrar SIP.
Configuration minimale du registrar
Voici maintenant la route principale. C’est elle qui reçoit les requêtes SIP entrantes et décide quoi en faire.
/*
* Point d'entrée principal de Kamailio
*/
request_route {
/*
* Dans ce tutoriel, on ne traite pas encore les appels.
* Toute requête INVITE reçoit donc une réponse 480.
*/
if (is_method("INVITE")) {
sl_reply("480", "Temporarily Unavailable");
exit;
}
/*
* Lorsqu'un client SIP envoie une requête REGISTER,
* on sauvegarde son contact dans la table "location".
*
* La fonction save("location") est fournie par le module registrar.
* Elle stocke l'AoR, l'adresse de contact, le port et l'expiration.
*
* Attention : dans cet exemple, aucune authentification n'est faite.
* Ne pas exposer cette configuration telle quelle sur Internet.
*/
if (is_method("REGISTER")) {
xlog("L_INFO", "Enregistrement SIP reçu pour AoR: $fu, contact: $fU, depuis IP: $si:$sp\n");
save("location");
exit;
}
/*
* Toutes les autres méthodes SIP ne sont pas encore implémentées.
*/
sl_reply("501", "Not Implemented");
}J’ai volontairement épuré cette configuration pour ne garder que les instructions qui nous intéressent. Dans la route par défaut, l’équivalent d’un point d’entrée principal, on sauvegarde l’AoR du client quand on reçoit une requête REGISTER.
Pour le moment, on ne fait rien d’autre. Les requêtes INVITE retournent une erreur 480 Temporarily Unavailable et toutes les autres requêtes obtiennent une erreur 501 Not Implemented.
Attention : cette configuration est volontairement simplifiée pour comprendre le mécanisme du registrar. Elle ne doit pas être exposée telle quelle sur Internet.
En production, il faudra ajouter au minimum :
- une authentification SIP avec identifiant et mot de passe ;
- une vérification du domaine SIP ;
- une politique anti-bruteforce ;
- une limitation du nombre de requêtes ;
- une protection réseau via firewall, SBC ou règles spécifiques ;
- une vraie réflexion sur la gestion du NAT.
Sinon, votre serveur risque de devenir assez vite un joli terrain de jeu pour les bots SIP qui scannent Internet à longueur de journée. Et croyez-moi, ils ne viennent pas pour vous souhaiter bon courage. D’ailleurs, si vous laissez votre SBC ouvert avec en plus un trunk opérateur, les bots risquent d’émettre des appels sur-taxés et vous de le payer cher.
Confirmer le bon fonctionnement du registrar
Pour vérifier que notre registrar Kamailio fonctionne correctement, je vais utiliser trois outils :
- Gnome Calls, un softphone VoIP sous Linux ;
sngrep, pour observer les requêtes SIP ;- les outils en ligne de commande de Kamailio, pour inspecter la table
location.
Le déroulé du test est assez simple :
- Démarrer Kamailio avec la configuration du registrar.
- Lancer
sngrepdans un terminal. - Ouvrir un softphone et configurer un compte SIP à destination de Kamailio.
- Vérifier que le softphone envoie bien une requête
REGISTER. - Confirmer que Kamailio répond avec un
200 OK. - Vérifier que l’AoR apparaît bien dans la table
location.
Dans sngrep, vous devriez voir un échange très court entre le softphone et Kamailio :
C’est bon signe : le téléphone s’annonce, Kamailio accepte l’enregistrement, et le contact est sauvegardé en mémoire.
Vérifier la table location avec kamcmd
Une fois le softphone enregistré, vous pouvez vérifier ce que Kamailio a en mémoire avec la commande suivante :
kamcmd ul.dumpSelon votre installation, vous pouvez aussi utiliser :
kamctl ul showVous devriez voir apparaître l’AoR de votre utilisateur, son contact SIP, son adresse IP, son port et la durée restante avant expiration.
Vous remarquerez aussi dans les logs Kamailio que celui-ci indique le bon enregistrement de l’AoR en mémoire.
Remarque : dans mon cas, j’ai configuré Gnome Calls pour s’enregistrer auprès de Kamailio sur localhost. Prenez soin d’adapter l’adresse du serveur SIP, le domaine et les paramètres réseau à vos conditions de test.
Ce que ce tutoriel ne fait pas encore
À ce stade, notre Kamailio sait recevoir des requêtes REGISTER et mémoriser les contacts SIP dans sa table location. C’est déjà une belle première brique.
En revanche, il ne sait pas encore :
- authentifier les abonnés ;
- router un appel entre deux utilisateurs ;
- gérer proprement les clients derrière NAT ;
- connecter les appels vers un trunk opérateur ;
- stocker les AoR dans une base externe ;
- sécuriser une exposition sur Internet.
Et c’est très bien comme ça. Kamailio est puissant, mais il vaut mieux avancer étape par étape plutôt que de copier-coller une configuration de 900 lignes sans comprendre ce qu’elle fait.
Dans un vrai réseau, beaucoup de téléphones SIP se trouvent derrière du NAT. Cela peut nécessiter des mécanismes complémentaires côté Kamailio, notamment avec des modules comme nathelper, et parfois l’utilisation de RTPEngine pour gérer correctement les flux média RTP. Ici, on reste volontairement sur le signalement SIP de base.
En conclusion
Et voilà, on a maintenant un Kamailio capable de jouer le rôle de registrar SIP. Ce n’est pas encore une plateforme VoIP complète, mais c’est une brique fondamentale. Sans registrar, impossible de savoir où joindre vos abonnés. Avec lui, Kamailio peut maintenir un annuaire dynamique des clients connectés, même si leurs adresses IP changent.
Dans cette version volontairement simple, les AoR sont stockés en mémoire vive et aucune authentification n’est appliquée. Pour un labo, c’est parfait. Pour Internet, beaucoup moins. Dans un prochain article, on pourra donc ajouter l’authentification SIP, la gestion du NAT ou encore le routage des appels entre deux abonnés.
Dans ce tutoriel, nous sommes partis du principe que les AoR sont uniquement conservés en mémoire vive. Si vous souhaitez aller plus loin, sachez qu’il est possible d’utiliser des bases comme Redis, MariaDB ou MongoDB.
Dans un contexte de haute disponibilité, il peut être intéressant de sauvegarder ses AoR dans une base de données externe afin d’avoir plusieurs instances Kamailio redondantes. C’est également une piste intéressante pour faire de la géo-redondance et centraliser les enregistrements SIP entre plusieurs régions.
La suite logique sera donc d’ajouter les briques qui manquent : authentification, persistance, NAT, routage des appels et sécurité. Bref, tout ce qu’il faut pour passer du petit labo sympathique à une vraie plateforme VoIP un peu plus sérieuse.
