Separation flux data/voip

[TaHu]

Salutations,

Je vais mettre en place une plateforme Asterisk avec plusieurs téléphones ToIP hardphone. Au niveau de l'architecture, chaque station de travail sera connecté derrière son téléphone en rj-45 ethernet, et chaque téléphone sera connecté sur un switch PoE. Je compte séparer les flux data/voip via 2 vlans différents (le hardphone gere le 802.1q).Jusque là rien d'extraordinaire.

Ma question se pose sur le cas de situation suivant: si j'ai un utilisateur qui ne souhaite pas avoir de hardphones, mais simplement un softphone sur sa station de travail, il va donc falloir que la carte réseau de son poste gère le 802.1q, correct ?

Si c'est pas le cas, ce qui se passera c'est que l'utilisateur de softphone passera ses appels voip dans le vlan data, et du coup ça, ça me plait beaucoup moins.

Merci d'avance pour vos confirmations/infirmations là dessus

[hb22]

Je ne pense pas qu'il y ait une solution. Ton téléphone et ton PC ont la même carte réseau et donc seront dans le même VLAN. Mais je n'ai jamais eu de problème de qualité de communication sur un LAN. Les problèmes sont sur le WAN.
Si, quand même, tu veux gérer de la QoS sur le LAN il faut marquer les trames VOIP et paramétrer les Switch en conséquence.

[TaHu]

Ok merci pour l'info. Les problèmes sur le WAN dont tu parles sont mutuels aux deux cas que j'ai cités (que je sépare le flux data/voip ou non sur mon LAN) ? Ou ils apparaitront plus dans un cas que dans l'autre ?

Personnellement Les types de problèmes que j'avais déjà rencontré au niveau Wan en tant qu'utilisateur était du type écho, qualité de l'appel moindre, etc...

[hb22]

Il faut faire un choix judicieux du type de lien pour acheminer la VOIP et prévoir du secours.
Les critères sont :
- Le codec utilisé
- Le nombre de communications simultanées
- Les conditions de repli acceptées par le client en cas de panne
3 exemples :
1) Site avec ADSL non dégroupé à 2500m du dslam. Un lien Free sur un routeur avec QoS pour la téléphonie et l'internet. L'Opérateur renvoi les communications vers un mobile en cas de panne. 6 téléphones et 3 communications simultanées en g711.
2) Site avec ADSL dégroupé à 250m du dslam. Un lien ADSL Free pour la téléphonie + un lien ADSL orange pour l'internet et le secours. 12 téléphones et 5 communications simultanées en g711.
3) Site dégroupé à 1000m du dslam avec un lien SDSL 2M pour la téléphonie et un lien ADSL Free pour l'internet et le secours. 40 téléphones et 12 communications simultanées en g711.

[therebel23]

Il me semble (sous linux en tout cas, donc ça doit se faire sous windows), qu'à partir du moment où le 802.11q est installé et géré par l'OS, tu peux avoir deux interfaces réseau (un réelle et une virtuelle correspondant à un VLAN ID différent), donc tu peux tout à fait demander à la voix de passer par le VLAN voix.

Mais comme dit hb22, le problème ne se pose pas sur le LAN ..

[therebel23]

Pour les problèmes d'écho et de qualité moindre, c'est un problème de QoS..

[F6HQZ]

Pour les problèmes d'écho et de qualité moindre, c'est un problème de QoS..

Bonjour à tous,

Pas d'accord.

Les soucis d'écho sont mis en évidence par la durée de traitement de l'information aller/retour entre deux correspondants et la réinjection du signal d'origine vers sa source suite à un défaut sur la ligne ou l'équipement du correspondant (diaphonie, couplage acoustique micro/écouteur, couplage parasite entre câbles, carte son de qualité médiocre, absence d'anti-écho local ou de différentiel sur un poste ou une carte analogique, rupture d'impédance de ligne analogique, etc...) et donc son décalage dans le temps (délai).

