I’ve had DIDs into my system from multiple providers for years. I recently moved the last of my land-lines into SipStation and ported the number. Following the port however, none of my inbound routes appear to be working any longer.
I’m assuming it has something to do with caller-id but given that all the ports worked in the past, not just the ones on that one DID, is that a reasonable conclusion?
And if indeed that’s the issue, then I guess I need to ask for suggestions on how to get caller ID on those Sipstation DIDs.
Does SIPStation present your DIDs to you in a different format? Are they using 10-digits, 11-digits, E.164? Are they sending all calls to a “pilot number” and have the real destination in the To header?
Not all providers send calls the same way and the Inbound Routes need to match how those DIDs are being presented. This should be covered in the SIPStation docs.
Checking. It looks like some of the caller ID is working. I think the problem is with my understanding of the path taken. There seem to be more things effecting caller ID than I’d realized and they don’t play nice together.
I had set up OpenCNAM and Internalphonebook as my CIDLookup Source. But I’d also set up CallerID Superfecta. In looking at the documentation for OpenCNAM, it appears that OpenCNAM won’t work if Superfect is enabled. Indeed running a Debug/Test Run Scheme results in an OpenCNAM failure claiming it was run without credentials in spite of having proper credentials in the CIDLookup Source.
If I enable “Trunk Provided”, which I had thought would bring the CID from SipStation, I get the unexpected result where it sets the caller ID to “CID Superfecta!” which seems to be worse than no result at all since it’s 100% misleading. Given the Sangoma control over SipStation I had expected a more seamless integration.
Adding to the confusion (mine) is that the inbound routes also have two callerID settings under their “other” tab. According to OpenCNAM, each inbound route must have it’s source changed to them and the Superfecta Lookup turned OFF. I can understand why you’d want to do that if you wanted them to be the exclusive callerID source. And maybe because they don’t seem to play well with others, that might be they only way THEY work.
As I’m new to callerID sources, having used my landline for that info in the past, I’m not sure I want to be married to OpenCNAM if they aren’t going to play well. I’m happy with just one source, as long as it’s a source that’s going to provide good results. I had hoped that would be SipStation for simplicity but that doesn’t seem to hold true so far.
Unless you are doing something unusual, the Caller ID has nothing to do with your inbound routes.
Normally you leave the CID blank and it results in “Any”
You can see here that I do have one populated. This was a service tech not calling into the normal tech line like he was supposed to. Instead of management dealing with it, they had me force a call to the main St Louis number from his cell phone to the service tech line.
I did notice the 1 in front of some of the numbers, but no all, even from the same trunk. I guess that means entering all the inbound rules twice.
I’m guessing that the Superfecta CallerID will generally find more results than using just the CallerID Lookup sources since they appear to be exclusive of each other. Is it just hit-or-miss as to which provider of the callerID does the best job?
Again, I’d planned to use SipStation since it’s my provider and it’s Sangoma, but it doesn’t seem to work since the results are useless:
Looking for Trunk Provided Caller ID …
found value of CID Superfecta! …
determined good.
‘CID Superfecta!’
result took 0.0005 seconds.
That is not how anything works. Your phone numbers can come in exactly one way. The DID will not come in with a 1 sometimes and sometimes not.
Stop talking about CID. It has nothing to do with your inbound routes working or not working.
If you hare having CID issues, that is a totally different thing that you should resolve separately from ensuring your inbound calls are hitting the correct routes that they are supposed to.
Not on the DID. The CallerID sometimes has a 1, and sometimes not, but only when the come in on different DIDs.
I think I’ve solved the inbound routing problem by adding the 1 to the CallerID entries so that it finds a route regardless of which DID it comes in on.
You are right that the routing issue isn’t the same as the callerID issue. I thought it was when I started this thread because the source for my callerID had been the landline DID which I’d ported to VOIP. I should separate the CallerID questions into a new thread.
