CID_Number missing on internal SCCP calls

bodger · September 1, 2021, 6:57pm

Greetings all,

I’m hoping someone can help me out troubleshooting a rather perplexing problem.

I’ve just configured a new Asterisk/FreePBX/chan-sccp-manager system from scratch using the latest FreePBX Distro. (12.7.8-2107-3.sng7)

This installs:

Asterisk: 16.9.0

PBX: 15.0.17.48

To which I installed chan-sccp: 4.3.4 develop -b0b3cdb and chan-sccp-manager: 14.2.0.11

Everything appears to be working well, with the sole exception that the CID_Number is missing from internal calls originated on an sccp extension (it works just fine on SIP extensions).

Calls are routed just fine, and the cid_name is present & correctly displayed on the destination device, just without a number

Checking the sccpline table the necessary data appears to be there: ’name’ contains the extension (line) number (eg. 101), ‘label’ the name (Cashwrap), ‘description’ the name & number (Cashwrap <101>), ‘cid_name’ contains the correct name (Cashwrap), and ‘cid_num’ is empty - as this is where an outbound caller ID would be passed to a trunk (if required)

Checking the Asteriskdb, it does appear that required fields are correctly populated (/AMPUSER/101/cidname: Cashwrap, /AMPUSER/101/cidnum: 101)

Doing a complete ‘database show’ also lists just the sccp extensions at the end of the listing (/cidname/101: Cashwrap), although it’s quite possible that I may have created those by messing around with CIDSuperfecta/Asterisk PhoneBook (which can cache to the Asteriskdb).

I’m not sure what’s causing the problem, but running a call trace reveals that [macro-user-callerid] is not returning the CALLERID(number) although it does return the correct CALLERID(name). See trace below:

== Using SCCP RTP TOS bits 184

== Using SCCP RTP CoS mark 6

-- Executing [601@from-internal:1] GotoIf("SCCP/301-000000DC", "1?ext-local,601,1:followme-check,601,1") in new stack

-- Goto (ext-local,601,1)

-- Executing [601@ext-local:1] Set("SCCP/301-000000DC", "__RINGTIMER=15") in new stack

-- Executing [601@ext-local:2] ExecIf("SCCP/301-000000DC", "0?Set(__CWIGNORE=)") in new stack

-- Executing [601@ext-local:3] Macro("SCCP/301-000000DC", "exten-vm,601,601,0,0,0") in new stack

-- Executing [s@macro-exten-vm:1] Macro("SCCP/301-000000DC", "user-callerid,") in new stack

-- Executing [s@macro-user-callerid:1] Set("SCCP/301-000000DC", "TOUCH_MONITOR=1630457047.313") in new stack

-- Executing [s@macro-user-callerid:2] Set("SCCP/301-000000DC", "CHANCONTEXT=") in new stack

-- Executing [s@macro-user-callerid:3] Set("SCCP/301-000000DC", "CHANCONTEXT=") in new stack

-- Executing [s@macro-user-callerid:4] Set("SCCP/301-000000DC", "CHANEXTENCONTEXT=301-000000DC") in new stack

-- Executing [s@macro-user-callerid:5] Set("SCCP/301-000000DC", "CHANEXTEN=301-000000DC") in new stack

-- Executing [s@macro-user-callerid:6] Set("SCCP/301-000000DC", "CALLERID(number)=") in new stack

-- Executing [s@macro-user-callerid:7] Set("SCCP/301-000000DC", "AMPUSER=") in new stack

-- Executing [s@macro-user-callerid:8] Set("SCCP/301-000000DC", "HOTDESCKCHAN=301-000000DC") in new stack

-- Executing [s@macro-user-callerid:9] Set("SCCP/301-000000DC", "HOTDESKEXTEN=301") in new stack

-- Executing [s@macro-user-callerid:10] Set("SCCP/301-000000DC", "HOTDESKCALL=0") in new stack

-- Executing [s@macro-user-callerid:11] ExecIf("SCCP/301-000000DC", "0?Set(HOTDESKCALL=1)") in new stack

-- Executing [s@macro-user-callerid:12] ExecIf("SCCP/301-000000DC", "0?Set(CALLERID(name)=)") in new stack

-- Executing [s@macro-user-callerid:13] GotoIf("SCCP/301-000000DC", "0?report") in new stack

-- Executing [s@macro-user-callerid:14] ExecIf("SCCP/301-000000DC", "1?Set(REALCALLERIDNUM=)") in new stack

-- Executing [s@macro-user-callerid:15] Set("SCCP/301-000000DC", "AMPUSER=") in new stack

-- Executing [s@macro-user-callerid:16] GotoIf("SCCP/301-000000DC", "0?limit") in new stack

-- Executing [s@macro-user-callerid:17] Set("SCCP/301-000000DC", "AMPUSERCIDNAME=") in new stack

-- Executing [s@macro-user-callerid:18] ExecIf("SCCP/301-000000DC", "0?Set(__CIDMASQUERADING=TRUE)") in new stack

-- Executing [s@macro-user-callerid:19] GotoIf("SCCP/301-000000DC", "1?report") in new stack

-- Goto (macro-user-callerid,s,28)

-- Executing [s@macro-user-callerid:28] NoOp("SCCP/301-000000DC", "Macro Depth is 2") in new stack

-- Executing [s@macro-user-callerid:29] GotoIf("SCCP/301-000000DC", "1?report2:macroerror") in new stack

-- Goto (macro-user-callerid,s,30)

-- Executing [s@macro-user-callerid:30] GotoIf("SCCP/301-000000DC", "0?continue") in new stack

-- Executing [s@macro-user-callerid:31] ExecIf("SCCP/301-000000DC", "1?Set(__CALLEE_ACCOUNCODE=)") in new stack

-- Executing [s@macro-user-callerid:32] Set("SCCP/301-000000DC", "__TTL=64") in new stack

-- Executing [s@macro-user-callerid:33] GotoIf("SCCP/301-000000DC", "1?continue") in new stack

-- Goto (macro-user-callerid,s,49)

-- Executing [s@macro-user-callerid:49] Set("SCCP/301-000000DC", "CALLERID(number)=") in new stack

-- Executing [s@macro-user-callerid:50] Set("SCCP/301-000000DC", "CALLERID(name)=Cabin Private Line") in new stack

-- Executing [s@macro-user-callerid:51] GotoIf("SCCP/301-000000DC", "0?cnum") in new stack

-- Executing [s@macro-user-callerid:52] Set("SCCP/301-000000DC", "CDR(cnam)=Cabin Private Line") in new stack

-- Executing [s@macro-user-callerid:53] Set("SCCP/301-000000DC", "CDR(cnum)=") in new stack

-- Executing [s@macro-user-callerid:54] Set("SCCP/301-000000DC", "CHANNEL(language)=en") in new stack

I’ve been bashing my head against the wall for a few days trying to sort this out, as it’s screwing up the cdr and makes it impossible to go directly to the correct VM box by pressing the VM softkey (*97 invokes comedian mail).

So if anyone can help me out, I’d be hugely grateful.

Best - Anton

bodger · September 11, 2021, 4:22pm

Just a quick bump.

If anybody has any ideas, I’d love to hear them.

Thanks - Anton

Stewart1 · September 11, 2021, 4:41pm

Does this fail even if you set CID Num Alias for the extension?

bodger · September 11, 2021, 5:30pm

Thanks so much for the reply.

So, if by CID Num Alias, you mean Outbound Caller ID, I did try manually writing the caller ID into the CID_Num column in the sccpline table via MySQL Workbench while I was trying to troubleshoot the issue, but it didn’t work.

However, following your suggestion today, I did try putting the internal caller ID (Ext number) into the Outbound Caller ID field in the GUI (which I see writes the value to CID_Num in sccpline). This time it worked… which is curious.

It was my understanding that the value entered here would actually override the extension’s CID and also the outbound CID set for the trunk… which would be a problem.

Much to my surprise, I did a little more playing around and it appears that it does not actually override the setting for the trunk.

This is decidedly strange, and I’m pretty sure it’s not supposed to work this way.

bodger · September 11, 2021, 6:09pm

I’d also just add that this issue only affects the sccp extensions, my SIP (chan_pjsip) extensions are fine… they pass the correct internal CID as expected and the Outbound Caller ID field is blank.

Stewart1 · September 11, 2021, 6:16pm

On pjsip and chan_sip extensions, the Advanced tab has a ‘CID Num Alias’ field that overrides the caller ID for internal (or intra-company) calls. For external calls, the Outbound CID field is used. I thought that CID Num Alias was technology independent, but if an SCCP extension doesn’t have that field, it could be a bug or some conflict specific to SCCP.

bodger · September 12, 2021, 2:56am

Interesting, Stewart,

I think you might be right about a bug with the way sccp calls are handled.

I believe you’re quite correct about CID Num Alias which allows an extension to masquerade as another extension. The Advanced tab and CID Num Alias field is indeed available via the Extensions app, but the value is only saved if the alias is actually different from the extension number (eg. entering 101 on ext 101, hitting submit & then apply config, results in an empty CID Num Alias field when next opened to edit).

Setting the Ext. number to the Outbound Caller ID field, however, does appear to work for internal calls and does not actually override the CID for the trunk, which it should. This is decidedly strange and different from how it used to work in the previous incarnation of our phone system running Asterisk 13 and a much earlier version of FreePBX.

I’ve only done limited testing on a couple of extensions so far, but I’ll give it a thorough test this coming week. If all works out ok, I’ll mark this thread as solved (via workaround), but I really should raise a bug report… just not sure where exactly the bug lies… in chan-sccp-b, the chan-sccp-manager module, in FreePBX, or Asterisk itself?

Very much appreciate your help.

Best - Anton

bodger · September 12, 2021, 4:43pm

Further to my last, having done a little more testing I can confirm that Outbound Caller ID field actually does override the trunk settings (as it’s supposed to). However my VOIP trunk provider (Callcentric) will only permit the Outbound Caller ID configured for the trunk at their end, whatever I pass to them has no effect.

What I still don’t understand is why, when I manually set the CID_Num in sccpline it has no effect, but setting the Ext. number to the Outbound Caller ID in the GUI (which writes that value to the CID_Num column in sccpline) works. It must be altering something else, but what?

Deleting the Ext. number from the Outbound Caller ID field in the GUI clears the value from CID_Num and results in the Ext. being reported as unknown in the CDR.

You can see from my original post that the Extension is correctly listed in the Asteriskdb… AMPUSER/(ext)/cidnum: is correctly populated.

I have a viable workaround (thanks to my VOIP provider’s CID policy), but something is definitely not right here.

I’d so love to get to the bottom of this.

lgaetz · September 13, 2021, 1:50pm

They are written to the AstDB:

CLI> database show ampuser 6007/cidname
/AMPUSER/6007/cidname                             : Lorne Gaetz
1 results found.
CLI> database show ampuser 6007/cidnum
/AMPUSER/6007/cidnum                              : 6007
1 results found.

bodger · September 13, 2021, 3:29pm

Hi Lorne,

Thanks for your reply. I did check that as part of my initial troubleshooting… both cidname and cidnum are correctly populated in the database.

Removing the Ext number from the outbound caller ID does not delete the cidnum from the database, but the extension shows as unknown in the CDR.

Is it stored anywhere else that you can think of?

Best - Anton

system · October 14, 2021, 3:29pm

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