What exactly is a Contact Trace Record?

Exactly what  is a CTR?

Amazon Connect creates a “contact trace record” with a unique “contact ID” for each phone call in or out of the contact center.   Older legacy telephone folks would call this a SMDR or CDR (station message detail record or call detail record) but Amazon calls it a CTR.  The end result is the same, it is a record of the details of every call made or received into the system.    From within Amazon Connect you can search for these contact records through the dashboard in 14 day increments and review the details of each record.   Amazon keeps the CTRs for 24 months in a secret location that you can not access and for which no API currently exists!    You have two options:  First, search for them using the dashboard in 14 day increments  or setup a kinesis stream and a consumer to send CTR records to an S3 bucket or some other data lake for later review.   The basic CTR is ugly but it does have a great deal of useful data and all the more reason to make it more easily accessible!  Even if you were to save the CTR records you would then need to write a custom report generator to take this data and make it human readable to fit your reporting goals!

Dextr has an Activity screen that captures all of this information and makes it available in human readable format!



DrVoIP CISCO CIPTV2 CCNP Collaboration 300-075 Study notes!

OverView of 300-075 Content

Like many other working VoIP Engineers, I have had to upgrade my CCNP yet again. The first time was when CISCO changed from CCVP to CCNP Voice. Now we have to convert from CCNP Voice to CCNP Collaboration. The good news is, if you have a CCNP voice you only need to pass this one test, the CISCO 300-075 CIPTV2! The test however, is remarkably difficult as the availability of study materials is limited. The available CISCO Press book “Implementing IP Telephony and Video Foundation Learning Guide” is just not going to get the job done! Certainly you should digest the book but do not expect to pass this exam with only the material contained in that book. The book is useful for at least highlighting the areas you need to study:

(a) Expressway Firewall Traversal Configuration;
(b) VCS Control;
(c) All things Mobility (Device Mobility, Extension Mobility and Mobile Voice Access);
(d) SRST;
(e) QOS for Video including RSVP options;
(f) SAF and CCD; ILS and GDPR
(g) LRG, AAR and TEHO;
(h) Translation Patterns and Voice Translation Rules;

All these areas were covered in the exam, so be prepared. The good news is I got an 820 when i took the test the first time. The bad news is that passing was 860! There was once question on Call Clearing codes that I had not idea how it got in this test, but none the less you might want to review  that material in the referenced URL

300-075 Practice Tests and Dumps

If you are just looking for a cheat sheet, I really cant help you as most of the stuff on the Internet is riddled with errors.  As near as I can figure it, all the practice tests and dumps on the net have the same source and are packed for marketing under different names.   I do find that they are useful for getting some focus on the exam content, but you need to look up every question and find a reference that supports the answer the dump indicates is correct.   I found many errors through study and research!  At the end of the day, you either know this stuff or your do not know this stuff.  Here is a list of sites that have practice materials available for no charge:


Real VoIP Engineer Study Sites

I found a few sites that are written by other engineers who are sharing their study notes as I am doing here.  Both of these are excellent examples created by other Engineers who were also cramming for this test.



https://ccieme.wordpress.com. (really great content)!

DrVoIP Study Notes on 300-075

In going through all the study materials, I noted my references and I offer them up here for others who may be following this path to certification.  The questions represent practice tests from the above sources in which they all had different answers to the same question.  So in keeping with my commitment to actually learn and digest this material, I dug deep to find CISCO references to support the answers or to sort through the wrong answer and find the correct answer.   As with all CISCO tests you need to carefully read the question and put the answers within the context of the subject they are asking about.  Many times there will be two very good answers, but only one is the one CISCO wants you to select to get the points for a correct answer!

1 – The HQ Cisco Unified Communications Manager has been configured for end-to-end RSVP. The BR Cisco Unified Communications Manager has been configured for local RSVP.
RSVP between the locations assigned to the IP phones and SIP trunks at each site are configured with mandatory RSVP. When a call is placed from the IP phone at HQ to the BR phone at the BR site, which statement is true?https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/8_6_1/ccmsys/accm-861-cm/a02rsvp.pdf

End-to-End RSVP

End-to-end RSVP configuration is available if the clusters are connected by a SIP trunk. End-to-end RSVP uses RSVP on the entire connection between the end points, and uses only one RSVP agent per cluster.

Consider the following scenario:

endpoint A — agentA — ICT1 — ICT2 — agentB — endpoint B

where A specifies an endpoint in cluster 1, B specifies an endpoint in cluster 2, ICT1 and ICT2 specify the intercluster trunks within clusters 1 and 2, and the RSVP Agents associate with the respective end points.

In this scenario, Cisco Unified Communications Manager establishes an end-to-end RSVP connection between agentA and agentB.

Configuring End-to-End RSVP Over a SIP Trunk

RSVP configuration on a SIP trunk is determined by the SIP profile that is applied to the trunk. To enable end-to-end RSVP on a SIP trunk, configure the trunk’s SIP profile as follows:

  • From the RSVP Over SIP drop-down list, choose E2E.
  • Set the Fall back to local RSVP field to your preference.
  • From the SIP Rel1XX Options drop-down list, choose an option other than Disabled.


2 – Company X has deployed a VCS Control with a local zone and a traversal client zone. To facilitate external calls, VCS Expressway is deployed and traversal server zone is set up there. Video endpoints inside Company X have registered, but are unable to receive calls from outside endpoints. Which option could be the cause of this issue?

