CallerID on intra-company routed call (from-internal) on externally forwarded outbound?

Hello,

I have a multi-site setup with a central office FreePBX (15.0.17.37) and a branch office FreePBX (same release). Each branch office operates “autonomously” for it’s own inbound and outbound calls to/from external. There are intra-office routes for internal calls. I have the outgoing trunk on the branch office set for “Any CID”. So, when a branch office extension (2875) gets an inbound external call, and call forward unconditional is set for 2875, the corresponding outbound diverted call transmits the foreign CID to the CF target external number (a cell phone) and the cell phone user sees the originating caller’s CID.

Fine. That’s what I want. BUT another internal extension at the main office (3065) dials 2875, and the call is diverted, the “Any CID” is sending the CID of “3075” to the carrier, but the carrier is clearly discarding it (most likely as invalid) and substituting the carrier’s default trunk CID (some 775 area code number), and NOT the intra-office route’s set outbound CID (the public DID of the main branch).

Is there any way to set this up so that a “from-internal” call to 2875 that is being diverted externally would set the CID of either the intra-company trunk and/or the fixed CID of the outbound trunk (as if no CID was supplied from the incoming call from 3065)? I tried “Force Trunk CID” but then I only get the CID of the branch office’s trunk on ALL outbound calls (losing the Foreign CID of incoming external callers).

I suppose I could train users that any calls from area code 775 are from inside the company, but I’d rather have the respective default DIDs for each of the other branches trunks and routes (that being each respective branches’ main DID #, OR a given internal extension’s extension-level (direct) DID).

Thoughts?

Thanks much!

Not exactly what you’re looking for, but there is this block of dialplan that preserves the outbound caller ID of the original dialing extension. It’s based on IAX trunks, but it could be modified without too much trouble to use SIP.

1 Like

The problem with that is it assumes an IAX trunk. It does not work with a PJSIP trunk. At least not when I tried it.

I never found the right variables to set.

Correct. The day will come when I need to rewrite this for SIP, when that happens I will throw it in a gist.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.