There’s another SfB call handling option that we haven’t covered yet, called Shared Line Appearance, or SLA. Where Call Pickup Group felt like “let’s cram old school PBX functionality into SfB”, SLA feels like “Let’s cram old school key system functionality into SfB”.

CsServerApplication

The first step is to create a CsServerApplication, which provides the queue-like functionality. This runs on your FEs, and you only do this setup once.

Create a User

With SLA, you create a user object (that’s not assigned to an actual person, it’s like the phantom user concept), and assign the Line URI to that user.

CsSlaConfiguration

Next up is creation of the CsSLAConfiguration that’s not unlike what we saw for Response Group Queues:

• Set a maximum number of calls
• Set busy option, which is what happens when the maximum number of calls is exceeded (like a Queue overflow). Options are busy on busy – a busy signal!, voicemail, or to forward the call to another SIP address.
• Set Missed Call (no answer) option – disconnect, busy signal, or forward to another SIP address.

I don’t understand why an organization would allow a call to ring, and then when it’s not answered, send a busy signal to the caller. One would think that voicemail – even a greeting with no option to leave a message – would provide a better option, but hey, there’s no option to send a Missed Call to voicemail!

CsSlaDelegates

The last bit of functionality that you configure is to configure user(s) as delegates of the SLA object created above.

When a call comes in to the Shared Line, all of the delegates phones will ring, showing the caller’s information. Delegates can also see how many calls are “queued”, and can see who has answered each call.

Limitations

Delegates cannot place an outbound call on behalf of an SLA. Further, SLA is only supported on certain models of deskphones. Windows, Mac, and mobiles do not support SLA.

Summary

I’ve never deployed SLA for a main number. In fact, I’ve never deployed SLA, have never met a customer who has, and could not find any coworkers who have, either.  Compared to Team Ring (or Delegation) of a phantom user, SLA is limited to certain devices and doesn’t allow outbound calling like Delegation (which is odd, since SLA uses Delegation under the hood). I don’t understand why there is an option to send a call to voicemail when the “queue” has too many calls, and no option for sending a call to voicemail when it’s not answered.

I don’t recommend SLA for handling a main number for an organization that faces the public or paying customers. If you’re considering SLA for other uses, you need to set it up and test, test, test to see if it’s going to meet your needs. My guess is that it won’t.

Call Pickup is one of my least favourite SfB functions. It’s clunk to setup, unnecessarily overlaps other functionality, and seems to be around for those holdouts who want a modern UC system to act like their legacy phone system.

Call pickup is similar to Team Ring, in that it allows your coworkers to answer your phone on your behalf. There are a couple of differences in the implementation, however.

With Call Pickup, only your phone rings. Your coworkers have to be able to hear your phone, and  distinguish that it’s your phone ringing. With Team Ring, your coworkers phones will ring after a configurable delay. They don’t have to be able to hear your phone or distinguish that it’s your phone that’s ringing. This allows you to use Team Ring across floors, buildings, or cities. When your coworkers phones ring with your call, they’ll receive a notification indicating that it’s a call for you, and they can set a distinctive ring.

Group Call Pickup needs to be configured by an administrator, via PowerShell. This makes it a bad choice for an environment with a lot of changes. Team Ring is configured at the user level, meaning administrators aren’t required, and the user can configure and reconfigure their settings to best reflect their immediate requirements. SfB is supposed to be flexible and dynamic, right?

Group Call Pickup works by piggy backing on the call park service. SfB parks the call, and allows any user who knows the call pickup code to answer the call. There is no security here, and I’ve seen post-its on cube with pickup numbers “*300 for Bill, *301 if Sarah’s phone is ringing, *303 for John”. With Team Ring, the user can specify which team members are able to answer calls. The Team Members don’t have to remember any specific code to dial. With Team Ring, users who might answer the call are also presented with information about who the caller is. With Group Call Pickup, they just know there’s a call.

