FreePBX 15 inbound route's CallerID number length

FreePBX Applications / Modules
, ,
1

Hello all,

Recently I decided to go to FreePBX 15 and Asterisk 16 and I found a very disturbing bug. As everyone knows here, in the Inbound routes there is a “CallerID Number” field you use to specify the incoming call CID with a pattern.

What I noticed (…unfortunately) in version 15 is that in this field you can write any pattern you want but when you save the route, your saved pattern is limited to 21 characters only!!! Witch is very short in many cases. Even if you manually check the /etc/asterisk/extensions_additional.conf the pattern string stored there cannot be longer than 21 characters.

In previous version 14 there was not this limitation. Does anyone knows if this is a known bug or there is somewhere a parameter that can extend this limit? (…i dont think so but lets hope)

Thanks for your time

2

I’m not aware of any new limitation introduced.

The longest a phone number can be is 15 digits, which gives you an additional 6 if you’re using any prefix/suffix or any other digits. What’s your use case that requires more than 21?

3

What caller id number is over 21 characters? 15 digits is the ITU max length for International numbers. So why would the caller id number be over 21 characters?

4

In that field you need to specify callerID patterns and not single CID numbers.
One example is: _+31213XX[0-4|6-9][0-4|6-9][0-6|8-9].
And believe me this is not something very rare :slight_smile:

5

That’s not a valid pattern match for Asterisk so one would probably say that is the reason it doesn’t work. You should review how pattern matching works Pattern Matching - Asterisk Project - Asterisk Project Wiki](Home - Asterisk Documentation)

Once you do that, try an actual valid pattern matching scheme and see how that plays out.

6

This pattern worked absolutely fine with FreePBX 14 for more than 3 years!!!
Why you think that this is not a valid pattern?

7

It is syntactically valid, but matches a character that, in practice you will never find, namely “|”, as well as digits. (E.g. it would match +3121309|||5, or +3121309|6|5). I don’t think that is causing your problem.

8

Guys as I said before, this pattern works flawlessly for years with Asterisk 13 and Freepbx 14.

This describes a caller ID starting with +31213 the next two digits could be anything possible, then the next two digits can be anything exempt “5” and the next digit anything exempt “7”. The rest of the CID can be anything.

With other words, in this pattern you specify an exclusion for an incoming number that looks like that: +31213(any)(any)557(any)

Once again, this worked fine !!!

9

It works because you never receive numbers containing “|” (false positive) and never receive numbers containing *, #, a, b, c, or d (false negatives), and your caller-IDs are restricted to DTMF digits, with an initial+, not the fully range of possibly SIP user field values.

1 Like
10

Ok lets forget why it works or how. My issue is on the limitation in this field length on the dialog box of inbound routes. Probably it should be a bug :(((

11

We cannot forget how or why it works but then claim it is a bug. Perhaps the bug was allowing invalid patterns for this field and that was fixed. But perhaps a length limiter has been put on. Have you simply tried removing the unneeded | and trying that? That would at least reduce the length by 3. Have you tested patterns with less than 19 characters?

12

Yes I checked that and you can put any pattern till 21 characters. Seems that frontend does not check pattern’s validity. Just saves the first 21 characters of this field. Instead of 50 characters in the previous version!!! That’s why I believe that should be a bug…

13

Submit a feature request and a bug report, and let the semantics sort themselves out. Without one, or the other, or both. Nothing will change. In the short term does adding the pattern to the conf file resolve the issue?

14

The limitation is in SQL. I’m surprised to learn this changed between versions 14 and 15, but will accept the claim without verifying. From the maria prompt:

MariaDB [asterisk]> describe incoming;
+-----------------+--------------+------+-----+---------+-------+
| Field           | Type         | Null | Key | Default | Extra |
+-----------------+--------------+------+-----+---------+-------+
| cidnum          | varchar(20)  | YES  |     | NULL    |       |
| extension       | varchar(50)  | NO   |     | NULL    |       |
  *snip*

You can manually alter the type to accpet 50 chars with the following:

MariaDB [asterisk]> ALTER TABLE incoming MODIFY COLUMN cidnum varchar(50) NULL;
Query OK, 1 row affected (0.02 sec)
Records: 1  Duplicates: 0  Warnings: 0

MariaDB [asterisk]> describe incoming;
+-----------------+--------------+------+-----+---------+-------+
| Field           | Type         | Null | Key | Default | Extra |
+-----------------+--------------+------+-----+---------+-------+
| cidnum          | varchar(50)  | YES  |     | NULL    |       |
| extension       | varchar(50)  | NO   |     | NULL    |       |
   *snip*

This is a work around, a feature request (or ideally a pull request) is the way to get it fixed for everyone. https://issues.freepbx.org/

1 Like
15

Thank you so much. I really appreciate your help

Have a great evening

16

https://issues.freepbx.org/browse/FREEPBX-23802

17

When reporting bugs don’t report them as New Feature as this is misleading. Report them as a bug properly so it gets handled properly and not triaged the wrong way.

18

Changed to bug.

19

PR in the ticket. :slight_smile:

1 Like
20

@lgaetz can confirm, see below the default in v14:

MariaDB [asterisk]> describe incoming;
+-----------------+--------------+------+-----+---------+-------+
| Field           | Type         | Null | Key | Default | Extra |
+-----------------+--------------+------+-----+---------+-------+
| cidnum          | varchar(50)  | NO   | PRI |         |       |
| extension       | varchar(100) | NO   | PRI | NULL    |       |
1 Like