03-03-2022 10:10 AM
I have an existing CCX 11.6(2) script with a Call Consult Transfer step to an external PSTN number. When you call in from an external device and hit this step, you can hear MOH briefly while the call is being setup, but then the call drops. The script falls to the Successful branch, marks the call as Handled, etc. If you call into the same application from an internal DN, hit the Consult Transfer step, MOH briefly, and the call proceeds as it should without dropping.
If I replace the Consult Transfer step with Call Redirect and change nothing else, the call proceeds to the PSTN regardless of where you originally called in from.
Thoughts?
Solved! Go to Solution.
03-22-2022 11:56 AM
Circling back to this, as it was solved working with our ITSP. After looking over SIP debugs in the CUBE, there was a mid-call signaling issue. Reviewing the CUBE config, it was discovered they had the following:
voice service voip
sip
midcall-signaling block
The config was updated to 'midcall-signaling passthru media-change' and now the Consult Transfer step to an external number is successful.
03-03-2022 10:34 AM
Scott... I smell a CSS issue here...
03-03-2022 11:20 AM
Thanks for replying. I was going down this road, too. I changed the CSS on the trigger and CCG to one with more access than is needed, but nothing changed. I'm spinning my wheels.
03-03-2022 11:00 AM
I think I would lean towards this being your telco providers refusing the call because of the caller ID on outbound.
03-03-2022 11:17 AM
Hi Elliot, thanks for the response. Let's run with this for a minute or two. Would the outbound caller ID I'm sending change with who the originating caller is? We have "enterprise trunking" with our ITSP, which allows us to outpulse basically any caller ID we want.
03-03-2022 01:55 PM - edited 03-03-2022 01:58 PM
wondering whats the callerid the ports are sending out. try changing that or make sure the ports have a valid external number mask.
Also the offnet to offnet parameter in CUCM. Is it disabled ?
Hope this Helps
Cheers
Rath!
***Please rate helpful posts and if applicable mark "Accept as a Solution"***
03-04-2022 05:55 AM
Hi Rath, thanks for the response. The CTI ports associated with the CCG that's in use all have a valid external number mask. The consult transfer is successful if the call into CCX originates internally; it only fails when the call originates from an external party.
The parameter 'Block Offnet to Offnet Transfer' is set to False.
Appreciate the ideas!
03-04-2022 05:40 AM
@Ratheesh Kumar makes an excellent point about the offnet to offnet transfers. To know for sure, you will need to look at the Call Manager logs via RTMT to see why it is failing. If you don't want to parse the logs yourself, you can download Translator-X and it will do that for you including decompressing the .gz files. That is where you can see for sure. If you want to see if the transfers are making it to the gateway (I am assuming a CUBE), "debug ccsip mess" will show that to you. That would tell you if the provider were refusing the outbound invite.
03-04-2022 06:14 AM - edited 03-04-2022 06:16 AM
Good morning Elliot,
Appreciate you replying again. I mocked up a Call Handler in Connection to test with something other than CCX. I created a caller input option that transfers to an alternate contact number and set the transfer type to Supervised. The contact number is set to the same external number that CCX attempts to consult transfer to. I dialed into the handler with my cell, chose the input option in question, "please wait while I transfer your call", MOH plays briefly, and the call connects and proceeds as it should.
So it's something specific to my CCX setup, I just can't put my finger on it.
Edit: As for the gateway, yes it's a CUBE. But, we recently switched from a customer-managed (me) 4431 to an ITSP-managed router. So I lost visibility into it.
03-04-2022 06:44 AM
Do you get the original caller ID when you get transferred out from an external call? If so then that points away from it being the outbound ANI. I think your best bet now is to use RTMT to get the Call Manager logs and see why it is failing.
03-22-2022 11:56 AM
Circling back to this, as it was solved working with our ITSP. After looking over SIP debugs in the CUBE, there was a mid-call signaling issue. Reviewing the CUBE config, it was discovered they had the following:
voice service voip
sip
midcall-signaling block
The config was updated to 'midcall-signaling passthru media-change' and now the Consult Transfer step to an external number is successful.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide