Bug with TAPI phone numbers containing spaces?

[coatline]

Bug: phone numbers formatted with spaces in them (as is frequently the case when initiating a call from Outlook) seem to be passed along to the server with the spaces present, which causes the call to fail. I assume that the 3CX server dislikes spaces in the called number field.

Either the VOIP softphone needs to strip space characters, or the server needs to be changed to ignore space characters?

It would be a pain to go through thousands of phone numbers in our Outlook public folders to edit out all spaces which are preset in the phone numbers. People leave the spaces in the phone numbers in order to ease the process of dialing manually from a number displayed on sceen.

 

[Resolve]

Bug: phone numbers formatted with spaces in them (as is frequently the case when initiating a call from Outlook) seem to be passed along to the server with the spaces present, which causes the call to fail. I assume that the 3CX server dislikes spaces in the called number field.

Either the VOIP softphone needs to strip space characters, or the server needs to be changed to ignore space characters?

It would be a pain to go through thousands of phone numbers in our Outlook public folders to edit out all spaces which are preset in the phone numbers. People leave the spaces in the phone numbers in order to ease the process of dialing manually from a number displayed on sceen.

Agreed.....

We're starting to use TAPI from Outlook in anger now. It's really important to a prospective customer. Any suggestions as to how to catch, filter/remove would be very welcome...

Tim Winstanley
Resolve Information Technology

 

[darrellchapman]

Is this in the buglist for the next version of the 3CX client? I really hope so. This was the option that basically convinced my boss that 3CX was the way to go (and it's not even working).

Darrell Chapman

 

[Jared.Savage]

Also need to have the phone strip out dashes and brackets so that a copy pasted number reading like this: (555) 555-5555 will go through.

 

[N_G]

Thanks for the feedback. We will address this in the next build.

 

[polyphemos]

Just an additional observation which might be relevant when addressing this problem.

Typically, what happens with spaces is that they are simply included in the string sent by the client to the server, and on from there to gateway or VoIP operator. Log then reports something like:

Call to sip:0477%20400%[email protected]:5060 has failed; Cause: 403 Call cannot be served here

But there's also a variant where the number is truncated at a space, generating this error message:

No known route to target: <sip:[email protected]:5060>

The number in this case was sent by Outlook as +46 47740160. The space character in this case is probably not ASCII32, but something different. I could confirm that the space is added automatically by Outlook when I type in a number with a country code formatted with the + prefix. (And of course this space is impossible to delete manually, in wellknown Microsoft fashion.)

An Outlook problem really, rather than a 3CX one. But will have to be solved in order for international numbers to be handled correctly. Perhaps not all that difficult if it can be done by a positive list of allowed characters in strings (0-9 and the plus sign, nothing else).