TCP Voip Client/Server

A

Avexrion

n00b
Joined
Jul 23, 2015
Messages
15
For many years I have been using Ventrilo as a non-SIP based Voip program due to its simplicity. It works great, but the codec is dated, and the program is loaded in so many proprietary shackles it is ridiculous (aside from that creepy tracking feature.) However, one nice aspect is that it uses TCP for its voice packets (so they all arrive sounding normal.)

I tried using Mumble, but it only has a TCP mode as an afterthought and you cannot configure servers to force TCP mode for all clients. I do like how it is encrypted though (few actually bother with this.)

Does anyone know of something like Vent/TS/Mumble that uses Opus or a similar high quality codec, without tracking features, and uses TCP? I would really prefer not to have to program something entirely myself...
 
Can't just block UDP so clients can only connect via TCP?

What about uMurmur?
 
MoFoQ said:
Can't just block UDP so clients can only connect via TCP?

What about uMurmur?
Click to expand...

I am doing that now, but it is very awkward due to that initial "delay" for it. It would be nice if the server just has a "TCP Mode Only" flag I could activate.

Can uMurmur force stock clients into TCP mode immediately without that awkward lag?
 
TCP isn't good for serving time-sensitive content such as video and audio, hence why most implementations rely on UDP.

If you lose a packet, your client has to wait for the host to resend it before you can get any more packets. That means you either have to buffer the audio and accept that it can be severely delayed, or there will be random audio dropouts.

Modern voice codecs such as Opus and Speex implement packet loss concealment and are therefore designed with UDP in mind. If you lose a packet, the audio might have a bit of distortion but you'll still be able to decode the stream and play it without losing the content (voice, music, whatever).

Aside from all that, because UDP is stateless it's inherently lower latency than TCP and therefore much more appropriate in audio/video transmission.

It seems like you'll have a much worse experience using TCP over UDP, especially if (what from what I inferred) you have packet loss. Sounds like you should fix first.
 
I agree with Snowknight -- you don't want TCP for VOIP applications. TCP is robust, therefore introducing more latency before each packet of information even gets to the application. Here's an example:

TCP:

Sending Computer ---->>> Here's some data
Sending Computer ---->>> Did you get it?
Recevining Computer ---->>> I got it
Sending Computer ---->>> Here's some data
Sending Computer ---->>> Did you get it?
Recevining Computer ---->>> No, please send it again
Sending Computer ---->>> Here's the same data again
Sending Computer ---->>> Did you get it?
Recevining Computer ---->>> I got it

UD:
Sending Computer ---->>> Here's some data
Sending Computer ---->>> Here's some data
 
Demon10000 said:
I agree with Snowknight -- you don't want TCP for VOIP applications. TCP is robust, therefore introducing more latency before each packet of information even gets to the application. Here's an example:

TCP:

Sending Computer ---->>> Here's some data
Sending Computer ---->>> Did you get it?
Recevining Computer ---->>> I got it
Sending Computer ---->>> Here's some data
Sending Computer ---->>> Did you get it?
Recevining Computer ---->>> No, please send it again
Sending Computer ---->>> Here's the same data again
Sending Computer ---->>> Did you get it?
Recevining Computer ---->>> I got it

UD:
Sending Computer ---->>> Here's some data
Sending Computer ---->>> Here's some data
Click to expand...

Yeah, I know the standard issues with using TCP for VOIP. Issue here though that I am not in a latency sensitive environment, I need accuracy over latency.

TS and Mumble are corrupting voice packets and sending them out of order in such a way that the voice becomes unintelligible in certain situations. This is not acceptable for what I am doing, therefore I need some form of proprietary protocol within UDP implementing sequencing and correction, or TCP (which is more universally allowable anyway.)

Ventrilo works great for this, but I am not liking how they restrict private servers and have no interest in selling licenses out to individuals (aside from the old codec and home phoning feature.)

Packet loss definitely impacts TCP badly, but at least the transmission will eventually reach the end destination. The packet loss I am experiencing is bad enough to destroy Speex and Opus's concealment algorithm, but not bad enough to prevent me from understanding people talking via Ventrilo and Mumble's TCP mode.
 
I'll just go ahead and stick to Mumble for now, it works well enough.

Maybe they'll consider adding a TCP only mode to the server in the future. If that was the case, I would have never had made this thread.
 
You must log in or register to reply here.
Back
Top