Vous avez déployé une solution de VoIP et vous rencontrez des problèmes de qualité. Alors, que les communications doivent être d’une qualité équivalente au numéris ou proche (dans le cas de compression), vous subissez des blancs, de l’écho, une voix métallique voir même des coupures de communications.
Dans l’article, je vais considérer que le site dispose d’un câblage informatique de qualité suffisante et que le matériel déployé est de bonne qualité (switch, routeur, IPBX, postes téléphoniques, passerelles …).
Il va être important dans un premier de temps de déterminer si le problème vient des communications externes ou si le problème intervient aussi sur les communications sur le même site. Si les appels entre 2 postes IP (important) sur le même site (avec l’IPBX en local si nous ne sommes pas en centrex) sont dégradés, il va falloir dans un premier temps résoudre ce problème. Pour cela, il faut vérifier quelques paramètres cruciaux :
- quel est le codec utilisé : le codec a une influence sur la qualité perçue. si on a un PABX, utilisez le G711 voire G722 (codec large bande permettant de mieux reproduire la voix). En mode centrex, il peut être souhaitable d’économiser la bande passante, alors le G729 sera le codec de choix.
- le mode peer to peer activé : si oui, le flux RTP reste sur le réseau local en mode centrex, la connexion se faisant de poste à poste. Le WAN n’intervient donc pas dans le flux voix en dehors de la signalisation (qui peut-être considéré dans un premier temps comme négligeable d’un point de vue bande passante si on le compare aux flux RTP). Sinon, pour un appel entre 2 postes sur le même site, nous avons 1 appel sortant et 1 appel entrant sur le site, il y a donc un impact sur le WAN.
- la fonction VAD (Voice Activity Detection) est-elle activée ? cette fonctionnalité intéressante permet de limiter la bande passante d’une communication en supprimant les paquets incluant les silences. Suivant les réglages, l’économie peut-être importante. Cette fonction est inutile en local, et doit-être désactivée. Elle est difficile a bien paramétrer, et en cas d’erreur les mots seront coupés, les communications pouvant devenir inaudibles.
- un VLAN voix a t’il été paramétré appliquant la CoS voix aux flux concernés ?
- vérifier que les équipements sont bien à jour, car une version firmware peut avoir un défaut expliquant le problème.
En général, les problèmes sont surtout rencontrés lors des appels externes. En effet, la bande passante est alors plus limitée, les communications passent parfois sur internet et le lien est aussi parfois partagé avec d’autres flux.
Je ne conseillerai jamais assez de ne pas transporter la voix sur internet. Internet n’a pas été conçu pour transporter des flux temps réels et ne sait pas garantir la qualité (cela ne veut pas dire que cela ne marche pas). De plus, la sécurité sera aussi difficile à assurer. Je vous laisse imaginer ce que je pense des offres de trunk SIP via internet. Il suffit d’aller voir la liste des failles de sécurité pour prendre peur, mais ce n’est pas le sujet du jour, mais d’un prochain article. En plus des questions posées plus haut, il faut aussi obtenir d’autres informations :
- Nombre d’appels simultanés externes
- Bande passante du lien haut débit (en IP)
- Le lien est-il dédié à la voix ? si non, quels sont les mécanismes qui prioritisent la voix sur les autres flux ?
- Les flux voix empruntent ils internet ou restent sur le réseau de l’opérateur ?
- En mesurant les flux sur le lien, vous pourrez vérifier si le lien est saturé, si les règles sont bien appliquées ou si le lien souffre de perte de paquets ou de gigue.
Ne connaissant pas vos cas particuliers, je ne peux pas allez beaucoup plus loin, mais si vous avez des connaissances réseaux suffisantes et en répondant aux questions ci-dessous, vous avez toutes les billes pour trouver la source du problème. Pour vous aider un peu plus, on peut obtenir des informations intéressantes en écoutant la qualité de la voix.
- Vous avez des blancs en court de communication, il faut regarder du côté de la VAD si elle est activée. Ensuite, cet effet peut-être causé par de la perte de paquet ou une gigue trop importante du lien WAN. Cela peut aussi être dû à une règle de QoS mal définie.
- Vous avez des bruits ou des craquements. Ils sont souvent causés par une congestion du LAN ou du WAN.
- Vous avez une voix de robot, regardez du côté de la perte de paquet dûe à une gigue trop importante. (reste à trouver la source de cette gigue).
- Vous avez de l’écho. Cela est dû à un problème de réglage de l’echo canceller du PABX ou de la gateway.
J’écrirai prochainement un article détaillé sur les symptômes et les causes qui s’y rattachent.
Related posts:
« Je ne conseillerai jamais assez de ne pas transporter la voix sur internet. Internet n’a pas été conçu pour transporter des flux temps réels et ne sait pas garantir la qualité (cela ne veut pas dire que cela ne marche pas). »
Enfin bon, la téléphonie par internet est pourtant l’AVENIR des communications !
Internet n’était pas fait aussi pour héberger des services et tout ce qu’on peut trouver à la Web 2.0 mais à évolué et s’est adapté à la demande. C’est la même chose pour la VoIP.
De nos jours, des opérateurs comme [url=http://www.ippi.fr]ippi[/url] ou [url=http://www.b3g-telecom.com]B3G[/url] proposent vraiment une qualité équivalente voir meilleure que les anciens systèmes PBX basé uniquement sur le réseau PSTN.
Si on se retrouve avec des problèmes de qualité, c’est dans la plupart des cas à cause de la bande passante ou du NAT.
Cordialement,
Philippe
Bonjour Philippe,
Nous sommes d’accord sur le fait que la téléphonie sur IP est l’avenir, et que le réseau numéris est appelé à disparaître à terme. Il est même précisé dans l’article, qu’il est possible d’avoir une meilleure qualité en VoIP avec des codecs plus performants.
Néanmoins, il y a une grande différence avec la téléphonie sur internet. Les 2 deux souvent mélangés. Par exemple, Ippi utilise la VoIP qui transite sur internet afin de connecter leur serveur ToIP au client final. Au contraire, B3G raccorde ses clients via un lien privé (ADSL ou SDSL). Les communications ne transitent jamais par internet (si on exclue leur offre nomade).
Quand les flux restent sur le réseau prive de l’opérateur, il est possible d’y affecter des règles de CoS de bout en bout afin de garantir une liaison de bout en bout. Sur internet, ce n’est pas possible (du moins pour le moment), car il est impossible de prévoir le chemin que va suivre un paquet, son temps de transit ainsi de s’assurer de variables clés comme la gigue et le taux de perte de paquets. Ouvrir ses serveurs SIP sur internet est aussi très dangereux, le protocole disposant de failles permettant l’usurpation, le détournement et le déni de services. Il existe bien entendu des solutions pour se protéger, mais sont-elles mis en oeuvre ? chez les opérateurs offrant ce type d’offres, rarement, et pour les clients finaux jamais, car n’oublions pas que l’argument de vente principal concerne les économies !
Je suis tout à fait d’accord avec toi sur l’avenir des communications : VoIP.
Cordialement,
Mathias
Bonjour Philippe et merci pour cet article bien renseigné.
Je voudrais faire part de mon experience du moment avec un nouvel opérateur VOIP . Il s’avère qu’il nous a vendu une solution internet+voip s’assurer que nous avions besoin d’avoir un reseau bien separé ( un switch pour la Voip et un switch pour le LAN PC) il s’avère que la qualité sonore de la voip est mauvaise voire très mauvaise.
Le debit est un sdsl 2megas pour 15 utilisateurs donc 15 téléphones .
Le soucis c’est que chaque PC utilisateur est branché sur le switch du téléphone IP. Il est vraiment déconseillé de connecter PC et telephone sur une même prise RJ45 ?
Avons-nous une manière de trouver une solution à ces soucis de qualité ?
Merci de votre expertise.
Bon vent.
Vanino
Bonjour Vanino,
Le problème de la qualité VoIP que vous rencontrez peut avoir plusieurs origines.
- Tout d’abord, combien d’appels simultanés avez vous ?
- Quel est le codec utilisé ?
- Avez-vous un PABX sur le site ? Quel est la marque ?
- L’internet passe t’il par le lien SDSL ?
Dans le principe un lien SDSL 2M est suffisant pour les 15 coms simultanés même en G711.
Suivant les postes IP, en effet, certains ne marchent pas super bien avec un PC connecté derrière. Quel est la marque déployée ?
Les postes IP sont-ils alimentés électriquement par le switch ou disposent-ils d’une alimentation séparée ?
Enfin, êtes vous sûr de votre câblage ? tester en connectant un poste directement sur le switch.
Ce ne sont que quelques pistes générales, mais avec vos réponses nous allons pouvoir avancer.
Pouvez-vous me décrire ce que vous entendez par mauvaise qualité sonore ?
Good winds
Mathias
Bonsoir Mathias,
pas de pabx sur site mais technologie Centrex .
10 appels en simultané au maximum.
je ne sais pas quel est le codec utilisé .
Pour les téléphones IP(thompson 2022) , oui ils sont pourvus d’alimentation électrique séparées.
L’internet passe par le lien sdsl.
Merci et à bientôt.
V
Vanino,
Le lien est donc suffisamment dimensionné pour votre besoin. Le premier point à vérifier, c’est la qualité de la voix sans qu’aucun poste informatique n’accès à internet. Si vous avez un FW vous bloquez les ports, ou vous éteignez les postes. Très souvent les problèmes viennent que sans mécanismes de filtrage, la voix et la données ne cohabitent que très mal sur un même lien. Si lors du test, la voix est de bonne qualité, c’est que la qos est inefficace.
@+
Mathias
Pour faire le test que vous proposez Mathias, c’est un peu complexe car pour avoir une bonne évaluation il faut le faire dans un contexte de travail (je ne peux pas deconnecter les PCs en fait)
Je peux essayer de séparer les telephones du LAN PC (deux switchs bien distincts : un switch pour les PCs connecté au routeur du fournisseur sur le port LAN , l’autre pour la voip sur le port telephonie su routeur) et surveiller si la qualité est meilleure.
Que pensez vous du test : http://www.ippi.fr/index.php?page=voiptest?
Je compte m’en servir mais je ne sais pas si c’est efficace sur un reseau voip centrex.
Bon dimanche soir.
v
Le problème que j’imagine, c’est que les flux data impactent la qualité de la voix du fait d’une QoS inefficace. Le seul moyen rapide est de débrancher les PC pour en avoir le coeur net. Néanmoins, le soir quand il ne reste plus grand monde, la qualité est-elle dégradée ?
Il existe un autre moyen un peu plus complexe. Il faut mesurer les flux afin de déterminer exactement la nature de ceux-ci et la bande passante utilisée. La manière de mettre en oeuvre va dépendre de votre fournisseur. Acceptera t-il de vous ouvrir le service netflow s’il est implémenté ou sinon, le smtp, moins riche, mais qui nous permettra d’avoir déjà des informations de saturation.
Avez-vous la main sur le switch ? quelle est sa référence ? On peut aussi récupérer des informations intéressantes selon les fonctions embarquées sur le switch.
En règle générale, dans mes missions, je commence par voir l’architecture et ses composantes, j’effectue des mesures et vérifie les configurations. C’est suffisant dans la plus part des cas.
Bonne journée
Mathias
Bonjour Mathias,
Ci-dessous les tests sur le lan , il y a toujours des grésillements et des hachures, je vous laisse étudier les chiffres .
D’autre part, je me demande si les telephones IP utilisé thompson 2022 sont en fait mauvais , il faut les brancher sur des prises courants alors que certains fonctionnent sans alimentation. En somme , c’est vraiment pas top.
***
Statistiques
————
Vitesse de téléchargement: 4597632 bps
Vitesse d’upload: 433632 bps
Qualité de service: 69 %
Type de test de téléchargement: HTTP
Type de test d’upload: HTTP
Délai TCP maximum: 140 ms
Pause moyenne de téléchargement: 12 ms
Durée minimum d’aller-retour au serveur: 43 ms
Durée moyenne d’aller-retour au serveur: 43 ms
Statistiques
————
Gigue : Serveur ippi –> Vous: 3.4 ms
Gigue : Vous –> Serveur ippi: 1.8 ms
Perte de paquets : Serveur ippi –> Vous: 0.0 %
Perte de paquets : Vous –> Serveur ippi: 0.5 %
Paquets désordonnés: 0.0 %
Nombre de lignes VoIP supportées: 1
Score MOS estimé: 3.9
Rapport
——-
Statistiques du test VoIP ippi
——————————
Gigue : Vous –> Serveur ippi: 1.8 ms
Gigue : Serveur ippi –> Vous: 3.4 ms
Perte de paquets : Vous –> Serveur ippi: 0.5 %
Perte de paquets : Serveur ippi –> Vous: 0.0 %
Paquets rejetés: 0.0 %
Paquets désordonnés: 0.0 %
Score MOS estimé: 3.9
Speed test statistics
———————
Vitesse de téléchargement: 4597632 bps
Vitesse d’upload: 433632 bps
Qualité de service: 69 %
Type de test de téléchargement: HTTP
Type de test d’upload: HTTP
Délai TCP maximum: 140 ms
Pause moyenne de téléchargement: 12 ms
Durée minimum d’aller-retour au serveur: 43 ms
Durée moyenne d’aller-retour au serveur: 43 ms
Bande passante estimée pour le téléchargement: 5760000bps
Concurrence des routes: 1.2528188
Idle TCP forcé: 0 %
Vitesse de route maximum: 12192552bps
un deuxième mais cet fois si en wifi ::
Statistiques
————
Vitesse de téléchargement: 2275856 bps
Vitesse d’upload: 411496 bps
Qualité de service: 11 %
Type de test de téléchargement: HTTP
Type de test d’upload: HTTP
Délai TCP maximum: 337 ms
Pause moyenne de téléchargement: 24 ms
Durée minimum d’aller-retour au serveur: 45 ms
Durée moyenne d’aller-retour au serveur: 46 ms
Statistiques
————
Gigue : Serveur ippi –> Vous: 3.9 ms
Gigue : Vous –> Serveur ippi: 2.8 ms
Perte de paquets : Serveur ippi –> Vous: 0.0 %
Perte de paquets : Vous –> Serveur ippi: 0.7 %
Paquets désordonnés: 0.0 %
Nombre de lignes VoIP supportées: 1
Score MOS estimé: 3.8
Rapport
——-
Statistiques du test VoIP ippi
——————————
Gigue : Vous –> Serveur ippi: 2.8 ms
Gigue : Serveur ippi –> Vous: 3.9 ms
Perte de paquets : Vous –> Serveur ippi: 0.7 %
Perte de paquets : Serveur ippi –> Vous: 0.0 %
Paquets rejetés: 0.0 %
Paquets désordonnés: 0.0 %
Score MOS estimé: 3.8
Speed test statistics
———————
Vitesse de téléchargement: 2275856 bps
Vitesse d’upload: 411496 bps
Qualité de service: 11 %
Type de test de téléchargement: HTTP
Type de test d’upload: HTTP
Délai TCP maximum: 337 ms
Pause moyenne de téléchargement: 24 ms
Durée minimum d’aller-retour au serveur: 45 ms
Durée moyenne d’aller-retour au serveur: 46 ms
Bande passante estimée pour le téléchargement: 2275856bps
Concurrence des routes: –
Idle TCP forcé: –
Vitesse de route maximum: 11650664bps
bonjour,
Malheureusement ces tests ne donnent que peu d’informations. En l’absence de données notament sur l’architecture réseau de votre fournisseur, je ne peux que tirer de conclusions hatives.
Vous pouvez me passer en privé (via le formulaire contact) son nom, il y a des chances que je connaisse son infrastructure.
Ce que je vois sur les éléments, c’est qu’il y a un peu de perte de paquets. En G711, ce taux n’est pas génant, mais en G729 ça l’est.
Il est vrai que je recommande vivement d’alimenter les postes IP via un switch POE et non pas par un transfo (qualité aléatoire, et plus grande sensibilité à la qualité de la source de courant). Le switch et routeur doivent être branchés sur un onduleur.
@+
Mathias
Bonjour Vanino,
Pouvez-vous me passer votre adresse email afin que je puisse vous répondre ?
@+
Mathias
Vous n’avez pas accès à mon adresse email dans votre CMS ? le champ email de commentaires dit : Mail (will not be published) (required)
je ne veux pas mettre mon adresse dans un commentaire…
Avez-vous un profil skype ?
not unless you installed a program for them …aside from the vpn client. However they can get a ton of info. Your public ip, where you went, how much data you moved, and which protocols you used.
Bonjour,
Je viens de voir votre article et il se trouve que vous allez peut être m’aider à comprendre une erreur qui a pu se produire sur mon lieux de travail. Je travaille en centre d’appels et je voulais savoir s’il était possible qu’une erreur survienne lors d’un appel externe c’est à dire que le deuxième numéro rattaché au client soit composé en même temps? Car nous nous sommes rendus compte d’une erreur survenue et je ne trouve pas le moyen de l’expliquer.
Pouvez vous m’aider ?
Merci d’avance
Aline
Bonjour Aline,
Je résume votre situation afin de vérifier ma bonne compréhension :
- lors d’un appel externe généré automatiquement ou par clic sur la fiche client, les 2 numéros du clients sont appelés simultanément.
Cela ressemble à un problème lié à la programmation du CTI ou de l’algorithme générant les appels.
J’ai besoin de quelques informations :
- comment l’appel est généré ?
- votre système gère t’il les appels prédictifs ?
Cordialement,
Mathias