About Torren

I'm a Microsoft Certified Solution Master for Communication, aka Skype for Business. As a consultant I work in all areas of SfB design, deployments, and support, with a particular focus on voice workloads, networking, and high availability.

Main Number Handling – PSTN number as a Response Group IVR Destination

In my last post, I covered how to have a Response Group Queue overflow/timeout action send a call to a PSTN number. That means you can send a call to an analog phone (maybe a cordless one), a mobile, or any other PSTN number. That’s awesome for overflow and timeouts, but there’s still a hole in Response Group functionality: how can an IVR option deliver a call to a PSTN destination?

Every once in a while, you need to get creative in your solutions to meet end-user requirements. The solution here is tricky to figure out, but simple to configure once you know what to do.

To review, a Response Group IVR is when someone calls a workflow number, hears options, and presses a corresponding key. The native workflow options are to deliver the call to a Queue, or to ask another series of questions. There is no option to deliver a call to a PSTN number.

If we look deeper at the Queue configuration, the only place to specify a PSTN number is in the overflow and timeout options. If we could set the workflow to deliver a call to a Queue, and set the Queue to overflow immediately to a telephone number, we’d be set. We can do that by setting the Maximum number of calls in the Queue configuration to zero:

Queueoverflow0

And if you try the call, it will not work. As it turns out, a Queue will error out if there is no Group assigned to the Queue. The fix is simple: create a user in AD, enable them for SfB and enable Enterprise Voice, create a new Response Group group and assign the new user as an Agent. Assign that Group to the Queue:

Group in Queue

And things will work – a call to the IVR, where the caller selects the option for the mobile number, will be forwarded to that mobile phone immediately. The Queue process throws an error when it see there isn’t a Group with at least one Agent assigned, it never gets far enough in the process to look at the overflow options.

I don’t recommend that you use a real user’s SfB account for this. Create a fake account, and make sure you add comments or notes to indicate the purpose of the account, so that it’s not deleted or changed.

If you’re going to use this solution for a number of different workflows, you can use a more generic name for the User and Group, and use the same User and Group for all the Queues, as the destination is configured in the Queue.

 

 

Main Number Handling – Putting it all Together, Response Group Calls to a non-SfB number

A few years ago, I worked with a two different organizations who had the same scenario.  They had a main number for the security department. This number was for a Response Group Workflow, which would ring the security staff and a couple of additional phones in the security area, such as the break room.

That worked well when there was someone in the security office to answer the call, but it meant that calls would go to voicemail if there were no security staff in office. This happened often, especially in the one organization that was closed at night and the security staff member had to do patrols.

The solution for both was to setup the Response Group Queue timeout and overflow actions to “forward to telephone number”:

call action PSTN

Note the formation for the telephone number – you need to enter it as if it’s a SIP address, with your SIP domain after the @.

Yes, all of my lab environment domain names are colors! I set the desktop background of all the servers to be the domain name color, which helps me stay straight on which environment I’m connected to.

Okay, that’s cool, we can forward calls to a mobile or analog or any other phone as a timeout action on a queue. Tune in next blog post, where I show you how to send a call to any PSTN destination from a Response Group IVR.

Main Number Handling – Putting it all Together in Large Offices, reception coverage

In the previous post, I covered how to have a receptionist have first kick at answering a call, then for the call to be handled by an Auto Attendant if they weren’t available. You might want to have a backup for the receptionist if they’re not able to answer the phone. The easy solution is to also add this person to the Response Group group as an Agent. The trick here is to specify the two agents, and set the Routing Method to Serial in the Group configuration:

Serial Agents

Wit this setup, calls will always first ring “AApple”, then after the Alert Time has expired, the call will go to “BBlueberry”, and finally to the overflow destination. Be sure to watch your Queue and Group timers as discussed here to make sure your call doesn’t bounce around between the users.

This solution works well if you only need a main person and one backup. If you need a main group and a backup group, you would configure two groups, and then create an ordered list in the Queue settings:

Reception Queue

Make sure that the sum of the Group timeout values equals the Queue timeout value, otherwise your call with ring “Reception_Main”, then “Reception_Backup”, and then “Reception_Main” again. For example, I might set the Reception_Main group to 10 seconds, the Reception_Backup group to 15 seconds, and the Queue timeout to 25 seconds.

You can include the users in the “Reception_Main” group as agents in “Reception_Backup” if you want the users in the main group to be able to answer the call if it’s ringing the backup group.

I’ve seen this approach used for a shipping/receiving door buzzer. The driver pushed the door buzzer, which automatically dialed the Response Group (this behaviour was configured in an AudioCodes MediaPack). The Response Group had the shipper/receiver as the main group, and then some other nearby staff who could act as their backup.

Up next: Sending a call from a Response Group to a PSTN or other PBX phone

Main Number Handling – Putting it all Together in Larger Offices

I previously covered some simple solutions for main number handling for smaller offices. Now let’s have a look at larger offices.

I’ve worked with several organizations that prefer a human voice answer the phone wherever possible, and when that can’t happen they would allow the call to handled by an Auto Attendant.

