Time2Market's Cloud Complete Unified Communications as a Service (UCaaS)

First off... this blog post is going to come across as a sales pitch and that is because it is. I'm not going to insult your intelligence... but there is a lot of confusion out there as to what is offered with various different Unified Communications as a Service (UCaaS) solutions and where they can fit into an organizations plan to further their communications. I'm not going to go into detail about all the other offerings out there, but what I'm going to do is offer you detail about Time2Market's Cloud Complete offering. We also offer a Cloud Custom option, that adds some additional functionality, but this blog post will focus on the Cloud Complete offering.

Anyone who knows me... knows that I'm not a fan of the "cloud". The reason is because I think it is one of those terms that gets thrown around and decisions made without really understanding the implications of turning over control to the cloud. I'm not saying that it doesn't make sense 100 percent of the time... because it actually does in a lot of scenarios.  I just don't like the blind run toward the cloud that I see a lot of people doing just because all the cool kids are doing it.

Having said that, Time2Market's Cloud Complete offering is a hosted UCaaS that is a Multi-tenant... Enterprise Voice... Skype for Business environment.

Yup.. you read that right... Skype for Business.

Time2Market's cloud is not based on the now defunct Lync Hosting Pack that was limited to the same feature set and Lync Online.

The is a Skype for Business hosted environment with feature sets that to my knowledge are currently not offered anywhere else. Those feature sets even include the new Broadcast Meeting offering that depends on a hybrid implementation with Office365. We even leverage Exchange Unified Messaging in Office365.

Now why would an organization want to do this. It is simple... instead of investing in all the equipment, server licenses and professional services to implement an on-premises solution that has costs as a capital expenditure. This allows an organization to move these costs to the operational expenditure column. The Cloud Complete offering scales and shrinks as you do and is a totally managed service from deployment to support. In short, you focus on your business, not running a Unified Communications infrastructure.

So what are some of the things that Time2Market offers in its Cloud Complete that make it unique...

• E-Faxing Services
• Advanced Call Routing Options
• DID Parking
• Common Area Phones
• Standalone Fax Services
• Unlimited Calling Plans
• Auto Attendant
• Dedicated Conference Bridge
• Room Systems and Video Integration
• Conference Room Audio Devices
• 800# Support
• Paging Applications
• Contact Center (Clarity)

But here is the really big key to Time2Market's offering, we have a whole organization that will help you every step along the way with a White Glove Service. Cloud Complete isn't a self service type of offering, instead it is an offering where you have a whole team of people who have been in the business of helping organizations communicate for decades. Here are some of the things we can help you with...

• Office365 Tenant Setup/Mail Migration
• Unified Messaging Setup
• IP Phone Setup
• On-Premises Active Directory Integration
• Auto Attendant Configuration
• Room System Installation
• Device Consultation

But wait.... there's more!! Sorry couldn't resist saying that.

But really there is more... Time2Market has created a Self Service web based portal that gives easy access to the following tasks...

• Password Reset
• Add New Users
• Assign DIDs
• Modify/Update Conferencing and Global Dialing Policies
• Update Federation Policies
• Get Support
• Access to Usage Reports and Billing Info
• Access to training, tips and tricks

What are you waiting for? Interested in Time2Market's Cloud Complete offering or have further questions? You can contact me by SIP or email using jonathan at t2mdev dot com or by calling 303 997 2100.

Change in route selection behavior in Lync Server 2013 from Lync Server 2010

I was recently working on a rather complicated dial plan and ran into a situation where the route I expected to be followed wasn't being followed. What I was trying to do was create a single Voice Usage that would route for specific numbers and then have a catch all route that would be the route as a last resort.

After doing numerous tests and doing an Outbound Routing debug it was clear that the route wasn't being skipped and it wasn't being marked down. The catch all route was being tried first even though the order of the routes in the Voice Usage had it at the bottom.

Interestingly, if I simplified the regular expression of the route that matched a range of specific numbers to just be one of those numbers, it magically started to work correctly. As soon as I modified it back to the larger range, it would fail.

Knowing that I have done this many times before, I was convinced somehow I hit some sort of bug. So a case with Microsoft was opened. After some lengthy testing, the Microsoft support engineer was just as baffled as I was and was coming to the same conclusion I did.

As a work around, until the Microsoft engineer decided how to proceed, we created two different Voice Usages. The first one was for ranges of numbers and the second usage contained the catch all route all by itself. The routing worked as expected, but this was not ideal, because this would increase the number of Voice Usages across the hundreds of sites in this deployment. I was aiming for the simplest dial plan possible since it was already complex.

Anyway, after a few days the Microsoft engineer got back to us and dropped a huge bomb.

Believe it or not, this was working as designed. He informed me that there was a change in Lync Server 2013 in how it processes routes in a Voice Usage. Lync Server 2013 now chooses the least complex regular expression before it processes the other routes. The reason for this change I don't agree with, but apparently there were some customers that had really large dial plans, where processing a large list of routes in a Voice Usage was taking too long and this change was decided to speed up processing the list.

