Main Number Handling: Response Groups, pt 1

This post is part of my series on Main Number handling. The most feature-rich call handling solution native to SfB is Response Groups. Response Groups, while nowhere near a full contact center, offer a great deal of flexibility and capability for an organization.

In the overview post, I provided a brief outline of Response Groups – they are an on-prem solution that offers hunt groups or IVR trees to assign calls to a Queue, and you can designate agents to handle the calls within that Queue. Response Groups are comprised of a Workflow, that receives and processes the call, passing it off to a Queue. Queues have Agents that are offered the call. To “Offer a call” is Microsoft’s terminology for the Response Group service ringing a particular Agent’s phone, so that they have the option to answer the call.

You might think at first that the Workflow would be the best place to begin any kind of deeper explanation. I’ve found that the opposite is true, so let’s being by taking a look at Groups, and since a picture is work a thousand words, here’s a screenshot of where to find the Response Group configuration page in the SfB Control Panel:


You can see the three components: Groups, Queues, and Workflows. The components are homed on a Front-End Pool, so you will need to select a pool each time you create or edit one of these objects.

Diving into Groups and selecting New, we see this page (it’s the same page for editing):


Note that while these components are homed on a particular pool, users who are Agents in a Group can belong to any on-prem pool in your organization.

The Name and Description fields are self-explanatory. Note the red star indicating that the name is a required field. You cannot edit the name afterward. This isn’t a big deal for groups since you can create a new group with the updated name, set the same options, flip queue assignments from the old group to the new, then delete the old group… but make things easy on yourself and come up with a naming scheme before you start.

Note that you’ll need names for Groups, Queues, and Workflows. If you call all three components “sales”, life can get confusing for you, especially if you find yourself in PowerShell. The easiest way to alleviate this is to add _Group or _Queue to the end of the name for these components. Users never see these names, so don’t worry about confusing them.

Great naming standards are always a win in my books, but do feel free to leave notes in the description field that provide more insight into the purpose of the group.

Participation Policy has two options, Formal and Informal:

  • Formal requires your agents to sign in and out of the Response Group. You do this via a web page and not just a button on a phone or in the client. I personally find this annoying. The lack of other Contact Center functionality in Response Groups makes Participation Policies somewhere i
  • Informal means there’s no login/logout required. You are essentially always logged in. This is the most common selection that I see.

Alert Time  is generally how long SfB will offer a call to the Agents before it’s passed back to the Queue. There are two timers in Response Groups, one at the Group level and one at the Queue level. Any decent conversation about these timers needs to include how the two timers work together for you (or against you, if you’re not careful) so more on timers in the upcoming post on Queues.

Routing Method is the pattern that the Response Group service user to select Agents to offer calls to. Your options are:

  • Longest Idle: The Agent who has been idle the longest, as long as their presence is Available or Inactive.
  • Parallel: The call is offered to all Agents whose presence is Available or Inactive.
  • Round Robin: The call is presented to each Agent based on the list of Agents, so long as they are Available or Inactive. The RG service keeps track of the last agent that was offered a call, and will start with the next agent for the next call. Over time, you will get a roughly equal distribution of calls, assuming your agents have similar presences statuses for similar amounts of time.
  • Serial: Similar to Round Robin, but follows the order of the agents as you have them in the Agent list, so long as that user is Available or Inactive. Unlike the Round Robin option, the RG service will start again at the top of the Agent list for the next call. This is a great way to prioritize your agents so that one person typically answers calls, but calls will immediately go to their backup(s) if they’re not available
  • Attendant: The RG service will offer the call to all agents, regardless of their presence (Save for DND and Offline). One key difference is that the calls will “stack up” in the Agent’s notification window, and they can cherry pick which call they answer. On the downside, agents will hear ringing and see toast for each call that is coming in. If you have a lot of calls stacking up, this gets really annoying. (Use Queue overflow settings to alleviate this)

