Author Topic: Delay on phones  (Read 3975 times)

Offline Hershel

  • Full Member
  • ***
  • Posts: 154
  • Country: ca
  • Karma: +1/-0
    • View Profile
Delay on phones
« on: November 10, 2015, 02:36:39 PM »
I have a client who is experiencing delays on their 5000.

"I’ve noticed increasing frequency and length of delay on the phone.  Delay to get a dial tone; delay to make the phone connection; delay in transmitting voice."

They are running 5000 HX
4 digital phones
v 6.0.11.113

I have noticed that they CPU usage seems to be quite high for a small system.  50-70% at the moment with no active calls.
AND a couple of weeks ago they had a voicemail channel failure & voice mail system link down.  A reboot of the system seemed to clear up those issues.

Thoughts?


Offline acejavelin

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4064
  • Country: us
  • Karma: +129/-0
  • High-tech, heavy metal redneck!
    • View Profile
    • Like what I do and wanna help out? Send me a donation!
Re: Delay on phones
« Reply #1 on: November 10, 2015, 04:58:12 PM »
SSH into the controller when it is bogging down and go to the command line and type 'top' and press enter twice

Look at the resulting form, it is updated in real-time (every second I believe), it will show the highest CPU usage at the top dynamically, look at %CPU and Command column

These are the processes/commands you will see and their associated function in the system:

Avdap = voicemail
RO = Call Processing
Perl = SysAD
MP3 = They are running MP3 with forward and copy
IPRA = IP applications
SSH = SSH, if it is high most likely someone is trying to hack the system

Report back what you see... Should look something like the attached file, just press Q to exit and type exit<enter> to return to DMU and exit normally.

« Last Edit: November 10, 2015, 05:00:38 PM by acejavelin »

Offline Hershel

  • Full Member
  • ***
  • Posts: 154
  • Country: ca
  • Karma: +1/-0
    • View Profile
Re: Delay on phones
« Reply #2 on: November 13, 2015, 10:51:20 AM »
SSH into the controller when it is bogging down and go to the command line and type 'top' and press enter twice

Look at the resulting form, it is updated in real-time (every second I believe), it will show the highest CPU usage at the top dynamically, look at %CPU and Command column

These are the processes/commands you will see and their associated function in the system:

Avdap = voicemail
RO = Call Processing
Perl = SysAD
MP3 = They are running MP3 with forward and copy
IPRA = IP applications
SSH = SSH, if it is high most likely someone is trying to hack the system

Report back what you see... Should look something like the attached file, just press Q to exit and type exit<enter> to return to DMU and exit normally.

SSH was the issue and we have corrected the issue by closing up that port. 

Offline acejavelin

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4064
  • Country: us
  • Karma: +129/-0
  • High-tech, heavy metal redneck!
    • View Profile
    • Like what I do and wanna help out? Send me a donation!
Re: Delay on phones
« Reply #3 on: November 13, 2015, 10:59:31 AM »
SSH into the controller when it is bogging down and go to the command line and type 'top' and press enter twice

Look at the resulting form, it is updated in real-time (every second I believe), it will show the highest CPU usage at the top dynamically, look at %CPU and Command column

These are the processes/commands you will see and their associated function in the system:

Avdap = voicemail
RO = Call Processing
Perl = SysAD
MP3 = They are running MP3 with forward and copy
IPRA = IP applications
SSH = SSH, if it is high most likely someone is trying to hack the system

Report back what you see... Should look something like the attached file, just press Q to exit and type exit<enter> to return to DMU and exit normally.

SSH was the issue and we have corrected the issue by closing up that port.
Unfortunately that is a common one... Best to keep it closed to the public, or limit the IPs that can access it. Phone techs sometimes don't understand network security implications and some It people just do what they are told/asked without question (port forward this port to that IP)...

Anyway, glad you got it taken care of!

Sent from my MotoG3 using Tapatalk


Offline Hershel

  • Full Member
  • ***
  • Posts: 154
  • Country: ca
  • Karma: +1/-0
    • View Profile
Re: Delay on phones
« Reply #4 on: November 14, 2015, 02:27:54 PM »
If all you want is remote access to DB programming and live monitoring do you only one those two ports? And is it still a good idea to limit the IPs that have access

Offline acejavelin

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4064
  • Country: us
  • Karma: +129/-0
  • High-tech, heavy metal redneck!
    • View Profile
    • Like what I do and wanna help out? Send me a donation!
Re: Delay on phones
« Reply #5 on: November 14, 2015, 06:49:33 PM »
If all you want is remote access to DB programming and live monitoring do you only one those two ports? And is it still a good idea to limit the IPs that have access
For most installation, we do a port forward of 44000 and 8443 to the Mitel 5000... and change the SSL port of the 5000 to 8443. The only exception being if they actually use the web interface of the 5000, then the solution varies by need. The SSH port is only port forwarded if we can restrict the IP range from our corporate subnets, but in general we don't open that port.

Unless changed, the system needs these ports for remote access (not phones)

44000/TCP - DB Studio, this is the only port needed for programming. Completely safe to leave open to the public, assuming you have a reasonably complex password.

443/TCP - Used by System Admin & Diagnostics and web page (https), this is often remapped to 8443 for security reasons. Remember to change it in connection settings, you have to enable Show Ports in advanced settings. It is generally safe to leave 8443 open to the public but has some potential security risks (although as long as your passwords are reasonably complex, it is relatively safe to leave open). Without this you cannot get advanced monitoring but still can get SMDR, backups, system output (not logs) since they use 44000/TCP. Port 443 can be safely forwarded if you can restict it's access to a certain IP range(s)

22/TCP - used for SSH connections, in open "port forwarding" situations it is a door for hackers and it should be left open unless it can be restricted to only certain IP addresses (like your corporate public IP range). In general, if you need to access this tool, you should be onsite or for the occasional thing you can take control of remote users PC with something Teamviewer and use portable putty if you can't install the full version due to domain security.
« Last Edit: November 15, 2015, 11:14:26 PM by acejavelin »


 

Sitemap 1 2 3 4 5 6 7 8 9 10