The information in this document is based on these software versions:
CVP Server 9.0 and above
UCCE 9.0 and above
IOS gateway 15.X
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
When a service is added to an incoming PoTs Dialpeer to trigger the Survivability script, the call fails with this cause:
Note: run the debug command, debug voip ccapi inout, in order to see the error code reported when the call fails. In addition, run the debug command debug ccsip message if you want to see the SIP error messages reported when the call fails.
Inconsistent error messages are reported when the debug ccsip message is enabled. SIP messages, do not give much indication other than that the call fails after network VRU label is returned, which can be misleading.
If the service is removed from the from the incoming pots dial-peer, everything works fine.
Step 1. One the Ingress gateways enable the debugs: debug voip ccapi inout, debug ccsip message, debug voice application all, and debug isdn q931.
Step 2. Recreate the problem. Place a call to the gateway.
Step 3. Collect the logs. Use the command, show logging.
If you look at the CCAPI logs (debug voip ccapi inout), you just see the call gets successfully handed off the survivability script and then the call fails:
Now, if you dive down to the isdn messages (debug isdn q931) you see that the messages are not in sync with the PSTN messages. There is a FACILITY message that is coming in immediately after the setup and before the call proceeding. The survivability script is not able to handle this situation.
The L3_BadPeerMsg is the key here to solve this problem. This error is reported when there is a mismatch on the switch type between the gateway and the PSTN.
The recommendation is to run the command to set the ISDN switch type that the PSTN and the gateway agree. In this scenario the switch type on the PSTN is primary-ni. For US customers, the switch-type commonly used is primary-ni.
The command isdn switch-type primary-ni configured on the ingress gateway solved the problem.