Author: DrVoIP

Peter S. Buswell (aka DrVoIP) is a rare blend of C-level executive leadership and deep technical expertise in telecommunications and cloud infrastructure. With a career that began at AT&T in 1970, he has founded and led multiple industry-defining companies, including Dextr.Cloud—acquired by AWS Global Partner CloudHesive. Peter has held senior roles at firms like Exxon Enterprises, Intervoice/Brite, and Franklin Telecommunications, and has consistently driven innovation from traditional PBX to Amazon Connect cloud deployments. A hands-on architect with certifications from Cisco (CCNP/CCDP, UCCX/UCCE) and AWS (Solutions Architect, Developer, SysOps), he combines strategic vision with engineering precision. Known as DrVoIP, he continues to bridge the gap between enterprise goals and technical execution in today’s evolving cloud communications landscape.

Trends – Part 2 the impact of SIP

Posted on by DrVoIP

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.

Trends in the PBX equipment market – Part 1

Posted on by DrVoIP

From time to time a new technology comes along that causes a dramatic paradigm shift with significant economic impact. As it relates to the customer premise telecommunications world, there are a number of trends that have the potential of dramatically altering the telecom equipment market place.   Many industry executives have witnessed the switching equipment transition from electro-mechanical technology to solid state and stored program control switching. Clearly the migration from circuit switch to packet switched technology is reaching Tsunami proportions.  So what happens next?  There are three trends coming into high relief on the technology adoption radar screen  that will have significant impact on the telecommunications marketplace, the economics of the marketplace and ultimately define the employment requirements in that market place.  I would summarize and simplify these trends as the commoditization of PBX hardware; the increased acceptance of SIP and the explosion of high speed wireless technology.  The next few blogs will briefly examine each of these trends at the 100,000 foot level.

This blog will take a look at the commoditization of PBX hardware.  Unlike circuit switched technology, packet switched communications demands that the enormous economic investment necessary to the creation of high speed digital signal processing and the supporting semi-conductor technology be rewarded with high volume production.  Production is a factor of demand and to increase demand, prices must be continually reduced.  This reduction in price is achieved in large part by the adoption of the core technology by a wider base of equipment designers.   This is an economic over simplification for purposes of blogging, but  you do not need an MBA in economics to understand why the  Apple Mac is now built on Intel chip technology.   Nor do you need an MBA in marketing to understand the challenge of trying to convince an increasingly savvy consumer market that your brand of laptop is better than the other guys laptop brand!

As goes the PC hardware market, so goes the media gateway market.  Demand for gateway interoperability will make it increasingly more difficult to differentiate one box of DSP’s from another.   For this reason telephone system manufactures will have to make a fundamental decision:  are we in the the hardware business or are we in the software business?  Are we planning to become the low cost, high performance provider of the VoIP building blocks?  Or are we focusing on the applications (read software) that drive the need for building blocks?   It is my assertion that you can not do both and be successful.   A free market place will demand that “PBX” hardware be separated from “PBX” software.   

Consequently, the skill sets of VARs will be tested yet again.   With the transition form TDM to VoIP, traditional PBX vendors had to develop network engineering expertise.  In the near future, before many VARS have made this first transition, they will be asked to make yet another transition.  Application level software integration expertise will become the underlying skill set demanded of the more successful VAR.   So are you in the business of who can sell a ShoreTel SGT1 cheaper than CDW? Or are you in the business of executing the delivery of underlying technology and application solutions?  Both the supply chain and the distribution channel will once again be redefined and that only question remaining is: just how fast will this transition occur?

   

ShoreTel Star Codes!

Posted on by DrVoIP

starcodes

