These ports are used for Manager and Status - this is acceptable to use for remote management and changes to customer systems if you do not have an agent/workstation available on the customer network. I would only recommend doing this IF you follow the following precautions:
1. Change ALL...
I am not forwarding the 50802-50812 BUT I have any learned that you will be hacked of course. For clients that we can get an agent (LMI/TeamViewer)that's what we do - otherwise if we have to we forward those ports but ONLY white-listing our IP so they won't get hacked.
Would you say it's safe...
Actually the inbound and outbound different IPs didn't matter. Changed to full cone nat and rebooted and it's working. Also put the ip in instead of letting stun pick up the outgoing ip. I have two way audio over voip.
It's showing the IP which is the outgoing IP on the Cisco (primary WAN IP) of course traffic coming in using the FQDN routes to a secondary IP in the same WAN subnet not sure if that causes an issue but I can't control that with Cisco.
I do have a 0.0.0.0 0.0.0.0 GATEWAYIP route. I have seen others use 255.255.255.255 I assume they accomplish the same thing not to get off topic.
What's odd is that I setup evening before PRI cutover and I was able to dial *17 and hit vm prompts now it connects and I get dead air. It DOES work...
I can make a call on the mobile app but have no audio. I am on the latest release and have a FQDN setup using Cisco Meraki firewall with 1:1 NAT on a dedicated WAN IP. I have all ports forwarded.
it took over 30 minutes - i just formatted the sd card and then rebuilding from the 9.0.12 manager files. after it comes back up i will wait 20 minutes or so and see if the phones come up...any other suggestions
After upgrading the phones are still searching for firmware. The upgrade completed successfully, there are 9508 phones and 1416 phones. manager is set to SD card and there are no apparent errors
After completing a call the system does not disconnect and plays a tone/hum. I have adjusted the settings in Manager 9.1 (upped the disconnect to 255) with no success.
The customer is complaining about DTMF not forwarding to various AA/IVR systems across the PSTN. We tried adjusting the Auto Gain Control setting and also verified they are using the handset when making calls.
Comcast came in and connected a TBIRD to the PRI to show the customer it's the Avaya...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.