The simplest way to configure this is to have the main number be a response group workflow. The receptionist is added as an agent. In the Queue, set the timeout (and optionally the max calls) overflow destination to the SIP address of your Auto Attendant. Callers now ring the agents when they first call, and then get the Auto Attendant if no agent can take their call.

Up next, some scenarios where you might want to add a second group of agents.

Outbound Caller ID Overrides and Anonymous Calling

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!

Inserting a PSTN usage into a Voice Policy

Voice Policies are assigned to users, and they control what a user is permitted to do in terms of voice functionality and calling. The “calling” part is determined by an ordered list of PSTN Usages within the Voice Policy.

Usages in VoicePolicy

The PSTN Usages are evaluated from top to bottom, until a call completes or the end of the list is reached.

If you’re using the Control Panel GUI and have just a few PSTN Usages and Voice Policies, it’s straight forward to edit this list. However, in the land of PowerShell, your only options are to remove a PSTN Usage, or to add one. The add function appends the PSTN Usage to the end of the list of usages, which isn’t ideal given that this is an ordered list.

I recent had to insert a new PSTN Usages into a large number of Voice Policies, and wrote this script to do that.

It’s straight forward to use. Create your new PSTN Usage, then run something like this:

Insert-PSTNUsage -CsVoicePolicy <VoicePolicy> -AddUsage <UsagetoAdd> -Priority <Priority>

where:

-CsVoicePolicy is the Voice Policy that you want to add the PSTN Usage to.

-AddUsage is the PSTN Usage that you want to add to the Voice Policy

-Priority is where the PSTN Usage should be added to the list of existing PSTN Usages. 0 is the start, and if you enter a value larger than the number of existing PSTN Usages, it’ll append to the end.

For example:

Insert-PSTNUsage -CsVoicePolicy VancouverStaff -AddUsage LongDistance -Priority 5 -verbose

This script returns no output to the console unless you use -verbose, in which case it will output the same information that’s also recorded to a log file:

Adding PstnUsage: LongDistance
To CsVoicePolicy: VancouverStaff
At priority: 2
Current Number of Usages: 6
Current Usages: zero One Two Three Four Five
Usages before insertion point: zero One
Usages after insertion point: Two Three Four Five
Restore Command: Set-CsVoicePolicy test -PstnUsages zero,One,Two,Three,Four,Five
Resulting in new usages: zero One LongDistance Two Three Four Five

  • The first three items are simply logging the parameters that you’ve provided.
  • Current Number of Usages is the number of PSTN Usages assigned to the Voice Policy before insertion.
  • Current Usages: a list of PSTN Usages assigned to the Voice Policy before insertion
  • Usages before insertion point and Usage after insertion point: Lists of usages before and after the spot where the new PSTN Usage will be inserted
  • Restore Command: this is a command that you can cut and paste into a PowerShell session to undo the Insert-CsPstnUsage command. The ability to back out your changes is something that I always like! (It might have wrapped in the above output, it’s not wrapped in the log file).
  • Resulting in new usages: this is a Get of the new list of PSTN Usages in the Voice Policy so that you can check your work.

I hope you find this useful, and I welcome your feedback!

 

Main Number Handling – Putting it all Together

A number of months ago, I kicked off what I thought would be a short and simple overview of the various ways you could handle a main number in SfB. As it turns out, there was nothing short about the process! However, now that we’ve covered the various components that you can use to handle calls to main numbers, it’s time to tackle some common main number scenarios that I see in organizations I work with. Along the way, I’ll throw in some tips and tricks from my list of ways to make life easier.

Before we do that, you should hop back to my first post in this series, where I talk about some of the non-technical things you should consider, and how you should approach designing a solution to handle your main numbers. You shouldn’t just rush in and set things up, as some of them take time. It’s also important to ensure that you’re getting the best SfB solution for your users, and not just a clone of what they had previously.

“I find that it’s often the case that SfB has all of the functionality to meet the same goals as users expected from a previous PBX. However, that functionality is often implemented differently.  That’s not because SfB is weird, but rather because it’s a UC system and not a PBX. There are multiple modalities to consider, as well as things like mobility and presence.  Tag for status change alerts is a good replacement for “Camp on” in the PBX world. While it may require you to take the additional step of click “call”, this does give you the opportunity to use a different modality to contact the user once they’re available, such as IM. Of course, you could always choose to IM the user who’s on the phone and thus avoid the entire requirement for Camp on functionality”

The Solutions

The first solution that I’m going to list, will also be the first one that I recommend that you not implement, and that’s to simply use the receptionist’s phone as your main line. If your receptionist goes on a break or vacation, then someone needs to know their password to check voicemails. That’s bad for security, but it also sucks for the privacy of the receptionist’s account. And what greeting gets used – the receptionists, or the organizations? Yuck, better to just move on to the next solution.

The second solution is suitable for small offices. You setup a standalone or “phantom” account for the main number, and leave the receptionist with their own account. We had a look at the good and the bad around this solution here so I won’t rehash that discussion.

Up next, we’ll have a look at options for scaling up to larger offices.