Call control

Call control tools let the agent manage the telephony call itself — ending it, transferring it, or sending DTMF tones.

For each tool, the Tool schema table describes the tool as it is exposed to the LLM. The Tool parameters table describes the optional parameters you can configure when adding the tool in the agent's Tools tab to customize the tool's behavior.

end_call

Allows the agent to end the conversation and hang up the call.

Tool schema

Parameters the tool exposes to the LLM.

Parameter	Type	Description
termination_message	string	(Optional) Message the agent says while hanging up the call. Textual models only. Speech-to-speech models (e.g. gpt-realtime) do not support this parameter — the model must say the goodbye message itself before calling the tool. Adjust your prompt accordingly when switching from a textual model or using a quickstart template.

Tool parameters

Optional parameters you can configure when adding the tool in the agent's Tools tab.

Parameter	Description
Default termination message	A fallback goodbye message for textual models, played when the LLM ends the call without a message of its own. If the LLM provides a message — via the termination_message parameter or in its accompanying reply — that message is used instead. Not applicable to speech-to-speech models, which speak the closing phrase themselves. For example: Have a good day. Good bye!

Sample prompt

Textual models — instruct the LLM to say the message while hanging up, so it is passed as the termination_message parameter and the call is disconnected immediately:

Call `end_call` to hang up, say that you are sorry while hanging up.

Speech-to-speech models — the model speaks the closing phrase itself before hanging up, so instruct it to say the phrase and then call the tool:

When the conversation is over, say "I am sorry, goodbye!" and then IMMEDIATELY call
the `end_call` tool.

transfer_call

Allows the agent to transfer the current call to another phone number or SIP destination.

Tool schema

Parameters the tool exposes to the LLM.

Parameter	Type	Description
phone	string	Destination as a full E.164 phone number (e.g. +12024561414) or a SIP URI (e.g. sip:1111@example.com). Required unless a Default number tool parameter is configured (see below), in which case the LLM does not set it.
transfer_message	string	(Optional) Message the agent says before transferring the call. Textual models only. Speech-to-speech models (e.g. gpt-realtime) do not support this parameter — the model must say the transfer message itself before calling the tool. Adjust your prompt accordingly when switching from a textual model or using a quickstart template.
queue_name	string	(Optional) Destination queue within the contact center for call routing. See Custom SIP headers for call transfer for how it is carried in the transfer (REFER) message.

Tool parameters

Optional parameters you can configure when adding the tool in the agent's Tools tab.

Parameter	Description
Default number	Fixed transfer destination, used instead of letting the LLM specify the number. May contain variables or conversation data. For example: +442079304433 or {transfer_phone}
Valid numbers	Allow-list of permitted transfer numbers, as a comma-separated string or a JSON list. This protects against LLM hallucination, where it may "invent" a random number and pass it as the phone parameter. A transfer is rejected if its number is not in the list. For example: 442079304433,+442072193000
Default transfer message	A fallback message for textual models, played when the LLM transfers the call without a message of its own. If the LLM provides a message — via the transfer_message parameter or in its accompanying reply — that message is used instead. Not applicable to speech-to-speech models, which speak the message themselves. For example: Please wait while I'm transferring you to the operator.
Wait for result	Whether the agent waits for the transfer result (voice calls only). When disabled (default), the agent leaves the conversation regardless of whether the transfer succeeds. When enabled, the agent waits for the transfer to complete and can resume the conversation if the transfer fails (for example, the destination is busy or does not answer).

Routing rule

For the transfer to actually work, you must configure a routing rule to specify the phone number / SIP connection via which the call will be sent:

1. In the Navigation pane, select Routing and then click Routing Rules.
2. Click Add new routing rule.
3. From the Type drop-down list, select Transfer.
4. From the Call origin drop-down list, select the bot connected to your Agent.
5. From the Call destination drop-down list, select phone number or SIP connection via which the call will be sent.
6. Click Create.

Sample prompt

In most cases the tool can be referenced in the prompt by its description, for example:

