May 1, 2010 at 12:40 pm #42383
I tried many VOIP phone services, and found that some will provide you with good quality phone service, especially like sound is clear, call is smooth and not stuck sometimes. So except the internet connections, which part of the hardware and software affect the VOIP phone quality?May 1, 2010 at 6:36 pm #50253
Audible Echo. Reflections occur at any point the telephone line is converted from two wire to four or back. And also in the hand set. A little reflection is designed into the handset itself because otherwise the phone sounds dead. If the reflections are delayed too long then annoying audible echo is possible. This can be mitigated by appropriate echo suppression (turning off incoming sound when you are speaking, older technology that sounds pretty bad) or echo cancellation (detecting the actual echo and removing it from the received sound, typically needs a digital signal processor (DSP) and only became cheap enough for consumer grade equipment in the last 10 years or so). However echo cancellation can only do so much. If there is too much delay between the sound and its reflection or if the reflection is too high the adaptive logic will not be able to handle the situation. You can reduce level reflections on your side by making sure the line impedance in your two wire phone and that in your Analog Terminal Adaptor (ATA) are properly matched. Some ATAs have controls for this others seem to do an automatic impedance match. You have no control on the reflections generated on the far end of the call. You can reduce the time delay for the reflections by using a VoIP provider that is close to you on the Internet. And a high speed link is needed, just the delay in getting a packet to your ISP via a dial up can be a deal killer.
Drop outs. Voice, or other streaming real-time packet flows, need a smooth stream of received data all with the same time delay between sending and receiving. The Internet does not provide that. So your ATA or IP phone or maybe your VoIP BPX will have a jitter buffer. The more variation in packet delivery you have the bigger the jitter buffer you need. It seems that the VoIP providers I have dealt with have a maximum jitter buffer size of 10ms. This puts an upper limit on how much jitter there can be before the person you are talking to hears funny things. For your listening there may be a control on your ATA or VoIP PBX that allows you to adjust this to something larger so you may still hear things okay with more jitter. The better the ISP (fewer drop outs, less jitter) the better your call quality.
Routing. Most VoIP nowadays uses SIP for setup and control and RTP for the actual voice. The IP addresses and ports used for RTP are negotiated in the SIP dialog between your ATA/VoIP PBX and your provider. The RTP need not follow the same path as the SIP. If you have a NAT or PAT router that does not understand SIP then it will not know how to look inside the SIP packets and detect the assignments it has to setup for the RTP to work. The result is no voice or one way voice. There are some work arounds where your ATA/VoIP Router can attempt to discover what your NAP/PAT router is doing (STUN is one) and try to compensate. However it is best to have a router that is SIP aware.
Those are the first things that come to mind for me…
And to get ZeroShell to be SIP aware, you should add the following to your Pre-Boot script:
Apparently an older version of Zeroshell had that but it was removed for some reason. I found that I needed it to make my VoIP setup work properly.May 2, 2010 at 7:42 pm #50254
No need to reply bots 😛July 14, 2010 at 7:02 am #50255
I am also using Voip phone for business purposes. It definitely gives a lot of benefits. I have problem when I play music in my PC. However, when I stopped playing my music, it is working again.July 15, 2010 at 7:36 am #50256
I have the release 13
This has already modprobe nf_nat_sip
or do I have to include it in the boot q
and how is that done?July 16, 2010 at 5:58 pm #50257
You’ll almost certainly want to setup QoS to do bandwidth management and prioritize the VoIP traffic as well as reserve some guaranteed bandwidth for your VoIP channel(s).
QoS / Bandwidth Management is currently my primary use for Zeroshell on our networks and Zeroshell works very well for this.
There’s a QoS tutorial on this site.January 19, 2012 at 10:21 am #50258
Yes, you are right internet connection affects the VoIP phone quality. But the voice clarity also depends on the locations. The location plays important role in CSR (call success rate). The call setup success rate is key performance indicators used by the network operators to determine the performance of their networks. Choice of codec also affects the VoIP phone quality because you need enough bandwidth to make good quality calls. The VoIP hardware equipment you use greatly impact on your quality. Poor quality equipment is normally the cheapest; therefore try to gather as much information as possible on an ATA, router or IP phone before investing on it and starting to use it. It might also be that the hardware you choose is the best in the world, but still you get problems – the reason being you are not using hardware that suits your needs.
I am also using VoIP services from …. So far, I have not faced any issues like poor sound quality; not even software or hardware problem.February 10, 2013 at 8:02 pm #50259
I’ve not verified this for certain but I’ll make some commentary with respect to the SIP & NAT module
- It seems like ZS 2.0 RC2 has the sip nat module enabled because I saw it on the list when I ran lsmod
- That I need to track udp for the sip ports (5060:5090/udp) with, at least, related and established and probably new
Unfortunately, I’ve not been able to get to the phones and test my hypothesis as I’m snowed-in here in the US North East 🙂
By the way, this is Polycom RingCentral VOIP over Cox’s cable networkAugust 28, 2013 at 2:40 am #50260
I find it interesting, that I never had to set up NAT for either SIP or RTP ports.
Linksys PAP2T just worked, no NAT settings whatsoever, but it had a nasty habit of sometimes losing login to the provider until I simply changed port on the line that went down. Since then I tried setting up port forwarding to 5060-5070 and 16384-16482 hoping it would make the problem go away. That did not work, once in a few months one of the lines goes down and nothing but changing the SIP port# can fix it.
You must be logged in to reply to this topic.