Category Archives: Analog

Survivable Branch Telephony & The SBA

Posted on by
Reply

Skype for Business has long had a survivable branch office telephony solution product, but it’s no longer a good choice in 2018 and beyond. I’m not convinced that it was ever anything more than “the best of the worst”.

Way back in the day, Cisco had a survivable remote telephony option. If your branch office WAN was down, a line card (analog, PRI, or even SIP) in your branch router could get you access to the PSTN. Office Communication Server 2007 R2, the first release in the LCS/OCS/Lync/SfB product to be classifiable as a potential PBX replacement, didn’t have a comparable solution. With Lync 2010, Microsoft introduced the Survivable Branch Appliance (SBA).

SBA Administrative Effort

The intention was that Microsoft partners would build appliances that host the SBA software. A company could ship one of these to a branch office, have an entry level technical person rack & stack the device, and the IT techs more experience with voice would then connect to it remotely and finish the configuration. In reality, that was… challenging. Some initial firmware upgrades required a USB hub, flash drive, keyboard and VGA monitor to be hooked up, so that the “entry level” technical resource could bang their way through a really ugly CLI. Not fun.

In terms of ongoing support, the vendor is responsible for releasing updates for the SBA, including the CU. When Lync 2010 CU4 was released (it enabled the first mobile experience) it took more than 6 months for some vendors to roll out CU4 for their SBAs. Not a great experience, and a lot of my customers abandoned the SBA in order to get their users their mobile connectivity.

Hardware

Depending on the vendor, a PSTN gateway was often included as a module in the SBA. Alternatively, the  SBA was a module in the gateway. The first option offered a chance of decent performance. The second option typically offered terrible performance. It’s simply not possible to shrink Wintel server horsepower down to an itty-bitty interface card size, never mind power it. Often the specs were similar to those of entry level laptops. This really limited performance and capacity, and the higher-end modules are expensive.

If you went for the full-sized SBA with the add-on gateway, you will likely open the box and recognize the device as a rebadged 1U or 2U server from one the standard Wintel server vendors. Don’t those need 4 post racks? Yup. And this is for a branch office, and while some branches have 4 posters, a lot are lucky if they’ve got an 8U wall mount equipment rack.

Feature Loss

Other than being a difficult product to manage, the SBA has some significant drawbacks.

First, the users only use the SBA as a SIP registrar and for backup telephony. All meetings, video, whiteboard shares, response groups, contact list functionality is all in the Standard Edition or Enterprise Edition that the SBA is associated with. If that SfB pool or connection to it is lost, users are presented with a “limited functionality mode”, with no contact list, and only voice capabilities. However, voice calls have to be placed by dialing the full number. No click-to-call, no buddy list, no extension dialing. Yuck. How many users would a) remember what to do to place in call in this mode, and b) actually want to do it, versus doing other things during the outage?

Next, your PSTN connection needed to be to the gateway located onsite with the SBA. Your three options are analog lines, PRIs, or SIP trunks.

Analog lines offer terrible call quality, and don’t offer DIDs. The later is okay if you only need outbound calling and don’t need the call to have your DID as caller ID, otherwise it’s a pretty terrible experience.

PRIs offer good call quality and DID support, but they’re expensive. Fractional T1s offer just a tease of cost reduction. You can pay 20% less for 50% less capacity, if you’d like!

SIP trunks offer good call quality and DID support, and depending on your provider, offer some extra options that PRIs and analog lines can’t support, like redundancy and failover.

Remember that the SBA doesn’t have any functionality other than the SIP registrar and backup calling. It’s likely that when your wan is down, your callers can’t reach Auto Attendant, Response Groups, or voicemail. That’s not a very good scenario, though there are a couple of workarounds – with huge tradeoffs.

