Hello,
I am trying to configure two sip trunks of the same VoIP provider. Each trunk has its geographic phone number.
In freepbx I configured the two trunks and two inbound routes to manage differently the calls that arrive at the telephone numbers of each trunk. However, I do not understand why independently by dialed number, the call always comes on the same trunk. All this should determine the same DID; however, although the call arriving at the same trunk, the DID varies as expected, and the routing is carried out correctly. Why? Here are the configurations.
Make a test call from your mobile to each of your numbers.
Then, go to Reports -> CDR Reports and click Search. Look at what appears in the DID column for each call. If they are different, set DID Number for each Inbound route to exactly what showed in the CDR. Retest.
If the DID column is the same for both calls, try replacing context=from-sip-external
with context=from-pstn-toheader
for both trunks, then make two new test calls and look at the CDRs again.
Hi @Stewart1,
do you refer to outgoing section? I before to write this post I put in the section:
But my problem was always them same. In the CDR I have correctly the DID and in fact the incoming call follows the correct route. But I don’t understand why for all calls for both numbers, trunk used is always the same.
Anyway I saw that topic was moved in “Provider” section, so I’ll try to dive the problem in that section or with my provider.
Thank you very much for your help! If you have any further suggestions, they would be very appreciated.
It is probably because they are coming from the same originating IP and the trunk is matching that IP. Probably for your particular provider, one trunk is enough and you just need to create the two inbound routes to direct each DID to the desired destination.
codabat, this is the expected behavior with multiple chan_sip trunks to the same provider. It is harmless. As long as you set up inbound routes for each number you should have no problem.
The typical FreePBX user doesn’t care which trunk a call arrives on, as noted above you filter by DID. But if you do, there is a line parameter for PJSIP trunks that is used for this: How to implement the PJSIP "Line" feature
Hi @arielgrin, @billsimon, @lgaetz,
Sorry if I can only answer you now.
I will deepen your considerations.
The question is that statistically all inbound calls would always result from only one trunk. I am wrong?
I now reflect on your precious advice and update you.
Sorry again for the delay with which I replied and thanked you.
See you soon
Hi @arielgrin ,
Suppose that each number has a connected service, how can I know which service generates the most incoming traffic?
Forgive me if the consideration or question is a bit stupid; it is probably still due to my poor knowledge of the whole ecosystem. Not entirely related, I also noticed that the CDR statistics are a bit tricky. In fact, in the case of an answered call, there is no trace of the ringing time, but I get an “ANSWERED” record remains, the total time of the call is the sum of the ringing time and the conversation time. Also, in this case, probably my considerations could be wrong for still poor knowledge of the whole system.
Thanks a lot, again!
What do you mean by “each number has a connected service”?
In VoIP, the traditional concept of one line per number does not apply anymore, at least if you are using multichannel trunks.
Hi @arielgrin,
Yes, I see. In my case I need to have distinct trunks that have distinct numbers.
But if I receive a call, for example on the second trunk, it is however intercepted by the inbound route dedicated to trunk number 1. I hope I have explained myself.
Thanks a lot.
That is not because of the trunks, that is because your inbound routes are either misconfigured or the DID info sent by your provider is not in the place it is supposed to be so you might need to check either the inbound routes or the context you are using.
One special context that you can try, after making sure the problem is not with the inbound routes themselves, is the from-pstn-to-header. This context is able to extract the DID when it is not coming in the supposed way.
