DTMF interoperability: in-band tones, RFC 4733 and SIP INFO

Short answer: choose a DTMF method understood by both call legs and their transitions. In-band tones, RFC 4733 RTP events and SIP INFO are different representations. Hearing a tone does not prove that the application received the intended choice. Verify DTMF separately from call establishment, especially when transfer changes the path. The goal is to connect a user’s keypress to the correct menu step.

In-band DTMF requires a decision from the audio

With in-band DTMF, the tone travels within encoded audio and the receiver detects it. [1] Treat tone generation, passage through the audio path and detection as separate checks. Recheck this step when codecs or media processing change. Listening helps investigation, but pair it with the application event that identifies the actual menu choice.

RFC 4733 represents a telephone event

RFC 4733 carries telephone events in RTP payloads with an event code, duration and end information. Payload mapping is agreed through mechanisms such as SDP. [1] The receiver therefore need not identify the choice only by listening. Verify the negotiated event representation alongside the choice reaching the application. Do not equate network packet count with user keypress count; connect the event lifecycle to one logical menu input.

SIP INFO support does not settle body compatibility

SIP INFO transports application information within a session. [2] RFC 6086 describes unstandardized legacy DTMF INFO usage and introduces the Info Package framework. [3] Do not stop at “INFO is supported.” Document the expected content type, body semantics and application behavior with the remote party. The method name and body contract are different checkpoints. A delivered message does not remove the need to verify the resulting menu action.

If one leg expects RTP events and another expects INFO, define the transition explicitly. Make the mapping from incoming event to logical choice and outgoing representation visible. Conversion is not a reason to assume unsupported formats will work automatically. Document each side’s input, output and unsupported cases.

Compare methods against the same acceptance question

The table does not declare one method universally superior. Ask whether a key pressed at the intended moment makes the target menu choose the intended step. Repeat the question for each direction and transfer boundary. Success in the first menu does not establish that a later menu accepts the same representation. Include useful user guidance for unsupported cases in the test plan.

Build the test set around user behavior

Do more than test a single key. Exercise different choices, repeated presses of the same key, a rapid sequence, a long press and input while a prompt is playing. Write each expected menu result in advance. Compare generated input with the received application event, then inspect the confirmation given to the user. Missing choices and duplicate choices are different failures; record them separately so a later fix can be checked against the original behavior.

Locate the boundary where a failing test diverges: did the source generate the keypress, did the transition translate it, did the menu receive it and did the workflow perform the right action? Investigation data need not contain secret codes or real callers’ numbers. Design synthetic inputs that are sufficient to compare expected and observed outcomes.

Hypothetical example: reception menu to employee transfer

Imagine a hotel menu accepting a key to reach reception. The first test produces the correct menu input. The team then transfers the call to an employee telephone and tries a further menu choice. If the DTMF method changes at this boundary, verify the conversion separately. When a tone is audible but the choice does not change, preserve the distinction between audible audio and the event received by the menu.

For repeated input, investigate whether a selection is a genuine second press or the same event being processed again. Record the result by direction, menu and transition rather than writing only “DTMF works.” Reuse synthetic examples when adding telephone endpoints.

Interoperability checklist

• Record the method each call leg sends and accepts.
• Verify RTP event negotiation or the INFO body contract.
• Match in-band detection to the actual application choice.
• Test repeated, rapid, long and prompt-overlapping input.
• Review how retransmitted reports differ from a genuine second press.
• Repeat the same checks after transfer and reconnection.
• Use synthetic input and keep secret codes out of diagnostics.

Frequently asked questions

Are RFC 2833 and RFC 4733 the same name? RFC 4733 replaces RFC 2833. [1] Check what an old interface label means using endpoint documentation and the negotiated representation rather than relying on its wording alone.

Does a successful INFO response prove the menu choice? Observe the application result separately. Acceptance of a message and execution of the intended menu rule are different conditions.

Should every method be enabled together? Define the supported path and handling of possible duplicate inputs first. If several representations arrive, the design should specify which logical input the application accepts.