+1
La bonne QoS c’est pas de QoS.
Avec le débit des liens de nos jours, mieux vaut shaper la partie data en lui
enlevant X%, pour les garantir pour la voix.
> Le 10 mars 2023 à 09:45, Gérald Vannier a écrit :
>
> Très bons points de Christophe.
>
> Eventuellement également vérifier des pb de MTU (découpe/réassemblage de
> paquets...).
>
> Sinon, la technique dichotomique classique si c'est possible dans ton
> architecture : tcpdump/prise de traces réseau sur un appel avant et après les
> équipements principaux pour t'aider à localiser si un équipement est
> problématique sur ton chemin (wireshark pour rejouer les flux audio pour une
> vérification facile)
>
> Gérald
>
> -Original Message-
> From: frnog-requ...@frnog.org On Behalf Of Stephane
> Perez
> Sent: jeudi 9 mars 2023 20:17
> To: Mickael Hubert ; Christophe DABADIE
>
> Cc: frnog-t...@frnog.org
> Subject: Re: [TECH] Re: [FRnOG] Discussion technique : gestion gigue serveur
> VOIP | [TECH] || frnog-t...@frnog.org
>
> Bonjour christophe,
>
>
>>> Environ 1000 utilisateurs (multisites) sont reliés aux serveurs VoIP
>>> pour environ 400 communications SIP simultanées.
>>> Nous rencontrons de plus en plus de dégradations sur la qualité des
>>> communications VoIP (mauvaise qualité et décalage voix, blanc,
>>> etc..)
>>>
>>
>
> 400 comms simultanées, ça doit tourner entre 38 et 40 Mbits/s avec du G711
> sans compter la signalisation, est-ce qu'une partie des comms passent déjà ou
> peuvent passer sur du G726 / G729 ou équivalents ?
>
> En terme de QoS, la problématique des pare-feux est que majoritairement ils
> n'intègrent pas de gestion de QoS sur la partie State-machine, ils traitent
> la QoS au niveau de l'interface mais il faut considérer au niveau du routeur
> le queueing qui peut persister.
> Une des grandes questions est de savoir sur une infra où la QoS de bout en
> bout ne peut être garantie, où est-ce que la Gigue et packet loss (blancs)
> peut se produire et surtout dans quelle direction ?
> De ma fenêtre les premiers symptômes décrits ressemblent à une QoS où le lien
> WAN bufferise dans les deux sens et vu qu'il n'y a pas de priorisation voix
> certains paquets RTP sont mis dans la file d'attente du routeur opérateur
> dans le sens montant mais probablement en descendant aussi.
>
>> Après analyse de nos équipements et investigations, nous pensons que
>> cela
>>> peut être lié à la gestion de la QoS coté WAN ainsi que la gigue et
>>> la latence.
>>>
>>> Existe-t-il des solutions pour optimiser la gigue et la latence ?
>>>
>>
>> A priori une des premières cibles serait de :
>
> - Mesurer précisément la bande passante de la partie Voix pour ajuster
> les valeurs de QoS
> - Vérifier si certains flux VoiP (RTP) ne passent pas dans la mauvaise
> classe de trafic en sortie
> - Garder une marge de secours par rapport à la bande passante théorique
> et limiter la BP de la DATA en sortie
> - Effectuer un Shaping entrant sur le flux Data Internet -> DC qui n'est
> pas de la VoIP pour limiter la bande passante utilisée et limiter les
> risques de queueing au niveau du réseau opérateur.
> - En gros. 1 Gbits / s de BP théorique
> - On garde 100 Mbits sur la classe VOIP
> - On mets 700 Mbits en shaping Data entrant sur le premier équipement
> derrière le routeur opérateur ce n'est pas parfait mais tu limite pour
> les
> flux data TCP la vitesse à laquelle les segments sont envoyés au client
> interne et donc on abaisse "heuristiquement" les gros blocs entrants
> - Par ailleurs sur le FW faire une modification de TCP window pour
> les flux data, etc.
>
> Voilà pour mes idées.
>
> a+
> --
> ---
> Stephane Perez
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
---
Liste de diffusion du FRnOG
http://www.frnog.org/
