Comunicazione vocale su TCP/IP

https://stackoverflow.com/questions/1946731

20-09-2019
|

Domanda

Attualmente sto sviluppando un'applicazione utilizzando DirectSound per la comunicazione su una intranet.Avevo una soluzione funzionante che utilizzava UDP, ma poi il mio capo mi ha detto che per qualche motivo voleva utilizzare TCP/IP.Ho provato a implementarlo più o meno allo stesso modo di UDP, ma con pochissimo successo.Quello che ottengo è fondamentalmente solo rumore.Il 20% è suono registrato e il resto è solo rumore strano.

La mia ipotesi è che TCP debba leggere più volte tutti i dati accettati finché non ottiene il suono finale che posso riprodurre.

Ora due domande:

Sono sulla strada giusta?È una buona idea utilizzare TCP/IP per questo tipo di applicazione (una sorta di conferenza vocale)?
Lo sto facendo in C# ma non penso che questo sia specifico della lingua.

Soluzione

No, utilizzando il protocollo TCP è un terribile idea. UDP in questo caso si esibirà molto meglio e caduto / out dei pacchetti di sincronizzazione non importa!

Se il vostro capo non può capire i dettagli tecnici, lui o lei che uso praticamente tutti i sistemi VOIP attualmente esistenti UDP raccontare e ci deve essere un motivo: Skype, Ventrilo, TeamSpeak, World of Warcraft di, ecc

Altri suggerimenti

Per rispondere correttamente a questa domanda, ritengo che alcuni dei concetti chiave del VoIP debbano essere spiegati.

Innanzitutto, UDP è il più popolare E ampiamente usato metodo per VoIP.Ricordare che una rete IP è a commutazione di pacchetto ed è ideale per la comunicazione di dati non in tempo reale e non è progettata per VoIP in tempo reale.

Per superare questo problema viene utilizzato UDP.UDP è un protocollo inaffidabile e senza connessione.Anche se UDP perderà pacchetti, l'audio del parlato potrà comunque essere compreso, il cervello compenserà efficacemente gli errori.Ecco perché puoi ancora parlare con qualcuno al telefono con 3 barre di segnale.

Perdita di pacchetti e lunghezze di burst

La perdita di pacchetti spesso si verifica a causa della congestione, quindi la quantità di pacchetti persi dipenderà da quanto è ben equipaggiata la rete.La perdita di pacchetti nel VoIP utilizzando UDP si verifica molto spesso in lunghezze di scoppio. UN lunghezza dello scoppio è il numero di pacchetti persi in successione nella trasmissione, quindi una lunghezza di burst di 3 significa che sono stati persi 3 pacchetti di seguito.

Compensazione della perdita di pacchetti

Laddove si verifica la perdita di pacchetti, emergeranno semplici tecniche di compensazione della perdita di pacchetti e la qualità del servizio non verrà compromessa seriamente, il discorso può ancora essere compreso anche nei casi in cui viene perso il 20-30% dei pacchetti.I metodi includono:

Ripeti l'ultimo pacchetto ricevuto con successo.
Compila: riproduci il silenzio nello spazio vuoto.
Splicing - In effetti questo si può pensare di rimuovere il divario causato dalla lunghezza di scoppio spingendo insieme l'inizio e la fine del divario.
Interpolazione: utilizzare la conoscenza del linguaggio prima e dopo per interpolare i pacchetti persi all'interno del divario, ad esempioMedia tra i pacchetti ricevette con successo prima e dopo la lunghezza di scoppio.

Un buon metodo per ridurre la dimensione della lunghezza del burst è noto come interleaving e quindi aumentare la QoS interlacciamento.Una funzione di interleave a blocchi prende il parlato e lo divide in una serie di pacchetti.Questi pacchetti vengono caricati in un buffer a forma di matrice (ad es.4 per 4), viene utilizzata una funzione per ruotare o trasporre il buffer in modo che i pacchetti non siano in ordine.Dal lato del destinatario viene utilizzato l'inverso di questa funzione per riordinare i pacchetti.Questo metodo è semplice ed efficace, vedere la figura seguente:

testo alternativo http://img688.imageshack.us/img688/3962/capturevnk.png

Recentemente ho creato una piccola app VoIP.su una LAN wireless utilizzando UDP.Non sono molto sicuro dei requisiti esatti della tua applicazione, ma generalmente le applicazioni VoIP (tra due host) possono essere implementate come segue:

