cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1947
Views
335
Helpful
10
Replies

Call Consult Transfer failing, but falls to the Successful branch

Scott Holden
Level 1
Level 1

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?

1 Accepted Solution

Accepted Solutions

Scott Holden
Level 1
Level 1

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.

View solution in original post

10 Replies 10

rikardkrvaric
Spotlight
Spotlight

Scott... I smell a CSS issue here...

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.

I think I would lean towards this being your telco providers refusing the call because of the caller ID on outbound.

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.

Ratheesh Kumar
VIP Alumni
VIP Alumni

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"***

 

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! 

@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.

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.

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.

Scott Holden
Level 1
Level 1

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.