Lexique VoIP

Ce document est un guide de référence contenant de courtes explications sur VoIP/SIP.
Les instructions de configuration des terminaux sont disponibles ici.

VoIP / MoIP

VoIP signifie "Voice over IP" et décrit une méthode de transmission de la voix sur un réseau informatique.
Il est également possible de transmettre des flux vidéo et des messages, ce qui est alors appelé MoIP "Multimedia over IP".

VoIP englobe différentes techniques de transmission, mais nous nous concentrons ici sur la transmission via le protocole SIP.

Bases du réseau

Protocoles

IPv4 / IPv6

Le protocole Internet version 4 (IPv4) est la base des réseaux IP actuels et de l'Internet.
Il appartient à la couche 3 du modèle OSI (couche de réseau, Network Layer).
Une adresse IPv4 comprend 4 octets et est généralement représentée sous la forme de 4 nombres décimaux séparés par des points, avec des valeurs comprises entre 0 et 255.
Toute adresse IP utilisée sur l’Internet public doit être unique dans le monde entier.
L’espace d’adressage de 4 octets permet en théorie plus de 4 milliards d’adresses, mais en pratique, moins sont effectivement utilisables.

Le protocole Internet version 6 (IPv6) est de plus en plus utilisé à la place d’IPv4.
Il s’agit d’une évolution d’IPv4 qui apporte plusieurs avantages, notamment une expansion massive de l’espace d’adressage IP.

Comme il existe actuellement très peu de terminaux VoIP compatibles avec IPv6, ce document se concentre principalement sur IPv4.

Adresses sur Internet

Il est courant de spécifier uniquement une adresse IP comme destination sur Internet.
Cependant, il est important de noter qu'une adresse complète inclut également un port (par exemple, 192.168.0.11:5060).

Adresses dans le LAN

Les plages d’adresses IP à utiliser dans un réseau local (LAN) ont été définies comme suit :

10.0.0.0/8 172.16.0.0/12 192.168.0.0/16

Ces plages doivent impérativement être utilisées, sinon des conflits d’adresses avec des adresses sur Internet peuvent survenir.

TCP

Transmission Control Protocol

TCP est un protocole de transport garantissant une connexion de transport sécurisée de bout en bout. Si la réception d'un paquet n'est pas confirmée dans un certain délai (Retransmission Time), la source retransmet le segment TCP concerné. En raison de son manque de capacités en temps réel, le protocole TCP n'est pertinent pour la VoIP que pour la signalisation des sessions. Son utilisation avec SIP est uniquement optionnelle, UDP étant préféré. Pour la transmission de données en temps réel, comme les paquets vocaux, TCP est largement inadapté en raison des délais potentiellement inacceptables qu'il peut introduire.

UDP

User Datagram Protocol

UDP est un protocole de transport simple assurant une connexion de transport de bout en bout, mais sans garantie. En raison de la communication sans connexion et non sécurisée, les datagrammes UDP sont transmis aussi rapidement que possible, sans retard causé, par exemple, par des retransmissions de paquets. Ainsi, l'UDP est particulièrement adapté aux communications en temps réel.

RTP / RTCP

Real Time Protocol

RTP est un protocole de transport conçu pour la transmission de données audio et vidéo en temps réel. Les paquets RTP sont généralement transportés via UDP afin d'éviter une surcharge inutile.

RTP Control Protocol

RTCP est un protocole de contrôle des sessions RTP. Il complète RTP en permettant l'échange d'informations sur la qualité de service (QoS) entre l'expéditeur et le destinataire.

SIP

Session Initiation Protocol

Le protocole SIP est utilisé pour transmettre des messages de signalisation afin d’établir des sessions de communication (« Sessions ») dans le domaine de la VoIP. Les formes de médias incluses dans une session (VoIP, « Video over IP » ou autres applications multimédias), ainsi que les paramètres nécessaires pour l'encodage et le décodage des données multimédias (par ex. les codecs utilisés, etc.), sont également transmis via les messages SIP, tout comme les informations sur les participants et la signalisation. SIP, avec l’aide du protocole de support SDP, fournit l’infrastructure complète pour l’établissement, la modification et la fin d’une session, offrant ainsi, par rapport à la suite de protocoles H.323 (ISDN), l’avantage d’une utilisation simplifiée, d’une meilleure extensibilité et d’une plus grande clarté.