testo alternativo http://img338.imageshack.us/img338/6566/captureec.png

Nel diagramma l'applicazione definisce il proprio design del pacchetto.L'intestazione potrebbe essere semplicemente il numero del pacchetto (usando 1 byte) e il carico utile i dati audio (n byte, dimensione del carico utile).La definizione di ciò consente migliori tecniche di compensazione dei pacchetti e consente un flusso logico per la programmazione.

TCP è un Scelta sbagliata per VoIP per diversi motivi.Una rapida ricerca su Google di "TCP VoIP" rivela il motivo del primo risultato a sostegno di ciò visualizzazione.

TCP è un protocollo affidabile, orientato alla connessione, ciò significa che i pacchetti persi durante la trasmissione ad un certo punto verranno rispediti dall'altro host.Questa ritrasmissione non è pratica per i servizi in tempo reale e aumenterà il jitter, la latenza e possibilmente la perdita di pacchetti (in alcuni casi).

Risposte alle tue domande

Quello che ottengo è fondamentalmente solo rumore.Il 20% è suono registrato e il resto è solo rumore strano.

TCP non dovrebbe introdurre rumore, dovrebbe introdurre jitter e latenza.I socket tendono ad avere un tempo di timeout definito automaticamente, definisci tu il tempo di timeout?In caso contrario, cosa succede perché non ricevi il pacchetto corretto in tempo prima della riproduzione?

Sono sulla strada giusta?È una buona idea utilizzare TCP/IP per questo tipo di applicazione (una sorta di conferenza vocale)?

No NON utilizzare TCP/IP non è una buona idea.Sembra che il tuo manager abbia erroneamente presunto che qualsiasi perdita di pacchetti sia una cosa terribile.

Riepilogo

Alcuni concetti chiave generali sono stati mostrati qui per cercare di aiutare il più possibile per questo problema specifico, tuttavia ciò non deve essere considerato esaustivo.Assicurarsi che il sistema VoIP utilizzi anche alcuni principi di base delle tecniche di codifica vocale/elaborazione del segnale.

I punti chiave da ricordare sono:

Utilizza UDP per VoIP.
Implementare la compensazione della perdita di pacchetti
tecniche.
Un interlacciatore a blocchi è un semplice e
metodo efficace per aumentare la QoS.

Spero che aiuti.

Quando la gente sta parlando lo stack TCP / IP che spesso significano "l'intero stack di protocollo Internet", che comprende UDP. Forse che rende il tuo manager felice; -)

TCP / IP avrebbe funzionato; consegnerà i dati. Potrebbe non essere abbastanza efficiente come UDP se non erano preoccuparsi di perdita di pacchetti, ma si dovrebbe essere in grado di trasmettere i dati più che bene.

TCP / IP su router e reti moderne è molto veloce. E 'più che in grado di gestire la comunicazione Voice over IP. (Ho fatto io)

La mia ipotesi è che l'implementazione ha qualche bug in esso legato per tamponare le dimensioni.

Non v'è alcun motivo per cui si dovrebbe essere sempre rumore su TCP e sembra quindi, come un bug nel codice. In realtà la maggior parte dei media in streaming che riceviamo (si pensi YouTube) vengono eseguite su TCP.

Il problema con il protocollo TCP è il jitter. Consegna del vostro flusso di dati sarà ritardata fino a quando tutti i pacchetti sono stati ricevuti e riordinato. Ora, poiché la consegna in ritardo per il multimedia è buono come non la consegna a tutti. Questo è normalmente una scelta più povero semplicemente interpolando il telaio mancante. Come accennato in precedenza, se la perdita di pacchetti è minimo e la rete veloce, dovrebbe fare alcuna differenza.

RTP / RTCP UDP viene normalmente utilizzato per la consegna del flusso multimediale. RTP include cose come numeri di sequenza nell'intestazione del pacchetto che permettono l'inserimento di pacchetti ritardati nella loro posizione corretta, se possibile. RTCP ha una funzione di segnalazione che permette il codec di adattarsi alle situaltions dove la perdita del pacchetto inizia a diventare più alto. RTP / RTCP fornisce quindi alcuni, ma non tutte le funzionalità TCP.

Per streaming media su TCP, questo può essere risolto facilmente avendo un buffer jitter grande. Questo aggiunge la latenza, ma per sola andata in streaming questo non è un problema. La latenza, tuttavia è un problema importante in streaming bidirezionale-colloquiale.

