.
QSIG ping-pong of CT_UPDATE_OP messages
PROBLEM TEXT:
CS1K with DTI trunks to some nodes and QSIG to a third party node is having calls from the DTI forwarded to the QSIG. In some cases the call is transferred on the QSIG node which generates a sequence of incoming CT_COMPLETE_OP, outgoing CT_UPDATE_OP. In the DTI tandem case, at times the far end of the QSIG connection does not like the CT_UPDATE_OP message and sends back a RejectPDU with indication of a 'General Problem - Mistyped Comp'.
In some percentage of these cases the CS1K sends a new CT_UPDATE_OP in response to the RejectPDU message. The next CT_UPDATE_OP message is also rejected. Intermittently this process continues as long as the call stays established, creating high traffic on the DCH. This ping pong of CT_UPDATE_OP and RejectPDU messages is also strongly suspected to be the cause of a BUG4001 issue that the site has. What is seen in that case, is that a call that was ping ponging messages suddenly begins to accumulate son call registers of C87 type (.UIPE_GF_CR) on the C31 type (.PRA_MSG_CR) father.
From working with the site it was found that most if not all of these son call registers contain the RejectPDU coding. IMPACT: Very little visible evidence of the problem exists other than a few of the MSG LOG CONFIRM messages indicating an excessive number of CC_FACILITY messages and DISCONNECT messages. At times, there is evidence that the DCH is going into Flow control as well. When the BUG4001 part of the ping pong occurs, the terminal is bogged down for 15 to 20 minutes printing the BUG4001, and associated messages. When did problem first occur (date and circumstances)? Site is patch current on 7.65P SP4 Diagnostic MPLR33283 was installed to attempt to find the cause of the BUG4001. In it confirmed the ping pong is inter-related with the accumulation of too many son call registers which is what triggers the BUG4001 storms. Configuration changes SETUP and ACTIONS performed to cause the problem:
HARDWARE and DATA SETUP: CS1K connected to third party system via QSIG, other systems via DTI, and the Central Office via NI2
. Set A - On remote site connected via DTI. Set B - On CS1K with CFW All Calls to Set C. Set C and D - On system connected by QSIG.
ACTIONS: 1. Set A calls Set B which is forwarded to Set C.
2. Set C answers and transfers to Set D.
3. Set D answers.
EXPECTED RESULTS
: 1. Outgoing setup message on the QSIG leg with appropriate Divert information.
2. QSIG side sends CT_COMPLETE_OP message
. CS1K responds with a CT_UPDATE_OP message. QSIG side responds with a CT_UPDATE_OP message. CS1K responds with a CT_UPDATE_OP message.
3. No additional CT_UPDATE_OP messages are required
. ACTUAL RESULTS:
1. As expected.
2. QSIG side sends CT_COMPLETE_OP message. CS1K responds with a CT_UPDATE_OP message. QSIG side responds with an error indicating they did not like the CT_UPDATE_OP message. CS1K responds with a CT_UPDATE_OP message.
3. CS1K continues to resend the CT_UPDATE_OP message as long as the QSIG side continues to send the response. This continues until the call disconnects
. MPLR33303 installed on site to prevent the ping pong, which will resolve the BUG4001 storms.
PROBLEM TEXT:
CS1K with DTI trunks to some nodes and QSIG to a third party node is having calls from the DTI forwarded to the QSIG. In some cases the call is transferred on the QSIG node which generates a sequence of incoming CT_COMPLETE_OP, outgoing CT_UPDATE_OP. In the DTI tandem case, at times the far end of the QSIG connection does not like the CT_UPDATE_OP message and sends back a RejectPDU with indication of a 'General Problem - Mistyped Comp'.
In some percentage of these cases the CS1K sends a new CT_UPDATE_OP in response to the RejectPDU message. The next CT_UPDATE_OP message is also rejected. Intermittently this process continues as long as the call stays established, creating high traffic on the DCH. This ping pong of CT_UPDATE_OP and RejectPDU messages is also strongly suspected to be the cause of a BUG4001 issue that the site has. What is seen in that case, is that a call that was ping ponging messages suddenly begins to accumulate son call registers of C87 type (.UIPE_GF_CR) on the C31 type (.PRA_MSG_CR) father.
From working with the site it was found that most if not all of these son call registers contain the RejectPDU coding. IMPACT: Very little visible evidence of the problem exists other than a few of the MSG LOG CONFIRM messages indicating an excessive number of CC_FACILITY messages and DISCONNECT messages. At times, there is evidence that the DCH is going into Flow control as well. When the BUG4001 part of the ping pong occurs, the terminal is bogged down for 15 to 20 minutes printing the BUG4001, and associated messages. When did problem first occur (date and circumstances)? Site is patch current on 7.65P SP4 Diagnostic MPLR33283 was installed to attempt to find the cause of the BUG4001. In it confirmed the ping pong is inter-related with the accumulation of too many son call registers which is what triggers the BUG4001 storms. Configuration changes SETUP and ACTIONS performed to cause the problem:
HARDWARE and DATA SETUP: CS1K connected to third party system via QSIG, other systems via DTI, and the Central Office via NI2
. Set A - On remote site connected via DTI. Set B - On CS1K with CFW All Calls to Set C. Set C and D - On system connected by QSIG.
ACTIONS: 1. Set A calls Set B which is forwarded to Set C.
2. Set C answers and transfers to Set D.
3. Set D answers.
EXPECTED RESULTS
: 1. Outgoing setup message on the QSIG leg with appropriate Divert information.
2. QSIG side sends CT_COMPLETE_OP message
. CS1K responds with a CT_UPDATE_OP message. QSIG side responds with a CT_UPDATE_OP message. CS1K responds with a CT_UPDATE_OP message.
3. No additional CT_UPDATE_OP messages are required
. ACTUAL RESULTS:
1. As expected.
2. QSIG side sends CT_COMPLETE_OP message. CS1K responds with a CT_UPDATE_OP message. QSIG side responds with an error indicating they did not like the CT_UPDATE_OP message. CS1K responds with a CT_UPDATE_OP message.
3. CS1K continues to resend the CT_UPDATE_OP message as long as the QSIG side continues to send the response. This continues until the call disconnects
. MPLR33303 installed on site to prevent the ping pong, which will resolve the BUG4001 storms.
