A common request that we get is to mask or change the caller ID of an outbound call. This might be because the caller is a VIP and doesn’t want to be harassed, or they might be a support rep and any returned calls should go to a queue or main number. You might also be calling from a number that doesn’t belong to the carrier you’re sending the call over. There are a handful of ways to handle this scenario in SfB.

Using a number that doesn’t belong to the carrier you’re sending the call over can have some odd results. They may allow it, they may block it, or they may override it with another number, usually your billing telephone number (the “BTN”) for the trunk. The BTN is usually not taken from a customer’s block of DIDs, may not have a caller ID string or 911 address associated with it, and typically is not assigned to any endpoints, so sending the BTN as the caller ID won’t help anyone that you’re calling.

You can use the “Suppress caller ID” and “Alternate Caller ID” on a route  to set a number of your choosing. This would apply to all calls using  this route. If you want to override some users’ numbers and not others, you’ll need a of duplicate your voice policy, usage, and route, and then set the override on one route. Repeat this exercise if you have different users that need to send a different number. If you need more flexibility than this, check the other options. On the plus side, this solution doesn’t care which trunk/gateway the call is routed to.

A Trunk Translation rule gives you more flexibility than the alternate Caller ID solution. You can set a series of translation rules using regular expressions on the Trunk Configuration (you could cheat and do so globally if you’re in a small organization, but you’ll just wind up undoing and redoing all of your work if you expand).

The use of regular expressions means that you can easily handle multiple translations per trunk without needing all those extra voice policies, usages, and routes. You also get the flexibility of regular expressions to match and change only certain parts of a number and leaving the rest, like 236-551-xxxx to 236-555-xxxx.

If you have multiple trunks/gateways, you’ll need to configure appropriate rules on all of the gateways.

Trunk Translation is generally seen when performing Least Cost Routing (aka Toll Bypass), such as when a user from the UK calls a number in New York. The New York telco may not like the UK number, so you can configure translation rules so that the call appears to be from the New  York office. You lose the personal DID of the caller, but the call will go through. I’ve also used this when a different carrier is providing a backup trunk, and they won’t allow the numbers from the first carrier.

The two above options are configured by administrators, are generally deployed because of telco requirements, and aren’t very flexible. It’s possible to use some other calling features to allow your users to be in control.

Delegation, also known as Boss/Admin, allows an assistant to answer calls and place calls on behalf of their boss. This functionality can be used to allow a user to selectively mask their number with another, when they choose. I’ve typically seen this setup for VIPs, when they want the recipient to see some alternate number – maybe there assistant, or an auto attendant.

To implement this, you’ll need to setup a dummy “boss”. Delegate the dummy boss account to the real boss. Now the real boss can place calls as the dummy boss. Next, if you don’t want returned calls to simply get a busy signal or dummy boss’s voicemail, setup the dummy boss to forward all calls to the assistant, or the auto-attendant.

Don’t setup delegation between a boss and their assistant to be two-way. Weird things can happen!

The gotchas with this solution are mainly around client support. Not all clients support calling on behalf of someone else, especially mobile.

You can also use a Response Group that’s configured to have Agent Anonymity. This gives users who are agents in that Response Group to place calls on behalf of the Response Group. See my Main Number Handling posts on Response Groups for details on how to do this. This solution has even more limitations that the Boss/Admin option above. Client support is limited to the Windows client, and your users will need to be homed on the same pool that the Response Group is homed on. This is a good solution is good if the users are already agents in the Response Group (such as on a helpdesk), but otherwise I wouldn’t bother with this one.

And lastly, Ken Lasko outlines how to implement *67 in Skype for Business here.

If you’ve got any other solutions for number privacy, hit me up in the comments!

I’ve written quite a bit about SfB Response Groups, so let’s dive into their Exchange cousin, the Auto Attendant – AA for short.

Auto Attendants allow Exchange to answer calls to your organization. You can play greetings, set schedules, allow callers to reach your users by saying or spelling a user’s name or dialing their extension, or you can provide them a list of options that they select by pressing a key.

Creation

To create an Auto Attendant, open the Exchange Admin Center, select UM dial plans, open the dial plan that you want the AA created under, and click the + in the Auto Attendant section.

You’ll need to provide a name, indicate if you want the Auto Attendant active immediately after you create it (you might not if you’re preparing for a future migration), indicate whether you want the AA to respond to voice commands, and provide a phone number to reach the Auto Attendant at. Note that you don’t *have* to provide a phone number, which is handy for lab work and setup before a migration. You will of course need to circle back and provide at least one phone number before anyone from the PSTN can use your AA to reach your organization.

If you’re in a SfB environment, you’ll need to run the New-CsExUmContact command to create a contact object so that your SfB environment knows about the AA endpoint. Non-SfB environments will need to follow different setup steps which I won’t cover here.

Options

Now that your AA is created, you can double-click it to configure additional options.

General

Under General, you see the same options as when you created the AA, joined by a few others: setting a language, business name, and business location. Set the name and location accurately, as they can be read to a caller by the Auto Attendant. Here, you can also set a backup Auto-Attendant, that callers can be sent to when voice recognition isn’t working well.

Greetings

Under Greetings, you can set business hours and after-hours greetings. You can also add an informational message, and optionally set this message so that callers cannot skip it. This is useful for things like unexpected closures dues to weather

Business Hours

Under Business Hours, you can set the timezone for the Auto Attendant, and then you can configure your business hours  as granular as 15 minute intervals. Here, you can also specify your Holidays using a start and end date, and specify a Holiday Greeting. Note that the holiday greeting is played from 12:01am to 11:59PM on the day(s) you configure. You can’t have the holiday greeting start at the close of business on the last day of work. You can use the announcement feature for this, or sneak in at the end of the day and reconfigure the holiday greeting to have started that day. Note that after the holiday greeting plays, callers are sent to the after-hours greeting and menu.

Menu Navigation (or not)

I’m going to skip menu navigation for now…

Address Book and Operator Access

Under address book and operator access, you can specify what permissions callers have to reach users, user voicemail without ringing the user, for searching the directory for users,  and for transferring to an operator. Note that “operator extension” here is the operators actual phone number, not what key you want the caller to press.

Dialing Authorization

Under dialing authorization, you can set where users can dial via “outdialing”.

Menu Navigation (for real)

This section is the meat and potatoes of the AA is configuration. There are two sections, business hours and non-business hours. The options within each section are the same:

• You can upload a record prompt file – if you don’t, the AA will read the options for each entry using text-to-speech.
• You can enable or disable menu navigation, but you do need to enable menu navigation for your AA to work, so go ahead and enable it.

If you click the + or pencil button, you can created or edit a menu entry. You need to configure the prompt, which will be read by the AA using text-to-speech if you haven’t uploaded a greeting.

Entry Configuration

You can pick when key you want to assign this action to. You can select 1-9 or timeout. 0 is reserved for reaching the operator at the extension programmed earlier.

When the key is pressed, you can optionally play an audio file. After then you can select one additional action:

• None
• Transfer to an extension (This can be an internal or external number, so long as it is permitted by the dialing authorization rules you configured above)
• Transfer to another auto-attendant (this is useful if you want different languages, or transfer someone to a different country or group, but please don’t try to build an IVR solution with multiple Auto Attendants)
• You can leave a voice message for a user, without ringing them. This usually goes to a generic voicemail box
• You can have the text-to-speech reach your business hours (you entered this carefully under the “general” section)
• You can have the text-to-speech reach your business location (you entered this carefully under the “general” section)

The business hours and location that are read out are what you entered in the “general” section. If they are pronounced funny with correct spelling, you may need to spell them phonetically so that they sound proper. The text string that you enter is never seen by users, so you don’t need to worry about weird spellings.

If you don’t set a timeout option, callers will be offered the same menu again. I prefer this option, since there is no explicit keypress to repeat the menu choices.

Up next

Response Groups and Auto Attendants share some common features, but differ considerably with others. Up next,  a comparison of Auto Attendant and Response Group capabilities and functionality.

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.