Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Externall call recalls on blind transfer through IP networking

Status
Not open for further replies.

V3RTechNP

Technical User
Oct 18, 2011
84
CA
Hi!

Most often than not, we manage to solve our problems by ourselves but this one is left unresolved to this day and Mitel Tech Support has yet to find a solution as well. It's occuring since we upgraded both systems of a customer from 7.1 UR2 on 3300 LX to MCD 4.2 SP2 on 3300 MXe III 3 weeks ago.

There are 2 different scenarios; one of these can be reproduced 100% of the time on the customer's systems (but not on our office's systems or on our lab equipment nor at Mitel's with the same software release).

-Setup-
Two MCD 4.2 SP2 shared in a cluster with resiliency and everything.
Both have a PRI (T1) from the same provider.
Both sites are within the same city over a private fiber network.
Nupoint Messaging server standalone configured for System A with MiTAI MWI.

-Problem #1 (can be reproduced every time)-
1) Incoming call from PRI on System A or B.
2) System speedcall sends call to single line phantom key on IP Phone on System A.
3) IP Phone is call forwarded always to NuPoint Voicemail Hunt Group located on System A.
4) Call is processed inside NuPoint through a call director with a menu.
5) Caller dials 1 which is a Blind Transfer to ACD Path on System B.
6A) IF agent on System B with IP Phone on System B is logged in and available, phone rings half a sec. and then call recalls to NuPoint Voicemail default greeting. Caller hears MoH before getting VM greeting.
6B) IF all agents are busy on a call, it recalls to VM.
6C) IF all agents are logged off, call is processed correctly via overflow.

If we route the call via System A's embedded VM instead of NuPoint, we get the same problem.
If we route the call via System B's embedded VM instead of NuPoint, it works fine.
If we route the call via any phone on System A and do a manual Blind Transfer, we get the same problem.
If we route the call via any phone on System B and do a manual Blind Transfer, it works fine.
If we do an internal call from anywhere to anywhere and Blind Transfer to ACD Path anywhere, it works fine.
Basically, the problem occurs only with external calls transferred between PBXes -- and not all calls.
But with any of the above, if we blind transfer the call to a nametag hunt group on System B call forwarded always to ACD Path on System B, it works fine with everything.
Note that if you switch System A for B and B for A in all of the above, the results stay the same.

-Problem #2 (cannot be reproduced always)-
1) Incoming call from PRI on System B.
2) System speedcall sends call to single line phantom key on out of service 5240 IP Phone on System A.
3) IP Phone is call forwarded always to NuPoint Voicemail Hunt Group located on System A.
4) Call is processed inside NuPoint through a call director with a menu.
5) Caller uses option #1 which is a Blind Transfer to 5220 IP Phone on System B.
6) IP Phone user Blind Transfers call to other IP Phone on System B.
7) IP Phone user #2 doesn't answer.
8) After CFNA Timer expires, instead of rerouting using 1st alt. as it should, call recalls to IP Phone #1.

The 1st alt. CR destination can be anything (or nothing), doesn't matter, it recalls on no answer.
If IP Phone #2 is busy, it doesn't recall and follows normal call rerouting.
What's more puzzling, is that it's not happening always. Sometimes it works fine and we can't reproduce the problem ourselves anymore since we changed some timers in CoS.

-What we have tried-
We looked at CoS for sets, agents, trunks and VM ports involved in all tests. We changed all the NA timers we could find or recall timers or reroute timers (in Sys Opt and CoS). We made sure all the Public Trunks CoS Options were OK for everything and tried different setups. We tried default CoS with default timers (+added basic options for workability). We reproduced the same setup on different systems but they work fine. We cleared all CoR Restrictions so that nothing was restricted anywhere. We don't use tenanting or interconnect restrictions. Nothing of the above had an impact on the problem.

Problem #1 is easy to reproduce at will but we found a cheap trick to bypass it. However problem #2 is hard to reproduce and we don't have any cheap trick to solve this yet, so the customer is starting to put pressure on us to find a solution -- even more since it was OK before the upgrade.