I’ve seen Call Pickup used for main numbers. For scenarios where you have a small group of people who are sitting in an open area near the reception desk, this can work well. To help those users determine if the reception phone is the one that’s ringing, use an indicator light like Blync or Busylight so there’s a visual indication, especially if the office area is noisy.

I prefer Team Ring to Group Call Pickup. It’s more inline with a UC approach where you’re provided information and allowed to make a decision. Users see information about the caller, they can click to answer instead of needing to remember and then dial a specific code, and they don’t need to listen for a specific ringtone or look for a light to know a call is coming in. Group Call Pickup still feels like forcing legacy PBX functionality on top of SfB.

This post is part of my Main Number Handling series, so if you’ve just recently stumbled on to my blog, be sure to check out the earlier posts, including the introduction.

One of the most awkward scenarios I’ve seen for handling a main number is to assign that number to the receptionist. It works well for low call volumes and when the receptionist is at their desk, but it falls apart in several scenarios:

• When reception is on a break, late, on vacation, or doing one of the million+ task receptionists take on, who answers the phone? If it’s a softclient, this means an PC is left unsecured.
• Voicemail routes to the receptionist’s Exchange mailbox. When they’re not available (see above!) messages are either not read or the receptionist needs to share their password or voicemail PIN.
• The receptionists voicemail greeting is either their personal greeting which is inappropriate for corporate messages, or the voicemail greeting is the corporate message and doesn’t reflect the fact that it belongs to a user, when someone is calling directly for that user.

A better solution is to create a standalone or “phantom” user account for the role of the reception phone, so that the receptionist can have their own phone and voicemail and privacy of email, voicemail, and PC.

The approach that I usually see is to have the receptionist use a softclient on their PC, and use a deskphone for the main number. If the deskphone is too clunky for forwarding calls, I’ve seen SimRing and TeamRing used to have the receptionist’s softclient also be able to handle the call.

If the receptionist doesn’t answer the call, voicemails would be left in the main reception voicemail box. Other staff can retrieve voicemails via the phone, or mailbox delegation can be used to allow others access. If someone else is covering the reception desk, they can answer the phone at the desk, or choose to Simring/TeamRing their own SfB account instead.

In the past handful of posts, I’ve run through some of the details on how analog devices connect to and work with, SfB. Now that the technical bits are out of the way, I wanted to provide some recommendations on how you can make life with analogs easier.

We’ve seen that analog devices really don’t become Skype for Business devices. They might as well be an extension on a PBX. If you’re not getting SfB functionality and management, and you have to buy gateways and do all kinds of extra configuration, why bother at all?

You should get rid of as many analog lines and devices as you possibly can, including faxes. 141 years of analog telephony is already too long.

There, simple enough? Well no, not really, but that statement sums up what I feel is a realistic and relevant aim for every organization deploying Skype for Business. Exceptions exist in a few cases, but in general analog needs to go.

Analog Trunks

Let’s talk first about analog trunks to the PSTN. The quality is terrible, they’re expensive in comparison to a SIP trunk channel, and they offer very poor flexibility for inbound calls. You can’t have more than one number assigned to each physical line except for when you use the concept of overlines. That means you need one line per direct phone number, and user with a direct number is limited to one call at a time. That forces you to the use of main numbers, auto-attendants, and extensions, and that’s what the 80’s were for.

For outbound calls, you have no flexibility to set caller ID. You get the individual line number, the overline number, or the telco will allow you to use the main number, but this configuration is all static, and all done through the telco.

As for emergency calls, stick a red phone on the wall beside the firstaid kit, AED, and fire extinguisher. Don’t try and use one analog line to handle emergency calls for an entire building of SfB users. In any real emergency, your users will quickly swamp one or two lines. Your Skype for Business deployment should be able to place multiple emergency calls per site, not just one or two.

Faxes and Modems

