Some users not obeying CsCallingLineIdentity setting

[Justin Kingston]

In the midst of a PBX migration to SfB Online (pure online deployment with CloudPBX); running into an odd issue;

some users (for whatever reason it seems specific to a single site currently) are not obeying outbound caller ID as defined by the CallingLineIdentity policy.  Same policy (using a servicenumber substitution) is applied to approximately 80 users; 4 so far are still displaying their LineURI regardless of what CID policy is applied to the user.  

I've created new policies for this site, those make no difference; I've applied CallingLineIdentity policies from other sites to these users (known good, in use policies), with no affect as well.

[#2]

@Marcel Korbee

You got further than I ever did; I gave up on 365 support and tried leveraging Skype for Business through Twitter; was eventually led by them to start yet another thread here:

https://answers.microsoft.com/en-us/msoffice/forum/msoffice_sfb-mso_other-mso_o365b/skype-phone-syst...

If I'm reading your ticket reply correctly, are they basically pointing the finger at everyone else?  Who exactly do they expect you to call at a 3rd party carrier, as a non-customer, to have them implement a protocol?  The best thing MS could do it at this point is give a clear explanation and set expectations of the featureset if they're refusing to acknowledge an issue (assuming there is one).

Were you able to catch a user in the act?  Any time we get a report and scramble a tech to a user that's exhibiting, we've yet to capture it in Tracing as it magically starts working again.

[#3]

@Justin Kingston I now asked them to escalate this issue, we can not accept this (our customers will not accept). I cannot call all telco providers in the world to fix this issue. And also think Microsoft should do more.

Not sure what you mean with your last sentence? I am able to replicate the issue over and over again, mainly to mobile\cellphone networks.

[#4]

Really don't believe they give me this answer:

In order we to provide you with that answer, the problem has already been communicated within Microsoft, and our end, everything that was needed to be done is already implemented.

Everything else depends on the Carriers, and in order to avoid the issue you should be communicating the issue with them.

We cannot influence are all the carriers going to use that feature, from our side the CLIP is sent however the carrier doesn't have that feature implemented as you can see by the investigate by us calls.

This e-mail can be used as an official Microsoft statement, and you can go ahead and request from the carrier to check the issue.

At this point there is nothing else that can be performed by our side as the issue has been allocated within the carriers.

Thank you in advance!

[#5]

Not sure what you mean with your last sentence? I am able to replicate the issue over and over again, mainly to mobile\cellphone networks.

---

@Marcel Korbee wrote:

Not sure what you mean with your last sentence? I am able to replicate the issue over and over again, mainly to mobile\cellphone networks.

---

Ah, that's different than what we're seeing; most users are fine, but sporadically (and we can't replicate generally) it swaps Service Number for LineURI as far as what's broadcast to the other side.   By the time we can get a tech involved to pull Tracing, it's magically fine, and shifted to another user.  Of course, users don't know what they're broadcasting, and call recipients don't always know what to expect to see, so we're assuming this is mostly going un-reported in our case.