CFD Makecall works poorly due to the prefixes requested by the provider

[JRodriguez0105]

Good morning 3CX team,

We have a project with a client with a simple outgoing dialer, he consults a database and depending on it makes a call connecting to an extension and an external number, he tries to call the external number first and then the extension.

The problem we have is that even if the call is answered or not, the MakeCall component is always returning that the call is false, that is, it does not connect, in this way our flow is working poorly and it tries to call the number over and over again. because for him it was never answered.

This same flow was tested with another provider and it worked fine, but with this SIP Trunk provider, this is happening to us.

the problem we have is the inconsistency with the calls and the logs of the call flow designer, you will find them. I put it specifically here:
Log of the outgoing call that connects to an extension:

'2024/01/11 12:34:42.698|15065|0037|Trc|CallPair._887_3.Callflow.48921.[C:29580.2]-From script: Dialer - Dialer 0 - CallFlow.CFD.MakeCallComponent 'MakeCall_I' - Making call from origin='56974308109' to destination='001'



Result of the call 'AS PER THE MAKECALL COMPONENT':

'2024/01/11 12:35:12.699|15065|0035|Trc|CallPair._887_3.Callflow.48921.[C:29580.2]-From script: Dialer - Dialer 0 - Dialer - OnMakeCallResult for component 'Individual_Calls' - Result : 'False'


But the issue is that the call actually happened, it was answered and it passed without any problem, that is why the result of the CFD does not agree with that of the calls, and I don't know if it has to do with the SIP Trunk or not because with another plant and another provider the same flow worked without problem.




I already managed to solve, or rather find the problem, but the problem seems very serious to me with respect to dialer developments.

The problem in the end was related to the fact that the provider's outgoing trunk was prepend to the number 80000, so if the CFD called the number 12345678, the result of the call is returned but with the call 8000012345678, then clearly at the point of Viewing the CFD the number 12345678 did not obtain a refund and it always marks it as the calls did not work.

I have no idea or way of how to evaluate the MakeCall component and ensure that the response of whether the call was answered or not works for this case.

 

[edossantos]

You will need to use an outbound rule that doesn't add a prefix. You can add this prefix to the database, or you can also add it to your CFD project so the MakeCall component initiates a call to the exact number dialed out.

 

[JRodriguez0105]

Hello Ernesto, I am glad to have a response from you,

it is indeed what I did but I am aware that it is a temporary solution, because if the client wants to add an additional rule, or an additional trunk, we will have to change our development with the prefix o That the database is always changing depending on it, is not viable so it is not dynamic, I was thinking of some way in which this in the flow could identify the number used by the trunk to be able to evaluate it correctly. But I can't think of anything viable.

 

[Evolute IT]

, or you can also add it to your CFD project so the MakeCall component initiates a call to the exact number dialed out

This is what we do.

 

[edossantos]

Well, it's not that easy to provide a matching if it's not an exact match. Some outbound rules add a prefix, others remove some digits. So comparing the numbers to check if the dialed number ends with the requested number might also not work in some cases.... If your SIP Trunk requests always the same prefix, adding it to the CFD app should always work.