Though I know we have readers out there who have never seen a rotary dial telephone (or a 33 RPM record), many readers will be familiar with “star codes”. Star Codes have been generally well known to most phone users since the inception of DTMF dialing. Who has not done the old *82 to block caller ID? In the ShoreTel system, basically, every feature has a star code making it possible to use a simple single line telephone set to do advanced features. If you do not have a list of these codes, send support@drvoip.com a request and we will send them right along. The characteristic of star codes that has me excited is how ShoreTel uses start codes with its “office anywhere” functionality. Many systems have the ability to forward a call to your cell phone (pun intended), but generally, the call dead ends there in your hand. How wonderful it would be to be on your cell phone and be able to transfer the caller to another team mate BACK IN THE OFFICE PBX! ShoreTel has a number of start codes that enable you to do jus that. In fact, **+Extension number+## will do just that! There are also star codes for conference e, hold, and access to the other star codes we talked about earlier. Now that it some powerful call processing, would you not agree?

ShoreTel Tools for Checking remote dial tone?

Posted on by DrVoIP

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!

VoIP and SRST/AES Encryption!

Posted on by DrVoIP

Encryption of VoIP traffic was, for some of us a humorous concept. I remembered as a young development professional how much fun it was to use a packet sniffer to capture the bosses packets and reassemble his email over the LAN. Years before that when I worked at the phone company as a central office test engineer, it was not uncommon to find an interesting phone call and plug it into the over head paging system to provide entertainment for the late night test crew. There are times I still think the concept of encryption on VoIP is humorous, but it is becoming less funny all the time as we move toward end to end VoIP with no TDM at all in a world populated by terrorists and other evil doers. In any VoIP environment today, you can at some point use the usual tapping tools to capture a phone call as it hits the TDM gateway and is converted from VoIP to traditional analog or digital signals. From an induction coil to a line mans butt set, you can still intercept a VoIP call as it crosses the TDM boundary.


Now that VoIP is being used end to end, we do need to have a mechanism for encrypting at least the media stream. Today we generally do that with SRTP and IETF standard in combination with AES. AES or the Advanced Encryption Standard was adopted by the US Government and comprises three block ciphers: AES 128, AES 192 and AES256. Each AES cipher has a 128 bit block size with key sizes of 128, 192,and 256 respectively. This standard has generally replaced the former Data Encryption Standard or DES. It is important to understand the difference between encryption and authentication. Determining that a signal is “authentic” and originated from a source we believe to be authentic, and encrypting the contents of that communication are two very different issues. Media authentication and encryption ensures that the media streams between authenticated devices (i.e. we have validated the devices and identifies at each end) are secure and that only the intended device receives and reads the data. We need to encrypt both the media (i.e. the voice) and the signaling information (i.e. the DTMF). In most VoIP systems today, SRTO or secure RTO is implemented to assure media encryption. Understand that this encryption is not passed through to the TDM network, so once the media stream leaves the VoIP environment it is subject to eavesdropping.

Clearly as we are now able to employ VoIP end to end, SRST/AES encryption has very powerful ramifications for both the good guys and the bad guys!

Least Cost Routing?

Posted on by DrVoIP

At one point in the evolution of telecommunications features, least cost routing was so sophisticated a function that it required an external processor. In the early 80’s when most large multi site telephone system installations were based on point to point, private T1 tie-lines the need for cost effective routing between sites was in such demand that a stand alone company of scale was formed to meet that need. In San Antonio Texas, a company still in existence today but with a much different agenda was formed to bring the Infoswitch Share family of products to market. These systems consisted of a rack mounted shelves of T1 telephone interfaces, that communicated with a centralized computer over a proprietary data link.

Most intersite dial tone was provided based on human selection. You might dial 81 for the tie line to New York; or 82 for the tie line to the Chicago office. Once at the other site you would then dial access the telephone lines connected to the pbx at that remote site. The decision making as to what facility to access was left entirely to the user and whatever printed instructions might be made available Scotch taped to the side of the phone. The Infoswitch Share family changed all of that! Infoswitch would accept interfacees from the systems at remote sites and using a stored program that reflected the various rate centers reachable by each end point; or the WATTS lines that might be available at a particular facility, it would route user requests for service.

