> For the complete documentation index, see [llms.txt](https://tmediadocs.telcobridges.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://tmediadocs.telcobridges.com/telecom-references/developer-reference/routing-scripts/call-transfer-requests.md).

# Call Transfer Requests

[Hide TOC](/telecom-references/developer-reference/routing-scripts/call-transfer-requests.md)

### Introduction

Toolpack allows that [Call transfer](/telecom-references/ss7-and-signalling/isdn/call-transfer.md) requests are relayed from one leg to the other, or to process them locally (making another outgoing call to replace the call that requested the call transfer).

If the chosen [Call transfer](/telecom-references/ss7-and-signalling/isdn/call-transfer.md) mode is to process requests locally, upon reception of a call transfer request (SIP REFER or ISDN Facility), routing script will be called once again, to select the routes for the new outgoing call (call transfer target).

### How to route call transfer request

Routing of a call transfer request is done exactly like routing of a normal incoming call. The routing script generally does not need any modification to support that.

In some cases, the routing script may want to use information related to the transfer request to perform routing, or to insert information in the outgoing call leg. Additional information is provided to the routing script, allowing routing decisions using information from the call transfer request (SIP REFER or ISDN Facility). See below\...

### params\[ :call ] content during transfer request

When processing a call transfer request, the params\[ :call ] hash contains the information from the inbound call (same as was passed to the routing script upon arrival of the inbound call) call = params\[ :call ] -> Information from original inbound call, with exception of call\[ :called ]

One exception (convenient because it allows a unmodified routing script to process call transfer request the same way as any other routing request): call\[ :called ] -> Replaced by the called number from the call transfer request (also called "redirection number") Complementary information: call\[ :original\_called\_number ] -> Contains the called number that was initially received from the incoming call, prior to call transfer request call\[ :redirecting\_number ] -> Number of the call from which the call transfer request was received (generally equals to original\_called\_number)

These fields will also be included in the outgoing call made after routing:

* original called number and redirecting number are existing fields on SS7 and ISDN calls
* SIP "diversion" header is used for SIP calls

### params\[ :transfer ] content

(this if valid only for release 2.7.102 and above)

When processing a call transfer request, information from the call transfer request message (SIP REFER, ISDN Facility) is provided in params\[ :transfer ]: transfer = params\[ :transfer ] The following field is always present: transfer\[ :original\_nap ] -> Contains the NAP of the first call from which a call transfer request was received transfer\[ :redirecting\_nap ] -> Contains the NAP of the call from which the current call transfer request was received (same as :original\_nap for the first call transfer, different for subsequent transfers) Examples of other fields that may be present, when appropriate: transfer\[ :uui ] -> The UUI (user-to-user information) found in the call transfer request transfer\[ :sip\_header ] -> Contains custom SIP headers from the call transfer request transfer\[ :request\_uri ] -> Contains the SIP Request URI

These fields are 'read-only'. They will not be included in the outgoing call, as they represent the contents of the call transfer request, and not the outgoing call to be made.

To insert/modify attributes of the outgoing call, the parameters from params\[ :call ] must be edited instead.

![BackToMain](https://docs.telcobridges.com/w/images/1/1e/BackToMain.png)


---

# 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://tmediadocs.telcobridges.com/telecom-references/developer-reference/routing-scripts/call-transfer-requests.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.