It’s in the [general] section of the included file “sip_general_additional.conf.”
It is over riding all other CIDs being sent out by the system.
I have looked everywhere on how to disable this in FreePBX, but I do not see it.
If I can’t find it, my last resort is just to delete it out of sip_general_additional.conf and get on with life.
Anyone know what I am referring to?
Thanks
I just commented out the line where is has “callerid=Unknown”
Works fine now.
If it was overriding any cid’s sent out the system, then you must have a seriously confused setup. That is a fallback default which should never be used because every standard dialpath out the system will set the callerid in the dialplan.
So, what ever you are doing, it is very non-standard. I mention this comment mostly for anyone else who comes along reading this thread and things that they should go and remove that to solve some problem…
All I had done was to follow the setup guide in the wiki. Though I may have done a restore with PIAF to contaminate this */FPBX.
In fact I had seen people with the same problem doing a search, but every solution kept pointing to somewhere else.
I had come across as this area as being the problem when I kept receiving direct SIP calls from telemarketers and saw in the “sip show setup” that CID was set to unknown when I was making sure my “allow anonymous calls” was set to no, which it was not.
Thanks again
It turns out that the CID is still not functioning. I have tested with with two different service providers.
This is ridiculous.
Maybe I see why, but not the coded reason why I am not getting the CID out.
I did a search of all the files (/etc/asterisk) for the number that should be in CID.
The only place it occurs in the extensions_additional.conf file.
Listed as “OUTCID_8 =” in the [globals] section.
It also so happens that “OUTCID_8” only appears in this file and section of all the conf files.
I looked in some other locations and could not find such variables being used so I am a bit lost on how the value of CIDOUT_x is getting passed.
Anyone care to explain?
Thanks
GeekBoy,
have a look at macro-outbound-callerid
it comes from one of several places, some of the global variables that you mentioned, AMPUSER and DEVICE objects depending on the mode, and REALCALLERIDNUM in certain instances.
macro-user-callerid plays a role in the whole myster also if you follow a call starting from outbound-allroutes
I started tracing, but then I thought it would be better just to watch what is going on. This is from the first few lines:
– Executing [4xxxxxxxxx@from-trunk:3] ExecIf(“SIP/66.xx.xxx.xx-1191aa00”, “0 |Set|CALLERID(name)=9999999999”) in new stack
– Executing [4xxxxxxxxx@from-trunk:4] Set(“SIP/66.xx.xxx.xx-1191aa00”, “__CALLINGPRES_SV=allowed_not_screened”) in new stack
– Executing [4xxxxxxxxx@from-trunk:5] SetCallerPres(“SIP/66.xx.xxx.xx-1191aa00”, “allowed_not_screened”) in new stack
– Executing [4xxxxxxxxx@from-trunk:6] Goto(“SIP/66.xx.xxx.xx-1191aa00”, “from-did-direct|100|1”) in new stack
– Goto (from-did-direct,100,1)
– Executing [100@from-did-direct:1] Macro(“SIP/66.xx.xxx.xx-1191aa00”, “exten-vm|100|100”) in new stack
– Executing [s@macro-exten-vm:1] Macro(“SIP/66.xx.xxx.xx-1191aa00”, “user-callerid”) in new stack
– Executing [s@macro-user-callerid:1] Set(“SIP/66.xx.xxx.xx-1191aa00”, “AMPUSER=9999999999”) in new stack
– Executing [s@macro-user-callerid:2] GotoIf(“SIP/66.xx.xxx.xx6-1191aa00”, “0?report”) in new stack
– Executing [s@macro-user-callerid:3] ExecIf(“SIP/66.xx.xxx.xx-1191aa00”, “1|Set|REALCALLERIDNUM=9999999999”) in new stack
– Executing [s@macro-user-callerid:4] Set(“SIP/66.xx.xxx.xx-1191aa00”, “AMPUSER=”) in new stack
– Executing [s@macro-user-callerid:5] Set(“SIP/66.xx.xxx.xx-1191aa00”, “AMPUSERCIDNAME=”) in new stack
– Executing [s@macro-user-callerid:6] GotoIf(“SIP/66.xx.xxx.xx-1191aa00”, “1?report”) in new stack
– Goto (macro-user-callerid,s,11)
– Executing [s@macro-user-callerid:11] GotoIf(“SIP/66.xx.xxx.xx-1191aa00”, “0?continue”) in new stack
– Executing [s@macro-user-callerid:12] Set(“SIP/66.xx.xxx.xx-1191aa00”, “__TTL=64”) in new stack
– Executing [s@macro-user-callerid:13] GotoIf(“SIP/66.xx.xxx.xx-1191aa00”, “1?continue”) in new stack
– Goto (macro-user-callerid,s,20)
– Executing [s@macro-user-callerid:20] NoOp(“SIP/66.xx.xxx.xx-1191aa00”, “Using CallerID “Name Unavailabl” <9999999999>”) in new stack
Just how is the being produced? Now all of a sudden I cannot get it to reproduce.
Thanks a lot for the assistance so far.
that is an inbound call. We don’t mess with inbound call CID with the exception of inbound cid modules which should typically only set the cnam from optional sources.
It has to be coming from somewhere. I have tested it calling to other phones, and calling back into the system. Even calling internal extensions are coming back as unknown or the 9999999999.
So this would mean that CID is not being sent out by the system at all.
I am starting to think just using plain ol’ Asterisk would be less of a headache since there are a lot less macros, and conf files to try to trace a bug down like this. A quick edit of the extension would have long solved this.
Any more Ideas?
Thanks again
I am having the same problem No caller ID is arriving at the provider when i use a different freepbx server running the same version and using the same trunk the callerID works fine