Unable to pick up calls from shared parking randomly

[onlineaccess]

I'm having an issue where randomly calls that have been placed into shared parking are not able to be picked back up from anyone.

I have set up our phones to have Shared Parking extensions on the phone's BLF that we use to park/pickup calls and for the most part this works with no issue, but occasionally (once or twice a day) the call seems to get lost but the call still shows as being connected and in the shared parking

This started about a week or so ago and there have been no changes/updates to the phones or the 3CX system itself.

Monday I noticed that some of our phones had out-dated firmware. I updated all phones to the latest version and rebooted them all and it seemed to have worked for one day, but then this morning we had it happen again.

 

[Alphabetic]

check you reply back with support info requested from the pinned post pls

 

[onlineaccess]

3CX Version - 16.0.910
Server OS - Debian 9
Is the 3CX Server Hosted? - Yes, Google Cloud Platform
IP Phone Make/Model/Firmware - Yealink SIP-T29G, firmware: 46.83.0.130
Provisioning Method - Direct SIP (STUN)
Trunk Provider - VoIP Innovations
Has the firewall checker passed - It shows a green check on the dashboard, but I cannot check until after hours as it requires services to be stopped. I will update later once I can run the test
Are custom Phone Templates being used - no

 

[Alphabetic]

How many phones we talking?

have you given each phone its own local SIP port and respected RTP ports, along with static addresses and port forwarded said ports to the relevant handsets?

 

[onlineaccess]

In total, there are 17 handsets

They all have their own SIP and RTP ports, although the phones do not have static IPs

we don't have any issues besides the shared parking problem noted in the original post, so I believe that the port forwarding is all set up correctly

 

[Alphabetic]

If you haven’t got static IPs where do you expect your port forwarding to go?

 

[ppickens]

In total, there are 17 handsets

They all have their own SIP and RTP ports, although the phones do not have static IPs

we don't have any issues besides the shared parking problem noted in the original post, so I believe that the port forwarding is all set up correctly

The phones should never need static IPs in this instance. I'm just running into this for a client with one phone remotely as well. When trying to retrieve the call packet captures show the phone respond to PBX with a "SIP/2.0 481 Call Leg/Transaction Does Not Exist". If I find something to fix this on my side, I'll let you know!

 

[onlineaccess]

After running the Firewall checker, it appears that all ports after 10742 were being blocked. We have since opened up the remaining blocked ports and am hoping that this resolves the issue.

If we still run into the issue again, I'll update this post.

@ppickens - Any information you find would be appreciated, thanks!

 

[ppickens]

@onlineaccess - I can tell you those ports are just RTP ports. They should only pertain to audio transmission after the SIP setup. Those definitely should be opened up as they could cause one way/no audio if not opened though.

 

[ppickens]

Testing with a T42G from a different network did not replicate. @onlineaccess Do you happen to have other models to test on your current setup?

 

[onlineaccess]

Testing with a T42G from a different network did not replicate. @onlineaccess Do you happen to have other models to test on your current setup?

Almost all of our phones are a model T29G, although we do have a couple T27G, the users that have a T27G do not use shared parking so I am unsure as to whether the problem is linked to that particular model.

Unfortunately, I am not able to reproduce the issue myself and it only happens randomly. So far there have been no problems today

 

[ppickens]

Looks like this one was just a SIP ALG issue (client with a home office, so the first time looking at their network), so I don't think that's what you're running into at this point. I would check to see if the ports on the phone get manipulated by the router/firewall on the STUN phones side though.

 

[onlineaccess]

We're on day two without an issue, fingers crossed that opening the ports has fixed this.

Appreciate all the help on this and will be back here again if we run into the problem again