PSTN calls route right, VoIP to VoIP don't.

[dandenson]

This one is driving me nuts.

If I call in from my cell phone, Inbound routes works as expected, call drops into queue.

If I call from another 3CX system that is using the same carrier (voip innovations) then instead of dropping into the queue, it just rings to first extension.

I've changed the operator extension in /settings/general already.

I've scoured the queue and the trunks and extension 000 isn't there anywhere.

Call log shows my caller id straight to the 000 extension.

This is driving me crazy, it shouldn't be doing this.

 

[cobaltit]

Need to turn on verbose logging and see why.

 

[cobaltit]

One of the things I would look for is caller-id. Many times on-net calls and off-net display differently.

 

[dandenson]

ok, so I've sngrepped this out and the call is coming in with the appropriate to address.

I have 5 trunks to handle the main VI IP and the 4 supplemental addresses. I have 2 DIDs configured on the first trunk. This usually works.

So what's happening is that PSTN calls are going to the first trunk which is VI's primary Origination trunk. Calls from the other 3CX box are being delivered to the second trunk.

For some reason, the inbound routing rules are just ignored when a call hits the second trunk. Rules apply to the first trunk though, if I call either DID it hits the inbound rules and works even if I select a different default rule in the trunk.

If I remove that trunk, I can make the calls. If I leave the trunk but put the first trunk's IP address in (thus removing the address the other PBX hits) it works.

Ultimately, Inbound routing ISN'T working and is being overwritten by the trunk config. For example, if I put both DIDs on the first trunk and put a fake one in the second trunk, that call to the second trunk's IP still routes how that trunk is configured and ignores the inbound rules.

VI basically has 5 origination services for redundance and 4 term servers. It looks like I can get around this by just putting one origination server in but i'll lose access to their redundancy.

 

[cobaltit]

Ahh. And this is why you should use supported providers.... So there's two possible explanations:

• One, you are missing a subtle difference between the calls from off-net vs the calls from on-net
• Otherwise you'll need to play with the settings on the 'Inbound Parameters' tab of each trunk. The bottom section labeled 'Call Source Identification'

Configure this option only when the SIP Trunk is IP based (peering), or does not support automatic inbound call detection. If you have multiple trunks from the same vendor or issues with incoming calls, you might need to toggle this option (on/off) and see what configuration works best for this SIP Trunk

 

[dandenson]

@cobaltit tell me a supported provider that's in VoIP Innovation's price range...

That's where I'm stuck, my price would double if I switched.

 

[dandenson]

ok, so changing GWHostPort to OutHostPort makes this behave with 2 VI trunks. I guess this is because it's not using the IP (provider host) as a matcher anymore?

 

[cobaltit]

@cobaltit tell me a supported provider that's in VoIP Innovation's price range...

That's where I'm stuck, my price would double if I switched.

So you're saying your time is free? Or your sanity? Because in your own words this was driving you crazy. You need to factor those things in when you are calculating costs. I learned about true costs long ago.

 

[dandenson]

@cobaltit I have to resolve this once... I have a few dozen other systems and no issues with their use case.

 

[cobaltit]

Who knows how long this would have been an issue until someone posted resolution? Yes this is one issue resolved which is great until the next issue. That's the point of using a supported provider is it works now, and for those that are setup for auto-testing (we are) you know it will work with the next version either as-is or with an updated template. But as you said it's financially beneficial to you to keep using it so keep using it.