Faxes and modems work by sending sound over an analog line. The devices on either end whistle at each other. Does it really make sense to stick a piece of paper into a machine, have that machine scan the paper, then whistle over an analog line to a gateway that’s going to now digitize and packetize the audio, transmit it long distances over laggy, jittery, and potentially lossy media, then decode and reassemble that digital information back into an approximation of the original whistle, such that a second machine can listen to it and draw a picture of what is represents?

How is this still a thing that we do?

Faxes

Some organizations still use faxes. It may be a legal requirement, they may have partners that still use fax, or they just might be slow to change. First, do a quick survey of your existing machines and users. Pull some reports from the machines to see how often they’re used. Find out who uses them, and what for. There’s a good chance that they could scan to PDF and email, fax directly from MS Word via an eFax driver, and receive directly to their inbox via an eFax service.

At the very least, you can probably reduce the number of physical fax machines that you have. If you do need to keep a machine around, it doesn’t need to talk to Skype for Business, so move them off your SIP trunks and PRIs to an individual analog line.

Modems

Gone are the days of modems for accessing the Internet. Every modem that I stumble across these days is a rescue – or out of band management – modem. It makes a lot of sense to have a way to reach and administer your gear, that’s independent of that same gear. Independent is the key word.  If you need a rescue modem for anything voice related, it must be a single analog line from the telco.

Better yet, ditch the analog modems. You can use an LTE stick in a device or router, or a consumer-level DSL line to a VPN headend. This approach will also give you enough bandwidth to do more than poke away at a command line.

Alarms and Elevator Phones

These too, are best moved to individual analog lines. They don’t need to talk to Skype for Business. In terms of uptime and reliability, a boring analog line from the Telco will be rock solid. Your users that get stuck in an elevator won’t be using the elevator phone when the UPS powering your SBC or gateway runs out of juice and the call drops. If you need your elevator phone to reach someone at your organization, you can route the call via the PSTN.

When You Have To Integrate Analog

Lurking in many larger conference rooms are standards based video conferencing units. Many of these have analog connections for voice calls. Depending on how old these units are, and if you’re planning to refresh them, you may be in a position to deploy some of the fantastic options that talk natively to Skype for Business for both audio AND video. If refresh/replacement isn’t near, then you may need to go down the path of analog integration into Skype for Business. The good news is that this is the simplest form of a SfB analog device.

Paging and Enterphones

This is a spot where analog in your Skype for Business environment makes sense, especially if they’re already deployed. Many paging and enterphones (“buzzers”) come in analog or SIP versions, but Skype variants don’t exist. You’re also not going to be worried about call quality or downtime due to power outages with these. Financially, these devices likely aren’t used enough to justify analog lines directly to the telco.

Skype for Business Online

If you are planning to move to Skype for Business Online, you should be aware that there is no “CsAnalogDevice” online (there’s also no CsCommonAreaPhone). You won’t be able to take advantage of how CsAnalogDevice simplifies routing, and your analog devices won’t be SfB objects that can be added to your contact list. If your analog device needs PSTN access, you will have to obtain an on-prem PSTN connection, there is no way to use a Cloud PBX with PSTN Calling number.

In my previous post I talked about options for routing calls within gateways. In this post, we’ll take a look at how Skype for Business routing options work with the gateway.

When you’re working with analog devices, you have two ways of configuring routing in SfB. The first is the standard SfB routing, which is flexible and resilient. However, analog devices don’t require this flexibility – they are attached to just one gateway by a pair of copper wires. It’s possible to simplify the routing to analog devices by the use of CsAnalogDevices, which is a SfB object you create with the New-CsAnalogDevice PowerShell command. A CsAnalogDevice object registers to a pool, allows a SIP address and display name for an object to be added to contact lists, specifies the gateway that the device is plugged in to, and offers fax handling.

