RE: [TECH] Re: [FRnOG] Discussion technique : gestion gigue serveur VOIP | [TECH] || frnog-t...@frnog.org

2023-03-10 Par sujet Gérald Vannier
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/


Re: [TECH] Re: [FRnOG] Discussion technique : gestion gigue serveur VOIP | [TECH] || frnog-t...@frnog.org

2023-03-09 Par sujet Stephane Perez
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/


Re: [TECH] Re: [FRnOG] Discussion technique : gestion gigue serveur VOIP | [TECH] || frnog-t...@frnog.org

2023-03-07 Par sujet Raphael Mazelier



On 07/03/2023 17:08, Mickael Hubert wrote:

Bonjour Christophe,
Je ne sais pas si tu as eu ta réponse depuis le temps...
Si ton flux passe par l'Internet, c'est mort, tu n'auras pas de QOS de bout
en bout, car le tag QOS sera forcément cassé par les X providers qu'il va
traverser.


Sur Internet tu n'auras aucune garantie en effet. Si ton path est clear 
la voip marchera très bien. Mais dès que tu auras un peu de latence, de 
gigue, ou du packet loss ca va moins bien marcher forcément.


pas de secret il faut analyser le chemin et faire des mesures (voir 
mettre en place des sondes actives pour grapher tout cela).



--
Raphael Mazelier

---
Liste de diffusion du FRnOG
http://www.frnog.org/