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. Continue Reading...

ShoreTel has a family of new media gateways.  The more interesting switches are referred to as SGV switches.  There is an SG50V and an SG90V that differ only in the number of FXO and FXS ports that they support.  What makes these switches (i.e. media gateways) so interesting is that they have a LINUX kernel built in to support a Compact Flash Card which enables localized Automated Attendant and Voice Mail.   In the world of ShoreTel's "single image solution" we have the concept of a DVM (e.g. Distributed Voice Mail sever.     The DVM are typically deployed at remote sites and, as explained in previous  blog, provide for a level of resiliency (not redundancy) in your multi-site solution.   More importantly, as the DVM enables Voice Mail and Automated Attendant to be localized at a remote site, it keeps these bandwidth intensive functions off your very expensive WAN. 

For example, if I have a New York HQ site with users, media gateways and workgroup services; I might have a North Carolina remote site with a DVM, media gateways and users.   Workgroups are currently NOT a distributed service, so any workgroup functions will require the HQ server.   However, in North Carolina I can assign the users at that site to Voice Mail boxes on the DVM at that site.   Callers to telephone lines that terminate on media gateways at that remote site will be answered with an Automated Attendant that lives on that remote DVM, eliminating the need to stream that media across the very expensive WAN.  (Note: historically the media stream was G711 as it originated from the server regardless of the Inter-site codec.  Recent release of ShoreTel enable a HQ media gateway to proxy the media stream enabling the use of the lower bandwidth Inter-site code).    Should the DVM at the remote site fail, the HQ server would take over for the remote site.  In this way VM and AA are still provide to the remote users.

The new SG50V and SG90V are typically used as replacements for or instead of a DVM at a remote site.   The question arises as to what would happen if you added an SG50V or SG90V to a remote site under the control of a DVM?  One would argue that it would make no sense to install  these media gateway in that scenario.    In the ShoreTel architecture it is important to note that DVM's fail upward.  For this reason we might install the SGV media gateway as a new site under the remote site.  So in this example we might install a new site under North Carolina and put the SGV media gateway in that new site.  Then we might move all the users at the North Carolina site to the new SGV media gateway for voice mail and automated attendant.  In this way, the SVG should it fail, would have its services picked up by the North Carolina DVM; which in turn should it fail, would have all services picked up by the HQ server. 

The new SGV switches are very interesting building blocks for the ShoreTel architecture and should be studied in some detail.  They also might indicate a move by ShoreTel away from both Microsoft and VxWorks.   This is only conjecture on my part and not based on any fact other than that we which can all observe.  ShoreTel has dropped the Microsoft Access Database in favor of the MySQL database engine.  Clearly this could be just a cost cutting move.  However, the SGV switches, do not have VxWorks, they have a Linux kernel.    Taken together these may in fact be an indication of a product road map that is moving steadily toward a total Linux based solution.

Find this and other videos in our video library at www.drvoip.com Continue Reading...

Voip Solutions
If you ask your average IT professional what a T span is, the usual response will be that it is a 1.5MB connection to the internet. Ask your average telecom tech what a T span is and you will be told it is 24 channels of dial tone! Ask a VoIP Engineer what a T span is and you should get the answer:, "what do you want it to be"? One of the great challenges of implementing a business VoIP solution is the absolute requirement that the implementation team possess an interdisciplinary skill set. The solution demands expertise in a range of specialized skills including IP network, switching, routing, supplementary telephony services , server technology management and application call flow integration.  If the user group is going to fully realize the benefits of a business VoIP implementation, then each of these specialized areas of technology are going to be necessary to a successful deployment. Traditional telephony vendors are comfortable with all things TDM. Continue Reading...

Shoretel

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. Continue Reading...

In telephony, VOIP QOS is somewhere between a science and an art.  Setting up QOS on your network is essential for toll quality voice from end point to end point, especially across a WAN.Historically, in ShoreTel, IP packets were marked with the DSCP value set in the Call Control Options page.  Generally  this is generally set as a value of 184 or Precedence Level 5, what CISCO would call Express Forwarding or EF. This value is represented as 184  (10111000 or 46) but as a TOS/Differential Service Control Point marking it is  only applied to the IP layer and has no impact on your LAN.   

Additionally,  IP packets were only marked on the media stream between IP phones, not between the switches or between the phones and the switches.    Version 9 of ShoreTel, now reports "system wide" TOS/DSCP support, which represents a significant improvement in your ability to control QOS. At the LAN level, it is important to know that you are working with Ethernet frames and for this reason the only QOS marking available to you is a VLAN tag. Inside the VLAN tag, three bits have been set aside for precedence markings and are named COS for "class of service".    

If you are NOT running SIP on your network, you have another QOS tool available to you.  ShoreTel media streams in other than SIP environments run on UDP port 5004 enabling you to prioritize voice over data at the transport level. ShoreTel also provides the opportunity for you to establish "admission bandwidth control" per site, to assure that the next phone call does not exceed the limits you have set with this parameter. Beware that this parameter exists only within the ShoreTel architecture and has no real knowledge about the actual bandwidth utilization of your network.  Establishing this threshold  is left entirely to the engineer designing the network. In large part QOS is best determined at the IP level and is heavily dependent on establishing queue in your routers that service latency sensitive traffic, voice and video, over less sensitive best efforts traffic. Continue Reading...

Prior to release of ShoreTel Contact Center Version 5.0,  reporting was essentially statistical analysis. The Contact Center had very useful report generation capabilities that included  the ability to add and delete columns to existing pre-defined reports. The reports, however, were generated largely as summary reports based on accumulated totals of events.  For example, you could generate an Agent Performance report that could report the total number of calls presented; total call answered; average call holding time; average talk time over a specified interval.  Though very useful for tracking aggregate call volume, the reports could not track individual agents events.   The Shoretel Contact Center had no equivalent of the Call Detail Reporting that you might find in the ShoreTel IPBX database.   What information was available, was derived by arithmetic manipulation of totals or the equivalent of "peg counters".    Each agent had a bucket for total calls, but the details of each call were not archived in the database.  This led to reports that indicated total calls for the period were 19.2 as calls were averaged over an interval.

ShoreTel Contact Center 5.0 takes a major step forward in the area of reporting.  A new feature named variously "interaction reporting" or "cradle to grave" reporting has made a major positive contribution to the contact centers already strong feature set.   The database has also migrated from Sybase to MySQL, which completes the database migration strategy that ShoreTel began with version 7 of the IPBX.   In the ECC database contains a table structure that can be generally summarized as a configuration database.    A second database, named C2G has been created and does not appear in contact centers before version 5.    This database contains about 22 tables of which four are effectively the equivalent of "CDR" records.   A table named events, tracks all the incoming event detail and includes a GUID that can be used to link back to the CDR record in the IPBX.    This database makes it possible to create very detailed reports.  For example, assume you needed a report that listed each call handled by a specific agent over an specified interval.   Additionally, you want the agent detail to include a call disposition status  or wrap code.  Prior to the C2G database, this type of report would have been impossible.  With the new C2G database, you can generate the report very easily using any MySQL administration tool, like SQLyog.    Interaction reporting is a major step forward for ShoreTel Contact Center and one that the market will be very excited to receive.  Look for a video update in our online library for a "hands on" look at how to setup configure and make use of Interaction reporting!

More info on our Shortel Services Continue Reading...

If you are an 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. Continue Reading...