Please note that none of these problems happened on 7.1 UR2 before the upgrade. The only thing that changed in the above setup between old platform vs new one is that before the PRIs were on NSU and now they're on embedded PRI cards. Same CoS, CoR, routes, trunking, cluster, sys opt, attributes, etc...

I think the source of both problems is the same since both are of the recalling type. However, we're totally out of ideas. So, throw what you have and I'll tell you if we did that and will try what we didn't.

Thank you very much!
 
A couple of thngs I would check

In the system options check the following
Conference options by default they are set to 1, 5, 4
set them to 8, 8, 8
Also check the number of forward hops set this to 10

Next check you IP trunking IP/XNET trunk groups and check that all the routes have 26 Network hops

The last one I would check is CoS on all devices
Trunks both PRI and IP trunks
VMail Ports
Extensions
Conference call is set to Yes
Public network via Dpnss is set to Yes
Public Network to Public Network Connection Allowed is set to Yes
Public Trunk is set to No
Recall if Transferred to Original Call Destination is set to No
Suppress Simulated CCM (Call Connect Message) after ISDN Progress is set to No
Use Held Party Device for Call Rerouting is set to Yes
No Answer Recall Timer set to 30secs

Share what you know - Learn what you don't
 
Conference options were 3,8,4 (changed years ago according to customer's needs) but making them 8,8,8 had no impact.
We already tried changing forward hops, no change.
Trunks are already at 26 network hops.
Conference call CoS Opt. is set to Yes everywhere.
All three Public CoS options are as you described except for PRI which has Public Trunk set to Yes. However, we already tried Public Trunk to No and it doesn't change anything.
Recall if Transferred and Suppress Simulated CCM are already set to No everywhere.
Use Held Party Device is already set to Yes everywhere.
We put all Recall Timers at max (125) first thing we heard about this problem to see if it was related. It changes nothing. We tried different values too.

Thank for replying! Willing to hear more input from anyone.
 
What is the status of system option:

DPNSS/QSIG Diversion Enabled? Yes/No

I've seen this option cause some odd behaviour.

**********************************************
What's most important is that you realise ... There is no spoon.
 
it would be worthwhile to disable the DPNSS/QSIG Diversion as a test.

**********************************************
What's most important is that you realise ... There is no spoon.
 
Just tried "No" on both systems.
Nothing changed at all.
 
It was worth a shot.

Next step is to setup a phone with the same COS/COR as a Nupoint port and simulate a call manually.

This way we can observe the system responses on the phone display and gain a more exact insight to the moment that things are failing.



**********************************************
What's most important is that you realise ... There is no spoon.
 
Actually, it occurs already when a set transfers manually the call instead of the VM.
Before doing the transfer+release everything is normal. Once the call recalls, we can see "PRI" on display. I looked around and it doesn't match with any trunk label or tel dir entry I've seen or known about. So I guess it might be a kind of default system label.
It doesn't match either with the original CID of the call which is the external CID.
 
The label PRI is not a defalt you have this programmed somewhere in a Trunk service (trunk attributes) form on one of the systems.
If there is no name programmed you wouls see the trunk number or the CLI of the caller.

Share what you know - Learn what you don't
 
Nevermind that. PRI label is from our lab system.

I redid the test on the customer's site with a set and we see "RINGING YOU BACK".
Something of note I didn't notice before :

We always did our tests (IP set tests) with a blind transfer, in other words "Trans/Conf key + release button". It rings the agent half a sec and recalls. However, if I do only "Trans/Conf" key and wait before doing release, it keeps ringing the agent. Once I hit release it recalls. It also means that if I do a conference call, it works fine.

 
Just to follow up, Mitel found the solution to problem #1.
It was because the ACD Group associated to the ACD path was resilient and contained traditional ACD agents.
We knew traditional ACD couldn't be resilient but we didn't know it could cause a problem like this if they were to be included in a resilient group.

Mitel has issued a DPAR to prevent this in future MCD releases.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top