Another downside is that typically a user homed on a full SfB pool has failover to a paired pool. With an SBA, this isn’t possible. The user is homed on the SBA, and can only failover to the full SfB pool associated with that SBA. If the SfB pool is lost, they’re in limited functionality mode. If an SfB pool that’s paired with another is lost users failover with that same limited functionality mode, but the administrator can quickly trigger a full failover that restore all modalities and functionality.

So what’s a organization supposed to do?

On the plus side, the SBA didn’t consume an SfB server license. That’s one small plus for SBAs, against a sizable list against. So, what are your options, in a classic on-prem only environment, but also in a hybrid, Cloud Connector Edition, Teams Direct Routing, and mixed SfB/Teams scenarios? Stay tuned!

 

 

 

Normalization and Translation with Gateways and SfB

Posted on by
Reply

Skype for Business has a number of areas where you can normalize or translate a number. When we’re dealing with users, normalization is the process of taking the number that they’ve entered or “dialed”, and converting it to a standard format for further processing. This normalization allows the user to maintain local dialing habits, and convert them to a standard format. That standard format is E164, which also ensures the number is globally unique. When we’re dealing with calls received from the telco or PBX, normalization refers to the process of converting the called number into E164 standard format.

Normalization is a form of translation, but not all translation is normalization. When we’re sending a call out of SfB, we might need to translate to a format that’s expected by the device we are sending the call to. That format might not be standard or globally unique. This translation can take place on both the called and calling numbers. This translations is configured in Trunk Translation Rules.

Trunk Translation rules can only match and translate same field. For example, SfB cannot match on Calling Number and translate the Called Number. However you can match and modify a called number and match and modify the calling number, on the same call.

Outside of SfB, number translation can happen

  • At a PSTN gateway or SBC
  • At an analog gateway
  • At a PBX
  • At the telco (few and far between, but some do!)

The options you have within these systems will vary. Generally speaking, the gateways and SBCs are very flexible, PBXs somewhat flexible, and telcos are something that you shouldn’t count on.

Depending on what are we’re talking about, there are a number of overlapping options available, so which ones should you use?

In general, you’ll want to avoid a smattering of different translations. Where ever possible, keep all of your translations in one system. Which system? Usually SfB, because most organizations have more people that understand SfB more thoroughly than gateways. For example, when you’re sending a call to +14258675309, the telco probably wants you to send only 4258675309 to them. You could strip the +1 within SfB before you had the call to the gateway, or you could strip it at the gateway before you hand it to the telco. SfB is my preferred option here.

Sometimes, your hand will be forces. Let’s say you want all calling numbers (your caller ID) to be changed when you call to a certain area code. You need to match on the called number, but change the calling number. SfB doesn’t handle complex translations like this, so you’ll have to use a gateway.

When you’re considering analog devices dialing through SfB, you can perform normalization in the gateway or in SfB.  If you use a dialplan within SfB, you can take advantage of the “select” feature to select normalization rules that already exist in SfB. Generally, you would want to use the same rules that are in the Dialplan that apply to the local users.

There’s some confusion over how to assign a Skype for Business Dial Plan to an analog device. Technet states “you can then manage the analog device by assigning policies and dial plans to the contact.” It turns out that you can’t apply a dial plan to a CsAnalogDevice. Well, you can apply it, it just won’t work.

When you look at how user level dial plans work, this makes sense. User dial plans are applied at the device level: your SfB client on your PC, your mobile client, or your AudioCodes 440HD phone – any SfB client. An analog phone isn’t an SfB client, nor is the gateway that it plugs into, so there is no place for the normalization rules to be downloaded to and applied. Instead, you need to use a pool level, site level, or global dial plan. These dial plans will apply at the server level for inbound calls, but will also be used for users if a user level dial plan doesn’t exist.

For gateways, I’ll use the Global Dial Plan in smaller environments, and Pool level Dial Plans in more complex or geographically diverse environments. The Global Dial Plan can quickly get messy if you try to stuff in enough rules to handle larger, global deployments.