Agents are last. We have a dropdown that allows you to build your own ordered list of agents, or select an existing AD distribution list. The distribution list can be a great option however there are a couple of gotchas:

  • The Response Group service is updated overnight through SfB maintenance processes. If you need to add an agent to a group faster, you can either fiddle with triggering updates manually or use the “customer group of agents” option instead.
  • The Response Group service can’t take advantage of nested groups. Only direct members of the group you select become agents.
  • Agents must be enabled for Enterprise Voice.

Gotchas to watch for when adding a user as an Agent to a Group in a different SfB Topology Site


  • An user in the same site as the pool hosting the Response Group will receive a banner on their client advising that they’ve been added to the Response Group as an Agent. A user outside of that site will not receive any notification that they’ve been added to a Group.
  • An Agent in one site cannot place calls on behalf of a response group in a different site.
  • When an agent hits their default logon/logout page via the client, it will only have Response Groups from their own site. They’ll need to manually bookmark the login/logout page for any other sites that host Response Groups that they are a member of.
  • You can leave a group without any agents defined, but you cannot use that group for anything. (Stay with me here, this applies in a more advanced call handling scenarios that I’ll get to later).

And that’s it for Groups. Next up will be a post on Queues, where all of the interesting stuff happens.



Main Number Handling: Solution Overview

In the first post in this series, I provided some basic guidance on how to plan for you main number scenarios. In this post, I’ll outline each of the technical options that you can use to address you main number requirements.

Your call handling functions include:

SfB Response Group Hunt Groups

Response Groups are a hunt group/IVR solution built into SfB on-prem. Response Groups have three components: groups, which are your users who will handle calls, queues that present the calls to groups, and a workflow that will play a greeting and send the call to a queue.

Workflows have options for business hours, holidays, music on hold, recorded or text-to-speech greetings. A call can be distributed to a queue, or based on work hours and holidays it can be disconnected (really? Who would ever do that?) or forwarded elsewhere.

Response Groups have some other features like Agent Anonymity so that you don’t reveal the name, SIP address, or number of the agent receiving or placing a call. A Response Group can be Formal or Informal. With Formal Response Groups, Agents must log in and out of the Response Group, whereas with informal Response Groups they’re always “logged in”.

You can also scope a Response Group to a manager, so that you can easily delegate all the fiddly settings like greetings and hours and group membership to an administrator.

Once the call is in a queue, there are a variety of timeout and overflow options. Within Groups, you can set the method used to pick which agent(s) is offered the call, and how long the call will ring before it’s sent back up to the queue for alternate handling.

SfB Response Group IVR

The Response Group type I described above is a Hunt Group, where an incoming call has only one destination queue. An IVR Response Group allows you to provide options to the caller, and route their call to a different queue based on their responses. This can be via keypress or speech recognition. You can also record that ubiquitous “Please listen carefully as our menu options have changed” greeting that everybody seems to have, regardless of how old their IVR structure is.

Response Groups are pretty versatile (and free) and are commonly used because of this. However, they’re not without their limitations. I’ll explore these more in a future post.

Exchange Auto-Attendants

Exchange Auto-Attendants aren’t an SfB feature, they’re a component of Exchange Unified Messaging. They’re available online or on-prem, and are fairly simple to configure. When an Auto Attendant is called, a greeting is played and the call can do things like an address book looking, enter an extension, or similar to the IVR Response Group, press keys or use voice recognition to play messages or reach destinations. You also get business hours and holidays, and can change behavior based on these.

Unlike Response Groups, there are no queues or groups in Auto Attendants, however the Auto Attendant doesn’t care what’s at the number that you forward a call too, so you could forward a call from an AutoAttendant to another AA, Response Group, user, or your annoying coworker’s mobile.

SfB Standalone/Phantom “user” or Common Area Phone

You could also chose to have a main number ring a regular phone or SfB client, typically one that isn’t assigned to a person. I’ve seen these called “Standalone” phones or “Phantom users”. This solution is common when your call volume is low, or when you have a rotation of people through a reception desk. The users can logon to the PC as themselves, and would have a phone on the desk for the main number. I have also seen organization load an Attendant console on a small form factor PC with a touch screen, and have this sit on the desk beside the regular office PC.

