Lets take a look at the impact of SIP – Aide from the pure technology play, SIP represents a fundamental change in the economics of the telecommunications market. The carriage of telecommunications has been in transition with a steady migration for distance sensitive to usage sensitive pricing. Historically there where three components of the cost of a telephone call: origination, interexchange (e.g. Inter-LATA) and termination. The US telecommunications market has been moving toward a consolidation of service providers. Local Exchange Carriers (LEC) and competitive local exchange carrier (CLEC) is becoming as consolidated and the Inter-Exchange (IXC) carriers. Where do we draw the line on Enhanced Service Providers?
Generally, throughout the rest of the planet, telecommunications services are still owned and operated by government monopolies. Rural telecommunications for much of the planet is predicated on the payment of termination fees. If your favorite telephone company wants to interconnect with your parents in another country, they must pay a termination fee to the phone company in that country. This is not unlike the model of a US based LEC paying the IXC who paid a fee to terminate your phone call in another LEC. A complex price model and tariff structure exists even with the current “bucket of minutes” concepts borrowed from the wireless carriers.
At issue here is the impact of SIP phone calls made through the internet, both public and private. With the growing acceptance of SIP trunking and the development of E164, internet alternative carriage is also pressuring the move from TDM to VoIP. The Electronic Numbering Mapping System (ENUM) provides users with, what marketing people would call “experiential compatibility”. Being able to dial a phone numbers in the manner that users have become comfortable is absolutely essential to the success of the migration to and the adoption of VoIP solutions. SIP and ENUM work together to accomplish this.
The impact on the economics of telephony services is dramatic, both at the infrastructure level and and at the usage level. The cost of building packet switch networks, like the cost of build out wireless networks requires significantly less capital investment. The cost to the users will certainly not be distance based; but access and bandwidth based. SIP also provides for the increased use of multimedia communications solutions, also a bandwidth intensive application.
Sometimes there is nothing like a telephone lines mans test set to hear exactly what is going on! VoIP solutions have a double challenge: First it is hard to put a butt set on an IP connection; and secondly what happens when that connection hits a gateway at a remote site? This is always a fun situation. ShoreTel has a “trunk test tool” that has some usability. You can actually bring up the test tool, and right click a particular telephone line and place a call. If you are really in the fast reader group, you can set the test tool options to point the call at your own remote handset. In this way, you are sitting in NY, dialing out on a SF analog telephone line.
ShoreTel has another debug tool that is very useful for “hearing” what is happening on a remote analog telephone line at a site that you just cant get a handle on. You can literally telnet into the switch and setup up a recording session and capture the analog line sounds to a file back at your location. This will enable you to listen to the error message or lack of dial tone, locally enabling you to make the right decision about how to handle the trouble ticket.
The audio output of the analog trunk port is saved on the HQ or DVM server that controls the switch. To do this, follow this procedure:
From the start menu, navigate to the Control Panel> Administrative Tools and locate the IIS Manager;
Right-click on the IIS manager and select Properties. Then enable the ability to write to the FTP server by selecting the Write checkbox and clicking OK. This enable the ability to write to: C:\Inetpub\ftproot
At the command prompt, run the following VXWorks commands: Record2File2 (1, 60, “test” ) Audio data from running this command is stored in the file test_rx.pcm and file test_tx.pcm in the C:\Inetpub\ftp which will be stored as 8000Hz 16bit, Mono and can be listed to using a standard audio application.
Give this a shot the next time you are trying to “hear” if an analog line out at some remote location has any dial tone!
In a VoIP environment the WAN circuit is generally engineered to handle X phone calls of a specific codec. For example you might plan out a circuit that supports 10 simultaneous phone calls across the WAN between sites. You select the G711 codec and plan each phone call at 82KPS per call. This would require that there be a minimum of 820KB of bandwidth available or approximately 55% of a full T span. Given that the WAN connection also supports data applications, we want to assure that Voice does not take all available bandwidth! Interestingly when people complain about the bad quality of a VoIP call, it is generally the result of exceeding a bandwidth limitation, If you engineered the circuit for 10 calls, when the 11th call is placed, not just that phone call is trashed, but all 11 phone calls are destroyed! For this reason VoIP systems in general and ShoreTel in particular have strategies for limiting the number of calls across the WAN. In ShoreTel there is a parameter entitled “Admission Control Bandwidth” located in the Sites definition in the ShorewareDirector administrative web portal. This parameter assures that a call will not be set up between this site and another site, if that phone call would exceed the bandwidth setting. This generally eliminates the 11th phone call on a circuit designed for 10 simultaneous phone calls! ShoreTel switches or media gateways, know about the bandwidth they would consume when setting up a phone call and can take action based on this ACB parameter. We need to apply solid WAN engineering practices to the circuit planning however, as the ShoreTel switches will not know if that bandwidth is actually available! So it is possible that the ABC parameter will allow a call to be setup, but bandwidth may not actually be available as other data applications might be consuming more than planned bandwidth at that point in time. For this reason, we need to prioritize voice and data with queuing strategies in our WAN routers, the subject of yet another blog!
Has the economy hit VoIP? My thinking is that it has and in a very positive way for both integrators and voip service providers. Throughout my career I have always been amazed at the number of traditional key telephone systems sold into the small business segment of the telephone equipment market place. If you added up the numbers as published by the publically reporting companies in this segment, extrapolated an average SBE equipment size requirement you would conclude that every man, woman and child in this country already owns a telephone system! So where do all the new SBE phone system come from? Having said that, this number is getting harder to calculate as the companies that you could track in this segment (e.g.. Vodavi, Comdial, etc) have morphed into something else and generally as a direct result of the increasing acceptance of VoIP in that market segment (e.g. Covad, Packet8, Vonage et. Al). The economy even when it contracts, causes companies that survive to change their shape and size. We have witnessed a growing demand for companies seeking to spin off a branch office as a standalone business. If you have a CISCO Call Manager, for example, and you were running SRST at the branch office, we are servicing requests to convert the branch to a standalone CCME. Business Partnerships dissolve, the partners create new entities and split a perfectly good ShoreTel IPBX in two! Service providers in general, seem to be showing increases in VoIP revenue segments, specifically in the SIP environment. Cbeyond (CBEY) seems to be trading at near its 52 week high. Generally, my thinking is that VoIP is a good place to be no matter which way the economy moves!
When VoIP gateways first started hitting the market back in 98′, the vendors tried to packetize DTMF and quickly learned it did not work well. For this reason they quickly learned to “regenerate” DTMF at the outbound gateway rather than packetize and truck it across the network. Moving modem tones is even more challenging and most VoIP solutions discourage attempting to send modem tones over an IP connection. If you can get it to work at all, the modems will negotiate down to about teletype speed or about 300 baud. (Now there is a device and an term you don’t hear much about anymore). Given that a fax machine generates modem tones, faxing over an IP connection is equally challenging. ShoreTel makes it possible, for example, to attach a low end fax server as a couple of analog IPBX ports. Incoming fax calls to the IPBX system, can reroute these faxes and even regenerate the DID number as DTMF to the fax server enabling fax to email applications. What we are beginning to see as the SIP market matures, is that the phone companies are bringing PRI circuits to the customer premise disguised as traditional TDM circuits. Your Telco interface may in fact be a ShoreGear T1, but you are interfacing to an Integrated Access Device that is converting SIP signaling to SIP and then on to the Telephone companies softswitch. Currently, this is a big problem for fax machines connected as analog lines to the host IPBX. True Fax over IP is going to require a T38 interface and fax machines and servers that can support this protocol. The message here is, make sure you know what you are connecting to! True TDM or a SIP trunk! Knowing the difference will enable you to properly handle fax traffic.