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.

 

[Charli]

[...]
So maybe the following could work:
variableMap["session.transferingExtension"] = new Variable(MyCall.Caller["extnumber"] ?? string.Empty);

Thank you so much! This also works for us, I just upgraded to V20 U1 (from V18)

 

[edossantos_sipcaller]

Thank you so much! This also works for us, I just upgraded to V20 U1 (from V18)

You're welcome!

 

[Charli]

well, "extnumber" wasn't quite right actually.. Only for internal calls it contained the transfering Extension. Otherwise it somehow was the number of the caller.. But then "inbound_did" is populated and I can use the last two digits as the transfering extension. I was a bit lazy and did like this:

variableMap["session.transferingExtension"] = new Variable((MyCall.Caller["extnumber"].length = 2) ? MyCall.Caller["extnumber"] : MyCall.Caller.AttachedData["inbound_did"].Substring(12));

@edossantos_sipcaller Your two little foreach loops helped me to figure this out

 

[edossantos_sipcaller]

@edossantos_sipcaller Your two little foreach loops helped me to figure this out

Glad I could help! Enjoy your weekend!

 

[Gilles (Transacom)]

Hi,

I have tested this workaround, but extnumber contains the caller ID in 3CX v20 Update 1 Build 731 and Update 2 Build 688 Alpha.
There doesn't seem to be any call data that contains the transferring extension number...

Best regards,
Gilles

2024/06/25 12:30:13.205|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Attached Data: 'prevCall'=0
2024/06/25 12:30:13.205|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Attached Data: 'prevLeg'=0
2024/06/25 12:30:13.205|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Attached Data: 'devcontact'=sip:[email protected]:5483
2024/06/25 12:30:13.205|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Attached Data: 'public_push_pickupinfo'=CcFIR7pcKNeRhyRbROgIyg..;from-tag=bd3add2a;to-tag=8a330b78
2024/06/25 12:30:13.205|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Attached Data: 'public_push_callerid'=04xxxxxx79
2024/06/25 12:30:13.205|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Attached Data: 'public_push_callername'=Gilles
2024/06/25 12:30:13.205|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Attached Data: 'msep_id'=[email protected]:5482
2024/06/25 12:30:13.205|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Attached Data: 'sip_dialog_set_id'=CcFIR7pcKNeRhyRbROgIyg..0bd3add2a
2024/06/25 12:30:13.205|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Attached Data: 'recordstate'=0
2024/06/25 12:30:13.205|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Attached Data: 'extnumber'=04xxxxxx79
2024/06/25 12:30:13.205|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Attached Data: 'chid'=ab14f24e90010000_9
2024/06/25 12:30:13.205|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Attached Data: 'public_qticket'=28
2024/06/25 12:30:13.206|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Caller Attached Data: 'prevCall'=0
2024/06/25 12:30:13.206|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Caller Attached Data: 'prevLeg'=0
2024/06/25 12:30:13.206|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Caller Attached Data: 'devcontact'=sip:[email protected]:5060
2024/06/25 12:30:13.206|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Caller Attached Data: 'caller_name'=Gilles
2024/06/25 12:30:13.206|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Caller Attached Data: 'public_push_callername'=
2024/06/25 12:30:13.206|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Caller Attached Data: 'public_push_pickupinfo'=qGdLBLY2mMXtOZ1hEx4hlA..;to-tag=5f907011;from-tag=652ee607
2024/06/25 12:30:13.206|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Caller Attached Data: 'public_push_callerid'=990
2024/06/25 12:30:13.206|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Caller Attached Data: 'inbound_did'=+339xxxxxx29
2024/06/25 12:30:13.206|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Caller Attached Data: 'inbound_did_rule'=
2024/06/25 12:30:13.206|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Caller Attached Data: 'sip_displayname'=Gilles
2024/06/25 12:30:13.206|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Caller Attached Data: 'msep_id'=[email protected]:5482
2024/06/25 12:30:13.206|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Caller Attached Data: 'sip_dialog_set_id'=qGdLBLY2mMXtOZ1hEx4hlA..05f907011
2024/06/25 12:30:13.206|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Caller Attached Data: 'recordstate'=0
2024/06/25 12:30:13.206|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Caller Attached Data: 'extnumber'=04xxxxxx79
2024/06/25 12:30:13.206|0005|Trac| CallPair._990_2.Main.38.[C:9.5]-From script: transacom_3cxmanager - CallID ab14f24e90010000_9 - Callflow - Caller Attached Data: 'chid'=ab14f24e90010000_9

 

[Charli]

@Gilles (Transacom) What about 'inbound_did'=+339xxxxxx29? I was able to use it in my example above by stripping everything but the last two numbers, which in our case represent the extension number.

 

[Gilles (Transacom)]

@Charli I understood what you did and it's a good idea, but it doesn't work in my use case. I have no way of determining the transferring extension from the inbound_did. A single inbound_did routes to different extensions under different conditions which in turn route to the CFD...

 

[edossantos_sipcaller]

Hello @gilles,

