Which DTMF transport should I use for door access?

RFC 4733 telephone-event is the usual default, negotiated in SDP as a=rtpmap:101 telephone-event/8000. In-band only works reliably on G.711 because G.729 distorts the tone. Pick exactly one method and match both ends.

Why does the door never hear the key press?

Most often a transport mismatch: one end sends RFC 4733 while the other expects in-band or SIP INFO. A compressed codec distorting an in-band tone is the second common cause. Check the SDP negotiation first.

Does the SIP server power the electric lock?

No. The server triggers a dry-contact relay; the lock's own supply drives the current. The SIP side only switches the circuit, keeping a software fault from becoming an electrical or life-safety problem.

How do I stop stray tones opening the door?

Gate the open command to an active call to that door, add a debounce interval, restrict which extensions may send the digit, and keep a single transport so digits are not duplicated. Log rejected opens to spot patterns.

Can I use G.729 and still send in-band DTMF?

Not reliably. G.729 and similar codecs distort in-band DTMF, so an in-band code may not be recognized. Use RFC 4733 or SIP INFO on compressed calls, or keep the access call on G.711.

ENGINEERING · ACCESS · 9 min read

DTMF Door Access Control with SIP Intercom

How a key press becomes a door open over SIP: the three DTMF transports, the relay and lock wiring, event audit, and guards against false triggers.

2026-11-06 · FlySip engineering · All guides

A SIP intercom does not open a door by magic. When a resident presses a key, or an operator dials a code, that press must travel as a recognizable signal and the controller must turn it into a clean relay closure driving the strike or magnetic lock. The signal carrying the key press is DTMF.

This covers the three ways DTMF is carried over SIP, how the relay and lock are wired safely, how to audit door-open events, and how to stop stray tones from popping locks. It is written for integrators who already have a SIP server and want the access part reliable, not theoretical.

The Three DTMF Transports and Why They Diverge

DTMF - digits 0-9, * (code 10), # (code 11), A-D (12-15) - is carried over SIP three ways. In-band puts the tone in the voice stream. RFC 4733 (which obsoleted RFC 2833 in 2006) sends the digit as an RTP event negotiated in SDP, typically 'a=rtpmap:101 telephone-event/8000', with a 4-byte payload of event, volume, and 16-bit duration. SIP INFO carries the key press in the signalling plane.

The most common access failure is a mismatch: one end sends RFC 4733, the other expects in-band, so the door 'never hears the key.' A compressed codec such as G.729 distorts in-band tones while G.711 carries them faithfully, so in-band is only safe on G.711. Enabling several methods at once doubles digits - pick exactly one and match both ends.

In-band: reliable only on G.711; distorted by G.729 and similar codecs.
RFC 4733: out-of-band RTP event, negotiated in SDP; the recommended default.
SIP INFO: signalling-plane reports; useful when media is heavily compressed.
Mismatch: the classic cause of a door that does not hear the key; use one method end to end.

Relay, Strike, and the Electric Lock

The validated DTMF digit (a configured open code, or '#' during a door call) triggers a relay. That relay is a dry contact: it closes a circuit the lock's own supply drives. The SIP server and relay never carry the lock's current; they only switch it. This separation keeps a firmware bug from becoming a code problem.

Wire the lock so a power loss fails safe for the application - a fail-secured strike only where the code allows, an egress door uses a fail-safe lock releasing on loss of power. The SIP system should not decide life-safety behavior; that belongs to the door hardware and local code.

Safety note: the relay is a dry contact switching the lock's own supply. Fail-safe versus fail-secured is a hardware and code decision, not a SIP setting.

Auditing Door-Open Events

Every open should leave a record: which extension called, which door, the time, and whether the open was by DTMF, a scheduled rule, or an operator. On a SIP system this lives in the CDR and the access log, and the two should agree. An open with no matching CDR means the relay fired outside the expected path - worth investigating.

For accountable sites, export on a schedule and retain per the site's own policy. The server produces the events; how long to keep them is a site or contractual requirement, not a guess. Match the export to the audit cadence the building already uses.

Guards Against False Triggers

A relay that fires on the wrong tone is worse than one that never fires. Require the open code only during an active call to that door, add a debounce window so a glitch cannot chatter the relay, and restrict which extensions may send the open command at all.

Also watch for dual-tone duplication from multiple DTMF methods - if the controller counts two digits per press it may reject the code or act on a partial match. Keep the transport single and the code length fixed, and log rejected opens to see a pattern before a real failure.

Active-call gate: accept the open command only during a live call to the door.
Debounce: a minimum interval prevents relay chatter from one glitch.
Source allow-list: only certain extensions may send the open digit.
Single transport: avoids duplicate digits that reject or mis-trigger the code.

Verification Order

Test in a fixed order: confirm the DTMF transport matches from an SDP trace, place a call and capture the event at the controller, then verify the dry contact closes and the lock moves. Only after the electromechanical path is proven do you test the log and the guards. Skipping to 'does it open' before the transport matches hides the defect.

If the door never opens, the SDP line for telephone-event is the first place to look, then the codec on the call (G.711 for in-band), then the relay wiring. Most field failures are a transport mismatch or a compressed codec, not the lock.

Frequently asked questions

Which DTMF transport should I use for door access?: RFC 4733 telephone-event is the usual default, negotiated in SDP as a=rtpmap:101 telephone-event/8000. In-band only works reliably on G.711 because G.729 distorts the tone. Pick exactly one method and match both ends.
Why does the door never hear the key press?: Most often a transport mismatch: one end sends RFC 4733 while the other expects in-band or SIP INFO. A compressed codec distorting an in-band tone is the second common cause. Check the SDP negotiation first.
Does the SIP server power the electric lock?: No. The server triggers a dry-contact relay; the lock's own supply drives the current. The SIP side only switches the circuit, keeping a software fault from becoming an electrical or life-safety problem.
How do I stop stray tones opening the door?: Gate the open command to an active call to that door, add a debounce interval, restrict which extensions may send the digit, and keep a single transport so digits are not duplicated. Log rejected opens to spot patterns.
Where are door-open events recorded?: In the SIP CDR and the access log, which should agree. An open with no matching CDR means the relay fired outside the expected path and deserves investigation. Retention is set by the site's own policy.
Can I use G.729 and still send in-band DTMF?: Not reliably. G.729 and similar codecs distort in-band DTMF, so an in-band code may not be recognized. Use RFC 4733 or SIP INFO on compressed calls, or keep the access call on G.711.

Combine access with ring groups and call routing so door calls reach the right desk, and log everything with the CDR and audit guide. Start from the FlySip product overview.