Comunicazione vocale su TCP/IP

Question

Attualmente sto sviluppando un'applicazione che utilizza DirectSound per la comunicazione su una rete intranet. Ho avuto una soluzione funzionante usando UDP ma poi il mio capo mi ha detto che vuole usare TCP/IP per qualche motivo. Ho provato a implementarlo praticamente allo stesso modo di UDP, ma con scarso successo. Quello che ottengo è fondamentalmente solo rumore. Il 20% di esso è il suono registrato e il resto è solo rumore strano.

La mia ipotesi per il motivo è che TCP ha bisogno di leggere tutti i dati accettati più volte fino a quando non ottiene il suono finale che posso riprodurre.

Ora due domande:

• Sono sulla buona strada? È anche consigliabile utilizzare il protocollo TCP/IP per questo tipo di applicazione (chiamate vocali di tipo)?
• Lo sto facendo in C# ma non penso che questo sia specifico della lingua.

Answer 1

No, l'utilizzo del protocollo TCP è una terribile idea. UDP in questo caso funzionerà molto meglio e i pacchetti non sincronizzati/non sincronizzati non contano!

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

Answer 2

TCP/IP funzionerebbe; consegnerà i dati. Potrebbe non essere altrettanto efficiente di UDP se non ti preoccupi della perdita di pacchetti, ma dovresti essere in grado di trasmettere i dati bene.

Answer 3

TCP/IP su router e reti moderne è molto veloce. È più che in grado di gestire la comunicazione voce su IP. (L'ho fatto io stesso)

La mia ipotesi è che la vostra implementazione abbia qualche bug relativo alle dimensioni del buffer.

Answer 4

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

Per quanto riguarda il motivo per cui si sta disturbando, come si gestiscono i pacchetti in ritardo di arrivo a causa di ritrasmissioni?

Answer 5

Quando le persone parlano dello stack TCP/IP, spesso indicano "l'intero stack del protocollo Internet" che include UDP. Forse questo rende felice il tuo manager ;-)

Answer 6

Dipende dal tipo di rete sottostante, se hai Ethernet con un'affidabilità del 99,9%, la mia ipotesi è che TCP farebbe proprio bene. Tuttavia, se lo stai facendo dire 802.11, allora TCP non sarebbe una buona idea.

È possibile chiedere al proprio capo un motivo specifico per utilizzare TCP e quindi implementare quel particolare servizio, ad esempio l'affidabilità di base o un servizio di correzione degli errori su UDP. Potrebbe anche interessarti di esaminare RTP. (http://en.wikipedia.org/wiki/Real-time_Transport_Protocol)

Answer 7

TCP dovrebbe non introdurre alcun rumore. Jitter e lag, sì (specialmente se i tuoi collegamenti sono lossy); ma nessun rumore. Qualcosa è difficile con la tua programmazione.

BTW, concordo sul fatto che UDP sia molto più appropriato del TCP in questo caso.

Answer 8

La maggior parte delle applicazioni vocali vengono create utilizzando il protocollo RTP che è in streaming sulla porta UDP. Bene, la maggior parte di loro con supporto codec per assicurare che i file multimediali siano compressi prima del flusso da un'estremità all'altra. Discuta con il tuo capo sui requisiti di larghezza di banda.

Answer 9

Sono quasi sicuro che la maggior parte dello streaming audio/video utilizza UDP ... potresti perdere alcuni pacchetti, ma non te ne accorgeresti mai.

Answer 10

Non c'è alcun motivo per cui si dovrebbe ottenere rumore su TCP e quindi sembra un bug nel codice. In effetti, la maggior parte dei media in streaming che riceviamo (pensa YouTube) viene eseguita tramite TCP.

Il problema con TCP è jitter. La consegna del tuo flusso di dati sarà ritardata fino a quando tutti i pacchetti non saranno stati ricevuti e riordinati. Ora dal momento che la consegna tardiva per il multimediale è buona come la mancata consegna. Questa è normalmente una scelta più scadente rispetto alla semplice interpolazione del fotogramma mancante. Come accennato in precedenza, se la perdita di pacchetti è minima e la tua rete veloce, non dovrebbe fare alcuna differenza.

RTP/RTCP su UDP viene normalmente utilizzato per la consegna del flusso multimediale. RTP include cose come numeri di sequenza nell'intestazione del pacchetto che consentono l'inserimento di pacchetti in ritardo nella loro posizione corretta, ove possibile. RTCP ha una funzione di reporting che consente al codec di adattarsi alle situazioni in cui la perdita di pacchetti inizia a salire. RTP/RTCP fornisce quindi alcune ma non tutte le funzionalità TCP.

Per lo streaming di media su TCP, questo può essere risolto facilmente con un buffer di jitter di grandi dimensioni. Questo aggiunge latenza ma per lo streaming a senso unico non è un problema. La latenza, tuttavia, è uno dei problemi principali nello streaming a due vie.

Uno dei principali vantaggi di TCP, tuttavia, è che attraversa i firewall più facilmente di UDP. Una volta stabilita una sessione TCP, il firewall è aperto sia per inviare e ricevere dati. Questo è più complicato per UDP, specialmente quando ci si aspetta un flusso di dati in entrata. Ci sono modi per aggirare questo problema, ma possono essere complicati e possono implicare la comprensione del protocollo di controllo della sessione (come SIP o RTSP).

Answer 11

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

In primo luogo, UDP è il metodo ampiamente utilizzatopiù popolare e per il VoIP. Ricorda che una rete IP è commutata a pacchetti e ideale per la comunicazione di dati non in tempo reale e non progettata per il VoIP in tempo reale.

