Cela faisait quelques temps que j’avais l’idée de pouvoir récupérer le numéro de téléphone de la personne qui m’a appelé et d’effectuer des actions à partir de cela. C’est à partir de Février 2017 que j’en ai eu la motivation lorsqu’une plate-forme d’appel de Canal+ n’a pas arrêté de m’appeler presque tous les jours pendant un mois et toujours avec les mêmes numéros.

Je me suis donc dit qu’il serait utile d’avoir un truc qui permettrait, à partir du numéro et d’une base de données, d’afficher un nom (un simple répertoire en somme) et de le bloquer en faisant décrocher la ligne puis raccrocher automatiquement une seconde plus tard.

Décrocher puis raccrocher la ligne avec quelques composants est assez simple. Vous faites passer le courant de la ligne dans une résistance de 100Ω, la tension chute et la box croit qu’un vrai téléphone a décroché. Commandez cela avec un relais et c’est bon.

Mais la partie complexe était la récupération du numéro. Celui ci est envoyé entre la 1ère sonnerie (dite de réveil qui ne fait pas forcément sonner les téléphones récents) et la 2e sonnerie sous forme d’un message numérique transitant sous la norme V.23 (1200 bauds, 8 bits, 1 bit de stop, pas de parité).


J’avais donc besoin d’un démodulateur vers série pour récupérer ces informations. J’ai utilisé un TCM3103 qui est un modulateur/démodulateur multi-usages. Il en existe d’autres mais j’avais celui là en stock. Donc là, il s’agit d’un simple test visant à récupérer les informations transmisses en V.23 et d’en faire une analyse sans traitement particulier derrière.

Première étape, réalisation du circuit connecté à la ligne de ma box Free et qui convertit les signaux V.23 vers l’entrée série d’un RaspberryPi.



Cliquez pour agrandir ou version PDF.

J’ai ensuite réalisé une application Java qui lit le port série "/dev/ttyAMA0" et affiche les données dans la console. Pour la liaison série, j'ai utilisé librairie JSSC disponible sur Maven.
Les premiers résultats me permettent de voir ce qu’on reçoit lorsque le numéro est présent et lorsque l’appelant a décidé de cacher son numéro.

Modification de l’affichage du résultat pour voir le code hexadécimal de chaque octet envoyé.

On reçoit la date et l’heure, le numéro ou un code indiquant la non-présence du numéro.
En se basant sur la document technique de France Télécom de 1999 sur les données transmisses en V.23 entre le réseau et l’usager, on peut comprendre la structure d’un message envoyé composé d’un code définissant le type de message, sa longueur et de plusieurs paramètres.
Les messages contentant les informations de l’appelant sont de type "Message d’appel" avec le code 80h.
Plusieurs types de paramètres peuvent être transmis tels que la date et l’heure (code 01h), son numéro (code 02h), la raison de la non présentation du numéro (code 04h) ainsi que d'autres.
En analysant octet par octet, on peut arriver à un résultat lorsque quelqu’un appelle avec son numéro visible ou masqué.

Il n'y plus qu’à faire quelque chose de ça et de gérer dans le code le fait que la transmission peut être altérée ou incomplète. Dans le code test, si la transmission s’arrête, il continu à attendre indéfiniment jusqu’à ce que la supposée transmission se termine. Il faudrait un 2e thread qui surveille l'activité de la transmission. S’il n’y a plus de transmission depuis 1 seconde, il y a reset de l’analyse.

Projet Java de test : TestNumeroAppelantRaspberryPi.zip
Documentation technique France Télécom : STI04-ed6_0304.pdf
Quelques informations sur le service de présentation du numéro : Wikipédia Présentation du numéro