IVR and remote ACD path transfer 1

[KurpeusLondon]

Hi guys,

I've a cluster of 2 x Mitel ICP3300 controllers MCD6.0 PR1. I've also a contact center with 2 IVRS (on at each site) with resilients ports located at both site.

When a call comes in to Site A, IVR A execute a call flow, play the initial greetings and should then transfer the call to an ACD path to is configured on Site B

The call reaches ICP controller B but it looks like the controller is terminating the call.


(Call flow: SIP_TRUNK A -> ICP-A -> IVR-A -> ICP-A -> IP trunk -> ICP-B -> Path 6507)



CCS Trace on controller A (where the call lands first, then is sent to the IVRA which executes the call flow and transfer the call to ACD path 6507)

17:59:44 RIL DPN PEER adept 381 29 ISRM_I
;10;*3#*19*Z#*58*Ca*1*Z#*100*+440712345678#
17:59:44 RIL DPN PEER adept 381 27 SSRM_I
*58*CW*`O@s@@@@LMVLOp#*50*0712345678#
17:59:44 RIL DPN PEER adept 381 D SSRM_C 441234567892
17:59:44 ROL DPN PEER adept 381 18 NAM *1*3#*50*406611#*166*6#
17:59:44 ROL DPN PEER adept 381 11 NSIM ;1C;*58A*Cc*4*4410#
17:59:44 ROL DPN PEER adept 381 29 CCM
*1*3#*50*404410#*166*6#*100*IVRPort10*1#
17:59:52 ROX DPN PBX8 1927 1721 D** B** 1D ISRM_I
;10;*3*1#*50*0712345678#*80*3#
17:59:52 ROX DPN PBX8 1927 1721 D** B** 1C SSRM_I
*100*+440712345678*1#*19*Z#
17:59:52 ROX DPN PBX8 1927 1721 D** B** 22 SSRM_I
*58*CW*`O@s@@@@LMVLx@#*58*C6*001#
17:59:52 ROX DPN PBX8 1927 1721 D** B** 27 SSRM_I
*58*CL*E*3*4410*C0036018*A#*58*C4*4*1#
17:59:52 ROX DPN PBX8 1927 1721 D** B** 1E SSRM_C
*58*CQ*00#*58*CY*2*-#98786507
17:59:52 RIX DPN PBX8 1927 1721 D** B** 2A NAM
*1#*50*406507#*166*4 5 6#*100*StHelens*1#
17:59:53 ROX DPN PBX8 1927 1721 D** B** 2 CRM/CIM ;30;
17:59:53 RIX DPN PBX8 1927 1721 D** B** 2 CRM/CIM ;30;
18:00:15 RIL DPN PEER NIL_PEER_ 381 17 CRM/CIM ;30;*58*C2*G*487#*234*Gp#


CCS trace om controller B (where the destination ACD path 6507 resides)
17:59:52 RIX DPN PBX3 1721 1927 D** B** 1D ISRM_I
;10;*3*1#*50*0712345678#*80*3#
17:59:52 RIX DPN PBX3 1721 1927 D** B** 1C SSRM_I
*100*+440712345678*1#*19*Z#
17:59:52 RIX DPN PBX3 1721 1927 D** B** 22 SSRM_I
*58*CW*`O@s@@@@LMVLx@#*58*C6*001#
17:59:52 RIX DPN PBX3 1721 1927 D** B** 27 SSRM_I
*58*CL*E*3*4410*C0036018*A#*58*C4*4*1#
17:59:52 RIX DPN PBX3 1721 1927 D** B** 1E SSRM_C
*58*CQ*00#*58*CY*2*-#98786507
17:59:52 ROX DPN PBX3 1721 1927 D** B** 2A NAM
*1#*50*406507#*166*4 5 6#*100*StHelens*1#
17:59:53 RIX DPN PBX3 1721 1927 D** B** 2 CRM/CIM ;30;



If I change the speed call to target IVR B instead of IVR-A it works fine. (Call flow: SIP_TRUNK A -> ICP-A -> IP trunk -> ICP-B -> IVR-B -> ICPB ->Path 6507)

If I change the speed call to target the ACD path directly it works ok too (Call flow: SIP_TRUNK A -> ICP-A -> IP trunk -> ICP-B ->Path 6507)

Path 6507 resides on controller B and the primay agent group & agents also all reside on controller B


Hope that make sense.

Thanks

 

[kwbMitel]

Best guess is that the IVR on Site A is not allowed to create the conference between the SIP trunk and the IP trunk to site B.

Simplest test is to assign the same COS and COR that the IVR has to a standard phone and try to transfer the call manually. This will reveal the issue 9 times out of 10

**********************************************
What's most important is that you realise ... There is no spoon.

 

[KurpeusLondon]

Thanks KwbMitel. I'll try that.

Interestingly, the call seems to be presented on the agent phone for a split of second. The agent hasn't got time to answer the call and the call is requeued endlessly.

 

[kwbMitel]

That symptom makes perfect sense to me for the scenario that I described.

IVR answers SIP call
IVR puts SIP trunk on transfer hold
IVR dials transfer destination
Transfer destination rings
IVR tries to disconnect from call
IVR fails to disconnect
Call never arrives at agent

**********************************************
What's most important is that you realise ... There is no spoon.

 

[KurpeusLondon]

Yes that was spot on. The Ip trunk is somehow defined as public trunk. In the CoS for the IVR port Public Network to Public Network was disallowed. Switching it on allowed the forward.

Thanks for the tip, I'll remember that.

Cheers