Asterisk PJSIP_DTMF_MODE: channel override, signaling method and proof

Keep endpoint policy and one channel value separate

The endpoint dtmf_mode setting supplies policy for endpoint communication. PJSIP_ENDPOINT(name,dtmf_mode) reads that loaded endpoint field, while PJSIP_DTMF_MODE() reads or writes the current mode on one SIP call leg. They answer related but different questions.

Record the endpoint, channel name, unique ID, direction and collection time. A correct endpoint field does not prove which channel was inspected, and a channel override does not rewrite the stored endpoint configuration.

Use the documented mode vocabulary precisely

The runtime function uses the same names as the endpoint option. Current res_pjsip documentation distinguishes rfc4733, inband, none, info, auto and auto_info. RFC 4733 events are outside the main audio stream; in-band tones are part of audio; SIP INFO is a SIP request.

auto prefers RFC 4733 when the other side supports it and otherwise uses in-band. auto_info instead falls back to SIP INFO. A mode name is not evidence that the remote side accepted, received or acted on a digit.

Run the function on the leg that sends the digit

A bridged call has at least two channel owners. Read or write the function on the intended PJSIP leg, not on a caller, Local-channel half or sibling callee merely because they share a linked ID. CHANNEL(endpoint) can identify the endpoint attached to the current PJSIP channel.

For a change that must exist on an outbound callee before dialing, use a callee pre-dial handler and preserve proof that the handler ran and returned. Each parallel destination must be treated as its own leg.

Separate the configured method from protocol evidence

For RFC 4733, retain the negotiated telephone-event payload and the matching RTP event packets. For SIP INFO, retain the request, content type, digit body and response. For in-band, preserve the codec path and a bounded audio observation.

Writing PJSIP_DTMF_MODE() changes the channel mode value; the function documentation does not make that write proof of SDP renegotiation, peer support, packet delivery or downstream application handling. Stop at the first evidence boundary that diverges.

Observe digit direction, duration and consumers

Asterisk AMI exposes DTMF begin and end events with the channel, digit and Received or Sent direction; the end event also carries duration. Keep those events attached to the exact channel and time window. A digit received on one leg is not automatically proof that it was sent on another.

Then prove the consumer separately: IVR collection, feature code, bridge forwarding, ARI application or external service. A visible event can coexist with a missed, doubled, truncated or unauthorized downstream action.

Apply one bounded override and restore policy

Use a runtime override only for a demonstrated per-call requirement. Preserve the original mode, set one supported value on the intended leg, repeat the same digit sequence and compare channel events with wire evidence and the final IVR result. Verify a control call that must retain endpoint policy.

Do not globally widen endpoint behavior to mask one leg or infer provider compatibility from one successful menu. Remove temporary logging and avoid recording sensitive digits. This guide is documentation-derived; no Asterisk host, channel, digit or call was tested.

[set-callee-dtmf]
exten => apply,1,Set(ORIGINAL_DTMF_MODE=${PJSIP_DTMF_MODE()})
 same => n,Set(PJSIP_DTMF_MODE()=rfc4733)
 same => n,Return()

[outbound]
exten => 702,1,Dial(PJSIP/${EXTEN}@provider,,b(set-callee-dtmf^apply^1))
 same => n,Hangup()

Use the active call mode as one step, not menu proof

The ConfBridge menu diagnostic distinguishes a runtime DTMF mode, received digits, the effective menu and the resulting conference action.