DTMF Issues
Troubleshoot DTMF sending and receiving problems including RFC 4733 RTP negotiation failures, SIP INFO issues, and inter-digit timing problems.
This page covers common issues with DTMF digit sending and receiving during test execution. DTMF is used for IVR navigation, automated menu testing, and tone transmission validation.
RFC 4733 RTP Issues
Digits Not Received by Remote
Symptom: DTMF digits are sent (confirmed by dtmf_digits_sent metric) but the remote system does not detect them.
Likely causes:
-
telephone-event not negotiated — The remote endpoint did not include
telephone-eventin its SDP answer. Without negotiation, RFC 4733 DTMF packets are dropped by the receiver.Resolution: Check the SDP answer for
a=rtpmap:101 telephone-event/8000. If missing, the remote does not support RFC 4733. Switch to SIP INFO method instead. -
Payload type mismatch — The remote answered with a different payload type for telephone-event than what was offered.
Resolution: Inspect the SDP offer and answer. CallMeter adapts to the answerer's payload type automatically, but some endpoints may fail if the types do not match exactly.
-
Duration too short — The digit duration is set below the remote's detection threshold. Some IVR systems require a minimum of 80-100ms to reliably detect a digit.
Resolution: Increase the DTMF duration to at least 100ms in the scenario action configuration.
Digits Sent But Not Logged
Symptom: The scenario action shows "Send DTMF" executed, but dtmf_digits_sent metric is zero.
Likely cause: The DTMF send was attempted during a call hold state. DTMF is blocked when the call is held (local or remote hold).
Resolution: Ensure the call is in the Active state when the SEND_DTMF action is triggered. If using event-triggered DTMF, verify the trigger fires after a Resume action, not during hold.
SIP INFO Issues
489 Bad Event Response
Symptom: SIP INFO requests are sent but the remote responds with 489 Bad Event.
Cause: The remote endpoint does not support application/dtmf-relay as a SIP INFO content type.
Resolution: Switch to RFC 4733 RTP method. SIP INFO for DTMF is not universally supported and some endpoints reject it outright.
SBC Stripping INFO Requests
Symptom: SIP INFO requests leave the endpoint but never reach the remote system. No response is received (timeout).
Cause: An intermediary SBC or proxy is filtering out SIP INFO requests. Some SBCs are configured to block non-essential SIP methods.
Resolution:
- Check the SBC configuration for INFO method filtering
- Switch to RFC 4733 RTP method, which sends DTMF in-band via RTP and is not affected by SIP-level filtering
- If both methods must work, use the Both DTMF method to send via RTP and SIP INFO simultaneously
Wrong Content-Type
Symptom: SIP INFO reaches the remote but digits are not detected.
Cause: The remote expects a different SIP INFO body format. CallMeter uses application/dtmf-relay with Signal=X\r\nDuration=Y format, which is the most common. Some systems expect application/dtmf or other formats.
Resolution: Verify the remote system's expected SIP INFO format. If it uses a non-standard format, switch to RFC 4733 RTP method.
Inter-Digit Timing Issues
Digits Merged (Detected as One Long Tone)
Symptom: A sequence like "123" is detected as a single digit or fewer digits than sent.
Cause: The inter-digit gap is too short. The remote's DTMF detector cannot distinguish between consecutive digits when they arrive too close together.
Resolution: Increase the inter-digit timing in the SEND_DTMF scenario action. A minimum of 50ms gap between digits is recommended. For IVR systems, 100-200ms provides more reliable detection.
Extra Digits Detected
Symptom: The remote reports more DTMF digits than were sent.
Cause: The digit duration is too long, causing the remote's detector to trigger multiple detections for a single digit. This is more common with SIP INFO where the Duration value may be interpreted differently.
Resolution: Reduce the digit duration. Standard DTMF duration is 80-100ms. Durations above 300ms may cause double-detection on some systems.
DTMF During Hold
DTMF sending is intentionally blocked when the call is in any hold state:
| Hold State | DTMF Allowed |
|---|---|
| Active | Yes |
| Local hold (sendonly) | No |
| Local hold (inactive) | No |
| Remote hold | No |
If a SEND_DTMF scenario action triggers while the call is held, the action is skipped and logged as blocked. Resume the call before sending DTMF digits.
DTMF method recommendation
RFC 4733 RTP is the most reliable DTMF method and should be the default choice. SIP INFO is a fallback for systems that do not support RFC 4733. The Both method provides maximum compatibility but doubles the signaling for each digit.
Diagnostic Checklist
| Check | How |
|---|---|
| Is telephone-event negotiated? | SDP answer contains a=rtpmap:NNN telephone-event/8000 |
| Is the call active (not held)? | Scenario action timing occurs after resume, before next hold |
| Is duration sufficient? | At least 80ms per digit, 50ms inter-digit gap |
| Is SIP INFO supported? | Remote allows application/dtmf-relay content type |
| Are digits reaching the remote? | Check dtmf_digits_sent and dtmf_digits_received metrics |
Related Pages
- Scenario Actions — Configure DTMF send and receive actions
- Metrics Glossary — DTMF-related metric definitions
- Common Test Failures — General test troubleshooting
Media Encryption Issues
Troubleshoot TLS handshake failures, SDES negotiation errors, DTLS-SRTP handshake timeouts, and SRTP authentication problems.
Frequently Asked Questions
Answers to the most common questions about CallMeter, including platform capabilities, testing features, billing, workers, metrics, integrations, and security.