[Home]

Summary:ASTERISK-03229: PrivacyMgr will not work on ISDN4Linux
Reporter:unnet (unnet)Labels:
Date Opened:2005-01-09 04:22:54.000-0600Date Closed:2011-06-07 14:10:34
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) patch-app_privacy-01.diff
Description:PrivacyMgr will not work on ISDN4Linux as ISDN4Linux gives me a callerid of 0 when there is no CID present. PrivacyMgr expects any empty callerid. I have not tested if this really is an ISDN4Linux issue or that our telco/frontend pbx generates this issue.

****** ADDITIONAL INFORMATION ******

I've fixed up the following patch that will solve the problem for me. The patch wants to see an callerid with a longer length of 1 to go into privacy mode.
Comments:By: Mark Spencer (markster) 2005-01-09 04:32:39.000-0600

Fixed properly in CVS head (do not use attached patch)
By: unnet (unnet) 2005-01-09 04:50:56.000-0600

CVS fix for this problem does not compile

#include <asterisk/utils.h> will fix it
By: unnet (unnet) 2005-01-09 04:54:33.000-0600

Also I've just checked if the patch will work but it doesn't and obvious is that it will not work.

       if (chan->cid.cid_num && !ast_strlen_zero(chan->cid.cid_num)) {

Will fail for non-existant chan->cid.cid_num or an empty string. But will NOT fail for a string containing '0' which is our case.

My initial bugreport might be a little confusing, my apologies for that.
By: Mark Spencer (markster) 2005-01-10 00:20:05.000-0600

0 is still a number.  If you're getting a callerid of 0, then something else is presumably wrong, and you can try to use the setcallerid app to set it to epmty.
By: unnet (unnet) 2005-01-10 01:56:17.000-0600

It seems it is a bug inside ISDN4Linux and it would be nice to circumvent this in Asterisk and not in ISDN4Linux.

--kernel dmesg--
isdn_net: Incoming call without OAD, assuming '0'
isdn_net: call from 0 -> 0 229 ignored
isdn_tty: Incoming call without OAD, assuming '0'
isdn_tty: call from 0, -> RING on ttyI0

Inside the kernel it already notices there is no callerid and sets the callerid to 0. Maybe a workaround somewhere in channels/chan_modem_i4l can fix this ?
By: Brian West (bkw918) 2005-01-10 20:39:00.000-0600

exten => 0,1,Goto(nocid)

exten => nocid,1,DoYourThing

bkw
By: Brian West (bkw918) 2005-01-10 20:39:22.000-0600

Not really a bug if you're really getting 0 as a callerid from the telco...
By: Brian West (bkw918) 2005-01-10 20:40:02.000-0600

Ment to say exten s/0,1,Goto(nocid)
By: unnet (unnet) 2005-01-11 01:16:07.000-0600

You are misreading the issue.

If there is no callerid present the telco does not send it, however ISDN4Linux notices there is no CallerID and adds a CallerID of 0.

Although your fix of s/0, will go into a command tree for no callerid this will not really fix PrivacyMgr, unless you manually set the CID to empty in that Tree.

But this is only a workaround for a bug inside ISDN4Linux.

Here is ISDN4Linux getting a Call with CallerID set

isdn_net: call from 0655872642 -> 0 229 ignored
isdn_tty: call from 0655872642, -> RING on ttyI0

Here is a ISDN4Linux call without CallerID

isdn_net: Incoming call without OAD, assuming '0'
isdn_net: call from 0 -> 0 229 ignored
isdn_tty: Incoming call without OAD, assuming '0'
isdn_tty: call from 0, -> RING on ttyI0

Secondly if there is no CallerID set, PrivacyMgr will ask for a number being a minimum of minlength. Shouldn't we check if the incoming callerid set is ALSO minlength ?
By: Mark Spencer (markster) 2005-01-12 21:17:04.000-0600

Okay, so this is a bug basically with the ISDN4Linux stack, not with Asterisk, and can be worked around with extension logic in the mean time by eliminating a callerid of 0.  I think that's your best option -- I can't see any logical reason to try to make the isdn4linux portion of Asterisk change the callerid to empty if it's 0.
By: unnet (unnet) 2005-01-13 00:59:45.000-0600

What if this is not a bug in ISDN4Linux, but a misunderstanding off the ISDN4Linux API by asterisk developers. What if they meant to return 0 if no callerid present instead of delivering an empty callerid. Then my first guess is that this is really a bug inside channels/chan_modem_i4l. The extensions 'workaround' will still not fix PrivacyMgr, as we still want people to enter their 10 digit phone number.

Also because there is no way to tell PrivacyMgr that it just should run it's 'no-callerid-present'-routine, will still render PrivacyMgr broken/useless on ISDN4Linux.
By: Mark Spencer (markster) 2005-01-13 08:56:52.000-0600

The point is if you do an extension with callerid match of 0, you can then empty the callerid, e.g.:

exten => _X./0,1,SetCallerID()
exten => _X.,1,NoOp

Given that '0' is a perfectly valid callerid (e.g. from a private network), I can see way in which using '0' to represent a lack of callerid could be anything but a bug, especially in the absense of any documentation to the contrary from isdn4linux.

I suggest that you use the above workaround for now and that you contact the developers of isdn4linux to comment on their bizarre behavior in this case before reopening this bug report.
By: Digium Subversion (svnbot) 2008-01-15 15:20:46.000-0600

Repository: asterisk
Revision: 4728

U   trunk/apps/app_privacy.c

------------------------------------------------------------------------
r4728 | markster | 2008-01-15 15:20:46 -0600 (Tue, 15 Jan 2008) | 2 lines

Fix privacy manager to "do the right things" with blank, but present, callerid (bug ASTERISK-3229)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=4728