11-01-2017 10:38 AM
11-01-2017 10:38 AM
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.
11-01-2017 10:47 AM - edited 11-01-2017 10:47 AM
We had this exact problem as well, and could only get it resolved with a support ticket.
Were these numbers ported in? (My speculation is that this only occurs on ported numbers.)
FYI: One huge issue we ran into was ~48 hours after setting a (non-working) CsCallingLineIdentity policy -- 100% of outbound calls were rejected (until we removed the CsCallingLineIdentity).
11-01-2017 11:08 AM
Service number was ported in, TNs assigned to the problem users (that I know of) are MS-native TNs.
Our other 16 sites have ported-in Service numbers with operational CID policies though, nothing different on this run than any others. I'll get a ticket going after some larger pressing issues get addressed.
11-06-2017 08:01 AM
@Nicholas Semenkovich Still waiting to get this ticket in, but curious if the fix was tenant-wide or just specific to those affected users?
11-06-2017 06:25 PM
I think it was actually number (DID) specific (we'd applied the CID policy tenant-wide).
11-07-2017 09:29 AM
We are experience this as well. Currently have a ticket open #6721919 and are awaiting a response/escalation.
Did anyone find a resolution?
11-07-2017 09:39 AM
11-07-2017 01:51 PM
Can you share your case number? We've spent another hour working on this with no resolution yet.
11-07-2017 03:24 PM
Our case was #6477472 (resolved only with escalation to the Skype for Business team)
11-08-2017 06:28 AM
Having the same issue but only when connecting to CellPhone numbers.... so calling to another landline works, but calling to a Cell phone number (+316********) shows the users LineUri.
11-09-2017 07:49 AM
We still have no resolution to this issue and it's been over 24 hours since we've received an update.
11-14-2017 09:12 AM
Our service has now regressed, and we've lost Outbound Caller ID (even though we haven't touched our CsCallingLineIdentity policy and it was working fine for a few weeks).
11-14-2017 09:14 AM
It's been several days since I've had an update from Microsoft. Their last statement to me was that this had been escalated to development but could not give me an ETA on it's priority or it's lead time.
11-14-2017 09:27 AM
Our original ticket was useless; technician sent me info for the line port team (email@example.com) who rightly had no idea why I was sent there; opened a new ticket this morning referencing the tickets called out here, as well as this actual thread.
11-17-2017 03:44 AM
Trying to keep this thread up-to-date; we originally had at least 10 staff that we knew of that were affected (i.e. despite having a CallingLineIdenity policy applied specifying Service number for outbound CID, they were still displaying their LineURI). After some back and forth with 365 Support (sent in Tracing folders after a PSTN call), they hadn't made much in the way of headway, but most of the affected users fixed themselves.... for the most part.
We have one user (that we know of, no one else is willing to test this far through things) that has called multiple people to test, on multiple cellular carriers, with mixed results. Originally, AT&T Wireless subscribers were seeing his LineURI, while Verizon Wireless was seeing the Service number. I applied a different CID policy to this user, then flipped him back to production, and now he's seeing the following mix with 5 people he's testing against:
AT&T Customer #1- Service Number (as defined by policy, and correct)
AT&T Customer #2 - Service Number
VZW Customer #1 - LineURI
VZW Customer #2 - Service Number
VZW Customer #3 - LineURI
He then tested against a 4th VZW Customer, with the first call showing the Service Number, then a subsequent test call to the 4th VZW line showed LineURI.
To be completely honest, I'm running into some communications issues with 365 support, and I don't feel like they have a grasp on this particular (US Domestic PSTN) setup, so I'm hoping someone else (or someone from the SfB team?) has some more input/direction on this, because I'm at a bit of a loss at this point, and have a user base that's rightfully concerned about how calls are being presented to clients.
11-20-2017 12:25 AM
Same issues on a Dutch PSTN Calling and French PSTN Calling. Some carriers are working, some are not. However when setting up the Anonymous CallingIdentity it seems to work with every carrier.
Also sent tracing logs, calling times etc... but no results so far.
It's starting to get frustrating.
11-20-2017 06:08 AM
Yeah; last note from 365 support was to "contact carrier ATT"; there's zero chance of getting anywhere with that, and ATT is displaying the number they receive from MS; building a full table with this one user, but they did more testing last week, and it's basically a crapshoot on all carriers which number gets displayed. Sometimes it's the LineURI, sometimes it's the Service number per policy.
12-06-2017 03:26 PM
@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.
12-13-2017 03:57 AM
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.
12-27-2017 12:11 AM
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.