[TECH] Re: [FRnOG] Discussion technique : gestion gigue serveur VOIP | [TECH] || frnog-t...@frnog.org
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. Mais d'après ce que tu décris, le problème m'a l'air global à l'ensemble de tes clients, ce qui suppose que le problème provient plus d'un goulot d'étranglement (ta liaison WAN) et pas les X liens de tes clients. Sais-tu si le prob est plutôt en upload ou en download ou les deux sur ton WAN ? Car pour l'upload, tu pourrais y faire qqch, mais en download ce n'est pas possible, car on parle de flux RTP donc UDP. Sinon sur de la VoIP, je fais de la QOS type CBQ, avec des queues et le truc sympa avec cette QOS c'est que c'est dynamique. Bonne fin de journée Le jeu. 2 févr. 2023 à 00:35, Christophe DABADIE < christophe.daba...@recom.fr> a écrit : > Bonjour, > > Nous hébergeons des serveurs VOIP (environ 150 VM) dans un Datacenter > (infra haute dispo sous Vmware Esx). > Notre FAI fournit une liaison fibre 1 Gb. > > Nous gérons la QoS sur la VoIP sur nos firewalls au datacenter et sur le > réseau LAN de l'infra des serveurs VoIP. > Par contre, notre FAI ne permet pas de gérer la QoS sur leur routeur fibre > côté WAN. > > 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..) > > 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 ? > > Merci pour votre retour d'expérience. > > Cordialement, > > Christophe Dabadie > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
[TECH] Re: [FRnOG] Discussion technique : gestion gigue serveur VOIP | [TECH] || frnog-t...@frnog.org
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. Mais d'après ce que tu décris, le problème m'a l'air global à l'ensemble de tes clients, ce qui suppose que le problème provient plus d'un goulot d'étranglement (ta liaison WAN) et pas les X liens de tes clients. Sais-tu si le prob est plutôt en upload ou en download ou les deux sur ton WAN ? Car pour l'upload, tu pourrais y faire qqch, mais en download ce n'est pas possible, car on parle de flux RTP donc UDP. Sinon sur de la VoIP, je fais de la QOS type CBQ, avec des queues et le truc sympa avec cette QOS c'est que c'est dynamique. Bonne fin de journée Le jeu. 2 févr. 2023 à 00:35, Christophe DABADIE < christophe.daba...@recom.fr> a écrit : > Bonjour, > > Nous hébergeons des serveurs VOIP (environ 150 VM) dans un Datacenter > (infra haute dispo sous Vmware Esx). > Notre FAI fournit une liaison fibre 1 Gb. > > Nous gérons la QoS sur la VoIP sur nos firewalls au datacenter et sur le > réseau LAN de l'infra des serveurs VoIP. > Par contre, notre FAI ne permet pas de gérer la QoS sur leur routeur fibre > côté WAN. > > 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..) > > 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 ? > > Merci pour votre retour d'expérience. > > Cordialement, > > Christophe Dabadie > > > > --- > 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
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/
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/
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/
Re: [TECH] Re: [FRnOG] Discussion technique : gestion gigue serveur VOIP | [TECH] || frnog-t...@frnog.org
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/
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/
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/