Por que o asterisco (e outros sistemas) sentem a necessidade de regenerar o DTMF em chamada?

Question

Estou usando o Asterisk para interagir com dispositivos de telefonia analógica que podem ser programados e testados com interação DTMF.

Alguns desses caras falam rapidamente. Muito depressa, você poderia argumentar convincentemente; Eu estaria bem com você lá. E ainda assim, o Asterisk é perfeitamente capaz de ouvir os timbres, e se eu tiver a sorte de obter um fluxo puro com áudio DTMF em banda, posso reconhecer tons muito rápidos mesmo com sucesso.

O problema surge quando o Asterisk (ou outro sistema de telefonia) decide que precisa reconhecer e regenerar o DTMF. Eu entendo que isso é importante quando se traduz, por ex. para / de DTMF fora de banda, mas não sei por que parece ser a ação padrão para fazer isso, e em particular porque é frequentemente regenerado com longas durações (por exemplo, 100ms; felizmente, no Asterisk, isso pode ser alterado, embora possa envolver uma recompilação) que é quase garantido como perda de dígitos. Outros reportaram problemas em que a conversão em banda para fora da banda resultou em dígitos duplicados, mesmo que a conversão não tenha sido necessária.

Então, minha pergunta é: por que isso é o M.O. para sistemas de telefonia? Por que não deixar o DTMF da chamada sozinho, a menos que a tradução seja explicitamente exigida?

    

Answer 1

Faça uma gravação em CD de alta fidelidade da sua música favorita.
Grave-o usando o microfone mais barato que você encontrar. Codifica a gravação com um péssimo codec de áudio de 8 bits otimizado para palavras faladas.
Reproduza a gravação através de um alto-falante barato (e mexa os fios).

Se você ouvir o CD e a cadeia acima, lado a lado, você ouvirá o quanto as coisas ficam distorcidas na telefonia. Agora imagine que, em vez de uma música, você gravou os tons DTMF e estava tentando reproduzi-los e fazer com que um computador os reconhecesse.

É por isso que a maioria dos sistemas VoIP recodifica os tons DTMF usando um canal fora de banda (como o RFC 2833) - a compactação, o jitter de rede, a latência e a perda potencial de pacotes tornam o DTMF codificado em áudio propenso a falhas.
Ao enviar os tons DTMF como dados fora de banda, eles podem ser reinseridos no fluxo de áudio no ponto de extremidade mais próximo da PSTN, minimizando o risco de que os tons sejam desconfigurados.

Por que 100 ms? Como algumas linhas telefônicas ou terminais remotos têm problemas com durações de tons mais curtos (se você já ligou para um sistema de tons de toque em uma linha de terra barulhenta, provavelmente segurou um botão por alguns segundos em frustração para fazer o sistema reconhecer tom).
(100ms é provavelmente muito longo - 20-50ms é mais que suficiente)

Você não tem para usar sinalização fora de banda - sistemas VoIP úmidos lidam com sinalização em banda (você normalmente precisa definir um parâmetro em seu telefone e seu servidor para fazer isso, e você deve usar codecs de alta qualidade (ou desabilitar a compressão por completo se você quiser uma imagem real da confiabilidade). A maioria das pessoas que os implementa prefere usar o RFC 2833 (e recodificar o DTMF recebido dentro da banda) porque é substancialmente mais confiável.