SIP peut être transporté via UDP ou TCP. Étant donné que SIP, en tant que protocole de signalisation et de gestion des sessions, intègre des mécanismes de communication sécurisée tels que le handshake, les retransmissions et les timeouts, il fonctionne de manière orientée connexion et n’a donc pas besoin d’un protocole de transport également orienté connexion. Pour cette raison, l’UDP, qui est sans connexion, est généralement utilisé comme protocole de transport pour SIP. Contrairement aux protocoles orientés connexion comme TCP et SCTP, UDP permet d’éviter les contraintes liées à l’établissement préalable d’une connexion et au contrôle du flux durant l’échange des données de signalisation SIP. Cela permet de réduire le temps de transmission et la charge du trafic réseau lors de l’utilisation de l’UDP pour le transport SIP.

SIP est en grande partie basé sur la norme HTTP en ce qui concerne la structure de ses messages. De plus, les messages SIP sont transmis en utilisant le jeu de caractères UTF-8, compatible avec l’ASCII (Universal Character Set Transformation Format), ce qui signifie qu’aucun décodeur spécifique n’est nécessaire pour leur affichage.

SDP

Session Description Protocol

SDP est utilisé pour décrire les médias transmis dans le cadre d’une session « Multimedia over IP ». Cela inclut non seulement les types de médias (audio, vidéo, etc.), mais aussi les paramètres de contact (adresse IP et port), ainsi que les codecs disponibles (G.722, G.711, H.264, etc.). Il est transmis dans le corps du paquet SIP.

STUN

Session Traversal Utilities for NAT

Le protocole STUN permet aux appareils situés dans des réseaux privés de déterminer leurs informations de contact valides dans le réseau public et de les inscrire automatiquement dans les champs d’en-tête SIP et les paramètres SDP.

L’activation de STUN n’est généralement nécessaire que si elle est explicitement demandée par le fournisseur. Dans la plupart des cas, elle n’est pas requise.

DNS

Domain Name System

Le DNS est un système de noms de domaine hiérarchique et distribué utilisé pour traduire les noms de domaine (par ex. example.com) en adresses IP (par ex. 192.0.2.1) et inversement. Il joue un rôle essentiel en permettant aux utilisateurs d’accéder aux ressources sur Internet en utilisant des noms de domaine lisibles par l’homme plutôt que des adresses IP numériques.

Dans le processus de résolution DNS, lorsqu'un utilisateur saisit un nom de domaine dans un navigateur web ou une autre application réseau, l'application envoie une requête DNS à un résolveur DNS, généralement fourni par le fournisseur d’accès Internet (FAI) de l'utilisateur ou par un service public de résolution DNS. Le résolveur initie alors le processus de résolution en interrogeant des serveurs DNS autoritatifs afin d'obtenir l'adresse IP correspondante au nom de domaine spécifié.

La hiérarchie DNS est composée de plusieurs types de serveurs DNS, notamment :

• Serveurs DNS racine (Root DNS Server) : Ces serveurs se situent au sommet de la hiérarchie DNS et pointent vers les serveurs DNS des domaines de premier niveau (TLD).
• Serveurs DNS de domaine de premier niveau (Top-Level Domain - TLD DNS Server) : Ces serveurs sont responsables de la gestion des noms de domaine dans des domaines de premier niveau spécifiques comme .com, .org, .net et les TLD nationaux comme .ch, .at, .de, etc.
• Serveurs DNS autoritatifs (Authoritative DNS Server) : Ces serveurs stockent les enregistrements DNS (tels que les enregistrements A, AAAA, MX, etc.) pour des noms de domaine spécifiques et sont chargés de fournir des réponses autoritaires aux requêtes DNS.

Le DNS fonctionne via UDP ou TCP sur le port 53. UDP est généralement utilisé pour les requêtes DNS, tandis que TCP est utilisé pour les réponses DNS volumineuses ou les transferts de zone.

En somme, le DNS est un élément fondamental de l’infrastructure Internet, fournissant des services essentiels de résolution de noms qui permettent une communication fluide et un accès aux ressources en ligne.

NAT / PAT

Network Address Translation / Port Address Translation

Le NAT a été introduit pour répondre à la pénurie d'adresses IPv4. Avec le NAT, chaque terminal n'a plus besoin d'une adresse IPv4 accessible sur Internet public, seul le réseau en a besoin. Les terminaux connectés au réseau communiquent alors via une adresse IP publique commune.

