> 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/ss7-and-signalling/isup/blocking-and-unblocking.md).

# Blocking and unblocking

[ISUP](/telecom-references/ss7-and-signalling/isup.md) gives the opportunity to the local application to decide whether or not a specific circuit can receive or transmit normal call. This is achieved through the blocking/unblocking state of the circuit. An ISUP layer always remembers the state of the local circuit as well as the state of the remote ISUP peer regarding the same circuit. It is important to remember that a local stack cannot change the state of the remote stack regarding the block state of the circuit. This behavior prevents an [SS7](/telecom-references/ss7-and-signalling/ss7.md) node to re-activate a circuit that is flagged as out-of-service by the remote end which would be hazardous because it does not know the reason why it was blocked. Note that the ‘blocked’ state does not prevent test calls from being made on a circuit.

![ISUP blocking unblocking](https://docs.telcobridges.com/w/images/2/21/ISUP-blocking-unblocking.jpg)

As shown in the figure above, a specific circuit can be in four different states. They are: idle; locally blocked; remotely blocked; and 'locally and remotely blocked'. A call normally cannot be made if the circuit is not in the ‘idle’ state. There is one exception to that as the ISUP layer will interpret an outgoing call as an ‘unblocking’ request from its host application if the circuit state was ‘locally blocked’.

**Note:** A SS7 application can only change the local state of a circuit. The remote state is always controlled by the remote node.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://prosbcdocs.telcobridges.com/telecom-references/ss7-and-signalling/isup/blocking-and-unblocking.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.