CFD Shared Call Park

[CISCOX]

Hello,

I've noticed that in V20, Shared Call Parking via SP0, SP1, etc., is no longer functioning. I would like to set up a CFD to redirect an active call, and when I call the CFD, I want to be reconnected with the original caller. Is that possible?

I also have a question: Why is Shared Call Park not working in V20 despite being displayed in the settings?

Regarding the lack of Outbound Dial Tone on my Cisco phone in V18 and hearing it in V20, I've already toggled Replaces Header and Reinvites in the Cisco Extension options and SIP trunk settings on V18. I only hear the tone during internal calls.

Thanks in advance and best regards.

 

[TheodorosG_3CX]

Can you please clarify if you are trying to place a call to shared parking but getting an error?
Have you check the guideline here with each extension role as a standard user does not have this permission?

 

[CISCOX]

This is the wrong way. Previously, I used to forward calls to Extension 1111. Calls to 1111 were answered by SP1. I believe you mean the star code to park calls. In any case, the user at 1111 is disconnecting the call because the user at 1111 is not logged in. This worked in V18; I could call 1111 even if it wasn't logged in, and then the participant would be connected to SP1.

So, here's my question. 3CX offers a 3CX Call Flow Designer, but it's so complex that users can't understand it. I would like to create a call flow that can do exactly that.

When I forward a participant to the CFD, they should hear a prompt playback. When I call the CFD again, I want to be reconnected with the participant. This is the correct approach in V20. Can anyone help me with this?

 

[edossantos]

Looks like you want to emulate the existing shared parking functionality with a CFD app. You can't do that actually. You can interact with the caller from a CFD app, and you can transfer a call, but you can't join 2 different calls which are unrelated.

 

[benrg]

Hello @edossantos
Interesting, I gave a try until I found your statement above.

I have a very simple Test CFD app, only using the Transfer component, transferring to "SP0".
This Test app has extension number 900.
Tests are made using 3CX V18 U9 B20.

When a call is transferred to 900, call is properly parked into SP0. Perfect !
When someone calls 900, he's parked into SP0. Useless, but it works. OK.
However, when a call is already parked into SP0, and someone calls 900, I would have expected him to retrieve the parked call.

But instead the following error triggers :

2024/02/17 09:42:16.263|28369|0010|Trc|CallPair._900_148.Main.7427.[C:2677.2]-From script: Test - CallID 0000018DB63AFC2D_2677 - CallFlow.CFD.TransferComponent 'Transfer1' - Transfering call to destination='SP0'.
2024/02/17 09:42:16.264|28369|0010|Trc|CallPair._900_148.Main.7427.[C:2677.2]-From script: Test - CallID 0000018DB63AFC2D_2677 - CallFlow.CFD.TransferComponent 'Transfer1' - Adding timer to monitor transfer call progress.

2024/02/17 09:42:21.430|28310|0021|Verb|CHR: Adding event: 2024-02-17 09:42:16.409|RouteFailed|0000018DB63AFC2D_2677|7eec5b402e3a/Route DN.SP0/ParkOrb dn-name='' epname='Ext.SP0' [RouteBusy]
>7eec5b402e3a/Route DN.SP0/ParkOrb dn-name='' epname='Ext.SP0' [RouteBusy]
2024/02/17 09:42:22.297|28310|0048|Info|CHR: #3: Seg[1/#3] 0ee3484c05f1(Ext.202)=>18ade6581296(Ext.SP0) (09:42:16.309..09:42:21.294) Ringing RouteBusy

Same result using the C# call PhoneSystem.Root.TransferCall.

Any reason why ?
Did I miss something ?
Is there a trick somewhere to apply ?

What makes me think it should work is that if I call we call a dummy extension transferring to SP0 (so a transfer to SP0 is also used here), we properly retrieve the parked call.
Same result modifying Test app to transfer to this dummy extension, parked call is properly retrieved calling 900 (but what a mess !).

Looking forward to hearing from you

 

[CISCOX]

Hi, could you please share this project with me? What C# Code do you use?

 

[Guillaume Bourgeois]

3CX offers a 3CX Call Flow Designer, but it's so complex that users can't understand it.

Forgive me for contradicting you, but this isn't true.
I have many clients with no technical knowledge, in development or computing, who manage to create very beautiful CallFlow projects.

Obviously, if you want to accomplish something that isn't available in the callflow components, you will need some C# development skills, which is normal.

All you need to do is read the documentation; it's very well detailed.

Each component has a "?" that will open a web page with instructions. I myself still use it regularly, even though I have been creating CallFlow projects for a long time.

https://www.3cx.com/docs/manual/cfd-building-projects/
https://www.3cx.com/docs/manual/call-flow-designer/


.

What makes me think it should work is that if I call we call a dummy extension transferring to SP0 (so a transfer to SP0 is also used here), we properly retrieve the parked call.
Same result modifying Test app to transfer to this dummy extension, parked call is properly retrieved calling 900 (but what a mess !).

I don't believe the method you're using or attempting to use is good practice.