Cette mise en œuvre est rendue possible grâce à un routeur qui modifie l'adresse source des paquets réseau. Ainsi, une destination sur Internet ne voit pas l'adresse locale de l'appareil émetteur comme adresse source des paquets reçus, mais plutôt l'adresse publique du routeur. Pour que le routeur puisse associer correctement les réponses reçues d'Internet à l'appareil local approprié, il stocke ces informations dans une table NAT.

Afin d'éviter que les tables NAT ne deviennent trop volumineuses, le routeur attribue une durée de validité à chaque entrée dans la table NAT. Lorsque cette durée est atteinte et qu'aucune donnée n'a été transmise via la connexion enregistrée, le routeur supprime l'entrée correspondante.

Le PAT est souvent négligé lorsqu'on parle de NAT. Si le port utilisé par le terminal émetteur (généralement 5060 pour SIP) est déjà utilisé sur l'interface WAN, le routeur ne doit pas seulement changer l'adresse IP en une adresse WAN, mais aussi modifier le port de l'adresse source en un port non utilisé. Ainsi, un paquet SIP envoyé par le terminal avec l'adresse source 192.168.0.11:5060 peut être modifié par le routeur pour devenir 80.70.60.51:1024.

CGNAT

Carrier-Grade NAT

Le CGNAT, également connu sous le nom de large-scale NAT ou NAT444, est une technique de traduction d'adresses réseau (NAT) utilisée par les fournisseurs d'accès à Internet (FAI) pour gérer la pénurie d'adresses IPv4 publiques et prendre en charge le nombre croissant d'appareils connectés à Internet.

Dans un déploiement CGNAT, plusieurs clients au sein du réseau d'un FAI reçoivent des adresses IP privées à partir d'un pool commun d'adresses (généralement dans les plages définies par le RFC 1918 : 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 ou dans la plage RFC 6598 100.64.0.0/10). Ces adresses IP privées sont utilisées pour la communication au sein du réseau du FAI, mais elles ne peuvent pas être atteintes directement depuis Internet public.

Lorsqu'un appareil situé dans le réseau du FAI initie une communication avec une destination sur Internet, par exemple pour accéder à un site Web ou se connecter à un serveur, l'appareil CGNAT effectue une traduction d'adresse sur les paquets sortants. Il remplace l'adresse IP source privée du paquet par une adresse IP publique provenant du pool du FAI et maintient une table de correspondance pour suivre la traduction.

De même, lorsque l'appareil CGNAT reçoit des paquets entrants depuis Internet, destinés à un appareil du réseau du FAI, il effectue une traduction d'adresse inverse. Il remplace l'adresse IP publique de destination par l'adresse IP privée correspondante avant de transmettre le paquet au destinataire prévu.

Avantages du CGNAT :

• Conservation des adresses IPv4 : Le CGNAT permet aux FAI de préserver les adresses IPv4 publiques en multipliant plusieurs clients derrière une seule adresse IP publique.
• Évolutivité : Le CGNAT permet aux FAI de prendre en charge un grand nombre d'appareils connectés à Internet tout en minimisant l'épuisement des adresses IPv4 publiques.
• Sécurité du réseau : Le CGNAT offre un certain niveau de sécurité en masquant les adresses IP internes des appareils des clients face à Internet public, réduisant ainsi l'exposition aux attaques potentielles et aux accès non autorisés.

Inconvénients du CGNAT :

• Disponibilité limitée des ports : Le CGNAT peut restreindre la disponibilité des ports pour certaines applications et services, ce qui peut poser des problèmes pour la communication peer-to-peer, les jeux en ligne et d'autres applications nécessitant des configurations de port spécifiques.
• Impact sur la communication peer-to-peer : Le CGNAT peut affecter la communication peer-to-peer et certains protocoles réseau qui nécessitent une connectivité de bout en bout, car il ajoute une couche supplémentaire de traduction d'adresses et peut restreindre les connexions entrantes.
• Complexité : La gestion et le dépannage des déploiements CGNAT peuvent être complexes, en particulier dans les grands réseaux avec un volume de trafic élevé et des attributions d'adresses dynamiques.

En résumé, le CGNAT joue un rôle essentiel dans la prolongation de la durée de vie d'IPv4 et permet aux FAI de fournir un accès à Internet à un nombre croissant d'abonnés tout en atténuant les contraintes liées à l'épuisement des adresses IPv4.

SIP-ALG

