Issue with Caller ID and Transferring Extension in IVR Transfers

[Sajjad.Khurshid]

Scenario:

1. A customer calls, and the call is directed to a queue where an agent answers.
2. After the call ends, the agent transfers the call to an IVR for review.

Issue:

• Attended Transfer: The callerId shows the agent's extension instead of the customer's phone number. (Previously, it worked correctly, where callerId contained the customer number and transferringExtension contained the agent's extension.)
• Blind Transfer: The callerId is correct (customer's phone number), but transferringExtension is empty.

Expected Behavior:

• callerId should display the customer's phone number.
• transferringExtension should contain the agent’s extension.

Has anyone encountered this issue before? Any suggestions on how to ensure both variables display the expected values?

Thanks in advance!

 

[Evolute IT]

CFD is deprecated in v20.

session.ani should have the external Caller ID still, even for transfers.

seesion.transferingExtension is empty on v20 by default. You need to modify the output script to make adjustments. Search for forums, you'll see plenty of people asking for that.

 

[EscondidoAdmin]

Hi,

Revisiting the OP's issue of not being able to access certain session variables in v20 that were available in CFD v18.5.8.0:

session.did​

session.dnis​

session.transferingExtension​

With the recent release of CFD v20.2.84, I assume that the CFD isn't really deprecated in v20?

In any case, using CFD v20.2.84, it appears the above variables are still not available in a v20 Call Flow. I see it appears that there are some new session variables, but I've not tested to see if they have the equivalent values that the above had.

Are we still expecting to hand edit the C# output from the CFD v20.2.84 to get the above values?

Reason why I ask is we have hundreds of Call Flows and they get updated fairly often. Hand editing the C# output is untenable. We've undertaken a wholesale rewriting of call flows to get around the lack of access to the above variables. Would be nice if this is something that'll be added back to v20 sometime soon.

Thanks,

 

[NicholasP_3CX]

Hand editing the C# output is untenable.

Isn't that really the whole point of scripting in general? That you wont need to load it in the CFD application, build it, export it and upload it to the PBX?

 

[Sajjad.Khurshid]

Hi,

I have followed this approach https://www.3cx.com/community/threa...-3cx-version-20-0-update-0-build-1494.124792/ and now I am getting value in transfering extension when using blind transfer.But the value is the extension number of the queue, but what I need is the extension number of the agent from that queue who transfered the call.If I uses attended transfer, I get agent extension in session.ani instead of caller phone number

 

[fxbastler]

So if I have an external call on a queue 802, answer it with agent 202 and then blindly forward it to a CFD app, then the number 202 is in session.transferingextension. Built with CFD 20.2.84.0.

 

[Tom Z]

So if I have an external call on a queue 802, answer it with agent 202 and then blindly forward it to a CFD app, then the number 202 is in session.transferingextension. Built with CFD 20.2.84.0.

That's literally the ONLY setup where this works.

Try calling an extension via an external DID and is DND => empty
Try calling from an internal extension to an internal extension that is DND => empty

I tried this with both older and newer versions of the Callflow Designer.
Especially "funny" since 3cx has this problems since like 3 years now....on and off, and on and off...

 

[fxbastler]

Try calling an extension via an external DID and is DND => empty

You mean:
A call from outside to a DID that is assigned to an extension, this extension is in DND, the call is forwarded directly to the CFD app and there you want to know which original first internal extension should be called according to the DID?

If so: I have a tried and tested C# snippet for that

 

[Tom Z]

Basically I want to ALWAYS have the information who called the CFD in "session.transferingExtension".
That's how it's documented as well.
https://www.3cx.com/docs/manual/cfd-conditions-variables/#h.gerfdz7c0fxh

It's very important to understand where the call came from, no matter how it got there in the first place.

And this is simply not the case.

I'm curious about your c# snippet thou, since it seems like we need to take the idea to ever use a bug-free CFD again to the grave.

 

[fxbastler]

Pleasy

A call from outside to a DID that is assigned to an extension, this extension is in DND, the call is forwarded directly to the CFD app and there you want to know which original first internal extension should be called according to the DID?

The question about the scenario was serious.

Is that what is being asked?

A simple yes or no is enough

Basically I want to ALWAYS have the information who called the CFD in "session.transferingExtension".

Unfortunately, I can't completely agree with that. In my experience, it also depends on the type of transfer - how did the CFD receive the call. There are several possibilities.

 

[fxbastler]

I'm curious about your c# snippet thou, since it seems like we need to take the idea to ever use a bug-free CFD again to the grave.

The C# snippet described above is about exactly that: who was called first.
If it was a user who forwardeds to a call queue that does not answer and then the CFD App comes the call should go to the mailbox of the callee - the caller who was originally called. After the call has been accepted anywhere (in this case the call queue, but it could also be an IVR or something else) the original CFD variables no longer works. We have to solve it differently, but it works.

 

[Tom Z]

For me it's like:
If an extension is unavailable and goes into a status of DND, is busy/offline or whatever...in any case => CFD
The customer will be asked if he wants a callback from that extension by the CFD.
Only possible ofc if you know the source of the transfer to the CFD...

If the customer decides to say yes (in my case "press 1"), an email will be sent to that extension's email, so he knows he needs to call back later. If not the CFD sends the call into a queue to be answered by someone else.

A extension can be called internally or directly via an DID assigned to the extension from external sources.
In those 2 cases the "call data" is different (obvi), BUT the session.transferingExtension is always empty.

I tried to use session.transferingExtension 4 times now since the ...probably 6 (?) years of working with 3cx...and it never worked the way it's documented.
Funny enough there are forum posts that indicate, it worked for a short period of time in v20.

 

[fxbastler]

If an extension is unavailable and goes into a status of DND, is busy/offline or whatever...in any case => CFD
The customer will be asked if he wants a callback from that extension by the CFD.

Then this snippet will not work for you. It 'only' identifies the first person called.

Funny enough there are forum posts that indicate, it worked for a short period of time in v20.

Yes, I know that. We worked with it for a while when it worked all the time. We just don't need it at the moment.

You'd have to dig a little deeper to get it working again. This scenario isn't included in the normal variables. Nor in the AttachedData. But there may still be possibilities.

 

[Tom Z]

you said you have a c# snipped that returns the originator?

 

[fxbastler]

Post in thread 'Get Extension by called number'

Feb 26, 2025

CFD C# snippet, returns the extension which is first called from external or internal caller

returns 0 if all fails

string retval="0";
if(myCall.Caller.DN is ExternalLine externalLine && myCall.IsInbound)
{
    string[] range;
    foreach (var a in externalLine.RoutingRules)
    {
        bool match = (a.Conditions.Condition.Type == RuleConditionType.BasedOnDID &&
        (
            a.Data == myCall.Caller.CalledNumber
            || (a.Data.StartsWith('*') && myCall.Caller.CalledNumber.EndsWith(a.Data[1..]))
        ))
        ||
        (
            a.Conditions.Condition.Type...

• fxbastler

• 

Thanks to 3CX for the reference implementation of handling incoming calls in the published holiday.cs. We had previously built some home-made solutions, but the original is better. For example, we used regex (which takes a little more time) and didn't take the CID into account at all. The 3CX script was only available in autumn

 

[Tom Z]

that's not what "session.transferingExtension" should do, isn't it?

We just want to know what extension was the LAST extension before the transfer to the CFD, so we know what extension the customer tried to reach.

Like

01234-20 => extension 20
20 is dnd => CFD 97 => in CFD 97 we want to know what extension triggered us (it's 20!).

But your snippet would give 01234-20 or am I wrong?
01234-20 is in fact contained both in "ani" as well as "did".

 

[fxbastler]

01234-20 => extension 20
20 is dnd => CFD 97 => in CFD 97 we want to know what extension triggered us (it's 20!).

If '01234-20' is a call from external to a DID and this call ends at first on extension 20 (no matter what comes after) the script return 20 - in any case.

 

[Tom Z]

If '01234-20' is a call from external to a DID and this call ends at first on extension 20 (no matter what comes after) the script return 20 - in any case.

this statement is FALSE.
It in fact DOES NOT return 20 - it's empty!