PBX doesn't backlist 1001st or higher black listed numbers

[5953lc]

As best as I can test, any entry under 1000 on the black list will be blocked; any entry over 1000 will not be blocked.

 

(This may affect the white list code as well.)

 

Assuming the following:

 

The # of .xml files in the snomONE adrbook directory are the total # of Contact Type entries in the domain addressbook (combined WhiteList BlackList and Regular Contacts, right?) I have 2389 .xml files in my addrbook directory and 90%+ are Black List entries.

and for the /dom_adrbook.htm page:

I set "Result Length" to "View All" and click on the "Search" button.

It will only list 1000 entries. ( I have 2389 .xml files in my addrbook directory and 90%+ are Black List entries.)

[Vodia PBX]

I think that this is a web presentation issue. Because the PBX has to somehow limit the amount of information it presents on the web page, it shows the first 1000 blacklisted numbers. If you grep in the address book directory, I think you should be able to verify that the records are in the system.

[5953lc]

There may be a web presentation issue (But there is no reason to limit the amount of information presented, especially since this information is all displayed vertically and the user just has to scroll down ...).

 

Yes, I've checked and the blacklisted numbers are listed as blacklisted using the web interface, and I'm still getting calls from numbers that are supposed blacklisted.

 

How would you grep for a blacklisted number to not only show the file, but show the value listed in the file is black listed ? ?

 

grep -rni "000-000-0000" *

 

It worked and came back with a filename match.

 

I used "ls -l | wc -l" to count the total address book entries (white list, regular, and black list). Is that correct ?

 

Please double-check to make sure that having 2404 files in my adrbook directory isn't messing things up.

[Vodia PBX]

The other common problem is how numbers are exactly written. To the human, +1-617-399-8147 may be the same like 6173998147 or 16173998147 but it is not for a string comparison. The country code in the domain is supposed to transform those numbers into the same string, make sure that it is set. Also sometimes the display portion of the SIP From-field contains the number, but the user part does not. The blacklisting happens based on the user-part in the URI.

[5953lc]

1) I assumed string comparison was absolute, where +1-617-399-8147, 6173998147 and 16173998147 would be 3 different entries and, in fact, I would have made 3 separate entries. Whatever CID is presented incoming is faithfully copied and put in as a "Black List" entry, every time.

 

2) In the Agent Group, my From-Header: is set to "Group Name (Calling Number)" where Calling Number is what is being black-listed.

 

Again, there may be a web presentation issue showing just the first 1000 entries (But there is no reason to limit the amount of information presented, especially since this information is all displayed vertically and the user just has to scroll down ...).

 

How can I fix the 1000 entry limitation ?

 

Also the phonebook list just the black-list entries, just the white-list entries, or just the regular entries ...

[Vodia PBX]

1) That is not necessary actually a bad idea if you have a country code set. The job of the country code is to transform those numbers into exactly the same (string-comparable) format at least internally. If you don't have a country code set, well then you need to do that.

 

2) On the server side the list is not limited. What is the exact file you looking at? I see some 1000 limitation in the recording files; where that number could be changed in the template.

 

Down the road the proper way to have those long lists is to have a better REST API for those records, so that the records are downloaded in a pages fashion. The goal for the next generation is to make every list paged, so that you can have millions of numbers everywhere. For V5, well there are limits of what we can do.