Étant donné que les terminaux SIP sont généralement installés dans un réseau local (LAN), ils ne connaissent que l'adresse IP interne du réseau et non l'adresse WAN, par laquelle les paquets sont envoyés au fournisseur. Par conséquent, les terminaux ne peuvent inscrire que l'adresse IP interne dans les paquets SIP.
Cela a conduit certains fabricants de routeurs et de pare-feu à implémenter une fonction sur leurs produits qui remplace l'adresse IP interne dans les paquets SIP par l'adresse WAN de la connexion.
L'idée était que l'adresse dans les paquets SIP corresponde à celle vers laquelle le fournisseur enverrait les appels entrants.
Malheureusement, la plupart des fabricants de routeurs et de pare-feu n'ont mis en œuvre que le remplacement de l'adresse IP.
Cependant, comme expliqué dans "Adresses sur Internet", une adresse complète comprend également un port, et pas seulement une adresse IP.
Si le routeur ou le pare-feu remplace simultanément le port avec PAT et l'adresse IP avec SIP-ALG, une adresse incorrecte sera inscrite dans les paquets SIP.

C'est pourquoi sipcall recommande toujours de désactiver SIP-ALG.
Les serveurs sipcall disposent d'une reconnaissance NAT qui identifie les adresses IP privées dans les paquets SIP et adapte leur comportement en conséquence.

Malheureusement, certains opérateurs mobiles activent SIP-ALG dans le CGNAT.
Si tel est le cas et que l'opérateur mobile ne souhaite pas le désactiver, vous pouvez modifier le protocole de transport de votre terminal en TCP.
Souvent, les paquets TCP ne sont pas modifiés par SIP-ALG, contrairement aux paquets UDP.

NAT keep alive

Afin de réduire au maximum l'effort de configuration des utilisateurs, VoIP a été conçu de manière à ce qu'il ne soit pas nécessaire de configurer des redirections de ports sur le routeur pour être joignable en entrant.
Les terminaux VoIP intègrent la fonctionnalité "NAT keep alive".
Lorsque cette fonctionnalité est activée sur un terminal, celui-ci envoie régulièrement un paquet vide au serveur SIP configuré.
Ce paquet permet de maintenir l'entrée de connexion active dans la table NAT du routeur, garantissant ainsi que les appels entrants puissent être correctement acheminés vers le terminal.

RTP keep alive

En raison de la situation avec le NAT chez les clients, le serveur SIP attend avant de délivrer les flux RTP jusqu'à ce qu'un flux RTP soit envoyé depuis le terminal du client vers notre serveur.
Ce n'est qu'en envoyant le flux RTP que la connexion est ouverte à travers le NAT, permettant ainsi d'acheminer le flux RTP entrant vers le terminal.

Si une PBX est configurée pour rediriger un appel vers l'extérieur au lieu d'un terminal, elle ne dispose pas d'un flux RTP sortant depuis un terminal.
Le serveur SIP ne livre alors pas les flux RTP ni sur le côté entrant ni sur le côté sortant de l'appel transféré, car aucune connexion à travers le NAT n'a été établie.

Dans ce cas, RTP-Keep-Alive doit être activé afin que la PBX génère et envoie des paquets RTP, ouvrant ainsi une connexion à travers le NAT.
Dès que le serveur SIP reçoit ces paquets RTP vides via RTP-Keep-Alive, il sait que la connexion NAT est ouverte et commence à acheminer les flux RTP des deux côtés.

QoS