From what I understand, it's not designed for that purpose.

And if it works on v18, I consider it to be using a "bug" or an "edge case" as a workaround, which does not ensure a reliable long-term solution.

Clearly, it should not be possible to transfer 2 externals calls to the same share parking spot.

I can imagine a disaster if a user transfers 2 clients to the same parking spot and, in the end, the 2 clients end up communicating with each other.
By mistake, without the user actually intending this.

Instead of explaining what you're trying to accomplish in your project...

Maybe you could explain your ultimate goal of what you're trying to do...

Forget the technical details, clearly explain to us the needs and an example scenario without explaining the solutions you've imagined.

This way, we can advise you better.

Have nice day

 

[benrg]

Clearly, it should not be possible to transfer 2 externals calls to the same share parking spot.

I can imagine a disaster if a user transfers 2 clients to the same parking spot and, in the end, the 2 clients end up communicating with each other.

This simply can't happen with Shared Parking (we are talking about SP here) :
https://www.3cx.com/blog/docs/call-parking/ : There is also a limit of 1 person per room.

First call / transfer to a SP is intended to park the call into this SP room.
Second call / transfer to a SP is intended to retrieve the parked call from this SP room and give it to the caller.

Finally, dialling SPx is "supported" by 3CX team itself.

Forget the technical details, clearly explain to us the needs and an example scenario without explaining the solutions you've imagined.
This way, we can advise you better.

I"m used to / found of technical details, no worries So I'll still be interested into 3CX Support Team answer to these technical points
Anyway, I appreciate your help, and what I simply try to do is to Shared (un)Park from a CFD-app.
I dynamically park calls based on available SP rooms, perfect.
But I'm stuck with unpark, as transferring the CFD-app caller to the SP room does not unpark the call, as it should.
Hence my (technical) questions above

Thank you again !

 

[Guillaume Bourgeois]

I'm not saying that SP (Shared Parking) is not supported...
I'm saying that trying to transfer 2 calls to a SP (SharedParking) is theoretically not possible.

Do you want technical details?

There is a big difference between a call and a supervised call transfer.

In the SIP packet ((Invite)) you can see the difference.

CallFlow performs a supervised call transfer and maintains the call until the destination answers. However, the destination can establish conditions on the acceptance of an incoming call, such as ensuring that a Shared Parking does not accept 2 transferred calls.

If you bypass this with a workaround... it's not guaranteed to continue working in the long term.

Now, tell us why you need this, why automatically park a call and then retrieve it, with a CallFlow?

There might be another approach I can suggest...

What you're trying to do with a CallFlow, I designed it several years ago... and I removed everything for reliability reasons.
I found a better approach without Parkings and it works very well and is super reliable.

I was monitoring active calls via the CallControlAPI, and with a Call Pickup, I managed to conference a call that was in Parking with a call that was in CallFlow.

But, is it reliable? I had plenty of scenarios where... the 2 calls were disconnected instead of being connected.

Obviously, I would add patches to cover each special scenario... in the end, I got lost in my own code.. with lots of conditions.. and ended up introducing new bugs.

So, advice, let go of this strategy unless you want something unreliable.

Before I reveal my new recipe, I want to know if it will suit you.

So, why do you want to park a call with a CallFlow, then retrieve it via a CallFlow? There must be a reason, otherwise, you would use an parking orbit, not a CallFlow ?...
https://www.3cx.com/blog/docs/call-parking/

 

[benrg]

Thank you for the details.

So, why do you want to park a call with a CallFlow, then retrieve it via a CallFlow? There must be a reason, otherwise, you would use an parking orbit, not a CallFlow ?...
https://www.3cx.com/blog/docs/call-parking/

I have users who start their call on a device, and want to grab it on another device. Mobile device included.
There's no such feature for now (feat req here) (note that Wazo.io has such a feature, Call Flip).
And there's no Shared Parking option from mobile apps (feat req here).

We already have the SP BLFs on SIP devices, also on Web/PWA apps.
We also have the right-click Park option from the Web/PWA apps.
I then though about adding SP to mobile apps thanks to a CFD app :
- a call is transferred to this CFD app : the call is parked into the first available SP room (works like a charm) ;
- a call is made to this app : if you have a SParked call, you grab it.
Would then work whatever the SIP/Web/PWA/mobile device used, BLF/right-click/CFD-app option used.

CallFlow performs a supervised call transfer and maintains the call until the destination answers. However, the destination can establish conditions on the acceptance of an incoming call, such as ensuring that a Shared Parking does not accept 2 transferred calls.

Makes sense, and could explain my previous results.

If you bypass this with a workaround... it's not guaranteed to continue working in the long term.

Of course goal is not to go for a workaround.
I then worked on other possible solutions for the unpark part :
- I tried to join the incoming CFD app call and the SParked call (ReplaceWithPartyOf), but my various tests fail ;
- I found the solution to drop the incoming CFP app call, and to immediately transfer the SParked call to its extension. It works, but it's a 2-step operation, I would have preferred a seamless join operation.