VoIP solutions generally available today have to address the same circumstances. A primary driver of VoIP solutions is that they seamlessly integrate geographically dispersed workgroups into a single image phone system. The central “soft switch” has an intimate understanding of the PSTN facilities at each end point. Trunk groups are created with dialing definitions that enable the entire system to facilitate least cost routing at a level of accuracy that has become increasingly more complex as we add new exchange codes. Back in the days of the Infoswitch, all area codes had either a 1 or a 0 in the second digit, making area code recognition a breeze. Today we not only have to figure out what is an area code, we have to figure out what can be dialed as a local call and what is a long distance call. Long distance also has a new litany definitions as terms like “local long distance” creep in our vocabulary.

ShoreTel has a reasonable least cost routing facility. You have the ability to create trunk groups and assign dialing rules to those trunk groups. In an area like San Diego we have four area codes (see previous post) that might at one time or another be consider either a local or a long distance call. Lets consider an installation in which we have two site. One site in the 619 area code and the other site in the 858 area code. Both sites have PRI lines to the phone company. One of the benefits of having a multiple site system is that if one PRI goes off line, the system should be able to re-route calls through the other site. In this example, we have a couple of interesting warts to deal with. Lets assume the 858 PRI goes down. A caller at that site, picking up a handset and dialing any area code and number other than 858 will have no problem, the call will go out the 619 PRI. At that same site, had they dialed a 7 digit local number, the system would not allow the call without some advanced dialing rule programming. The reason for this is that the ShoreTel will consider the 858 a “cost promotion” if it was to go out the 619 PRI and this is not normally allowed.

There are ways around this, a custom dialing rule access can be enabled on the ShoreTel trunk group. We can create trunk group preferences and to some extent we can generate new dialing patterns. As the national dialing plan moves closer to a 10 digit rule for all phone calls, the subject of least cost routing and programming will continue to be an area that requires considerable planning, design, implementation and testing. When you through SIP trunks into the mix, complete with remote area code origination, the possibilities become endless.  Stay tuned and keep your hands and feet in the car at all times!

How to get your iPhone running SIP on your ShoreTel IPBX!

Posted on by DrVoIP

If you are and iPhone aficionado, you absolutely want your iPhone to work  on your ShoreTel IPBX! I recently downloaded VeNetCorps SipPhone fromt the iPhone App store! There are several SIP phone apps at the store, but most have a pre-programmed domain name for the sip registration proxy server. If you want to use your own SIP proxy there was no easy way to change the IP address so you had to hack your DNS to get it to point to the ShoreTel SIP proxy. Also you need at least iPhone firmware 2.2 as previous versions had WiFi connectivity challenges that negatively impacted the potential for using a SIP softphone. After the iPhone WiFi acquired an IP address, if you attempted to ping the address you would see latency in excess of 300ms. With version 2.2 this issue has all but become unnoticeable. As with any SIP extension setup on ShoreTel, you need to assign sip extension proxy resources on a ShoreGear switch. In the sites section of the ShoreWare Director, make sure you assign a virtual IP address. This is the address you will use for your “domain’ when you setup the Iphone SipPhone. Clearly you will need a User setup with a SIP phone password defined in the individual user section of the ShoreWare Director.

Clearly the assumption here is that you have a WAP that your iPhone can connect to. Also that that wireless connection can route to your ShoreTel network! Once the ShoreTel SIP user, virtual IP address and proxy resources are configured it is time to configure your iPhone SipPhone! After you down load the application and tap to activate the application you will get a screen that lists the options: Dialer, Recent, Contacts, Accounts and Settings. Hit the Accounts tab and you will then EDIT a new SIP account. To get this app to work on ShoreTel you need to enter only three values. First you need to enter the domain name, we have previously defined in the ShoreTel Director as the Virtual IP address. The Username and password are also as specified in the individual user setup in ShoreTel. Hit the DONE tab, and the phone should register and you can make and receive calls from your ShoreTel. I put together a video clip that covers this so you can see that it accutaly works! The video suggests that you enter the user name, but if you want to call the iPhone from a ShoreTel extension, enter the user’s extension number instead.  This was just a fun project and latency on the iPhone WiFi is still a challenge for SIP phone usage.  I suspect that Version 3.0 of the iPhone will fix this small issue, but it was a blast trying it out!  Enjoy!