Pour garantir une qualité de communication vocale optimale, la latence du signal (de la bouche à l'oreille, dans une seule direction) doit rester en dessous de 200 ms.

• 200-300 ms sont encore considérés comme acceptables,
• 300-400 ms sont à la limite de l'acceptable,
• au-delà de 400 ms, l'intelligibilité devient insuffisante.

Dans les réseaux actuels, la capacité de transmission est généralement élevée, de sorte qu'aucun retard ne devrait s'ajouter au temps de transmission normal des paquets.
La latence du signal reste donc généralement inférieure à 100 ms.

Si la latence devient trop élevée, cela peut indiquer un problème réseau, par exemple un débit NAT insuffisant sur le pare-feu.
Dans ce cas, il est préférable de résoudre le problème en améliorant la performance du pare-feu plutôt que d'essayer d'appliquer des paramètres QoS pour prioriser les paquets RTP du flux audio.

Si plusieurs flux en temps réel se ralentissent mutuellement, le QoS ne pourra pas compenser ce problème efficacement.

Modèle OSI / Modèle DOD

Il existe plusieurs modèles de référence permettant d'associer les protocoles réseau aux différentes couches d'un réseau. Le modèle le plus connu est le modèle OSI à 7 couches, tandis que Wireshark utilise le modèle DOD pour l'affichage.

Modèle OSI

Couche :	Désignation :	Protocoles :
7	Application Layer	Navigateur, e-mail, messagerie instantanée
6	Presentation Layer	Traducteur entre différents formats de données
5	Session Layer	RPC, HTTP, FTP, SIP, SDP, RTP
4	Transport Layer	TCP, UDP
3	Network Layer	IP, IPX
2	Datalink Layer	MAC
1	Physical Layer	Ethernet

Modèle DOD

Couche :	Désignation :	Protocoles :
4	Process	HTTP, SMTP, FTP, Telnet, SSH
3	Host-to-Host	TCP, UDP
2	Internet	IP, IPX
1	Network Access	Ethernet

Pare-feu

Étant donné que les ports utilisés par les terminaux sont négociés dynamiquement, il n'est pas possible de rendre les terminaux accessibles pour les appels entrants depuis Internet avec des redirections de ports classiques.
Pour cette raison, nous recommandons de configurer le pare-feu en se basant sur les adresses IP plutôt que sur les ports.
Autorisez tout le trafic entrant et sortant vers et depuis nos serveurs SIP.
Vous trouverez les adresses IP utilisées par sipcall ici .

---

Requêtes SIP

• REGISTER :
  • Enregistrement d'un client auprès du serveur Registrar
• INVITE :
  • Invitation d'un participant SIP à une session
• re-INVITE :
  • Modification d'une session existante
• ACK :
  • Confirmation d'une requête INVITE
• CANCEL :
  • Annulation d'une requête INVITE
• BYE :
  • Fin d'une session
• OPTIONS :
  • Utilisé pour échanger les méthodes de requêtes prises en charge

Réponses SIP

• 1XX :
  • La requête a été reçue et est en cours de traitement
• 2XX :
  • La requête a été traitée avec succès
• 3XX :
  • L'appel est redirigé vers un autre participant
• 4XX :
  • Une erreur s'est produite du côté du client
• 5XX :
  • Une erreur s'est produite du côté du serveur
• 6XX :
  • La requête ne peut être satisfaite par aucun serveur

---

Paramètres importants dans le paquet SIP

• From :
  • Nom d'affichage, URI SIP, numéro de l'appelant
• To :
  • Nom d'affichage, URI SIP, numéro cible
• Contact :
  • URI SIP temporaire, peut être utilisée pour un contact direct
• Authorization :
  • Authentification par nom d'utilisateur et mot de passe
• Call-ID :
  • Valeur aléatoire générée par l'initiateur, identifie toutes les requêtes et informations d'état associées à une même session
• CSeq :
  • Valeur aléatoire identifiant la requête SIP à laquelle la réponse SIP correspond
• User-Agent :
  • Nom de l'agent utilisateur
• o= :
  • Origine, nom de la personne initiant la session multimédia, suivi d'un numéro aléatoire généré par session, version de la session, type de réseau et adresse de contact
• c= :
  • Adresse de réception des données utiles du participant à la session, type de réseau et adresse IP pour les données utiles
• m= :
  • Descriptions des médias, type de média, port, protocole, codec
• a= :
  • Attributs, explication des codecs spécifiés dans le paramètre "m"

SIP URI

SIP Uniform Resource Identifier

Une SIP URI représente une adresse de contact pour un système terminal SIP. Sa fonction est comparable à celle d’un numéro de téléphone dans les anciens réseaux de télécommunication.
La structure d'une SIP URI est similaire à celle d'une adresse e-mail avec un préfixe indiquant le protocole.

• sip:User@Host

"User" représente un nom d'utilisateur individuel, tandis que "Host" correspond à une adresse IP ou à un nom de domaine.

Codecs

Bases

Il existe différentes techniques permettant de numériser la parole. Pour cela, on utilise des codecs.

Le mot codec est une combinaison de deux termes : coder et decoder.
Un codec est un logiciel ayant pour mission d’encoder un signal analogique en un flux de données numériques, puis de le décoder.

Numérisation des signaux analogiques

Lors de la conversion analogique/numérique à l’émetteur, le signal audio analogique est échantillonné.
Les valeurs d’échantillonnage obtenues, discrètes dans le temps mais encore continues en amplitude, sont ensuite quantifiées,
c’est-à-dire qu’une plage d’amplitude donnée est associée à une valeur discrète d’amplitude.
Le résultat est un signal à la fois discret dans le temps et en amplitude.

Pour transmettre ce signal sous forme numérique, les valeurs d’amplitude sont codées sous forme de mots de code numériques,
des séquences spécifiques de 0 et 1. Ce processus est appelé codage.

Selon le codec utilisé, il est pris en compte que le signal vocal analogique original contient des informations redondantes.
Celles-ci peuvent être éliminées lors du codage, ce qui permet de compresser le signal vocal.

Codecs recommandés

Étant donné que les principaux fournisseurs autorisent uniquement un nombre limité de codecs sur les connexions des opérateurs,
nous recommandons d’utiliser les codecs suivants, dans l’ordre de priorité indiqué :

Audio :

1. G.722 - Codec HD de haute qualité
2. PCMA (G.711-alaw) - Codec standard en Europe
3. PCMU (G.711-ulaw) - Codec standard en Amérique

Vidéo :

1. H.264 - Codec vidéo largement utilisé

Transcodage

Le transcodage désigne le processus de décodage et de recodage d'un flux de données.
Cela est nécessaire lorsque l’appareil A utilise un codec différent de l’appareil B.
Dans ce cas, un échange direct des données entre les deux appareils n'est pas possible.
Si le flux de données est correctement transcodé, l'échange de données fonctionne.

Cependant, le transcodage doit être évité autant que possible grâce à des paramètres de codec adaptés sur les appareils finaux,
car il nécessite une puissance de calcul considérable sur le serveur de transcodage.

Bande passante réseau pour la VoIP

Ces dernières années, les connexions Internet sont devenues de plus en plus rapides,
ce qui signifie qu'il n'est généralement plus nécessaire d'économiser de la bande passante.
Cependant, si un calcul précis de la bande passante est nécessaire, vous pouvez vous référer aux valeurs suivantes :

Codec :	Débit binaire :
G.711-alaw	64 kbit/s
G.711-ulaw	64 kbit/s
G.722	64 kbit/s
Opus	6-510 kbit/s
H.264	64 kbit/s-240 Mbit/s

Appareils / User-Agent

Il existe différents types d'appareils, tels que les téléphones de bureau, les softphones,
les intégrations de MS Teams avec la téléphonie et les systèmes téléphoniques.
Pour les appareils analogiques, des adaptateurs SIP permettent de continuer à les utiliser.
Bien que les formats de ces appareils varient, ils ne diffèrent pas en termes de protocole SIP.

Tracing

Le traçage désigne dans le domaine des réseaux l'enregistrement et le stockage du trafic de données entre ordinateur ou appareils. Tous les paquets transmis sur le réseau sont enregistrés et souvent stockés dans un fichier (généralement au format PCAP).

Le traçage permet de déterminer quelles informations ont été transimes quand et par qui. Ceci est très utile pour le dépannage afin d'examiner précisément les paquets réseau.

Wireshark

Wireshark est un logiciel libre permettant d'analyser et de visualiser graphiquement les protocoles de données.
Avec son "sniffer réseau" intégré, il permet également d'enregistrer les paquets réseau.

Wireshark propose des outils spécifiques pour l'analyse des paquets SIP, ce qui facilite considérablement l'analyse.
En l'absence de chiffrement, Wireshark permet de voir les données contenues dans les paquets réseau en clair,
y compris les données SIP et la partie audio des communications.

Switch avec Port Mirroring (duplication de port)

Le port mirroring peut renvoyer (dupliquer) le trafic réseau transitant par un port du commutateur sur un autre port. Cela permet de recevoir sur un ordinateur les paquets d’un autre port et de les enregistrer avec Wireshark.

Autres méthodes de traçage

Outre un commutateur avec port mirroring, il existe d'autres moyens de créer un traçage :

• De nombreux téléphones disposent d'une fonction de traçage accessible via leur interface web. Nous avons également créé des instructions détaillées à ce sujet.
• Sur 3CX, il est possible de lancer un traçage via l'interface web du PBX.
• Pour les PBX ne proposant pas cette fonctionnalité, un traçage peut être effectué au niveau du système d'exploitation sous-jacent :
  • Sous Linux avec tcpdump
  • Sous Windows avec Wireshark
• Si un pare-feu est installé dans le réseau, il peut également être utilisé pour capturer un trace réseau.

Problèmes fréquents (Causes / Solutions)

L'User-Agent ne se connecte pas

Les deux causes les plus courantes d'un échec d'enregistrement sont :

• Pare-feu : Si un pare-feu bloque les paquets REGISTER, l'User-Agent ne peut pas s'enregistrer.
• Mot de passe incorrect : Il arrive parfois qu'un espace soit accidentellement copié avec le mot de passe,
  ce qui entraîne une erreur d'authentification.

Pas d'appels entrants

Les deux causes les plus courantes d'absence d'appels entrants sont :

• SIP-ALG : Un SIP-ALG actif peut modifier l'adresse utilisée pour les appels entrants, ce qui empêche leur acheminement correct.
  Il est donc recommandé de toujours désactiver le SIP-ALG.
• Pare-feu : Si un pare-feu bloque les appels entrants, la configuration de ce dernier doit être ajustée en conséquence.

One Way Voice

Si, lors d'un appel, vous entendez votre interlocuteur, mais que lui ne vous entend pas (ou inversement),
on parle de "One Way Voice".
La cause la plus fréquente est un pare-feu bloquant les paquets RTP entrants.

Vous trouverez des détails sur la configuration du réseau et du pare-feu ici .

Mauvaise qualité d’appel

Pour garantir une qualité d’appel optimale, un paquet audio contenant 20 ms de son doit être transmis toutes les 20 ms.
Si vous constatez une dégradation de la qualité audio, plusieurs causes peuvent en être à l’origine :

Perte de paquets

Si des paquets sont perdus entre le terminal et le serveur sipcall, la qualité de l’appel se détériore.
La perte de paquets est souvent causée par un dysfonctionnement d’un composant réseau ou de la connexion Internet.
Dans de nombreux cas, redémarrer l’appareil concerné peut aider.
Si le problème provient de la connexion Internet, le fournisseur d’accès doit s’assurer que la perte de paquets est éliminée.

Jitter / Retards

Il arrive rarement que les paquets soient transmis, mais avec un retard important.
Lors des transmissions audio, les paquets arrivant trop tard sont ignorés, car ils ne peuvent plus être lus en temps voulu.
Les retards sont souvent dus à des équipements réseau surchargés.

Par exemple, si un pare-feu est conçu pour une connexion Internet de 10 Mbit/s,
mais qu’après une mise à niveau, il est soudainement connecté à une connexion de 1 Gbit/s,
le trafic plus élevé peut surcharger le processeur du pare-feu.
Dans ce cas, il est possible que des paquets soient transmis avec un retard.

Perturbations analogiques

Si le terminal utilisé présente un dysfonctionnement au niveau des composants analogiques (par exemple, microphone ou haut-parleur),
ce problème n’apparaît souvent pas dans les journaux SIP.
Dans ce cas, Wireshark peut être utile pour l’analyse, car il permet d’écouter les appels enregistrés.
Si vous y détectez un bruit de fond, cela peut indiquer un défaut matériel.

Ghost-Calls

Les terminaux SIP maintiennent une connexion ouverte via le routeur pour rester joignables en réception.
Tous les paquets SIP qui arrivent sur le port correspondant du routeur sont transmis au terminal.
Les pirates exploitent cette fonctionnalité pour envoyer des paquets SIP aux terminaux via Internet.
Malheureusement, certains terminaux font retentir une sonnerie à chaque appel entrant, même frauduleux.
Dans ce cas, on parle de Ghost-Calls.

Prévention des Ghost-Calls

Pour éviter les Ghost-Calls, installez un pare-feu et autorisez uniquement les paquets entrants provenant des serveurs VoIP de sipcall.
Les serveurs VoIP sipcall utilisent les plages d’adresses suivantes. Vous trouverez les adresses IP utilisées par sipcall ici.

Sécurité

Étant donné que les terminaux SIP et les systèmes téléphoniques sont accessibles depuis Internet,
il est essentiel de maintenir ces appareils à jour.

La longueur des mots de passe utilisés est également un facteur de sécurité important.
Ils doivent contenir au moins 15 caractères pour renforcer la protection contre les attaques.

De plus, il est recommandé de configurer un pare-feu afin de limiter la communication uniquement au fournisseur de services SIP.
Cela empêche les paquets SIP d’être envoyés directement aux terminaux sans contrôle, réduisant ainsi les risques de tentatives d’intrusion.