Clientes provedor de telefonia alegando alta latência em UDP, como faço para testar?

Question

Um cliente nosso usa uma solução de telefone hospedada para o seu call center de 50 agentes. Eles usam um discador hospedado que faz as ligações, uma vez que a conexão é feita, a chamada é passada para o usuário do meu cliente, onde ele pega a conexão em uma interface de telefone 3CX.

Coisas bem padronizadas.

A empresa de hospedagem está alegando que está vendo uma latência de 100 a 200 ms para todos os telefones.

Ao testar uma ida e volta TCP [tcping.exe ], estou recebendo subms 10 ms vezes. Eles bloqueiam o ICMP. O provedor de hospedagem está dizendo que este não é um teste válido, pois os dados de VOIP são UDP.

Eu entendo que o UDP poderia estar sendo moldado de forma diferente ou roteado de forma diferente, mas parece bastante improvável. A equipe de TI de hospedagem é muito 'nós temos centenas de clientes e sua latência é ok, este é o seu problema' que eu posso entender, mas isso não me ajuda muito. Como não consigo controlar um ouvinte UDP do lado deles, não sei como demonstrar como e onde o atraso do UDP pode estar chegando.

O equipamento no local é um par de Cisco 2960 que se conecta a um Draytek Vigor. O Draytek se conecta ao Cisco p887 fornecido / gerenciado pelo ISP.

O uso da largura de banda é de aproximadamente 20% durante o período de chamada. Todos os testes ICMP para sistemas externos mostram boas viagens de ida e volta, geralmente não além de 5ms-30ms, dependendo de onde estou indo.

Pensamentos sobre como avançar isso?

    

Answer 1

Embora a questão mencionada aqui tenha parado de acontecer sem motivo óbvio, a resposta à minha pergunta original - como demonstrar efetivamente a qualidade da rede e a ida e volta para o tráfego SIP UDP - é usar um SIP OPTIONS como um ping.

Breve discussão aqui: link

Teste / demonstração do Powershell aqui: link

e eu implementei isso através do nosso monitoramento PRTG existente (aqui: link )

Infelizmente, o host remoto não foi configurado corretamente, por isso recebemos um 404 e não um 200, mas ainda podemos usá-lo para demonstrar o tempo de ida e volta, embora o PRTG sempre mostre isso como erro.

    

Answer 2

Se você tiver um host Linux em cada extremidade da rede, poderá instalar o iPerf ou Thrulay para executar um teste de rede. O Thrulay tem a vantagem de exibir o jitter durante o teste.

Você também pode assistir a algumas estatísticas de rede em cada extremidade durante seu teste ou tráfego real usando este snippet bash:

function watch_net()
{
/usr/bin/watch -d -n10 --no-title 'netstat -s | grep "\ \ \ [0-9]" | sort -rn'
}
watch_net