Huawei, ZTE, Nokia, Alcatel Lucent, Fiberhome Network Hardware Store

Problem:

EPON terminals can realize voice access services, so what are the reasons that MA5800 cannot connect to the attendant console through the voice port of EPON?

solution

These ONUs do not provide ISDN interfaces and therefore do not support ISDN attendant consoles. However, since ONUs such as MA5606T, MA5620E, HG850e, etc. can provide network ports, they can support IP attendant consoles.

Reason:

There are 2 product attendant consoles related to EPON, CC08 attendant console and NGN attendant console;
There is only one type of CC08 attendant console, which uses CTX card to access. The interface of CTX card is twisted pair that provides 2B+D service;
There are 2 types of NGN attendant consoles, one is a twisted pair that carries 2B+D services, and the other is a network port;

Solution:

EPON terminals, neither 5620E nor 5606T support 2B+D services, so they do not support 2B+D attendant consoles.
The attendant console connected to the network port can be realized as long as it provides broadband access, so it can be realized.

Reason:

Improper DBA configuration, resulting in frequent instant interruption of all ONUs under the same PON

Solution:

1. Test the branch optical path, -17db, normal.
2. Replace the splitter, the fault remains.
3. Replace the GPBC board, the fault remains.
4. Use the minimum configuration method to exclude. Deactivate all ONUs under the 0/1/3 PON port and activate them one by one. Finally, it was found that as soon as the ONU with the ONU ID of 9 went online, all ONUs under the PON began to instantaneously lose packets. The No. 9 ONU is suspected to be a rogue ONU, and it is replaced, but the fault remains.
5. Ping the No. 9 ONU management address from the Layer 3 interface on the OLT. On the ONU, use “display icmp statistics” to perform packet statistics and find that the echo and echo reply of the ICMP packet are the same, which proves that the instantaneous packet loss does not occur on the ONU side.
6. The packet statistics on the OLT found that the number of echo packets and echo reply packets of the ICMP packets are inconsistent and smaller than the number of echo relay packets counted on the ONU side. In this way, packet loss occurs on the OLT side.

Further investigation of the data found that the T-CONT3 bound to the GEM stream of the broadband service on the ONU with the ONU ID of 9 under the 0/1/3 PON port, the DBA is type 4, and the bandwidth is 1024000. It is suspected that the uplink rate limit configuration is too large, causing congestion. After this DBA template is changed to 102400, the fault is resolved.

Reason:

The call cannot be established due to the non-support of G.729 by Friends of Business

Process

1. The call between B and A can be established, and both parties can hear each other, indicating that RTP packets can be sent from MA5616 to ONT normally, basically eliminating link problems.
2. Grab the message interaction between MA5616 and SX of a friend, and analyze its signaling. It is found that when A calls B, SX responds with a 403 Forbidden message after receiving the INVITE message sent by MA5616, where the description is “Reason: Q.850;cause=57;text=”Bearer capability not authorized”” generally means that certain capabilities of MA5616 are not authorized to be used. Because there is no assistance from a partner, it is impossible to figure out its specific meaning. Since the ONT is also connected to the SX, and B can call A normally, the plan is to locate the problem by comparing the similarities and differences between the INVITE messages sent by the ONT and the MA5616.
3. Comparing the INVITE message sent by MA5616 and ONT, two suspicious points were found. One is that the allow part of the message header in the INVITE message sent by the MA5616 contains the NOTIFY capability, but it is not included in the INVITE message sent by the ONT; the second is that in the SDP, the MA5616 reports support G.729 encoding, but the ONT reports no G. 729 encoding.
4. By modifying the parameter value of the sip profile, the NOTIFY capability in the INVITE message sent by the MA5616 is cancelled, but the problem remains, and SX still responds with 403, so the problem caused by NOTIFY is basically ruled out.
5. Cancel the support of MA5616 for G.729 encoding, test again, and solve the problem.
6. Later, I learned from other local employees that this softswitch of a friend company does not support G.729 encoding. It is estimated that because it does not support it, it responded with a 403 error.