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>Search

Reminder

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

upgrade

CloudEC V600R019C00 Troubleshooting (Enterprise On-premises, Convergent Conference)

Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Announcement Playing Faults

Announcement Playing Faults

Announcement Playing Fault Rectification Method

Symptom
  • A user fails to hear the announcement.
  • The announcement heard by the user is different from the expected announcement.
  • The voice quality is poor.
  • The user fails to schedule a conference.
  • The user fails to participate in a conference.
Possible Causes
  • A user fails to hear the announcement.
    • The AS does not apply for the announcement.
    • The MRFP fails to collect digits.
    • The MRFP does not load the voice file.
    • The MRFP resources are insufficient.
    • The MRFP language type is configured improperly.
    • The network between the terminal and the MRFP is faulty.
    • The calling party hears repeat announcements indicating call failure when calling a user in the CS domain.
  • The announcement heard by the user is different from the expected announcement.
    • The AS applies for an incorrect announcement.
    • The announcement playing file is not recorded properly.
  • The voice quality is poor.
    • The network quality between MRFP and the terminal is poor.
    • The network quality between the MRFP bearer gateway and the terminal is poor.
  • The user fails to schedule a conference.
    • MRFP resources are insufficient.
    • The terminal capacity cannot support the service.
  • The user fails to participate in a conference.
    • MRFP resources are insufficient.
    • The terminal codec type does not meet the requirements that are specified when the conference is scheduled.
Troubleshooting Method

A user needs to locate the faulty NE to rectify the announcement playing failure.

If a user fails to hear the expected announcement, the troubleshooting procedure is shown in Figure 9-2.

Figure 9-2 Troubleshooting procedure for the failure in hearing the announcement
NOTE:

Perform the following steps to locate the NE where the announcement playing fails:

  • Determine whether the AS receives an INVITE 200 OK message.
  • Determine whether the AS receives an INFO 200 OK message (XML contained in the message carries result response ="200").
  • Determine whether the AS receives an INFO message from the MRFC indicating the announcement playing failure.

If the announcement is different from the expected announcement, the troubleshooting procedure is shown in Figure 9-3.

Figure 9-3 Troubleshooting procedure for wrong announcement

For poor voice quality, check the network quality between MRFP and the terminal, and the network quality between the MRFP bearer gateway and the terminal.

For the failure in scheduling a conference, check whether the MRFP resources are sufficient and the terminal supports the conference function.

For the failure in participating in a conference, check whether the MRFP resources are insufficient and the terminal codec type is set properly.

Procedure

Check the alarms.

  1. Huawei maintenance engineers need to check whether the announcement alarms are displayed on the HUAWEI Operation & Maintenance System. For details, see Alarm Browsing.

    Alarms of the announcement playing failure are shown in Table 1.

    Homing ME of Alarms

    Related Alarms

    AS

    ALM-20030 All Links Disconnected in a DNS Server

    ALM-20031 A Link Between USM and DNS Disconnected

    ALM-20053 Disconnection of the USM from the S-CSCF or MRFC

    CSCF

    ALM-10705 All Links Between MRFC and DNS Disconnected

    ALM-10704 Link Between MRFC and DNS Disconnected

    ALM-10703 HTTP or HTTPS Connection Faulty

    ALM-11000 H.248 SCTP Link Failure

    ALM-11002 H.248 SCTP Link Congestion

    ALM-11004 MGW Out Of Service

    MRFP

    ALM-125156 ARP Probe Failure

    ALM-61510 H.248 signaling link fault

    ALM-63003 VPU Media resource overload

    • Yes: Rectify the fault by following the handling procedures of alarms and go to 2.
    • No: Go to 3.
  2. Check whether the fault has been rectified.
    • Yes: The alarm handling is complete.
    • No: Go to 3.
  3. Rectify the fault according to the fault symptom.
  4. Create a message tracing tack on the AS to check whether the AS sends the INVITE message of an announcement request.
    NOTE:

    The Subscriber IMPU message trace task can be created by referring to Creating a Tracing Task. If the failure reoccurs after the message trace task is created, check whether the AS sends the INVITE message of the announcement according to the message tracing information.

    • Yes: Go to 5.
    • No: The AS announcement playing failure occurs.
  5. Check whether the non-direct connection mode is used between the AS and the MRFC.

    Log in to the HUAWEI Operation & Maintenance System, and open the MML Command - USM window. Run LST MRFMODE to check whether the Connection mode is DIRECT.

  6. Check whether the AS receives an INVITE 200 OK message for the request of announcement playing.
    • Yes: Go to 7.
    • No: The MRFP announcement playing failure occurs. For details, see MRP6600 Announcement Playing Failure.
  7. Check whether INFO 200 message received by the AS is correct.

    Check whether xml contained in the INFO 200 message carries result response ="200".

    NOTE:

    If the MRFP announcement playing fails, an INFO 200 message can be returned. However, the message does not carry result response ="200". The cause value varies according to different reasons.

    • Yes: Go to 8.
    • No: The MRFP announcement playing failure occurs. For details, see MRP6600 Announcement Playing Failure.
  8. Check whether the AS receives an INFO message from the MRFC indicating the announcement playing failure after sending an INFO 200 message.
    • Yes: The MRFP announcement playing failure occurs. For details, see MRP6600 Announcement Playing Failure.
    • No: Go to 9.
  9. Perform the message trace on the AS to check whether the announcement URI is proper in the INFO message sent from the AS to the MRFC.
    NOTE:

    The Subscriber IMPU message trace task can be created by referring to Creating a Tracing Task. If the failure reoccurs after the message trace task is created, check whether the announcement URI is correct in the INFO message sent from the AS to the MRFC.

    Check the announcement URI of the INFO message.

    • Yes: The MRFP failure occurs. For details, see MRP6600 Announcement Playing Failure.
    • No: The AS failure occurs.
  10. Check whether the fault has been rectified.
    • Yes: No further action is required.
    • No: Go to 11.
  11. Contact Huawei technical support engineers.

