Subscriber Calling Self

[calmichael]

In client acceptance testing between Unity 2.4.6 and<br>CallManager 3.0.9, a test was performed that had a<br>subscriber dialing the main greeting internally, and<br>then performing a dialed transfer, or transfer by name to<br>themselves and it appears to flashes the second line as<br>coming from Unity, but then joins the two lines.<br><br>I know this shouldn't happen in production, but what is<br>causing this to happen?<br><br>The client thought that it should see the call as busy and<br>forward to voicemail - but it doesn't. . .<br><br>--- Thanks ---<br><br>

[#2]

There seem to be a lot of things that shouldn't happen in production that do : )

Is Unity transferring to the exact extension that they called from?

Sounds like they have the first call appearance on the phone forwarded on busy to the second call appearance on the same phone. What happens when they have one person call the first line appearance on the phone in question and then have a second person call the first line appearance on the phone in question. Does it ring the second line?

Even if Unity "knows" a subscriber is in the voice mail system (determined by that subscriber signing in at the login prompt), that will not prevent Unity from attempting to transfer other calls to that subscriber.

[calmichael]

The way the user is setup in CallManager 3.0.9

It is a 7940 phone with a single line appearance.

Call Waiting is set to default (on).
Call No Answer is set to go the Unity pilot number.
Call Busy is set to go to the Unity pilot number.

In your suggested testing situation, when we tied
up the first line, and then with the "new call"
under the first line went to Unity, we were able
to get the call to go into voice mail as expected.

However, it was interesting that when calling from
the second call from the first line appearance that
Unity challenged with enter your ID then PIN prompt
instead of recognizing the extension we were calling
from. Why is this? because if I dial another extension
I see the calling party information as if it was the
line appearance.

A fellow engineer suggested that when the first call
is on hold, that the stream is now being serviced by
a MTP, and the second call is not free to use the
line appearance normally. Is that causing issue with
Unity in this odd scenario?

--- Thanks ---

[#4]

The behavior you previously described is due to the fact that the extension has call waiting enabled. For auto-attendent transfers out of Unity, call waiting must be disabled. I believe this fact is metioned in the Call Manager Integration guide for Unity.

[#5]

Just an FYI, my last to posts were posted in reverse order.

[#6]

My last post wasn't entirely fair! The CallManager integration guide makes no mention of turning off call waiting for subscriber's extensions. The CallManager section of the Unity Integration guide does mention to turn off call waiting for the voice messaging ports.

Now, I am not exactly following how the test was ran. I am probably just mistunderstanding this, but with the extension that has call waiting enabled, you tied up its line (by calling it from another phone, I suppose), then a second call was placed to the same extension that has call waiting enabled. At that point, the call waiting did not kick in? The call forwarded to Unity? That's how I was reading that last post.

What is the transfer type that Unity is using to this extension?

[calmichael]

Unity subscriber has a 7940 with a single line appearance
of extension 43210 that has Call Waiting set to On.

He dials the Unity pilot number with the 7940 - 42000.
The Unity handler allows him to select an extension,
he enters his own - 43210.

The expected result is that he could accept or ignore
the call coming in on his Call Waiting, and if he ignored
it, it would go to voice mail. I understand that some
cellular voice mail systems work in a similar fashion for
user voice mail access, which why this was in the test -
acceptance plan.

The actual result is that for a brief second, use see
on the 7940 display that Unity (Pilot Number) is calling,
but immediatly disappears with the hold tones being played
for him.

Unity Port Monitor continues to display that he is in
a call handler until he hangs up.

Test #2, inspired by a forum reply, had us initiate
a call to tie up line one from a different extension,
and then using the Hold - New Call, try the same thing.

The expected result being the same as stated above,
but since Call Waiting would be busy, the call should end
in the subscriber's voice mail.

The actual result is that he did get to Unity, but the
subscriber heard the main greeting, and not the subscribers
voice mail box.

We verified that the "Hold - New Call" was sending caller
information by calling another 7940 and seeing correct
information showing up.

The call handlers are setup to transfer blind - not
supervised. We did try supervised as a test, and this
had no effect on the result.

--- Thanks ---

[#8]

Aha! Very good information here. The symptoms that you are describing really sound like an invalid transfer attempt from Unity. There are a couple of indicators that reveal invalid transfer attempts. You mentioned that the caller heared the hold tones on a release transfer. That's a problem. If the release transfer is successful, the caller should hear ring-back. Even more distinguishing is the fact that you mentioned the Status Monitor shows the transferring Unity port still active after the release transfer has been attempted. And the real smoking gun...the fact that the transferring Unity port does not go idle in the Status Monitor until the caller hangs up.

Now the question is why is this an invalid transfer attempt. There are many reasons why transfers can be invalid. By "invalid" I mean that the Unity transferring port is doing something that CallManager does not like. There are many ways that this can happen, but with a valid configuration like the one you have, timing is most likely the issue.

Now that I really understand what is going on (sorry, it took so long) I am going to try to duplicate here in my office with some debugs on. Give me a while and I will send another post out on the results.

[#9]

I did some testing here and found out some more information. I think what the customer wants to happen based off of their compliance test is going to work, I think the test could be changed to more accurately simulate a production environment. I know that sounds a little lame, but hear me out...

TEST1:
Just like their compliance test, I have a 7960 with a single line that has call waiting enabled. The phone is set to forward to the Unity pilot for both busy and no-answer. My Unity transfer type is release. If I call the Unity pilot from the 7960 and transfer to myself, I get the same results you did. I can go into the reasons why that happens, but it is really out of the scope of this forum. I can say that it has nothing to do with MTPs. Is this really how transfers and call waiting are going to interact in a production environment?

TEST2:
I ran another test. With my 7960, I tied up the line by calling Unity and just sitting there listening to the polite lady ask for my password. Then, from another IP phone, I called Unity, and then transferred to the 7960. The transferring Unity port shows on the 7960 very quickly and then transitions to the extension number of the second phone I used to call into Unity (that would be expected). At this time on the 7960, I can take the call waiting call, or listen to the Unity lady insist I enter in my password. If I do not take the call from the IP phone, it will forward to Unity and I hear the correct greeting of the 7960 phone.

Did TEST2 more accurately represent how auto-attendant transfers and call waiting interact in their environment? Did it produce the results that the customer expects?

I am making some assumptions here, but I think TEST2 at least gets closer to how auto-attendant transfers to phones that have call waiting enabled will show up in a production environment. See if you can run TEST2 and get the results that I did. Let me know what you think.

[calmichael]

The sceanrio that is Test 1 reflects what the client
performed as part of their acceptance testing of the
Unity product.

The client admits that this situation in Test 1 will
probably not happen in production, but they want to
understand why the predicted result did not happen.
This is not a show stopper - but it is something that
the client would like an explanation for.

What is happening to the call in Test 1?

Regarding Test 2, this is probably how production
would work in that situation.

--- Thanks ---

[#11]

You can simulate the exact same behaivor with two IP phones. From IP phone A (that has call waiting enabled) call IP phone B. On IP phone B, press the transfer key, dial IP phone A's extension, press the transfer key again, and then hang up.

IP phone A is going to hear dial-tone and the call that did the transfer has an indication "From [IP phone B's extension]" showing in the display. The options at the bottom of the phone are "Hold" "Resume" and "New Call".

They saw that behavior with the transfer because when Unity transfers, it hits the transfer key, dials the extension, hits the transfer key again, and then hangs up. Unity totally bails at that point, that's the point of the release transfer.

Since Unity is not a 7960 phone, it doesn't get all the options that a 7960 gets. CCM does send messages that something is a little wacky with the transfer, but it's not enough information for Unity to make decisions about handling the call.

If the site wants this to work in TEST1, it'll probably go in as a feature request.