You can use a standard SfB user for this, or a Common Area Phone. Using a SfB user consumes a license, where a CAP does not. However, CAPs are not yet available in SfB Online, and cannot offer voicemail.

SfB Team Ring or Delegation

When a standalone phone or phantom user proves too limiting, such as when there isn’t a reception desk or you need a ring a group of people, you can use Team Ring or Delegation.

Team Ring allows one user – your phantom user – to have their calls ring on their teammates SfB clients or phones after some delay (0-15 seconds). They’ll get a unique ring/toast so they can identify that the call isn’t to their individual number.

Team Ring and Delegation are very similar, with one key difference. With Team Ring, you can only answer calls on behalf of the phantom user. With Delegation, you can receive and place calls on behalf of the phantom user.

This is a popular, free (other than the SfB license for the phantom user), self-serve option, but it’s not a scalable solution.

SfB Simultaneous Ring

A similar option to Team Ring is to use the Simultaneous Ring feature. However, Simring only allows you to assign one destination user or phone number, so you can’t alert multiple people for an incoming call. This option is useful for a single user or phantom user, when the person who would normally answer the call is away from their desk – an admin person making some photocopies, or a security officer doing a patrol. They can setup simring to a mobile or cordless phone, and wander away from their desk while being able to answer the phone. Note that options for call transfers are limited in this scenario.

They could also simring a coworker who is staying at their desk, who would have the usual SfB call transfer options.

Call Pickup

Call pickup is a relatively new option in the SfB world. The idea is that when your phone is ringing, your coworkers can enter a code on their phone to pickup your call. This was a popular function in traditional PBX environments that didn’t have things like delegation or team ring. Call pickup is a bit of a pain to administer. Frankly, I get the feeling that this feature was added to SfB to satisfy a large customer, or to gain another point or two when organizations are scoring RFP responses.

Shared Line Appearance

A Shared Line Appearance is another legacy PBX features that has crept into the SfB world, at least partially. The idea here is that you would have a button (or two or three) on your phone that would be a duplicate of the line on another phone. Think of an admin who can have buttons on their phone for the main number, the bosses’ number, and maybe a coworker. They can hit this button to answer the other line(s) when they ring. In most legacy PBXs, the button also offered a busy light, and could either act as a speed dial to call that person, or a “place call on behalf of” function. In SfB, this functionality is limited at present to just Polycom VVX phones, it’s not available on other phones or the SfB clients. The button also doesn’t do anything other than answer the call.

I’ve seen limited uptake of this feature, and again I suspect it’s to provide some level of comfort to a large SfB customer or for RFP scoring. There are better, less limited ways to handle most scenarios where SLA is mentioned.

Coming soon to the SfB offerings are Cloud PBX Organization Auto Attendant and Cloud PBX Call Queues. These are meant to offer functionality similar to SfB Response Groups in Online deployments, and to eliminate the need for the Exchange UM role for Auto Attendant functionality. These features are currently in preview, and I’m hopeful that they’ll be released soon so that I can provide more concrete details.

AudioCodes Auto Attendant

AudioCodes offers an application that they call AutoAttendant, though it’s more like the Response Group than Exchange Auto Auto attendant. There are no directory lookups, but there are decent options for queueing and IVR handling of calls.

Full-blown Contact Center

If these solutions don’t meet your requirement, you may need to look at a full blown contact center solution like Computer Talk ICE, Clarify Connect, or Enghouse’s offerings. This isn’t as daunting of a concept as it once was. You no longer need to deploy one or more servers and installing software. Most call centre software is now available in the cloud as a service, with functionality and pricing on a per-user, per-month basis.

Next up…

In the next several posts, I’ll provide more in-depth details on each of the items above. If I’ve missed your favorite main number handling option, hit me up in the comments!

Main Number Handling