Service Announcement Playing Fault

Symptom
  • The AS fails to send the announcement request message.
  • The AS applies for an incorrect announcement.
Possible Causes
  • The AS fails to send the announcement request message.
    • The DNS is not configured properly.
    • In the non-direct connection mode, the S-CSCF route address is not configured between the AS and the MRFC.
    • The announcement data is not configured.
  • The AS applies for an incorrect announcement.

    A user performs an incorrect service operation.

Troubleshooting Method
Figure 9-4 Troubleshooting procedure for the AS announcement request failure

For the troubleshooting of the wrong announcement, check whether the service operation is correct.

Procedure
  1. Determine the troubleshooting procedure based on the failure type:
    • The AS fails to send the announcement request message: Go to2.
    • The AS applies for an incorrect announcement: Go to 18.
  2. Check whether the MRF address is set to a domain name.

    Log in to the HUAWEI Operation & Maintenance System, and open the MML Command - USM window. Run LST MRF to check whether the value of MRF address type is Domain Name.

    %%LST MRF:;%% 
      
     RETCODE = 0  Operation succeeded 
      
     The result is as follows: 
     ------------------------- 
                    MRF name  =  MRF_0 
            MRF address type  =  Domain Name 
                 IP address  =  NULL 
             MRF domain name  =  mrfc.example.com 
                 MRF IP mode  =  ACTIVE 
             MRF description  =  NULL 
              Record address  =  file://provisioned 
                 Record name  =  RECORD 
     Maximum record duration  =  600 
                Terminal key  =  NUMBER # 
      Clear data buffer flag  =  TRUE 
           Break by key flag  =  TRUE 
        S-CSCF Route Address  =  NULL 
                    MRF TYPE  =  MSML1.1 
                Record codec  =  CODEC_PCMA 
                    Reserved  =  0 
     (Number of results = 1) 
      
     ---    END
    • Yes: Go to 3.
    • No: Go to 9.
  3. Rectify the fault according to the DNS server type.
    • Embedded DNS: Go to 6.
    • External DNS: Go to 4.
  1. Log in to the HUAWEI Operation & Maintenance System, and open the MML Command - USM window. Run DSP DNSLNK to check whether Link status is Link state ok.
    The result is as follows: 
     %%DSP DNSLNK:;%% 
     RETCODE = 0  Operation succeeded 
      
     The result is as follows: 
     ------------------------- 
     DNS server name  =  DNSSERVER 
       DNS link name  =  DNSLINK 
      DNSlink state  =  Linkstate ok
     (Number of results = 1) 
    • Yes: Go to 8.
    • No: Go to 5.
  2. Run LST DNSLNK to check whether the DNS configuration record is correct. Check whether Local port number, Peer IP and Peer port number are consistent with the planned parameters. Run LST DNSLNK. The result is as follows:
    %%LST DNSLNK:;%% 
     RETCODE = 0  Operation succeeded 
      
     The result is as follows: 
     ------------------------- 
             DNS link name  =  DNSLINK 
           DNS server name  =  DNSSERVER 
     DNS server group name  =  DNSGROUP 
         BSG module number  =  23 
             Protocol type  =  TCP protocol 
            Recursion flag  =  No 
              Address type  =  IPV4 
                  Local IP  =  10.12.13.102 
         Localport number  =  3999 
                   Peer IP  =  10.12.22.13 
          Peerport number  =  19005 
     (Number of results = 1) 
      
     ---    END
    • Yes: Go to 8.
    • No: Run RMV DNSLNK to remove the DNS configuration record. Then run ADD DNSLNK to add the DNS service information as required. Go to 7.
  3. Check whether the embedded DNS is configured properly. For details, see Embedded DNS Failure of the USM.
  4. Check whether the fault has been rectified.
    • Yes: No further action is required.
    • No: Go to 8.
  5. Check whether the non-direct connection mode is used between the AS and the MRFC.

    Run LST MRFMODE to check whether the value of Connection mode is INDIRECT.

    %%LST MRFMODE:;%% 
     RETCODE = 0  Operation succeeded 
      
     The result is as follows: 
     ------------------------- 
      MRF mode index  =  0 
     Connection mode  =  DIRECT 
      Support option  =  NOT SUPPORT OPTION 
     (Number of results = 1) 
      
     ---    END
    • Yes: Go to 20.
    • No: Go to 10.
  6. Check whether the non-direct connection mode is used between the AS and the MRFC.

    Run LST MRFMODE to check whether the value of Connection mode is INDIRECT.

    %%LST MRFMODE:;%% 
     RETCODE = 0  Operation succeeded 
      
     The result is as follows: 
     ------------------------- 
      MRF mode index  =  0 
     Connection mode  =  DIRECT 
      Support option  =  NOT SUPPORT OPTION 
     (Number of results = 1) 
      
     ---    END
    • Yes: Go to 10.
    • No: Go to 13.
  7. Check whether the S-CSCF route address is configured.

    Run LST MRF to check whether the value of S-CSCF Route Address is NULL.

    %%LST MRF:;%% 
     RETCODE = 0  Operation succeeded 
      
     The result is as follows: 
     ------------------------- 
                    MRF name  =  MRF_01 
            MRF address type  =  Domain Name 
                  IP address  =  NULL 
             MRF domain name  =  mrfc.example.com 
                 MRF IP mode  =  ACTIVE 
             MRF description  =  NULL 
              Record address  =  file://provisioned 
                 Record name  =  RECORD 
     Maximum record duration  =  600 
                Terminal key  =  NUMBER # 
      Clear data buffer flag  =  TRUE 
           Break by key flag  =  TRUE 
        S-CSCFRoute Address  =  NULL 
                    MRF TYPE  =  MSML1.1 
                Record codec  =  CODEC_PCMA 
                    Reserved  =  0 
     (Number of results = 1) 
      
     ---    END
    • Yes: Go to 11.
    • No: Go to 13.
  8. Run MOD MRF to configure the S-CSCF route address.
  9. Check whether the fault has been rectified.
    • Yes: No further action is required.
    • No: Go to 13.
  10. Create a message trace task on the AS to record the cause value contained in the Oxx message received by the AS indicating the announcement playing failure. A 183 message is as follows:
    %%LST IPRT:;%% 
     RETCODE = 0  Operation succeeded 
      
     The result is as follows: 
     ------------------------- 
     IFM module number  =  52 
          Address type  =  IPV4 
            IP address  =  10.11.9.130 
           Subnet mask  =  255.0.0.0 
     (Number of results = 1) 
      
     ---    END
  11. Check whether the announcement playing failure is on the MO side.
    • Yes: Go to 15.
    • No: Go to 18.
  12. Run LST CVTOTID to check whether the failure processing data is configured.

    The command output is as follows:

    %%LST CVTOTID:;%% 
     RETCODE = 0  Operation succeeded 
      
     The result is as follows: 
     ----------- 
      Causevalue  Cause in reason header  Release position  Tone ID  Tone group number 
      
      1236        65534                 65534     15      65534    
      1237        65534                 65534     15      65534    
     ...... 
      65534       8                     65534     25      65534    
      65534       17                    65534     8       65534    
     ...... 
     

    According to the cause value recorded in 13, locate the record corresponding to Cause in reason header. Check whether Cause value is set to 65534.

    • Yes: Go to 16.
    • No: Go to 20.
  13. Check whether the value of Tone ID is the same as data planning.
    • If the parameter is not specified, specify this parameter by referring to Configuring Announcement Data: Go to 17.
    • If the parameter is specified incorrectly, modify the configuration of this parameter by running MOD CVTOTID: Go to 17.
    • The parameter is specified correctly: Go to 20.
  14. Check whether the fault has been rectified.
    • Yes: No further action is required.
    • No: Go to 20.
  15. Check whether the service operation is correct.
    NOTE:

    Check whether the service operation is correct according to the relevant feature description after understanding the used service. For example, a user wants to deactivate the CFU service. However, another announcement is heard due to the wrong access code.

    • Yes: Go to 20.
    • No: Perform the operation based on the correct method, and then go to 19.
  16. Check whether the fault has been rectified.
    • Yes: No further action is required.
    • No: Go to 20.
  17. Contact Huawei technical support engineers to rectify the fault.

