G700 Troubleshooting Guide This guide provides resolutions for several categories of problems that could occur during installation, configuration, or maintenance of an Avaya TM G700 Media Gateway. Additional assistance If you cannot find the resolution to a problem using this Guide, you need to escalate the problem: • Before escalating an issue, please be sure you have tried all of the relevant suggestions in this guide to isolate the problem. • You should know whom to contact when you cannot resolve the issue. If you don’t know, please call 1-800-242-2121 in North America, or call your Avaya regional representative from other locations. Requirements As a user of this guide, you should have the following qualifications and access: • Qualifications : Avaya certified technician to perform G700 installation and maintenance. • Access : Know login, password, and access procedures with appropriate permissions. How to use this Troubleshooting Guide -- General Troubleshooting Strategy To use this Guide, please follow these procedures: 1. Get the basic information about the system: load, version, vintage, etc. a. Upgrade G700 to latest Generally Available (GA) software & firmware. b. Make sure that systems interconnected with the G700 have the correct installed minimum configurations. (please see ftp://ftp.avaya.com/incoming/Up1cku9/tsoweb/media/minhardwarevintages.pdf ) 2. Isolate the possible “root cause” based on the symptoms observed. First find the symptom listed (in left-most column) in the guide, then: i. For each symptom, there is a possible cause listed in the next column ii. Try each possible resolution (column to the right) for that cause iii. If the resolution does not clear the trouble or eliminate the symptom, then go to the next possible cause associated with that symptom (usually the next row) iv. Several different root causes may be associate with the same symptom 3. Be systematic, make only one change at a time and observe the results. a. Does the symptom persist? If so, proceed to the next possible cause. b. If the symptom disappears, check for cause and effect (reintroduce the change to see of symptoms re-appear). 4. Eliminate obvious and easy to verify causes first, like physical connections, (layer 1 and 2) before proceeding to more complex causes (layers 3 and higher). 5. Document all of the different troubleshooting steps taken. a. Precise and detailed information will help you when you escalate the problem. b. For example, you may want to print out this sheet and check-off each procedure that has been used. 6. Finally, you can compare “normal” settings of the equipment with the current parameter settings of the problematic equipment. If you find a difference between the “normal” settings and the problematic equipment, try changing the settings of the problematic equipment to match the settings of the “normal” equipment.
Transcript
G700 Troubleshooting Guide This guide provides resolutions for several categories of problems that could occur during installation, configuration, or maintenance of an AvayaTM G700 Media Gateway.
Additional assistance If you cannot find the resolution to a problem using this Guide, you need to escalate the problem:
• Before escalating an issue, please be sure you have tried all of the relevant suggestions in this guide to isolate the problem. • You should know whom to contact when you cannot resolve the issue. If you don’t know, please call 1-800-242-2121 in North America, or call your
Avaya regional representative from other locations.
Requirements As a user of this guide, you should have the following qualifications and access:
• Qualifications: Avaya certified technician to perform G700 installation and maintenance. • Access: Know login, password, and access procedures with appropriate permissions.
How to use this Troubleshooting Guide -- General Troubleshooting Strategy To use this Guide, please follow these procedures:
1. Get the basic information about the system: load, version, vintage, etc. a. Upgrade G700 to latest Generally Available (GA) software & firmware. b. Make sure that systems interconnected with the G700 have the correct installed minimum configurations.
(please see ftp://ftp.avaya.com/incoming/Up1cku9/tsoweb/media/minhardwarevintages.pdf) 2. Isolate the possible “root cause” based on the symptoms observed. First find the symptom listed (in left-most column) in the guide, then:
i. For each symptom, there is a possible cause listed in the next column ii. Try each possible resolution (column to the right) for that cause
iii. If the resolution does not clear the trouble or eliminate the symptom, then go to the next possible cause associated with that symptom (usually the next row)
iv. Several different root causes may be associate with the same symptom 3. Be systematic, make only one change at a time and observe the results.
a. Does the symptom persist? If so, proceed to the next possible cause. b. If the symptom disappears, check for cause and effect (reintroduce the change to see of symptoms re-appear).
4. Eliminate obvious and easy to verify causes first, like physical connections, (layer 1 and 2) before proceeding to more complex causes (layers 3 and higher). 5. Document all of the different troubleshooting steps taken.
a. Precise and detailed information will help you when you escalate the problem. b. For example, you may want to print out this sheet and check-off each procedure that has been used.
6. Finally, you can compare “normal” settings of the equipment with the current parameter settings of the problematic equipment. If you find a difference between the “normal” settings and the problematic equipment, try changing the settings of the problematic equipment to match the settings of the “normal” equipment.
Access to the G700 and S8300 The following diagram shows an Avaya™ G700 Media Gateway with an Avaya™ S8300 Media Server and the access methods for various configuration and maintenance tasks.
Comments If you have comments regarding this document, please email them to [email protected].
Possible fault with the Media Gateway Processor (MGP) or Media Modules. At least two fans have been operating at less than 90% of their nominal speed for five minutes or more. This may be an early warning of overheating.
1. Verify there are faults in the system. Use the Avaya™ G700 Media Gateway Processor (MGP) Command Line Interface (CLI) command show faults to display any faults on the G700. 2. If there is a temperature fault, check to see if the fans are working and/or if there is sufficient space around the G700 for air circulation. 3. Low voltage may be responsible for slower fans. Issue MGP CLI command show voltages to determine voltages for the Media Modules and other components of the G700. Voltage may be reduced by a short in one of the media modules or a bad power supply.4. Systematically, remove each media module to determine if one of the media modules is responsible for reducing the voltage levels. 5. If fans are faulty then replace the entire G700. Fans are not field replaceable.
Red LED on LED board is on. Minor Alarm is present.
Possible fault with the Media Gateway Processor (MGP) or Media Modules. The power supply fan has been operating at less than 90% of its optimal speed for 15 minutes or more. This may be an early warning of overheating.
1. Verify there are faults in the system. Use the Avaya™ G700 Media Gateway Processor (MGP) Command Line Interface (CLI) command show faults to display any faults on the G700. 2. If there is a temperature fault, check to see if the fans are working and/or if there is sufficient space around the G700 for air circulation. 3. Low voltage may be responsible for slower fans. Issue MGP CLI command show voltages to determine voltages for the Media Modules and other components of the G700. Voltage may be reduced by a short in one of the media modules or a bad power supply. 4. Systematically, remove each media module to determine if one of the media modules is responsible for reducing the voltage levels. 5. If fans are faulty then replace the entire G700. Fans are not field replaceable.
7/5/2002 4:35 PM
Alarms-LEDs-Traps G700 Troubleshooting Page 2
Symptom Root Cause Resolution
Red LED on LED board is on. Minor Alarm is present.
Possible fault with the Media Gateway Processor (MGP) or Media Modules. The temperature sensor at the CPU has exceeded its warning threshold.
1. Verify there are faults in the system. Use the Avaya™ G700 Media Gateway Processor (MGP) Command Line Interface (CLI) command show faults to display any faults on the G700. 2. If there is a temperature fault, turn off the G700 and let it cool; then, check to see if the fans are working and/or if there is sufficient space around the G700 for air circulation. 3. Low voltage may be responsible for slower fans. Issue MGP CLI command show voltages to determine voltages for the Media Modules and other components of the G700. Voltage may be reduced by a short in one of the media modules or a bad power supply. 4. Systematically, remove each media module to determine if one of the media modules is responsible for reducing the voltage levels. 5. If fans are faulty then replace the entire G700. Fans are not field replaceable.
Red LED on LED board is on. Minor Alarm is present.
Possible fault with the Media Gateway Processor (MGP) or Media Modules.The temperature sensor at the DSP complex has exceeded its warning threshold.
1. Verify there are faults in the system. Use the G700's Media Gateway Processor (MGP) Command Line Interface (CLI) command show faults to display any faults on the G700. 2. If there is a temperature alarm, turn off the G700 Media Gateway and allow it to cool. 3. If faults do appear, then resolve them by checking for fan alarms. 4. If it is a fan alarm, then check for voltage alarms. Issue the MGP CLI command show voltages to determine voltages for the Media Modules and other components of the G700. Low voltage may be responsible for slower fans. Voltage may be reduced by a short in one of the Media Modules or a bad power supply. 5. Systematically, remove each Media Module to determine if one of the Media Modules is responsible for reducing the voltage levels. Replace faulty Media Module.6. If fans are faulty then replace the entire G700. Fans are not field replaceable.
7/5/2002 4:35 PM
Alarms-LEDs-Traps G700 Troubleshooting Page 3
Symptom Root Cause Resolution
Red LED on LED board is on. Major Alarm is present.
Possible fault with the Media Gateway Processor (MGP) or Media Modules. The CPU temperature sensor has exceeded its shutdown threshold. The system is about to begin controlled shutdown
1. Verify there are faults in the system. Use the G700’s Media Gateway Processor (MGP) Command Line Interface (CLI) command show faults to display any faults on the G700. 2. If a temperature alarm, turn off the G700 Media Gateway and allow it to cool. 3. If faults do appear, then resolve them by checking for fan alarms. 4.If it is a fan alarm, then check for voltage alarms. Issue the MGP CLI command show voltages to determine voltages for the Media Modules and other components of the G700. Low voltage may be responsible for slower fans. Voltage may be reduced by a short in one of the Media Modules or a bad power supply. 5. Systematically, remove each Media Module to determine if one of the Media Modules is responsible for reducing the voltage levels. Replace faulty Media Module.6.If fans are faulty then replace the entire G700. Fans are not field replaceable.
Red LED on LED board is on. Major Alarm is present. The command show faults indicates that the fault in the Root Cause column is present.
Possible fault with the Media Gateway Processor (MGP) or Media Modules. The voltage reading at the +5.1v power source serving the MG Processor is out of tolerance.
1. Check for voltage alarms. Issue the MGP CLI command show voltages to determine voltages for the Media Modules and other components of the G700. Low voltage may be responsible for slower fans. Voltage may be reduced by a short in one of the Media Modules or a bad power supply. 2. Systematically, remove each Media Module to determine if one of the Media Modules is responsible for reducing the voltage levels. Replace faulty Media Module.3. If fans are faulty then replace the entire G700. Fans are not field replaceable.4. If the alarm clears in 10-20 seconds, it was a probable voltage spike. Do not replace the G700. 5. If a brown-out condition is suspected, use a power monitor to monitor the power line.
7/5/2002 4:35 PM
Alarms-LEDs-Traps G700 Troubleshooting Page 4
Symptom Root Cause Resolution
Red LED on LED board is on. Major Alarm is present. The command show faults indicates that the fault in the Root Cause column is present.
Possible fault with the Media Gateway Processor (MGP) or Media Modules. The voltage reading at the -48v power source serving the media modules is out of tolerance
1. Check for voltage alarms. Issue the MGP CLI command show voltages to determine voltages for the Media Modules and other components of the G700. Low voltage may be responsible for slower fans. Voltage may be reduced by a short in one of the Media Modules or a bad power supply. 2. Systematically, remove each Media Module to determine if one of the Media Modules is responsible for reducing the voltage levels. Replace faulty Media Module.3. If fans are faulty then replace the entire G700. Fans are not field replaceable.4. If the alarm clears in 10-20 seconds, it was a probable voltage spike. Do not replace the G700. 5. If a brown-out condition is suspected, use a power monitor to monitor the power line.
Red LED on LED board is on. Major Alarm is present. The command show faults indicates that the fault in the Root Cause column is present.
Possible fault with the Media Gateway Processor (MGP) or Media Modules.The voltage reading at the +3.4v power source serving the VoIP complexes is out of tolerance.
1. Check for voltage alarms. Issue the MGP CLI command show voltages to determine voltages for the Media Modules and other components of the G700. Low voltage may be responsible for slower fans. Voltage may be reduced by a short in one of the Media Modules or a bad power supply. 2. Systematically, remove each Media Module to determine if one of the Media Modules is responsible for reducing the voltage levels. Replace faulty Media Module.3. If fans are faulty then replace the entire G700. Fans are not field replaceable.4. If the alarm clears in 10-20 seconds, it was a probable voltage spike. Do not replace the G700. 5. If a brown-out condition is suspected, use a power monitor to monitor the power line.
7/5/2002 4:35 PM
Alarms-LEDs-Traps G700 Troubleshooting Page 5
Symptom Root Cause Resolution
Red LED on LED board is on. Major Alarm is present. The command show faults indicates that the fault in the Root Cause column is present.
Possible fault with the Media Gateway Processor (MGP) or Media Modules. The voltage reading at the +1.58v power source serving the DSP units is out of tolerance.
1. Check for voltage alarms. Issue the MGP CLI command show voltages to determine voltages for the Media Modules and other components of the G700. Low voltage may be responsible for slower fans. Voltage may be reduced by a short in one of the Media Modules or a bad power supply. 2. Systematically, remove each Media Module to determine if one of the Media Modules is responsible for reducing the voltage levels. Replace faulty Media Module.3. If fans are faulty then replace the entire G700. Fans are not field replaceable.4. If the alarm clears in 10-20 seconds, it was a probable voltage spike. Do not replace the G700.5. If a brown-out condition is suspected, use a power monitor to monitor the power line.
Red LED on LED board is on. Major Alarm is present. The command show faults indicates that the fault in the Root Cause column is present.
Possible fault with the Media Gateway Processor (MGP) or Media Modules. The voltage reading at the +2.5v power source serving the VoIP Processor is out of tolerance.
1. Check for voltage alarms. Issue the MGP CLI command show voltages to determine voltages for the Media Modules and other components of the G700. Low voltage may be responsible for slower fans. Voltage may be reduced by a short in one of the Media Modules or a bad power supply. 2. Systematically, remove each Media Module to determine if one of the Media Modules is responsible for reducing the voltage levels. Replace faulty Media Module.3. If fans are faulty then replace the entire G700. Fans are not field replaceable.4. If the alarm clears in 10-20 seconds, it was a probable voltage spike. Do not replace the G700. 5. If a brown-out condition is suspected, use a power monitor to monitor the power line.
7/5/2002 4:35 PM
Alarms-LEDs-Traps G700 Troubleshooting Page 6
Symptom Root Cause Resolution
Red LED on LED board is on. Major Alarm is present. The command show faults indicates that the fault in the Root Cause column is present.
Possible fault with the Media Gateway Processor (MGP) or Media Modules. Synchronization signal lost.
1. Check that provisioned clock-sync source has a good signal by issuing a Media Gateway Processor (MGP) Command Line Interface (CLI) command show sync timingProcedure for setting synchronization timing sources on E1/T1 MM or MM710:2. Be sure that the E1/T1 MM has been added properly on the Avaya™ S8300 Media Server or Avaya™ S8700 Media Server, otherwise go to System Access Terminal (SAT) and issue a ADD DS1 command before going to the MGP CLI and issuing a set sync interface or set sync source command. Otherwise the MGP CLI will not allow these commands to be executed.3. Go to the MGP’s CLI, and first specify the primary and secondary clock sources for synchronizing the E1/T1 span, using the set sync interface command. Note: You don't specify the internal clock source from the CLI - only the primary and secondary. The local clock is "built-in" and not provisionable.4. Issue a set sync source command to set to the specific MM710 E1/T1 Media Module to be used as the active clock reference.5. Verify whether or not these commands were executed by issuing a show sync timing command to ensure that the source is provisioned and active, or visually inspect the Yellow LED on the MM710 Media Module.
Note: When the Yellow LED is on 2.7 seconds and off 0.3 seconds, this means the tone-clocksynchronizer is in “active” mode, and an external synchronization source is being used as a synchronization reference. Setting the sync timing was successful.
When the Yellow LED is on 0.3 seconds and off 2.7 seconds, this means the tone-clocksynchronizer is in “active” mode and the internal (on-board) clock is being used as a synchronization reference. Setting the sync timing was not successful.
For more details, please consult the maintenance documentation under LEDs and E1/T1 Media Module; go tohttp://www.avaya.com/support and select Product Documentation.
7/5/2002 4:35 PM
Alarms-LEDs-Traps G700 Troubleshooting Page 7
Symptom Root Cause Resolution
Red LED on LED board is on. Unable to make calls.The command show faults indicates that the fault in the Root Cause column is present.
Possible fault with the Media Gateway Processor (MGP) or Media Modules. The H.248 link between the media gateway and its controller is down.
1. Check the Avaya™ S8300/8700 Media Server. If it is down, bring it up. 2. If the S8300/S8700 is up, check Avaya™ G700 Media Gateway administration. 3. If the G700 is correctly administered, then reboot the G700. 4. If the problem persists, please contact Avaya or your Authorized Avaya Business Partner.
Red LED on LED board is on. Warning is present. The command show faults indicates that the fault in the Root Cause column is present.
Possible fault with the Media Gateway Processor (MGP) or Media Modules. The media gateway is beginning automatic reinitialization.
If the problem persists, please contact Avaya or your Authorized Avaya Business Partner.
Red LED on LED board is on but no alarms are raised.
LED board is not making good contact with the backplane.
1. Verify there are faults in the system. Use the Avaya™ G700 Media Gateway Processor (MGP) Command Line Interface (CLI) command show faults to display any faults on the G700. 2. If no faults appear, then push the LED board in to make sure the backplane connector fully sits against the backplane. 3. If the problem persists, escalate.
7/5/2002 4:35 PM
Alarms-LEDs-Traps G700 Troubleshooting Page 8
Symptom Root Cause Resolution
Red ALM LED on the Avaya™ S8300 Media Server is on.
Possible fault with the S8300 or the connected Avaya™ G700 Media Gateway(s).
1. From Avaya Site Administration or the SAT issue the command display errors and verify if any active errors are displayed. 2. Verify there are faults in the system. Use the Avaya™ G700 Media Gateway Processor (MGP) Command Line Interface (CLI) command show faults to display any faults on the G700. 3. If no faults appear, verify if there are alarms in the Linux server. 4. If no alarms appear, escalate the problem.
Red ALM LED on the Avaya™ S8300 Media Server is on but no error exists on the S8300. The command display errors shows no major alarms.
Possible shutdown or initialization fault with the S8300.
1. From Avaya Site Administration or the SAT issue the command display errors and verify if any active errors are displayed. 2. Verify there are faults in the system. Use the Avaya™ G700 Media Gateway Processor (MGP) Command Line Interface (CLI) command show faults to display any faults on the G700. 3. If no faults appear, verify if there are alarms in the Linux server. 4. Shutdown and restart the S8300 to clear and reset the LED drivers.
a) IP Phone does not get Dial-tone b) No talk path between IP Phone and a DCP/Analog phone c) No talk path between IP Phone and a Trunkd) One-way talk path.
No VoIP resource available.
1. Check if there is an Avaya™ G700 Media Gateway or a prowler resource available with the right codec for the IP Phone,
using the SAT commands described in the Avaya MultivantageTM Administrators guide. 2. Issue a SAT command display events and look for a denial event (2049) for no available VoIP resource.3. If there is no resource, then administer one. 4. If there is a resource, then check for connectivity between the source and the destination using the ping command. 5. If the problem persists, then escalate.
a) IP Phone does not get Dial-tone b) No talk path between IP Phone and a DCP/Analog phone c) No talk path between IP Phone and a Trunkd) One-way talk path.
VoIP on Avaya™ G700 Media Gateway is insane.
1. Issue a SAT command display events and look for a denial event (2049) for no available VoIP resource. 2. Using telnet, go to the Media Gateway Processor (MGP) CLI. Use the command show voip vX where X is the slot number of the VoIP ( 0- for VoIP on the motherboard, 1-4 for MM760 VoIP Media Modules). Check if the Admin State is "Release". 3. Verify that the static IP address is non-zero, that the current IP address matches the static, that there is a valid MAC address, and that the resources in use are fewer than the allowed maximum number. 4. Also check if there are any faults. Refer to the Maintenace manual to clear the faults. If the Admin State is OK and if there are no faults, use the command ping mgp xxx.xxx.xxx.xxx, where xxx.xxx.xxx.xxx is the IP address of the VoIP in question. If you cannot ping the VoIP, then the VoIP is insane. 5. Go to the 'configure' mode. Use the command reset voip vX, where X is the slot number of the VoIP. Wait for a couple of minutes, then use the command show voip vX. Verify that the VoIP is in normal state. 6. Now check if IP Phones get dialtone. If not, escalate the problem.
Echoes during an IP call - particularly between IP phones and shuffled calls.
Data network delay.
1. If an IP Softphone is involved, check the latency on the data network or LAN by selecting audio monitor for ping delay. 2. If it is greater than 150 ms, echo may be due to delay. If delay is significant (Avaya™ VoIP Monitoring Manager or a 'sniffer'-like internet advisor), echo can be amplified by delays. Reduce latency in the data network. 3. Try using VLAN tagging and QoS settings.
7/5/2002 4:35 PM
Voice Quality G700 Troubleshooting Page 2
Symptom Root Cause Resolution
Echoes during an IP call - particularly between IP phones and other circuit switched phones like DCP or analog.
Levels issues - impedance mismatch.
1. Check levels and adjust loss plan in SAT. 2. Check to see if problem is from T1. If so, upgrading T1 board to TN464G series with hard echo canceller may fix problem.
Echoes during an IP call - particularly between G700 and calls to the Public Switch Telephone Network (PSTN).
Improper functioning headset.
1. Exchange the headset with one that does not exhibit the echo problem.2. If the problem persists, investigate other possible root causes, below.
7/5/2002 4:35 PM
Voice Quality G700 Troubleshooting Page 3
Symptom Root Cause Resolution
1. Check to see if echo cancellation is turned on in the SAT connected to the S8300: Example: display ds1 1v42. If Echo Cancellation is not turned "ON", issue a change ds1 [port] command: Example: change ds1 1v43. Change fields to the following settings: Echo Cancellation: [y] EC Direction: [inward/outward - for the GA release it is actually opposite of what it’s suppose to be on the MM710 (for firmware version 2 and earlier)] EC Configuration: [1]4. Issue a change trunk-group [trunk group #] command associated with the ds1: Example: change trunk-group 185. On page 2 set Ds1 Echo Cancellation? to ’y’.6. If Echo Cancellation is not displayed, escalate the problem and contact Avaya or your Authorized Avaya Business Partner to turn ON Echo Cancellation (must purchase).Level 2: If Echo Cancellation is not turned "ON" for a DS1, and the customer reports that the SAT screen doesn’t display an option to turn Echo Cancellation ’ON’, login to the SAT to check the system-parameters customer-options form:1. Issue a display system-parameters customer-options command.2. On page 1, check that "Maximum Number of DS1 Boards with Echo Cancellation [1]" is set to greater than "0", or to thenumber of DS1 boards under control of the S8300.3. On page 2, check that the echo cancellation feature is set to ’enabled’ or ’y’.4. Issue a change ds1 [port] command: Example: change ds1 1v45. Change fields to the following settings: Echo Cancellation: [y] EC Direction: [inward/outward - for the GA release it is actually opposite of what it’s supposed to be on the MM710 (for firmware version 2 and earlier)] EC Configuration: [1]6. Issue a change trunk-group [trunk group #] command associated with the ds1: Example: change trunk-group 187. On page 2 set Ds1 Echo Cancellation? to ’y’.
Echoes during an IP call - particularly
between G700 and calls to the Public Switch Telephone Network (PSTN).
Echo Cancellation
was not turned on.
7/5/2002 4:35 PM
Voice Quality G700 Troubleshooting Page 4
Symptom Root Cause Resolution
Clipping, Pops, Cracks during an IP call.
Caused by packet loss or jitter due to network congestion.
1. Check for packet loss and jitter using Avaya™ VoIP Monitoring Manager. 2. Check to see if QoS is enabled at every hop. 3. Add more bandwidth or enable QoS (see Network Connectivity documentation). 4. Use a network analyzer (sniffer) to evaluate the network congestion.
Dropped Calls. Networking problems.
1. Consult the troubleshooting information contained in the 4620 documentation. 2. If the problem persists, escalate.
One way or no talk path.
Multiple possible causes.
1. Consult the troubleshooting information contained in the 4620 documentation. 2. Possible duplicated IP addresses (see AN-18, Intermittent problems (unexplained IP talk path problems; G700 Media Gateway reboots)).3. If the problem persists, escalate.
IP phone is in ’discovery’ state and never comes out of it.
May have wrong controller IP address, or the server is down, or one or more of the network nodes are down or not connected properly.
1. Check the server IP address by pressing "MUTE or HOLD" button + ADDR + # and use # to navigate, until you see the "CallSv" the IP address. This should be a valid CallServer IP address (S8300/S8700). If you do not know your "CallSv" IP address, contact your system administrator. 2. Also make sure the Router address and Mask values on the IP station are properly set. You can see ROUTER and MASK values by pressing the # key. Refer to the troubleshooting section of the IP phone 4600 series documentation for additional troubleshooting information. 3. Ping the server from a PC local to the network to make sure the server is up. 4. If the server is up, ping the phone from the PC.5. If the ping command succeeds, escalate the problem.6. If it does not, there is a network problem. Check for network connectivity.
IP-phone display shows "Wrong Set Type".
The set type associated with the extension does not match the IP-set type.
1. Re-enter your extension after pressing #, if you know the extension, and follow the steps. 2. Otherwise, contact your system administrator to find out your extension and password for the IP-set. 3. Refer to the troubleshooting section of the IP phone 4600 series documentation for additional troubleshooting information.
IP-phone display shows "No Ethernet".
No cable or bad cable or cable in the wrong port.
1. Check that the other end of the cable is connected to a switch or hub.2. Make sure the cable is CAT5 and plugged in to the port indicated by the phone symbol and is not a cross-over cable. 3. Refer to the troubleshooting section of the IP phone 4600 series documentation for additional troubleshooting information. 4. If the problem persists, escalate.
IP phone display shows that the "System is busy".
Your switch is already serving allowed number of IP stations.
1. On the SAT, issue a display events command, and look for IP Phone denial event 1912, the maximum number of administered endpoints has been exceeded. The first value contains a truncated string indicating the IP Product (from the System-Parameters Customer-Options form). The second value indicates the registered limit and actual count in the upper and lower halves of the word, respectively.2. If the number of administered endpoints is to be increased, a new license file will be required.
7/5/2002 4:42 PM
Endpoints G700 Troubleshooting Page 2
Symptom Root Cause Resolution
IP station screen indicates extension or password mismatch.
The extension or the password is not administered on the server.
1. If you know you extension and password, please enter them. 2. If you still see an error, either your extension is not present on the server, pointed by CallSv on your phone, or the password does not match. 3. Check if you have the right server IP address by pressing "MUTE or HOLD" button + ADDR + # and use # to navigate, until you see the "CallSv" the IP address. This should be a valid Call Server IP address. 4. If you do not know your "CallSv" IP address, contact your system administrator. 5. Refer to the troubleshooting section of the IP phone 4600 series documentation for additional troubleshooting information.
No Dial tone on IP Phones.
IP station may not be registered or has no VoIP resources in its network region.
1. Make sure the IP station is registered. If registered, you would see a red-LED on the first call appearance button, and, if you have a display phone, you may see the date or a green LED light up on thefirst call appearence when you go off hook.2. If the IP station is registered, login into the system SAT terminal, and make sure an Avaya™ G700 Media Gateway or a prowler board is in your network region. To find this out, do 'display ip-network-map' on the SAT, and verify that the IP address of your station falls in the range defined by the IP address in the first two fields. 3. If it does, look at the last column for this entry. If you find your IP station IP address in the scope, that is the network region of your IP phone. If you do not find one, go to the next step. 4. Issue a display ip-interfaces command on the SAT. This returns a list of names with an associated network region in the last column. If you do not know your network region look for the IP stations "CallSv" IP address, and look for the associated network region number.5. Now you should have a network region number. In the same form, look for the media procesor boardIP address in the same network region. If you find one you have VoIP resources. 6. Otherwise, cancel out of the form and issue a list media command on the SAT. This returns a list of G700s with associated network region. 8. Issue a display media x command, where x is the G700 number, for each of the G700s to display its network region number. 9. If you find a G700 with the same network region number as your station region number, you have VoIP resources. 10. If not, there are no VoIP resources. In such a case, make sure the station network region is served by at least one network region.11. Refer to the troubleshooting section of the IP phone 4600 series documentation for additional troubleshooting information.
7/5/2002 4:42 PM
Endpoints G700 Troubleshooting Page 3
Symptom Root Cause Resolution
IP phone looks dead. May not have any power.
1. If the phone has no local power supply, and it is not a 4630 phone, make sure it is getting power from the Ethernet cable. 2. Make sure that the far end of the cat5 Ethernet cable is plugged into a P330-PWR. 3. If it is a 4630 phone, provide a 4630 local power supply.4. A regular IP phone can be powered locally, using a midspan power unit or the P330-PWR.5. Once power is available, recycle the power, either by removing the local power supply or removing the Ethernet cable in case of in-line power supply. 6. If this does not fix the problem, replace the phone.
IP Phone keeps rebooting.
Bad phone, or wrong cable type, or intermittent power problems.
1. Swap the phone with another to see if the rebooting problem follows the phone.2. If it does, replace the phone.3. If not, check the cable. It must be a CAT5 type.4. If the cable is correct, begin checking power sources, connectors, and jacks for problems.
IP phone displays the message "discovering" and cannot login to the controller.
No network connectivity between the IP phone and the controller.
1. Verify that the subnet can see the DHCP server. 2. Verify that the DHCP scope is correctly sending out information to the scope. 3. Check to see if the IP address on the phone is in the correct range of valid IP addresses. If not, then set the IP address to a correct address. 4. Check the IP address of the S8300/S8700. 5. Check the IP address of the router. 6. If all of this is correct, then use a PC on the LAN to ping the S8300/S8700 by issuing a ping command from the PC. 7. If the ping is successful , then check from the S8300/S8700 webpages if you can ping the IP phone in question. 8. If the pings do not succeed, try swapping out the cable, and the IP phones, as well. Otherwise, escalate the problem.
Refer to the troubleshooting section of the IP phone 4600 series documentation for additional troubleshooting information.
Cannot communicate between Avaya™ G700 Media Gateways in a stack.
Cables are not connected properly, or they are not fully inserted.
Make sure the green LEDs on each of the Cascade Modules are 'on', indicating good connections.
Red LED on the Avaya™ G700 Media Gateway LED board is 'on', but no alarms are raised.
The LED board is not making good contact with the backplane.
1. Verify there are faults in the system. Use the Avaya™ G700 Media Gateway Processor (MGP) Command Line Interface (CLI) command show faults to display any faults on the G700. 2. If no faults appear, then push the LED board in to make sure the backplane connector fully sits against the backplane. 3. If the problem persists, escalate.
Cannot telnet to the Avaya™ S8300 Media Server over the Services Ethernet port.
There is a bad cable, or a bad configuration on the services laptop.
1. A cross-over Ethernet cable is required, if connecting a laptop to the Services Port on the S8300. 2. The laptop's IP address must be 192.11.13.5 (netmask 255.255.255.252).
Cannot establish communication with the Avaya™ G700 Media Gateway.
There is a bad cable, or a bad configuration on the G700 Media Gateway.
1. An Ethernet cross-over cable is required, if connecting the G700 ports to a switch or router. 2. Check the EXT1 or EXT2 LEDs on the G700 LED board to make sure they are 'on'. 3. If the corresponding link LED is 'on', make sure the correct IP address and netmask have been configured.
The IP-Phone display shows 'System Busy'.
The number of IP phones have exceeded the limit specified in the customer's license.
1. From the SAT, issue the command display system-parameters customer-options, and look at the page with the heading "MAXIMUM IP REGISTRATIONS BY PRODUCT ID". 2. Compare the maximum number allowed to the number currently registered end-points on the same page. 3. Also check on page 1 the number of "Maximum Concurrently registered IP stations" to see if this number has been exceeded.4. If the maximum number is to be re-administered, a new license file will be required.
Cannot establish communication with the Avaya™ G700 Media Gateway.
Invalid S8300/8700 IP address
1. Enter the correct S8300/S8700 IP address using the serial port P330 Processor CLI interface. 2. Issue the command set mgc list <MGC IP Address>.
Cannot establish communication with the Avaya™ G700 Media Gateway.
Invalid MGC IP Address - using DHCP.
There may have been an upgrade problem, and the NVRAM has bad data. 1. Clear the NVRAM from the P330 Processor CLI by issuing the command nvram init. 2. Then re-enter the G700 MGP IP address with the command set interface mgp<MGP_IP_Address>, and the correct MGC IP address with the command set mgc list <MGC_IP_Address>.
Cannot establish communication with the Avaya™ G700 Media Gateway.
Bad or missing serial number in the S8700 or S8300 configuration.
1. Verify the G700 serial number is correct on the S8700 or S8300. Issue the command list media-gateway from the Avaya Site Administration or SAT screen.2. Verify that the serial number displayed matches that displayed by the P330 Processor CLI command show system.
The Avaya™ S8300 Media Server comes up in "License File Error" mode.
The S8300 can't get the serial number from the Avaya™ G700 Media Gateway for license verification.
Cannot Communicate with the Media Gateway Processor (MGP). (Cannot ping or telnet to the MGP).
Incorrect configuration of IP address, subnet mask.
1. Connect to the internal P330 Processor, and from the internal P330 Processor CLI issue the command session mgp. 2. If the command fails, retry after one minute. 3. If the second attempt fails, issue the internal P330 Processor command reset mgp. 4. If this command fails, reset the internal P330 Processor with the reset command. 5. If after all these steps the session mgp command still fails, escalate the problem.6. If the session mgp command succeeds, verify that the IP addresses and netmask of the MGP are correct. From the MGP CLI, issue the command show interface. 7. If the IP addresses and subnet mask don’t match, then change the configuration with the set interface mgp command.
Cannot Communicate with the Media Gateway Processor (MGP). (Cannot ping or telnet to the MGP).
Incorrect configuration of network gateway.
1. If the host is in a different subnet, make sure the default gateway (default route) on the switch is configured with the address of a router in the same subnet, and that the router can be reached using the ping command. 2. From the MGP CLI use the command show ip route mgp. For the default route, the net mask should be 0.0.0.03. If the IP address is incorrect, issue the command set ip route mgp 0.0.0.0 <net_mask> <network_ip>, where network_ip is obtained from your network administrator. 4. To verify if the change has been made, issue the command ping mgp <gateway_ip>.
Cannot Communicate with the Avaya™ S8300 Media Server using the services port. (Cannot ping or telnet to the S8300 server).
Have the incorrect cable (should be a cross connect).
1. Check cable to be sure that it is a cross-connect. 2. If it is, check the LEDs on both the laptop and the services port of the S8300. 3. If they are on, escalate the problem.
7/5/2002 4:37 PM
Access-Networking G700 Troubleshooting Page 2
Symptom Root Cause Resolution
Cannot Communicate with the Avaya™ S8300 Media Server using the services port. (Cannot ping or telnet to the S8300 server).
Incorrect configuration of the laptop's IP address (should be set to 192.11.13.5) and the netmask is incorrect (should be set to 255.255.255.252).
Set laptop IP configuration to IP address 192.11.13.5 and the netmask should be set to 255.255.255.252.
Cannot Communicate with the Avaya™ S8300 Media Server using the customer's LAN. (Cannot ping or telnet to the S8300 server).
Incorrect configuration of External (customer's) IP address, subnet mask.
1. Using the services port, verify the Avaya™ S8300 Media Server configuration with the Configure Server Web page wizard (Assuming that you are onsite and standing in front of the Avaya™ G700 MediaGateway and S8300).2. Verify that the external IP address, gateway, and subnet mask are correct. Use the Server Configure and Upgrade tab in the left panel of the web page, and the link is Configure Server.
Cannot communicate with the Media Gateway Processor (MGP) in a stack configuration. (Cannot ping or telnet to the MGP).
Physical layer problem - bad cable or Octaplane Module.
1. In a stack configuration, verify that the Octaplane Module is working by checking the green LED on the back of the G700, or with the internal P330 Processor command show module. 2. If the green LED is not on, check the cable connections, and check that the cascade module is seated properly. 3. Consider a possible bad cable (swap out cable). 4. If not successful, try swapping out the Octaplane Module. 5. As a last step, try issuing an internal P330 Processor command session <stack number> to see if there is connectivity between P330 modules in the stack. 6. If there is connectivity, try a reset of the entire stack.7. If the problem persists, replace the Avaya™ G700 Media Gateway. The MGP is not field replaceable.
7/5/2002 4:37 PM
Access-Networking G700 Troubleshooting Page 3
Symptom Root Cause Resolution
Cannot communicate (ping or telnet) with internal P330 Processor and/or Media Gateway Processor (MGP) and/or VoIP and/or Avaya™ S8300 Media Server.
Incorrect VLAN ID. 1. Use the internal P330 Processor CLI command session mgp to connect to the MGP CLI.2. Verify the VLAN settings on the MGP with the command show interface. The default value is [1]. 3. The VLAN ID is set on the MGP, and applies to the VoIP engines as well as the Avaya™ S8300 Media Server in the same Avaya™ G700 Media Gateway. Verify the VLAN settings on the internal P330 Processor with the commands: show vlan <vlan_id> show trunk <mod/port>5. Verify that the VLAN ID used for the MGP CLI is enabled on the internal P330 Processor port connected to the network via the Ethernet port (EXT1 or EXT2) or any port on the expansion interface.
Cannot communicate with the motherboard VoIP engine. (Cannot ping or telnet to the MGP).
Incorrect configuration of VoIP IP address.
1. Verify the VoIP IP address with the Media Gateway Processor (MGP) CLI command 'show voip vn’ (n=0, if motherboard VoIP). 2. If the VoIP IP address is incorrect, issue a set interface voip command with the correct IP address. 3. If the IP address is correct, then try the command reset voip vn.
Cannot communicate with the motherboard VoIP engine. (Cannot ping or telnet to the MGP).
VoIP firmware problem or hardware problem
Escalate the problem.
Cannot communicate (ping or telnet) with the internal P330 Processor.
Incorrect configuration of IP address, subnet mask.
1. Using the serial interface, make sure the internal P330 Processor configuration (IP address, subnet mask) is correct. From the internal P330 Processor CLI, issue the command show interface. 2. Verify that the interface "inband" has a valid IP address in the customer LAN. 3. If it is not a valid customer LAN IP address, if it is 0.0.0.0, or if it is the factory default "149.49.35.214", then the IP address for the internal P330 Processor has not been set. 4. Use the procedures described in the Installation and Upgrades documentation to set the internal P330 Processor interface. Note: If you don't have a serial interface cable, then telnet into the Media Gateway Processor (MGP). From the MGP, type the command session stack to get into the internal P330 Processor. Then use the procedures described in the Installation and Upgrades documentation to set the internal P330 Processor interface.
7/5/2002 4:37 PM
Access-Networking G700 Troubleshooting Page 4
Symptom Root Cause Resolution
Cannot communicate (ping or telnet) with the internal P330 Processor.
Incorrect configuration of network gateway.
1. Using the serial interface, make sure the internal P330 Processor configuration (IP address, subnet mask) is correct. From the internal P330 Processor CLI, issue the commands: show ip route ping <gateway_ip>2. If not successful, escalate the problem.
Cannot communicate (ping or telnet) with the internal P330 Processor.
Physical layer problem - bad cable.
1. Check the front panel LEDs, and make sure the LINK LED (EXT1 or EXT2) for the port is green. 2. If there is no link present, check the cables. Note: Host to switch 10/100BaseT connections, and router to switch 10BaseT or 100BaseTX connections typically are made using a straight-through cable. Switch to switch 10BaseT or 100BaseTX connections typically use a cross-over cable. The internal P330 Processor ports (EXT1 and EXT2) are switch ports. 3. If changing the cables does not solve the problem, then that specific port may be bad. Try switching to another port (EXT1, EXT2, or any port on the Expansion Module, if present).
Cannot communicate (ping or telnet) with the internal P330 Processor.
Incorrect configuration of switch port.
1. Make sure the external port is enabled. From the internal P330 Processor CLI, issue the command show port [module#/port#], where module# is the stack number; EXT1= port1; EXT2=port2. 2. If the external port is not enabled, issue the command set port enable [module/port]. 3. If unsuccessful, check the next possible root cause with the same symptoms.
Cannot communicate (ping or telnet) with the internal P330 Processor.
Incorrect configuration of PPP interface.
1. Make sure the PPP interface for the modem is on a different subnet and uses a different IP address than the inband interface to prevent conflicts. 2. Change or disable if required. 3. From the internal P330 Processor CLI, issue the command show interface. 4. If the subnet is the same, change the PPP subnet using the command set interface ppp <ip address>.
7/5/2002 4:37 PM
Access-Networking G700 Troubleshooting Page 5
Symptom Root Cause Resolution
Cannot communicate (ping or telnet) with the internal P330 Processor.
Physical layer problem - bad port.
1. Verify that there are no physical layer errors that may indicate a bad port or cable. 2. From the internal P330 Processor CLI, issue the command show rmon stat <port>. 3. In a multi-Avaya™ G700 Media Gateway stack, verify the stack connections by checking the LED on the Octaplane Module or with the command show module. 4. If the cable is bad, replace the cable. 5. If the port is bad, don't use that port; use another.6. If there isn't another good port, replace the G700, or add an Ethernet expansion module with additional data ports.
Intermittent problems (unexplained IP talk path problems; G700 Media Gateway reboots).
Physical layer problem - wrong cable.
1. Verify that the internal P330 Processor port does not report an error.2. Make sure that you have the correct cable (CAT 3 cable can be used for 10Mb connections, but CAT 5 should be used for 10/100 connections). 3. Check the cable connections, and, if necessary, replace the cable.
Intermittent problems (unexplained IP talk path problems; G700 Media Gateway reboots).
Switch port configuration - incorrect negotiation of speed and mode.
1. Verify that the ports that have 'autonegotiation' enabled have not downgraded the speed, or that there is not 'half/full duplex' mode mismatch that usually generates late collisions. Use the P330 commands: show port [module#/port#], where module# is the stack number; EXT1= port1; EXT2=port2. show rmon stat <port>2. If there is a mismatch, change the speed or mode appropriately, using the commands: set port speed <module#/port#> [10MB|100MB] set port duplex <module#/port#> [full|half].
Intermittent problems (unexplained IP talk path problems; G700 Media Gateway reboots).
IP address duplication.
1. Disconnect from the network or shutdown the device with problems.2. Try to ping the IP address from the internal P330 Processor or the Media Gateway Processor (MGP). 3. If the ping succeeds, there is a duplicate IP address. 4. Try to telnet to the IP address, or look in the ARP tables to detect the conflicting device.
7/5/2002 4:37 PM
Access-Networking G700 Troubleshooting Page 6
Symptom Root Cause Resolution
Can ping the Avaya™ S8300 Media Server 192.11.13.6 interface but cannot telnet to it.
The IP address on the service PC/laptop is configured incorrectly - especially when mistakenly setting both the laptop to the same IP address as the S8300.
Make sure that the service laptop/PC has IP address: 192.11.13.5, and net mask: 255.255.255.252.
Telnet session to internal P330 Processor or MGP was lost.
P330 Processor firmware crash.
If all other attempts to telnet to the internal P330 Processor fail, this may be a firmware problem, therefore:1. Power down and power up the Avaya™ G700 Media Gateway, using proper procedures (see Maintenance documentation). 2. From a PC, use the ping command to ping the IP address of the internal P330 Processor. 3. In either outcome (ping successful, or not), escalate the problem.
Level 2: Technical Services Organization should perform the following when receiving a call from field or customer regarding this problem: 1. Telnet to the internal P330 Processor. (If you cannot telnet to the internal P330 Processor, ask a tech to do the remaining steps through the serial port). 2. Go to the 'tech' mode. 3. Go to the 'dev' mode. 4. Look at the internal P330 Processor reset log by using the command system show reset-log. Also look at the internal P330 Processor log using show logs. 5. Collect both logs and escalate the problem.
7/5/2002 4:37 PM
Access-Networking G700 Troubleshooting Page 7
Symptom Root Cause Resolution
Cannot Access serial port or "console port".
Improper settings in the Serial interface program on the PC or hardware problem.
1. Check the settings of the Hyperterminal Program (or the terminal emulation program you are using for accessing the serial interface). The settings are mentioned in the Installation and Upgrades documentation. To summarize: Choose the right COM port (Usually it is COM1). Bits per second should be 9600. Data bits should be 8. Parity should be set to none. Stop bits should be set to 1. Flow control should be set to None. 2. Check to see if you have the correct cable and cable adapter. 3. If everything is set right with the correct cable and the problem persists, try making a LAN connection, via EXT1 or EXT2, if the Avaya™ G700 Media Gateway is already configured with IP addresses (as a work-around). 4. Otherwise, replace the G700.
Telnet window to internal P330 Processor/Media Gateway Processor (MGP)/Avaya™ S8300 Media Server gets disconnected due to P330 resets.
Copy TFTP returns failure. Image file to download does not exist or filename is not spelled correctly.
Make sure the file to be downloaded exists and is spelled correctly in the command.
Copy TFTP returns failure. TFTP server is not responding. 1. Verify that the path to the TFTP server is correct. 2. Try to ping the TFTP server. 3. If the ping fails, check the network connectivity.
Copy TFTP returns failure. Configuration of IP address, subnet mask does not match the external or customer’s LAN.
Set the time using the "Set Server time" link from the web page, or re-download the tarfile.
Cannot download/upload file.
TFTP server is inaccessible. 1. Try pinging the TFTP IP address. 2. If you have access to the machine where the TFTP is running, make sure that the TFTP service is up and running, and servicing on port 69.
Cannot upload file. No writing permissions on the TFTP server.
Make sure the TFTP server is configured to allow writing to the server.
Cannot download Media Gateway Processor (MGP) image.
The MGP image is corrupted. The MGP will switch over to the bank that contains a valid image on boot time. After the MGP boots, try to download a new image to the bank that has a corrupted/invalid image.
During download, the Media Gateway Processor (MGP) CLI remains on a download screen.
Download process did not return to the IDLE state.
Escalate the problem.
7/5/2002 4:43 PM
Upgrading G700 Troubleshooting Page 2
Symptom Root Cause ResolutionUG-8Cannot view Media Module (MM) information after downloading an MM image.
MM is not back in service yet. After the MM image downloads, the MM undergoes an automatic reset. You must wait about 30 seconds for the MM to come back in service. 1. From the MGP CLI, issue the command show mmvx, where vx is the MM slot number.2. If the command returns ’operation failed’, issue the command reset mmvx3. If this is unsuccessful, escalate the problem.
Upgrade failsshow tftp download status indicates ’idle state’ and "0% completion"
The Avaya™ S8300 Media Server cannot reach the server that is in the download path.
Check for one or more of the following: 1. Typo in the download path.2. DNS name is used in the download path and the Avaya™ S8300 Media Serverdoesn’t have DNS set up (so try using the IP address).3. The Avaya™ S8300 Media Server IP setting is wrong and cannot reach the server.4. No proxy set on the browser, if using the services port.
Upgrade fails Download path is wrong, but was able to reach the server. The server responds with a "File not found" message. A file of only about 100+ bytes results after the download.
Check for a typo in the download path.
Clicking on “Install New Software” brings up reboot stage
/var/tmp/install_status file is at the wrong state. Possible causes are: an upgrade was executed but the "reboot" button on the screen was not pressed after the upgrade; the file is a remnant of previously failed upgrade attempts.
Select the reboot button to complete an unfinished/abandoned upgrade, if this is desirable.
7/5/2002 4:43 PM
Upgrading G700 Troubleshooting Page 3
Symptom Root Cause Resolution
“Upgrade failed, exit status 1” displays on the refresh screen, after “Starting upgrade script”
The system is trying to start the upgrade script, but the script doesn’t exist. The system may have a corrupted tar file.
Escalate the problem.
Unable to login to the Avaya™ S8300 Media Server after upgrade.
No lacfile on the new partition. This could occur while performing an upgrade on a new hard drive before installing license and authentication file.
1. Reboot the Avaya™ S8300 Media Server by pressing the reset button, or by power cycling. Since the upgrade is not permanent yet, it will reboot to the old partition. 2. Install the license and authentication file before attempting another upgrade.
Note: If the upgrade has been made permanent and no password file (.pwd file) has been supplied (for example, if you have checked the button "Will supply license and authentication information later" in the install process, you may be locked up in an unrecoverable state, and your only recourse is to have a new hard drive installed.
Avaya™ S8300 Media Server doesn’t reboot after clicking the reboot button on the "upgrade system" page ("OK to Remove" LED stays on).
This problem can occur for software loads prior to MV1.1 (22.3).
Reseat the Avaya™ S8300 Media Server.
Internal server error observed on S8300 Media Server web page while upgrading.
There may be missing libraries or files; not running an official load; accidental removal of /opt/ws directory.
Escalate the problem.
7/5/2002 4:43 PM
Upgrading G700 Troubleshooting Page 4
Symptom Root Cause Resolution
The Avaya™ S8300 Media Server upgrade web page displays "Improper Signature for...".
Cannot successfully verify the signature. The time on the Avaya™ S8300 Media Server has not been configured, and the server has found that the signature file was created in the future; or, the tar file is corrupted and doesn’t contain the right signature.
1. Set the time using the "Set Server time" link from the web page, or, re-download the tarfile.2. Then perform the upgrade.
The Avaya™ S8300 Media Server upgrade web page displays "No signature file for...".
0022.0.tar.sig doesn't exist after S8300-11.1-0022.0.tar is untarred; or there is a corrupted tar file; or there is insufficient disk space.
Re-download the tar file and make sure that binary transfer mode is used (if using manual ftp).
“System failure” displays after typing username on the web page (“Could not login to login proxy").D10
TMP directory may be missing from the "/" directory; or the sudo package may not be installed, or it is out of date.
Local Survivable Processor G700 Troubleshooting Page 1
Symptom Root Cause Resolution
Avaya™ S8300 Media Server configured as a Local Survivable Processor (LSP) is not receiving translations and the primary call controller shows success after a save translations operation.
The primary call controller is not yet aware that the LSP is ready for translation transfers.
1. Login as craft or cust to the SAT/Avaya Site Administration screen of the primary controller (i.e. either the Avaya™ S8700 Media Server or Avaya™ S8300 Media Server. 2. Try save trans again on the primary call controller in five minutes.
Avaya™ S8300 Media Server configured as a Local Survivable Processor (LSP) is not receiving translations and the primary call controller shows success after a save translations operation.
The LSP is not configured correctly.
1. Login as craft or cust to the LSP's web page. 2. Run 'configure server'. 3. Advance to the Local Survivable Processor page. 4. If the primary call controller is an Avaya™ S8700 Media Server, check the CLAN address. 5. If the primary call controller is an Avaya™ S8300 Media Server, check the address of the S8300. 6. If the appropriate IP address is not correct, change it and complete the configure server process. 7. Then run 'Shutdown This Server', selecting one the options for a delayed shutdown, to restart system after shutdown, or shutdown even if this is the active server.
7/5/2002 4:38 PM
Local Survivable Processor G700 Troubleshooting Page 2
Symptom Root Cause Resolution
Avaya™ S8300 Media Server configured as a Local Survivable Processor (LSP) is not receiving translations. The primary call controller shows success after a save translations operation (on the MultiVantage SAT or Avaya SA login).
There is a network issue between the primary call controller and the LSP.
1. If the primary call controller is an Avaya™ S8700 Media Server, check to see if the CLAN is in service. 2. Login as craft or cust to the S8700 and bring up a SAT window. 3. Run 'test board' for the CLAN in question. 4. If this CLAN is not functional, then escalate the problem. 5. If the test returns success, login to the LSP's web pages. 6. Run the 'Execute Ping' command. Enter the CLAN's IP address. 7. If the ping is successful, the LSP should be able to communicate with the primary call controller. 8. If the ping is not successful, there is a problem in the network. Escalate the problem. 9. If the primary call controller is an S8300, login to the LSP's web pages. 10. Run the 'Execute Ping' command. Enter the S8300’s IP address. 11. If the ping is successful, the LSP should be able to communicate with the primary call controller. 12. If the ping is not successful, there is a problem in the network. Escalate the problem.
Avaya™ S8300 Media Server configured as a Local Survivable Processor (LSP) is not receiving translations. The primary controller shows failure after a save translations operation (on the MultiVantage SAT or Avaya SA login).
The version of Avaya MultiVantage™ on the LSP does not match that on the primary call controller.
1. Verify the software version on both the LSP and primary call controller. 2. Login to the LSP's web pages and run the 'View Software Version' command. 3. Login to the primary call controller's web pages and run the 'View Software Version' command. 4. Compare the two versions. If they do not match, upgrade the machine(s) running the older version of Avaya MultiVantage™.
Avaya™ S8300 Media Server configured as a Local Survivable Processor (LSP) is not receiving translations. The Avaya™ S8700 Media Server primary controller shows failure after a save translations operation (on the MultiVantage SAT or Avaya SA login).
LSP is not configured to receive files from the primary call controller.
1. Log in to the LSP's web pages. 2. Run the 'configure server' command, and check the LSP values. The key values to check are the server 1 and server 2 addresses of the S8700. These must be the servers' addresses and not CLAN addresses or the "active" address.
7/5/2002 4:38 PM
Local Survivable Processor G700 Troubleshooting Page 3
Symptom Root Cause Resolution
Avaya™ S8300 Media Server configured as a Local Survivable Processor (LSP) has IP endpoints registered with no Avaya™ G700 Media Gateways registered/ IP endpoints have no dial tone.
The G700 registered briefly during its recovery stage, thus allowing the LSP to accept IP phone registrations, but the G700 then re-registered with the primary call controller.
1. Login as craft or cust to the LSP and run the Avaya SA or SAT window.2. Run list reg to verify that phones are registered with the LSP. - If phones are registered, continue with Step 3. - If phones are not registered, this is not the appropriate resolution -- look for another Root Cause. 3. Run display errors and filter on errors.4. Look for Maintenance Object name MED_GTWY and Error Type 257 to indicate the G700 did register. 5. Perform a reset system 4 on the LSP.
Avaya™ S8300 Media Server configured as a Local Survivable Processor (LSP) is backing up an Avaya™ S8700 Media Server, and the translations are corrupt on the LSP.
The S8300 has a file named btm_parm.conf that cannot exist on the LSP when the LSP is backing up an S8700 or translation corruptions occur.
Escalate the problem.
Avaya™ S8300 Media Server configured as a Local Survivable Processor (LSP) is backing up an Avaya™ S8700 Media Server, and translations have been copied to the LSP. Now the LSP is in a rolling reboot.
The S8300 has a file named btm_parm.conf that cannot exist on the LSP when the LSP is backing up an S8700 or translation corruptions occur.
Plugging in the Expansion Module brings down the Avaya™ S8300 Media Server.
Shorting between S8300 Media Server and the Expansion Module.
1. Replace the Expansion Module. 2. If this is unsuccessful, back-up the S8300 and then replace the S8300, including the License File, Authentication File, and translations from the old one. 3. If this is unsuccessful, then replace the Avaya™ G700 Media Gateway, and insert the new Expansion Module and the new S8300. 4. If the problem persists, contact Avaya or your Authorized Avaya Business Partner.
Cannot telnet to the P330 Processor.
P330 Processor firmware crash.
1. Power down and power up the Avaya™ G700 Media Gateway, using proper procedures (see maintenance documentation). 2. From a PC, use the ping command to ping the IP address of the P330 Processor. In either outcome (ping is successful or not), escalate the problem.
7/5/2002 4:39 PM
P330-Expansion Module G700 Troubleshooting Page 2
Symptom Root Cause Resolution
Cannot Access serial port.
Improper settings in the Serial interface program on the PC, or hardware problem.
1. Check the settings of the HyperTerminal program (or the terminal emulation program you are using for accessing the serial interface). The settings are mentioned in the installation document. To summarize: Choose the right COM port (Usually it is COM1). Bits per second should be 9600. Data bits should be 8. Parity should be set to none. Stop bits should be set to 1. Flow control should be set to None. 2. Check to see if you have the correct cable and cable adapter. 3. If everything is set right with the correct cable and the problem persists, try using a LAN connection via EXT1 or EXT2, if the Avaya™ G700 Media Gateway is already configured with IP addresses (as a work-around) 4. Otherwise, replace the G700.
Telnet window to P330 Processor/Media Gateway Processor/Avaya™ S8300 Media Server gets disconnected due to P330 Processor resets.
P330 Processor firmware resets.
Escalate the problem.
7/5/2002 4:39 PM
P330-Expansion Module G700 Troubleshooting Page 3
Symptom Root Cause Resolution
Cannot telnet to P330 Processor.
Interface might not be configured.
1. Use the serial interface into the P330 Processor, and login to the P330 Processor. 2. Issue the command show interface. Check if the interface "inband" has a valid IP address in the customer LAN. 3. If it is not a valid customer LAN IP address, or if it is 0.0.0.0, or if it is the factory default "149.49.35.214", then the IP address for the P330 Processor has not been set. 4. Use the proper procedures described in the Installation and Upgrades documentation to set the P330 Processor Interface. Note: If you don’t have a serial interface cable, then telnet into the Media Gateway Processor. From the Media Gateway Processor, type the command session stack to get into the P330 Processor. Then use the proper procedures mentioned in the Installation and Upgrades documentation to set the P330 Processor interface.
No data is received by the Avaya™ VoIP Monitoring Manager: 1: The endpoints are not sending RTCP data to the Avaya™ VoIP Monitoring Manager server.
Mis-administration on Avaya MultiVantage™.
1. Make sure the change system ip-options form on the SAT has the IP address set for the PC on which the Avaya™ VoIP Monitoring Manager is running. 2. Make sure the Network region associated with the endpoint or gateway has the field "use system default values" as 'yes'. If it is set to 'no', make sure the IP address of the server is same as the PC's IP address (where the Avaya™ VoIP Monitoring Manager is running).3. Restart the SNMP service on your PC via Control Panel>Services>SNMP.
No data is received by the Avaya™ VoIP Monitoring Manager: 2: The Avaya™ VoIP Monitoring Manager server is not receiving any data.
Mis-administration on the PC where Avaya™ VoIP Monitoring Manager is running, or not connected to the network properly.
1. Make sure the PC's IP address is what you administered on the switch via the SAT. You can start a command shell on the PC via the START menu or command.exe on the RUN option of the START menu. Once you have the shell, type ipconfig. This displays the IP address of the PC. 2. Make sure Avaya™ VoIP Monitoring Manager server is running on this PC. 3. If you still do not see any data, restart the SNMP service on the PC via Control Panel>Services>SNMP). 4. Make sure the PC on which the Avaya™ VoIP Monitoring Manager is running is on the network, and has connectivity to the IP endpoints, and the Avaya™ G700 Media Gateway/Avaya™ S8300 Media Server.
Cannot install Avaya™ VoIP Monitoring Manager.
Unsupported operating system, or insufficient system resources or corrupted executable program.
1. Make sure the PC has the right operating system and resources, as described in the Avaya™ VoIP Monitoring Manager installation document.2. If the operating system is right, reboot the G700, and possibly reinstall the application.
1. Via the internal P330 Processor serial port, login to the Media Gateway Processor (MGP) by typing session mgp. 2. Then, on the MGP CLI, issue the commands show interface mgp, and show ip route mgp. Make sure you have a valid "IP ADDRESS", "GATEWAY IP ADDRESS", and"NETWORK MASK". 3. If the parameters are not set properly, then on the MGP CLI, type configure to enter configure mode.4. Type set interface mgp <VLAN> <IP_ADDRESS> <NETWORK_MASK> to set these parameters.5. Type reset mgp, and enter a y when prompted. 6. Wait until the reset completes, then type set ip route <DESTINATION> <NETWORK_MASK> <GATEWAY_IP_ADDRESS> to set these parameters.7. Reboot the MGP.
Media Gateway Processor (MGP) does not register.
Controller list not configured.
1. Verify that the controller list is correct. From the MGP CLI, issue the command show mgc list. The IP address should match the S8700 Media Server CLAN or the S8300 Media Server IP addresses. 2. If needed, correct this in 'configure' mode on the MGP's CLI by issuing a set mgc list with the correct IP addresses.
Avaya™ G700 Media Gateway doesn't register with the Media Gateway Controller (MGC).
Serial Number mismatch between the Media Gateway Processor (MGP) and the MGC.
1. Using the SAT command display events, look for the event 2047. If present, the Serial Numbers of the MGP and the MGC do not match; therefore, the Media Gateway is unauthorized.2. The Serial Number of the G700 MGP is shown by the MGP CLI command show system. 3. The Serial Number provisioned on the MGC is shown by the SAT command list media-gateway Note: This editable field is labeled "identifier". 4. If the Serial Numbers do not match, then change the Serial Number of the incriminated G700 in the MGC by typing the following command on the SAT : change media-gateway <G700_NUMBER>.
Avaya™ G700 Media Gateway doesn't register with the Media Gateway Controller (MGC).
The MGP is not administered on the MGC.
1. Issue the command list media-gateway.2. If this command shows that there is no G700 administered, issue the command add media-gateway.3. Using the procedures described in the Installation and Upgrades documentation, administer the G700.
Avaya™ G700 Media Gateway doesn't register with the Media Gateway Controller (MGC).
The MGP cannot communicate with the controller.
1. On the MGP CLI, execute the command ping mgp <controller-ip>. 2. If the ping command is successful, check the administration of the Avaya™ G700 Media Gateway on the S8300/S8700.3. If the ping is not successful, and the controller is in the same Avaya™ G700 Media Gateway (Avaya™ S8300 Media Server), verify the physical layer with the command session icc4. If the controller is external and the ping fails, you need to verify VLANs, gateway addresses (use show ip route to see if the problem is with the S8300 or the MGP, as in the networking symptom AN-7 "cannot communicate with the S8300".
Avaya™ G700 Media Gateway doesn't register with the Media Gateway Controller (MGC).
Duplicate G700 IP address or MGC IP address.
1. To verify that the Media Gateway Processor doesn't have a duplicate IP address, physically disconnect it from the network.2. Try to ping the MGP from a station in the network. 3. Do the same with the S8300/S8700. Make sure you have valid "IP ADDRESS", "GATEWAY IP ADDRESS", and "NETWORK MASK" on each of the internal P330 Processor, Media Gateway Processor, and S8300/S8700.
Avaya™ G700 Media Gateway doesn't register with the Media Gateway Controller (MGC).
Media Gateway Processor (MGP) is misconfigured (possibly from a previous installation).
1. Reset the G700 to factory settings by issuing the command nvram init in the Media Gateway Processor CLI.2. Reconfigure the G700 using the Installation and Upgrades documentation.
Avaya™ G700 Media Gateway doesn't register with the Media Gateway Controller (MGC).
Media Gateway Processor (MGP) True Flash File System is corrupted.
1. Check to see if setting the "IP ADDRESS", "GATEWAY IP ADDRESS", and "NETWORK MASK" doesn't properly change the values of those parameters on the G700. 2. If this is the case, then there is an indication that the tffs may be corrupted. Please escalate the problem and contact Avaya or your Authorized Avaya Business Partner.
Avaya™ G700 Media Gateway doesn't register with the Media Gateway Controller (MGC).
Both G700 flash banks are corrupted.
1. If the Media Gateway Processor is not reachable from the network, nor from the internal P330 Processor (command session mgp), the only way to access it is to plug a debug cable on the Media Gateway Processor 2. Power cycle the G700.3. If both Bank A and Bank B are corrupted, there will be a clear indication of that. 4. Replace the G700, since flash is not field replaceable. 5. Send the original G700 to the factory where they can re-program the flash.
Avaya™ G700 Media Gateway doesn't register with the Media Gateway Controller (MGC).
Duplicate MAC address.
Some connectivity problems may be due to duplicate MAC addresses between the P330 Processor, the VoIP engine, and the Media Gateway Processor (MGP). One of the consequences is that the MGP will become unreachable as soon as you go off hook on an IP phone. 1. To check the MAC address of the MGP, type the MGP CLI command show system. 2. Type the same command on the P330 CLI to check it's MAC address. 3. You can check the VoIP engine MAC address by issuing the command show voip on the MGP CLI. 4. If you find duplicate MAC addresses, escalate the problem.
Avaya™ G700 Media Gateway doesn't register with the Media Gateway Controller (MGC)
G700 recovery is not set properly.
The G700 recovery is shown by the Media Gateway Processor (MGP) CLI command "show mgp recovery". Here is an example of valid values : “Primary Search = 1”, “Total Search = 30”, “Transition Point = 1”. The Primary Search is the time in minutes during which the G700 is going to try to connect to the S8300/S8700. If the primary search time is too small, the G700 may not have enough time to register. If it's too big and the S8300/S8700 is not reachable, the G700 may not register with a secondary controller (possibly an Avaya™ S8300 Media Server configured as an LSP). The Total Search is the total time of the cycle during which the G700 is going to try to register with different S8300s/S8700s. If it's too small, the G700 may not have enough time to register, if it's too big, the G700 may take a long time to find an S8300/S8700 with which it can register. The Transition Point is the point beyond which the S8300/S8700 isconsidered to be a secondary controller.On the MGP CLI, depending on which parameter you need to change, type one of the following commands: set mgp reset-times primary-search <PRIMARY_SEARCH_TIME_IN_MINUTES>, or set mgp reset+F6-times total-search <TOTAL_SEARCH_TIME_IN_MINUTES>, or set mgp reset-times transition-point <TRANSITION_POINT>.
![[EN] G700 Part List](https://static.documents.pub/doc/80x56/55281b71550346e06e8b4640/en-g700-part-list.jpg)