A topic in every SfB deployment I’m involved in is main number handling, and rightly so. Callers to your organization deserve a first class experience, and that experience needs to also meet your organizations objectives. For example, do you want a caller to first reach a live receptionist and only overflow to an auto attendant, or are your calls best handled by an automated system?

Over the next several posts, I’ll review the organization characteristics and requirements for main numbers, and the features in SfB for main number handling. I’ll then dive deeper into each feature to show how they work and what the benefits and drawbacks of each may be. I’ll then outline how the features can “snap together” to provide a more detailed solution, and give some real-world examples that I’ve seen.

30,000 Feet

A main number is any phone number that reaches your organization, but isn’t assigned to any one particular person or phone. A regular user, Common Area Phone, subscriber access, and conference room phone aren’t main numbers. Main numbers are things like reception, help desks or support lines, team phone numbers, or even things like enterphones/door buzzers.

The beginning is a very good place to start

Jumping in to the technical features of SfB is a terrible place to start this process. Your technology products need to address your business issues, so let’s start with business processes and people.

If you’re migration to SfB from another system

A migration means that you’re already handling your main numbers in some fashion. Document how the number is currently being handled. Review what you’ve documented with the users that are involved with handling calls to the number. This includes anyone who might answer the phone, but also those who receive calls from an Auto-Attendant, for example. Your goal here is ensure that you have accurately and completely captured how things are working today (and not necessarily how they’ll work in SfB)

  • If you’ve identified phone numbers, voicemail boxes, departments, recordings or greetings that you don’t know anything about, you will need to ask around. Call those unknown numbers, leave voicemails in those odd looking voice mailboxes and ask people to call you back. I’ve seen one organization that just couldn’t track these down set up bounty-hunter prizes for staff members who solved the mystery of the unknown number. (Some people will do anything for a Starbucks gift card!)
  • During this process, be sure to ask stakeholders about any toll-free numbers that might be involved. Typically, a toll-free number is delivered to a regular number at your organization. Make sure you don’t disconnect the regular number, or port it away to a different carrier without also bringing the toll-free number.

Next, review what you’ve discovered and documented. Your current system might be decades old, and may have grown organically and uncontrollably since then. Ask those involved if they like how it functions, or if they’d like to see any changes made. Draw up a new plan based on their input, as if you were deploying a new number – which brings us to the next section…

If you’re deploying a new main number

A net-new number can be easier or more difficult that a migration. It can be easier because there isn’t any legacy baggage of “we’ve always done it this way”. It can be more difficult because sometime people don’t know enough to provide useful input.

Meet with those involved in handling calls to the main number, or receiving calls from it. Establish what their requirements are, and how they would like to see the system work. Again, stay away from technical features – focus on what people want and what the business needs. Draw up the new plan, and review it with those involved.

Designing and Documenting

Whether you’re migrating or deploying net-new, don’t aim for one rigid plan that you’re now going to try to implement in SfB. Instead, capture ideas and concepts like “if reception doesn’t answer within a couple of rings they might be busy, so also ring accounting, then if nobody answers after 30 seconds, go to voicemail”. Whiteboards, post-it notes, and the Office Lens app on your smartphone are your friends here.

You may wind up with multiple plans or ideas for handling some numbers. That’s fine, and maybe even useful as you being to map those requirements to features available.

Mapping Requirements to Technical Features

Now that you have a handle on your current deployment and what the desired functionality is, you can being to examine the technical options for implementing that functionality. As you progress, you may need to rework your desired functionality because of technical limitations, or new ideas that arise when you map your desired functionality to the technical options available. If you have multiple possible plans or ideas for a number,

In the next post, I’ll jump into an overview of the (many!) options within SfB. Stay tuned!

Patching Without an Internet Connection

In some organizations, allowing servers to have direct access to the Internet isn’t permitted. Or, it could be you have an isolated lab and need to patch your machines. WSUS is great, but not always possible to implement.

There are a couple of utilities available that help with this. The first is quite excellent,

The second one I haven’t personally used

