I have a very strange issue which I can’t solve. I want to use the Privacy and Call Screening capabilities of FreePBX to enhance my main PBX. Therefore I need to “loop” FreePBX in like this:
An incoming call from the outside rings at an extension (7981) of my main PBX. FreePBX (10.32.4.5) has a trunk configured to register to this extension. The inbound routing of this trunk points to endpoint 81.
FreePBX will now process Privacy and Call Screening. As soon as endpoint 81 finally rings, this “filtered call” goes back to my main PBX. For this, my main PBX (10.32.4.1) registers with one of its trunks back to the endpoint 81 of FreePBX.
But here comes the strange part:
The FreePBX trunk registers fine at my main PBX
But for no reason, FreePBX responds with a 404 to the registration requests of my main PBX for endpoint 81
If I deactivate the trunk in FreePBX, my main PBS can register fine to the endpoint 81 of FreePBX.
Somehow having a trunk active to the same device which also registers (with a different account) to an endpoint of FreePBX seems to completely worry FreePBX. I’ve checked multiple times that the SIP usernames of the directions are definitely different (7981 for FreePBX → MainPBX and 81 for MainPBX → FreePBX) and I still have no clue why FreePBX refuses with a 404 as soon as the trunk is active.
Assuming pjsip extension and trunk, try setting Authentication for the trunk to Both and Match Inbound Authentication to Auth Username. Unfortunately, this requires the main PBX to respond to a challenge on a call to what it thinks is an extension. If it won’t, there are two possible approaches:
The lazy way – use chan_sip for the extension or trunk (but not both), so they don’t conflict. This will likely cause trouble when chan_sip is removed from new Asterisk versions.
Provide details on the main PBX (make/model/version) and with luck, someone here will be familiar with it and know of a compatible configuration.
Is this a bug or more a concept issue with FreePBX? Just trying to find an explanation for this unexpected behavior. It’s clearly the FreePBX which behaves strange (returning 404 to a valid registration request if the trunk is active), not the main PBX (Auerswald COMtrexx Flex)
This is pretty complicated; any PBX has to ‘identify’ which endpoint is associated with a given request, which is typically done by IP address. It is unusual for a PBX to have both extensions and trunks at the same remote IP (the usual case is a gateway with both FXS and FXO ports), typically handled by having the trunk configured Registration Receive, but that’s not possible in your case because the COMtrexx side is an extension. Your specific issue is caused by the REGISTER for the extension ‘matching’ the trunk (by its IP address).
Just curious, what goes wrong with the trunk settings I suggested?
I assume that you are using UDP transport. Does the COMtrexx support TCP and/or TLS? If so, using different transports for extension and trunk should be a suitable workaround.
Another approach, which unfortunately requires more complex configuration at both ends, is to just have one trunk between the two systems. Calls to 7981 would be sent on the trunk, e.g. by having call forwarding set on that extension, and successfully filtered calls would be sent back over the same trunk, which the COMtrexx would route to a different extension. (In your original system, I assume that you also had to use different extensions, or had some other way to avoid a loop.)
I think that challenge thing won’t work, and I can’t find a setting for chan_sip in FreePBX … however, using an obsolete library is also not the greatest solution.
Yes, the PBX supports TCP and UDP … I’ll try to separate trunks and extensions by different protocols and see if that helps.
One trunk for all won’t work. I have the “outside” lines config which can be a SIP trunk or “normal” VoIP accounts, but I can’t ring on one of these if a call comes in on another “outside” connection. And I can’t register the FreePBX in parallel to the outside lines as this is a SIP trunk (which only accepts one endpoint on my side).
And on the endpoints side I can’t do a “CLIP-no-screening”, so if the FreePBX routes the call back the initial caller ID won’t be handed to the main PBX. It’s all not that easy as it looks.
The perfect solution would be a Call Screening software which registers like a SIP phone to the PBX, takes incoming calls, processes the identification / screening and then simply SIP-transfers it to the final destination depending on the outcome of the screening. But this does not seem to exist on this planet.