I currently have a problem that incomming calls are not coming through. Full-log says:
NOTICE[15225] res_pjsip/pjsip_distributor.c: Request ‘INVITE’ from ‘“xxxxxxxxxxxxxx” sip:[email protected]’ failed for ‘192.168.50.1:5060’ (callid: [email protected]) - Failed to authenticate
where 192.168.50.1 is my “provider”, trunks are registered there.
Can anyone confirm that this might be a firewall-problem, in combination with my advanced custom rules saying:
-A fpbxinterfaces -p udp -m set --match-set allow-list src -m multiport --dports 4569,5060,63380 -j ACCEPT
-A fpbxinterfaces -p udp -m multiport --dports 4569,5060,63380 -j DROP
No. It will be because you have either used auth= for the trunk, or you have not configured Asterisk to correctly recognize calls as having come from the trunk. (It is also be because you have provided a chan_sip configuration, on a system which only has chan_pjsip installed, or on which chan_pjsip is on the default port.)
auth= corresponds to setting authentication to inbound, or both, in FreePBX.
pbx is purely pjsip.
also valid for all trunk (each pjsip trunk had the same problem)
Finally what might be the auth-problem which never appeared during the last 5 years?
“provider” in this case is the router which on his side connects to the real public provider.
Specific context (never changed for years) is required to fake my own inbound phone numbers since the router does not deliver these numbers to sip-chanels (he just delivers an ‘S’ for each and every number).
The only real thing I lately changed, was to add 3 additions phones to own extentions (cisco CP8861 instead of my usually used yealinks). One of the cisco’s connect for 2nd line via 5065 instead of 5060 which is quite strange, but should not have any effect to the trunk connect.
Weird. The only thing I can think of is that you have set match/permit, and it doesn’t match the server address.
good idea. It is set not for all trunks, but for 2 of 4 it should’n create trouble. Is set to 192.168.50.1/32
Are you saying you have more than one trunk with the same match/permit setting? You can’t do that, as it undefined which trunk will be assumed to match.
yes.
What would you recommend? Delete the match-permit entries and let it empty?
It’s not undefined, the config works in a top-down format. The first endpoint that has a match to 192.168.50.1 will be what is matched. If extension 100 is before ISPTrunk and they both matched 192.168.50.1 then endpoint 100 is what will be matched as it is the first listed in the config.
That won’t help. The default is to use the server address.
Do you have the line option enabled for everything using that address? Is there anything using that address that does need outbound inbound authentication?
Each internal system is using this adress. It`s in addition the gateway (because it’s the router).
The router’s phone function connect to the phone-provider. The router’s interfuction connects to the ISP (where both are the same provider).
Extensions are connect to the PBX, which is 192.168.50.15 in my case.
Trunks are connecting from 50.15 to 50.1
In my previous thinking an entry in the match-permit of the trunk restricts the contact to this address, only.
Why should not different trunks be resticted to the same address?
These address might be a local one like in my case, or an external IP-Range (which is owned by the telefon-company)
Result should be, that trunks might not be connect to a faked DNS distributed criminal…
In most parts of Asterisk, objects are stored in a hash and chain structure. Searches are done by going through each bucket in order. The result is that the first one to be found isn’t the first one defined.
Also, it isn’t normally the config that one is searching, but rather a table created by parsing the configuration, and managed by the specific module.
I don’t know if that is the case here, but I do think that it is not guaranteed not to be the case, and therefore the order is implementation dependent.
The order is repeatable from run to run, but I don’t believe that it is guaranteed to be the order of definition.
(The reason that you need a restart when switching between linear and other queue member strategies is because the table of members has to change from a simple list to hashed structure:
It looks like “show queue”, from the CLI does a sorting step, but the AMI equivalent doesn’t so you will get different orders (neither of them the order of definition).
I don’t know my way around the chan_pjsip code well enough to know where to look for the ao2_container_alloc* for type=identify, but I don’t think there is any guarantee given that it isn’t hashed, or won’t be in the future. I’m also not sure that the primary search order isn’t that of the endpoints.
Originally everything was hashed and I think the linear queue strategy was achieved by setting the number of hash buckets to one. It looks like there are now also simple list and B-tree containers.)
The name of that option is misleading. It isn’t use for access control, at all. What it does is to generate a type=identify section which specifies the match= parameter as the addresses provided, and the endpoint to which that address relates as the endpoint to use for a match on that address.
If you specify a server address, it gets generated with the server address as the default value for match=
If you have more than one endpoint with the same match address, whether explicit or default, the one that gets selected depends on exactly how the search is done. That’s not straightforward, as it is possible to make the endpoint name a higher priority match, even though I think that FreePBX only enables one matching mode per endpoint.
There is a work around for when multiple endpoints have otherwise identical matching information, which is the line option, which sets an extra parameter in the Contact URI, in the registration. Not every provider supports this, and I’m not sure exactly how it interacts with the rest of the matching process, given that the normal matching is done on source information (IP source or From header), but this is returned in the destination information (request URI), which, otherwise, isn’t used until the inbound route stage.
I also don’t know how it works if some but all the ambiguous candidates use it.
A router should not be changing the source IP address on inbound traffic. If that happens, it normally means you have SIP ALG enabled on the router, which is generally considered a bad thing, as it is generally misimplemented.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.