> For the complete documentation index, see [llms.txt](https://prosbcdocs.telcobridges.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://prosbcdocs.telcobridges.com/telecom-references/protocols/circuit-continuity-testing.md). # Circuit continuity testing [SS7](https://telcobridges.com/media-gateways/solutions/signaling/migrating-ss7-sigtran/) signaling is out-of-band compared to the circuits (voice/data channels), therefore, at times there is a need to validate the integrity of a circuit before using it to establish connections. This is especially true for connections that go through a satellite path. There are two methods for initiating a continuity test: in a call and outside a call. During the set up, a circuit is configured with options. These options are used by the [ISUP](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/protocols/isup/README.md) layer when a remote SS7 node queries information about a circuit and does not affect the behavior of the layer. Three of these options are NONE, STATISTICAL and PER-CALL. When the NONE) option is used, the host application should not issue any continuity check on the specific circuit. There is no side effect when issuing a continuity check on such a circuit other than not respecting the local node configuration as seen by other SS7 nodes. When the (PER-CALL) option is used, the host application should issue a continuity check for every outgoing call. The (STATISTICAL) option lets the host application decide on a per-call basis if continuity testing should be done. Since the circuit options do not influence the behavior of the ISUP layer, the three ways to issue continuity checks are to 1) set the ‘fContChkForOutgoing’ field in the circuit configuration structure upon allocation, or 2) set the ‘continuity test required’ field of the ‘nature of connection indicators’ IE into an outgoing IAM message, or 3) send a CCR (continuity check request) primitive on an idle circuit. The ‘fContChkForOutgoing’ should be set to TBX\_TRUE when the circuit option CONTINUITY\_CHECK\_PERCALL is used to be consistent with the configuration. This will instruct the ISUP layer to force the proper IE configuration for every outgoing call. **NOTE:** When using configuration parameter fContChkForOutgoing’, the TB640 will enforce the ‘continuity check required’ field in the ‘nature of connection indicators’ IE for every outgoing call. To be consistent, the host application should set the circuit option to CONTINUITY\_CHECK\_PERCALL. ### Continuity testing within a call This circuit testing occurs when the forward side (originating side) sets the ‘continuity test required’ field of the ‘nature of connection indicators’ IE into the IAM message. This indicates to the backward end to activate a physical loopback (see note below) on the circuit associated with the call. Then, the forward side can proceed with the circuit testing, usually by sending a test tone and analyzing the returned data. The forward side indicates to the backward side about the result of the test by sending a COT (continuity test report), which will then remove the loopback from the circuit. In case of success, the call can proceed as usual (see call flow 6.3.4.9). If the test fails, the forward side starts a ‘continuity re-check’ sequence by sending a CCR (continuity check request) (see call flow XXXX). Because the first test fails, it is not recommended to keep the pending call opened and, therefore, the host application should consider it as closed. Upon reception of the CCR, the backward side re-activates the loopback on the circuit and waits for the test report (COT). Again, after analyzing the test data, the forward end sends a report (COT) to the backward end. In case of success, the circuit is returned to the idle state. In case of failure, it is recommended that the host applications (both forward and backward) block the circuit to prevent subsequent calls on the circuit (see call flow 6.3.4.12). **NOTE:** If the backward-end circuit is located on a TB640 blade, there is an easy way to do a trunk resource physical loopback. The application only needs to allocate a full-duplex trunk resource (which should already been done anyway if it plans to receive calls on this specific trunk) and connect it on itself with a half-duplex connection (source connected on destination) using the connection API. To achieve this, use the same hTrunkRes as the source and destination in the TB640\_MSG\_ID\_CONN\_OP\_CREATE message and set the connection type to half-duplex. No other resource is required. ### Continuity testing outside a call This circuit testing occurs when one of the nodes wants to validate a currently idle circuit. It is recommended that the switch first blocks the circuit to prevent calls to use the circuit during the testing. The testing pattern is similar as for the continuity testing within a call except that the initial testing is indicated by a ‘CCR’ sent by the testing side (instead of being embedded in an IAM primitive). Refer to call flows 6.3.4.14, 6.3.4.15 and 6.3.4.16. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://prosbcdocs.telcobridges.com/telecom-references/protocols/circuit-continuity-testing.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.