Are you doing a blind or attended transfer? In an attended transfer, the call is received as a new call, unrelated from the original call, and then these 2 calls are bound together.

 

[Gilles (Transacom)]

Hi @edossantos_sipcaller

The transfers are programmed transfers in the exceptional transfers section.

 

[edossantos_sipcaller]

Hi @edossantos_sipcaller

The transfers are programmed transfers in the exceptional transfers section.

I understand, maybe in this case the information is not attached to the call, because the call is actually not going through that extension, it's the routing logic that directly skips it. This is something that has changed in v20.

An option could be using a different CFD app for each extension. This way the app will know the extension it's associated with, using the session.dnis variable you can know the extension number of the CFD app.

 

[Gilles (Transacom)]

An option could be using a different CFD app for each extension. This way the app will know the extension it's associated with, using the session.dnis variable you can know the extension number of the CFD app.

This cumbersome approach could work in theory but in practice it is not feasible. There was a clean easy solution to do this in v18. We just need a similar solution in v20. The ability to directly transfer to a CFD system extension from a user extension is a very good improvement in v20, but the loss of transferringExtension is a major breaking change for our use cases.

 

[richiewhite]

This has unfortunately caused issues for ourselves today. We have some CFD apps used by one of our teams to handle some workflow, basically the agent transfers the caller to an app to play a prompt, the app logs the agent out of queue, and once the prompt is listened to and the caller takes an action, the caller is transferred back to the agent, and the agent is logged back into queue.

I can't use MyCall.Caller["extnumber"] since it's generally inbound calls that use this workflow.

Without transferringExtension I'm having to bruteforce this by giving each agent their own app.

 

[edossantos_sipcaller]

I can't use MyCall.Caller["extnumber"] since it's generally inbound calls that use this workflow.

I don't see why not. This should work when transferring the call from an extension to a CFD app. This doesn't work when the transfer happens automatically for example due to a forwarding rule, but in this case the agent manually transfers to the CFD app, so it should work. Have you tried it?

 

[richiewhite]

I don't see why not. This should work when transferring the call from an extension to a CFD app. This doesn't work when the transfer happens automatically for example due to a forwarding rule, but in this case the agent manually transfers to the CFD app, so it should work. Have you tried it?

I did, and the logs indicated that the caller's number was used instead of the transferring extension. I'll keep digging into it, but I'll need to brute force it for now as I didn't think to test this specific functionality before upgrading.

 

[edossantos_sipcaller]

I did, and the logs indicated that the caller's number was used instead of the transferring extension. I'll keep digging into it, but I'll need to brute force it for now as I didn't think to test this specific functionality before upgrading.

Then before going the brute force way, I would try the other solution I proposed before:
You need to change this line:
variableMap["session.transferingExtension"] = new Variable(MyCall["onbehlfof"] ?? string.Empty);

To this:
variableMap["session.transferingExtension"] = new Variable(MyCall.ReferredByDN?.Number ?? string.Empty);

Probably this is much simpler than creating all those apps.

 

[richiewhite]

Then before going the brute force way, I would try the other solution I proposed before:
You need to change this line:
variableMap["session.transferingExtension"] = new Variable(MyCall["onbehlfof"] ?? string.Empty);

To this:
variableMap["session.transferingExtension"] = new Variable(MyCall.ReferredByDN?.Number ?? string.Empty);

Probably this is much simpler than creating all those apps.

That'll teach me for skimming threads! That worked perfectly!

Thank you, you're a star!

 

[edossantos_sipcaller]

That'll teach me for skimming threads! That worked perfectly!

Thank you, you're a star!

Well, it is a long thread, I would have done the same myself

Glad I could help!

 

[Gbot@Okam]

I don't see why not. This should work when transferring the call from an extension to a CFD app. This doesn't work when the transfer happens automatically for example due to a forwarding rule, but in this case the agent manually transfers to the CFD app, so it should work. Have you tried it?

Dear @edossantos_sipcaller,
Sorry if i miss something, but have you figure out how to obtain the session.transferingExtension variable when the call to a CFD comes from a user FW rule ?
Thanks for you help !

 

[edossantos_sipcaller]

Dear @edossantos_sipcaller,
Sorry if i miss something, but have you figure out how to obtain the session.transferingExtension variable when the call to a CFD comes from a user FW rule ?
Thanks for you help !

Hello @Gbot@Okam,

It seems it's not possible, from the tests I did the call doesn't have the information attached in any property, so it wouldn't be possible to get it in that way. The only option would be having a separate CFD App for each extension. I understand this would be cumbersome, but I don't see other option.

 

[Gbot@Okam]

Hello @Gbot@Okam,

It seems it's not possible, from the tests I did the call doesn't have the information attached in any property, so it wouldn't be possible to get it in that way. The only option would be having a separate CFD App for each extension. I understand this would be cumbersome, but I don't see other option.

Dear @edossantos_sipcaller
Thanks for your reply, I've opened a ticket support relative to this case, and an internal report has been created.
Let's hope this will be implemented soon !