Q: Share Park <> vs Call Xfer <> reliability / consistency ?

[fortech]

Hi,

I've got 2 clients who are on small 3cx PBX setups, more or less as discussed in this old thread
https://www.3cx.com/community/threa...te-sbc-shared-parking-call-park-issues.77879/

Clients are using GXP2135 or GXP2170 handsets, and an on-site SBC box to act as gateway to a 3cx PBX running on Openstack public cloud (OVH montreal data centre)

I've got BLF buttons on the phones programmed so users can see status of each other, and also the SP1/sharepark is configured.

One site who was setup in Fall.2020 complained about reliability/inconsistency with SP so after some debug and troubleshoot, I just gave up and removed SP / since all they really wanted was call transfer anyhow. They simply complained that SP didn't work consistently / they had trouble retrieving calls from SP.

I have another client who was setup more recently (about 2 months ago) and they are now giving me similar sounding compaints, ie, SP works fine 90% of the time, and 10% of the time callers complain they are dropped and have to call back. So the client site is not so much happy/trusting the SP feature. want me to dig in and debug. I will do so / and maybe there will be clear log messages in the 3cx instance about what happened to the call. Likely I will need to generate some known examples (ie, make 10 test calls / hope one of them fails on a park), while I am paying attention to logs on the server.

The fact they are claiming ~90% success implies they know how to do the key sequence / workflow / to get a SP / parked call 'parked' and 'un-parked'. I think. Although I do realize human error is also a thing. But..

Wanted to post to forum, ask if this rings a bell for anyone, or if there are known issues / interactions where SP can be less reliable / calls are dumped / etc ?

Many thanks,

Tim

 

[YiannisH_3CX]

Hi @fortech

I do not recall seeing other complains about this but if you do manage to replicate the issue your best course of action is to open a ticket with our support department so they can have a closer look at this.
Make sure you are on the latest stable version.

 

[fortech]

OK, thanks for this feedback. I think my next step in this latest case, is to do some hands on debug testing with the primary end user of the handset. Based on review of call log on the 3cx PBX, it looks to me like we maybe have some 'bad button pressing' which could be the cause. ie, human error. But this is not entirely clear. The 3cx PBX is up-to-date on latest for sure. Phone handsets are running latest support firmware as well from 3cx. So that side of things should be good. Thank you for the followup. I will update this thread when I have more info. Client is out of office for a ~week so there is some delay likely I think.

 

[YiannisH_3CX]

Let us know if you have any further questions.

 

[fortech]

Hi, just quick followup on the thread. I did some test calling with client today, and
(a) things seem to work smoothly with their 3cx (latest) and Grandstream GXP2135 when doing an attended transfer > if the person getting the xfer declines the call / hangs up / the original person starting the xfer can use "hold" button to grab back the call and speak with caller. So this appears to give the desired workflow / call transfer flow that we need here.
(b) They confirmed that the SP1 method works 'perfectly, most of the time" but not 100% of the time.
ie, generally they can Transfer > SP1. Park the call. DIal to (another person, talk, discuss). Then other person can pull the call out of SP1/ or the original front-desk person can grab call off SP1 if the other person can't talk now.
The GLITCH - appears to be - in some cases, when the front desk hits XFER>SP1. The SP1 goes to RED (ie, has someone in the SP1) and the Reception person ext.100 also remains RED instead of being freed up. So then it is unclear to them what has happened, and the recovery of the SP1 person does not go smoothly after that. But this only happens rarely (ie, less than 10% of the time, but enough times in the last few weeks they feel uncomfortable using the Xfer>SP1 method now)

So. Not sure if I should ? submit this via email to 3cx support? (if I am even able to do that? as this client is using a non-paid 3cx free subscription) or if we're only entitled to forum comment feedback, that is cool as well. Just wanted to float an update on the thread / confirm that the AttendedXfer>HOLD recover call method appears a workaround here.

Thanks for all help / and for reading this far

Tim

 

[fortech]

Hi, a small update on this. Same client now reports to me a different glitch that I am having trouble getting my head around.

Scenario: External caller JohnDoe calls Jane on Reception / main office number. Jane checks if JACK is free internally via attended Xfer. Jack says "yeah, ok". Jane attempts to complete the attended transfer, and what ends up happening is that JohnDoe is dumped to JackVoiceMail; and JACK also is dumped to his own voice mail.

Apparently this has happened more than once in the last ~week. Approximate call volume is maybe 100 calls per week, ie, not high volume, but not zero volume.

Apparently the attended transfer works normally 'most of the time' and we've got maybe 2 failed call transfers in the last week being reported. In this case "Jane at Reception" insists that attended transfer button-press process being used is identical in all cases, there are no typos happening etc.

Just curious if anyone has an idea on how it could end up that an attended transfer 'splits' both parties to dump into voicemail
and/or any other thoughts on this fun situation.

Many thanks,

Tim