MRP Announcement Playing Fault

Symptom

If any of the following conditions exists, it indicates that the announcement playing failure in the MRP6600 has occurred.

  • Announcement playing fails.
  • Digit collecting fails.
  • Users cannot hear voice.
  • The voice quality is poor.
Possible Causes
  • If announcement playing fails, the possible causes are as follows:
    • Tone materials do not exist.
    • The announcement playing failure in the network file server (NFS) is caused by incorrect link configuration of the NFS server.
  • If digit collecting fails, the possible causes are as follows:
    • The IP network between the MRFP and the terminal failed.
    • The RFC2833 digit collecting terminal does not carry the attribute defined in RFC2833.
    • The value of RFC2833 PayloadType is incorrect, or RFC2833 PayloadType is not carried.
    • Dual tone multi-frequency (DTMF) digit collecting operations are performed for non-G.711 users.
  • If users cannot hear voice, the possible cause is as follows:
    • The IP network between the MRFP and the terminal failed.
  • If the voice quality is poor, the possible causes are as follows:
    • The quality of the network between the MRFP and the terminal is poor.
    • The quality of the network between the gateway connected to the bearer interface of the MRFP and the terminal is poor.
Troubleshooting Method

Figure 9-5 shows the troubleshooting procedure for the announcement playing failure in the MRFP.

