The caller has already keyed in an account number, picked Spanish and said "billing". The call reaches the voice agent, and the first thing it says is: "Can I take your account number?"
That repeat is rarely a prompt problem. It is a telephony decision nobody made: which data leaves the IVR or contact-centre platform with the call, how it travels, and how much the agent may trust it. This guide is for the telephony or contact-centre lead making that decision. It is vendor-neutral: what your platform can send, and what a given voice agent can receive, is confirmed for your stack.
What callers have already told your IVR
Start with an inventory, not a design. Export the IVR flow and list every variable that is set before the transfer node. Most fall into three origins, and the origin matters later because each one deserves a different level of trust.
| Origin | Typical fields (fictional examples) | Who supplied it |
|---|---|---|
| The network | Calling number, the number dialled, time of call | The phone network and your carrier |
| The caller | Account number keyed on the keypad, menu choice, spoken reason, language choice | The person on the line, unverified |
| Your systems | Customer record found by lookup, open ticket, queue, wait time, result of any check the IVR ran | Your IVR, CRM or CCaaS logic |
For each field, write down three things: its exact name in the IVR, an example value, and whether the agent needs it to avoid a question. Some fields matter only for reporting and do not need to travel at all. Passing fewer fields is easier to secure and easier to test.
Check every branch, not just the main menu. An after-hours branch or an overflow route may skip the node that sets the language or the reason, so the same field can be present on one path and empty on another. Ask whoever maintains the IVR flow for an export of the variables per branch, rather than a description from memory.
Mark the fields that must never travel. If callers type a PIN or answer a security question in the IVR, the agent does not need the secret itself. At most it needs to know that a check took place, and the trust-levels section below explains why even that needs care.
Three ways data travels with a call: SIP headers/UUI, lookup by call ID, re-capture
Once you know what exists, pick a carrying method per field. There are three.
1. In the SIP signalling. The call transfer itself can carry data. The standard option is the User-to-User header defined in RFC 7433. It carries a small piece of data that SIP treats as opaque, with an "encoding" parameter (the standard defines hex) and a "purpose" parameter that tells the receiver how to read it. Platforms also use their own named headers. Two limits come from the standards themselves. RFC 7433 allows proxies and other intermediaries to remove the header based on policy. And under RFC 3261 §8.2.2, a receiver that does not understand a header must ignore it and carry on. So a field can be lost in two ways: a hop can remove it, or a receiver that does not support it can ignore it, and neither produces an error. Ask the owner of each hop, from your platform through any session border controller, whether it passes the header unchanged. Then confirm that the agent side supports and reads that header, and test both. If you define new header names, RFC 6648 advises against the old "X-" prefix convention.
2. A lookup key. The IVR writes its data to a store your systems control, such as the CCaaS call record, a CRM entry or a context service. Only a short key, such as a call or interaction ID, travels with the call. When the call arrives, the agent's integration fetches the data by that key. This keeps longer or sensitive values out of the signalling and leaves an audit trail. The risks move elsewhere: the record may not be written yet when the call lands, the key may not be unique across transfers, and a slow lookup delays the greeting. Write the record before the transfer starts, and decide how long the agent waits for it before falling back to re-capture.
3. Re-capture. Ask again, but only for what is missing or untrusted, and say why. "I didn't receive your account number from the menu. Could you give it to me again?" respects the caller more than a scripted fresh start.
| Field type | Suggested method | Why |
|---|---|---|
| Language choice, menu choice | SIP header | Short, low risk, needed in the first second |
| Account number keyed by the caller | Lookup key | Keeps the value out of signalling that many hops can read |
| Customer record, open ticket | Lookup key | Too large for a header; changes between calls |
| Anything not received or failing a check | Re-capture | The caller is the fallback source |
Trust levels: what the agent may rely on and what it must re-verify
Arriving data saves questions. It does not settle who the caller is. Give every field one of three trust levels, and make the agent's permissions follow the level, not the field name.
| Trust level | Examples | The agent may | The agent must not |
|---|---|---|---|
| Network-asserted | Calling number | Use it as a routing hint or to find a candidate record | Treat it as identity. Caller ID can be falsified (FCC) |
| Caller-asserted | Keyed account number, chosen reason, language | Skip asking for it again, and confirm it in neutral words | Treat it as verified or read back details linked to it |
| System result | A record your system found, an open ticket | Use it to frame the conversation | Disclose account details before your verification rules are met |
The difference between the first two levels matters in practice. A calling number tells you which line the call came from, and that line may be shared or faked. A keyed account number tells you what the caller typed, and they may have typed someone else's number by mistake, or on purpose. Neither tells the agent who it is talking to.
System results have a shelf life. A record found for this call is good for this call. Do not carry a verification state or a disclosure decision over from an earlier call, even if the number is the same.
When the agent uses caller-asserted data, it should acknowledge it without echoing it: "I have the account number you entered. What can I help you with on that account?" Reading the full number back adds nothing and tells anyone listening what it is.
The rule for this guide: inherited identity data never counts as verification. It lets the agent skip a question, never a check. If your IVR already verifies callers, whether that result can carry over is a decision for your security owner. Make it within your caller authentication model, and do not assume it in the integration.
When the data is missing or wrong
Design the first turn so that it works with no inherited data at all. Missing data is a normal state, not an exception.
- Nothing arrives. A header was stripped or the lookup returned nothing. The agent asks once, plainly, with no error message and no silence.
- The value is malformed. Wrong length, impossible format, failed check digit. Treat it as missing. Never read a garbled value back to the caller.
- The record is stale. The lookup returns the previous call's context because the key was reused. Check that the record's timestamp matches this call before using it.
- The caller contradicts the data. "I'm calling about my other account." The caller wins for reasons and language; the data was only a starting point.
- The language does not match. The caller chose Spanish but answers in English. Follow the caller.
Log every mismatch with the call ID and the field name, and give the log an owner who reviews it. A pattern of missing fields can point to one hop that strips headers or one IVR branch that never sets the variable.
Transfer-in acceptance tests
Run each test on every path into the agent, not only the main menu branch: after hours, overflow and transfers from people. Capture what was sent and what was received at each hop, and compare them field by field.
- Full data. All fields arrive; the agent asks for none of them again.
- Missing data. Strip the header or empty the lookup record; the agent asks once, with no error or dead air.
- Garbled data. Send a malformed account number; the agent treats it as missing and never reads it out.
- Contradiction. The caller states a different reason or language; the agent follows the caller and the mismatch is logged.
- No inherited verification. Inherited data is present and the caller asks for an account change; the agent still runs your verification step first.
For evidence, take a SIP trace where the call leaves your platform and where it reaches the agent, and keep the agent's own log of the fields it received and used. Put the three side by side for each test: sent, received, used. A field that is sent but not received points to a hop; a field that is received but not used points to the agent's configuration.
Re-run the set after any change to the IVR flow, the session border controller or the agent's prompt. A small edit to the IVR can stop a variable being set without anyone noticing until callers start repeating themselves.
Where NextLevel fits
NextLevel's SIP Bridge page lists "caller ID and intent hints" and "detected language" among the data passed to the agent. Which of your own IVR fields can travel, and by which method, is confirmed with NextLevel's technical team for your platform.
Next step: bring your IVR field list to a scoping call, booked from the pricing page. The inventory from the first section is enough to start.
Frequently asked questions
What is UUI in SIP?
User-to-User Information: a small block of call-control data that one application puts into the SIP signalling for the application that answers the call. RFC 7433 defines the header that carries it.
Can we put the account number in a SIP header?
You can, but signalling may be readable by every system on the path unless it is protected end to end, which RFC 7433 notes is rarely deployed. Passing a lookup key keeps the number in a system you control.
Does the voice agent still need to verify the caller?
Yes, before any account action. Inherited data removes questions, not checks.
What if our platform cannot send custom headers?
Use a lookup key or re-capture. Re-capture done well, asking only for what is missing, still beats a full restart.
Sources
- RFC 7433, A Mechanism for Transporting User-to-User Call Control Information in SIP (IETF, January 2015), read 9 Nov 2026: §3 (intermediaries may remove the header; integrity protection generally not deployed), §4 (purpose and encoding parameters), §7.
- RFC 3261, SIP, §8.2.2 Header Inspection, read 9 Nov 2026.
- RFC 6648, Deprecating the "X-" Prefix (BCP 178), read 9 Nov 2026.
- FCC: Caller ID Spoofing, consumer guide (last reviewed 13 Nov 2024), read 9 Nov 2026.
- NextLevel SIP Bridge, "AI side" block, read 9 Nov 2026.