Mitel sx2000 transfer / re-routing issue, QSIG to Avaya g450 gateway

[WideTrac]

The system uses a QSIG Tie Trunk (Trunk Group 114) to connect the G450 to the existing Mitel sx2000 system. All incoming calls route through the Avaya Gateway. If a call needs to route to MM, it travels over a QSIG trunk group (Trunk Group 18). Calls route flawlessly with one noteable exception. Scenarios are described below:

1. Outside Call > G450 > Avaya Phone > no answer > MM (Call concludes successfully)
2. Avaya Phone > Avaya Phone > no answer > MM (Call concludes successfully)
3. Outside Call > G450 > Mitel Phone > no answer > MM (Call concludes successfully)
4. Avaya Phone > Mitel Phone > no answer > MM (Call concudes successfully)
5. Scenario 4 Mitel to Avaya (Call concludes successfully)
6. Outside Call > G450 > Avaya Phone > Mitel Phone > Transfer to Mitel Phone > no answer (Call fails to forward to MM across the QSIG trunk)
7. Scenario 6 except 2nd Mitel Phone has All Call Forward/Send All Calls engaged > (Call concludes successfully)

As you can see, the programing config works in almost every scenario with the exception of one. Since the various scenarios are very close to one another in how the systems handles them, we have concluded that the calls placed in the Scenario 6 manner must be sending (or failing to send) identifying packets across the D channel. We have no idea if it is the Mitel failing to send the correct configs or the Avaya who fails to recognize them in Scenario 6. Scenarios 6 and 7 are virtually identical with the exception of the DND engaged on the 2nd phone.

Any suggestions would be appreciated

 

[kwbMitel]

I have a couple of suggestions.

As the failed scenario is the only scenario that involves a transfer, you need to test the other scenarios and add a transfer component.

You could try toggling the System Option DPNSS/QSIG Diversion. I hve had to turn this option on to fix some things and off to fix others. See if it makes a difference in your case.

Try using forwarding instead of reouting for the final hop to voicemail (Or vice-versa, whichever applies)

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[WideTrac]

I have sent the info to the technician that has been performing the test to see if he has changed the diversion settings.