Which Three Devices Support the SAF Call Control Discover Protocol?



CUCM, CUBE, CME, IOS Gateway, CUCM CME are CCD SAF clients!

3 – Which two steps must you take when implementing TEHO in your environment?


4 – Which two commands verify Cisco IP Phone registration? (Choose two.) . https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/troubleshooting/guide/ts_phreg.html

For SCCP phones: Use the show ephone registered command to display the status of registered SCCP phones.

For SIP phones: Use the show voice register statistics command to display statistics associated with the registration event.  Use this command to display all the SIP endpoints currently registered with the contact address.
Router# show sip-ua status registrar

5 – A pre sales engineer is working on a quote for a major customer and must evaluate how
many Cisco VCS Expressway traversal call licenses for which to plan. Calls to and from
which three routes must the engineer include in the tally? (Choose three.)    or said another way

(When do calls on a VCS use a traversal call license?

  1. Any call where the VCS takes the media as well as the signaling is a traversal calland will use a traversal call license on that VCS. The following calls require the VCS to take the media, and are therefore traversal calls:
  • for a VCS Control, calls to or from a traversal server (i.e. firewall traversal calls)
  • for a VCS Expressway, calls to or from a traversal client (i.e. firewall traversal calls); traversal clients include other VCSs, gatekeepers, Border Controllers, or traversal-enabled endpoints
  • calls that are gatewayed (interworked) between H.323 and SIP on the local VCS
  • calls that are gatewayed (interworked) between IPv4 and IPv6 on the local VCS
  • for VCSs with Dual Network Interfaces enabled, calls that are inbound from one LAN port and outbound on the other
  • a SIP to SIP call when one of the participants is behind a NAT (unless both endpoints are using ICE for NAT traversal)

6 – What is the standard Layer 3 DSCP media packet value that should be set for Cisco
TelePresence endpoints?  (CS4/32) See Table 5-1  If the question is on Telepresense it is CS4/32 if it is a quation on Video then it is AF41/34


7 – Which two actions ensure that the call load from Cisco TelePresence Video
Communication Server to a Cisco Unified Communications Manager cluster is shared
across Unified CM nodes? (Choose two.)
https://www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/vcs/config_guide/X8-1/Cisco-VCS-Basic-Configuration-Control-with-Expressway-Deployment-Guide-X8-1.pdf  and See Table 11

8 – An engineer must resolve a call failure issue. When using RTMT, the engineer notices that
the Location Bandwidth Manager-OutOfResources counter is showing a positive value.
Which option is the cause of the call failure?

9 – An engineer is configuring URI calling within the same cluster. Which four actions must be
taken to accomplish this configuration? (Choose four.)

10 – Which two options are functionalities of subzones in  cisco vcs deployment (choose two). https://www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/vcs/admin_guide/Cisco_VCS_Administrator_Guide_X7-2.pdf


Bandwidth management

The Local Zone’s subzones are used for bandwidth management. After you have set up your subzones you can apply bandwidth limits to:

n individual calls between two endpoints within the subzone
n individual calls between an endpoint within the subzone and another endpoint outside of the subzone n the total of calls to or from endpoints within the subzone

For full details of how to create and configure subzones, and apply bandwidth limitations to subzones including the Default Subzone and Traversal Subzone, see the Bandwidth control section.

Registration, authentication and media encryption policies

In addition to bandwidth management, subzones are also used to control the VCS’s registration, authentication and media encryption policies.

Apply registration, authentication, and media encryption policies
Manage bandwidth to restrict standard definition endpoints from using more than 2 Mb of bandwidth. “Subzones are used to control the bandwidth used by various parts of your network, and to control the VCS’s registration, authentication and media encryption policies”.

11 – A voice-mail product that supports only the G.711 codec is installed in headquarters.
Which action allows branch Cisco IP phones to function with voice mail while using only the G.729 codec over the WAN link to headquarters?

Much confusion as to correct answer as some report B and others report C. The trick is in the question. The all must traverse the WAN as G.729, therefore you can not transfer at the branch. You send media to the Voice Mail at HQ as G.729 and transcode remotely at HQ. this suggests that B is the correct answer. – DrVoIP.com

12 – Which two are gatekeeper-controlled trunk options that support gatekeeper call administration control? (Choose two.) https://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/4_0_1/ccmsys/a08trnk.html#wp1098346

13 – An engineer is configuring Global Dial Plan Replication and wants to prevent the local cluster from routing the Vice President number 5555555555 to the remote cluster. Which action accomplishes this task?   Create a Block Learned pattern as outlined in this reference


14 – A PSTN call arrived at the MGCP gateway. The calling number was received as
14087071222 with number set to type international. The HQ_clng__pty_CSS contains the HQ_clng_pty__Pt partition. Which caller ID is displayed on the IP phone?


15 – Analog Voice Gateway support (See Table 1)


16 – An engineer must enable video desktop sharing between a Cisco Unified Communications Manager registered video endpoint and a Cisco VCS registered video endpoint. Which protocol must be enabled in SIP profile for VCS SIP trunk on Cisco Unified Communications Manager?


At any rate, using Dumps is a high risk.  At $300 US to take this exam, getting a “money back guarantee” on a $59 practice test is not very helpful.   I passed the on the second attempt with an 860!   I can assure you that more than 50% of the questions were NOT on any dump.  Again the only real value in these dumps is to point you in a study area.  Take every question and open a text book, or CISCO reference and make sure you really understand the subject matter.   This is NOT an easy test, but if you study, you will pass it.   Good Luck!






Configuring a SIP Trunk TIE Line between CISCO CUCM and ShoreTel iPBX

Merging Systems is fun and easy?

In a world of swirling mergers and acquisitions,  IT organizations are expected to integrate the different systems so that they all work together.   In the world of  IP PBX systems, that might result in having to make a ShoreTel system play nice with a CISCO system.  Actually, both systems support SIP and though it is sometimes more of an art than a science, it can be configured and made to work.   In fact we are seeing this request a lot lately.  Not sure why, but there are a lot of ShoreTel/CISCO integrations out there in the real world!   This video cheat sheet takes a look at a real world configuration from both the ShoreTel side and the CISCO side, so there is something for everybody who has to work with either or both systems.

Quick Topology Overview

In our example we have a CISCO Version 11 deployed in France and a ShoreTel version 14.2 CPE solution deployed in several NY locations.    This will be an interesting configuration as both systems have over lapping extension numbers.  For example, both systems have the range of 4100-4199 as extension numbers.  This along with a requirement for tail end hop off or TEHO at both ends makes for an interesting configuration puzzle.  We determined to take it a step at a time and get a basic SIP  TIE line working between the two systems.  Once that was up an operational, we could then focus on the basic dial plan strategy that would enable us to resolve the extension number conflict.

We are not going to use a session boarder controller at either end.   The good news is that it will greatly simplify the configuration as the two SIP proxies will directly exchange SIP messages.   In the case of the CISCO, the SIP trunk will originate on the call manager server itself and will terminate on a ShoreTel SG appliance (one of those orange boxes for you CISCO guys) with SIP Trunk resources sufficient for the number of channels you want to set up.    The bad news is, that on the CISCO side it makes trouble shooting a bit more time consuming.  If you had a CUBE in the mix you could easily open up CCSIP Messages in the debug on the IOS device, but when you do not have IOS you need to download logs from RTMT.  On the ShoreTel side, there is the ability to do a remote wire shark capture from the HQ server diagnostic panel using the SG appliance as the end point source.   (As a VOIP engineer SIP debugging should be second nature).

To avoid the use of a SBC on either end, we have to configure the solution entirely within a private IP topology.  In this case we have a /24 network on the ShoreTel side and a network on the CISCO side.   The WAN connection is an MPLS network.

ShoreTel and CISCO dial plan strategies

CISCO does not really care about over lapping extension numbers of difference in extension number ranges.  When I say, they don’t care, I mean they have a strategy for dealing with it.   You might have a multi-site deployment as a result of a recent acquisition and you have four digit extension numbers at one site, and five digit extension numbers at a different site.  CISCO can deal with this.  ShoreTel not so much.   With ShoreTel you would have to convert the four digit site to five digits (you can expand from four to five digits,  but not five to four) if you are going to have one dial plan.  In CISCO you could actually let both sites coexist with different extension number lengths.

CISCO has a verbose dial plan strategy that expects you to create route “patterns” that when matched by dialed digits, point to a gateway or route list that contains a destination reachable by that route pattern.  In our example, we set up a dial pattern of 51.xxxx with a pre-dot discard that points to the SIP trunk TIE Line over to the ShoreTel.   The SIP Trunk configuration is relatively simple and is shown in the video below.

ShoreTel requires you to configure a Trunk Group and then put your individual trunks into the group.  These individual trunks are basically SIP channels and the video also shows this configuration.  The difference in the strategy of both systems is interesting to note.   CISCO is routing to this trunk group based on a route patter that matches dialed digits.  ShoreTel is going to want you to define both an access code and list out the OPX (off premise extension) numbers that this trunk can reach.

From a digits dialed perspective, ShoreTel is going to match the dialed digits against the list of OPX extensions to route calls over the Trunk Group that contains a matching OPX list.   Note that no access code will be required, though it will be required in the Trunk Group configuration.

SIP Trunk Group Profiles

Both systems required a reference to a SIP Profile that defines specifics of the call setup messaging.    Sometimes this is a bit more of an art than a science and it may take a bit of tweaking.   CISCO has a standard SIP Profile and an associated SIP Security profile both of which will be referenced in the SIP trunk configuration.  The only change I typically make to the SIP Profile on CISCO is to activate the “enable PING option” so that I can keep track of my trunk status which would otherwise be “unknown”.

I made all my SIP Profile changes on the ShoreTel Trunk side.   This is the  list of configuration options we applied and it was the result of trying and retrying, so this list alone should be worth the blog read as it most definitely works in our example:


If you have never configured a ShoreTel SIP Profile, the video walks you though this in detail.  ShoreTel provides a “standard tie-line” sip profile and suggests that you use it.  In fact if you change it, they generate a strong message urging you not to do so, but change it we did to the settings above and we had a more than acceptable result.

Extension conflict resolution

ShoreTel trunks do not out of the box allow abbreviated dialing.  The Standard ShoreTel domestic dial plan really wants what amounts to an E164 format.   ShoreTel will take all digits dialed and attempt to construct a +1 NPA – NXX – XXXX dial string.   So in this example, we are not going to be able to dial 51 as an access code on the ShoreTel side, then output only four digits.  Not going to work.    As outlined above, ShoreTel will want you to define the OPX extension reachable by the encapsulating trunk group in a detailed list as part.   The good news is that this means that you only have to dial the distant extension number and ShoreTel will see it as an OPX and route it over the associated trunk.

Clearly this means these extensions are unique.   What are we going to do? We have extensions on both sides of the TIE Line that are not unique, they are the same 41xx.   ShoreTel will allow you to create translation table to over come this limitation.   We could create a range of 61xx for our OPX list and then convert it to 41xx in the translation table and that would eliminate our problem.  Not my favorite solution but it may be the one we have to go with.   The down side is that we have no eliminated the 61xx range for use on the ShoreTel side.   Additionally, it is not very friendly to directory systems as people have to remember that if you are calling 4304 in France from New York, you need to dial 6304 not 4304 another colleague in NY!

Ideally we want to make use of that access code.  It would be nice to dial 51 + XXXX and be done with it, but as previously explained ShoreTel does not easily support that option.   It may be possible to write a custom dial plan and apply it to this specific trunk group.   For example, when working with paging adapters that have zones, you want to dial the paging amplifier and then dial your zone.   The custom dial plan for this would by “;1I” but you would still have to dial an OPX number.   For example, you would create the trunk group and maybe put 1234 as the OPX which would route the caller to the paging adapter.  The custom dial plan rule would be interpreted by ShoreTel as “do not echo any digits” enabling the paging adapter to play a second dial tone, and then you could touch tone out some digits.   Sounds like this would be a good solution but you would end up dialing eight digits, but it would free up a range of extensions that might otherwise be eaten alive by the required translation table.

ShoreTel Update

At the end of the day, the solution was to create a custom dial rule and apply it to the ShoreTel Trunk Group.  Users inside the ShoreTel would dial 50+xxxx but as a result of the custom dial rule, the ShoreTel would see 999-555-xxxx and only pass the xxxx.   Remember that ShoreTel wants you to list the extension numbers on the other side of the TIE line in the OPX list of the Trunk Group.  In a situation in which you have extension conflict you can use a translation table, but often that is not the most friendly solution.  Ideally you will want to dial and access code, get connected to the distant phone system and then out dial the extension digits regardless of extension conflict.   To do this on a ShoreTel system will require a custom dial plan modification to the trunk group.  The document on this subject is very limited so you either have to pay ShoreTel  Professional Services or be prepared to play detective.  We went the detective route, so hit us up for the solution.








An IP Blue soft-phone tool kit for serious CISCO voice engineers!

The trials of a Call Center Engineer!

As a consulting engineers, we spend a lot of time working remotely over a VPN connection!  Testing configurations, features and CSS access requires end points!  Typically more than one end point device!   Scripting for the call center applications is even more demanding as you need to be able to test call flows.  Now a VPN over CISCO Anyconnect that allows you to work long hours remote is always nice, is not the same as a point to point VPN.  You might get one IP Communicator up on your local machine, but it is often not practical to register multiple devices.  When testing a UCCX scripts you need multiple Agent and Supervisor Phones to really ring out (pun intended) your call flow.  How best to do this?

Enter IP Blue!

I was taking a CISCO certification class and noticed that the instructor somehow managed to get multiple IP communicators up on his desktop.  I immediately realized the value this would have for UCCX scripting in particular and CISCO CUCM work in general.  I did a bit of research and found a company named IP BLUE Software Solutions, the industry’s best kept secret!  They make some really innovative products, but the one that I now can not live without is the “VTGO-PC Multilab Softphone” a product without equal and one that is a must have for every serious CISCO VoIP Engineer.   With this product I can open some 5-8 7960 type CISCO phones on my desktop, all registered to call manager with individual extension numbers and separate sound interfaces (i.e. speakerphones).   I used to have one IP Communicator and one X-lite SIP phone open on my desk and that was the best I was able to do remotely.  Now I can open an entire call center on my desk!  Astonishing!


Softphone Feature Set

These softphones are fully featured CISCO 79XX models ranging from the 7960 through the 7975 and are completely configurable.   When working with multiple clients I can setup a phone for each system I remote into!  I can even right client on the Instance name and change it to a client name for future reference and quick setup when working on multiple simultaneous deployments! When working on a Call Center I can bring up a few agents, a supervisor and exercise the script for all the possible scenarios.  All on a single desktop!

The feature set includes some really nice, not CISCO features, like an answering machine function!  Very Powerful! Multiple softphone instances can run on a single PC, connecting to the same or different Call Managers.  Each softphone instance is independent from another, and can call any phone including other softphone instances.  This setup allows to easily simulate various call scenarios, verify Call Manager settings, troubleshoot VoIP issues and configure Call Center Scripts results!   If you are running a  lab while preparing for some certification exam, this tool is going to not only save space and electricity, but lower the overall air conditioning requirements!  Here are some of the other features:

  • Emulates Cisco 79xx line of IP phones with dual 14 button expansion modules
  • Tested and certified with CallManagers 3.2-4.1, CallManager Express
  • Supports Cisco Survival Remote Site Telephony, redundant CallManagers, DHCP option 150
  • High quality-low latency using multiple codecs (G.711, GSM 6.10, G.729), QoS support
  • Accessibility features for visually impaired users include text to speech and keyboard shortcuts
  • Supports Extension Mobility
  • XML telephony services
  • Configuration Wizard with user-definable profiles
  • Supports a wide range of external USB audio devices
  • STUN/UPnP NAT traversal, SKINNY fix-up protocol friendly
  • Call log with Callback
  • Call recording, storage and playback with email attachment
  • Integration with LDAP directories, MS Outlook, Windows Address Book, Instant Messengers (Microsoft, Yahoo, AOL)
  • Language Localization (English, Dutch, Danish)
  • Dialing from MS Outlook, Web pages and much more

This is the best kept secret in the industry and if you are a serious student or working engineer doing anything with the CISCO Collaboration suite, you need to own this software.  If you boss will not spend less than hourly rate he bills you out at, get it yourself!  The time you implementation and troubleshooting time you will save, will more than pay for itself in increase leisure and family time!    We rarely pitch products on this site, but this product was just so astonishing we had to share it with our readers!



CUBE SIP Header Matching – Extracting DNIS from a Toll Free Number!

The Problem – Call Forwarding DNIS to Toll Free Numbers

Recently we were presented with a new challenge while deploying a Call Center based on the CISCO UCCX Version 11.5 feature set. Generally, we employ DNIS as a strategy for defining the CSQ  service parameters.   The more specific you can make the inbound number, the less you will need to “prompt and collect” digits from your caller.   A call to a specific DNIS number can separate the English callers from the other language options, or route “customer service” differently than routing “technical support”.   DNIS is always a preferred routing strategy.    Using DNIS we can design a single call routing script that can  pull in the CSQ name; offer up the proper audio menu’s; provide unique queue handling options and customize the caller experience all based on the dialed number.

In this centralized scheduling application for a large national medical practice, patients would call a local number in their community.   This number was then forwarded by the carrier to a toll free number that rang into the centralized CISCO cluster and UCCX call center.   The issue was setting up the dial peers to address the number the caller dialed, not the toll free number.   These numbers terminated on a SIP trunk that was serviced by a CISCO CUBE and the number presented was the 10 digits of the toll free number.   The DNIS number, or the number that the caller originally dialed may or may not be buried in the TO field of the incoming SIP headers.

Solution – Step 1 Debug Captures of inbound SIP messages

We need to setup “debug ccsip messages” and “debug voice ccapi inout” and make some test calls.   We need to understand how the carrier is handling the forwarded number.    In the log output below we can see the INVITE is the 877 toll free number.   The number that the caller dialed is the 9323646969 number and we can see that it is in the TO filed of the sip message headers.   We will need to write a dial-peer,voice class uri,  translation rule and profile that extracts the TO field and routes on that number rather than the original INVITE.   It is the “voice class uri” that is most magical in this solution.   (Note that we got luck here and the carrier was handling the call forwarded number in a manner that was appropriate to our goals.   This however is not always the case)!


Solution Step 2 “Voice Class URI”

In this example, the caller is dialing 93236453XX which is being call forwarded to the  toll free 877 number and shows up in the sip headers in the TO field.   The solution here is to create a “voice class uri”  rule.  In the snippet below we can see “voice class uri 102 sip” with a “user-id of 9323645323” as an example.   We are going to ultimately want to translate this to a four digit extension number 5323 and this is done with the traditional translation rules.  In this example “voice translation rule 102” does this conversion.  Note however that the translation rule refers to a match on the 877 toll free number, not the  9323645323 number.  This is where the magic of  “voice class uri”, the ability to do dial-peer matching based on the uri.

The Voice Class uri is structured such that it has a unique TAG and then a matching expression or host IP address.   The the snippet below we can see two attemtps to setup up a uri filter based on the last digits in the TO field of the SIP header.  Tag 102 looks to match 5323 and tag 103 looks to match 5324:

Solution Step 3 Dial Peer Matching

The call flow is dictated by dial-peer matching.   From the following snippet:

dial-peer voice 103 voip
translation-profile incoming 5324
session protocol sipv2
incoming uri to 103
voice-class codec 1
voice-class sip bind control source-interface GigabitEthernet0/0/0
voice-class sip bind media source-interface GigabitEthernet0/0/0
dtmf-relay rtp-nte
no vad


dial-peer voice 102 voip
description Incoming – FAX DID
translation-profile incoming 5323
session protocol sipv2
incoming uri to 102
voice-class codec 1
voice-class sip bind control source-interface GigabitEthernet0/0/0
voice-class sip bind media source-interface GigabitEthernet0/0/0
dtmf-relay rtp-nte
no vad

We can see that the voice class reference is applied to the dial-peer much the way a voice translation-profile is applied with the expression “incoming uri to 102” which sets up a filter to match for the number  9323645323.  Note that the dial peer matches the voice class but it is the translation-profile incoming 5223 that changes the ten digit number of the URI to the desired four digit extension.  In fact if you study the voice-translation rule 102 rule 1, references the toll free number!

These tools, the voice-translation rule and the voice-class uri work together to enable us to route and match dial-peers on information in the uri and not necessarily the original INVITE sip: number! Way powerful!



TOP ShoreTel Connect Installation Gotcha’s !

So you are upgrading to ShoreTel Connect!  Watch out for these blistering hot spots:

Assume you have a call center that works three shifts, with 15 Agents per shift.  In the Pre-Connect world, you would define 45 agents but you would only need licenses for 15.  The Pre-Connect ECC license strategy was “concurrent users”.  The new license strategy requires you to license 45 Agents.  Additionally, all agents have to be named in the iPBX, costing you an additional “per seat” license for the newly named agents.  Before, 45 agents could log into extensions Agent1 through Agent15 using their AgentID to differentiate them for reporting purposes.   Wow!  I hope you don’t find this out the hard way.

Here are some of our favorite ShoreTel Gotcha’s:

1 – Ever have to move route points from one server to another?   You CAN NOT use the batch utility to do this and must remove and then reinstall each route point.   So much fun on a large contact center deployment ( If you know SQL you can actually modify the configuration database to do this).

2 – Want to change IP address of your HQ?   If you are using the new family of 400 phones, you will have to touch each phone individually and manually CLEAR the Configuration for the new Option 156 and DHCP values to take hold.  How would you like to upgrade 3K phones across five times zones to learn that gem!

3 – Gee, would it not be nice to use DNS Name resolution in the Phone Setup?  You could just change the IP address in DNS and update your entire deployment!

4 – Is it no time to get rid of the DB9 Serial IO cable for switch configuration?  It is the 21st century and we sill do not have USB on ShoreTel switches?  When was the last time you had a serial printer cable with an DB9 connector hanging around your tool bag?

5 – Setting up OBDC connectors still use 32-bit connector and do NOT support AD login.   If you are connecting to Microsoft SQL, for example, if you use an AD credential your ECC Script will fail.

6 – Active Directory  integration is a one way sync out of the box.   Even adding the ShoreTel professional Service add on for AD will not solve all your issues!

7 – ECC Shifts will destroy you if you do not fully understand their use and impact.   Create a Shift to close on of your Customer Service Queues at 1PM and end up closing your entire call center!  (See this Blog entry).

8- You can not enter anything in the External number field for transfer a call but  9+1+NPA- NXX-XXXX.  No 9+011-44-204-668-5000 for example.  It will not work! Not for a call handling mode, CTI route point, External Assignment.  Nada. no bueno, NFG!

Useful and Helpful Event Log error entries!  Our Personal favorite:


Send us your favorite Installation and Maintenance Gotcha’s and we will update the list and credit you for the contribution!




Build ShoreTel Connect inside your own private Cloud using AWS!

Placing your ShoreTel HQ in the “cloud”?

Moving the ShoreTel HQ server to a data center to increase system resiliency, reduce or eliminate down time and increasing overall recovery times has always been high on the check list for business continuity and disaster preparedness.    Our preferred “data center” however is Amazon Web Services, or AWS for short!   We have been deploying ShoreTel in AWS as a “private” cloud solution for some time and have several blogs on the subject.

Do you already have an Amazon Account?

If  you have a regular old Amazon book buying account, you already have all you need to log into AWS and get started building out your own virtual private cloud!    Though there is a lot to learn,  in less than 15 minutes you can spin up a Windows 2012 Server in a virtual private network and then link it back to your onsite location with an AWS provided VPN Gateway!

The simplest ShoreTel/AWS deployment model

The simplest of VoIP deployment models is the placement of the ShoreTel Connect Server in an AWS Region and availability zone of your choice.    Typically, we defined a private subnet in three different AWS availability zones and then launched a ShoreTel Connect server.    The availability zones provide additional resiliency  options.  It is even possible to setup an Elastic load balancer than can move from one ShoreTel HQ server to a standby duplicate in another availability zone in the very unlikely situation of a AWS availability zone going off line!

You can interconnect your ShoreTel Connect VPC  with your remote sites over a VPN, ultimately moving to a “direct connect” circuit and only using the VPN for backup.   The remote sites will have ShoreGear resources to support localized carrier access and onsite user phone services.   The distributed nature of the ShoreTel architecture makes this a natural deployment model.   This is  by far the simplest of the deployment options and one that everyone who is considering moving a ShoreTel HQ server to a data center should consider.

Even Ingate in the Cloud?

With ShoreTel Version 14, virtual switch resources make it possible to create the entire deployment in your VPC.  You can even deploy your Ingate as a virtual Session Border Controller, in the AWS cloud and centralize your SIP carrier access.    This is a bit more demanding then spinning up a Windows server but now that AWS enables you to import vmware machines, it is an exciting option.

Importing vmware based ShoreTel machines

The secret to deploying ShoreTel vSwitches in the AWS cloud is to first build the machines as vmware machines in your local environment with an IP that can be duplicated in your private virtual network.   Once your machines are created, you can then import them into AWS.

The options for deploying VOIP in your own “private cloud” have never been more flexible.   Your CFO is going to be impressed when comparing AWS to the cost of building out your own data center or renting space in a collocation facility.   You have all of the benefits and none of the cost associated with a typical infrastructure build out.    Connection options are unlimited and you can access AWS facilities on a global bases!

The Video clip demonstrates a ShoreTel HQ and ECC Server in an AWS VPC, with a VPN back to the main office site.   The office site contains ShoreGear switches for SIP trunk access and 400 series phone support.  There is a synergy when integrating AWS and ShoreTel that every CIO should be seriously considering.    Give us a call and we can help make this happen for your company!


Compare CISCO and ShoreTel “dial plans” and “calling priviledges”!

What is a route or dial plan?

Most if not all phone systems provide for route plans and calling or “class of service” privileges.   The dial plan defines the over all numbering system used through out the system.  For example, how many digits do we need to define all of our extension number or telephone endpoints?  What access code do we use to indicate we want an outside line?  What numbers will we set aside for system features like the automated attendant, voice mail, contact center and conference servers?   Generally this is one of the first decisions you make when designing a new phone system.   Once set, it is usually very cumbersome to alter or refine.

Calling privileges or “class of service” defines what facilities a specific user might have access to.   For example, we might want the Lobby and Kitchen phones to be able to dial 911 and make internal calls, but we might restrict them from dialing outside numbers at all, let alone long distance or international phone calls.   Some systems even restrict internal extensions from calling other internal extension numbers.  For example you might isolate the CEO from being dialed by the automated attendant “dial by name” directory and you certainly do not want the over head paging system accessible by an outside caller!

How do we include a new branch with the same internal Extension numbers?

These options become increasingly more complex as organizations redefine themselves as a result of a merger or acquisition.   How do you add that new branch office into the company phone system?  Things become even more exciting when the new office has a “dial plan” that uses the same internal extension numbers already in use by the HQ phone system.   ShoreTel and CISCO tackle this in very different ways and it is interesting to note the different strategies.

In ShoreTel you define you “dial plan” as the necessary first step in designing the phone system.  How many digits do we need to dial internal telephone numbers?  Out of the box, ShoreTel assumes you want to use three digit extension numbers.   You can change them to four, five or more digits but you can only do this once.  You can increase extension digit length but you can not reduce them, so plan carefully!  The next issue is what range will we use for extension numbers?  Will they start with 1, 2 or some other digit?  Don’t forget those “system extensions” as you will need them for many features and system resources.

ShoreTel also uses the concept of a User Group and a Class of Service.   A user group might be a function like Executive,  Manager, Employee and House phones.   The Class of service defines Telephone Features, Calling privileges and Mailbox options.   Telephone features might include who can access the Intercom, or record their own phone calls.   Calling privileges enable internal, local and long distance dialing options.  Finally mail box options indicate the size of messages, greetings and administrative controls.

ShoreTel has a very simple to implement and understand concept for dialing plans and calling privileges.  With simplicity, however, comes some restrictions.   Lets take the example of acquiring a new business unit and they have an existing dial plan that conflicts with the one already in place.   Well, you could through the inplace  phone system out and install ShoreTel at that location (certainly the ShoreTel re-sellers plan) by expanding the existing ShoreTel but that would certainly mean an change in extension numbers at the newly acquired business unit.  Optionally, you could install another ShoreTel system and integrate the two separate system through a SIP  tie-trunk.  Using a digit translation strategy you could let the other guys keep there old extension numbers but you would have two separate telephone systems, each with their own configuration database.   (In CISCO parlance that would be a two “cluster” solution).

ShoreTel Simple or CISCO Complex?

CISCO uses the concept of “route patterns” to define a dial plan.   It is a bit more complex, but with that complexity comes great flexibility.   A “route pattern” is a map for taking the digits a user dials and searching a database to find the route those digits should follow to complete the call.  For example, a user in the California Office might dial 9,1-212-523-51234 to reach extension 234 in the New York office.  The route pattern would then hit route list that might include a local PRI for a long distance call to NY, dropping the 9 and out dialing the E164 1+area code and number.  That route list might also include a WAN gateway that directly terminates in NY and in that case, drops all the digits but the 234 while placing the call over the company’s WAN connection.

To be fair, ShoreTel can also complete a call over the WAN and would be smart enough to know that #234 also has a DID number of 212-523-51234.  If the California user dialed #234, and the call could not be routed over the WAN, the call would be completed over the Long distance line using “PSTN fail over”.  The feature does not, however work the other way.  Had the user dialed the LD number and encountered  a network busy condition, it could not then route the call over the WAN.

As to”class of service”, CISCO uses the concept of a “partition” and a “calling search space” (i.e. CSS).   Though some folks like the “lock and key” metaphor,  we think the best way to understand this is to realize that “partitions” define who can call me.   “Calling Search Spaces” define who I can call.    So if my line or phone is in a CSS that specifies partitions NYPhones, SFPhones, UKPhones, Windstream, COX and Verizon, then those are the objects I can call.    If my device is in a partition named SFPhones and your CSS does not contain that Partition, then you can not call me.

Sounds a bit confusing, and at times it is.   The structure however enables us to build some very  significant solutions.  Take that example in which you have phones with the same extension number in two different business units in the same “cluster” or phone system.   You could put Extension 1234 in the NYPhones partition and in the SFPhones partition!   They would not conflict with each other!  Every phone, feature (i.e. intercom, conference), line in a CISCO deployment is in a specific “partition” and only reachable by an entity that has a Calling Search Space that includes that partition.  Simple!

Given that we are not in the business of selling phone system, only engineering and supporting them, We do not  have an emotional attachment to one over the other.  We observe that ShoreTel is best suited for smaller deployments and in fact can be easily deployed and managed by a small business of 25 or more.   Though there are larger ShoreTel deployments, we see them in the 100 – 1000 user line size most frequently.  CISCO has a low end Solutions, the Business Edition 6K-S for system under 150 users,  but the CISCO Collaboration solution could run a small a small country though the Business Edition 6K and 7K are optimized for 100 – 5000 users!

The video shows the two different approaches to solving these common route plan issues!







Use an Ingate SIParator and you are “virtually there”!

We have written on the subject of SBC quite extensively in the past and have also covered the easy installation of the Ingate product (see DrVoIP here).   Readers must find this interesting because the hit counter for our Ingate videos continues to grow, indicating engineers are eager to learn more about this product.   We generally regard ourselves as CISCO brats, but when it comes to Session Border Controllers, we remain deeply impressed with both the Ingate product and, most importantly, the Ingate support team!  Pre-sales support is typically as good as it gets when developing a relationship with a vendor.  Post sales support, however, is where the true value system of a company is tested and Ingate passes with high marks.

Ingate SIParator as a virtualized appliance

Ingate, began shipping product as early as 2001 and has its roots in firewall security products.  Ingate has now made its very popular SIParator Session Border controller available as a virtual software appliance.  The SIParator E-SBC, scalable from 5 -20K sessions can be obtained as either a hardware appliance or as a software package.  There are over 10K SIParators installed and working worldwide, making Ingate the “go to” knowledge base for documented SIP deployment experiences that is without equal on a global basis!   Those of you working with ShoreTel have already discovered how powerful a vmware ESXi deployment can be.   New options for fail safe, high availability and increased reliability magically appear when you virtualize your deployment!   Ingate is no different and the availability of the Ingrate SIParator as a virtualized appliance adds a significant level of both reliability and flexibility to your ShoreTel deployment.

The most widely asked question in the DrVoIP technical support forum:  “Is there a need for a Session Border Controller?”   Why can’t we just use our firewall is a common theme.  Though it is possible to use a firewall to do a SIP trunk implementation, it is not our best practice recommendation to use a firewall in that way.  Even firewalls with AGL SIP functionality fall short of the wide rage of features needed for true SIP arbitration.   We are firm believers that firewalls already have enough work to do and are being attacked even more ferociously every day by a wider group of hackers and evil doers than ever before.   If you are committed to using a “firewall” to do SIP deployments, then we urge you to consider at least using an Ingate SIParator Firewall as a best of breed solution!

A dedicated Session Boarder Controller

Session Border Controllers have a lot of work to do!  The concept of normalization alone could fill a text book.  The fact is,  not all SIP implementations are equal.It is often necessary to swap SIP message headers to achieve the desired results!   Try getting your firewall, unless it is a SIParator, to do a SIP message header translation and you will quickly understand why a dedicated Session Boarder Controller makes sense!


The software SIParator is easy to obtain, easy to install, easy to configure, and easy  to license.  Ingate has adopted a pay as you go philosophy, and though the software product scales from 5-2000 channels, you only pay for what you use!  In fact, Ingate is so confident in the adoption rate of its product over competitors,  they offer a 30 day free trial.  Just click here to take advantage of this outstanding offer.

The video is Part one of a two part video on the product!   Part one shows how to obtain, download, and install the virtual SIParator software package.  Part two goes through the configuration of the SIParator on a ShoreTel system for use in SIP trunking deployments.  This material was previously covered in our YouTube video on Ingate and that material is still relevant!

Kudos for Ingate

Lastly, we want to commend Ingate not for having a great product,  but for the quality of the support they offer the entire industry by an ongoing commitment toward the education of the market place on SIP and, now WebRTC technology.   We are not talking about thinly masqueraded advertising, but serious SIP education programs for serious technology students, and a demonstrated sincere desire to advance the state of the art!  They offer an endless variety of webinars,  seminars, ebooks and even work in partnership with the SIP school to further develop and educate industry stake holders.    Excellent work  Ingate and well done! – DrVoIP


V14 Configuring ShoreTel SIP Trunks P2 -SonicWall or InGate SBC?

A question that keeps coming up in the support ticket system is the subject of InGate and Session Border Controllers.  Folks want to know if you need a SBC to configure a SIP trunk.  Why not just use a Firewall?  Can you configure ShoreTel SIP trunks to work without a SBC?  The simple answer is “yes” but the smart answer is “no”.  In our humble opinion, just because you can do it, does not mean you should do it!   Session Border controllers, like those offered by Intuit for ShoreTel,  provide functionality not normally found on a firewall.   “Normalization” for example, the ability to mediate ShoreTel SIP and your carrier’s  SIP, as they most likely speak a different “dialect” of the common language SIP, is not a standard firewall feature.

Application Level Gateways, sometimes take actions that are injurious to SIP messages.  Remember, SIP was not designed for NAT based networks.   Something has to keep track of which internal private trusted network users made a SIP request for service to another IP address across an untrusted boundary!  Which RTP (voice, video or “media”) ports need to be opened to support this request?  SBC can do this more effectively than firewalls. At the end of the day, you end up turning off the SIP ALG functions in your firewall to make it work! (In SonicWall turn off  “consistent NAT” and “SIP transformations”.)

We have never recommended bringing your SIP services into your VoIP deployment over the same circuit as your Internet circuit, but so be it.   At least, let’s use a separate IP address and make use of the DMZ port on your firewall, if you are not going to use a separate circuit!  Let us try to keep the SIP traffic from undergoing the same port specific inspections you put the Internet traffic on!  Again our best practice recommendation for ShoreTel, if you are serious about SIP trunks as the main Communications link for your company, is get an Intuit SBC and bring your service in on a separate circuit or IP!

SonicWall has for sometime, had a number of “service objects” to support the ShoreTel MGCP phones.  In fact, before SIP was enabled on ShoreTel, all media flowed on port 5004 which was really great for enabling transport level QoS!   Though there is a steady trend to use TLS and get both SIP messages and RTP over a single port, most SIP carriers expect to send messages on UDP 5060.   So if you are using a SonicWall, you will need to create new Service Objects, and put them in new Service Groups to get SIP to work.   You will need to configure Network Objects for your ShoreTel SIP proxy and configure access rules.  We recommend you also create a network object for your ITSP rather than enabling  an open 5060 for all the script kiddies running SipVicious!

We will do this again on a  CISCO ASA 5505 just for giggles as we get a lot of requests for that as well!  At the end of the day, however, for a serious business application of SIP trunks on ShoreTel, get a separate circuit and invest in an Ingate SBC!  Heck, you can even get a virtualized version of InGate!