Hello all.
I have a client who has the following scenario.
CUCM 10.5(SU1)
UCCX 10.5
3945 H.323 Gateway
The following call setup is as follows and is very straightforward. Inbound PSTN call to the UCCX via the H.323 gateway and then CUCM. CUCM routes it to a UCCX script which plays an IVR Menu. Some of the options in the IVR menu are transferred to the PSTN using a call-direct step, out to the same gateway the call came in on. Up until this week, this was all working fine. However, the customer moved from a circuit based ISDN BRI service to a SIP service this week. This SIP service uses an ISDN handoff but is SIP from the NTU in the ITSP cloud. They reported to me that the UCCX off-net transfers were not working.
From analysing the ISDN debug information, I know why that is the case, the calling party number being presented to the ITSP is the called party of the re-direct step. For example, option 1 of the IVR is PSTN number 12345, so the calling party being presented to the PSTN is 12345. Obviously this makes the call fail as the ITSP want to see a valid DID number of the range. I have set the H.323 gateway to use “last redirect number” so I assume the CUCM is taking the last redirect number to be the transfer destination of the call-direct step in the script? I have never seen this behaviour before, is it working as designed? I was expecting to see a calling party number of the DN of the CTI port? To make matters more complex/strange, if I create a Calling Party Transformation pattern for 12345 which is in a PT used by the gateways CSS, it seems to ignore it?
