Section Toolbox – Reports of the PBX, it is very useful for the agnosticare problems, most of the time, related to its connectivity, or of some UI device or misconfigured, sometimes related to VoIP operators.
This section is to show abnormal events related to the verse entities (users, gateways, IU) of the PBX. Every new event has a date of start ( first event ): If the same event occurs again for the same entity, a progressive counter ( event number ) is updated with the date/time of the last event ( last event ). In this way, the events can be counted from the first to the last occurrence. If therefore in a relatively short time range, the number of events is particularly high, the problem can manifest itself in a macroscopic way for the switchboard users.
The events monitored are the following:
-
-
-
- Terminal or gateway registration timeout: timeout in the registration of the indicated entity.
- Authentication of the failed device: incorrect credentials for the indicated client entity (physical gateways, and users)
- Authentication against the failed carrier: incorrect credentials for the indicated server entity (VoIP operators)
- Unattainable apparatus: unattainable entity. For example, the VoIP account configured in the PBX has banned the IP of the UCloud server
- Unexpected IP / Port Source Change: change of the door of the entity during the current session
- Expire time of the apparatus too short: time of too short registration for the specified amount (minimum 60 second accepted by )
- Too many requests in the clear from the device: too many retransmissions coming from the indicated client entity
- Too many clear requests from the server: too many retransmissions of the server to the indicated entity
- No SSE connection with the UI of the user: an SSE connection could not be established for the UI of the indicated user
- Excessive loss of packets from the gateway: an excessive loss of machines causes the lack of audio in the conversation that has affected the indicated entity (typically a gateway)
- IU Registration Expiration of the user: timeout of the connection of the UI shown
- Expiration challenge to the authentication of the device: the device did not respond in time to the challenge of the PBX for authentication
-
-
| As a result of interventions carried out on its network or on a device, it is possible to reset the statistics eliminating the single event, clicking on the icon of the corresponding basket, or by acting on the magic wand at the top, erasing entire groups of signals as shown at the side |  |
TYPES OF PROBLEMS AND REPORTS
While we can not list all the possible problems (described explicitly in this page ), we will give the directions of maximum on the significance of these reports.
The events of type authentication of the failed device clearly indicate an error in the credentials to log in.
Events of type timeout device or gateway logging indicate the disconnection of the login of the entities indicated that they no longer show up at the PBX. They can be associated with events of type too many requests in clear from the apparatus, indicating that the PBX has sent too many acknowledgements to requests to REGISTER the device. This indicates that the confirmations of the PBX do not reach the device which, not receiving them, insists on always sending the same report which is then trashed with the outcome ofconnection timeout. These phenomena may be linked to configurations of NAT ( the router or firewall) whose sessions are too short compared to the time of recording of the indicated entity. The Inline of principle it is absolutely necessary that the duration ofthe NAT sessions is greater than or equal to a minimum of the times of registration used by telephones and gateway (the ns provisionig sets these times to 60 secon to ).
Issues of gender can lead to the impossibility to make and receive calls with the classic feeling that the exchange will be “locked”: the truth is to pour fact restarting your router / firewall often the situation returns to normal. Quin the need to investigate the efficiency of the active equipment.
These events of timeouts can also be a symptom of “holes of connectivity”, which can be triggered by physical problems on the connectivity of the company, or by problems of some active equipment such as routers and firewalls. In this case, it is necessary to investigate the quality of the connection together with your supplier.
Events of type unexpected change IP / port source , indicating that the router with either of the devices has changed source port for the named entities: thenormally this is not a problem because the PBX pursues this change of door however a frequent change of the door can indicate an incorrect configuration of theNAT once again with too short sessions.
Events of type no SSE connection with the UI of the user , indicate the impossibility for the UI to make a connection with the server: typically the responsibility is the firewall that should ensure navigation on TCP port 3542 and HTTP port indicated in the information of your company.
Events of type excessive loss of packets from the gateway , indicates the lack of sound in one or both of rezioni, settings related to the NAT of the router or a problem of routing with the operator.
WHEN TO BE ALARMED
Events of any kind can always be present in this section, but this does not necessarily indicate a problem that is pre-conceived by users. Internet browsing itself may have numerous problems, but the user is not aware of it until the situation worsens to the point that the connection is “slow”. The VOIspeed reports are instead very punctual, to such an extent that their mere presence could lead to thinking of a big problem. In reality, it is absolutely necessary to receive the users’ reports and then to observe the number of events for the reports : there is no number ofminimum daily events at the top of which you should think of a chronic and serious problem. This limit is in fact due to too many factors such as the number of active users, the number of calls made, the degree of use of the connectivity. What is certain is that if out of 10 events with “low” numbers, a couple with a number of an order of magnitude higher would stand out, we should first consider those, which could be isolated cases and then the others. If all 10 events have similar and high numbers ( oflet’s say at least over a dozen a day) you can worry: for this reason every time a maintenance of the internal network is carried out it would be worth to note these signals and then reset them to get an idea of the results obtained.
