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:
Can you (or anyone else) reproduce this behavior?
Is this expected behavior, even if it is undesirable?
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.
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.
I appreciate the confirmation that, while undesirable, this is expected behavior.
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."
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.
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.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...