Help! My Customer Wants to Improve SIP Trunk QoS (Quality of Service)!
You’ve landed some customers, and have gone through all the necessary steps of getting their SIP trunk(s) properly set up. Everything is going smoothly for a while, then one of them comes to you and asks if you can help him improve the QoS (quality of service) that he’s currently getting. What do you do? In this post, we’ll show you how you can best handle a request for better QoS for a SIP trunk.
My customer wants QoS, what do I do?
The most common issues that we see are on the customer’s LAN, and making sure there isn’t someone sucking down too big a portion of the bandwidth. A good Layer 2 or Layer 3 switch will solve most issues with QoS (rate limiting, broadcast storm control, VLAN tagging, etc).
If you want insurance on the WAN side, we offer a QoS monitoring router called the SPR1000. It’s completely pre-configured and flashed with our QoS and monitoring firmware.
You can get “Basic Monitoring,” which includes monitoring the uptime of the connection and receiving alerts on outages monitored by our NOC.
If that’s not enough, there is “Pro Monitoring,” which includes monitoring uptime, as well as real-time bandwidth statistics and QoS alerts, and offers a VPN connection
The best part? As a dealer, you receive commissions on these monitoring services!
How does it work?
We force it to carve off the voice traffic before it ever reaches the customer’s internal router. Thus:
ISP —>>> SIP Power Router —>>> Customer Router —>> Customer IP Phones
We VLAN off the customer IP phones to go straight to SPR1000 which is QoS’d in front of the customer’s router. It gets first priority at the WAN connection!
What if the QoS still isn’t up to snuff?
If a customer says “money is no object,” and they are willing to pay huge amounts of money, they can build an MPLS point to point data connection. This is like a gold-plated Cadillac. Sure it’s nice, but it isn’t worth the cost (for most people).
You can also talk to them about the SIPTRUNK.com infrastructure.
All the carriers at this point in 2015 are very QoS-aware; so once you get to the “core of the internet” you’re unlikely to find QoS issues.
“What do you mean, ‘core of the internet’?”
Let’s suppose you do a SIP traceroute from your house (you might have AT&T or Comcast service, etc). Once you get past the first few hops, you’re at the core of the internet.
If you ping an endpoint in NYC, and the call originates from the ATL area, you’ll hop onto a couple AT&T U-verse routers, and get into downtown ATL. Once there, you’re talking about massive fiber connections (10GB pipes!).
At the core, the speeds are extremely fast, and the routers are tuned for QoS to eliminate issues. The call then speeds along from downtown Atlanta, and will make a hop in the Philadelphia / DC area, which makes its way to its destination in NYC.
Another thing to be aware of – We, by default, are not in the media portion of the call.
Media portion?
We are in the signaling path as a big traffic cop between carriers for inbound and outbound calls and our clients who have SIPTrunk.com connections to us. We are basically a big mediator existing in the cloud that handles SIP Signalling. We have SIP Signalling servers in Atlanta (SIPTRUNK.GW1), Dallas (SIPTRUNK.GW2), and NYC (SIPTRUNK.GW3). (They are all running redundantly on standby and will failover automatically if there are issues).
There are two major components to making the calls:
1. Port 5060 for call setup / call teardown:
So when you hit the call button on your phone, you’re initiating the call.
Next, our servers say – “Are you a valid SIPTRUNK.com account?” If yes, “okay put that call through.”
The call hits the carrier, and our servers tell the carrier “we want to make this call to this number.”
This is all happening on port 5060.
2. The default port range is 10000-20000 UDP on most asterisk servers. (The port range varies by PBX. The PBX will tell the signaling server what ports it is capable of using).
After that, the signaling server tells the upstream carrier which ports can be used for RTP media. The carrier chooses which of those ports to communicate on. (This port support and negotiation is all part of the actual SIP protocol).
The carrier then says, “Okay we see you placed this call, the guy on the other line picked up the phone”.
The carrier then says, “I need you to start broadcasting the audio on port” (range: 10000-20000).
(The audio is the MEDIA portion of the call, and has not been transported until this happens).
Why backhaul the media?
For performance reasons, we stay out of the media path of the call. We send the signalling portion only, so carriers can pass the call (audio and all) efficiently with no latency / QoS issues.
Therefore, it doesn’t matter where in the country the call is going (Atlanta to San Francisco for example), we don’t have to backhaul the media throughout the whole country.
So whatever carrier is routing the call, you get the closest point for that carrier.
We have to be in the signaling path so we can properly bill, route and account for the calls (we need to know when the calls were initiated and when they are hung up).
Conclusion
Handling a QoS SIP trunking issue requires a few hoops, but also can present a wealth of opportunities to the enterprising and ambitious SIP reseller. When the subject of QoS comes up, refer back to this post and handle it right!