Spectrum Outbound Calls Failing / Wrong Dial String? The REAL Fix (CallerID Format Issue)

FreePBX Providers
1

Hey all,

Posting this because I just spent way too long chasing a problem that looked like a FreePBX/PJSIP dialplan bug, but the root cause ended up being Spectrum’s extremely strict CallerID formatting requirements. This will save other admins a lot of pain.

I’ve handled quite a large number of PBX’s, and Spectrum SIP trunks, but I’ve only encountered this issue on my newest deployments using PJSIP for the Spectrum Trunk, so this may be PJSIP specific. And yes, Copilot wrote my summary here (which I’ve reviewed).

Symptoms

When placing outbound calls through a Spectrum PJSIP trunk, you may see:

  • Calls failing immediately

  • Calls being sent out with the wrong dial string, such as:

    PJSIP/<number>@Spectrum

    …instead of the expected:

    PJSIP/Spectrum/<number>

  • FreePBX appears to append a suffix like @Spectrum to the dial

  • You might find an unexpected line like:

    Set(TDIAL_SUFFIX=@spectrum)

  • Nothing in the GUI seems wrong

  • PJSIP endpoint settings look clean

  • No dial patterns contain “@spectrum”

  • No custom dialplan overrides

  • No Advanced Settings causing it

It’s extremely confusing because the dialplan looks wrong, but nothing you change in FreePBX makes any difference.

Root Cause (Spectrum‑Specific (and PJSIP-specific?))

Spectrum does not accept CallerID strings that contain formatted display names or quotes.

This includes:

"Caller Name" <1234567890>
"Caller Name"
Caller Name <1234567890>
<1234567890>

If you send anything other than a plain numeric CID, Spectrum silently rejects the INVITE.
When that happens, Asterisk tries alternative dialing forms (fallback SIP‑URI logic), and that’s when you see dial strings like:

PJSIP/number@spectrum

This makes it look like FreePBX is generating a bad dial string — it isn’t.
Spectrum is rejecting the first INVITE due to the CNAM display format.

The Fix (Simple, Carrier‑Compliant)

Set your Outbound CallerID to numbers only.

Correct (Accepted by Spectrum):

1234567890

or

11234567890

Incorrect (Rejected by Spectrum):

"Business Name" <1234567890>
"Business Name"
Business Name <1234567890>
<1234567890>

This single change immediately stops the fallback dialing behavior and restores correct PJSIP dial syntax.

Where to Set This in FreePBX

Connectivity → Trunks → (Spectrum Trunk) → General → Outbound CallerID

Use ONLY the number:

1234567890

Apply Config → Reload.

You’re done.

Optional: Force Trunk CID System‑Wide

(Note, this solution does not work if you do indeed need multiple outbound callerIDs)…

If you want to ensure no extension accidentally introduces CNAM:

Settings → Advanced Settings → Always Use Trunk CID → Yes

This forces FreePBX to always use the clean numeric CID you configured.

Why This Matters

This issue is incredibly misleading because:

  • The dialplan looks wrong

  • The PJSIP trunk looks correct

  • No custom dialplan exists

  • No dial manipulation rules include a suffix

  • Asterisk’s fallback behavior masks the real issue

But the entire problem boils down to Spectrum requiring unformatted numeric CallerID only.

Hope this helps someone!

If you’re using Spectrum — especially Spectrum Fiber or Business Voice trunks — and your outbound calls behave strangely or your dialstring is being rewritten, check your CallerID formatting first.

This fix eliminated the issue immediately.

2

In general, AI postings are not welcome. And this is a great example of why. Most of what you got from the AI is nonsense. The only thing relevant here is that Spectrum wants caller ID fields with only digits. So just post that.

Copilot does not understand how dial strings work…

Not unexpected if you look at the dialplan.

gah…

3

Sorry, you may not like it, but the full detail was what I found helpful in diagnosing this, and specifically the search fodder that may help someone else find this solution faster. I don’t just randomly post AI-generated crap, but modified portions before posting for relevance.

4

You shouldn’t be sending CNAM over PSTN at all, no matter who your provider is.

5

It’s not that I don’t like it, it’s that the things I quoted are just downright wrong.

6

No, they aren’t. I included them specifically because those were exactly the symptoms I was seeing, and every other solution led down a wrong path.

Example:
[2026-03-16 14:16:47] VERBOSE[32905][C-0000024e] app_dial.c: Called PJSIP/xxxxxxxxxx@spectrum

It’s not that the specific syntax is incorrect, but how its sent in the invite after callerID parsing (different between SIP and PJSIP) and interpreted by the carrier is, and with no other changes, does NOT work just simply changing from SIP to PJSIP. In other words, the SIP trunk handles the callerID differently than PJSIP, as the SIP trunk worked fine.

I’ll not post further responses, with the hopes that perhaps the little bit of information might save someone else time when searching for these symptoms.

7

Whoah there!

Pretty much defacto in the industry now is:

You send the digits of whatever DID number in your DID block you want to use as the source DID, in the CNAM.

You send blank in CNAM if you want the source to be blank, whereupon the carrier will pass the call into the PSTN with “source blocked” Many carriers, these days, will now substitute “possible spam call” or “blocked number” or some variation.

You DON’T send any actual names, alpha or otherwise.

The reason is because of the following. All carriers either use an internal CNAM database, or do dips from the national CNAM databases, or just do nothing, to send out the CLID to the subscriber phone (the alphanumeric name, enhanced caller ID, what have you)

A carrier sends whatever the heck it wants as the callerID number (CNAM) to the PSTN but in general it’s going to send a DID from the block assigned to the customer. The days of customers being funny smart asses and substituting “8675309 Jenny Jenny” instead of their actual DID are over.

Dips from the national database cost money so a lot of budget/cheapskate wireless carriers don’t do them at all on incoming calls and just pass the call with the number only.

Possibly, once upon a time, back in The Olden Days ™ carriers were trusting enough to actually believe an alphanumeric name sent in CNAM was valid. But, boiler-room operators everywhere destroyed that. This is why we just can’t have nice stuff anymore.

Basically what you are describing is - Spectrum had it’s head up it’s rear all these years and were letting you do it wrong, to the point that you thought the wrong way was the right way. Finally Spectrum pulled their head out and now is only letting you do it the right way and you think they are being overly strict. Well you can thank the boiler room operators for that.

8

This entire thread is filled with misinformation. CNAM isn’t checked for anything. It has nothing to do with validating the call. What we didn’t see in any of this was actual call logs showing what was really sent. A malformed from user could be the culprit, i.e. the from user or the PAI/RPID headers have the name and number formatted as part of the from user.

At most the CNAM will be ignored either by Spectrum and they’ll place the CNAM they have on record or the far side carrier will do their own lookup.

Depending on the carrier, the CallerID number is taken from the PAI or RPID headers but the default is the from user part of the From URI.

So basically by removing the Name portion it fixes the problem but why and how it fixed the problem is completely lost here because no one knew why it was causing the problem. Removing the name would fix a malformed CallerID issue which may look like “If I don’t send a name they accept it”.

As for the AI stuff, it’s wrong. Just wrong.

This is absolutely a proper dial string format for PJSIP. It won’t work for chan_sip.

This is 100% wrong dial string for PJSIP, it was for chan_sip.

It’s documented.