Solved CallBack issue - Internal Error

[DavidA]

Hello,

We are running a fully updated 15.5. I have a number of Queues setup to use Callbacks and they have all been fine. My main Queue has just had 3 new DIDs ported to it. The ports have finished. When calling in on those 3 new numbers I hit 2 to select a Callback I get an Internal Error when it is starting to read the Caller ID. The correct number is coming through on the caller ID per the management screen.

I have moved those numbers to a different queue to see if it is Queue based and they act the same, Internal Error.

We are running a 32 line Enterprise license.

 

[YiannisH_3CX]

Hello @DavidA

Do other numbers work Ok with callback? Are the numbers of the same provider?
Also where are you seeing the mentioned error?

 

[DavidA]

Yes, we have another 6 numbers all on the same provider and they have been working as expected. The error comes when the callback prompt plays. "You have selected a call back from caller id: Internal Error. "

 

[DavidA]

It looks like it's related to porting. We have these numbers being ported and forwarded to a temporary number on our Trunk. Direct calls to the trunk number work fine, the numbers being ported all give the Internal Error when trying to read out the Caller ID.

What should happen if it can't get the caller ID for the Call Back? Should it error, or another message asking for the correct number?

thanks

 

[DavidA]

It looks like it's not related to porting right now. it is happening with numbers i ported over and am using for call center queues as well as DIDs i created natively i SIPTrunk. Not all of them, but some of them. Some of the natively created numbers work just fine. Others throw the same Internal Error when trying to read back the Caller ID number.

Thanks

 

[YiannisH_3CX]

If this is happening to other numbers as well i would recommend creating a ticket with our support department as so they can look into the issue and determine what is causing this behaviour.

 

[DavidA]

Ok, It looks like its been resolved. We created the Trunks using the 3cx templates for SipTrunk.com. Some of the DIDs work fine. Others do not. Per Siptrunk the ones failing are coming into the system with a (+1 number) from their system in the call setup header whereas the working ones are just coming in with the raw number without +1.

The Inbound Parameters for CallerNum defaults to Contact: User Part. Per Siptrunk, they normally use/see the From: User Part field selected. When we changed to the From field calls do not throw errors when selecting a CallBack in a queue.

They could not explain why the calls were coming from their system differently depending on the DID.

Thanks for the help

 

[YiannisH_3CX]

Glad to see the issue has been resolved and thank you for updating the thread with your solution