|SCP Issues/Version compatibility issues
- Analyzed the SCP logs corresponding to the NIC logs before the time of the problem to understand the sequence of messages that led to the problem.
- Is the right version of the SCP being used for CrspNicV3. If the CrspNic v3 is being used and SCP is at a lower version or vice versa, then the lower version is negotiated by both the parties (NIC and SCP). CrspNic V2 does not support consult transfer or conference.
- If the ICM version is lower to 8.0, and if crspnic is upgraded from V2 to V3, then the NodeManager image name of crspnic has to be manually changed to crspnicV3, else the NIC will not come online.
- If the NIC being used is SS7, ATT or INAP and if ICM version is equal to or above 7.5(9), is the gateway being used a sigtran gateway?
- If the Consult Transfer/Conference is to be supported by the SS7 NIC, the Call Model should be Generic Inap CS2 and the variable “NetworkTransferSupported” (both in script and NIC registry)should be set to “2”. If the value is set to 1, only “BlindTransfer” is supported and if set to “0”, Network transfer is not supported.
- For the Network Transfer feature to work, “NetworkTransferEnabled” should be set to 1. This can be seen from the NIC logs (Connect OPI Message)
- If the call scenario is a NCT scenario, then mention in detail, the sequence of operations performed ( transfer(blind or consult), conference)
- If the Network Consult Transfer does not work, check if the NICCallID in the ICR_NEW_CALL_REQ is eligible for Network Transfer.
- If YES, check if the post-routing script is correct.
- If NO, locate PRE_ROUTE_IND or DEVICE_TARGET_PRE_CALL_IND for the call in the OPC log. If the pre-route call data is sent to PG and the pre-route NICCallID is not valid,then the Network Transfer feature is not enabled and it has to be enabled. If the pre route call data is sent to PG and pre-route NICCallID is valid, then it could be a error with PG call object tracking or data handling.
|NIC restart problems
- What is the Customer's Busy Hour Call Rate?
- Any system update or Maintenace Back up performed at the time of the problem.
- If it is a duplex configuration, did the NICs on both sides restart?
- Check to see if the failure of Router to respond to heartbeat messages exchanged between NIC and the router caused the graceful shutdown of NIC.
- Check to see if there are any timeouts in the NIC logs (this can be seen with default tracing)
- Any ES/ET installed before seeing the problem?
|Call event Reporting/Dropoffs
- While using SS7 NIC, if calls are getting disconnected after a certain fixed time period in the wait queue. The issue could be with the timer in the SS7 network that would drop the call off after that fixed amount of time. The resolution is to change the value of the parameter "ResetTimer" in SS7 NIC to a lower value than network timer, so that timer gets reset and call does not get dropped.
- If the event reporting for a call has not been done, check to see that DISCONNECT is seen in the NIC for the call. If the disconnect is not seen, make sure that the PSTN is not causing the problem by not disconnecting the call.
- Checked If an ES/ET has been installed before seeing the problem.
||For A VRU model, Confirm if the NIC being used is SS7 NIC or CRSP NIC. If the NIC is CRSP, is the VRU type 5 or type 6? For both the NICs, check the call flow in the VRU specifications document.