Comunicação de voz sobre TCP/IP

https://stackoverflow.com/questions/1946731

20-09-2019
|

Pergunta

Atualmente, estou desenvolvendo aplicativos usando o DirectSound para comunicação em uma intranet. Eu tive uma solução de trabalho usando o UDP, mas meu chefe me disse que quer usar o TCP/IP por algum motivo. Eu tentei implementá -lo da mesma maneira que o UDP, mas com muito pouco sucesso. O que eu recebo é basicamente apenas barulho. 20% é o som gravado e o resto é apenas um ruído estranho.

Meu palpite, pelo motivo, é que o TCP precisa ler todos os dados aceitos várias vezes até obter o som final que posso reproduzir.

Agora duas perguntas:

Estou nas faixas certas? É até uma boa ideia usar o TCP/IP para esse tipo de aplicativo (conferência de voz)?
Estou fazendo isso em C#, mas não acho que isso seja específico da linguagem.

Solução

Não, usar o TCP é um Terrível idéia. O UDP, neste caso, terá um desempenho muito melhor e os pacotes caídos / saídos de sincronização não importam!

Se o seu chefe não conseguir entender os detalhes técnicos, diga a ele que praticamente todos os sistemas VoIP atualmente existem o uso UDP e deve haver uma razão: Skype, Ventrilo, Teamspeak, World of Warcraft, etc.

Outras dicas

Para responder a essa pergunta corretamente, sinto que alguns dos principais conceitos de VoIP precisam ser explicados.

Em primeiro lugar, o UDP é o mais popular e amplamente utilizado Método para VoIP. Lembre-se de que uma rede de IP é comutada de pacotes e é ideal para comunicação de dados que não seja de tempo real e não projetada para VoIP em tempo real.

Para superar esse problema, o UDP é usado. O UDP não é confiável e sem conexão protocolo. Embora o UDP perca os pacotes, o áudio da fala ainda pode ser entendido, o cérebro compensará efetivamente os erros. É por isso que você ainda pode falar com alguém em um telefone com 3 barras de sinal.

Perda de pacotes e comprimentos de explosão

A perda de pacotes geralmente ocorre devido ao congestionamento; portanto, a quantidade de perda de pacotes dependerá de quão bem equipado a rede está. A perda de pacotes no VoIP usando UDP ocorre com mais frequência em comprimentos de explosão. UMA comprimento da explosão é um número de pacotes perdidos em sucessão na transmissão, então um comprimento de estouro de 3 significa que 3 pacotes seguidos foram perdidos.

Compensação de perda de pacotes

Onde a perda de pacotes ocorre técnicas simples de compensação de perda de pacotes e a qualidade do serviço não será seriamente efetuada, a fala ainda poderá ser entendida mesmo nos casos em que 20 a 30% dos pacotes são perdidos. Os métodos incluem:

Repita o último pacote recebido com sucesso.
Preencha - jogue silêncio na lacuna.
Splicing - efetivamente, pode -se pensar em remover a lacuna causada pelo comprimento da explosão, empurrando o início e o final da lacuna.
Interpolação - Use o conhecimento da fala antes e depois para interpolar pacotes perdidos dentro da diferença, por exemplo, a média entre os pacotes recebidos com sucesso antes e depois do comprimento da explosão.

Um bom método de redução do tamanho dos comprimentos de explosão é conhecido como intercalação e, portanto, aumentar a QoS é intercalação. Uma função de intercalação em bloco leva a fala e a divide em um conjunto de pacotes. Esses pacotes são carregados em um buffer a forma de uma matriz (por exemplo, 4 por 4), uma função é usada girar ou transpor o buffer para que os pacotes não estejam em ordem. No lado do receptor, o inverso desta função é usado para reordenar os pacotes. Este método é simples e eficaz, veja a figura abaixo:

TEXTO DE ALT HTTP://IMG688.IMAGESHACK.US/IMG688/3962/CAPTUSTNK.PNG

Recentemente, criei um pequeno aplicativo VoIP. sobre uma LAN sem fio usando UDP. Não tenho muita certeza dos requisitos exatos do seu aplicativo, mas geralmente os aplicativos VoIP (entre dois hosts) podem ser implementados da seguinte forma:

