Extensions are the identity of every agent/device in your PBX. A desk phone, softphone, SIP intercom, call-center agent, or a browser-based WebRTC client — all connect to FreePBX as an extension (PJSIP endpoint).

In modern FreePBX (Asterisk 18/20+), PJSIP is the standard. Your call flow always ends up routing to an extension (directly or via queue/ring group).

• Inbound: Trunk → Inbound Route → IVR/Queue/Ring Group → Extension
• Outbound: Extension → Outbound Route → Trunk → Carrier

Minimum rule before anything else: create/register at least two extensions and confirm internal calls have two-way audio. If this is not stable, IVR/Queues/Trunks troubleshooting becomes confusing.

SIP Extension vs WebRTC Extension (Concept)

Most extensions are used by SIP phones/softphones (UDP/TCP/TLS). A WebRTC client is also an extension, but it typically requires extra media features:

• WebRTC media: DTLS-SRTP (encrypted RTP) instead of plain RTP
• ICE enabled (for NAT traversal)
• AVPF enabled (WebRTC-friendly RTP feedback)
• RTP/RTCP multiplex (rtcp-mux) commonly enabled
• Transport: usually TLS + WSS (depends on your WebRTC module/UCP setup)

You may not see “WebRTC” as a single toggle in every FreePBX screen, but if you scroll down in the extension settings (Advanced/Media area), you will see options like ICE, AVPF, and rtcp-mux — these are key for browser calling.

Open Extensions Module

Go to: Applications → Extensions

Create your extension numbering plan early (example: 200–299 Sales, 300–399 Support, 10000+ for special devices/bots), so you never end up with random numbers later.

Screenshot 1 — General Tab (Identity + Secret)

This is the core “who is this extension?” screen. In the example below, extension 201 is being edited. You’ll set the user identity and the SIP password (“Secret”).

What matters most here

• Display Name: human-friendly label shown on internal calls
• Outbound CID: what this extension presents as caller ID internally/outbound (depending on routes)
• Secret: SIP password for the phone/softphone/WebRTC client
• Language Code: keep default unless you are intentionally using language prompts per user

Security rule: never use weak secrets (1234 / extension number / company name). Use a strong secret (16+ chars) to avoid PBX compromise.

Screenshot 2 — Voicemail Tab (Missed Calls)

Voicemail is optional, but most real deployments need it for missed calls and after-hours fallbacks. This is the voicemail configuration screen for extension 10001.

Practical voicemail defaults

• Enabled: Yes (if you want voicemail)
• Voicemail Password: strong PIN (not 0000/1234)
• Email: only if you have SMTP configured and want voicemail-to-email
• Email Attachment: policy decision (privacy vs convenience)

Screenshot 3 — Find Me / Follow Me (Call Ring Strategy)

This section controls how calls ring for the extension. In many call-center setups, you keep it simple: ring the device for a set time and then failover to voicemail/queue logic.

What to set intentionally

• Initial Ring Time / Ring Time: how long the extension rings before failover
• Ring Strategy: how it rings if you add multiple targets
• Announcement / Music On Hold: usually “None/Default” unless you have a specific experience

Tip: Don’t build complex “Follow Me” chains unless you really need them. For support teams, a Queue or Ring Group is often cleaner than heavy Follow Me rules.

Screenshot 4 — Advanced Tab (DTMF, Transport, WebRTC-related Options)

The Advanced area contains settings that affect stability and compatibility: DTMF behavior, identity headers, transport, and (for WebRTC) ICE/AVPF/rtcp-mux.

Recommended guidance for common setups

DTMF Signaling

• For most deployments, keep RFC4733 / RFC2833 (DTMF over RTP events)
• If IVR digit detection fails, re-check DTMF mode on both extension and trunk/provider

Transport

• Auto is fine for many SIP phones
• If you are doing TLS/WebRTC, you may need an intentional transport plan (TLS + certificates)

WebRTC-related toggles (when using browser calling)

• Enable ICE Support: typically Yes for WebRTC
• Enable AVPF: typically Yes for WebRTC
• Enable RTCP Mux: typically Yes for WebRTC

If you are not using WebRTC, keep these at defaults unless you have a specific reason to change them.

Screenshot 5 — Pinless Dialing

Pinless dialing is an optional feature. Leave it disabled unless your business flow requires it.

In many production systems, you keep this Disabled for safety and predictability.

Screenshot 6 — Endpoint, Routing, and Paging/Intercom

This section shows device provisioning/endpoint-related fields and additional routing options. Depending on your deployment, you might not use device templates here (especially if you provision phones separately), but it’s important to understand where the PBX expects “endpoint device” information.

What to watch

• Extension Routes is not registered: usually means no active registered device/contact yet
• Paging/Intercom: keep default unless you intentionally use paging features

Minimum Testing Checklist (Do This Before IVR/Queues)

1. Create two extensions (example: 201 and 202) with strong secrets
2. Register both on two devices/softphones
3. Call 201 → 202 and confirm:
   • two-way audio
   • hold/resume works
   • DTMF works (press digits / IVR test)
4. If using WebRTC: verify ICE/AVPF/rtcp-mux behavior and confirm audio + DTMF from browser

Once extensions are stable, move to: Trunks → Inbound Routes → IVR → Queues.

Security Best Practices (Do This Always)

• Use strong SIP secrets for every extension
• Restrict SIP/RTP access using Firewall and Trusted networks
• Enable intrusion detection/fail2ban
• Prefer VPN for remote agents instead of open SIP to the internet
• Disable unused extensions

Most PBX compromises happen because SIP is open to the world and extension passwords are weak.