Updating CLI after attended transfer

[geomat]

Hello,

I have the following scenario:
1. Agent (1001, CLI=123456) makes an outbound call to Customer 1 (destination number=777777). Customer 1 sees 123456 as the incoming number.
2. The same agent makes another outbound call to Customer 2 (destination number=888888). Customer 2 sees 123456 as the incoming number.
3. The agent makes an attended transfer from Customer 1 to Customer 2.

In the scenario above, after the transfer, is it possible to make Customer 2 to see the CLI of Customer 1 instead of the agent (i.e., 77777)?

Thank you in advance,
GM

 

[hfoster]

Is this going out via a trunk? If so, it's highly dependant on the carrier allowing you to spoof numbers freely. You'll probably find that Customer 2 already did get a REINVITE/UPDATE with the Customer 1, but the carrier re-wrote it back to your own number.

 

[geomat]

Thank you @hfoster !

The plan is to go out via a sip trunk. However, if I do my tests using local extensions (with different outbound caller id numbers) I don't see the change either. Does this also depend on the sip client ?

 

[hfoster]

Occasionally. I'm fairly certain our Yealinks update the number no problem (if permitted by the trunk). I'll have to run an sngrep tomorrow to ensure that FreeSWITCH is sending the RPID in the REINVITE. It's never been something I've had to toggle though.

 

[geomat]

Another interesting thing is that I tried to use the uuid_display command to update display information of a local call (using Zoiper and 3CX as clients) and nothing changed. I didn't notice any re-invite in sngrep. For this test I set ignore_display_updates=false in the diaplan manager (diaplan name = global-variables)

 

[geomat]

@hfoster did you have any chance to run sngrep?

Thank you in advance!

 

[dcitelecom]

Hello,

I have the following scenario:
1. Agent (1001, CLI=123456) makes an outbound call to Customer 1 (destination number=777777). Customer 1 sees 123456 as the incoming number.
2. The same agent makes another outbound call to Customer 2 (destination number=888888). Customer 2 sees 123456 as the incoming number.
3. The agent makes an attended transfer from Customer 1 to Customer 2.

In the scenario above, after the transfer, is it possible to make Customer 2 to see the CLI of Customer 1 instead of the agent (i.e., 77777)?

Thank you in advance,
GM

The above scenario describes a 3-way conference call. Your agent calls the first party and puts them on hold. Then he calls the second party and connects everyone or connects the 2 parties and exits the call but there is no call from the first party to the second party in this scenario.

 

[hfoster]

I did briefly, I had a bit of a hectic week regarding xml_cdrs and rather slow queries.

I think dcitelecom slotted something into place there. I was trying for ages to transfer a call to a previously held callee and my phone wasn't having it. If a 3 way convo is torn down on my Yealink, both Cust1 and Cust2 are booted off.

So I guess the question is, if the call flow is: Call Cust1 -> Att Transfer to Cust 2 -> Transfer

Does Cust2 see Cust1?
And for that, I can say yes as a lot of people get disappointed when we end up converting the foreign range back to the customers range. I will double check though.

 

[geomat]

@hfoster is this possible to make Att Transfer to Cust 2 (step 2 as you described above) with the current dialplans ?

Are you referring to feature code *4?

 

[hfoster]

Weirdly, you're right. I can't see an UPDATE or a REINVITE from the PBX. I can see the REFER being sent from the phone, but the FreeSWITCH then just consumes that and bridges the two calls. Hmmmm....

 

[geomat]

@dcitelecom thank you for your feedback. I though that the flow I described above is a standard way for doing attended transfers. I am using Zoiper and this is something they recommend: https://www.zoiper.com/en/support/home/article/199/Call Transfer with Zoiper 5

I also tried to use the *4 feature code but it seems that it only works for local extensions!

 

[dcitelecom]

Normally the scenario you are describing is only possible when A, B, and C are all on the same PBX system. If B and C are on POTS lines then A can not release the line after establishing a 3-way conference. This would disconnect B and C. I am still learning fusionpbx but if they have an unattended conference feature, that would probably do what you want and keep the B & C call alive after A releases the line.

When you use Zoiper to do the transfers then Zoiper is probably your backend PBX and the calls between A, B, and C are all managed by the Zoiper PBX. The transfers are a Zoiper feature, not a fusionpbx feature and apparently, you need to use the paid version Zoiper PRO.

 

[geomat]

@dcitelecom,

Indeed transfer features in Zoiper are only available in the PRO edition. However, I don't believe that Zoiper is acting as a PBX. I did a test where both B and C are mobile phones and everything worked fine. Also, while B and C were connected I closed Zoiper and the connection was still alive (here A is the Zoiper client).

@hfoster do you believe that I should open a ticket in the FS community ?

 

[dcitelecom]

@dcitelecom,

Indeed transfer features in Zoiper are only available in the PRO edition. However, I don't believe that Zoiper is acting as a PBX. I did a test where both B and C are mobile phones and everything worked fine. Also, while B and C were connected I closed Zoiper and the connection was still alive (here A is the Zoiper client).

@hfoster do you believe that I should open a ticket in the FS community ?

Actually this would be really easy to check. Simply look at your fusionpbx log during a Zoiper transfer from A to B. If you see nothing then the transfer is done via Zoiper PBX.

 

[geomat]

@dcitelecom, already checked and everything is handled by FusionPBX/FreeSWITCH

 

[hfoster]

The FreeSWITCH mailing list might have a bit of better knowledge. I've tried to Google ways of sending an UPDATE after bridging two calls for display purposes, but nothing appropriate seems to come up. (Might just be modern Google is crap tbh).

 

[geomat]

Thank you very much for your help @hfoster. I asked the freeswitch community in Slack. If I have an answer I will post it here.

 

[dcitelecom]

@dcitelecom, already checked and everything is handled by FusionPBX/FreeSWITCH

Maybe I misunderstood the issue but if it works the way you want when you use Zoiper and you confirmed that everything is handled by fusionpbx, then why not increase the log level and debug level to 7 and study the log of the call to see which transfer function Zoiper is using in fusionpbx?