I have one trunk, and two DIDs. No matter what I do, I cannot get the executive office to place an outbound call with the correct CID. This one particular phone continues calling with the CID matching the main office. I’ve tried outbound CID, I’ve tried the extension override. The calls place without a problem, it’s just the CID that never matches the input.
Am I doing the outbound routes wrong? Am I missing a magical switch?
Hey what do the caller ID settings for the trunk look like?
Also check the extension itself and make sure it doesn’t have a set caller ID for outbound calls
As we’ve discussed in the past, there are at least four places that can “mess with” your Caller ID:
- The provider. If they are messing with your CID, you are stuck.
- The trunk definition. If you set an overriding CID here, nothing you put below will be honored.
- The Outbound Route definition. Here, if you set the Caller ID, it’s because a phone/outbound combination has led you to overriding the extensions’ default CIDs.
- The Extension definition. This is the CID associated with the extension. Usually, it’s the easiest way “back” to this phone, which could be a personal extension DID or an Extension Number for local calls.
5?> The phone app itself. Some technologies allow you to set a CID at the actual phone (my PY-90 phone at the Farm, for example).
A look through the logs should give you (eventually, it’s a lot of looking) the place that is setting the offending CID.
I use SIPStation so I can’t imagine that they’re tampering with that as the provider.
The trunk definition for Outbound CID is blank.
The outbound route definition is blank.
I set the extension outbound CID to the appropriate phone number but it doesn’t seem to take. The format is <##########> as prescribed.
I going to keep testing some combinations to see if I can get anything to stick. The only odd thing I can think of it there are two DIDs and four trunk definitions that were imported automatically…wasn’t sure if that was a FreePBX thing or if that was a fluke??
I take it back, there was a CID setting hiding in a lower-tier route that was forcing it to use the wrong CID instead of the correct one from the extension definition.
Sorry for the wild goose chase!
Not that wild - it comes up about every six weeks.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.