A member in thread690-1793551 claimed there was a way to clear an Avaya phone via a setting in the 46xxsettings file but never said how. Does anybody know? I have a "special" subnet my warehouse guys plug phones into to make sure they boot and have the newest firmware. I would love for that subnet to also clear the phone.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
CLEAR Avaya phone via settings file?
- Thread starter Sam O
- Start date
avayaguy23
Systems Engineer
I would recommend installing the diagnostic server. It has the ability to remote control the phone. You can then remotely connect to the phone by IP and navigate through the screens to factory reset it.
- Thread starter
- #4
With the Diagnostic Server's remote control ability, you can remotely "press" just about any key.. So yes, you can logout a station. It's not very fast but it works in a pinch. It doesn't work if the phone is behind a firewall, at least not in the normal "discovery" mode. There is a poorly documented Remote Agent mode where you can have the phone "register" itself to the server. Since the phone opens the connection toward the server, this might get past firewalls. The Remote Agent mode was really designed so you remote control a teleworker's phone. One downside is you need to expose the required ports on your Diag Server to the internet.
I would love to try it for my local phones as well, mostly because Remote Control is the only function of Diag Server I actually use. The Diag Server can also cause phones to generate synthetic voice traffic, monitor that and alert on quality issues. That's where it's ability to discover phones in subnets assigned to Zones comes into play. However, there are some serious limitation on how many Zones/Subnets you can have and we quickly outgrew it. We still use the remote control but have to add individual IPs to discovery as needed, which is kind of a pain and why I'd like to try setting all of my "local" phones up as Remote Agents.
Hey @avayaguy23, maybe you know if there's a limit on how many Remote Agents Diag Server can support. Can I register all of my 17K 9611s to it?
-Sam
I would love to try it for my local phones as well, mostly because Remote Control is the only function of Diag Server I actually use. The Diag Server can also cause phones to generate synthetic voice traffic, monitor that and alert on quality issues. That's where it's ability to discover phones in subnets assigned to Zones comes into play. However, there are some serious limitation on how many Zones/Subnets you can have and we quickly outgrew it. We still use the remote control but have to add individual IPs to discovery as needed, which is kind of a pain and why I'd like to try setting all of my "local" phones up as Remote Agents.
Hey @avayaguy23, maybe you know if there's a limit on how many Remote Agents Diag Server can support. Can I register all of my 17K 9611s to it?
-Sam
avayaguy23
Systems Engineer
It depends on how you deploy it. Are using a dedicated sla mon? I forget the specs but they can be found on the sla mon documentation. I use it to just scan subnets and potentially connect to one or two phones when troubleshooting. I have probably close 30k worth of ips loaded into it and works fine. You can also use it if there is a firewall between the phone and the sla mon. You just need to open up a couple ports. I think 5011 is the default.
- Thread starter
- #6
We are running a dedicated SLAMon server but the documentation, last I checked, didn't mention any limitations for the Remote Agent feature. As for firewalls, these are departmental firewalls I have no influence over. I figured the remote agent method would work better, since I think the phone keeps a HTTPS "tunnel" open to the server, allowing the connection back to the phone for remote control. But again, unclear how many phones the server can keep connections open for in this manner.
Not sure why your warehouse guys need to plug phones in to make sure they boot or why warehouse guys would even know what phone firmware is 
Let's say you had the warehouse and the office.
One day, you'll want to upgrade the phone firmware on the office phones. Are you going to bring them all down to the warehouse to upgrade to bring them back to the office?
Why wouldn't the office subnet be able to provide the same the same firmware?
SLAMon has a remote control capability, but your settings file needs to enable that. SLAMon (as a software component of Secure Access Link (SAL) / Avaya Diagnostic Server (ADS)) can tickle the phone to bring up a remote keypad as long as the device is on the network with an IP. It doesn't have to be registered to a call server. You can mute/CRAFT/# and hardcode a H323 or SIP server if you want. That probably won't help you.
What could help you is a 46xxsettings.txt file that wipes settings.
So...
If you CLEAR a phone, the values are all default.
Almost all values that can be set by a 46xxsettings.txt file are retained after reboot.
An example:
Warehouse VLAN DHCP 242 says HTTPSRVR=avaya.com, HTTPDIR=warehouse
Office VLAN DHCP 242 says HTTPSRVR=avaya.com, HTTPDIR=office
Phones on the warehouse VLAN request Phones on the office VLAN request
Pretend /warehouse/46xxsettings.txt has a line that says:
SET SIP_CONTROLLER_LIST=1.2.3.4:5061;TLS
Pretend /office/46xxsettings.txt has no line for SET SIP_CONTROLLER_LIST
If you booted a new/cleared phone on the warehouse VLAN for the first time and then brought it to the office VLAN, it would try to register to 1.2.3.4:5061
If you booted a new/cleared phone on the office VLAN for the first time, it would say SIP PROXY LIST EMPTY
The opposite is also true.
If you had a phone that had a setting acquired via 46xxsettings.txt that defined a SIP_CONTROLLER_LIST and booted it on another VLAN pointing to another settings file that had SET SIP_CONTROLLER_LIST = ""
Then that would blank out the value.
There are a bunch of settings that are "one of the following 5 options, but the default is option X"
For example:
#################### LAYER 3 QOS SETTINGS ##################
##
## DSCPAUD specifies the layer 3 Differentiated Services (DiffServ) Code Point
## for audio frames generated by the telephone.
## Valid values are 0 through 63; the default value is 46.
## Note: This parameter may also be set via LLDP or H.323 signaling,
## which would overwrite any value set in this file.
## This parameter is supported by:
## J169/J179 H.323 R6.7 and later
## J129 SIP R1.0.0.0 (or R1.1.0.0), J169/J179 SIP R1.5.0, J100 SIP R2.0.0.0 and later, J139 SIP R3.0.0.0 and later
## Avaya Vantage Basic Application SIP R1.1.0.1 and later; used in IP office environment only (for Aura environment
## DSCPAUD is taken from PPM and configured using SMGR)
## H1xx SIP R1.0 and later
## 96x1 H.323 R6.0 and later
## 96x1 SIP R6.0 and later
## B189 H.323 R1.0 and later
## 96x0 H.323 R1.0 and later
## 96x0 SIP R1.0 and later
## 16xx H.323 R1.0 and later
## SET DSCPAUD 43
If you had SET DSCPAUD "" in your settings file, I would think that it would blank out whatever value had been set for DSCPAUD previously and it would take the default value of 46 as defined by the parameter.
## Valid values are 0 through 63; the default value is 46.
That's to say that you can't necessarily "nuke" a phone via a settings file. It would go in a reboot loop because whatever it learned next boot would nuke it again.
But, if you wanted to set a bunch of settings to default, you could have a settings file on the warehouse VLAN that said SET $PARAMETER = "" and that would wipe out whatever each parameter was.
PAY ATTENTION: it will only wipe it out if it was set previously by a 46xxsettings.txt file. Settings defined manually on the phone override those from a 46xxsettings.txt file, so defining those parameters as blank in a settings file won't have any effect. You'd have to clear the phone manually.
But then again, if your warehouse boot the phones to check the firmware, why don't they just clear the phones from the menu manually by hand when they're done?
I guess what I'm really saying is "tell me what you're really trying to do"
Let's say you had the warehouse and the office.
One day, you'll want to upgrade the phone firmware on the office phones. Are you going to bring them all down to the warehouse to upgrade to bring them back to the office?
Why wouldn't the office subnet be able to provide the same the same firmware?
SLAMon has a remote control capability, but your settings file needs to enable that. SLAMon (as a software component of Secure Access Link (SAL) / Avaya Diagnostic Server (ADS)) can tickle the phone to bring up a remote keypad as long as the device is on the network with an IP. It doesn't have to be registered to a call server. You can mute/CRAFT/# and hardcode a H323 or SIP server if you want. That probably won't help you.
What could help you is a 46xxsettings.txt file that wipes settings.
So...
If you CLEAR a phone, the values are all default.
Almost all values that can be set by a 46xxsettings.txt file are retained after reboot.
An example:
Warehouse VLAN DHCP 242 says HTTPSRVR=avaya.com, HTTPDIR=warehouse
Office VLAN DHCP 242 says HTTPSRVR=avaya.com, HTTPDIR=office
Phones on the warehouse VLAN request Phones on the office VLAN request
Pretend /warehouse/46xxsettings.txt has a line that says:
SET SIP_CONTROLLER_LIST=1.2.3.4:5061;TLS
Pretend /office/46xxsettings.txt has no line for SET SIP_CONTROLLER_LIST
If you booted a new/cleared phone on the warehouse VLAN for the first time and then brought it to the office VLAN, it would try to register to 1.2.3.4:5061
If you booted a new/cleared phone on the office VLAN for the first time, it would say SIP PROXY LIST EMPTY
The opposite is also true.
If you had a phone that had a setting acquired via 46xxsettings.txt that defined a SIP_CONTROLLER_LIST and booted it on another VLAN pointing to another settings file that had SET SIP_CONTROLLER_LIST = ""
Then that would blank out the value.
There are a bunch of settings that are "one of the following 5 options, but the default is option X"
For example:
#################### LAYER 3 QOS SETTINGS ##################
##
## DSCPAUD specifies the layer 3 Differentiated Services (DiffServ) Code Point
## for audio frames generated by the telephone.
## Valid values are 0 through 63; the default value is 46.
## Note: This parameter may also be set via LLDP or H.323 signaling,
## which would overwrite any value set in this file.
## This parameter is supported by:
## J169/J179 H.323 R6.7 and later
## J129 SIP R1.0.0.0 (or R1.1.0.0), J169/J179 SIP R1.5.0, J100 SIP R2.0.0.0 and later, J139 SIP R3.0.0.0 and later
## Avaya Vantage Basic Application SIP R1.1.0.1 and later; used in IP office environment only (for Aura environment
## DSCPAUD is taken from PPM and configured using SMGR)
## H1xx SIP R1.0 and later
## 96x1 H.323 R6.0 and later
## 96x1 SIP R6.0 and later
## B189 H.323 R1.0 and later
## 96x0 H.323 R1.0 and later
## 96x0 SIP R1.0 and later
## 16xx H.323 R1.0 and later
## SET DSCPAUD 43
If you had SET DSCPAUD "" in your settings file, I would think that it would blank out whatever value had been set for DSCPAUD previously and it would take the default value of 46 as defined by the parameter.
## Valid values are 0 through 63; the default value is 46.
That's to say that you can't necessarily "nuke" a phone via a settings file. It would go in a reboot loop because whatever it learned next boot would nuke it again.
But, if you wanted to set a bunch of settings to default, you could have a settings file on the warehouse VLAN that said SET $PARAMETER = "" and that would wipe out whatever each parameter was.
PAY ATTENTION: it will only wipe it out if it was set previously by a 46xxsettings.txt file. Settings defined manually on the phone override those from a 46xxsettings.txt file, so defining those parameters as blank in a settings file won't have any effect. You'd have to clear the phone manually.
But then again, if your warehouse boot the phones to check the firmware, why don't they just clear the phones from the menu manually by hand when they're done?
I guess what I'm really saying is "tell me what you're really trying to do"
- Status
Similar threads
- Question