Whenever the economy sinks I think the opportunists rise--debt collectors, web doctors to increase our "traffic," consultants to "seek out opportunities" on our behalf and promises of great savings if you dump your local Telco. I'll admit saving money is always on my mind.We are averaging 14% monthly savings. Again, this isn't moving all our traffic over to a SIP provider. Our VLAN1 is our Voice network while VLAN4 is our Internet via Verizon FIOS 10Mbps/2Mbps. Because we are working on two simultaneous projects--SIP trunks and Voice Quality Monitoring (VQM) I reached out to my buddy Samir Kakkar, who's IPT Product Manager over at ADTRAN. Samir advised that I map a QoS policy on the outbound of VLAN4 to Verizon FIOS connection.
Call quality again is fine, and most of our SIP trunk calls are rated by our onboard VQM as "excellent." The remaining calls that are not excellent are shown as "good." VQM shows all the "good" calls negotiating at G.729a and our IP-PBX first choice is G.711, so it's clear to me that it doesn't matter what I want, it matters what the provider can handle at the time of call setup. I think SIP calls are really like fax calls, only instead of negotiating optimum speeds with other fax machines, we are contending with other traffic on the network and are negotiating with the provider.
This brings a question for large enterprise, and that is in your Service Level Agreements; will you demand a percentage of your calls be routed at G.711 for example? How much call control can you really expect as to which compression scheme is negotiated? How do you apply your traffic engineering equations? Then, again, I believe that your SIP trunks or anything else hosted is as only good as your WAN connection but still you can have a great WAN connection unless the provider's end is busy, then you may not get what you want. Then, what about that prediction of running out of bandwidth--is that any cause of concern?
There's been discussion of the benefits of hosted solutions and realize that I keep including SIP trunking in this category because it is in fact a hosted service. I've got great tools embedded in my network at a terrific price; a nice clean flat network that performs really well until I start monkeying around with settings in the router; a WAN connection that is really exceptional (thanks Verizon), yet I'm no closer to converging all traffic onto one pipe to one provider to bypass Verizon as my Telco, which in my case Verizon provides the pipe. Are SIP trunk providers capable of a 100% guarantee that ALL my calls will complete? Maybe you think it's an unfair question but I don't have many lingering doubts that Verizon isn't already doing this for me. Sure, they cost more and they don't always "get it" but I'm not so sure that proclaiming 40-70% savings is delivering the full picture of what customers actually are getting or more importantly what they fail to see they are risking, putting at risk or losing by way of connectivity.
SIP trunks are an exchange of bandwidth for dial tone. You get less (throughput of calls) not more over a T1, for example. Then you really must define availability; in the past we've used tried and true traffic engineering to define how much we need and where, but now we are switching over to a new model of predictability--when will bandwidth be available from cradle to grave of every phone call? Some may argue it's the same as the PSTN but I still think the predictability is easier with the PSTN than the web.
We didn't save anything by eliminating masses of hardware since we already have a pretty GREEN configuration. But as Sorell points out in VoIP/SIP 800 Trunking: Is the Industry Ready; there's a huge GREENING potential in large enterprise by reducing hardware, power, heat and footprint. Our approach in the SMB may be different and again we want a history and some mileage using SIP trunks before moving our customers into them. The capabilities are in place for successful adoption, but the obstacles exist, as I discussed in SIP Trunks: A Call To the Wild. I wouldn't go too deep on the first round and at the same time I wouldn't hesitate getting SIP trunks into your businesses for pilots, and I would use them in non-revenue impacting areas first. Then, calls offered vs. calls delivered shouldn't be any different; it's just how do you or should you account for this?
Again, I ended up with more questions and the one that I think the Telcos will or should be pondering the most is: are we about to see another paradigm shift--will the Internet become the primary transport and the PSTN secondary, or do you think this has already occurred? One thing I do know--bandwidth is just as sacred as dial tone. The IT gods must be laughing at this one.
Here are some thoughts on how to exploit SIP trunks (Our tact is to use surplus bandwidth vs. an all out assault)
* Use SIP trunks to load traffic for outbound calling to avoid any long distance or any type of toll or message unit charges. That PBX/IP-PBX with ARS/LCR (Automatic Route Selection/Least Cost Routing) still comes in handy. * Use SIP trunks for interoffice calling especially if the provider can provide the private dial/numbering plan * Use SIP trunks for click to talk to me/us on your websites * Use SIP trunks to offload inbound calling to call centers * Use SIP trunks to gain a local market presence by purchasing DID numbers in available cities or to run test market campaigns * Use SIP trunks with "concurrent calling" to ring simultaneous multiple destinations * Use SIP trunks to deploy T.38 fax that may be cheaper over SIP trunks? * Use SIP trunks to create fax and modem pools * Use SIP trunks as "alternative, bypass and backup routes" * In all the examples you can apply every one of them to what we are doing--we are setting up SIP trunks for customers that already have diverse routes in their infrastructure. They have an overflow/backup route sitting mostly idle and this is where it makes great sense to use SIP trunks today
