Summary:ASTERISK-21741: [patch] - Improved Caller ID Diagnostics and Processing for FXO Channels
Reporter:Vladimir Mikhelson (vmikhelson)Labels:patch
Date Opened:2013-04-30 23:55:15Date Closed:
Status:Open/NewComponents:Channels/chan_dahdi Core/CallerID
Versions: 13.18.4 Frequency of
Environment:Attachments:( 0) callerid.diff
( 1) chan_dahdi.diff
Description:Current implementation of callerid.c fails to pass the "flags" to the dial plan. As a result distinction between failed Caller ID detection, Failed Check Sum verification, Private Number, and Unknown Number and related Caller ID names becomes impossible. In all cases all we get back is NULL in both fields. On top of that callerid module assumes a non existent ability to request another Caller ID transmission from an analog channel in case the Caller ID check sum verification fails.

A couple of simple patches I propose helped me with troubleshooting the Caller ID recognition on analog POTS lines as well as some enhancement to the dial plan based on flags processing.

I did not test on any other channels but analog.  Possible implications could be expected on other channel types serviced by chan_dahdi and callerid modules.

Somebody with better architectural knowledge of Asterisk components can easily enhance my patches or make them more universal or just more beautiful. This help is very welcome.
Comments:By: Rusty Newton (rnewton) 2013-05-01 15:23:58.351-0500

Vladimir, thanks for the contribution! Per the [guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines#AsteriskIssueGuidelines-PatchandCodesubmission] can you please re-attach your callerid.diff in unified format (diff -u) ?

By: Vladimir Mikhelson (vmikhelson) 2013-05-01 18:17:58.526-0500


Here is the current version of both patches in the "diff -u" format.


By: Vladimir Mikhelson (vmikhelson) 2013-05-01 18:25:41.122-0500

I was debating whether I should include the bottom piece of the chan_dahdi.diff as it is related to some strange 1.8 behavior which ignores "ast_debug" silently but processes "ast_log" as expected.

It well maybe something in my configuration or just my lack of knowledge of Asterisk functions. All I know as soon as I added the traditional log function, i.e. ast_log, I got my debug output back.

By: Vladimir Mikhelson (vmikhelson) 2013-05-31 20:36:32.673-0500

Who is in charge now?  Do I need to do anything?

By: Rusty Newton (rnewton) 2013-06-05 18:28:16.027-0500

The issue is waiting for a developer to review it,possibly suggest changes and then test and commit it. If you want to move things along you might ask on the asterisk-dev mailing list for someone to review it or on the asterisk-users list for someone to test. For more info see [Patch and Code submission|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines#AsteriskIssueGuidelines-PatchandCodesubmission]

By: Vladimir Mikhelson (vmikhelson) 2013-06-05 19:38:51.305-0500


Thank you for the clarification.

Please let me know whether any testing of the future developers' suggested modifications could be needed.


By: N A (InterLinked) 2022-11-25 20:00:01.191-0600

I think this issue is dead at this point, but the attached patch from the reporter is wrong and should not be used. It completely violates the Caller ID specification by setting the name in the way that it does. You can't just do whatever you want. There are rules in the standard about how to decode and process Caller ID.

The correct thing to do is set the presentation on the channel to match the presentation in the Caller ID spill. There is a patch up on Gerrit that actually fixes the presentation issue: https://gerrit.asterisk.org/c/asterisk/+/19603

That change should fix this issue so I've referenced this there.