No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

The corporate directory cannot be visualized in the Phones 7910 and 8950

Publication Date:  2017-11-29 Views:  219 Downloads:  0
Issue Description

Version information:

PBX U1981: V200R003C20SPC300B015

BMU ECS:     V300R001C00SPC200

 

Fault Symptom:

The corporate directory stopped visualizing in the IP Phones 7910 and 7950.

Networking Overview:

The BMU has connected 3 PBXs

a U1981 (Main PBX) , U1960 and another U1981.

 

Alarm Information

The error displayed in the Phone Screen is

 

 

 

"unconfigured or incorrect authentication number"

Handling Process

         Below the troubleshooting

To see if the Appagent was active, we checked that with the path  http://10.10.10.10:80/appServer 
Here below the example of how to check it.

 

 

2.- if the Appagent is not working properly, try to connect by telnet If it doesn’t work

3.- check the port 80 (if it’s over Windows) with the command


    
        netstat –ano | find “:80” /*find the pid which obtain the 80 port*/
 

 



if it is another process then obtain the 80 port andkill the process that is interfering with the Appserver.

 

If the Appserver its ok, please collect the wireshark of appagent and IP
phone. And the
logs of appagent, BMU and IPphone.



Logs
analysis



 We saw the requirement from IP Phone has been sent to Appagent, but the authorization is fail.  Maybe the code on BMU is not the same as it on PBX

 

 



confirm the following information:



                                             (We asked this to the customer, and sent an example  (the image below))

 

Login
the BMU to see whether the connection with U19 is ok or not.


 

and the customer sent this Image below

 

 

 

 












Root Cause

Root cause with images and logs

 

 


The log means the eid password is null or have more than 1 record in database about the eid. From the picture we saw the standby U1981 and local U1960 were also configured on BMU. we had to confirm whether the U1981 PASSIVE was used for standby function and whether the u1960 was used as local survival. 

with this confirmation, we saw that the customer had registered the three PBXs in the BMU

 





 

 



Solution

the standby and local U19 had the same SIP number and also were synchronized to BMU.
So there were more than one record about the
eid on database. we logged on BMU to see whether the standby U1981 and U1960 synchronized the SIP number to BMU.

Solution:

when we saw that, realized that we had to delete the standby U1981 and local U1960 on BMU to solve the Issue

as the Standby and local U19 should not be configured on BMU, as the SIP number is the same as active U1981

it means we had duplicated information in the BMU, that's why we had that error in the phones.

  with this the Directory appears normally again in the IP Phones, the error disappears

Suggestions

be careful with the configuration of the Standby and local survival.

 

and below an explanation of how it works

Disaster
Recovery Mechanism



The disaster recovery mechanism is
described as follows:



Two central nodes are deployed in
two places, and each central node has one unified gateway deployed. The two
unified gateways work in active/standby mode, known as an active node and a
standby node. The active and standby nodes are connected using the TCP
protocol. They also use a heartbeat mechanism to constantly check each other's
status. The service servers are deployed at the central node where the active
unified gateway resides.


When the active and standby nodes
are running correctly, all users register with the active node. The active node
processes all user requests and synchronizes data to the standby node in real
time
.
At
least 1 Mbit/s bandwidth must be reserved for data synchronization, and the
round trip time (RTT) must be shorter than 80
ms.


When the active node fails, the
standby node takes over all services from the active node and processes all
user requests.


A trunk gateway can be deployed for
connecting to the PSTN. If the trunk gateway is not deployed, the active and
standby nodes both connect to the PSTN. When the active and standby nodes are
running correctly, the active node routes calls to the PSTN through trunks.
When the active node is faulty, the standby node routes calls to the PSTN
through trunks.


END