Per risolvere questo problema viene utilizzato UDP. UDP è un protocollo inaffidabile e senza connessione. Anche se UDP perderà i pacchetti, l'audio vocale può ancora essere compreso, il cervello compenserà efficacemente gli errori. Ecco perché è ancora possibile parlare con qualcuno su un telefono con 3 barre di segnale.

perdita di pacchetti e Burst Lunghezze

perdita di pacchetti si verifica spesso a causa di congestione, quindi la quantità di perdita di pacchetti dipenderà da quanto bene attrezzata la rete è. La perdita di pacchetti in VoIP utilizzando UDP si verifica più spesso nelle lunghezze di burst . A lunghezza burst è un numero di pacchetti persi in successione nella trasmissione, quindi una lunghezza di burst di 3 significa che 3 pacchetti di una riga sono stati persi.

compensazione delle perdite di pacchetti

Dove si verifica la perdita di pacchetti semplici tecniche di compensazione perdita di pacchetti saranno Surfice e la qualità del servizio non saranno seriamente effettuato, il discorso può ancora essere compreso, anche nei casi in cui il 20-30% dei pacchetti sono persi. I metodi includono:

1. Ripetere l'ultimo successo ricevuto pacchetto.

2. Completa - Gioca silenzio nello spazio.

3. Splicing - Effettivamente questo può essere pensiero di prendere rimozione il divario causato dalla durata scoppio spingendo l'inizio e la fine del gap insieme.

4. interpolazione - Uso conoscenza discorso prima e dopo di interpolazione pacchetti persi all'interno del gap esempio media tra i pacchetti ricevuti con successo prima e dopo la durata del burst.

Un buon metodo per ridurre le dimensioni delle lunghezze di burst è noto come interleaving e aumentando quindi QoS è interleaving. Una funzione di interleave a blocchi prende il discorso e lo divide in un insieme di pacchetti. Questi pacchetti vengono caricati in un buffer della forma di una matrice (ad esempio 4 per 4), una funzione viene utilizzata per ruotare o trasporre il buffer in modo che i pacchetti non siano in ordine. Sul lato ricevitore, l'inverso di questa funzione viene utilizzato per riordinare i pacchetti. Questo metodo è semplice ed efficace, Vedere la figura seguente:

alt text http://img688.imageshack.us/img688/3962/capturevnk.png

Recentemente ho creato una piccola applicazione VoIP. su una LAN wireless usando UDP. Io non sono davvero sicuro delle specifiche esigenze della vostra applicazione, ma in generale le applicazioni VoIP (tra due host) può implementato come segue:

alt text http://img338.imageshack.us/img338/6566/captureec.png

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

TCP è una scelta errata per VoIP per diversi motivi. Un rapido google di "TCP VoIP" rivela perché il primo risultato a sostegno di questo view.

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

risposte alle tue domande

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

TCP non dovrebbe introdurre rumore, dovrebbe introdurre jitter e latenza. Gli zoccoli tendono ad avere un tempo di attesa definito automaticamente, si definisce il tempo di timeout? In caso contrario, cosa succede perché non si riceve il pacchetto corretto in tempo prima della riproduzione?

Sono sulla buona strada? È anche consigliabile utilizzare il protocollo TCP/IP per questo tipo di applicazione (chiamate vocali di tipo)?

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

Sommario

alcuni concetti chiave generali hanno dimostrato qui per cercare di aiutare il più possibile per questo problema specifico, ma questo non dovrebbe essere considerato esaustivo. Assicurati che il sistema VoIP utilizzi anche alcuni principi di base per la codifica del parlato/tecniche di elaborazione del segnale.

I punti chiave da ricordare sono:

• utilizzare UDP per il VoIP.

• Implementare la compensazione perdita pacchetto
  tecniche.

• Un blocco interleaver è un metodo semplice e
  efficace per aumentare QoS.

Spero che questo aiuti.

Answer 12

Se si sta disturbando, probabilmente si sta eseguendo un overrunning della parte del buffer che è stata riempita con successo di pacchetti e sta riproducendo un buffer vuoto/non inizializzato.

Answer 13

Ho sviluppato una soluzione voice oper ip per una comunicazione duplex con wave-api per il controllo remoto di un radioamatore tranceiver. Funziona bene con UDP e anche con TCI/IP! Uso un buffer da 512 byte ogni 64 ms, dati mono wave 8kHz. Ho lavorato nell'ultimo mese tra Stati Uniti ed Europa molto bene su TCP/IP! Ora la mia domanda: il wave-API non funziona correttamente con Win7, quindi penso che DirectSound sia 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.

Answer 14

Quanto più lento è TCP che UDP? Con TCP si ottiene un ritardo di ritrasmissione se qualsiasi pacchetto arriva fuori servizio o danneggiato. Devo dire che ci sono modi per ottimizzare il TCP, quindi c'è meno ritardo. Sia in Linux che in Winsock è disponibile l'opzione TCP_NODELAY. Anche un codec compatto aiuterà come G.729 a mantenere le dimensioni del carico utile. Poiché la trasmissione è basata sui pacchetti ricevuti (nell'ordine: TCP), è necessario concentrarsi sull'ottimizzazione della dimensione del pacchetto per essere sufficientemente piccola da ridurre il ritardo di ritrasmissione ma abbastanza grande da mantenere un flusso di qualità. Un buon programma VoIP TCP avrebbe la possibilità di variare al volo la qualità della codifica e la dimensione del pacchetto in cui il mittente avrebbe dovuto segnalare al destinatario della modifica. Ma in realtà l'unico vantaggio di utilizzare il protocollo TCP in tempo reale è che è meno probabile che venga bloccato dai firewall.