Connect. Communicate. Collaborate. Securely.

Home » Kerio User Forums » Kerio Operator » Parking calls on same slot connects both callers
  •  
nhoague

Messages: 846
Karma: 18
Send a private message to this user
Hello,

I believe we have encountered a nasty bug in Asterisk. When two external callers are parked on the same park slot, the two callers get connected and drops the call from asterisk!

Scenario: customer calls into business. Jennifer answers and parks the caller on Johns extension (*5200). Another customer calls in and Derrick parks the call on Johns extension (*5200). Now both customers get connected and are talking to each other and as you can imagine utterly confused!

I've done extensive research on this and it appears it is how asterisk is parking the call. I've also found information such as being able to configure a parking ext with multiple parking slots.

Can this be accomplished? Modify the asterisk config? I know operator has a read only file system, but can I boot in rescue mode and write changes to the asterisk config?

http://www.voip-info.org/wiki/view/Asterisk+call+parking
  •  
Vladimir Toncar (Kerio)

Messages: 1696
Karma: 39
Send a private message to this user
Hi Nick, we will try to reproduce this. If it is an Operator bug, we will fix it soon. If it is an Asterisk bug, we will try to fix it as well - we already have some experience in that direction.
  •  
M. Steinhauser (Kerio)

Messages: 187

Karma: 5
Send a private message to this user
Hi!

You are right... :-/ For external numbers both callers are connected together if/when they are parked with same code.

I reported this bug to developers. We will try to fix it as soon as possible.

Thank you very much for reporting!

Martin

______________________________
Martin Steinhauser
tester
Kerio Technologies
  •  
nhoague

Messages: 846
Karma: 18
Send a private message to this user
Thanks guys!!!

I haven't tested it with internal calls parking on same slot, but I would guess it does the same. I'll test that when I get to the office.
  •  
Vladimir Toncar (Kerio)

Messages: 1696
Karma: 39
Send a private message to this user
Our test shows that the error happens when you park two external calls to the same slot. It does not happen if you try to park two internal calls.
  •  
nhoague

Messages: 846
Karma: 18
Send a private message to this user
Actually it does fail on internal extensions as well.

Scenario: Erik (108) dials 101. I pick up 101 and park him on *5110. Ray dials 101, I pick up and park him on *5110. Now Ray and Erik are joined and 101 is out of the loop!

I am happy to do whatever I can to help troubleshoot this situation.
  •  
nhoague

Messages: 846
Karma: 18
Send a private message to this user
Update: I found that this does exist in the asterisk features.conf:

parkext => *5
parkpos => 1000-1999

And if I change the parking extension in the GUI and the number of digits, I can make it this:

parkext => *2
parkpos => 10-19

And this is exactly what I've been reading about. So why can't we just go back to the way it was, previous to getting hold music from the system.

i.e. User parks a call on *5, the system announces to the user the slot it is parked on, say 108, then the user can announce that a call is parkeed on 108 for a certain recipient. The next time a call gets parked the system would use the next available slot, and announce to the User 109.

Thoughts? and Thanks!
  •  
Filip Jenicek (Kerio)

Messages: 1072
Karma: 78
Send a private message to this user
Hi,

I don't find the implementation of asterisk's parking lot very user friendly. You are forced to listen to the parking lot number. You have to pay attention and capture all digits. Parking using blind transfer is not possible.

When implementing parking in Operator we decided to take a different approach and have the user choose the parking lot position. In order for this scheme to work, you must assign your users unique parking lot numbers. There is a suggestion in <http://kb.kerio.com/1030> to use the same parking position as the number of your extension.

Attended transfers can indeed bridge two remote callers. The problem with the attended transfers is that when a phone does an attended transfer it actually puts the first call on hold, creates a brand new call and once user hits the transfer button, the phone bridges the two calls together. Operator has no idea that there will be a transfer, it just sees "Hold #1", "Dial #2", "Bridge #1 and #2". So it unparks the parked call and then bridges the two remote callers. Unfortunately, this is not fixable.

When doing a blind transfer, the situation is a little bit different. Operator is able to detect the "collision" and the call should bounce back. Some phones are unable to recover and hang up. There is a some space for improvement, the call could ring back.