TEXTO DE ALT HTTP://IMG338.IMAGESHACK.US/IMG338/6566/CAPTUREEC.PNG

No diagrama, o aplicativo define seu próprio design de pacotes. O cabeçalho pode ser apenas o número do pacote (usando 1 byte) e a carga útil dos dados de áudio (n bytes, tamanho da carga útil). Definir isso permite melhores técnicas de compensação de pacotes e permite um fluxo lógico para programação.

TCP é a má escolha por VoIP por vários motivos. Um rápido Google de 'TCP VoIP' revela por que o primeiro resultado apoiando isso Visão.

O TCP é um protocolo confiável e orientado por conexão, isso significa que os pacotes perdidos na transmissão serão em algum momento se ressentirão do outro host. Essa retransmissão é impraticável para serviços em tempo real e aumentará o jitter, a latência e possivelmente aumentará a perda de pacotes (em alguns casos).

Respostas às suas perguntas

O que eu recebo é basicamente apenas barulho. 20% é o som gravado e o resto é apenas um ruído estranho.

O TCP não deve introduzir ruído, ele deve introduzir jitter e latência. Os soquetes tendem a ter um tempo de tempo limite definido automaticamente, você define o tempo de tempo limite? Se não o que acontece, por que você não recebe o pacote correto a tempo antes da reprodução?

Estou nas faixas certas? É até uma boa ideia usar o TCP/IP para esse tipo de aplicativo (conferência de voz)?

Não faz NÃO Use TCP/IP, não é uma boa ideia. Parece que seu gerente assumiu incorretamente que qualquer perda de pacotes é uma coisa terrível.

Resumo

Alguns conceitos -chave gerais foram mostrados aqui para tentar ajudar o máximo possível para esse problema específico, no entanto, isso não deve ser considerado exaustivo. Verifique se o sistema VoIP também usa alguns princípios subjacentes das técnicas de codificação/processamento de sinal de fala.

Os pontos principais a serem lembrados são:

Use UDP para VoIP.
Implementar compensação de perda de pacotes
técnicas.
Um intercaleaver de bloco é simples e
Método eficaz para aumentar a QoS.

Eu espero que isso ajude.

Quando as pessoas estão falando sobre a pilha TCP/IP, geralmente significam "toda a pilha de protocolos da Internet", que inclui UDP. Talvez isso faça seu gerente feliz ;-)

TCP/IP funcionaria; ele fornecerá os dados. Pode não ser tão eficiente quanto o UDP se você não estivesse se preocupando com a perda de pacotes, mas poderá transmitir os dados muito bem.

TCP/IP sobre roteadores e redes modernos é muito rápido. É mais do que capaz de lidar com a voz sobre a comunicação IP. (Eu mesmo fiz isso)

Meu palpite é que sua implementação tem alguns bugs relacionados a tamanhos de buffer.

Não há razão para que você deva obter ruído sobre o TCP e, portanto, parece um bug no seu código. De fato, a maioria dos meios de transmissão que recebemos (pense no YouTube) é feita no TCP.

O problema com o TCP é o jitter. A entrega do seu fluxo de dados será adiada até que todos os pacotes tenham sido recebidos e reordenados. Agora, já que a entrega tardia para a multimídia é tão boa quanto nenhuma entrega. Normalmente, essa é uma escolha mais pobre do que simplesmente interpolar o quadro ausente. Como mencionado acima, se a perda de pacotes for mínima e sua rede rapidamente, ela não deve fazer diferença.

RTP/RTCP Over UDP é normalmente usado para a entrega do fluxo de mídia. O RTP inclui coisas como números de sequência no cabeçalho do pacote que permitem a inserção de pacotes tardios na posição correta, sempre que possível. O RTCP possui uma função de relatório que permite que o codec se adapte às situações em que a perda de pacotes começa a se tornar maior. RTP/RTCP, portanto, fornece algumas funcionalidades TCP.

Para a mídia de streaming sobre o TCP, isso pode ser resolvido facilmente por ter um grande tampão de instabilidade. Isso adiciona latência, mas para streaming unidirecional, isso não é um problema. A latência, no entanto, é um grande problema no streaming bidirecional.