Either of these tools should get you patched, without needing to worry about Internet connectivity from your machines.


FXO vs FXS in Skype for Business

Analog trunks and devices are less and less of a factor in many of the projects that I work on. Areas where I still see analog are branch office trunks, faxes, door buzzers/enterphones, paging systems, and ring-down phones that you might see in a parking lot to contact security or a cab company.

To integrate analog trunks or devices with SfB, you connect them to a gateway. The gateway can come with two types of ports: FXO, and FXS. FXO is an abbreviation for Foreign eXchange Office, and FXS for Foreign eXchange Subscriber.

So, clear as mud and we’re done here, right? If you’re an old school telecom guy, you know there’s a lot of complexity hidden behind that simple jack in the wall. The good news is for nearly all SfB use cases we can boil things down so they’re very simple.

FXO is a port that you plug a telco trunk line into. FXS is a port that you plug your phone or other device into. Mostly. Confusion pops into the picture when you have paging systems or enterphones, which may oddly use the opposite interface than you’re expecting, or give you the option for both.

You can think of FXO and FXS as North and South on a magnet, or male and female, or whatever pairing you’d like. A FXO device plugs into an FXS device, and all is well, like this:

Your phone, which has an FXO jack on it, plugs into the wall, which is an FXS interface.

Your phone, which has an FXO jack on it, plugs into the AudioCodes MP-118 gateway FXS port.

The AudioCodes MP-114 gateway FXO jack plugs into the wall, which is an FXS interface.


MP114 back

An AudioCodes MP-114 gateway. From the left are power, Ethernet, RS-232 serial console, two FXS ports and two FXO ports.

Great, so why then would a paging system offer both FXO and FXS interfaces? The answer is that there are two different use cases for the paging system.

One use case is a standalone, where a phone plugs directly into the paging system. You pick up the phone, maybe enter some digits to indicate what zone to page, and you talk away. The paging system is acting as a PBX in this scenario.

The second use case is PBX integrated, where the paging system acts as a phone. You dial the extension for the paging system, it rings and then answers, you maybe enter some digits to indicate what zone to page, and you talk away.

These two use cases also apply to things like enterphones or gate/door buzzers. You can have a phone plugged directly into the enterphone, or you have have the enterphone act as an extension on your PBX.

The standalone option is simple, but restricts you to interacting via a single phone. The PBX integrated option is more complex, but allows you to interact via any phone on the PBX.

Caution: “interact via any phone on the PBX” in the SfB world means that in a global deployment, you could have a prankster user in New York telling jokes over a paging system in Paris. Configure your dial plans appropriately if your paging system doesn’t offer PIN functionality!

If you have a choice between using an FXO port or FXS port on a gateway to integrate with an analog device that offers both, I recommend you pick the FXO port. This has the device act as a PBX, which means that there is no ringing when you call it, and call setup is faster. Disconnects are usually quicker too, which is important if the paging system or enterphone is used a lot.

When you configure the device to plug into an FXO port on the gateway, set the gateway to route calls to that number out via the FXO port you’ve connected it to. If the device will be sending calls to the gateway, set the gateway to

You’ll need to use an FXS port on your device to connect to the gateway’s FXO port. If your device has one port that’s switchable between FXO and FXS, read the manual carefully – I’ve seen some that aren’t clear whether they mean FXO mode is “setting this device to FXO” or “setting this device to talk to FXO”. If it’s really unclear, plug a boring analog phone in. If the line is dead, the device is set to act as an FXS device and the port is configured as an FXO interface.

Do you need a voice VLAN?

I’ve had three conversations in the past week or so around whether a voice VLAN is required or recommended for use with Skype for Business. Let’s take a quick look at where the concept of voice VLANs came from, what they can do for you, and whether you need them for your SfB deployment.

