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]

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).

[#3]

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.

[#4]

@Nicholas Semenkovich Still waiting to get this ticket in, but curious if the fix was tenant-wide or just specific to those affected users?

[#5]

I think it was actually number (DID) specific (we'd applied the CID policy tenant-wide).

[#6]

We are experience this as well.  Currently have a ticket open #6721919 and are awaiting a response/escalation.

Did anyone find a resolution?

[#7]

@Jonas Vachal Just got a technician assigned to our ticket last night, trying to coordinate at this point.

@Nicholas Semenkovich We've got 20 sites in play, so we're not doing anything CID-related at the tenant level, so curious how this plays out.

[#8]

Can you share your case number?  We've spent another hour working on this with no resolution yet.

[#9]

Our case was #6477472  (resolved only with escalation to the Skype for Business team)

[#10]

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]

We still have no resolution to this issue and it's been over 24 hours since we've received an update.

[#12]

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).

[#13]

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.

[#14]

Our original ticket was useless; technician sent me info for the line port team (ptn@microsoft.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.

[#15]

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.

[#16]

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.

[#17]

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.

[#18]

@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.

[#19]

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.

[#20]

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.