VoIP = four letter word (customers say)

Asterisk Asterisk Support
1

I’ve inherited the “telephony engineer” hat (albeit that was not in my job description) and am determined to get this QoS Hell frozen over. The two most frequent customer complaints are dropped calls (that are not specific outbound or inbound calls, nor specific times) and indecipherable conversations that won’t stop breaking up (from beginning to end of call); basically the unendurable, “worse that cell phone” complaints. It doesn’t matter that some complaints come from cable customers with 1.5M/256k lines and some from DSL 5M/512k (and one with fiber); some from Linksys routers with QoS while others with DLink routers with no QoS gasp; some with PolyComm phones and others with SNOM. Basically it’s across the board. The basic customer setup is:
modem <-> router <-> asterisk <-> voip phone

Almost all Asterisk servers also have POTS interfaces which the customers just love. Give them a way to directly tap into an analog line (via an extension) and they try to always bypass the voip lines. Yea, it’s that bad.

My solution is an end-to-end diagnoses of what’s going on with these calls to essentially reverse engineer however they were suppose to work, but I’m not seeing all the tools needed for such testing. There’s these sip testing tools that I just bumped into but from what I’m seeing (via netstat) and these forums, I really need something that will let me spontaneously “make” a phone, aka. softphone, on the far end and on the near end for testing … tracing with wireshark. Any ideas? Otherwise I have to sit around waiting for a session or my other option is – heaven forbid – install etherreal on the server! gasp (These are dedicated asterisk boxes on their end. The other stuff running is … well ntpd and sshd. hehe … BUT, they are merged networks. The data and voice are not separated in any way. And yes, I’ve argued for separate networks or layer2/3 switches … but have been told that throwing money at this is not an option.)

Also, this pseudo-random rtp port numbering seems hell for QoS. I’ve watched asterisk open ports from as low as 11678 to as high as 32345. Some routers don’t support ranges of ports and customers tend to be unconvinced that buying a better, – read “more expensive router” – will help them. Is there a way to tell Asterisk, “hey, you’ve only got 6 voip lines, so you only get 12 ports to play with, and they are 10000 to 10011.” That would be fabulous … especially for the cheap routers playing alongside other programs.

Thx.

2

Take a look at rtp.conf, you can set your rtpstart and rtpend, that should ease up your QoS hell.

You may be able to set up SSH tunnels once you settle your ports down and run two softphones on machines directly next to each other for your testing, or set up a quick VPN.

3

Call quality is the biggest problem with VOIP adoption. Bar none. QoS efforts have helped, but they haven’t fixed the issue, and sadly, they won’t.

The issue isn’t the ability to do QoS treatments to a packet. Anyone can do that. But that alone won’t cure the problems of latency, dropped packets, and jitter. The solution is bandwidth. Sadly, QoS efforts only work when there’s virtually unlimited bandwidth available. Simply being able to mark a packet as “voice” is meaningless, unless you have a nice fat pipe to push it through.

However, if you have virtually unlimited bandwidth available, you don’t NEED QoS. It’s a bad situation.

In all (ALL!) cases, a network assessment should be done to determine the available bandwidth. That will tell you if VOIP is even feasible in the environment.

Remember always that the Internet Protocol, (IP) was NOT designed to be a real time data delivery protocol. Putting voice packets, (which people expect to be delivered immediately) onto an IP network is really like putting a square peg into a round hole.

Absent a fundamental change to the Internet Protocol, you’ll never solve the problem, you can only make a “best effort”.

Go back and argue for network separation again. Be sure to remember that a switch may have 24 ports of 100 meg Ethernet connections, but that DOESN’T mean that deal worth 2400 meg of data on it’s backbone. See? You MUST do network assessments to determine your capabilities.

You may find that you must limit VOIP calls over the internet to 1 or 2 at the very most to get something semi reliable.

Voice is not data, and can’t be treated the same way. People may wait 8-10 second for a web page to fill in, or an email message to be delivered to an email server, but a delay of 150 milliseconds is enough to label a phone call terrible.

4

Its not a free tool but I would highly recommend Network Instruments Observer. It will recognize SIP and QoS and has a feature that will allow you to replay whole packet streams - including making SIP calls.

5

Even with fixed rate codics VOIP in small doses is not that much of a bandwidth hog. Latency is another issue however. I will run ping tests, which represent the worst case, and see what the return times are. If they are over 250ms or all over the place, that is not good.

You also do not mention which codec(s) you are using. Is your server transcoding?

What protocol are your phones using (SIP or IAX2)?
If it is SIP, is your firewall or router configured correctly, and up to the task? IAX2 is a lot easier to deal with from a networking perspective.

You also do not mention if the issues are on IP to IP calls or on IP to a VOIP gateway. I have had issues where direct IP to IP calls have been fine, but calls going through an IP gateway to POTS have had issues. The issue turned out to be on the providers end.

One other thing you can do is download ethereal. Dig out an old hub and stick it between your IP providers jack and your router, and capture a few megs worth of packets and use the built in tools to sort them by percentages. Now you know where most of your traffic is comeing from.

6

You know, now I remember reading that in OReilly’s Asterisk book … duh! me. Thx for jogging my memory.

7

Well, perfection it won’t be, and there is only one customer with jitter … at the very last hop (evidently a bad demarq ???) I do tell customers to expect cellular quality.

Good point. I’m right in the middle of ours and telling the sales guys that we will NO LONGER install VoIP unless there’s a line test, ping plots, and separate networks, aka. non-converged.

If not harsh, it’s nice nonetheless. This done in asterisk by setting up only 2 channels ?

8

I’ll include this in ping tests.

Although (as an amateur mixer) I know what you’re asking, I don’t know how to check whether Asterisk is doing this … the Asterisk boxes are always idle whenever I touch them.

SIP

You mean 5060? Yes, udp & tcp just incase although the servers are using udp. I haven’t been able to trace this much on the ip phone end but it’s not like phones or the boxes are having issues registering, and the ip phones do not have reinvite enabled AFAK. I’m more concerned QoS for RTP traffic.

Yes I did. All boxen are operating as gateways to POTS. The customers, as I said above, like going through those analog lines for good reason: Digium. Digium hardware is damn good. :smile:

Uhuh. Wireshark any? (I know you’re responding and helping, but I despise speed readers just for these kinds of redundancies.)