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

# Blocking and unblocking

[ISUP](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/protocols/isup/README.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](https://telcobridges.com/media-gateways/solutions/signaling/migrating-ss7-sigtran/) 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 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/blocking-and-unblocking.md?ask=<question>&goal=<endgoal>
```

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