When you place a call to a CsAnalogDevice, the SfB routing process will route the call to the specified gateway, and not via the normal SfB routing process. This helps keep your routing configuration tidy if you have a number of analog devices, since you would need to specify routes manually for each number. You’re entering that same information when you use CsAnalogDevice, just in a much nicer format. If you’re in a large organization, you can also use Role Based Access to allow helpdesk admins to create CsAnalogDevices, but you probably wouldn’t want to turn them loose with making routing changes in SfB.

When you place a call from the analog device, the call is handled via SfB. This means that you can also now easily apply Voice Policies to your analog devices, leveraging the configuration that you’ve already built. Without CsAnalogDevices, you would have to build out your policy manually on each gateway.

When you configure a fax as a CsAnalogDevice, you need to specify “-AnalogFax $True”. This causes SfB to route the call differently, so that the fax call is sent back to the gateway that it came from, instead of routing through SfB.

I recommend this excellent blog post on Lync Faxing. Don’t worry, nothing has changed from Lync to SfB with regard to faxes.

While I’m sending you off to other Blogs, be sure to check out Greig’s post on M:N Routing and CsAnalogDevices. Greig explains a gotcha with naming your trunks and gateways in Topology Builder that may interfere with calls when using CsAnalogDevices.

Routing is an interesting topic of its own, however you can’t really consider much about routing without also considering number translation and normalization, which is the topic of my next post.

Gateway routing

Whether gateways have SIP trunks, PRIs or analog lines and devices, they all need to make routing decisions. In very simple architectures, a gateway only connects two systems – usually the PSTN and SfB – so there are no decisions to be made. Calls coming in one interface are sent out the other.

When you have multiple interfaces and systems to route between, you have a number of options for routing choices. In most cases, you can combine these choices.

Static Routing

Static routing is the least technical option is the most administratively demanding. You build a list of numbers, and assign them a destination. Static routing could include listing every single number, or it could be patterns like 425555xxxx or 74xx.

Analog devices that are connected to a larger gateway, possibly the same gateway used for your telco connection, are easy to route to. When a call reaches the gateway, it checks what numbers belong to devices connected directly to it, and delivers the call their rather than routing it to another destination. These gateways tend to not have very many analog ports, and you might also not be able to connect all of your analog devices to one gateway because of cable runs and gateway locations.

Gateway/SBC Registration

Analog only gateways such as the MediaPack from AudioCodes and Tenor from Sonus can integrate into their respective larger gateways. This integration allows you to treat the ports on the MediaPack or Sonus as if they were on the larger gateway. This gives you the simple routing of “connected” devices, yet allows you to have a number of different gateways in different locations. In this configuration, the analog gateway registers each analog device as a SIP endpoint in the larger gateway or SBC.

Active Directory Lookups

Both Sonus and AudioCodes offer the ability to use Active Directory to determine where a call should be routed. In the simplest SfB configuration, the gateway queries AD to see if the destination phone number is assigned to the msRTCSIP-Line attribute of any user. This attribute is the SfB LineURI, so a match indicates that the number belongs to a user in SfB, and that the gateway should route to the call to SfB. Calls that don’t match can be directed to another location, perhaps a legacy PBX. It’s possible to use more than the msRTCSIP-Line attribute, and build some very complex and dynamic route configurations. Be sure to account for other attributes for different devices like dial in conferencing, auto attendants, and other endpoints that don’t use the msRTCSIP-Line attribute of a user object.

Brute Force Method

If you don’t want to deal with Active Directory lookups, or are in a scenario where that method might not be suitable, you can take advantage of failover behavior. If you configure a gateway to deliver all calls to one destination – say a legacy PBX – and the number isn’t a valid endpoint on that device, the call should be rejected. The gateway can then delivery that call to the next destination in the route table, and so on, until the call is delivered or the destinations in that table are exhausted and the call fails.

And that covers gateway routing. Up next, SfB routing options.

Analog devices are one of the least understood aspects of a Skype for Business deployment. In this post, I’ll provide a 30,000 foot overview of how analogs work with SfB on-prem deployments.

