Normally I talk about overlays in the context of data center/SDN/cloud but today I'm going out into left field and am going to talk about voice! :-)

I freely admit that I'm a noob when it comes to Cisco voice so I'm not sure if the behavior I'm about to describe is obvious or not. It wasn't obvious to me and I only figured it out after running into the issue for real and troubleshooting it to resolution.

The issue stems from my misunderstanding about how dual-line ephone-dns function when used in an overlay.

The Desired Behavior

Here's the scenario: Cisco Communications Manager Express (CME) with a handful of IP phones registered to it. There's no Communications Manager (UCM); the dial plan lives entirely within CME. PSTN connectivity is via (4) POTS lines terminated on FXO ports on the router running CME.

The desired behavior is to have incoming calls from the PSTN ring on all the IP phones simultaneously. If a second call comes in, it should ring on all the remaining phones, and so on.

The Original CME Config

Here's what the original CME config looked like. At least, the parts of the config relevant to this blog post.

ephone-dn  149  dual-line
  number 6000
  preference 1

ephone-dn  150  dual-line
  number 6000
  no huntstop

ephone 1
  button  1:295 2c150,149

ephone 2
  button  1:293 2c150,149

Incoming calls from the PSTN are PLAR'd to extension 6000. Extension 6000 is represented by the two ephone-dns shown above. Those DNs in turn are assigned to ephones as overlays with call waiting (ie, the "c" on button 2). DN 150 has a better preference than 149 so it will be the first one that's rung. If someone has already picked up a call that rang on DN 150, it's configured to hunt to another DN that matched extension 6000 (the "no huntstop" line).

Look sane?

The Problem

Here's what happens with the configuration above.

  1. A call comes in from the PSTN and gets PLAR'd to extension 6000
  2. There are two DNs for extension 6000. DN 150 has the better preference so it's selected.
  3. DN 150 is configured on both ephone 1 and 2. The call rings on both phones.
  4. Let's say the person using ephone 2 picks up the call and starts chatting with the caller.

So far so good; it's doing exactly as we want. Here's where we see the misbehavior.

  1. A second call comes in from the PSTN while the first call is still connected.
  2. Again, it gets PLAR'd to 6000

Now, which DN will ring? DN 150 has the better preference but there's already a call connected on that DN. It's configured to hunt for another DN that matches 6000 ("no huntstop") if DN 150 is busy so maybe DN 149 will ring?

Here's what happens: DN 150 is matched because of its better preference. Since it's a dual-line DN, the second call actually rings on the second channel of the DN. However since there's already an active call connected on DN 150, when the second channel is rung, it only rings on the phone where that first call is connected. In this case, the only phone that rings is ephone 2.

Obviously this isn't our desired behavior and it's also really annoying! If you're on the phone with someone you don't want the next call to only ring on your phone. Now you have to juggle both calls even if the person right next to you isn't busy and would be able to answer that second call.

The Solution

How do we get the second incoming call to hunt to the next DN and skip past the second channel on the already-in-use DN? We tell CME not to hunt to the next channel with the command below:

ephone-dn  150  dual-line
  number 6000
  no huntstop
  huntstop channel

Now when CME handles an incoming call it will not hunt to the next channel (huntstop channel) and it will hunt to the next DN that matches 6000 (no huntstop).

My original logic with the DNs was that since there's (4) incoming POTS lines, I should only need (2) dual-line DNs (4 channels total for 4 lines). Now that I know that's incorrect, I realize that I really need (4) DNs. So the complete solution is to add two more DNs, configure the proper huntstop and preference parameters on each, and assign all 4 to the second button on the ephones.

ephone-dn  147  dual-line
  number 6000
  preference 3
  no huntstop
  huntstop channel

ephone-dn  148  dual-line
  number 6000
  preference 2
  no huntstop
  huntstop channel

ephone-dn  149  dual-line
  number 6000
  preference 1
  no huntstop
  huntstop channel

ephone-dn  150  dual-line
  number 6000
  no huntstop
  huntstop channel

ephone 1
  button  1:295 2c150,149,148,147

ephone 2
  button  1:293 2c150,149,148,147

Now everything is working exactly as desired. Multiple incoming calls ring on all the ephones.

A logical question would be, if we're telling CME not to use the second channel, why have a dual-line DN at all? We could change all four DNs to be single line and not have to configure "huntstop channel".

Well, there's good reason to actually have dual-line DNs. The second channel is used if, for example, someone is having a conversation on the line and they decide they want to conference in a third party or they want to do a consultative transfer. Both of those features require the use of the second channel. So for that reason, I left the DNs as dual-line for the convenience/usefullness to the users, and went with the "huntstop channel" configuration.

Closing

There we go. A tricky issue to solve but now that I've done it I understand overlays on CME a lot more. I don't think these kinds of overlays are as fun as the data center kind, but it always feels good to fix something and learn new things along the way :-)

For reference: the description of the "huntstop" command on CME at cisco.com.


Disclaimer: The opinions and information expressed in this blog article are my own and not necessarily those of Cisco Systems.