The idea of a voice VLAN first came about when the only IP endpoint for you IP PBX was a phone on their desk. The phones generally needed a specific DHCP configuration, and if the phones were in their own VLAN this was easier to do. QoS was implemented as 802.1p at the layer 2 (switch) level, and it was much easier to simply say “this voice VLAN gets a priority of 5”. Some switches would use Cisco Discovery Protocol (CDP) or Link-Layer Discovery Protocol (LLDP) to automatically put a device that said it was a phone into the voice VLAN. Much of this early IP telephony was done with voice guys coming from a traditional TDM PBX environment. The world of IP was new to them, so anything that made their lives easier and more automatic was welcomed by not only the voice guys, but also by any IT guys who had to work with them.

Raise your hand if you ever had to explain IP subnetting to your voice guys new to IP, and try to sort out for them why the IP telephone system vendor was blabbering on about Class A subnet masks and VLAN 0. Thankfully for me, my voice guys were smarter than your average bear and quickly picked up some good habits vs the drivel in the phone vendor manuals. (Thanks Brian and Willy!)

The curious thing is that at no point did anything actually require a voice VLAN. They just made life a lot easier and more “automagic”. You could deploy a perfectly good VoIP solution without using voice VLANs.

Fast forward to today, when we talk about Unified Communications instead of IP telephony. We now have soft clients, room systems, and mobile clients. In additional to voice, we have modalities like video, web conferencing and screen sharing, all from the same client. We’ve also got BYOD and Cloud technologies to add excitement to the mix.

Having your desk phones into a voice VLAN doesn’t provide any benefit to you when you’re conferencing from a PC, or watching a PowerPoint on your iPhone in the lunchroom while you wait for the coffee to finish brewing. A good number of your users might not even have a desk phone, opting instead for a headset and soft client.

One scenario where a voice VLAN does make some sense, is when you’re doing a large-scale deployment and the number of phones you are adding outstrips the number of available IP addresses on your existing subnets. In this case, it may make sense to create a new VLAN for the phones. I say “may” as you might also have a requirement to use IP subnets for location determination for emergency calling. Overlaying a single voice VLAN to cover your site may not be suitable – you may have to deploy multiple voice VLANs to provide the location granularity required. It may make more sense to simply further partition your network into general purpose user VLANs.

Do I recommend voice VLANs? No. I think they’re a thing of the past. They add complexity to your network, increase your administration, and affect only a very small number of your UC endpoints. For those endpoints that they do affect, they do not offer any benefits that can be provided via other means, and often those other means will need to be in place for other endpoint types and other modalities.

Bad Checksum in Packet Captures

I was working with a carrier to identity some SIP trunk issues recently, and they requested a packet capture of the traffic leaving our Mediation servers. I sent the capture over, and they quickly came back with a question: Why are all of the packets marked as “Bad Checksum” in NetMon.


As it turns out, this isn’t anywhere near the disaster that the carrier thought it was. If we open the same capture in Wireshark, we can see that Checksum validation is disabled.


This is expected when you are running your packet capture on a host that is generating or receiving the traffic you’re interested in (versus setting up a span port on a switch and mirroring traffic to a dedication packet capture machine). The reason? The packet capture takes place within the network driver stack, while checksums are almost always offloaded to hardware. For outgoing traffic, the packet is captured before the checksum is calculated, and there is no valid checksum available to include in the packet capture.

Here’s handy diagram courtesy of that shows the network stack and where the Packet Capture and Checksum take place. (Red arrows and boxes)

First with Offloading:


Packet capture with Offloading

And now without Offloading:


Packet capture without Offloading


If you’re not capturing packets to detect and correct malformed packets, this shouldn’t be of concern to you. If you need checksums, you have two options. One is to select your network adaptor, choose Properties, and on the Advanced tab, find all of the “Checksum Offload” properties and set them to Disabled (don’t do this). The other use a span port on a switch to mirror traffic to a dedicated capture PC (do this instead). Setting Checksum Offload to disable means you will take a performance hit, as you are no longer using the hardware on the NIC to perform these calculations. If you absolutely cannot do a span port, disable Checksum Offload with caution and be sure to re-enable it immediately after you’re done.


Happy packet capturing!