An analog device is anything like a phone, fax, alarm system, door buzzer or overhead paging system that uses an analog phone line. That phone line is a pair of wires that form a circuit that connects the device to your PBX or the telco.

With SfB, there is no Sfb hardware device that the analog phone can plug into. You have to use a gateway for this, from Microsoft partners such as AudioCodes and Sonus. However, plugging an analog device into a gateway doesn’t magically make it an SfB device. It doesn’t have presence, it doesn’t logon. It’s still just a boring analog device. The gateway communicates with SfB over a SIP trunk, just as if it were a SIP trunk from your Telco.

What we’ve got then, is an analog device that has an analog circuit to a gateway, that gateway has a SIP Trunk to SfB. SfB will have a connection to the PSTN, which will use an SBC or another gateway.

It is possible to have analog ports on the same gateway that’s connecting your SfB environment to the PSTN, but for clarity I’m showing them as two separate devices.

When you place a call from the analog phone, the analog gateway uses its routing tables to determine where the call should be routed next. This might be a simple “send everything to SfB”, or it could be more complex and allow connections direction to the PSTN gateway, or to SfB.

When a call comes in from the PSTN, the PSTN gateway has similar options. It can send all calls to SfB, or it can route the calls to different locations. When calling from SfB to the analog devices, SfB sends the call directly to the gateway.

Routing

In all cases, you have to configure the gateways’ routing tables. Every gateway you add to your environment adds to the administrative overhead of your solution, and the complexity of your call routing options.

Call flows and routing decisions are a significant part of dealing with analog devices. In the next posts, I’ll cover how gateways can make routing decisions, and how SfB can be configured to simplify routing to analog devices with some loss of more advanced capabilities.

I know more than a few people in emergency services, and they’ve shared some of their stories around bad location information situations. I wanted to share a few of those here so that you get an idea of what can occur. All of these scenarios are preventable – make sure you’re not contributing to future examples!

The Case of the Amphibious Cruise Ship

The first incident involves a sick passenger on a cruise ship coming in to dock. An ambulance was dispatched, but something seemed wrong to the paramedics – the address didn’t make any sense. The address was near an amusement park well inland, and nowhere near the cruise ship terminal. It turns out that the PBX was hosted in a datacenter near the amusement park, and the correct address for the phone number at the cruise ship terminal was never provided to the telco providing the PRIs.

The Case of the Mixed-up Addresses

The second incident involves a dispatching error. In a previous post on 911 and mobile phones I shared an example of what is typically seen at the PSAP. Here’s a variant on that example with what the dispatcher saw:

In this incident, the dispatcher sent resources to the address of the cell tower (28 Mineral Rd in this example) as the location of the mobile phone had not yet populated in the ALI database.

The Case of the Relocated Consumer

The third example involves a consumer with a home VoIP service. The consumer moved from a major city to a remote area, and neglected to update their address information with the carrier. When they placed a 911 call, they were connected to emergency services at their old address. Without a built-in method for reassigning the call to the correct PSAP, the staff relied on their wits and contacted a friend in the police service who’s brother – also a police officer – was near the caller and was able to coordinate a response.

The Cases of the Swapped Suffixes and Dizzying Directionals

The fourth and final scenario isn’t a specific case, because it’s too common. When you provide addresses, be very careful for suffixes like “street”, “avenue”, “circle”, etc., as in many areas the same road name will exist but with different suffixes. Mixing up or omitting directionals like “north” or “west” is also too common. Be really careful if you have craziness like “Maple Court East West” or “North Main Street Southwest”. Dispatching emergency services to the wrong location can have terrible consequences.

Your Goal

When you’re deploying SfB – or any phone system or line for that matter – take an extra moment to ensure the address is correct and clear. In the US, you can use the USPS address format to make sure your suffixes and directionals are clearly expressed.