Problem with Jabber Click to Call on Numbers with Spaces

[juliuspiv]

When I have a phone number that contains spaces, for example +1 123 456 7890, click-to-call displays the following:

Clicking yes results in an attempted call 12012320456207890. (Blue = the real phone number to dial; Red = junk)

Although the percent symbol is rightly stripped, there's no validation for encoded spaces (%20) which leaves behind the hex code for space (20) which is then interpreted as part of the number.

On the phone

In Jabber

I'm using Jabber 11.8.2.50390 on Windows 10 v1607, but other affected versions appear to be 11.6.0.35037, 11.7.1.46916 & 11.8.0.49608; there may be others as well.

Can anyone else reproduce?

Am trying to narrow the scope of the issue:

• is this a client bug?
• is this a configurable client setting?
• is this a configurable server-side setting?
• is this an issue with the application that's passing the number on to Jabber?
• is this something else entirely?

[Jaime Valencia]

https://supportforums.cisco.com/discussion/13094481/removing-spaces-jabber-click-call-dial-string

I can't recall if it was here at CSC or some other site, but I saw someone created a script to remove those spaces and normalize the number, that would be the only solution.

[juliuspiv]

Thanks for the reply Jaime Valencia!

I did see that link prior to posting but there's a few pieces missing to my puzzle.

When we initially rolled out Jabber, we ran a home grown script to 'normalize' the numbers of the contacts in our user's mailboxes to ensure Jabber would handle them correctly.  Fortunately, our signatures and phone numbers on corporate user facing fonts (intranet pages, corporate website etc.) were already setup properly so no work was required there.  Basically, all corporate numbers are fine.

Our users encounter the issue when:

• Corporate users create malformed numbers: This is purely a training issue and we're addressing it as best we can.
• Non-corporate entities display 'malformed' numbers: This could be on websites we visit, emails we receive, documents we receive or pull down from an external website and so on.  This is the real problem because we have no control here.

We're on Windows 10 and I can reproduce the problem by creating a new Sticky Note, and enabling Cortana integration and adding a number formatted incorrectly like +1 123 456 789.  When clicking the number you'll have the option to click 'call' which will hand it off to Jabber.
Alternatively, in Word or Outlook create a new hyperlink (CTRL+K) for the phone number using the tel prefix, for example: tel://+1 123 456 7890

I've got some questions:

1. Can you (or anyone else) reproduce this behavior?
2. Is this expected behavior, even if it is undesirable?
3. Can you explain a bit more about what these scripts are, where they're running from, how they're invoked?

I'll forewarn you, I'm not a CUCM admin.  I'm responsible for application packaging & configuration etc. and this was tagged as a Jabber client configuration issue.  But I've not been able to find anything that suggests it is (or isn't) nor have I found evidence that I can influence this behavior.

[#4]

Hello,

I was able to recreate this and the behavior is expected. According to RFC 3966, TEL URI must not have spaces. Please see the screenshot below. For more information on this please see:  https://tools.ietf.org/html/rfc3966#page-7

The reason you have the %20 in place of the spaces is because "%20" is the percent-encoding for the binary octet "00100000" (ABNF: %x20), which in US-ASCII corresponds to the space character (SP). This is explained further in RFC 3986 for URI Generic Syntax see: https://tools.ietf.org/html/rfc3986#page-12

The way to resolve this would be to remove the spaces from the Hyperlink.

[juliuspiv]

Thanks for the reply vrolands!

1. I appreciate the confirmation that, while undesirable, this is expected behavior.
   
   
2. I hear you on that 'textbook response' - it's just not easy to go to a customer or client and say "Hey, you're not confirming to RFC 3966 so your number links are broken."
   
   
3. So just to be clear, because we're the recipients of malformed numbers (be it emails, documents, websites etc.), we're just up a creek, correct?
   
   

I accept that it is what it is, but candidly, why doesn't Cisco add some logic so that 'it just works'?  Jabber is already stripping out the %, so why not do some simple validation to strip %20 from the string?  (Sort of a rhetorical question - I don't expect an answer here.)

Circling back to a previous question: What sort of scripts was Jaime Valencia referring to above?  Was he thinking we'd need to normalize numbers in our user address books/contact lists?  Or was this referencing something else?  If its the latter: Can you explain a bit more about what these scripts are, where they're running from, how they're invoked?

Otherwise I suppose we can consider this settled in full.

[#6]

Hello juliuspiv,

From your message, there are a few more things that can do here;

1.While you see this with MS Sticky notes, other MS software/applications and on certain browsers, you might not see this with other MS applications, or browsers which means it is software/platform dependent. You can reach out to the support team for that software and ask them to change the way to process spaced in "tel://" hyperlinks.

2.The application that sends out the incorrect "tel://" hyperlinks to you does not seem to be RFC complaint, so it might be a misconfigured or a made be a bug either way the Application Admin will need to be notified.

3.You might also want to eventually reach out to your Cisco Account team to help you file an Enhancement request with the Jabber Product team to see if it is possible to change the way Jabber processes HTML requests, specifically "tel://" with "%20" in the received request.