Ce délai n'est pas tant celui de la propagation des paquets dans les différents réseaux IP parcourus (peu significatif pour l'oreille humaine), mais principalement dû à la quantité de codecs traversés suite à l'accumulation d'un nombre important d'unités de traitement le long du trajet (plusieurs gateways, utilisateur, opérateur, tampons "jitter buffer" un peu trop dimensionnés, par exemple).

Il y a toujours eu des délais du temps de l'analogique, à cause du passage de 2 paires de fil de cuivre (micor et écouteur) à 1 seule paire (paire téléphonique abonné) mélangeant les signaux audio émission et réception, sur les très longue lignes internationales ou via satellites (analogiques eux aussi à cette époque).
Les opérateurs utilisaient alors des anti-écho hybrides terriblement chers, et ne résolvaient pas toujours tous les cas de figures, mais s'en sortaient pas mal tout de même.
La règle était de ne pas trop amplifier mais plutôt de diminuer un peu le gain de chaque élément amplificateur traversé pour éviter un désastre...

Côté abonné, le téléphone possédait un transformateur ou un système hybride qui atténuait le retour du signal reçu vers son origine, tout en laissant passer sans trop d'atténuation le signal local vers la ligne. C'était une affaire de compromis. Cependant, même avec des systèmes médiocres car trop bon marché, les utilsateurs ne s'en rendaient pas compte sur des liaisons courtes ou nationales, car le signal réinjecté était quasi immédiatement entendu avec un très faible décallage, et l'oreille humaine parfaitement habituée à entendre la voix de son propriétaire en reflexion sur des murs ou obstacles naturels.

La voix sur IP, ou plutôt, dans notre cas, la téléphonie sur IP a changé la donne, car, la somme des délais de traitement/acheminement évoqués ci-dessus, multipliés par deux puisque résultant d'un "aller/retour" ont "allongé" cette valeur, qui devient donc complètement décelable voire insupportable par un utilisateur.

Si les défauts constatés dans votre cas sont une qualité acoustique moins bonne, il faut aller contrôler les transducteurs utilisés (micro, écouteurs), les distorsions des équipements analogiques ou de conversion traversés et pour l'echo, tenter de supprimer les traitements intermédiaires (impossible dès que le signal quitte votre réseau local ou votre bâtiment), changer d'opérateur pour comparer, utiliser des DSP anti-écho sur vos cartes interfaces de lignes téléphoniques (de préférence aux solutions purement logicielles mais parfois mieux que rien) si c'est pour vous en protéger de votre côté, et utiliser des terminaux équipés des combinés et casques de qualité pour améliorer les choses du côté de votre correspondant.

Cordialement,
Francois

[plouf]

Bonjour à tous,

Pour Tahu, nous avons été confronté au même cas que toi, à savoir des utilisateurs travaillant uniquement avec des softphones et nous avons réglé notre problème en créant un VLAN spécifique au softphone.

Pour F6HQZ, Visiblement tu as quelles notions sur l'écho... Te serait-il possible de fournir à l'ensemble la communauté un "wiki" sur l'écho et les solutions pour y remédier?

Personnellement, c'est sur l'écho que je me casse les dents systématiquement et ce sans pouvoir donner de réelles explications...

[hb22]

Pour Tahu, nous avons été confronté au même cas que toi, à savoir des utilisateurs travaillant uniquement avec des softphones et nous avons réglé notre problème en créant un VLAN spécifique au softphone.

Tes softphones étaient installés sur des PCs sous Windows ?
Quel softphone ?
Tu as plus de détail sur la configuration ?

[fastm3]

Bonjour à tous,
Pour Tahu, nous avons été confronté au même cas que toi, à savoir des utilisateurs travaillant uniquement avec des softphones et nous avons réglé notre problème en créant un VLAN spécifique au softphone.

Ca ca m'interesse si avec un poste windows et avec une seule interface , on peut faire ca simplement. Tu peux expliquer ta config et le softphone que tu utilises ?
Fastm3

Edit: grillé par hb22...