Unity Not Sending to Correct Announcement

[tdodenhoff]

We have a "call handler" (actually an x port station in an Avaya PBX) that answers calls for a main number. When the caller gets into the greeting, they can enter an extension. Unity transfers to the right extension, but if the person isn't there sometimes it will prompt the caller for a password, sometimes it will go to the default Unity Opening greeting - sometimes it will work fine. Anyone experience this? if so, how do I fix this thing?

[eschulz]

The first step might be to narrow down what conditions result in which behavior. You'll need to play around with it a bit but here are my guesses that might at least give you some ideas on what to look for...

1. calls go to the correct greeting if the target subscriber is configured for supervised transfers

2. release transfers are being forwarded back to Unity but are not showing up as forwarded calls or do not have a valid forwarding number (check the Call Viewer and/or Integration Monitor)

2a. calls go to the Sub Sign-in prompt if the calling number matches a subscriber

2b. calls go to the opening greeting if calling number is not present or does not match a subscriber

Regards,

Eric

[tdodenhoff]

Thanks, but I'm not sure if this will help. I'll still try it, though. Here's the issue from the Call Viewer...

- All calls go through a main number - let's say 610 555 5555.

- That number gets forwarded to an X port station in the PBX (1500) which covers to voicemail - which is a subscriber that plays a duplicate of the Opening greeting (customized by us).

- when someone enters an extension, it works sometimes. when it fails, the call viewer shows it as an external call. when it succeeds it shows as internal.

why does it qualify the same call different ways?

[eschulz]

'internal' or 'external' won't directly impact how Unity routes the call. That field is populated as a 'best guess' based on call info presented from the PBX. What you should look for is whether the call shows up as 'direct' or 'forwarded' and what numbers, if any, show up for the calling, called and forwarding extensions.

Let us know what you find with respect to supervised versus release transfers. Also, you stated that the fail occurs when the extension rings after no answer. It wouldn't suprise me if you see a slightly different behavior with a forward on busy.

BTW, is your PBX using in-band DTMF (mode codes) or a PBXLink (smdi) to send call info to Unity?

[tdodenhoff]

Calls that fail are coming as "External","Direct", Trunk ID "-1". Internal/Direct calls work fine. No numbers show as calling or dialed or forwarding. Transfers are done as "release to switch" and are not supervised. I have not been able to ascertain forward busies as not working correctly, although my hunch is that they are just fine.

To the best of my knowledge, we are using the PBXLink box to pass info, however, we were told to be mode code enabled. So I'm not sure what your question is. The PBXLink uses a single digital line for passing info. Perhaps we should have 2?

[eschulz]

Ok, I think "External","Direct", Trunk ID "-1" are the default values that'll show up in the call viewer when no info is recieved from the PBX. If you check Integration monitor, I suspect you won't find an SMDI packet for this call, or the packet does not contain any extension numbers.

One common cause of 'no call info' with smdi is that the port numbers do not match up with the smdi packets. For example, the PBXLink thinks see a call going to what it thinks is port 2, so it sends a smdi packet marked for port 2. However, the physical line is actually connected to port 4 on Unity. Thus Unity does not associated the incoming packet with the incoming call. This type of problem can be resolved by shuffling the lines connected to Unity.