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 10.0.0.0 /24 network on the ShoreTel side and a 192.168.53.0/24 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: OptionsPing=1 OptionsPeriod=60 StripVideoCodec=1 DontFwdRefer=1 SendMacIn911CallSetup=1 HistoryInfo=diversion EnableP-AssertedIdentity=1 AddG729AnnexB_NO=1 Hairpin=1 Register=0 RegisterUser=BTN RegisterExpiration=3600 CustomRules=0 OverwriteFromUser=0 1CodecAnswer=1 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.