Hi,
I’m trying to connect a Lancom Router with a central FreePBX15 System. The Router registers correctly at the central system. Outbound calls work through the pjsip trunk correctly. Inbound Calls are set to go to context from-internal. But they don’t. They end up at context from-sip-external. It seems that the call is not authenticated correctly or the call is not being recognized as a trunk call somehow.
The trace of an inbound invite packet over the trunk shows the authentication line:
The asterisk log always shows WARNING,"Rejecting unknown SIP connection from…
Allow Anonymous Inbound SIP Calls works but is no option!
insecure=port,invite is not possible as it is pjsip
In another post I’ve read that the Match Inbound Authentication should be set to “auth username”, not “standard”. But with “auth username” the trunk inbound registration doesn’t work. So I’ve set it to “username” just to avoid “standard”.
I don’t find a way making inbound calls working as they should. Has anybody got an idea?
Please describe the overall system in more detail. I assume that your use of the word “central” and the username “zuerich” means that the Lancom is in your Zürich office and the FreePBX is at your headquarters in another city. If not, provide details.
Which model Lancom do you have? Other than the trunk to FreePBX, does it have: extensions (SIP phones, softphones, SIP apps, etc.)? SIP trunks to a VoIP provider? ISDN, POTS or other connections to the PSTN?
In addition to the Lancom, do you also have SIP phones or other extensions at the Zürich office registered directly to FreePBX?
Correct. It is not ‘matching’ the trunk’s identification so it’s being treated as anonymous.
This usually applies when you have a device that (on incoming PSTN calls) puts the calling number (caller ID) in the From header (and can’t be configured to use a different header), so identification by username won’t work. And, you also have other devices or sub-devices on the same IP address, so identification by IP won’t work. If this is really your situation, we can debug why auth username authentication isn’t working.
Yes, the headquater is the FreePBX system and the Zürich office Lancom 1781VAW is connected via VPN. There is no NAT between the sites and the headquater site has a LANCOM 7100+, SIP ALG activated. I can also see the trunk registration at the firewall monitor, so there seem to be no forwarding problems.
60 headquater extensions should be able to reach 3 extensions at the Zürich site. There are SNOM and DECT SIP phones mixed.
In the 1781VAWs trunk configuration, I’ve selectet “Link” for the connection (not trunk) as it is an intra company connection. The Lancom describtion says that this mode doesn’t modify the sender on outgoing and the receiver on incoming calls. It keeps the trunks main authentication data when making an outgoing call, so it doesn’t use the extensions authentication data (that would be registration at higher PBX system). For me that seemed to be the best option, the Invite trace showed that. Mode “trunk” in Lancom adds the main number prefix, which is not the goal here.
Match Inbound Authentication
When i set it to “Standard” or “Username” the 1781VAW registers successfully. Connection Headquater -> Zürich is possible then. With “Auth username” registration 1781VAW > HQ is not possible.
The 1781VAW sends the SIP-ID in the FROM field. I’ve selected that in the configuration.
Unless I’m missing something, all calls from the 1781 arrive from 192.168.13.254, and nothing else does, so I would expect identify by IP to work. Depending on details, you may need to set Match (Permit) to 192.168.13.254, and/or set Authentication to Outbound or None. The latter shouldn’t be a security issue, because an attacker would be unable to present a source address of 192.168.13.254 and receive a reply.
However, it appears that there are no trunks connected to the 1781, other than FreePBX. If this is true, and there are no problems setting up the VPN correctly, my inclination would be to simplify things by avoiding the 1781 altogether and simply registering each of the 3 Zürich extensions directly to FreePBX over the VPN. I can think of a couple of downsides: If the Zürich internet goes down, calls between extensions there would fail. I assume that in such a small office that would be unimportant. Also, you would see higher latency on such calls. This could be an issue if a user there makes a three-way call with an outside party and a local extension. If the two local users are within earshot, their voices through the phone will sound like an echo and be more annoying than if the connection were just through the 1781.
If you do have other trunks on the 1781, please explain how they are used.
I agree that the problem is in the match, not the authentication, however I would point out that insecure=port, invite is actually two settings. The port one is rarely needed, except for TCP, and the invite one can be reproduced in chan_pjsip by not specifying any inbound authentication. (I haven’t investigated how chan_pjsip handles mismatched source port numbers.)
Outbound registration is not possible as the LANCOM doesn’t support incoming trunk connections. The LANCOM is not very flexible concerning settings/callrouting.
When setting the authentication to None the calls from Zürich to the headquater WORK , but then the calls from the headquater TO Zürich do not work:
Asterisk reports:
VERBOSE[29344][C-00000cde] pbx.c: Executing [s@func-apply-sipheaders:6] ExecIf(“PJSIP/zuerich-00001c8d”, “1?Set(PJSIP_HEADER(remove,Alert-Info)=)”) in new stack
155[2021-08-03 15:54:17] ERROR[12476] res_pjsip_header_funcs.c: No headers had been previously added to this session.
. (don’t know if this section is important, but the next lines show the problem)
.
.
app_dial.c: Called PJSIP/139@zuerich
165[2021-08-03 15:54:17] VERBOSE[29344][C-00000cde] app_dial.c: Everyone is busy/congested at this time (1:0/0/1)
166[2021-08-03 15:54:17] VERBOSE[29344][C-00000cde] pbx.c: Executing [s@macro-dialout-trunk:28] NoOp(“PJSIP/215-00001c8c”, “Dial failed for some reason with DIALSTATUS = CHANUNAVAIL and HANGUPCAUSE = 1”)
So I’m running into problems with both variants.
I’d need two trunk connections one for outbound (with registration) and one for inbound (without registration, but that seems to be not the elegant way.
Match (Permit): 192.168.13.254/255.255.255.0
does not help when trying it with AND without authentication.
The Zürich office has another (single not trunk) connection to a public SIP Provider, which makes the office reachable under their pstn number (it is a separate number which has nothing to whith the extensions there). The LANCOM call route which matches the internal numbers to the hq works, so this SIP connection is not touched in my test scenario.
I’ve made a test to see why preselected “auth username” in Match Inbound Authentication does not work for establishing the trunk. Traces are taken at the LANCOM
The hq always answers forbidden:
Register (auth username):
I found the solution. The setting “Link” mode in LANCOM was wrong. I had selected that because the LANCOM help said that the senders or receivers are not modified. The Trunk would modify and add the root number which did not fit to my scenario.
But when a string is entered as the trunk username it’s difficult for the LANCOM to combine it with the extension number So the LANCOM leaves the extension numbers as they are and a 1:1 dialing is possible. And - of course - the call authentication works inbound!
Config has to be like this for this intra-company scenario:
So the LANCOM leaves the extension numbers as they are and a 1:1 dialing is possible. And - of course - the call authentication works inbound!