Call Manager and Alternate External Extensions?

[smburke]

We have a unity 3.1.5UM system connected to Call Manager 3.1.3a SP3.

If I set alternate extensions for a unity subscriber, any internal alternate extensions work correctly, but external ones, such as a cell phone number do not. The call manager is getting the correct caller ID, as shown on both the IP phone and in the CDR's, but Unity does not appear to be receiving the caller id from the external number. Is there anything special that needs to be configured on either the unity side or the CM side to enable this?

[kechambe]

Can you check Call Viewer to see what it is seeing for Caller ID? You can open it from Start > Programs > Unity.

Thanks,

Keith

[smburke]

The calling number is showing as the cell number, which has been added as an alternate extension. The forwarding station is my cm extension. Under reason, FWD(Unconditional) is listed.

[smburke]

I semi fixed it. Unity doesn't have an "attempt sign-in" by default in the Forwarded calls call routing section. Adding that and pushing it ahead of the greeting gives me the auto sign-on, but then if I call anyone's voicemail from my alternate extension, I go right to sign-on for my mailbox instead of their greeting.

[lindborg]

That's not a fix and is a really bad idea... as you noted, you actually broke forward to greeting for everyone. The "attempt sign in" is not in the forwarding routing rules for a reason and you just discovered it.

You really need to figure out why we're not getting the information you expect on the incoming call. You can beat Unity to death's doorstep, but until you get that working correctly, this will never fly right.

[smburke]

Unity appears to be getting the right information. There just doesn't seem to be a 'route' in place to allow a cell call to go to sign-in.

The only way I can think of to make this work without a forwarded call route would be to assign a DID to EACH voicemail port extension so that when you call unity, you're making a direct call instead of a call that's forwarded from your original phone extension.

Please correct me if I'm wrong in these assumptions.

[smburke]

Ok. . correct me if I'm wrong, but based on how Unity seems to work, the only way to make alternate extensions work with external phone calls is to do the following:

Either assign DID's to all of the unity ports, or dedicate a small number of ports to outside voicemail access and assign them DID's. That's the only way that Unity will see the inbound calls from the outside as "Direct" and as such, process them through the routing rules that include the sign-on option.

[lindborg]

A DID number to call into voice mail would be the normal way to do this, yes...

[smburke]

What I'm getting at is that the DID has to be applied DIRECTLY to the Unity port or ports. On most CM installations, the VM ports use non DID extensions for the voicemail ports and then a CTI route point or other reflector to reflect a DID into the voicemail system. Based on the way I seem to see Unity handling inbound calls and alternate extensions. the route point method won't work as Unity sees the inbound call through the route point as a forwarded call, rather than a direct call.

This, of course, brings up the next question (which I can't test at the moment due to not being in the office). If you have a couple of Unity ports with DID's to handle this, won't any calls that roll over to the 2nd, 3rd, etc. unity port not be handled as direct calls because they've been forwarded from the first DID number due to it being busy?

If there's any documentation on this somewhere, please feel free to direct me. The unity install and admin guides don't seem to go into tremendously specific detail about this type of thing.

[oliviers · Accepted solution]

You could think of it this way: make the forwarding numbers on these calls show up as the DNs of any of Unity port DNs.

Skinny call information can provide call reason (direct, forwarded), and it can provide called and calling parties. The way that Unity uses the skinny call information to determine "call reason" depends upon the called (aka, forwarded) party.

This is a good question, "If you have a couple of Unity ports with DID's to handle this, won't any calls that roll over to the 2nd, 3rd, etc. unity port not be handled as direct calls because they've been forwarded from the first DID number due to it being busy"

You would expect to see the same problem with simple, internal calls. For instance, if the first port is busy taking a call, and a subscriber uses their "messages" button (programmed to call the first port of Unity) to retrieve messages, the call will forward from the first port to the next available port. Won't the call be a forwarded call? From the skinny point of view yes, but from the Unity point of view, no. Why? Because Unity (the TSP, really) knows it's own DN numbers. It asks for them after registering with CCM and remembers them.

The TSP has logic like this: if a forwarded call (from the skinny point of view) comes in AND the forwarding number (called number, whatever you want to call it) matches a DN of one of Unity's own ports, it's really a direct call, not a forwarded call. That will handle the situation where the first Unity port is busy , and a subsequent call fowards from that first port to another.

If a forwarded call (from the skinny point of view) comes in, and the forwarding number does NOT match the DN of any Unity port, the call remains as "forwarded" in Unity's eyes.

To make a long story short... On the calls from these cell phones, the alternate extension stuff isn't quite enough, but you will need it to translate the calling party. If you can make the fowarding number show up as one of the DNs of the Unity ports, this should work as expected.

This changing of the forwarded number can be handled most likely at the GW, CCM and at Unity. But it's probably easier to do it at CCM. Does that make sense?

[cfortanb]

Why would you use a CTI route point to do this? Why not choose a single DID extension, and assign that as the first port in the voicemail system. Subsequent ports can be internal ports. It would elimintate the added step of using a CTI route point. MOST VM installations I have seen are done THIS way.

[smburke]

I'll try that configuration and see how it works.

FYI, the reason we use the route point is that it gives us more flexibility if/when we need to change the DID extension. It's much 'cleaner' to just change the route point than to have to change the first voicemail port number, along with ALL of the extensions in the system to point to a new DID.

[smburke]

Thanks for all the help guys. I set up a DID on the last unity port, which then rolls to the first when it's busy, thus eliminating the need to change the forward on busy/no answer on all of the phones.