+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 <gerald.vann...@mmtt.fr> 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 <frnog-requ...@frnog.org> On Behalf Of Stephane 
> Perez
> Sent: jeudi 9 mars 2023 20:17
> To: Mickael Hubert <mick...@winlux.fr>; Christophe DABADIE 
> <christophe.daba...@recom.fr>
> 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/

Répondre à