Hi,
Before I get into this issue I just want to let you know that all routing works as intended.
I have two trunks setup. Trunk-A and Trunk-B.
I also have two DIDs. DID-A and DID-B.
The inbound calls work as intended and reach the desired destinations.
Call Flow:
DID-A --> Trunk-A --> routes to correct destination.
DID-B --> Trunk-B --> routes to correct destination.
What I have noticed though is that my log file shows that:
DID-A --> Trunk-B --> but still goes to correct destination for DID-A.
and so too does,
DID-B --> Trunk-A --> bust still goes to correct destination for DID-B.
If I disable Trunk-A then DID-A fails, same for Trunk-B (DID-B fails).
Is there any insight that you can provide on this?
If the trunks are with different providers, or different servers on the same provider, you shouldn’t be seeing this problem; post details and we can troubleshoot further.
With multiple trunks registering to the same server, chan_sip cannot distinguish them; you should be using pjsip trunks and have Send Line in Registration set to Yes. If it’s still not working, it is possible that the provider is stripping off the line parameter. A SIP trace will show whether this is the case.
If for some reason you can’t distinguish the trunks, there are usually good workarounds. Please provide details as to why are you using multiple trunks, and why you want to distinguish them (billing to different departments, want to limit the number of concurrent calls, etc.)
If FreePBX had a way to send multiple registrations to the same provider it would not be necessary to set up more than one trunk pointing to the same ITSP.
If we assume that the two trunks are from the same provider (which your scenario implies), your operation makes perfect sense.
Did-A is processed at the remote end to come to you via the registration for Trunk-A, but is delivered through which trunk is actually available at the provider end. If you disable Trunk-A, you disable sending the call at the ITSP end and the call fails. Same with Did-B. FreePBX (and the underlying Asterisk) will gladly accept the call on any inbound trunk and process into the Inbound Route “pipeline” and get handled.
From what you’re describing, the system seems to be operating precisely the way you set it up to work. Having said that, I’m not sure I see the problem you are actually having.
Thank you all for replying.
Stewart1, you are spot on! I am using chan_sip as that is all the provider can offer so your explanation satifies my query.
The provider offers SIP. The SIP they offer is almost certainly not implemented by chan_sip at their end, I don’t see how they can offer it at your end.
There are one or two things where chan_pjsip is missing features, but the main provider problem is providers that can’t be bothered to test with current technology. You will almost certainly find their recommended chan_sip contain obsolete parameter names and poor choices of setting, as well.
