Number Display Formatting in MOC

Something I’ve been working on lately was a Microsoft case involving inconsistent formatting of numbers. It turns out that MOC actually displays numbers for users in your contact list differently the first time you sign in (i.e. No GalContacts.db exists yet) compared to subsequent sign-ins. This isn’t a normalization problem because the underlying Tel URI is always correct, but actually just a display issue in how the number is presented within MOC.

Apparently the first time you sign in because there is a slight delay in the ABS download (even if you force it immediately) MOC has nothing to go on for contact card information other than the presence XML. If you view the presence XML you’ll see at first it doesn’t actually carry the display format, just the Tel URI, tel:+12345678901 so MOC has to use its own logic to figure out how to display that number. The format it chooses is +1 (234) 567-8901 and there is no way to change that. Not by disabling normalization, using only built-in rules, or by using only company-specific rules – the result is always the same and that display format is hard coded into MOC.

After a lot of back and forth support gave me the ol’ “It’s by design” answer and ended it there. I was a little disappointed because I think MOC should be able to apply the rules immediately after receiving them, but it seems to take another sign-in to take effect. Let me show you what I mean:

Active Directory Fields:
ad

Company Phone Number Normalization file:
normalization

Address Book File Dump:
absdump

First sign-in uses MOC hard-coded logic:
1st

Subsequent sign-ins display the number as formatted in Active Directory:
2nd

Odd, right? Normally this wouldn’t be a problem, but the reason this popped up in the first place was because CUCIMOC was in use and it caches numbers you’ve called previously. So if a user signed in for the first time and dialed another user, CUCIMOC would show you calling with a +1. Even after signing out and back in, CUCIMOC would keep showing the +1 next time you dialed that user because it cached the original number you called, which had the +1. And now any new users you call would not have a +1, creating an ugly inconsistency. We were able to take care of the actual dialing with rules in Call Manager, but it’s just undesirable for end users to see this inconsistency.

Another gotcha I’ll point out is that MOC also tries to respect the access levels here. What I mean by tries is that as we know if a number is in AD it’s visible to everyone in the organization regardless of access level. Say you have a user’s work and mobile numbers in AD and try to view them from another user who’s assigned the company level in MOC, you’ll see MOC apply its own formatting to the work number only. Assign them to the team level and you’ll see MOC also format the mobile number. Bizarre.

Company Access Level on 1st Sign-In:
company

Team Access Level on 1st Sign-In:
team

There are two workarounds here since Microsoft refuses to acknowledge this behavior as a bug:

  • Format all numbers in AD to the format MOC is going to use on the 1st sign-in. That is, +1 (xxx) xxx-xxxx. Then create a normalization rule in your company file to make sure this gets processed to E.164 by the ABS.
  • When a user is signing in to a new PC for the first time (or you had them delete GalContacts.db), have them sign-in once, sign-out after the address book downloads, and finally sign-in again. MOC will now display the numbers from AD instead of formatting them itself. If a user goes to a new PC they need to repeat this process.

Neither of these are great solutions. The first is probably the best, but aren’t we defeating the entire purpose of normalization here? I should be able to put the numbers in any format I want in AD and normalize them with the ABS . Side note before anyone suggests it: This behavior still happens even if you put the AD fields in E.164 (+12345678901) format. For some organizations changing the formatting of the phone field isn’t an option especially if they have some kind of HR software responsible for syncing phone fields, or other applications dependent on the existing formats.

If you want to duplicate the issue yourself, there is a specific use case to make this happen. Most importantly, the user needs to actually be in your contact list.

  1. Enter your numbers in AD for User A and B.
  2. Ensure the numbers normalize by the ABS.
  3. Sign-in as User A.
  4. Add User B to your contact list.
  5. Sign-in as User B.
  6. Add User A to your contact list.
  7. Sign-out of both accounts.
  8. Delete GalContacts.db and GalContacts.db.idx from both accounts.
  9. Sign-in to User A.
  10. Sign-in to User B.
  11. View User A’s phone numbers from User B’s MOC. You’ll see the MOC internal formatting applied.
  12. Sign-out of User B. (Leave User A signed in)
  13. Sign-in to User B.
  14. View User A’s phone numbers from User B’s MOC. You’ll see the exact format you entered in AD, and for all sign-ins going forward.
  15. You can sign-out of User A, delete GalContacts.db again and sign-in to see the MOC formatting again.

Personally, I think the behavior is wrong and needs to be fixed, but Microsoft says otherwise.

Here

Recent content I've written for you—just for you!— to enjoy while you're here.

There

Quick commentary and links to other sources you'll find interesting. I promise.

Everywhere

Some personal background, links to related projects, and other ways to connect.

Hi there. My name is Tom Pacyk and this is my small home on the web. I love the intersection of design, technology, and communication, which is a combination that led me to a career in sales and marketing roles at places like Zoom and ServiceNow. They're a bit old now, but I also had the opportunity to publish a couple of books along the way.

Portland, Oregon is home for me, my wife Beth, and our three kids, but I'm actually a Midwestern transplant—I grew up in the Chicago suburbs and went to school at Purdue and Illinois. When I find some free time I'm probably going to concerts, rooting for the Portland Timbers, or working on my Sunshine Burn Photography project.