So... if you have similarly complex in the same usage, the order of the routes matters. But if you mix complex and simple rules in the same Voice Usage, then the more simple rules will always be followed first.

I hate this because now everyone else is forced to create more Voice Usages, sometimes with a single route in them, to have the routing work as desired. The other item that bugs me is that there is next to no documentation of this change and this was not communicated to the technical community in any other way that I'm aware of. This is a big change for a product that a lot of people depend on to be consistent.

I think a better alternative would have been to give the engineer an option to process the routes within a Voice Usage using the Lync Server 2010 method or to switch to the new Lync Server 2013 method. I can see merits to both methods, but ideally I would like a choice.

Now... If you are like I am, you want to know what exactly constitutes a simple rule vs complex rule. Unfortunately I can't tell you exactly. All I can share with you is a somewhat vague answer that I got back.

The algorithm has quite a bit of complexity – in simple terms, the route that has simpler “prefix” will be preferred over more complex ones. The “prefix” is a combination of characters, character escapes, alterations and substitutions (as defined in regular expressions).

So if anyone has more detail on this algorithm, I'd like to have it. But in the mean time it doesn't really matter because the permanent fix is to have similarly complex rules in the same Voice Usage and then make sure you test to verify the route order is being followed as desired.

Lync/Skype for Business Loud Ringer

Loud Ringers for Lync/Skype for Business is one of those problems you think can't be solved. But I stumbled upon a technique awhile ago that can be used to solve this problem. This technique though, uses pieces of the product in ways they were not originally intended. But I will say that I have been doing this since Lync Server 2010 and I hope with writing this blog that more people will use this technique and maybe it will get a better method for implementation by the product group.

So enough dancing around the topic.

In order to execute this technique we need the following:

• Analog based Loud Ringer (Algo 1825 for example)
• Gateway with Analog FXS ports
• Create a Lync/Skype for Business Analog Device
• Device that can do Pin Authentication for a Common Area Phone
• Lync/Skype for Business user that has SimRing capability

Step 1

First step is to setup the FXS port and Gateway so that a dedicated number can ring that port. I prefer to use non-DID numbers for this application, but it just has to be a unique number in the Lync Dial Plan. Later we actually use this number when defining the Lync/Skype for Business analog device LineURI. Because there are so many Gateways with FXS out there, I'm not going to get into specifics in this area. But I generally route the extension portion of the number to the port. For example if +13005551000;ext=9572 is the intended LineURI, only the 9572 portion would be configured for routing to the port on the Gateway. 

Not getting the hint? 

I manipulate the number either in the trunk configuration of Lync/Skype for Business (my preference) or the gateway to just be the extension.

Oh you you are one of those people who don't like to use ;ext= ? Then you'll have to figure out the Pin Auth on your own later.

Step 2

Next we add the Gateway with the FXS port to the Lync/Skype for Business Topology. Nothing special here, but make sure it is communicating on the correct port/protocol.
Once the Topology has been published and replication has occurred, you will need to create an analog device in Lync/Skype for Business. 

Here is an example of the command: 

New-CsAnalogDevice -LineURI "tel:+13005551000;ext=9572" -DisplayName "Someone's Loud Ringer" -RegistrarPool <same pool as Loud Ringer user> -AnalogFax $False -Gateway <IP or FQDN of Gateway just added> -OU <your favorite OU>

Here is the technet for reference.

Pssst don't forget to do an Address Book Update... you'll need it soon and might as well have it working while we do this other stuff

Update-CsAddressBook on the pool that has the user with the need for the Loud Ringer.

Step 3

Once AD Replication happens we need to set a client pin for this analog device. Say wha?! Yes... just stick with me here... 

Here is an example of the command:

Set-CsClientPin -Identity "Someone's Loud Ringer" -Pin <any pin you choose>

Here is the technet for reference

Step 4

Login to the Analog Device like a Common Area Phone using Pin Authentication. For example the extension is 9572 and the pin is well... whatever you set it to. It doesn't matter if this device stays logged in or not, we just needed to log it in once as a Common Area Phone.

This would be a great time to call the Analog Device from lync and make sure the Loud Ringer is actually working. That way we aren't troubleshooting the physical install too... later on.

Step 5

Set the SimRing for the user that needs the Loud Ringer. This can be going to their PC or getting their username and password, or using SEFAUTIL. The bottom line is you want to set the SimRing for the Analog Device above which should. 

If you don't see it as a contact you can add, you might have forgot to update the address book on the server, or maybe you need to log out and back in to force an update.

Step 6

Call the user who needed the Loud Ringer and hear their praises and celebrate that you solved that problem for them that has been hanging around for a year or two. Or if it doesn't work... dig out your Lync Debugging Tools and Wireshark. I know you'll figure it out.