Forward calls to a SIP address or PBX: when and how

Choose SIP when you already run a PBX or softphones and have stable internet; stick with phone-number (PSTN) forwarding when agents work on mobiles or your internet is shaky. To set it up cleanly, make SIP your first route with a 20–25 second ring timer, then fail over to one or two PSTN numbers on no-answer or error. That way you get low-latency audio and full IVR control on good days, and real phones still ring when SIP is down. We’ll use a 20-seat support team as the running example: the main number hits their PBX first, then falls back to two on-call mobiles.

Who should forward calls to SIP address vs phone numbers

If your team answers on a PBX (the system that handles your IVR and agent phones) or softphones (apps that take calls over the internet), forward calls to SIP. You’ll avoid an extra PSTN leg, reduce latency, and keep DTMF (touch tones for menus) under your control. If your people answer on mobiles, travel often, or you face power and internet drops, forward to phone numbers first. SIP can still be there as a backup path for office hours, but don’t make it the only route.

In our 20-seat team example, the best pattern is: inbound number to the PBX by SIP, ring 20–25 seconds, then fail over to two mobiles in priority order. This avoids a mobile voicemail picking up too soon, and it keeps callers on the PBX IVR when the office is online.

Here’s a side-by-side view of the three common options:

Trade-offs in plain terms:

• Quality and latency: SIP trims an extra PSTN leg, which often cuts delay by a few tenths of a second. Not huge, but you feel it on talk-over. PSTN is fine if your agents are already on mobiles.
• Control of features: SIP lets your PBX see the original caller ID and tones, so your IVR and call queues work as intended. With PSTN forwarding to a mobile, the mobile’s voicemail or DND can capture calls before your IVR times out.
• Failure modes: SIP fails with internet, DNS, NAT, or firewall issues. PSTN fails with poor radio coverage or a mobile voicemail answering fast.
• Operational effort: SIP takes some setup and watching registration health. PSTN is set-and-forget but gives you less control.

How to forward calls to a SIP address or PBX (clean setup)

Do this once and you won’t chase ghosts later:

• Provision your inbound business number.
• Add a SIP target:
  • For SIP URI forwarding, enter sip:username@domain (or a PBX hostname with SRV).
  • For SIP registration, create SIP credentials, then register from your PBX or softphone.
• Set the SIP ring timer to 20–25 seconds. This gives your PBX time to ring agents, but not long enough for dead air if the path is broken.
• Add PSTN failover targets in order (on-call Mobile 1, then Mobile 2). Use priority routing rather than simultaneous ring.
• End with voicemail on your platform or your PBX, but not both.
• Test inbound calls from a few networks and carriers.

Why 20–25 seconds? Most mobiles send a call to voicemail after about 20–30 seconds. If your SIP leg rings longer than that, a mobile voicemail in the failover chain can seize the call while your PBX is still ringing. Keep the SIP leg under that window, then fail over. Also, if your PBX runs its own IVR, make your PSTN fallback a number that answers fast (a person or a queue), not another IVR that adds more timeouts on top.

Caller ID and DTMF: With SIP delivery, the PBX should see the original caller’s number and the tones for IVR input. If you forward to mobiles as a backup, confirm your provider passes the original caller ID (most do) so call-back works. When your PBX expects RFC2833/101 (out-of-band tones), set the trunk to that; in-band tones can get lost with low-bitrate audio.

Short aside: CallFlow lets you add a SIP endpoint or register a SIP softphone as your first route, set per-target ring timers, then add priority fallbacks to phone numbers. You can watch live logs while you test and cap how many calls hit a fallback in a day.

SIP URI vs SIP registration: which should you use

A SIP URI is an address like sip:support@pbx.example.com. Your platform sends the call to that hostname, using DNS records (including SRV) to find the right server. This works well when your PBX has a stable public DNS name and you control firewalls.

SIP registration is when your PBX or softphone signs in to the platform with a username and password, and keeps that binding alive. The platform then delivers inbound calls to the last seen contact, which hides NAT and dynamic IP changes.

Pick SIP URI when:

• Your PBX has a static public IP or a reliable DNS record.
• You can open firewall ports and manage ACLs.
• You want multi-site redundancy using DNS SRV.

Pick SIP registration when:

• Your PBX or softphones sit behind NAT (a private LAN).
• Your WAN IP changes, or the ISP modem reboots at random times.
• You want the system to recover fast after an IP or route change.

