WTF is Ngrok?

Ngrok better than sliced bread!

As a software engineer developing telecom based web applications, testing and validating software can be a major time sync.  How do you get your lab system on the Internet, accessible with a public IP, so you can test a Webhook or REST API for example?   What if you are working behind a router that has a dynamic IP address?   Reconfiguring your firewall for each test of the new code is a pain!  There has to be an easy way to enable testing without going through 20 acts of vaudeville to test your application code!
We recently discovered two tools that are now essential elements of our software engineering toolkit!   Ngrok is very creative service that solves many problems for testing network-based applications during the pre-deployment, development process.  Ngrok is a software service developed by Alan Shreve, clearly a genius,  who often goes by the name “Inconshreveable”!  In its simplest form, Ngrok is a solution that enables you to expose your lab web server which is normally installed behind a NAT or firewall, and connect with it over the Internet.   Ngrok makes it easy to set up a secure outbound SSL tunnel that can be reached by a hyperlink to a public IP.

Secure tunnels on Demand!

Ngrok is a powerful tool and Alan Shreve is an extraordinary personality!   He makes this available for free use!  No credit card required!   Just open an account here and give this a try!   Then download Ngrok to your local Windows, MAC O/S or Linux development platform, unzip it and run it with a very simple configuration command.   You might enter  “Ngrok http 80” into your terminal window to indicate that you have a web server listening on port 80 on your local machine.

Ngrok then displays a DNS link that you can point at to access and test your application.   Now you can demo without deploying, simplify mobile device testing, build webhook integrations or run personal cloud services from your own private network!   For a modest monthly fee, you can change the random number Ngrok generates for your unique link to a reserved domain name.  So https://92832de0.ngrok.io can become https://yourcompanyname.ngrok.io which will not change and is easy for you to deal with!  The free account generates a random number that will change each time you run Ngrok.   Using a reserved domain also makes webhooks a lot easier.  For example, when developing Twilio applications you would have to change your webhook every time you ran Ngrok.  The paid version enables a reserved domain name that you can now use to stabilize your Twilio webhook!

You can also build secure tunnels that are password protected and able to support multiple simultaneous connections.  Open http://localhost:404o on the platform running your Ngrok client and you can inspect and replay traffic:

We now regularly use Ngrok not only for development testing but also for remote support applications so we don’t have to worry about VPN credentials!    You can create TCP tunnels as easy as you set up HTTP tunnels!  This resource will save you more than enough time to pay the annual fee of $60 for a basic account (1 online process, 3 reserved domain names and eight tunnels per process).     Alan is online from time to time and otherwise provides a link to ask questions!   (Learn about Alan’s other projects here)!  No serious developer, network engineer or remote support technician can afford to be without this power utility! – DrVoIP
(As a product of the 60’s you might note that Grok was first used in “stranger in a strange land”, a SiFi novel.  Profound effect on most of the 60’s generation).

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