CFD variable session.transferingExtension missing (bug) on 3CX Version 20.0 Update 0 (Build 1494)

[surawoot]

Hi team,

I have identified an issue with CFD in 3CX version 20 where it cannot send values from the parameters session.transferingExtension. Initially, I attempted to use the built-in component survey with the output fields parameter. I set the variable parameter to the table below.



You can review my call flow log here.


All parameters seem to be working fine, except for session.transferingExtension, which is not sending any values.
Subsequently, I attempted to debug by printing this parameter to the logging on my server, but it also proved unsuccessful.

 

[Benedikt Machens]

Yes, this is to improve security and avoid SQL injection, so it's good that you have and use this.


In 3CX v20, all the routing of incoming calls has been changed. Now, when you have a forwarding rule in your Extension, the call is not really stopping by in the extension. The router logic directly skips it. And this is what causes that you don't see the extension number in the variable. I would recommend you 2 things:
1) Execute the script mentioned here, check the logs and see if there is any property attached to the call that will give you the value that you need:
https://www.3cx.com/community/threa...-20-0-update-0-build-1494.124792/#post-605434

2) If that doesn't work, maybe your DID can tell you which extension would be involved. So by checking the session.did variable you might do something.

1) Thats how i find the other stuff So the big bad router logic steals our information
The key behind this, most of our CallFlows get the parameter from the transferring extension, so we have just one code, but 10-20 extension with different parameters to do their job.

If some has a better idea to get parameters in call flows - don't hide - then we may don't need the TE in those scenarios

 

[edossantos_sipcaller]

1) Thats how i find the other stuff So the big bad router logic steals our information
The key behind this, most of our CallFlows get the parameter from the transferring extension, so we have just one code, but 10-20 extension with different parameters to do their job.

If some has a better idea to get parameters in call flows - don't hide - then we may don't need the TE in those scenarios

Well, another idea could be that you use a different CFD app instance for each extension. So you have 20 extension, you deploy the same CFD app to 20 different extensions. Then the CFD app can read the value from the session.dnis variable, which contains the extension in which the CFD app is registered. I understand that maintaining this will become cumbersome, as you will need to deploy the CFD app 20 times if you make an update. But if you are not doing many changes, then it might be an option to consider....

 

[Benedikt Machens]

Well, another idea could be that you use a different CFD app instance for each extension. So you have 20 extension, you deploy the same CFD app to 20 different extensions. Then the CFD app can read the value from the session.dnis variable, which contains the extension in which the CFD app is registered. I understand that maintaining this will become cumbersome, as you will need to deploy the CFD app 20 times if you make an update. But if you are not doing many changes, then it might be an option to consider....

Painful, but yes.

But there is another thing

Maybe someone created a call flow, where you can redirect your calls when you are on DND, and if the call is on a whitelist inside your phonebook, the CFD will set your extension from DND to Available, redirects the call and reset your state to DND. You wont miss the pizza guy when you are on DND...

In this case the information is lost and you remain hungry.

From CDRS we also see some weird things, that somethings the redirector is not visible, depending on blind or attented transfer. This may could come from the same "ReferredByDN" issue.

We really need something, even when the router attaches some new data to the call like "RuleRedirectFromDN", anything. There are so many useful scenarios that are gone with the new router logic

 

[Guillaume Bourgeois]

You wont miss the pizza guy when you are on DND...

In this case the information is lost and you remain hungry.

Only three important people know my personal mobile number:

- My wife
- My parents
- The pizza guy

I won't starve, I promise you.

Theoretically, now that it's possible to copy and paste the content of CallFlow (C# code), it's no more painful than an extension. And if it's well-built, you can configure settings in Dn Properties to avoid hardcoding. True, I understand that the call routing logic of v18 simplified things a bit in the current scenario, but there are many other advantages to the new call routing logic in v20.

 

[Benedikt Machens]

Theoretically, now that it's possible to copy and paste the content of CallFlow (C# code), it's no more painful than an extension. And if it's well-built, you can configure settings in Dn Properties to avoid hardcoding. True, I understand that the call routing logic of v18 simplified things a bit in the current scenario, but there are many other advantages to the new call routing logic in v20.

For parameter yes, for dynamic call scenarios where you need to get informations from "who send this call to me" not.

And yes, the new features of the router logic are awesome, but why must they break such simple things? From the log we can the, the router knows on which behalf it is redirecting the call, so just attach this damn information to the generated call. And every existing call flow can be upgraded

 

[edossantos_sipcaller]

For parameter yes, for dynamic call scenarios where you need to get informations from "who send this call to me" not.

And yes, the new features of the router logic are awesome, but why must they break such simple things? From the log we can the, the router knows on which behalf it is redirecting the call, so just attach this damn information to the generated call. And every existing call flow can be upgraded

I don't think this was removed on purpose, it's just a scenario that was not considered when this was completely rewritten. You should let 3CX support know about this, and 3CX might get it fixed in a future update.

 

[Benedikt Machens]

I don't think this was removed on purpose, it's just a scenario that was not considered when this was completely rewritten. You should let 3CX support know about this, and 3CX might get it fixed in a future update.

Answer: Known issue, work in progress

 

[edossantos_sipcaller]

Answer: Known issue, work in progress

That's good, the fix is on the way!