Skip to end of banner
Go to start of banner

Debugging and troubleshooting of Media gateways

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Document description

Created: April 2018

Permalink:

Introduction



Troubleshooting of the BRI devices

Issues:

  • The gateway is not identified by the network
  • The gateway appears to cause the calls’ interruption
  • The gateway appears to affect the quality of the conversation
  • The gateway is not available for provisioning on the WMS
  • The gateway appears not to work correctly (the ports are not functional, the signal lights blink in a strange way…)

Reason:
Provisioning, network or functioning of BRI devices is not correct

Solution:
The Reset procedure of the gateway.

Reset operation resolves some problems related to the media gateway (strange blinking of LEDs, connectivity problems) and some problems related to LAN connection, access to the configuration page via http, etc…
Follow the steps below for the correct operation procedure.

  • The Gateway should be connected only to the power :


  • Press the button signed as reset/default on the backside of the Gateway, using paperclip or the object of a similar shape:


  • Hold the reset button. After a few moments the four LEDs of the display will start to blink. Only when all the four LEDs stop blinking, release the reset button and wait for the light of the LEDs to go out. Then unplug the power and retest the device.

In case the operation was not successful, repeat it again.


Test procedure

For the test performance you need:

  • 1 PBX with a user, created especially for the test
  • 1 provisioned phone associated to this user
  • 1 dialplan procedure
  • 1 provisioned BRI device (which was previously reset and upgraded to the latest version of firmware)
  • 1 network cable to connect the ports involved in the test

 

The test

The test consists of a call with two ports involved, one used as outgoing, another one – incoming.

The PBX plays the audio file in loop to keep the call running and to give the possibility to test the device.   
It is recommended to perform this operation in the specifically designed test environment in order to exclude the problems caused by some external factors, that could influence the result (the problems related to the operator, lines, configuration etc…). 
The following logical scheme demonstrates the procedure. In this case W02BRI is used.

In case W01BRI is tested, you need another BRI device, to set up the second port.

  • Create a user or use the existing one to perform the test. In this example the user “test2” with the phone number 103 is used:


  • Connect the Gateway to the Wildix test PBX and make the provisioning (refer to the online Guide if needed); connect the needed ports using the network cable RJ45:


  • Create a dialplan procedure to perform the test of the ports:


The procedure, while calling the number 9999, occupies the line corresponding to the predetermined BRI port and calls the number 5555.

The number is checked by the same procedure, and the selected music file starts to play.

Due to the loop that is generated, it’s possible to check all the eventual lines interruptions and the conversation quality, taking the necessary time to perform the test.

Once the procedure is entered into the dialplan, “test2” should be associated to the user.We should receive the following pictureProceed to the Gateway configuration. Set up NT as one port, TE as the second port (by choice) and associate the testbri procedure with both of them. 

PCM trace debugging of BRI/ PRI Gateways

This debugging tool helps you to identify the following problems:

Echo or noise in your network
Voice quality issues
Analog signals

PRI or BRI gateway fails to make/receive calls

Debugging of W04FXO

DESCRIPTION

To debug the W04FXO device, access the gateway on its IP address (e.g. 192.168.1.16) via telnet protocol.


How can I do it?

Use the command line (on Windows) or Terminal (on Unix and other systems) to enter the Gateway telnet IP (e.g. 192.168.1.16)
Log in using your access credentials (admin / wildix)
To start the debug:

debug -o


To stop the debug, 

debug -c


To disconnect from the device, type in 

quit


Syslog, Reset and recovery of media gateways

WP4X0 reset and recovery: Press the central button of the Navigation keys and hold it for several seconds. For more details read the guide: https://manuals.wildix.com/reset-and-recovery-of-wp410-wp480-wp480g-wp490-wp490g-2015-2016/

Enable remote syslog on Wildix devices: WMS -> Devices, double click on a provisioned device to edit it and select “Syslog Server” (enter the address of the remote server).

For the information on how to collect syslog from Wildix devices without Remote syslog server, read the guide: Collecting Syslog from Wildix Devices.

ISDN gateways:

Connect to the media gateway via SSH (on Windows you can use “putty” or other SSH clients) using the same credentials you used for access to web interface

Type “logs on” (at the end of the session, type “logs off”)

Make a test call

The logs help you to understand eventual issues, here is what happens when a user places an outgoing call to a trunk:

PBX receives a request from the user and forwards it to the BRI/PRI gateway

The gateway forwards the call to the operator

The operator responds to the gateway with the status “Call Proceeding” to confirm the reception of the request

The operator responds with the status “Call Progress” to indicate that the call has been routed to the destination

The operator responds with the status “Alerting” to indicate that the destination is available

The operator responds with the status “Setup Confirm” to indicate that the call has been responded

In case the call could not be connected or the call was hang up by the operator, the media gateway receives the following message: “Unicast RECV Disconnect”

Check the field indicating the reason of the call disconnection, for example: “Cause: Normal call clearing (16)”. Check the codes of disconnection reasons: http://www.cnes.com/causecodes.html


  • No labels