+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/