CID stuck with wrong CID

CID cannot be switched. There isn’t any CID in the termination trunks either and I’ve tried several variants of setting it. Currently it’s set to <9254185062> but 9254201420 is showing. It was working a few days ago but it went back to the other one and cannot get it back showing 9254185062.

Only location that has CID specified is each user. Our carriers don’t require trunk ID only IP base auth.

Sorry if the original question wasn’t clear.

Here’s my problem: I’ve setup our carrier with hidden CID since they don’t require it and each ext will handle their own CIDs. However on my ext I have setup currently “Scott Parks” <9254185062> but when I call my mobile phone the caller ID is showing as 9254201420 NOT what I’ve set in the ext settings.

Don’t override CID info in the trunk if you want teh extensions to do uit, if you want the CID to be presented to the called party don’t hide it.

I’m not following…

So don’t make the trunk CID hidden? This still doesn’t fix the problem. If left blank in the trunk still shows the 9254201420 CID NOT what’s in the ext settings of 9254185062.

Then you will have to check with you provider after watching the logs to make sure you are trying to send your preferred CID.

CDRs are all showing <9254201420>

Carrier doesn’t care what we send them for CID.

As I said

. . . Then you will have to check with you provider after watching the logs to make sure you are trying to send your preferred CID.

the CDR’s don’t prove much, a call log would.

tcpdump confirms it’s showing sip:[email protected]

If there was a way to upload screenshot I’d upload the call flow from wireshark

Just post a log of an outbound call, it’s that easy.

Not sure if this is what you’re talking about. I just used the commands from the wiki link then generated a call and this is what I got back.

2015-08-19 18:11:06 CHAN_START Scott Parks 1420 DEFAULT 8772891274 from-internal SIP/1420-000000bb
2015-08-19 18:11:06 CHAN_START DEFAULT s from-trunk-sip-Term-01 SIP/Term-01-000000bc
2015-08-19 18:11:09 ANSWER CID:9254201420 8772891274 DEFAULT 8772891274 from-trunk-sip-Term-01 AppDial SIP/Term-01-000000bc
2015-08-19 18:11:09 ANSWER 9254201420 1420 8772891274 DEFAULT s macro-dialout-trunk Dial SIP/1420-000000bb
2015-08-19 18:11:09 BRIDGE_START 9254201420 1420 8772891274 DEFAULT s macro-dialout-trunk Dial SIP/1420-000000bb
2015-08-19 18:15:19 BRIDGE_END 9254201420 1420 8772891274 DEFAULT s macro-dialout-trunk Dial SIP/1420-000000bb
2015-08-19 18:15:19 HANGUP CID:9254201420 8772891274 DEFAULT macro-dialout-trunk AppDial SIP/Term-01-000000bc
2015-08-19 18:15:19 CHAN_END CID:9254201420 8772891274 DEFAULT macro-dialout-trunk AppDial SIP/Term-01-000000bc
2015-08-19 18:15:19 HANGUP 9254201420 1420 8772891274 DEFAULT 8772891274 from-internal SIP/1420-000000bb
2015-08-19 18:15:19 CHAN_END 9254201420 1420 8772891274 DEFAULT 8772891274 from-internal SIP/1420-000000bb
2015-08-19 18:15:19 LINKEDID_END 9254201420 1420 8772891274 DEFAULT 8772891274 from-internal SIP/1420-000000bb

That is not a close to a complete call, nothing there to help diagnose. Please do it with regard to

http://wiki.freepbx.org/display/GHWF/Providing+Great+Debug

the call will leave a timestamped spore in /var/log/asterisk/full

[2015-08-19 19:29:48] VERBOSE[15054][C-000000ad] netsock2.c: == Using SIP RTP TOS bits 184
[2015-08-19 19:29:48] VERBOSE[15054][C-000000ad] netsock2.c: == Using SIP RTP CoS mark 5
[2015-08-19 19:29:48] VERBOSE[15054][C-000000ad] app_dial.c: – Called SIP/Term-01/19257654179
[2015-08-19 19:29:49] VERBOSE[15054][C-000000ad] app_dial.c: – SIP/Term-01-000000c8 is making progress passing it to SIP/1420-000000c7
[2015-08-19 19:29:51] NOTICE[15054][C-000000ad] res_rtp_asterisk.c: Unknown RTP codec 126 received from ‘66.159.230.250:55220’
[2015-08-19 19:29:56] VERBOSE[15054][C-000000ad] app_dial.c: – SIP/Term-01-000000c8 answered SIP/1420-000000c7
[2015-08-19 19:30:00] VERBOSE[15054][C-000000ad] pbx.c: – Executing [[email protected]:1] Macro(“SIP/1420-000000c7”, “hangupcall,”) in new stack
[2015-08-19 19:30:00] VERBOSE[15054][C-000000ad] pbx.c: – Executing [[email protected]:1] ExecIf(“SIP/1420-000000c7”, “0?Set(CDR(recordingfile)=.wav)”) in new stack
[2015-08-19 19:30:00] VERBOSE[15054][C-000000ad] pbx.c: – Executing [[email protected]:2] GotoIf(“SIP/1420-000000c7”, “1?theend”) in new stack
[2015-08-19 19:30:00] VERBOSE[15054][C-000000ad] pbx.c: – Goto (macro-hangupcall,s,4)
[2015-08-19 19:30:00] VERBOSE[15054][C-000000ad] pbx.c: – Executing [[email protected]:4] ExecIf(“SIP/1420-000000c7”, “0?Set(CDR(recordingfile)=)”) in new stack
[2015-08-19 19:30:00] VERBOSE[15054][C-000000ad] pbx.c: – Executing [[email protected]:5] Hangup(“SIP/1420-000000c7”, “”) in new stack
[2015-08-19 19:30:00] VERBOSE[15054][C-000000ad] app_macro.c: == Spawn extension (macro-hangupcall, s, 5) exited non-zero on ‘SIP/1420-000000c7’ in macro ‘hangupcall’
[2015-08-19 19:30:00] VERBOSE[15054][C-000000ad] pbx.c: == Spawn extension (macro-dialout-trunk, h, 1) exited non-zero on ‘SIP/1420-000000c7’
[2015-08-19 19:30:00] VERBOSE[15054][C-000000ad] app_macro.c: == Spawn extension (macro-dialout-trunk, s, 23) exited non-zero on ‘SIP/1420-000000c7’ in macro ‘dialout-trunk’
[2015-08-19 19:30:00] VERBOSE[15054][C-000000ad] pbx.c: == Spawn extension (from-internal, 7654179, 7) exited non-zero on ‘SIP/1420-000000c7’

Oh dear . . . .

We need the WHOLE CALL!. not just bits , try :-

cat /var/log/asterisk/full|grep 15054