Re: [TECH] [FRnOG] Discussion technique : gestion gigue serveur VOIP | [TECH] || frnog-t...@frnog.org
Bonjour , Une autre solution si il y a 400 appels c'est de limiter le premier trunk a 200appels et faire déborder le second trunk sur l ipbx de backup qui a son propre wan sur un autre opérateur bien sûr et donc d'avoir une répartition de charge. Ensuite voir si le problème est toujours sur l ipbx nominal et sur l'ipbx de backup. Cela permet de dégrossir un peu le problème. Si le problème disparaît sur les deux trunk c'est qu il y a effectivement de la congestion sur le nominal. Bonne soirée Richard Le ven. 10 mars 2023, 10:07, Paul Rolland (ポール・ロラン) a écrit : > Hello, > > On Fri, 10 Mar 2023 10:03:47 +0100 > David Ponzone wrote: > > > +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. > > Ou regarder si c'est pas plus simple d'avoir un lien dedie a la voix... > > Paul > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [TECH] [FRnOG] Discussion technique : gestion gigue serveur VOIP | [TECH] || frnog-t...@frnog.org
Hello, On Fri, 10 Mar 2023 10:03:47 +0100 David Ponzone wrote: > +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. Ou regarder si c'est pas plus simple d'avoir un lien dedie a la voix... Paul --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [TECH] [FRnOG] Discussion technique : gestion gigue serveur VOIP | [TECH] || frnog-t...@frnog.org
+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/
RE: [TECH] Re: [FRnOG] Discussion technique : gestion gigue serveur VOIP | [TECH] || frnog-t...@frnog.org
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/