Figure 9-5 Troubleshooting procedure for the announcement playing failure
Procedure
  1. Check the failure symptom

    Failure Symptom

    Description

    Operation Step

    Announcement playing fails.

    The announcement playing failure causes users to fail to hear voice. Rectify the signaling fault.

    2

    Digit collecting fails.

    The digit collecting failure causes users to fail to hear voice. Rectify signaling and bearer fault.

    11

    Users cannot hear any voice.

    Rectify the bearer fault.

    18

    The voice quality is poor.

    Rectify the bearer fault.

    21

  1. Log in to the HUAWEI Operation & Maintenance System.
  2. Create a call trace task and an internal trace task.
    1. Enter the trace interface.

      In the HUAWEI Operation & Maintenance System window, click the Maintenance tab. Choose Service Navigation > Trace > MRP6600. Expand CMU TRACE, and then double-click CALL to create a call message trace task. See Figure 9-6.

      Figure 9-6 Creating a call trace task
    1. Create an H.248 trace task.

      In the CALL Tracing dialog box, set Trace Type to the default value H248. Then, click OK. See Figure 9-7.

      Figure 9-7 Creating an H.248 trace task
    2. Create an internal trace task.

      In the CALL Tracing dialog box, set Trace Type to INTERNAL. Then, click OK. See Figure 9-8.

      Figure 9-8 Creating an internal trace task
  1. Check whether the MRFP receives H248_ADD_REQ and H248_MOD_REQ messages, and whether the MRFP transmits H248_ADD_RESP, H248_MOD_RESP, and H248_NOTIFY_REQ messages.

    Figure 9-9 shows the H.248 messages in the trace task.

    Figure 9-9 H.248 messages in the trace task
    1. Check whether the MRFP receives H248_ADD_REQ or H248_MOD_REQ messages.
      • Yes: Go to 4.b.
      • No: Rectify the fault according to Interworking Failure of the MRP6600 (MRFP).
    1. Check whether the MRFP transmits H248_ADD_RESP, H248_MOD_RESP, or H248_NOTIFY_REQ messages.
      • Yes: Go to 5.
      • No: Go to 26.
  2. Check whether the response messages or reported messages of the MRFP carry error codes and error texts.

    Use H248_MOD_RESP as an example. Click the H248_MOD_RESP message as shown in Figure 9-10. Then, check for the error code and text carried in the H248_MOD_RESP message. See Figure 9-11.

    NOTE:

    The H248_NOTIFY_REQ message shown in Figure 6 is not used to return an error code but to report a failure event. For details about the message, see Figure 9-12.

    Figure 9-10 H.248 messages in the trace task
    Figure 9-11 Error in the H248_MOD_RESP message
    Figure 9-12 Initiative reported message
    • Yes: Go to 6.
    • No: Go to 26.
  3. Check the type of the message that carries the error code and error text.
    • H248_ADD_RESP: Go to 7.
    • H248_MOD_RESP: Go to 8.
    • H248_NOTIFY_REQ: Go to 9.
  4. Check the error code and error text carried in the H248_ADD_RESP message.
    • If errorCode is 455 and errorText is Property illegal in this Descriptor, go to 26.
    • If errorCode is 501 and errorText is Not Implemented. Remote codec unsupported, check whether codecs that the MRFP does not support are configured on the MRFC. For details, see Check the configuration of gateway resources.
    • If errorCode is 625 and errorText is license out of range. Out of License Range(Item:AUDIO-CVT CHN), determine the license items to be applied for according to License Control Item Description and then see the License Operation Guide released with the version software to apply for a license.
    • If errorCode is 510 and errorText is Insufficient resources.Out of IP resource, go to 7.a.
    • If errorCode is 500 and errorText is Internal software failure in the MG. Receive error response message from HRU:M93,E78, go to 7.h.
    • If errorCode is 500 and errorText is not Internal software failure in the MG. Receive error response message from HRU:M93,E78, go to 26.
    NOTE:

    Item:AUDIO-CVT CHN in the error description indicates the restricted license item. Mapping of the restricted license items is as follows:

    • AUDIO-PLAY CHN: number of AudioPlay channels
    • AUDIO-CONF CHN: number of AudioConference channels
    • VMRFP SUM: number of Virtual MRFP
    • WBAMR CHN: number of WB-AMR codec channels
    • ILBC CHN: number of ILBC codec channels
    1. In the MML Command - MRP6600 window, run LST MEDADDR to check whether IPv4 gateway in the command output is correct.

      If the command is successfully executed, the command output example is displayed as follows:

      %%LST MEDADDR: ADDRNAME="MEDADDR";%% 
       RETCODE = 0  Operation succeeded 
        
       The result is as follows 
       ------------------------ 
               Media address name  =  MEDADDR 
                   HRU module No.  =  451 
              Main interface name  =  ethif_med 
                     Address type  =  IPV4 
                     IPv4 address  =  192.168.150.10 
                IPv4 address mask  =  255.255.255.0 
                     IPv4 gateway  =  192.168.150.1 
                     IPv6 address  =  NULL 
               IPv6 prefix length  =  0 
                     IPv6 gateway  =  NULL 
       Audio packet protocol type  =  DSCP 
         Audio packet IPQOS value  =  NULL 
       (Number of results = 1) 
        
       ---    END
      NOTE:
      The preceding output is used as an example to analyze the gateway resolution status (IPv4 gateway column) of each IPv4 address.
      • The interface with IPv4 address set to 10.0.0.1 is a loopback interface. You do not need to pay attention to the resolution status of the gateway address of the loopback interface.
      • If a gateway address is displayed in the IPv4 gateway column mapping to the IPv4 address column, the gateway address is successfully resolved.
      • If - is displayed in the IPv4 gateway column mapping to the IPv4 address column, the gateway address fails to be resolved
      • Yes: It indicates that the gateway address mapping to the interface can be resolved and that the link between the interface and the gateway is normal. In this case, go to 7.c.
      • No: It indicates that the gateway address corresponding to the interface cannot be resolved. In this case, go to 7.b.
    2. Troubleshoot the interworking failure according to Interworking Failure of the MRP6600 (MRFP). Then, check whether the announcement playing failure has been rectified.
      • Yes: No further action is required.
      • No: Go to 7.c.
    3. Check whether bearer interfaces are reserved.

      Run LST RSVPORT to check whether Start port is 0 and whether End port is 65535.

    4. Cancel the bearer interface reservation.

      Run RMV RSVPORT to cancel the bearer interface reservation. Then, check whether the announcement playing failure has been rectified.

      • Yes: Go to 7.e.
      • No: Go to 7.f.
        NOTE:

        You can run ADD RSVPORT to reserve only certain interfaces at a site. If all interfaces are reserved, bearer channels fail.

    5. Check whether the NFS server plays an announcement.
      • Yes: Go to 7.f.
      • No: Go to 8.
    6. Run DSP FSSTS to check whether FS status is Enable.

      If the command is successfully executed, the command output example is displayed as follows:

      %%DSP FSSTS:;%% 
       RETCODE = 0  Operation succeeded 
        
       The result is as follows 
       ------------------------ 
        File server name  VPU module No.  FS status 
        
        FS0               651             Enable    
        FS1               651             Enable    
        FS2               651             Enable    
        FS0               652             Enable    
        FS1               652             Enable    
        FS2               652             Enable    
       (Number of results = 6) 
        
       ---    END
      • Yes: Go to 26.
      • No: Go to 7.g.
    7. Troubleshoot the interworking failure according to Interworking Failure of the MRP6600 (MRFP). Then, check whether the announcement playing failure has been rectified.
      • Yes: No further action is required.
      • No: Go to 26.
    8. Check whether the peer device uses an odd port number.

      Check whether the port number carried in remoteDescriptor of the message is an odd number.

      • Yes: Go to 7.i.
      • No: Go to 26.

      Figure 9-13 shows an example message.

      Figure 9-13 Checking the port number used by the peer device
    9. Change the port number used by the peer device to an even number.
    10. Check whether the announcement playing failure has been rectified.
      • Yes: No further action is required.
      • No: Go to 26.
  5. Check the error code and error text carried in the H248_MOD_RESP message.
    • If errorCode is 455 and errorText is Property illegal in this Descriptor, go to 26.
    • If errorCode is 501 and errorText is Not Implemented. Remote codec unsupported, check whether codecs that the MRFP does not support are configured on the MRFC. For details, see Check the configuration of gateway resources.
    • If errorCode is 625 and errorText is license out of range.Out of License Range(Item:AUDIO-CVT CHN), see the License Control Item Description released with the version software to apply for a license.
    • If errorCode is 602, go to Commissioning the Interworking Between the MRP6600 and a File Server.
    • If errorCode is 605, go to 8.a.
    • If errorCode is 500 and errorText is Internal software failure in the MG.TdSubMsg:M218,E13318, go to 8.c.
    • If errorCode is 510, go to 10.f.
    1. Check the language type.

      In the MML Command - MRP6600 window, run LST LANGTYPE to check whether Language type string is the language type carried in the H248_MOD_REQ message. See Figure10 Language type carried in the H248_MOD_REQ message.

      Figure 9-14 Language type carried in the H248_MOD_REQ message

      If the command is successfully executed, the following command output is displayed:

      %%LST LANGTYPE:;%% 
       RETCODE = 0  Operation succeeded 
        
       The result is as follows 
       ------------------------ 
        Language type string  Language type ID 
        
        en                    1          
        zh                    2          
       (Number of results = 3)
      • Yes: Go to 26.
      • No: Go to 8.b.
    2. Specify the language type.

      In the MML Command - MRP6600 window, run ADD LANGTYPE to set the language to the planned one. Then, check whether the announcement playing failure has been rectified.

      • Yes: No further action is required.
      • No: Go to 26.
    3. Check whether the voice file is absent.
      1. Check the var field in the H248_MOD_REQ message. This section uses the H248_MOD_REQ message in a fixed intelligent network (IN) tone as an example. The var field contains information such as language type string, tone ID, and tone type, as shown in Figure11 var field in the H248_MOD_REQ message.
        Figure 9-15 var field in the H248_MOD_REQ message
        NOTE:
        The information contained in the var field is described as follows:
        • t=tone: The tone type is fixed IN tone.
        • tid=298: The tone ID is 298.
        • lang=en: The language type string is en.
      2. In the MML Command - MRP6600 window, run LST LANGTYPE with Language type string set to the language type string in the var field in the H248_MOD_REQ message and check the value of Language type ID in the command output. If the command is successfully executed, the following command output is displayed:
        %%LST LANGTYPE: LSTRING="en";%% 
         RETCODE = 0  Operation succeeded 
          
         The result is as follows 
         ------------------------ 
              Language type string  =  en 
                  Language type ID  =  1 
         Language type description  =  NULL 
         (Number of results = 1) 
          
         ---    END
      3. In the MML Command - MRP6600 window, run DSP TONEFILE with Language type ID set to the language type ID obtained in 8.c.ii, and VPU module No. set to 651. Then check whether the command output contains a record where the values of Tone ID and Tone type are the same as those in the var field.

        If the command is successfully executed, the following command output is displayed:

        %%DSP TONEFILE: VPUMID=651, CODEC=AMR, AMRRATE=AMR_RATE_4_75;%% 
         RETCODE = 0  Operation succeeded 
          
         The result is as follows 
         ------------------------ 
                  VPU module No.  =  651 
                         Version  =  MRP6600V500R008C00 
                       Timestamp  =  2014-07-22 11:01:33 
                           Codec  =  AMR 
                            Rate  =  4.75kbps 
                 Number of tones  =  2 
         Number of this language  =  2 
         (Number of results = 1) 
          
         The result is as follows1 
         ------------------------- 
          Language type ID  Service type  Tone ID  Tone type 
          
          1                 0             0        fix       
          1                 0             1        fix       
         (Number of results = 2) 
          
         ---    END 
        • Yes: Go to 26.
        • No: Go to 8.d.
    4. Re-create a tone package according to service requirements. For details, see Creating MRFP Static Tone Files and Creating MRFP Local Media Files. Then, load the tone package. For details, see Loading MRFP Tone Files.

      Then, check whether the announcement playing failure has been rectified.

      • Yes: No further action is required.
      • No: Go to 26.
  6. Check whether the error code 616 is carried in the H248_NOTIFY_REQ message. See Figure 9-10.
    • Yes: Go to 10.
    • No: Go to 26.

    Check the cause why the error code 616 is carried in the H248_NOTIFY_REQ message.

  7. Check the location of the announcement playing file.
    1. Check the location of the announcement playing file delivered in the H248_MOD_REQ message. SeeFigure12 File placing in the NFS server andFigure13 File placing in the MRFP
      Figure 9-16 File placing in the NFS server
      Figure 9-17 File placing in the MRFP
    2. In the MML Command - MRP6600 window, run DSP LOCALFILE to check whether the announcement playing file specified in the H248_MOD_REQ message is the file specified by Filename. See Figure 9-21.

      If the command is successfully executed, the following command output is displayed:

      %%DSP LOCALFILE: VPUMID=652, CODEC=AMR, AMRRATE=AMR_RATE_4_75;%% 
       RETCODE = 0  Operation succeeded 
        
       The result is as follows 
       ------------------------ 
        VPU module No.  =  652 
               Version  =  MRP6600V500R008C00 
             Timestamp  =  2014-07-22 14:45:50 
                 Codec  =  AMR 
                  Rate  =  4.75kbps 
       Number of tones  =  2 
       (Number of results = 1) 
        
       The result is as follows 
       ------------------------ 
        Size(Byte)      Filename                
        
        181784          local://wav2/048.wav 
        110448          local://wav2/049.wav 
       (Number of results = 2) 
        
       ---    END 

      Yes: Go to 10.f.

    3. In the MML Command - MRP6600 window, run LOD LOCALFILE to add the required file. Then, check whether the announcement playing failure has been rectified.
      • Yes: No further action is required.
      • No: Go to 10.f.
    4. Log in to the NFS server.

      Log in to the NFS server in Secure Shell (SSH) mode by using the PuTTY tool.

      For details on how to use the PuTTY tool, see Using the PuTTY.

      Figure 9-18 shows the location of the announcement playing file specified in the H248_MOD_REQ message.

      Figure 9-18 H248_MOD_REQmessage
      • Enter the user name root for login as, and press Enter.
      • Enter the password huawei for password, and press Enter.
      • Enter cd /directory holding the file to access the directory.

      Check whether the announcement playing file exists in the directory.

    5. Upload the announcement playing file to the NFS server according to steps in under Installation and Commissioning > Initial Configuration > Configuring the Basic Data > Configuring the Interworking Data > Configuring the Built-in NFS of the OSG9930 Product Documentation. Then, check whether the announcement playing failure has been rectified.
      • Yes: No further action is required.
      • No: Go to 10.f.
    6. Check the usage of the configured codec resources.

      Run DSP MRSTS in the MML Command - MRP6600 window to view codec resource information about Total resource capability, Idle resource capability, and Fault resource capability.

      • If Total resource capability is 0, go to 26.
      • If Idle resource capability is 0, go to 26.
      • If Fault resource capability is greater than or equal to 20% of Total resource capability, go to 26.
    7. Check whether the announcement playing failure is rectified.
      • Yes: No further action is required.
      • No: Go to 26.
  8. In the MML Command - MRP6600 window, run PING to ping the terminal's IP address. Check whether Packet loss ratio is 0.

    If the command is successfully executed, the following command output is displayed:

    %%PING: IPTYPE=IPV4, IP="10.3.21.55", SRCIP="10.3.21.54";%% 
     RETCODE = 0  Operation succeeded  
      
     The result is as follows: 
     ------------ 
                      Local IP address  =  10.3.21.54 
                Number of sent packets  =  4 
            Number of received packets  =  4 
                     Packet loss ratio  =  0 
                    Maximum round time  =  20 
                    Minimum round time  =  10 
                    Average round time  =  15 
      
     (Number of results = 1) 
      
     The result is as follows: 
     ------------ 
      Round time (ms)  TTL    
      
      0               255    
      10              255    
      10              255    
      0               255    
     (Number of results = 4)
    • Yes: Go to 13.
    • No: Go to 12.
  9. Rectify the fault on the IP network between the terminal and the gateway according to IP Network Failure. Then, check whether digit collecting is successful.
    • Yes: Go to 17.
    • No: Go to 13.
  10. Contact the technical support engineers of the terminal to check the type of the transmitted digit.
    • RFC2833 digit collecting: Go to 14.
    • DTMF digit collecting: Go to 15.
  11. Troubleshoot the RFC2833 digit collecting failure.
    1. Contact the network administrator to check whether packet loss occurs on the bearer network.
    2. Rectify the fault on the IP network between the terminal and the gateway according to IP Network Failure. Then, check whether the digit collecting failure has been rectified.
    3. Check whether the H248_ADD_REQ message received by the MRFP carries the attribute defined in RFC2833. See Figure15 Content of theH248_ADD_REQ message.
      Figure 9-19 Content of theH248_ADD_REQ message
    4. Check whether the value of RFC2833 PayLoadType carried in the H248_ADD_REQ message received by the MRFP is the same as that of RFC2833 PayLoadType carried in the bearer message transmitted by the terminal.
      • Capture the IP packets transmitted to the MRFP, and then identify the IP packets that are transmitted by the terminal. Select the RFC2833 packets. The Payload type=RTP Event is RFC2833 packets. See Figure 16. Figure 17 shows the contents of the RFC2833 packets.
      Figure 9-20 RFC2833 packets
      Figure 9-21 Contents of theRFC2833 packets

      Check whether the value of RFC2833 PayLoadType carried in the H248_ADD_REQ message received by the MRFP is the same as that of RFC2833 PayLoadType carried in the bearer message transmitted by the terminal.

      • Yes: Go to 14.e.
      • No: Contact technical support engineers of the terminal.
    5. Check whether the RFC2833 packets comply with telecommunications standards.

      The following requirements are defined by the standards of telecommunications networks:

      • Each digit must correspond to at least one RFC2833 packet that carries the end flag.
      • The timestamps of all RFC2833 packets for the same digit must be the same.
      Figure 9-22 RFC2833 packets
      Figure 9-23 Contents of theRFC2833 packets

      Check whether the RFC2833 packets transmitted by the terminal comply with RFC 2833 telecommunications standards. See Figure 9-22 and Figure 9-23.

      • Yes: Go to 14.f.
      • No: Contact technical support engineers of the terminal.
    6. Check whether the timestamps of all RFC2833 packets for two identical consecutive digits are the same. Figure 19 shows the timestamps of the RFC2833 packets.
      • Yes: Contact technical support engineers of the terminal.
      • No: Go to 26.
  12. Check whether the voice codec used by the terminal is G.711.

    Check whether the value of the field marked with red in the H248_ADD_RESP message is 0 or 8 (G.711μ or G.711A).

    Figure 9-24 H248_ADD_RESPmessage
    • Yes: Go to 26.
    • No: Go to 16.
  13. Troubleshoot the DTMF digit collecting failure of non-G.711 users.

    DTMF digit collecting is not supported by non-G.711 users. You need to contact technical support engineers of the terminal to change the codec used by the terminal or apply for RFC2833 digit collecting. Then, check whether the digit collecting failure has been rectified.

    • Yes: Go to 17.
    • No: Go to 26.
  14. Check whether the announcement playing failure has been rectified.
    • Yes: No further action is required.
    • No: Go to 26.
  15. In the MML Command - MRP6600 window, run PING to ping the terminal's IP address. Check whether Packet loss ratio is 0.

    If the command is successfully executed, the following command output is displayed:

    %%PING: IPTYPE=IPV4, IP="10.1.31.1", SRCIP="10.1.31.18";%% 
     RETCODE = 0  Operation succeeded 
      
     The result is as follows(0) 
     --------------------------- 
               Local IP address  =  10.1.31.18 
         Number of sent packets  =  4 
     Number of received packets  =  4 
              Packet loss ratio  =  0 
             Maximum round time  =  10 
             Minimum round time  =  0 
             Average round time  =  5 
     (Number of results = 1) 
      
     The result is as follows(1) 
     --------------------------- 
      Round time (ms)  TTL    
      
      0                255    
      10               255    
      10               255    
      0                255    
     (Number of results = 4)
    • Yes: Go to 26.
    • No: Go to 19.
  16. Rectify the fault on the IP network between the terminal and the gateway according to IP Network Failure. Then, check whether the users can hear voices.
    • Yes: Go to 20.
    • No: Go to 26.
  17. Check whether the announcement playing failure has been rectified.
    • Yes: No further action is required.
    • No: Go to 26.
  18. In the MML Command - MRP6600 window, run PING to ping the terminal's IP address. Check whether Packet loss ratio is 0.

    If the command is successfully executed, the following command output is displayed:

    %%PING: IPTYPE=IPV4, IP="10.1.31.1", SRCIP="10.1.31.18";%% 
     RETCODE = 0  Operation succeeded 
      
     The result is as follows(0) 
     --------------------------- 
               Local IP address  =  10.1.31.18 
         Number of sent packets  =  4 
     Number of received packets  =  4 
              Packet loss ratio  =  0 
             Maximum round time  =  10 
             Minimum round time  =  0 
             Average round time  =  5 
     (Number of results = 1) 
      
     The result is as follows(1) 
     --------------------------- 
      Round time (ms)  TTL    
      
      0                255    
      10               255    
      10               255    
      0                255    
     (Number of results = 4)
    • Yes: Go to 22.
    • No: Go to 24.
  19. Capture the IP packets transmitted to the MRFP, and then identify the IP packets that are transmitted by the terminal. Check whether the Lost RTP packets value is 0.
    • Yes: Go to 23.
    • No: Go to 24.
  20. Check whether the network jitter is within the jitter range allowed by the MRFP.
    • Yes: Go to 26.
    • No: Go to 24.
  21. Rectify the fault on the IP network according to IP Network Failure. Then, check whether the voice quality is good.
    • Yes: Go to 25.
    • No: Go to 26.
  22. Check whether the announcement playing failure has been rectified.
    • Yes: No further action is required.
    • No: Go to 26.
  23. Contact Huawei technical support engineers to rectify the fault.

A Participant Tries Joining a Conference Using IVR But Is Prompted the Call Ends

Symptom

When the USM and MRP are deployed separately, the MRP is interconnected with the NFS properly and plays announcements properly.

After the USM is redeployed and NFS connection is configured, the FS is available, but it fails to play announcements. A message is displayed, indicating that the announcement file does not exist. In fact, the announcement file can be queried on the server.

Possible Causes

The MRP mounting is abnormal. As a result, announcements fail to be played due to a link fault.

Troubleshooting Method

In the scenario where the USM and MRP are deployed separately, if the link between the USM and MRP is abnormal after the USM is redeployed, you can restart the MRP.

Solution
  1. Log in to the Huawei Operation & Maintenance System as the admin user and access the MML Command - CGP window.
  2. Run the RST ME command by setting ME IDto the ID of the MRP6600 NE to restart the MRP.

    NOTE:

    To query the ID of the MRP6600 NE, run the LST ME command.

Translation
Download
Updated: 2019-08-07

Document ID: EDOC1100059098

Views: 19684

Downloads: 12

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next