Route Points, IRN’s and Media Streams!

Lately the subject of ShoreTel Route Points and IRN’s has been getting a lot of “mind share” from those working with them.   Two questions:  How many Route Points can a ShoreTel server support?  How many IRN’s can an ECC support?  How many DNIS numbers can a ShoreTel support.   Seems like a simple set of questions, but the answers are something like “herding cats”.    Route Points are used in a ShoreTel system to accomplish call routing and TAPI connectivity between the IPBX and the Enterprise Contact Center, for example.   Let us assume, for purpose of illustration, that you have a large call center and you want to track the effectiveness of your advertising campaigns.   You determine to do this by tracking DNIS numbers.  Each DNIS represents a different advertising campaign.  Recently, I came across a client who was creating a route point – IRN pair for each DNIS number.   Nothing particularly wrong with this, but using the DNIS map would have required only one Route Point if the DNIs was pointing to the same Group of Agents (e.g. Service) in the Contact Center.

The Contact Center, currently can only map one DNIS number per IRN.  It is my understanding that ShoreTel may be moving toward 1000-1500 DNIS numbers in future ECC releases.  So if you want to run report about DNIS you might have to look in two databases: (a) the ShoreTel MySQL CDR database on the IPBX; and (b) the C2G database on the ECC.  You will need to use the GUID if you want to tie the two databases together to get the DNIS and Agent Events and Wrap codes.   If you bring the DNIS into the IRN,  to enable DNIS reporting in the ECC, you can see the list of IRN’s could get very long and there is a  limit.

I suspect that DNIS has a limitation as well.  My thinking is that DNIS numbers would live in the various SG switches.  So the ultimate answer to how many DNIS numbers you can have may be memory constraint and  configuration specific (e.g. different for each configuration).    If you have any input on this, I would welcome it!   At the end of the day what we know is that you can create Route Points all day long in ShoreTel (though I have not attempted to find the real limit).  If the Route Points live on the ShoreTel server the real limitation is the 254 simultaneous media streams that a Microsoft Server can support.   If you point 12 PRI’s at one server and you have the potential of having 276 simultaneous phone calls, bad things are going to happen.   You need to spread your media stream over multiple servers.   In the contact center, you generally shape media streams (e.g. IVR ports) to 150 per server.

The “devil is in the details”.

What is all the Hub about?

So you can’t get any help from the IT department getting a private printer connected to your office PC.  So what do you do?  You run down to your local favorite “we sell cheap computer stuff” store and buy a “hub” or “usb multiplier” or something that looks like a small “Ethernet Switch”.  You take it back to the office, and having send the quick start guide, you unplug your computer from the wall jack, plug it into your shiny new thing and run a cable from it to the wall jack.  Then you plug in your new printer!  Maybe you go really geek and add in your own scanner and wireless access port!

Enter VoIP phone deployment.  Anyone that has done a VoIP deployment knows or has learned the hard way, that “hubs” will kill a VoIP phone deployment!   Multiple devices in a hub will immediately change your ethernet port to half-duplex.   If you put the VoIP phone behind the hub, you are either using a local power brick or you will not have access to the POE on the home ethernet switch.   Running around a 400 desktop installation trying to reconfigure the wiring so that the wall jack feeds the phone and the hub goes into the bottom of the phone is one option. That is always a time sink and usually outside the statement of work (SOW) of any knowledgeable systems integrator.

Hubs need to go the way of “buggy wips”.   They mark a network as unmanageable and general indicate that there is no professional network administration being conducted at that location!   Personally, hubs should have the same warning label the government wants you to put on cigarette packages!   Hubs and toy switches may be ok for you home network, but in this day and age they have no place in an enterprise deployment and when it comes to VoIP deployments, they just don’t make sense and they don’t work!

VoIP is Intimate

A VoIP deployment is an act of intimacy.  One of the great challenges for the deployment team is defining the demarcation point between the phone system, the network and the various applications that integrate withe the phone system.   Clearly, the foundation of a successful deployment is a strong network foundation.   The ability of the network to provide the necessary DHCP services including NTS, IP and vendor specific options are area’s that need to be clearly defined.   Who is providing these services?  The existing data network, or the new voice network?  Is the the in place data network infrastructure capable of supporting the addition of low latency, zero packet loss, not jitter voice and video?   Can the in place access level switches support true 802.1Q Vlan functionality?  How will routing between the voice network and the data network be provided and who will be responsible for configuring these services?

The VoIP network invariably needs to interface with other applications.  Minimally, the VoIP solution will interact with both the Active Directory system and the contact management system (Outlook, Notes etc.).   Who is responsible for this configuration and problem resolution?  The VoIP solution vendor or the the client?   When the Call Managers fail to work properly because of an undisclosed Proxy Server that was not disclosed in the statement of work (SOW), is that time and effort that the VoIP vendor should eat, or is this an area the client should be responsible for?

Any professional that has worked with commuter network technology for any period of time understands that the complexity of integration issues makes these divisions of responsibility very difficult to enforce without jeopardizing an ongoing relationship.  The client wants everything to work better than it worked before the vendor got enveloped.  The vendor wants to provide a key area of expertise without taking ownership for all that came before.

