Forum Discussion
Some users not obeying CsCallingLineIdentity setting
Jonas Vachal did your ticket go anywhere? We've basically given up on our original ticket as support was refusing to work with us until we sent them even more Tracing logs (when this doesn't seem to be a client-side issue, and forcing users to call multiple outside parties for testing is hard to coordinate across the country). Just had a user yesterday broadcast a number to a client that isn't even in our tenant (or in an area code we have any numbers in) twice. Same user calls my cell, works as expected.
Still in the progress of getting an answer, last update:
Dear Mr. Korbee,
I'm contacting you regarding service request #617110992042126.
My name is Rositsa and I will be assisting my colleague Yordanka with your service request as she will not be available for a while.
As you are aware your case is taken to a higher level support engineers in order to find a resolution. I have received a request from them to collect again a new set of logs after reproducing the working and non-working scenarios, from the last 48 hours.
Please perform the steps and provide the requested logs. Also include the 'From' and 'To' numbers, date/time, carrier at destination and any additional details.
If you have any questions or concerns, please let me know.
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.
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!
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.
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-systempstn-users-not-obeying/edbff52c-be8a-49bb-aee5-97b85c4f6476?tm=1513197832630&auth=1
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.
After sending all the traces and logfiles, this is the "answer" I received:
Thank you for the cooperation regarding SR 617110992042126.
I apologize for the late response, however the update that we got from operations is as it follows:
"The generic number is untouched by COLT IMS and remains as it's
in the original invite
Please take in account that In case CLIP it is not working, destination carrier is displaying CgPN (PAI) instead of GN (FROM).
Unfortunately we cannot guarantee that third party providers (out of Colt) support Generic Number, hence we cannot guarantee that CLIP No Screening feature would work always.
"
Since we do not have a contractual agreement with the last mile (terminating) Carriers, we cannot force them to use the CLIP No Screening feature, so we kindly ask our customer to engage the Carrier and ask for this feature to be implemented.
This feature depends on every provider so if they don't have the feature implemented you won't be able to use it with all the providers.
I would like to ask for your confirmation to archive the ticket or in contrary I will be trying to reach you on 25/12.