conosco abbastanza le differenze tra UDP e TCP in generale (ad es. http://www.onsip.com/about-voip/sip/udp-versus-tcp-for-voip)con SIP, quando utilizzare TCP non UDP?
domanda è: in quali circostanze avrebbero utilizzando il protocollo TCP come il trasporto hanno vantaggi specificamente sotto comunicazioni SIP VoIP?
Un sacco di persone in genere associano UDP a VoIP e probabilmente lo lasciano, ma in termini semplici ci sono due parti per VoIP - connessione e trasferimento dati vocali.
SIP è un protocollo molto leggero, una volta stabilite le connessioni viene lasciato inattivo fino all'evento raro di qualcuno che effettua una chiamata. TCP (diversamente da UDP) ridurrà effettivamente il traffico al server eliminando la necessità di;
È possibile eseguire SIP su TCP e quindi utilizzare (come è consigliato) UDP per RTP.
Non ho potuto fare a meno di sottolineare anche le cose ovvie che ho guardato. Per esempio. numero di dispositivi che si collegano al server. A mano a mano che il numero aumenta, l'inclinazione delle equazioni negli UDP è favorevole. Ma devi anche considerare l'espansione degli agenti utente SIP per coprire più codec, multimedia, video e condivisione dello schermo. I pacchetti INVITE possono iniziare a crescere in modo significativo e potenzialmente a superare le dimensioni del singolo datagramma UDP, inclinando di nuovo l'equazione in favore di TCP.
Spero che tu abbia abbastanza informazioni per rispondere alla domanda a cui stavi cercando di rispondere.
Spero che questo aiuti.
credito: Il meraviglioso discussione al onSip: https://www.onsip.com/blog/sip-via-udp-vs-tcp
Se un messaggio è di grandi dimensioni (meno di 200 byte di dimensione MTU), RFC 3261 sezione 18.1.1 mandati uso del protocollo TCP (per essere precisi, mandati uso di un "protocollo di trasporto controllato dalla congestione, come TCP"). L'ho colpito in pratica quando invio un INVITE iniziale con un sacco di intestazioni e un URI di richiesta complesso.
SIP su TCP ha un vantaggio significativo su UDP per dispositivi mobili. Il motivo è dovuto all'uso di NAT e al modo in cui le voci della tabella NAT in un router wireless o in un router di provider di celle sono in genere molto più veloci per UDP e TCP. Poiché è necessario mantenere la stessa voce della tabella NAT per poter ricevere in modo affidabile le chiamate, SIP deve periodicamente inviare keep-alive per mantenere la voce della tabella NAT. La frequenza richiesta di keep-alive è molto più alta per UDP (forse ogni 30 secondi) rispetto a TCP (forse ogni 15 minuti), il che si traduce in un consumo di batteria del dispositivo mobile notevolmente più alto. Spesso quando vedi qualcuno lamentarsi di come il loro utilizzo della batteria riscuote un grosso successo quando si utilizza un client VOIP, è perché il client sta usando UDP.
Quindi, TCP vince su UDP verso il basso per i dispositivi mobili.
Si noti che quanto sopra presuppone che si desideri essere in grado di ricevere chiamate in modo affidabile sul dispositivo mobile. Se tutto quello che vuoi fare è essere in grado di effettuare chiamate, allora è una storia diversa.
Interessante. Ci si chiede come i cellulari moderni abbiano le loro app VoIP VoIP integrate configurate di default (ad esempio Android 4+) in questo contesto. – Marcos
qualsiasi fonte per questo? mandare un pacchetto udp ogni 30 secondi non suona come se potesse usare molta batteria. – kritzikratzi
TCP può ottenere con perfetta chiarezza su una connessione con perdita, quando UDP potrebbe non essere comprensibile. Si ottiene una latenza inferiore con UDP, ma questo non ti aiuta se non riesci a capire cosa viene detto.
SIP non trasporta la parte vocale. Questo è RDP. – Andrew
Non è possibile assemblare in modo affidabile un flusso audio da un protocollo basato su TCP. Nell'audio è molto meglio perdere un pacchetto, quindi avere un pacchetto ritrasmesso a causa di una caduta di pacchetti. L'audio non funziona se c'è un jitter eccessivo nel timing del pacchetto. L'audio è un protocollo in tempo reale e richiede un protocollo come UDP per funzionare correttamente. La perdita di pacchetti non interrompe l'audio, ma riduce solo la qualità. La consegna perfetta di TCP non aiuta l'audio in alcun modo, non ci può essere qualità se si ottiene il 100% dei pacchetti, ma non sono in tempo reale. Nell'audio sono i tempi (latenza, jitter) che determinano la qualità più dell'integrità dei dati.
Questo sorso funziona BEST quando il segnale e il controllo sono su TCP, ma i dati voce è su UDP.
Ho lavorato con la trasmissione di digital voice su protocolli di rete da quando ho progettato uno dei primi smartphone nel 1987 per la nuova rete cellulare digitale in Giappone. Dal 1987, l'unico aspetto della trasmissione digitale della voce che non è cambiato è ciò che descrivo qui. La natura in tempo reale della trasmissione audio (voce) e il modo in cui questo influisce sulla progettazione del sistema è ancora esattamente la stessa che era nei giorni dei dinosauri da cui provengo.
Vengono anche in mente i casi in cui è necessaria la crittografia (sebbene SRTP possa utilizzare UDP anche se non mi sbaglio). – Marcos
Sì, e SRTP lo fa molto spesso. Anche se questo diventa una discussione su RTP più che SIP. Per la sicurezza SIP si dovrebbe guardare SIPS (Secure SIP). – MickJ