91–100 of 141 posts
Ive seen some enterprise level voip providers in the UK not only provide clients with VOIP systems either on site or a cloud PBX, but also a dedicated leased ADSL line. Usually 2mbps both up / down (They say this is good for about 20 concurrent users). They also connect the the line directly to their voip server, so it dosnt have to make multiple hops. Never tried one in practice though. We run our voip over our main…
Lots of good answers, but there is another one that's important too: echo cancellation. Most telco equipment has very good echo cancellation hardware in it. It's not impossible to do a decent job in VOIP, but not all of the software does it well. This can be very important when you have high latencies or if you are doing conference calls. The other main overlooked problem is automatic gain control in software. This o…
It's actually for broadcasters who just want to get live audio from A to B, untouched. But as it's two way (and multi-way) we're finding users contacting us to say they're using it for regular 'conferencing'.
I suppose we are also doing it ourselves; we used Cleanfeed to communicate when developing Cleanfeed.
Elsewhere in the thread people mention jitter etc. issues. In my experience, 200-300ms of latency has much less negative impact on rapport than aggressive audio processing.
I don't have any specific recommendations though, haven't used one for years.
Also, lossy codecs usually drop a good chunk of information in favour of compression, working with larger packets for better efficiency and adding even more latency. In that sense, G.711 or higher-quality PCM is the best if you want lowest latency possible.
I've worked for some time with telecom to know that each time you add a complex codec (G.72x) you may end up doing a few conversions on the way: in most gateways, if audio comes in as codec X, it gets converted to PCM internally and then re-converted to codec X again before going to the other end. Adding bypass logic adds little benefit as you have to scale the system for worst case scenario (all channels performing the costlier compression), so bypass only complicates your code.
So those "X ms of algorithmic latency" for complex codecs may end up being multiplied a few times: throw in echo cancelling, jitter buffers, etc and you get a call where you end up interrupting each other all the time due to audio delay.
First, as others pointed out, you will need a decent internet connection, with minimized packet loss and jitter. Most metro area data connections and quality WiFi access points will be sufficient. However, the wifi router that comes from your provider and stuffed away on the other side of the house might not work very well. Secondly, good codecs make a world of difference. This is where I'll add the disclaimer that I…
Lots of good answers, but there is another one that's important too: echo cancellation. Most telco equipment has very good echo cancellation hardware in it. It's not impossible to do a decent job in VOIP, but not all of the software does it well. This can be very important when you have high latencies or if you are doing conference calls. The other main overlooked problem is automatic gain control in software. This o…
I manage SIP setups for myself at home as well as at my aunts shop, both of which have physical IP phones instead of softphones. While softphones are certainly useful, most people on a VOIP service of some kind are probably more likely to still use a physical handset, headset, or proper conference phone where echo cancellation is less of an issue since it's either handled by the hardware itself or non-existent in the case of users on a headset.
Earlier quoted context omitted.
just want to point out: vast knowledge of telephony/VOIP is not something every sysadmin should be expected to know. If you don't have telephony expertise on staff I hesitate to suggest someone build out a VOIP infrastructure on their own. It can be extremely time consuming to learn and it is definitely painful to troubleshoot.
Shouldn't it be possible for me to get some IP phones in my office and tunnel through my router to a competent online voice provider? If so, can you recommend such a provider?
I use this with good Polycom "HD voice" devices. I'm also rather picky about voice quality.
Lots of good answers, but there is another one that's important too: echo cancellation. Most telco equipment has very good echo cancellation hardware in it. It's not impossible to do a decent job in VOIP, but not all of the software does it well. This can be very important when you have high latencies or if you are doing conference calls. The other main overlooked problem is automatic gain control in software. This o…
I'm going to agree with you and take this opportunity to plug http://cleanfeed.net/ We run a free 'VOIP' system that does zero processing on your audio. It's actually for broadcasters who just want to get live audio from A to B, untouched. But as it's two way (and multi-way) we're finding users contacting us to say they're using it for regular 'conferencing'. I suppose we are also doing it ourselves; we used Cleanfee…
FAQ #1 should be "how does this remain free/why is this not going to disappear"?
First, as others pointed out, you will need a decent internet connection, with minimized packet loss and jitter. Most metro area data connections and quality WiFi access points will be sufficient. However, the wifi router that comes from your provider and stuffed away on the other side of the house might not work very well. Secondly, good codecs make a world of difference. This is where I'll add the disclaimer that I…
To be fair, this is probably true of any decent VoIP solution on the market. The problem is always that moment you have to connect to the PSTN and you're forced into a choice of G.711 or G.729.