NIC Checklist

From DocWiki

(Difference between revisions)
Jump to: navigation, search
Line 54: Line 54:
{| border="1"
{| border="1"
|'''Frequently occuring Issues'''
|'''Frequent Issues'''

Revision as of 14:28, 2 June 2010

Preliminary Checklist 1. Check with the Customer to understand if any changes/upgrades were done before a problem was seen. If any, complete details to be provided by the customer.

2. Check if all the registry parameters related to the scenario are conforming with the values specified in the Customer facing documents

3. Analyze the logs thoroughly to check if the problem is seen due to any public or private network issues.

4. Do a topic search to check if any past cases/defects will help resolving this issue.

5. Is the NIC setup a duplex or a simplex one? If it is a duplex, is the problem seen on both the sides if the calls were being sent to both the sides and if not, and then check to see if any private network problems could have caused the issue.

6. Enable correct trace levels for NIC to log the required messages for the problem.

7. If the NIC being used is SS7InNic, the required traces levels are to be set using ss7nictrace tool. The tool can be opened by giving "ss7nictrace" at the "Start->Run" prompt.

Trace levels If the customer is in a production environment:

For CRSP NIC: EMSTraceMask – 0x716

For SS7 NIC : Use ss7nictrace tool to enable relevant traces

For other NICs: EMSTraceMask – 0x700

If it is a lab environment:

For CRSP NIC: EMSTraceMask – 0x716 , EMSuserData – FE

For SS7 NIC  : Use ss7nictrace tool to enable relevant traces

For ATT NIC: EMSTraceMask – 0x822

For CWC NIC: EMSTraceMask – 0x822

For GKTMP NIC : EMSTraceMask - 0x1565

For ICRP\INCRP NICs: EMSTraceMask - 0x200

For MCI NIC: EMSTraceMask – 0x865

For NT NIC: EMSTraceMask – 0x823

For NTL NIC: EMSTraceMask – 0x775

For Sprint NIC: EMSTraceMask - 0x825

For Stentor NIC: EMSTraceMask - 0x745

For TIM NIC: EMSTraceMask – 0x734

Frequent Issues Checklists
SCP Issues/Version compatibility issues 1. 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.

2. 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.

3. 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.

4. 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?

NCT issues 1. 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.

2. For the Network Transfer feature to work, “NetworkTransferEnabled” should be set to 1. This can be seen from the NIC logs (Connect OPI Message)

3. If the call scenario is a NCT scenario, then mention in detail, the sequence of operations performed ( transfer(blind or consult), conference)

4. 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 1. What is the Customer's Busy Hour Call Rate?

2. Any system update or Maintenace Back up performed at the time of the problem.

3. If it is a duplex configuration, did the NICs on both sides restart?

4. 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.

5. Check to see if there are any timeouts in the NIC logs (this can be seen with default tracing)

6. Any ES/ET installed before seeing the problem?

Call event Reporting/Dropoffs 1. 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.

2. 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.

3. Checked If an ES/ET has been installed before seeing the problem.

VRU Types 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.

Rating: 0.0/5 (0 votes cast)

Personal tools