Still thinking about other ways to go.

Note that we could ask users to transfer the call to themselves. But the accept multiple calls option is not... an option
I could try to use parking orbit, but it would then be decorrelated from the Web/PWA right-click park option, and I may face the same non-seamless join limitations.

If you think about other ways to go, or a way to seamlessly join the 2 calls (incoming CFD-app call and SParked call), of course feel free

Thank you again !

 

[Guillaume Bourgeois]

Ah! There it is! Now it's very clear. I understand better what you wish and the reason.

I might have an idea, let's explore together. I'm not saying it will work but let's examine what we could do.

Before studying an automation solution, let's start by exploring the different manual solutions and if one of them meets the final objective, we could then analyze how to automate it to simplify its use.

Have you thought about "conference call"?
It's not a joke, sometimes we search so far for addressing a problem perceived as immense that we forget the basics solutions.

Step by step;

Example:
The user has extension number 101
The conference can be joined at extension 700

The user answers with a phone, then transfers the caller to 700**101

The caller will hear conference hold music until another call joins the conference.

Then, via another SIP device with the same extension number, he calls back 700**101, would that work?

And in the case where he wants to continue a call on his mobile phone via GSM line (non-application), the user calls his cellphone and then transfers the call to 700**101 !

That's exactly what it's for!
It's a private conference and is intended to be able to link multiple calls together..

If you like, we could analyze how to simplify the process for your users.

 

[Evolute IT]

If they just wanna swap device, they can transfer the call to themselves (same extension) and other devices will ring instantly to pick it up wherever they want. No need for parking or CFD or anything like that.

* Must have "accept multiple calls" enabled, obviously.

 

[benrg]

Thank you to both of you for your replies !

If they just wanna swap device, they can transfer the call to themselves (same extension) and other devices will ring instantly to pick it up wherever they want. No need for parking or CFD or anything like that.

* Must have "accept multiple calls" enabled, obviously.

Unfortunately, enabling it is not an option

Before studying an automation solution, let's start by exploring the different manual solutions and if one of them meets the final objective, we could then analyze how to automate it to simplify its use.

Better to use built-in solutions / options, I agree.

Have you thought about "conference call"?
It's not a joke, sometimes we search so far for addressing a problem perceived as immense that we forget the basics solutions.

To be fair, no.

Example:
The user has extension number 101
The conference can be joined at extension 700

The user answers with a phone, then transfers the caller to 700**101

The caller will hear conference hold music until another call joins the conference.

Then, via another SIP device with the same extension number, he calls back 700**101, would that work?

You're right, this technically works.
And we have sort of seamless solution joining the conference from the other device, which is nice.
There is a drawback though, which is due to conference mode itself. There is clearly the risk you stated before, which is to join various callers together (well, this is a conference, so should be taken as an opportunity). But we can't force the caller to leave the conference at the end of the conversation : you hang-up, but the caller stays online (he loves your onhold music ). You transfer a new caller to the conference, the previous one will be able to listen to the conversation. Well, tricky / edge case I admit... But would not like (my customers) to face it

If you like, we could analyze how to simplify the process for your users.

I think we would have thought about a way to automatically add the **<ext> to the composed number, so that everyone would have easily reached his own private conference, making the whole process as simple as possible. Perhaps this is what you thought about.

Thank you again !

 

[Evolute IT]

Sounds like you're making this complicated for no reason but okay.

 

[Guillaume Bourgeois]

You're really taking the caller scenario to the extreme, especially since 3CX limits the duration of a call to a maximum of 180 minutes. So, in an extreme scenario, after a total of 3 hours, the caller would be disconnected.

Anyway, here's an alternative:

In connection with the solution proposed by @ConceptsWeb .

If they just wanna swap device, they can transfer the call to themselves (same extension) and other devices will ring instantly to pick it up wherever they want. No need for parking or CFD or anything like that.

* Must have "accept multiple calls" enabled, obviously.

Unfortunately, enabling it is not an option

Ok.. the Available status doesn't accept simultaneous calls.
But.. the Custom1 status (Available #2) could accept simultaneous calls.

So, just before transferring the call to their own extension, they simply need to change their status to Custom1, answer on their other device, and then switch back to Available.

Help us help you. There need to be some compromises.

 

[edossantos]

Transferring a call to a Shared Parking slot already busy will not pick the call up. That's something that works for extensions because the call manager verifies that the destination is busy, and performs the pick up in that case. But that's not what the CFD app will do. The CFD app will blindly transfer the call because that's what you're asking.

 

[benrg]

Many thanks for your reply @edossantos, makes things clear
Is there then any way for a CFD app to pick a SParked call up, and merge / join it with the incoming call (the one which triggered the CFD app) ?
PhoneSystem.Root.PickupCall + <ActiveConnection>.ReplaceWithPartyOf ?
Thank you again for your support !

 

[tronic]

I think all they are asking for is the option to dial a code to unpark a SP call.

I had parking issues on a few v20 upgrades and for me upgrading to Beta 1 in V20 fixed there parking issues.