Because the unlicensed RF Spectrum that WiFi uses can be interrupted by anything. I have a location where the wireless (not WiFi!) handicapped-door open-button will cause the WiFi credit card machine closest to it to temporarily go offline for a few seconds. A door button.... Web browsing...
I only do this for home users, or those who want to use their own personal Bluetooth headset. I would never do a multi-endpoint rollout of WiFi phones.
My guess is that your VPN client credentials (username) don't permit access to the vLAN the IPO is on. Have whoever manages that Palo Alto fix that and I'm sure you'll be fine.
I can say that with 12.0.56 Time Profiles added are completely ignored. (observed on 3 different systems). 12.0.55 didn't do license checks, which is why it's gone from download availability completely.
If you mean on the IPO Linux server itself, just don't. Whether a virtual machine or bare-metal, just don't.
Once you do, it all becomes unsupported by both your Avaya BP and Avaya Support themselves. Any update(s) can replace system files, and if an XDR product changes ANYTHING about those...
Page 9 it literally says "• Avaya only supports IP Office virtual machines created using the virtualized server images supplied by Avaya."
I see it does show updating via ISO, but It's been my experience that v12.0 is actually v11.notreallyworking.1.goodluck
I had to create a backup and deploy...
...to the WAN (assuming no VPN tunnel exists here). I'd also have them show you screenshots proving SIP-ALG Transformations are disabled and that Consistent-NAT is enabled. (my line of thinking is that if these *did* work, but now don't, a firewall update/patch could have changed things...
...-can't install as a virtual machine on vmware, as the required version of vmware would be too new to have hardware support for that server
-you *might* get away with installing Windows Server with Hyper-V role to allow a IPO_R12 virtual machine to work. It would most likely work, but no...
I've found the newest version of Workplace will only work if TLS is setup with a proper 3rd party certificate. It will *mostly* work if TLS is completely disabled (including the appropriate lines of 46xxsettings.txt edited)
Discover x.x.x.x is always a routing/firewall issue.
What device is routing between the vLANs? Are there any NAT/firewall/security rules between these vLANs?
What's your "IP Route" look like in the IP Office?
...Mask= 255.255.255.0
Gateway= 10.0.8.1
Destination= LAN2
Metric=5
....assuming that 10.0.8.X/24 is the data network where LAN2 of the IPO lives.
*obviously if the subnets are smaller or larger than the /24, the subnet masks will need to be different.
With that said.....I'm going to assume...
I don't use Meraki, but for what I do use (using one DHCP server for everything), I have to have one DHCP Option 242: L2Q=1,L2QVLAN=10,VLANTEST=0 (this tells the phones to reboot and jump on vLAN10)
...and then another DHCP Option 242 specifically for vLAN10...
I'm kind of stuck on an issue and request the assistance of the group here.
I have a few IPO systems in an SCN, all 500v2 chassis, v12.0. All phones are IP, mostly J179s with some 9600s still hanging about.
I am attempting to move users from the remote systems to the "main" system at HQ...
Not supported means they won't support it. It *may* work. But if it doesn't, then it's all up to you to figure out why.
If this is for any regulated industry, they you need to update those ESXi servers anyway.
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.