External CallerID forwarding to external #

Hi all,

I am having a problem forwarding the external CallerID to an external number and wanted to make sure it wasn’t an asterisk/freepbx problem but the telco blocking it. I am using Freepbx 2.10.1.19 with asterisk 1.8.32.2, I setup a virtual extension with its DID 982 and created a follow me with the external number followed by a #. In the Change External CID config I set Mode: “Default” as this should pass the external Caller ID. In asterisk debug I see this:

– Executing [[email protected]:2] ExecIf(“Local/[email protected];2”, “0?Set(REALCALLERIDNUM=00YYYYYYYY)”) in new stack
– Executing [[email protected]:3] GotoIf(“Local/[email protected];2”, “0?normcid”) in new stack
– Executing [[email protected]:4] Set(“Local/[email protected];2”, “USEROUTCID=00YYYYYYYY”) in new stack
– Executing [[email protected]:5] GotoIf(“Local/[email protected];2”, “1?bypass”) in new stack
– Goto (macro-outbound-callerid,s,7)
– Executing [[email protected]:7] Set(“Local/[email protected];2”, “EMERGENCYCID=”) in new stack
– Executing [[email protected]:8] Set(“Local/[email protected];2”, “TRUNKOUTCID=0123456”) in new stack
– Executing [[email protected]:9] GotoIf(“Local/[email protected];2”, “1?trunkcid”) in new stack
– Goto (macro-outbound-callerid,s,12)
– Executing [[email protected]:12] ExecIf(“Local/[email protected];2”, “1?Set(CALLERID(all)=0123456)”) in new stack
– Executing [[email protected]:13] ExecIf(“Local/[email protected];2”, “1?Set(CALLERID(all)=00YYYYYYYY)”) in new stack
– Executing [[email protected]:14] ExecIf(“Local/[email protected];2”, “0?Set(CALLERID(all)=)”) in new stack
– Executing [[email protected]:15] ExecIf(“Local/[email protected];2”, “0?Set(CALLERPRES()=prohib_passed_screen)”) in new stack
– Executing [[email protected]:12] GosubIf(“Local/[email protected];2”, “0?sub-flp-1,s,1()”) in new stack
– Executing [[email protected]:13] Set(“Local/[email protected];2”, “OUTNUM=xxxxxxxxxx”) in new stack
– Executing [[email protected]:14] Set(“Local/[email protected];2”, “custom=SIP/1-isdn”) in new stack
– Executing [[email protected]:15] ExecIf(“Local/[email protected];2”, “0?Set(DIAL_TRUNK_OPTIONS=M(setmusic^default)tw)”) in new stack
– Executing [[email protected]:16] ExecIf(“Local/[email protected];2”, “0?Set(DIAL_TRUNK_OPTIONS=twM(confirm))”) in new stack
– Executing [[email protected]:17] Macro(“Local/[email protected];2”, “dialout-trunk-predial-hook,”) in new stack
– Executing [[email protected]:1] MacroExit(“Local/[email protected];2”, “”) in new stack
– Executing [[email protected]:18] GotoIf(“Local/[email protected];2”, “0?bypass,1”) in new stack
– Executing [[email protected]:19] ExecIf(“Local/[email protected];2”, “0?Set(CONNECTEDLINE(num,i)=xxxxxxxxxx)”) in new stack
– Executing [[email protected]:20] ExecIf(“Local/[email protected];2”, “0?Set(CONNECTEDLINE(name,i)=CID:00YYYYYYYY)”) in new stack
– Executing [[email protected]:21] GotoIf(“Local/[email protected];2”, “0?customtrunk”) in new stack
– Executing [[email protected]:22] Dial(“Local/[email protected];2”, “SIP/1-isdn/xxxxxxxxxx,300,tw”) in new stack
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
– Called SIP/1-isdn/xxxxxxxxxx
– SIP/1-isdn-0000a8c2 is ringing
– Local/[email protected];1 is ringing

The called party (0xxxxxxxxx) sees the root/radix TRUNKOUTCID (012345) and not the external CallerID (REALCALLERIDNUM=00YYYYYYYY). Is this due to the fact that the telco company does not allow any external CID passing through but only the root/radix of the system? I see that asterisk is passing USEROUTCID correctly so it seems it is doing it’s job - just wanted to be sure from the asterisk/freepbx side everything was ok and that there is nothing else to do.

Thanks for any heads up!

If this is going out over an ISDN trunk, then I’d guess that the Telco is blocking (or simply ignoring) your custom Caller ID. Call them and ask - most of the Telco folks I’ve talked to will eventually forward you to someone that can help you with this Tier-2 or Tier-3 customer support question.

Another place to look is in the settings for “Intra-company route” - if that is turned on, the system could actually be sending whatever you have specified for the extension instead of the outbound route or trunk settings.