Once resolved, please share the solution.
You’ll have to check with VitalPBX support on it. They were the ones that resolved it via terminal session to our install. Seems like it actually required an Asterisk upgrade to a version that VitalPBX doesn’t use by default.
Maybe they can comment.
Over the weekend, and even this morning until 10:39am, it was working great.
Now, it’s doing the same thing (“unregistered” & “PushSession” errors).
We were very excited, that it seemed to be working.
Now we have 900 users who are having problems, again.
Please reference Ticket ID: #563
900 WebSocket connections is ALOT. As far as I am aware, Asterisk’s strong point is not a heavy load of WebSocket connections. I suggest using a proxy like Kamailio to handle the connections.
It really looks to me like a resources/load issue, as it seems to me like it goes in and out.
A couple of things to look at:
- Monitor the CPU and Memory, see if it spikes.
- Check if your system is listening on port 8089.
netstat -a | grep 8089(Post the output) - Check the http status within Asterisk.
asterisk -x"http show status"(Post the output) - Check asterisk log as well as the /var/log/messages for any WebRTC/websocket/memory/CPU related messages
Good feedback PitzKey… a fellow-admin and I were talking about it and thinking it might be ‘load’ related too (as it’s been noticeably worse since all the teachers have returned for the new school year).
Will follow up w/you.
If you don’t mind, please post the server specs.
Well yeah 2 vCPUs are way too little resources for that many connections.
How many endpoints (SIP and WebRTC) and how many concurrent calls do you have on average and at max?
I was just going to ask… is there a report that can show that, historically?
Because I can usually see on the Dashboard that we tend to top out at about 150 PJSIP.
Also, curious… does a “re-ring” on a Call Q count as a “count” on a call? Or are those # of Incoming calls accurate? Seems high.
Not really. You can feed your AMI data to Grafana to keep track of registrations and calls.
Or, if the majority of your calls are queue call, then you can get a good picture of whats happening in Sonata Stats.
I am not sure, but I would assume that it is counted as an individual call from an Asterisk perspective.
Also, I am not familiar with DO, but looking at their pricing page, it seems that the $80 droplet will fit your needs better. Unless I’m missing something: Pricing Overview | DigitalOcean
We are using the $80 droplet. Upgrading to the $160 droplet.
Thanks for the tip on AMI/Grafana and Sonata Stats.
The $80 one I am referring to has 16gb Memory and 8 CPUs. The one in your screenshot above has only 2 vCPUs.
I’ve been watching some training videos by Fred Posner regarding Kamailio… and it looks like it’s meant to sit (ideally, at least) as an on-prem ‘end server’ between (Vital)PBX and the Inet.
Have you used it (or seen it used) w/a IaaS-based PBX, like we’re doing with DigitalOcean?
It’s designed to sit in front of the PBX, that’s correct. However, it does not need necessarily need to be on the same network. People usually do keep it on the same network for a lot of good reasons.
We use Kamailio and have hired Fred in the past, he’s a great guy and knows his stuff!
Edit to add: Kamailio is not designed to be able to be used in a single way. Kamailio can do hundreds of different things with SIP, starting from simple load balancing solution to complexed routing and ordinary header modifier.
…So with the scenario mentioned above, Kamailio is designed to sit in front of the PBX.
Out of curiosity - @JO_CPA @fnlauria and @AndrewF, Do you guys still have this issue?
If not, what changes have been made?
Thanks
Yes, it hasn’t been completely solved as we were still experiencing registration errors late yesterday afternoon, but we will see about today. We bumped up the maximum connections on 2 .conf files and have been having better results but isn’t completely fixed.
Thanks so much for your help! It’s truly appreciated.
Andrew
@PitzKey
Yes, the conf (connections increase) change that @AndrewF mentioned seems to have fixed the Webrtc issue, but not the SessionPush errors. I’ve followed up with VitalPBX on the existing ticket regarding this.
Thanks for ‘staying tuned’… we’ll update later.
1 Like
We’ve also been eagerly anticipating an updated iOS Vitxi mobile app (to get the Phonebook/Directory). Hoping that the Session Push errors get resolved soon.
We seem to have the same SessionPush on Android, but using Vitxi WebRTC on Android mobile (instead of the app) is an option. On iOS, security seems to prevent System Notifications in the browser, thus no audible ringing/vibe… so not really a workaround.
Hope the mobile issues are a VitalPBX setting that just needs corrected.
1 Like
We just released the VitalPBX mobile for iOS a couple of days ago; it uses the Apple APN for push notifications. You should give it a shot, just for testing purposes.
1 Like