Hello,
It’s a while that I am struggling with a problem and I was not able to find the solution to make things work properly.
My situation is the following: I have two FreePBX servers, one in the HQ and one in the BO.
The two PBXs are connected between them with a IAX2 Trunk.
In the HQ, the extensions use numbers from 200 to 299
In the BO, the extensions use the same range, so 200-299.
When someone in the HQ wants to call the BO, it calls the 59 2XX.
On HQ site, there is a specific outbound route that matches the 59 prefix and sends the request to the IAX2 Trunk. This outbound route has a intra-company flag.
Then the request arrives on BO site, where I have a specific inbound route, that routes the call to the desired extension.
Everything works well, no problem in the signaling or audio, but I am not able to display the correct callerID on the called device.
The BO PBX sets the CallerID with the name of the extension on BO side, and overrides what it received from the IAX trunk, so the correct CallerID.
I have the same problem from BO to HQ.
Does a solution exist without changing the extensions number on BO side?
Any suggestion is really appreciated.
Thank you
Lorenzo
Usually, if you use a intra-company trunk, you would want to use the from-internal context, which then, you don’t need any inbound route. What does that inbound route do? Is it a single inbound route?
I would set the context for the incoming side of each Trunk to a custom context which adds 59 as the CID prefix, something like:
Or, if for whatever reason you want to use the inbound route instead of all this, you can use the SetCID module to do the same…
That way, the local PBX won’t find any extension in it’s DB with 592XX, so it will maintain the original caller ID and this allows the callee to later redial the caller from their phone just fine.
Yes, it’s a single inbound route like DID: _2XX with destination a custom-destionation that simply performs a Goto to from-did-direct. I am not sure it was correct, any suggestion is appreciated!
Reading your answer, I understood that maybe it’s not necessary!
I tried with SetCID but it didn’t work as expected! But your answer opened my eyes, probably my idea of removing prefix on the caller PBX side, is not the best way to achieve the comunications between the HQ and the BO.
I give a try with your suggestions and I’ll let you know if any other problem still occurs.
Thank you!
Lorenzo
-- Executing [59267@from-trunk:1] Set("IAX2/TRUNK_MILANO-8445", "__FROM_DID=59267") in new stack
-- Executing [59267@from-trunk:2] NoOp("IAX2/TRUNK_MILANO-8445", "Received an unknown call with DID set to 59267") in new stack
-- Executing [59267@from-trunk:3] Goto("IAX2/TRUNK_MILANO-8445", "s,a2") in new stack
If I try to put this code in the extensions_custom.conf
Still doesn’t work, the call goes through from-trunk without the -custom part.
Could you please give me support to make it works without inbound route?
I tried but it doesn’t seem to work, the inbound call is still routed to the “from-trunk” context.
Here a screenshot of the configuration. Even if I put something in inbound it doesn’t work. Probably I do something wrong.
Yes, it was just a test to distinguish the production routes to the test routes.
Sorry for my ignorance, I am not very used to custom contexts and I don’t understand completely: I won’t use from-trunk-custom anymore as you suggested, but how I can execute the code inside “trunk-cid-prepend”? Is it executed automatically by asterisk or it should be insert somewhere?
Tbh it wasn’t necessary, but only in the test enviroment. So your original code was correct in my opinion
I think that to resolve my problem is enough to be able to route the inbound calls in the correct context, the rest seems to work as you suggested.
Thank you
Yes, I applied the configurations.
I am wondering if the type peer / friend is correct and how I should define the incoming settings
Seems that just the name and the context is not enough to tell asterisk what to do.
Do you have any example of the trunk configuration to share with me?
Can you try to get another log? Because I speculate that there’s a different error now. There’s no way that these calls arrive through this trunk and use the from-trunk context…
I made some tests and now the situation is more clear.
First, I tried with two test environments and everything works like expected.
So, I came back on the production environments and I wasn’t able to make it work.
Since I have 9 IAX trunks, I tried to change all the contexts on all the trunks, and now the call is routed correctly. I guess there is a bug probably, where the iax is not able to recognize the association between host and context? I’ll made a search later to see if other users found it out.
So, I tried to change the trunk from IAX2 to SIP, but now another issue occurs: the XXX extension in the BO has ‘INVITE’ authentication failed answer from the HQ PBX asterisk. I guess it’s a kind of security feature on the SIP protocol, where the extension already exists and has another secret.
The question is: is it correct that the invite arrives on HQ with the INVITE made by XXX extension?
It’s the result of inappropriately using type=friend on the local extensions. type=friend is a union of type=user and type=peer, for SIP, and type=user matches take preference. type=peer is vastly overused in typical SIP configurations, and it does cause this sort of problem.
I don’t know enough about IAX to know whether type=friend has the same meaning there, and therefore whether it also bad practice to use it for IAX.
The typical case where you might still require type=friend on SIP is if multiple extensions share the same IP address, but you will get false matches if the extension number appears in trunk traffic.
Ok thanks for the explaination David.
In the next days I will try the setup with the type=peer changing the trunks from IAX to SIP and I’ll let you know if other problems will appear.
Hello David,
I tried with SIP type=peer but still the PBX reject the invites from the Extension because of the authentication. With Iax this doesn’t happen because the protocol is different.
And even with IAX type=peer, the PBX is not able to recognize which is the inbound trunk, so everytime I have to change all the context of all my trunks.
What I should put in Incoming settings?
Probably I do something wrong.
Anyway @PitzKey, your suggestions were really useful and I resolved the problem about overlapping of the extensions number.
It would be cool understanding why I have those other two problems but for the moment I have my production environment working !
Thank you!
The extensions need to be type=peer. The only time this normally doesn’t work is when you have more than one extension with the same IP address, and I think I already mentioned that caveat.
