'lost/dropped' Parked calls

[focusonit]

If it possible to monitor a call park location to see why it was dropped/transfered/picked up

Our customers reporting that calls that have been parked are unable to be picked up while their customers are reporting the line has dropped after hearing onhold music for a short time.

We have setup monitoring buttons for the parked calls so we can see that the calls are being parked in the specified park locations.

[David Trad]

Hi Tim,

What phones is this happening on?

With the SPA-525G2 phones I was battling a massive issue with this, Symptoms to check with the client...

• Call drops and the screen does a quick refresh
• Call Drops and the phones goes blank and says it is resyncing
• Call Drops and all the buttons light up and the phone reboots

If you look up my previous post on this you will also see the CLI error message obtained when this happens, I had to try multiple firmware's to get it resolved and it was a nightmare as it was happening on multiple sites.

I had later discovered that this issue had also migrated to the 509G and 508G but the issue is not prominent with them as it was with the 525G2, this issue also gets worse when using the 500S add-on module.

Let me know if you need any help with this one, I think you have my mobile number anyway

Cheers,

David.

[focusonit]

No, no phone resyncing at all - in fact they watch the calls get dropped when it's parked.

They are handling many calls a minute so they would notice the phones restarting.

They are all 508s all with 500S add ons.

The phones trying to pickup the parked calls don't have sidecars

[David Trad]

OK So explain the process...

Is it like this?

I take call (A) and they want to speak to Tim (B), Now I place call on park slot 1 and advise you that the call is on there, and you press park slot 1 and pick the call up? (OR at least attempt too).

Can you explain the call flow topology please

Cheers,

David.

[focusonit]

Hi David,

Yes the receptionist(s) 'parks' 99% of incoming calls. (now via programmed keys on the 500s Park 101-105 so they can confirm they are parked - and/or still waiting to be picked up)

They then page to a group of people to announce the call is waiting for them.

Scenario one the call is dropped before timing out (and doesn't come back to the person who parked it) (timeout 6x 40 secs)

The call gets parked and dropped after about 10-20 seconds

The person trying to pick the call up gets the 'nothing there' tone - most people picking up parked calls don't have phones that 'watch' the parked calls like the receptionist do they simply key the park location to pickup.

eample - they are all the same as this.

ephone-dn 574

number 101 no-reg primary

park-slot timeout 40 limit 6 recall retry 120 limit 2

label Park 101

[David Trad]

Hi Tim,

Its an unusual way of doing things for a high volume ingress site, but I'll

hold back on that

OK so what we need to do is narrow down on the reception phone and debug

her/his mac, primarily all errors to see if the issue is occurring on the

ring back or for any other reason.

Then we need to isolate another phone, to which we debug the Mac on that

one when it tries to retrieve the parked call.

You may also might want to debug the voice ccapi but do that later as that

produces a lot of chatter.

The UC does not seem to be to good at the whole call park thing, much worse

than other systems, they really need to spend a little more time on this

feature and get it 100% right.

If this become a huge problem and we can't resolve it, then I have

alternative for you that might be considered by the client.

Cheers,

David.

"Sent from my Acer Iconia A500"