Multiple sip trunks stop to work when one is disabled

Hello,
I have a problem that made me crazy, hope someone could help me.

I have an asterisk server with many CHAN_SIP trunks registered on the same SIP provider.

Obviously i have the problem that an inbound calls is presented on the last channel, but this is not the real problem.
The big problem is that if i disable one trunk all others go in error and i don’t receive any call.

i have those messages

[2022-05-13 17:04:57] NOTICE[662238][C-00000edf]: chan_sip.c:26598 handle_request_invite: Call from ‘010893XXXX’ (PROVIDER_IP:5060) to extension ‘011198XXXXX’ rejected because extension not found in context ‘from-sip’.
[2022-05-13 17:04:57] SECURITY[662258]: res_security_log.c:116 security_event_stasis_cb: SecurityEvent=“FailedACL”,EventTV=“2022-05-13T17:04:57.742+0200”,Severity=“Error”,Service=“SIP”,EventVersion=“1”,AccountID=“01119821991”,SessionID=“0x7eff601afa58”,LocalAddress=“IPV4/UDP/(SERVER IP)/5060”,RemoteAddress=“IPV4/UDP/(PROVIDER IP)5060”,ACLName=“no_extension_match”

The only way to work is enable again the trunk disabled.

That’s the peer incoming configuration of the trunk

username=011198XXXX
user=011198XXXX
type=friend
secret=73xxxxxxL4
insecure=invite
host=voip.provider.it
fromuser=011198XXXX
context=from-sip
disallow=all
allow=alaw&ulaw
qualify=yes

The same happen if i change
insecure=port or add fromdomain=voip.provider.it

Any idea?

Thanks

Switch to pjsip and write the proper identify section. If you are lucky, i.e. you have a decent service provider, then you should use the line option in the registrations section.

chan_sip is, effectively, no longer supported, and will removed in the October 2023 release.

Having many registrations for the same peer address is generally a recipe for problems, as both sides can have difficulty telling which sessions relate to which registration.

I assume by trunk you mean a peer associated with an ITSP. SIP does not define the term trunk. What do you mean by disable?

This is not obvious. Do you mean that the last entry in sip.conf, for the ITSP’s host name handles all the incoming calls? That means that the provider is not taking advantage of your type=friend, by sending the sip.conf section name in the From header (and I wouldn’t expect a provider to do anything different), and is therefore matching an arbitrary entry, as type=peer, based on the host name.

Although I’m not sure what disable means, I rather suspect that the provider is having problem distinguishing the three registrations, and that is causing your headline problem.

username is only relevant to incoming registrations, and is a deprecated name. I don’t think that user is defined at all.

As noted, it is unlikely that the provider is putting the section name (which you failed to include) in the From header, so all this is doing compared with type=peer is giving an attacker the ability to spoof the provider, if they know that section name.

That could only make things worse.

chan_psjip, which you should be using, has the ability to run multiple transports, on different port numbers, which may allow the provider, and Asterisk to tell the endpoints apart. It also has a line parameter, that allows some providers to distinguish for inbound calls, although may well not help if they are treating the registrations as overriding each other.

It would appear that FreePBX has a disable option for trunks, but I don’t know what it does in Asterisk terms, and if it is the source of the problem this is the wrong forum.

Thanks for your answer,

It’s exactly what you say. I use the name trunk because it’s effectively an external trunk but it’s a peer associated with an ITSP.
With disable, i delete the configuration of the peer and reload.

What i can see from my logs is that incoming calls are directed to the right DNID but all calls has the same CHANNEL. If i delete the trunk with the number of that channel i cannot receive any call.