You may have missed the post, but the providers that were broken weren't explicitly named. However, the difference between those that were broken and those that weren't was explained.
If you used a rule like this X_InboundCallRoute -> {>[Your Account User ID]:ph} (AKA as the "Oleg method" to stop SIP scanners) then the contents of [Your Account User ID] was the potential culprit. This was exasperated by the fact that the OBiTALK service, if used, pushed this syntax to your OBi. If you had configured your SPs manually (didn't use OBiTALK), and didn't use the Oleg method, you were fine.
If your provider used your phone number for the contents of [Your Account User ID] then it continued to work. If your provider used anything other than your phone number there, such as 1777xxxxxxx for Callcentric, then it was broken in some circumstances.
For me, calls dialed to Callcentric DIDs failed to connect. But for calls to an IPKall DID that forwarded to the OBi provisioned Callcentric SIP URI worked. I do not understand why calling a DID failed and calling a SIP URI worked though. I'd like to have that explained.
The current status now is that OBiTalk no longer pushes {>[Your Account User ID] to your X_InboundCallRoute. Only the bare 'ph' is used. If want protection from SIP scanners, and you actually need this protection, then you have to manually enable the new X_EnforceRequestUserID feature.
I hope this clears it up for you. And if anything I said is not correct, I welcome corrections.