If the user asks for the supervisor, transfer the call to human agent at +12024561414.

To have a message played during the transfer, prompt it according to the model type:

Textual models — let the LLM pass the message as the transfer_message parameter (alternatively, configure a Default transfer message):

If the user asks for the supervisor, transfer the call to +12024561414, saying that
you are connecting them to a human agent while transferring.

Speech-to-speech models — the model speaks the message itself before transferring, so instruct it to say the phrase and then call the tool:

If the user asks for the supervisor, say that you are connecting them to a human
agent and then IMMEDIATELY call the `transfer_call` tool to transfer to
+12024561414.

Custom SIP headers for call transfer

When the transfer_call tool transfers a call, you can add custom SIP headers to the transfer (REFER) message. This is useful for passing routing information, caller context, or data extracted during the conversation to the contact center or downstream system that receives the call.

Use the transfer_call_sip_headers advanced configuration parameter to define the headers. Each header has a name and a value:

{
    "transfer_call_sip_headers": [
        {
            "name": "X-CallerNum",
            "value": "{caller}"
        }
    ]
}

Expanding header values

Header values are expanded at transfer time. You can combine free text with any of the following dynamic elements, referenced using the {...} syntax:

• Agent variables – any variable defined for the agent. See Agent variables.
• Conversation data – for example {caller}, {callee}, SIP headers received from the bot connection (sipHeadersToBot), or metadata passed on outbound call initiation. See Conversation data.
• The queue_name tool parameter – referenced as {queue_name} (see Queue name routing below).
• Parameters extracted via post-call analysis – see Using post-call analysis parameters below.

A single value may combine several elements with free text, for example:

{
    "transfer_call_sip_headers": [
        {
            "name": "X-Customer",
            "value": "{callerDisplayName} <{caller}>"
        }
    ]
}

Using post-call analysis parameters

You can populate a SIP header with a value that is extracted by post-call analysis — for example the caller's intent, sentiment, or an account number captured during the conversation.

Normally post-call analysis runs only after the conversation ends. However, when a header value references a parameter that is extracted by a post-call analysis (an analysis configured in the Extract variables mode), the framework detects this dependency and automatically runs the post-call analysis before transferring the call, so that the extracted value is available and can be expanded into the header. This extra analysis step is triggered only when at least one header actually references such a parameter; otherwise the transfer proceeds without it.

For example, if a post-call analysis extracts a department parameter, you can route the transfer accordingly:

{
    "transfer_call_sip_headers": [
        {
            "name": "X-Department",
            "value": "{department}"
        }
    ]
}

Queue name routing

The queue_name tool parameter specifies the destination queue within the contact center for call routing. How it is placed in the transfer message depends on whether you define custom SIP headers:

• If you do not define transfer_call_sip_headers, the queue_name value is automatically added as the X-Genesys-Routing SIP header.
• If you do define transfer_call_sip_headers, the automatic X-Genesys-Routing header is no longer added. In this case you are responsible for placing the queue name yourself — reference the {queue_name} variable in whichever header your contact center expects. If none of your custom headers reference {queue_name}, the queue name is not sent at all.

For example, to keep sending the queue name as the X-Genesys-Routing header while also adding other custom headers:

{
    "transfer_call_sip_headers": [
        {
            "name": "X-Genesys-Routing",
            "value": "{queue_name}"
        },
        {
            "name": "X-CallerNum",
            "value": "{caller}"
        }
    ]
}

dial_dtmf

Lets the agent navigate legacy IVR menus by sending DTMF tones.

Tool schema

Parameters the tool exposes to the LLM.

Parameter	Type	Description
tones	string	Tones to be dialed. May contain digits (0–9), asterisk (*) and hash (#); any other characters are ignored.

Sample prompt

You are calling Electric Company.

Your task is to report the power outage. The problem started 20 minutes ago
and affects all apartments in the building.

Use `dial_dtmf` tool to navigate the menu using DTMF tones.