We may have found out a solution for the future versions of Operator. There could be two pbx services, one for parking and another one for unparking. The collision could then not happen.

Filip
  •  
nhoague

Messages: 846
Karma: 18
Send a private message to this user
Hi Filip,

Thank you so much for your attention to this matter!

I have tested the blind transfer to a slot that is currently in use, and you are right, the call simply gets lost, so blind transfer to a call park is not a solution.

I do understand why two external callers get connected when transferring to an existing slot, cause the system is doing exactly what it is supposed to be doing, connecting the call to the transferred slot! As if someone internally dialed the slot and picked up the call.

I'm unsure of how the two services would work, since we'd still have to know what slot the call is parked on? Or if the same slot can be used, would the service to pick up the parked call know the order they were received? FIFO?


Honestly, I would like to see the solution be that Operator announces the slot number. In reality its only 3 digits and anyone (competent) person should be able to remember 3 digits and immediately announce over the intercom that a call is parked on 715 (or whatever it be!).
  •  
nhoague

Messages: 846
Karma: 18
Send a private message to this user
Hey guys, any update? Thanks.
  •  
Filip Jenicek (Kerio)

Messages: 1072
Karma: 78
Send a private message to this user
I will be honest, not much. There are other things we have to focus on. We don't plan to take the voice prompt approach. Feel free to use uservoice to change it.

The idea with two services is simple. One service will be used to park a call, another one to unpark it. If you try to park a call to a position which is already occupied, the transfer will fail and you will need to try again. Thus the collision would never occur.

My best advice for now is to instruct users to use a unique parking position. For example use positions same as their extension number.

In a quite common case where there is a receptionist, who needs to use multiple parking positions, I suggest you to take an advantage of BLF buttons to monitor the parking positions. I believe it is more convenient for a receptionist to park the call by pressing a button to a known position than having her to always listen to a voice prompt.
  •  
nhoague

Messages: 846
Karma: 18
Send a private message to this user
I appreciate you being honest. I'm bummed to hear that this is not priority. I'm going to be forced to remove Operator and put something else in place due to this. Sad

There are too many people that take calls for everyone that trying to manage one slot per person will not work. I.e there are three receptionist that take about 400 calls / day. For them to try to manage call park slots with BLF for 20 salesman just won't happen.

Please let me know if you change your mind as this currently means I have to replace their system.
  •  
Brian Carmichael (Kerio)

Messages: 579
Karma: 57
Send a private message to this user
What about using queues rather than parking slots?

Brian Carmichael
Senior Technical Marketing Engineer | Kerio
Stay Connected Anytime, Anywhere. Discover Kerio Cloud!
  •  
nhoague

Messages: 846
Karma: 18
Send a private message to this user
Hey Brian, the queue idea is working but it's very minimal workaround. I understand the theory but for the users it doesn't work well.

Question, in the asterisk config I can see the option to enable call park slots. Is there any way at all I can modify the configuration? I know operator is a read only file system but if I could make one change I think I can make asterisk do what I want it to. Thoughts?
Filip Jenicek (Kerio)

Messages: 1072
Karma: 78
Send a private message to this user
Unfortunately not, the asterisk's parking lot functionality is patched to work the way I described.
Previous Topic: Kerio Operator & Gigaset Pro
Next Topic: Yealink EXP38
Goto Forum:
  


Disclaimer:
Kerio discussion forums are intended for open communication between forum members and may contain information and material posted by members which may be useful in learning about Kerio products. The discussion forums are not intended to provide technical support for any specific product. Any information implied or expressed in the discussion forums is that of the posting member. Kerio is in no way responsible for the information posted in the forums, or its accuracy. Kerio employees may participate in the discussions, but their postings do not represent an offical position of the company on any issues raised or discussed. Kerio reserves the right to monitor and maintain the forums to promote free and accurate exchange of information.

Current Time: Wed Jan 18 15:05:35 CET 2017

Total time taken to generate the page: 0.01169 seconds
.:: Contact :: Home ::.
Powered by: FUDforum 3.0.4.