Unfortunately, a VoIP deployment is as intimate as a marriage.  You get more than a spouse, you get the entire family.   I often have clients ask me to provide references for my past work.  Clearly, I come up with a list or excellent references.  What I am always waiting for is a client who is smart enough to ask for a list of “disasters”.   You would think that clients would want to know how a vendor performed when Murphy ran amuck!   When everything that could possibly go wrong went wrong!  That is the client list you want to review.

A VoIP deployment is a marriage between a vision and reality, it is a leap of faith.   The Vendor and the Client need to look past the initial courting and dating, and look down.  We all start out young and good looking.  It is how we deal with the process of design, implementation, operating and the ongoing optimization of both the deployment and the relationship that really determines the ultimate success of a VoIP solution.

Preview ShoreTel ECC 5.1 Agent Tool Bar!

ShoreTel has now release the Enterprise Contact Center 5.1 for Beta users.  We are just now playin with it, but it has quite a few hot new features and even a new “look and feel” as it relates to icons.    For those of you who have installed the ECC, one of the more time consuming aspects of this deployment is the need to visit each desk to install the Agent Toolbar software.   Well, your prayers have been answered! An MSI is now available!  This will make upgrading, even a maintenance release, just that much more fun!   The 5.1 version has some other exciting capabilites that we will explore in detail in later blogs and film clips.  One of these is the ability to generate Real Time Adherance capability, a workforce management function that many call centers are demanding.  There are some new tabs and configuration options and as I said, there is a new look and feel.    Again, we will take a closer look at these features as we get more Beta experience but for now, lets just take a look at the Agent Tool Bar!

Where is the ShoreTel ECC Query file?

The ShoreTel Enterprise Contact Center has two sources of generating both historical and real time data.   With the release of 5.X, ShoreTel created the C2G (“cradle to grave”) or Interaction Reporting functionality.   This MySQL database is clearly visible in the default location of D:\ShoreTel\Contact Center Server\DbProvider\Data\c2g  though you may have installed it somewhere else.   For this database to be active, you have to create an OBDC connector to the MySQL database on the local host.  Then database connector in the System tab of the ShoreTel Contact Center Director has to be selected to enable the database write.    The C2G database is something like the CDR database on the PBX.   It captures real time events about ONLY incoming phone calls and enables you to create custom reports not previously available.  For example, Wrap-Code by Agent!

Prior to 5.x, the only report database is actually more of a statistical peg counter and has not detail behind it.   You might track the number of phone calls received by an agent, but not have any detail about the nature of the events that make up those phone calls.   Average talk time, for example, is arithmetically derived and is not the result of actual detail as captured in the C2G database.  One of the more interesting learning experiences you can have with the ECC is to examine the actual SQL query that is generated when you run a report!  Very instructive.   Each time you run a report, a SQL query is created.   Where does this query live?    If you look in the default path D:\ShoreTel\Contact Center Server\Log you will find a SUSQL.TXT file.  This file contains the actual query that was generated when you ran one of the canned reports on the ECC.   This file will be overwritten each time you generate a new file, but it does contain the most recent report query.   It is a great source of educational information on how to write query’s!   The attached video is a quick visual summary of this blog!

Analog lines in the 21st Century?

Getting old is a pain in the neck!   Literally and figuratively!  I am trying to figure out the benefits of getting older and I am not coming up with a very long list.    You built a library of experience, I guess that must count for something.   There is new generation of telecom professionals that have no idea what a cross bar switch is, but so what.   Nobody is really missing buggy wips either.   In the old “Bell System”  (I have really dated myself now, as google demographics tell me my readers were born post breakup) there was a specific regulation against the interconnection of analog telephone lines on an PBX.  Now part of that restriction was the Bell System being a bunch of anti-competitive jerks, but there were also real technical issues for not doing so.   Analog lines are most useful in man to man communication.   The issue here is the concept of “answer supervision” and “calling or callED party disconnect”.   

When you answer the ringing phone in your house, the answer supervision is actually your ear.   You can “hear” the other party.  yes, there is a line reversal or voltage change but being a two wire loop is nothing like being a trunk line.   For that reason we use trunks to interconnect machines to machines.   Every go to make an outside phone call, and find someone on the line?   Great example of “glare” the concept of a call ringing in just as you where grabbing it to make an outside call.   Analog lines are good for key systems with winking and blinking line keys that show everyone who is on what line, but they are a real annoyance on a PBX system.

Answer supervision is poor if it exists at all and glare can be a real issue.   Throw a couple of Centrex lines in the mix and you will get some real extra fun features.  Nothing like having analog lines connected to your PBX that have feature treatments you did not know about.   It is always phone when the phone companies VM picks up before your ShoreTel VM system does!  As a rule you might like to have one analog line at a site for 911 and power failure, but the idea of running a ShoreTel PBX with a rack full of analog lines, actually makes me ill.   Judas Grunt,  it is the 21st century already!   Can you spell SIP?

ShoreTel does a reasonably good job with analog lines given the real disadvantage they have in the area of answer supervision, etc.   ShoreTel actually goes off hook on these lines at timed intervals.  If it does not “hear” dial tone, it marks the line out of service.  If you are really cleaver, there is a trick to recording the sound made when the line goes “off-hook” so you can retrieve the wav file and play it back locally.  A great life saver when you are in Portland and your trouble shooting a local loop in a remote site, just outside Minute, ND and nobody is in the office.

It amazes me that we still have analog lines on PBX systems, but as long as we do, we might as well learn how to deal with them.