The Neverending Story: S P A C E S

[Christian_B]

3CX has trouble with spaces in forwarding rules. The call will simply be dropped and users are not prevent from entering numbers in this way.
Spaces are not a problem when using the input field of the phone client. In this case spaces are accepted and obviously ignored.
This kind of inconsequent behavior doesn't make any sense. Of course, users expect it to just work if they put the same number in the same
format into a forwarding rule.

Why are threads like the following being closed and even marked as solved?

https://www.3cx.com/community/threads/spaces-in-mobile-number-forwarding-failed.84766/#post-397092
https://www.3cx.com/community/threads/remove-spaces-in-outbound-trunk-rules.64418/
https://www.3cx.com/community/threads/mobile-phone-field-and-blank-spaces.85794/

This is not even solved in v18. Anyone who just glances at E.123 - or DIN 5008 for Germany - will see that human-readable phone numbers contain spaces. The standards might encourage or even require certain positions to place the spaces but as handling a phone doesn't require a lawyer or a PhD - not that any of that would actually help - but a average people will place spaces at arbitrary positions.

What is the actual problem with post-processing phone numbers and removing those spaces?

 

[YiannisH_3CX]

Hello @Christian_B

In V18 the management console will not allow you to add a number with spaces in forwarding rules. The only field that this is still allowed is the mobile phone field which is still pending as there is a compatibility issue with imports from Office 365.
So the users will be prompted to remove spaces from numbers when adding them in forwarding rules so calls will work every time. That is the intended functionality to avoid the need of extra processing on the servers side for each call.

 

[Christian_B]

Hi YiannisH_3CX,

indeed the HMI (human machine interface) shows the following, if I try to enter a number containing spaces - even if it's just a trailing space:

Phone number should be specified and can contain only: A-Z a-z 0-9 + * . _

Now, this is interesting! Technically, the list of allowed characters contains a space - multiple even. Furthermore, why the heck would you allow asterisk, period and underscore in phone numbers if spaces are such a huge issue? Even more interesting, if I replace each space character by an underscore, the HMI accepts the number but forwardings will fail in the same manner as with spaces before. However, if I replace each space character by an underscore, it works just fine. Haven't tried the other characters yet.

Edit: I tried arbitrary letters as well, they were accepted and the call forwarding worked just as if the letters weren't there. The full number with letters appeared in the log actually.

 

[Christian_B]

I found several such entries in the call log on the admin web interface:
Call or Registration to 0 xx 123 456 78@(Ln.10000@Patton XXXX) has failed. x.x.x.x replied: 484 Address Incomplete; from IP:x.x.x.x:5060
SIP Server ID: 12294 01/13/2022 2:54:40 PM

How do I quickly find the extension responsible/affected by this?
I already exported the extension list from the web interface to have a searchable CSV file.
Apparently, this number is not configured as a "mobile phone number" so it doesn't appear in there.
So it must be elsewhere in forwarding rules.