After much experimenting I have not been able to find an easy way to set a users Caller ID as their own associated DDI without putting an override directly into the user account.
Is there an easy way to do this for every use rather than setting it manually for everyone?
Hi John,
I’m not sure where you are trying to override the caller ID, this can be edited on the extension edit screen, or as a best match to the extension number. I can’t think of any way that can be changed on the user account edit screen.
There are two levels that you can manage the CLI that is sent out from any extension:
By overriding the originated caller-ID on the extension edit screen:
This allows an extension to send out an override caller ID which may not be related at all to the extension number or inbound DDI associated with the extension. This is useful for things like users who want to always send out, say, a support team number even when they are calling from their personal extension, or where you have a fairly random relationship between extension number and CLI you want to present. If you don’t configure anything here, the CLI will initially be just the extension number, which will then be further processed/matched by the per trunk CLI settings…
On the per trunk CLI settings.
When a call originated from a local extension (with or without a CLI override) is sent to a trunk, the settings on the trunk can then be used to restrict or override the values that will be sent for that trunk only. If nothing is explicitly configured for a particular trunk then Passthru is the default here which just passes the extension number to the trunk provider. This is OK for ISDN trunks, but usually not the best thing to do for SIP trunks which often require a full qualified valid CLI to be passed.
The first ability to override on a per extension basis is fairly self explanatory, but the second per trunk configuration allows you to tailor the presented CLI sent based on the combination of the extension that originates it, and dynamically based on the trunk that the call actually leaves through. This can be important as you may want to have multiple trunk providers for resiliency, but often the CLI that can be presented on a trunk is restricted by the trunk provider to one of the inbound DDIs on that trunk. The per trunk CLI configuration allows you to have a set of extensions pass the full CLI corresponding to their DDIs when being sent to the trunk that those DDIs are native on, but substitute a more general but valid for that trunk CLI when sending to a backup trunk.
Does this help?