Uma vantagem principal do TCP, no entanto, é que ele atravessa os firewalls mais facilmente que o UDP. Uma sessão de TCP é estabelecida, o firewall está aberto para os dados enviados e recebem. Isso é mais complicado para o UDP, especialmente quando se espera um fluxo de dados recebidos. Existem maneiras de contornar isso, mas elas podem ser complicadas e podem envolver a compreensão do protocolo de controle da sessão (como SIP ou RTSP).

Desenvolvi uma solução IP de operação de voz para uma comunicação duplex com o Wave-API para o controle remoto de um tranceador de rádio amador. Funciona bem com o UDP e também com TCI/IP! Eu uso o buffer de 512 bytes a cada 64 ms, dados de onda mono de 8kHz. Eu tenho trabalho no último mês entre os EUA e a Europa Verry sobre o TCP/IP! Agora, minha pergunta: o Wave-Api não funciona correto com o Win7, portanto, acho que dirija a melhor maneira. Apenas em Tim, eu tenho trubble com a implementação no Managed DirectX9, meu aplicativo é vb.net 2008. Pesquiso links para documentação para obter uma saída de streaming com o DirectSound - gerenciouDDirectx9 para vb.net.

Existem algumas razões principais pelas quais os dados de transmissão ao vivo usam o UDP. O maior dos quais é receber dados tardios é tão bom quanto não recebê -los, e atrasar o fluxo para retransmissão certamente não é uma boa ideia. Para VoIP, você tem uma tolerância à latência de cerca de 150ms. Qualquer pacote de voz atrasado mais do que isso se torna perceptível para os usuários.

Quanto ao por que você está recebendo ruído, como está lidando com pacotes de chegada tardia devido a retransmissões?

Depende do tipo de rede subjacente, se você tiver Ethernet com 99,9% de confiabilidade, meu palpite é que o TCP se sairia bem. No entanto, se você estiver fazendo isso, digamos 802.11, o TCP seria uma ideia não tão boa.

Você pode pedir ao seu chefe um motivo específico para usar o TCP e, em seguida, implementar esse serviço específico, por exemplo, confiabilidade básica ou um serviço de correção de erros sobre o UDP. Você também pode olhar para o RTP. (http://en.wikipedia.org/wiki/real-time_transport_protocol)

TCP deve não introduzir qualquer ruído. Jitter e atraso, sim (especialmente se seus links estiverem com perdas); Mas nenhum barulho. Algo é suspeito com sua programação.

BTW, concordo que o UDP é muito mais apropriado que o TCP neste caso.

A maioria dos aplicativos de voz é construída usando o protocolo RTP, que é fluxo sobre a porta UDP. Bem, a maioria deles com suporte ao codec para garantir que a mídia seja compactada antes do fluxo de uma extremidade para outra. Discuta com seu chefe sobre os requisitos de largura de banda.

Tenho certeza de que a maioria dos streaming de áudio/vídeo usa UDP ... você pode perder alguns pacotes, mas nunca notaria.

Se você está recebendo barulho, provavelmente está invadindo a parte do seu buffer que preencheu com sucesso com pacotes e jogando buffer vazio/não inicializado.

Quanto mais lento é TCP que o UDP? Com o TCP, você está obtendo um atraso de retransmissão se algum pacotes chegar fora de ordem ou corromper. Eu direi que existem maneiras de otimizar o TCP, para que haja menos atraso. Tanto no Linux quanto no Winsock, há uma opção TCP_NODELAY para usar. Além disso, um codec compacto ajudará como G.729 a manter o tamanho da carga útil baixo. Como a transmissão é baseada nos pacotes recebidos (em ordem - TCP), deve -se se concentrar na otimização do tamanho do pacote para ser pequeno o suficiente para reduzir o atraso de retransmissão, mas grande o suficiente para manter um fluxo de qualidade. Um bom programa TCP VoIP teria a capacidade de variar a qualidade da codificação e o tamanho do pacote em tempo real, onde o remetente teria que sinalizar para o receptor da alteração. Mas realmente o único aviso de usar o TCP em tempo real é que é menos provável que seja bloqueado pelos firewalls.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow