CallerID Issue with certain extensions

Hello Forum Friends,

I am looking for help troubleshooting an issue that is affecting ATA customers off my FreePBX related to CallerID name display. I am able to see in the Asterisk Logfiles the data displaying the CALLERID(name) pasted below, but I am stuck toying around with the ATA with no change and wondering if I am missing something in the server. My IP phones seem to work fine with CNAM getting through. I also have other ATA customers not impacted. Any ideas of where to go next with isolating this issue?

As always, thank you all in advance, your input is always beyond helpful.

33544 [2025-05-13 10:04:14] VERBOSE[17803][C-0000e868] pbx_builtins.c: Goto (macro-user-callerid,s,49)
33545 [2025-05-13 10:04:14] VERBOSE[17803][C-0000e868] pbx.c: Executing [s@macro-user-callerid:49] Set(PJSIP/bandwidth.com-0001da28, CALLERID(number)=+1717xxxxxxx) in new stack
33546 [2025-05-13 10:04:14] VERBOSE[17803][C-0000e868] pbx.c: Executing [s@macro-user-callerid:50] Set(PJSIP/bandwidth.com-0001da28, CALLERID(name)=NAME IS HERE) in new stack
33547 [2025-05-13 10:04:14] VERBOSE[17803][C-0000e868] pbx.c: Executing [s@macro-user-callerid:51] GotoIf(PJSIP/bandwidth.com-0001da28, 0?cnum) in new stack
33548 [2025-05-13 10:04:14] VERBOSE[17803][C-0000e868] pbx.c: Executing [s@macro-user-callerid:52] Set(PJSIP/bandwidth.com-0001da28, __MCNUM=+1717xxxxxxx) in new stack
33549 [2025-05-13 10:04:14] VERBOSE[17803][C-0000e868] pbx.c: Executing [s@macro-user-callerid:53] Set(PJSIP/bandwidth.com-0001da28, __MCNAME=NAME IS HERE) in new stack
33550 [2025-05-13 10:04:14] VERBOSE[17803][C-0000e868] pbx.c: Executing [s@macro-user-callerid:54] Set(PJSIP/bandwidth.com-0001da28, __MCEXTEN=) in new stack
33551 [2025-05-13 10:04:14] VERBOSE[17803][C-0000e868] pbx.c: Executing [s@macro-user-callerid:55] Set(PJSIP/bandwidth.com-0001da28, __MCORGCHAN=PJSIP/bandwidth.com-0001da28) in new stack
33552 [2025-05-13 10:04:14] VERBOSE[17803][C-0000e868] pbx.c: Executing [s@macro-user-callerid:56] Set(PJSIP/bandwidth.com-0001da28, CDR(cnam)=NAME IS HERE) in new stack
33553 [2025-05-13 10:04:14] VERBOSE[17803][C-0000e868] pbx.c: Executing [s@macro-user-callerid:57] Set(PJSIP/bandwidth.com-0001da28, CDR(cnum)=+1717xxxxxxx) in new stack

If I am missing lines, or need a different format please let me know.

The ATA will communicate caller ID to the analog device using some in-band signaling scheme. On a Cisco ATA, in the Regional menu, the selectors look like this:

image

1 Like

I am assuming that you can replicate the problem in your shop using a test extension, ATA of same make/model/version, and same or similar phone. If not, the remote ATA’s syslog feature may supply some clues. I am also assuming that the calling number is properly displayed and only the name is empty or wrong.

The ATA may have a configuration option to get the caller ID data from the From, Remote-Party-ID or P-Asserted-Identity header. Check with pjsip logger that the selected header is being sent with the correct data, e.g.,
From: "NAME IS HERE" <sip:[email protected]>

Next, the original caller ID standard required that the device be capable of displaying a 15 character name and a 10 digit number. Possibly, sending 717xxxxxxx instead of +1717xxxxxxx will help. If the incoming name exceeds 15 characters, truncating it may help.

If you still have trouble, post ATA and analog phone details, as well as how the name is incorrect.. If the same name and number display correctly on a different ATA/phone combination, provide an example.

Thanks for the suggestions. It turned out to be a setting that was wrong in the ATA. As for why the original ATA failed to pass CNAM all of the sudden, I had to factory the Grandstream HT802 and reconfigure it. It is working (minus the display lights).
For compatibility with my set up, These are some of the settings I landed on for success;

CallerID Fetch order
Auto

CallerID Scheme
Bellcore/Telcoria

Caller ID transmission mode
Multiple data message format

Thanks again all for your input.

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