Operational notes that save you pain:

• Registration expiry and keepalives (tiny periodic messages that keep the path open) help the system recover after a NAT reset. Set expiry between 60 and 300 seconds for branch sites. Very long timers hide failures.
• After a WAN failover, the old NAT mapping breaks. Re-register on the new path and the trunk is back without DNS edits.
• Most modern PBXs support both models. Look under “SIP trunk” or “inbound route” for URI, and under “SIP account/extension” or “registration/peer” for the credentialed method. If you’re new to this, a quick lab run like the one in Test a SIP trunk end-to-end helps shake out the basics.

NAT and audio: fixes for one-way audio and missed rings

NAT (the router that maps many private LAN devices to one public IP) breaks SIP in two ways. First, the SIP signaling (the call setup messages) may get through, but the RTP (the voice stream) gets sent to a private IP that the other side can’t reach, which causes one-way or no audio. Second, the NAT mapping can expire. When that happens, the platform’s inbound INVITE never reaches your PBX or softphone and you miss the ring.

Practical fixes:

• Turn off SIP ALG (a router feature that tries to help but often mangles SIP). Most business-grade routers let you disable it.
• Use STUN/ICE (tools that discover your public IP and open media paths) if your softphones support them. Many desktop and mobile clients do.
• Prefer SIP registration over raw IP/URI when you sit behind NAT. Registration keeps the pinhole open.
• Send periodic keepalives (OPTIONS, CRLF, or re-register) every 60–120 seconds to refresh mappings.
• Transport choices: start with UDP (simple, low overhead). If the network drops or rate-limits UDP, try TCP. TLS adds encryption if both ends support it and your CPU and latency budget can handle it.

Timeouts matter. A short early-media timeout (how long you wait for ringback or audio before failing over) and a 20–25 second ring per leg keep callers from waiting too long when a path is dead. If a branch office loses power, you want the platform to give up on that SIP leg fast and move to the mobile fallback. For agent devices and settings, see SIP softphone registration: settings that keep calls flowing.

Failover to PSTN targets when SIP is down

Keep at least one mobile or landline as a backup target. It’s your safety net during ISP and power issues. Order routes with priority: SIP first, then Mobile 1, then Mobile 2. Avoid simultaneous ring that includes mobiles, because a mobile voicemail can answer before your PBX or queue does.

If cost control matters, set daily or concurrent caps on the PSTN fallback targets. When a cap hits, send overflow to voicemail or a small queue with hold music. This stops a runaway day from hitting every on-call mobile while you fix the WAN.

Cross-border teams work fine with this pattern. If your main number is in the US and your agents sit in India or the Philippines, SIP to the PBX keeps it on net when the office is up. The PSTN backup can be a local mobile in the agent’s country. When that fallback triggers, expect an international leg — that’s normal. If you’d like more on route order and overflow patterns, see Failover call forwarding that actually fails over.

Testing and monitoring: prove it works and stays up

An acceptance test takes minutes and saves days later:

• Call your business number. Confirm the SIP leg reaches your PBX or softphone, and that you see the original caller ID.
• If you have a PBX IVR, press DTMF keys to navigate. Make sure the PBX hears them.
• Hang up and repeat from a different network (cellular vs Wi-Fi) to cover codec and DTMF paths.
• Pull the PBX’s WAN or block the trunk on your firewall. Call again. The route should fail over to Mobile 1 within 20–25 seconds, then to Mobile 2 if no answer.

Use live call logs and SIP responses to see where a failure sits. Codes like 486 (busy here) mean the PBX got the call and declined it. 408 (timeout) points to no SIP response — often a NAT or firewall block. 503 (service unavailable) suggests the far end or route is down; the platform should try the next target. A quick pass through Call logs and CDRs: how to debug a failing call shows what to look for.

Set a simple test regime. A weekly scheduled call that drives one menu option and confirms audio for 10 seconds is enough. Have a report emailed to you or your NOC. Watch for unusual spikes in very short calls, which can point to DTMF failures or audio one-way. If you use registration, alerts for registration drops or long gaps between successful calls help catch issues before a busy hour.

What to do next

If you want this pattern without a long contract, CallFlow supports forwarding to SIP endpoints, SIP softphone registration, and priority failover to phone numbers from a prepaid wallet. Start a test number, build SIP first with PSTN backup, and run the acceptance test above. You can sign up at /register, or reach our team at /contact if you’d like help with URI vs registration or NAT settings.