SIP-SGRP error log entries and recommended actions

Last Updated : Sep 18, 2023 |
Table 1: SIP-SGRP Error Log Entries

Error type

Aux data

Associated test

Alarm level

On/Off board

Command to resolve the error

0

0

Any

Any

test signaling-group grp#

1

Any

Ethernet Port Status test (#1386)

MIN

OFF

test signaling-group grp#

18

0

busyout signaling-group grp#

WRN

OFF

release signaling-group grp#

257

Any

Signaling Group Ping (#1387)

MIN

OFF

test signaling-group grp#

258

IP Signaling Group Far-end Status Test (#1675)

513

Any

Signaling Group Ping (#1387)

WRN

OFF

test signaling-group grp#

770

Any

WRN

OFF

1025

Any

MEDPRO Status test (#1392)

MIN

OFF

test signaling-group grp#

1281

Any

MEDPRO Status test (#1392)

MIN

OFF

1537

Any

IP Signaling Group Far-end Status Test(#1675)

MIN

OFF

test signaling-group group#

1794

MEDPRO Status test (#1392)

MIN

OFF

test signaling-group grp#

2561

Any

Registered to Survivable Remote Server Inline Error

MIN

OFF

3073

19

Far-end TLS Certificate Failure Inline Error

MIN

OFF

3329

21

Near-end TLS Certificate failure Inline Error

MIN

OFF

3585

IP Signaling Far-end Status Test (#1675)

MIN

OFF

3841 - 3942
Note:

  1. Error type 0: Run the short test sequence first. If every test passes, run the long test sequence. Refer to each appropriate test’s description, and follow its recommended procedures.

  2. Error type 1: Failure of IP-PROCR carrying the signaling group channel.

  3. Error type 18: The signaling group has been busied out by command. Release the signaling group, if appropriate, with release signaling-group grp#.

  4. Error type 257: Tracks failures of the SIP signaling-group PING test. See Signaling Group Ping Test (#1387) for test failure information.

  5. Error type 258: Tracks failure of the primary signaling channel.

    When the far-end signaling group encounters a primary signaling link which is down, it starts sending Polling Subscriptions to Communication Manager on a secondary signaling link. Communication Manager runs the IP Signaling Group Far-End Status Test (#1675) to validate if the primary signaling link is not working properly. Following are the possible outcomes:

    • If the test fails, the primary signaling link is withdrawn from service and an alarm is raised.

    • If the test passes, the primary signaling link is fixed back to service and the alarm is retired.

  6. Error type 513: Tracks excessive round-trip delay of the SIP signaling-group PING test, if the round-trip delay exceeds 4 seconds. See Signaling Group Ping Test (#1387) for test failure information.

  7. Error type 770: Tracks excessive latency and packet-loss from background IP measurements collected by the Media Processor Board. Indicates that test packets sent from a media processor circuit pack to the far-end IP address specified on the signaling-group form have exceeded the IP latency and loss thresholds, as administered on the system-parameters ip-options form. Exceeding these thresholds indicates that the IP network may not be providing sufficient quality of service for adequate transmission of voice. If the signaling group has been administered to enable BYPASS, then Error Type 1025 also occurs.

  8. Error type 1025: The signaling group has been placed into a BYPASS condition because of IP network congestion. The signaling group accepts incoming calls, but every outgoing call is denied. The system routes these calls over a secondary route, if one has been administered.

  9. Error type 1281: No medpro resources are in service to provide media connections for the trunk members of the signaling group.

    Check for errors against the MEDPRO and MEDPROPT maintenance objects. This error causes all SIP B-channels to be in an out-of-service near-end state.

  10. Error type 1537: The far end of the signaling group is not ready to handle audio bearer. If the other end of this signaling group is also a Communication Manager server, this error means the server on the other end does not have MEDPRO in-service for its signaling group.

    This error places the SIP B-channels into an out-of-service far-end state.

  11. Error type 1794: The Signaling Group reported that the far end has detected excessive packet latency or loss. This error places the SIP B-channels into an out of service far-end state.

  12. Error type 2561: The signaling group is registered to a Survivable Remote Server.

  13. Error type 3073: A TLS connection was established with the far-end but authentication with the far-end’s TLS certificate failed. Due to this condition, the signaling group will be placed in far-end bypass state so that no outgoing calls will be allowed,. The trunks in the group will be placed in an out of service far end state (OOSFE). Incoming calls will be accepted, but until the far-end’s TLS certificate is remedied, these will not be successful. Once the far-end’s certificate is remedied, an incoming call can succeed and the trunk group will be put back in service.

  14. Error type 3329: The near end TLS certificate is bad. The trunks in the group will be placed in a near end out of service state and the signaling group will be placed in bypass. No trunk calls either incoming or outgoing will be allowed until the near end’s certificate is corrected. The system is warm started (reset system 1), and the signaling groups go through a busy/release action. If the near end certificate is bad, listen sockets fro the signaling group will not be created, so this alarm is raised at the creation of the listen socket stage that is when initially bringing the signaling group into service.

    Note:

    Near end certificate authentication is the process of validating that the server certificate is OK, i.e., we have the private key and the certificate is trusted. This will only break if a user with root access has changed the certificate private key file.

  15. Error type 3585: IP Signaling Far-end Status Test failed. The far-end is not available. See IP Signaling Group Far-End Status Test (#1675) for more information.

  16. Error types 3842 - 3942: These Error Types report certain error messages received by the SIP Signaling Group for one of its associated D-channels. The aux data field shows for which D-channel the message was received.

    The generated error code is represented by the value 3840+x, where x is the Cause Value. The Cause Value provides additional data that may be useful when tracking down obscure networking and routing problems.

    Table 229: Descriptions and Recommendations for Error Types 3842-3942 provides a description of the error code and the recommended actions to troubleshoot the problem.

    Table 2: Descriptions and Recommendations for Error Types 3842-3942

    Error Code

    Description/Recommendation

    3842

    Cause Value 2. A request has been made to use a transit network or common carrier that cannot be accessed. The equipment sending this cause event does not recognize the transit network.

    1. From the circuit pack or media module and port number in the Aux Data field, determine the trunk group against which the error was reported.

    2. Check every routing pattern containing this trunk group for validity of interexchange carriers requested (IXC field).

    3843

    Cause Value 3. No route to destination. Request received to route call through a transit network that is recognized but not allowed to carry the call or not able to serve the destination. The service provider cannot route the call to the indicated destination. Communication Manager does not originate Cause Value 3.

    The repair steps are based on Tier 4 recommendations:

    1. Check the numbers sent for any missing prefixes or service values that were needed to access the network.

    2. Check the Cause Information Element Location Code.

    3. Check Communication Manager administration:

      1. Dial plan/Location: The home NPA is administered incorrectly, causing incorrect code conversion.

      2. IXC: The IXC matching pattern is administered incorrectly or not at all on the dial plan, causing incorrect IXC manipulation.

      3. AAR/ARS digit conversion: The wrong digit string substitution is being made. The call is being routed into the wrong network and over the wrong route pattern. Further conversion is needed but the dial string is restricted from further conversion.

      4. AAR/ARS digit analysis: Call type is incorrect for the call being made specifying the wrong type of number and/or number plan information, or it is preventing code conversion from taking place. Call is being routed to the incorrect route pattern where the incorrect digit manipulation and/or code conversion is taking place.

      5. ARS toll analysis: Toll/no toll classification is incorrect, causing incorrect code conversion at the route pattern.

      6. Route pattern: Incorrect code conversion due to wrong entries in NPA, prefix mark, and toll list/prefix mark fields. Deleting the wrong number of digits or inserting the wrong digits. Failing to strip IXC or international code digits, stripping a user-dialed IXC code, or IXC forcing the call to the wrong inter-exchange carrier. Number format changed to a format incorrect for the call type. The incorrect service or feature is specified for the call being made on a CBC trunk group preference.

    3846

    Cause Value 6. The far-end switch has indicated that the B-channel (trunk) is not acceptable for use in the call for which it was requested.

    This could indicate an administration problem. For example, the local switch and the far-end switch have different B-channels administered. It could also reflect the occurrence of a normal race condition. For example, the local switch has requested use of a B-channel that the far-end switch had just reserved for use on another call.

    1. From the circuit pack or media module and port number in the Aux Data field, determine the trunk group against which the error was reported.

    2. Enter status trunk for the indicated trunk. Refer to DS1 ISDN Trunk Service States and ISDN-PRI Trunk Service States sections of ISDN-TRK (DS1 ISDN Trunk) for recovery suggestions.

    3858

    Cause Value 18. The switch sent a message to the far-end switch or terminal adapter that did not respond in the time allowed. The remote device/endpoint did not respond with an ALERTING/PROGRESS/CONNect indication within the time administered in the T303 or T310 timers Q.931 specification. Cause Value 18 indicates high traffic conditions in the serving network or noisy conditions on the span carrying the D-channel messaging. The noise is causing the loss of messages being sent to the remote device. The remote device might also be unable to respond to the incoming SETUP message. This Cause Value has end-to-end significance and should always be passed back through the network to the user.

    3878

    Cause Value 38. The far-end switch has indicated that the network is not functioning correctly and that the condition may last a relatively long period of time. For example, immediately re-attempting the call may not be successful. The network is out of order.

    1. From the circuit pack or media module and port number in the Aux Data field, determine the trunk group against which the error was reported.

    2. Consult with the network provider to determine the nature and expected duration of the out-of-service condition.

    3. Consider modifying every routing pattern containing this trunk group to route calls around the network that is out of service.

    3890

    Cause Value 50. A request to use a network service has been denied. Administration somewhere on the network has indicated that the requested service has not been subscribed to or purchased for this trunk.

    This could be a local administration problem only, or a mismatch between the local administration and that of the network provider.

    1. From the media module and port number in the Aux Data field, determine the trunk group against which the error was reported.

    2. Display the trunk group form: If the trunk group is Call-by-Call (Service Type is cbc), check every routing pattern form containing this trunk group to see if the Service/Feature fields contain the correct network services purchased for this trunk. If the trunk group is not Call-by-Call, check that the Service Type field contains the single network service purchased for this trunk.

    3. If local administration is correct, consult with the customer and/or the network provider to determine the services that the customer has subscribed to for this trunk group.

    3892

    Cause Value 52. Protocol detail; may offer a clue if customer is having calls denied with an unexpected intercept tone. If the customer is complaining of unexpected intercept tones and no other cause can be found, escalate the problem and provide the next tier with this Error Log information.

    3894

    Cause Value 54. Protocol detail; may offer a clue if customer is having calls denied with an unexpected intercept tone. First, eliminate any transitory state mismatch problems by entering test port location for the trunk port shown in the Aux Data field. Service State Audit Test (#256) is the important test in the sequence. If this passes satisfactorily, yet the customer continues to complain of unexpected intercept tones and no other cause can be found, escalate the problem and provide the next tier with this Error Log information.

    3902

    FRANCE ONLY: Cause Value 62. Service not authorized.

    Call rejected. This Cause Value has end-to-end significance and should always be passed back through the network to the user.

    Cause Value 62 (VN4) indicates that the call could not be completed because the user has not subscribed to the service, feature, or supplementary service requested in the SETUP message. If the user is supposed to have access to this service, feature, or supplementary service, complete the required ordering process with the service provider.

    Cause Value 62 (1TR6) indicates that the remote endpoint does not accept this call, although it could have accepted the call because the equipment is neither busy nor incompatible. The diagnostic information in the Cause information element might contain the user-supplied condition for why the call was rejected.

    3903

    Cause Value 63. Service or option not available, unspecified. This cause value is used to report a “service or option not available” event only when no other cause in the “service or option not available” class applies. This Cause Value shall either be passed to the user or mapped to Cause Value 41 (temporary failure) when it is received at a CO as part of SS7 call handling. Communication Manager does not originate Cause Value 63.

    3905

    Cause Value 65. Protocol detail; may offer a clue if customer is having ISDN calls denied with an unexpected intercept tone. If the customer is complaining of unexpected intercept tones and no other cause can be found, escalate the problem and provide the next tier with this Error Log information.

    3906

    Cause Value 66. Protocol detail; may offer a clue if customer is having ISDN calls denied with an unexpected intercept tone. If the customer is complaining of unexpected intercept tones and no other cause can be found, escalate to the problem and provide the next tier with this Error Log information.

    3909

    Cause Value 69. A request to use a network service has been made, but the network has rejected the request because the requested service is not implemented. Follow the recommendation for Error Type 3890, Cause Value 50.

    3910

    Cause Value 70. Only restricted digital bearer capability available. The call could not be completed because the equipment sending this Cause Value only supports the restricted version of the requested bearer capability, and in the SETUP message, bearer capability was unrestricted. Communication Manager does not originate Cause Value 70.

    The repair steps are based on recommendations from Tier 4 ISDN experience:
    1. Check Communication Manager administration (network generated the Cause Value):

      1. Route pattern: An incorrect ITC and/or BCIE specified. These fields affect how the bearer capability is encoded in the SETUP message.

      2. The ITC administered on the originating endpoint might be incorrect for this call and/or the speed options in the device itself might be incorrect for calls over these ISDN facilities.

      3. Incorrect data speed option is set in the BRI device, causing a call from a BRI endpoint tandeming through Communication Manager to create a SETUP message with the wrong bearer capability.

      4. A call tandeming through Communication Manager ISDN trunk group to ISDN trunk group might have a bearer capability that is not supported by the outgoing ISDN facilities or network.

      5. A call tandeming through Communication Manager on a non-ISDN trunk group inter-working to an ISDN trunk group might have an incorrect bearer capability assigned on the incoming trunk group. The BC and ITC fields on the incoming trunk group may be set wrong.

    3919

    Cause Value 79. Service or option not implemented or unspecified. The call could not be completed because the equipment sending this Cause Value has not implemented a service, feature, or supplementary service requested by the user, and none of the other Cause Values in the Service or Option Not Implemented class apply. As an implementation option, this Cause Value might be mapped to Cause Value 41 (temporary failure) when it is received at a CO as part of SS7 call handling. Communication Manager does not originate Cause Value 79.

    3928

    Cause Value 88. A call was denied because a basic incompatibility existed between the type of call and either the facilities selected by the routing pattern or the called user. This error may offer a clue if the customer complains of receiving unexpected intercept tone.

    1. Determine the trunk group from the media module and port number in the Aux Data field.

    2. Check the BCC fields of the pertinent routing patterns.

    3. Investigate whether or not the calling and called endpoints are compatible. For example, some switches may not allow a voice station to call a data extension.

    3942

    Cause Value 102. Recovery on timer expiry. No answer to CALL PROCEEDING.

    The equipment sending this Cause Value sent or received a Layer 3 Q.931 message. Sending or receiving this message has initiated a Layer 3 timer that has expired. This Cause Value is being generated in conjunction with Q.931 protocol error handling procedures. The ISDN network between the user and the equipment generating the Cause Value might:

    • Send no cause indication through the network.

    • Send a more generic Cause Value through the network.

    The repair steps are based on recommendations from Tier 4 ISDN experience:

    1. Check the diagnostic information for the timer number that has expired.

    2. Check that the protocols at each end of the interface match. For example, both sides are NI-2.

      If the ends of the interface are running different protocols, they might be running with different values for their Layer 3 timers. If the protocols at each end of the interface match, the Communication Manager timer might have expired because:

      1. The far-end never saw the message because the message was corrupted in transmission by noise on the D-channel. Check for any type of T1/E1 facility errors.

      2. The far-end is experiencing a high traffic condition and did not have the processing time to parse the sent message before the timer expired.

      3. Even though the message was seen to be generated in an internal Communication Manager trace, the message was never transmitted out onto the D-channel. Perform an external protocol capture on the D-Channel to confirm the transmission of the suspect message.

    3942 (cont’d)
    1. To interpret the receipt of Cause Value 102 from the far-end, look at a trace/protocol capture of the messaging taking place, and find the last message received from the far-end before Cause Value 102 is received. The timer that expired is most likely the Layer 3 timer associated with that last message. If Communication Manager generated a message in between those two events that should have stopped the timer, the cause might be:

      1. The far-end never saw the message because the message was corrupted in transmission by noise on the D-Channel. Check for any type of T1/E1 facility errors.

      2. The far-end is experiencing a high traffic condition and did not have the processing time to parse the sent message before the timer expired.

      3. Even though the message was seen to be generated in an internal Communication Manager trace, the message was never transmitted out onto the D-Channel. Perform an external protocol capture on the D-Channel to confirm the transmission of the suspect message.

    2. If Communication Manager did not respond to the receipt of the last message from the far-end, then Communication Manager internal hardware and software become suspect, and troubleshooting the problem must proceed from that point.

    3. Communication Manager administration that can contribute to seeing timer expiry errors:

      1. Trunk group form: Incoming call handling table. If the Per call CPN/BN field is incorrectly populated in comparison to how the CO is programmed to send CPN or BN, it causes Communication Manager to send a FACILITY message to the CO requesting CPN/BN information and the CO will never respond. Communication Manager will log many timer expiry errors against the signaling group (Error Type 1, Aux Data 13).

      2. DS1 form: Protocol version: If Communication Manager is running custom protocol (protocol version A) and is connected to a Nortel DMS central office running custom protocol, Communication Manager will log timer expiry errors against the signaling group for DISCONNECT problems (Error Type 1, Aux Data 4) during high traffic conditions.

    3942 (cont’d)

    1. The DMS CO custom protocol implementation uses the ANSI recommended timer values for their Layer 3 timers while Communication Manager uses the ITU recommended timer values. The T305 timer in Communication Manager is 4 seconds while the same timer in the DMS is 30 seconds. This difference causes timer expiry problems in high traffic conditions. Change Communication Manager’s protocol version to c to line up the timers.