Add your iPhone as a ShoreTel SIP extension!

ShoreTel ECC Abandoned Call – Call Back and Dial List applications!

Posted on by DrVoIP

The ShoreTel Enterprise Contact Center has several features that are often confused: Abandoned Call, Call Back and Dial Lists. Thought the features are somewhat similar, they work in different applications and not all for these features are available in the basic Contact Center. The ShoreTel ECC uses the concept of a service to encapsulate the handling of an incoming phone call. Generally the Service includes Groups, which include Agents, but groups can encompass other call actions. For example, a Service can contain a “script” that prompts the caller for DTMF input or calls on a SQL query to search an external database The Service also provides instructions for how queue messages are to be played to the caller.

Abandoned Call back enables the system to recognize that a caller was in queue but hung up before being serviced. The ShoreTel ECC can capture the Caller ID and then return the call! Typically an Agent is “reserved” before the outbound call is placed, the call is dialed and then transferred to the agent. It is also possible to play a pre-recorded message to the called party before the call is transferred to the agent, but there are reasons that you might not want to do this.

Let’s make a modification to our queue service to hold the caller and after a period of time, offer the caller an option to bail out. This is where the “Call Back” feature comes in. ShoreTel enables you to create a “script” that can not only prompt the caller to enter a return telephone, but also offer the caller the option to schedule a particular date and time for the call back. This is a very useful option for callers that have a “help me, teach me, show me” request but not at a level of urgency that would inspire them to sit on hold for an extended period of time.

The “dial list” feature of the ShoreTel ECC usually works in conjunction with a database dip. Lets take a typical credit and collection application. The ShoreTel ECC can access a database of delinquent clients, obtain the phone number of the client, dial the client and pass that call to an Agent that has been reserved by the system to handle this type of call. The system also provides for the option of updating the client record with a completion status for further database processing.

The ShoreTel ECC is an exciting application that can be used in the small to medium sized “contact center” environment to enhance functionality, increase productivity dramatically scale the functionality of an already powerful VoIP solution. (Note ShoreTel ECC and Contact Center have been used interchangeably in this blog! The ShoreTel Enterprise Contact Center is a superset of the ShoreTel Contact Center and feature content may vary between the two versions).

Add ShoreTel Extension Lists to your Automated Attendant

Posted on by DrVoIP

Extension Lists are a unique solution for a variety of challenges in the Call Flow War! Does your Automated Attendant have a “spell by name” directory? Does the CEO want to be listed in the spell by name directory? In ShoreTel it is easy enough to disable a name from appearing in the directory, but what about that nasty ability to take action on the famous “if you know your parties four digit extension number, dial it at any time during this greeting….”. Think about it, anybody can bounce around the company telephone system after they hear that announcement! Sooner or later they may even find the CEO! So what is to be done about this possibility? In ShoreTel, you can create Extension Lists.These lists can be used for setting up paging groups, but they can also be used in the Automated Attendant.When setting up the Automated Attendant you have a drop down list of each of the digits and the ability to define what should happen when someone pushes that digit(i.e. send to a menu, transfer to an extension, take a message).There is a special entry list that includes what to do if the caller “Time Out”; or “invalid entry” or hits “multiple digits”.Typically, this last option: “multiple digits”, is set through the drop down menu to “Transfer to Extension” echoing the digits the caller entered.If look at the right of that drop down list, similar to the other menu items, you can click and select an Extension List!How wonderful!You can actually create a list of extensions that the caller can dial and limit the digits that the Automated Attendant accepts to only the extensions on that list!This assures that the caller will not accidentally hit the extension that activates the overhead paging system or ring the CEO’s office!

ShoreTel AA drop down list!

Admission Bandwidth Control?

Posted on by DrVoIP

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!