Uno dei vantaggi principali di TCP, però, è che essa attraversa i firewall più facilmente di UDP. Uno una sessione TCP è stabilito il firewall è aperto sia ai dati inviati e ricevere. Questo è più complicato per UDP soprattutto quando si si aspetta un flusso in entrata di dati. Ci sono modi per aggirare questo, ma può essere complicato e possono comportare la comprensione del protocollo di controllo della sessione (come SIP o RTSP).

Ho sviluppato una soluzione IP Voice oper per una comunicazione duplex con onda-API per il controllo remoto di un tranceiver radioamatoriale. Funziona verry bene con UDP e anche con TCI / IP! Uso 512 byte buffer di 64 ms ciascuno, dati dell'onda 8kHz Mono. Ho del lavoro nel corso dell'ultimo mese, tra USA e Europa verry bene su TCP / IP! Ora la mia domanda: L'onda-api non funzionano correttamente con Win7, quindi penso che DirectSound è il modo migliore. Proprio in Tim ho Trubble ingegno l'attuazione sotto DirectX9 Gestito, la mia domanda è VB.Net 2008. Cerco collegamenti alla documentazione per un'uscita in streaming con DirectSound - ManagedDirectX9 per VB.Net.

Esistono alcuni motivi principali per cui i dati di streaming live utilizzano UDP.Il più grande dei quali è ricevere dati in ritardo è come non riceverli affatto, e ritardare il flusso per la ritrasmissione non è certamente una buona idea.Per VoIP, hai una tolleranza di latenza di circa 150 ms.Qualsiasi pacchetto vocale ritardato più a lungo diventa visibile agli utenti.

Per quanto riguarda il motivo per cui ricevi rumore, come gestisci i pacchetti che arrivano in ritardo a causa delle ritrasmissioni?

Dipende dal tipo di rete sottostante, se si dispone di Ethernet con l'affidabilità del 99,9%, la mia ipotesi è TCP farebbe bene. Tuttavia, se si sta facendo più di dire 802.11 quindi TCP sarebbe un non così buona idea.

Si può chiedere il vostro capo per una ragione specifica per utilizzare TCP e quindi implementare quel particolare servizio, ad esempio l'affidabilità di base, o un servizio di correzione degli errori su UDP. Ti potrebbe piacere anche a guardare in RTP. ( http://en.wikipedia.org/wiki/ real-time_Transport_Protocol )

TCP dovrebbe non introdurre alcun rumore. Jitter e lag, sì (soprattutto se i vostri collegamenti sono lossy); ma nessun rumore. Qualcosa è pesce con la vostra programmazione.

A proposito, concordo che UDP è molto più appropriato di TCP in questo caso.

applicazione più voce sono costruire utilizzando il protocollo RTP, che è flusso sulla porta UDP. Bene la maggior parte delle quali con supporto codec per garantire i mezzi di comunicazione vengono compressi prima di flusso da un capo all'altro. Parlane con il tuo capo circa i requisiti di larghezza di banda.

Sono abbastanza sicuro che la maggior parte di audio in streaming / video utilizza UDP ... si potrebbe perdere alcuni pacchetti, ma non si sarebbe mai notato.

Se stai ricevendo il rumore, probabilmente stai ruota libera la parte del buffer che ha riempito con successo con i pacchetti, e la riproduzione di buffer vuoto / non inizializzato.

Come molto più lento è TCP che UDP? Con il protocollo TCP si sta rilevando un ritardo di ritrasmissione se tutti i pacchetti arrivano fuori ordine o danneggiato. Dirò ci sono modi per ottimizzare TCP così c'è meno ritardo. In Linux e Winsock c'è un'opzione TCP_NODELAY da usare. Anche un codec compatta aiuterà come G.729 per mantenere la dimensione del carico utile verso il basso. Poiché la trasmissione è basata su pacchetti che vengono ricevuti (in ordine - TCP) si dovrebbe concentrarsi sull'ottimizzazione la dimensione del pacchetto di essere abbastanza piccolo per ridurre ritardo ritrasmissione ma abbastanza grande per mantenere un flusso di qualità. Un buon programma TCP VoIP avrebbe la possibilità di variare qualità di codifica e dimensione del pacchetto al volo in cui il mittente dovrebbe segnalare al ricevitore del cambiamento. Ma in realtà l'unico advntage di utilizzare il protocollo TCP in tempo reale è che è meno probabilità di essere bloccati da firewall.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow