The behavior you are describing is normal, especially for trunks that use insecure=very (or insecure=invite).
When a SIP call comes into Asterisk, it makes several evaluations. One of the first evaluations is whether the call is coming from a valid Trunk.
It does this by comparing the IP address where the call is coming from with the host=IP addresses of the Trunks you have set-up. Ordinarily, it would also ensure that the originating port and the username and password are correct as well. However, if you have insecure=very (or port,invite) set (as you do) in a trunk, then Asterisk makes no effort to match the username/password/port on incoming calls. Rather, as long as the host matches, then Asterisk accepts the call as coming in on that trunk. Trunks are compared in alphanumeric order, so if you have several trunks set up to the same host, every incoming call will match to the trunk with the lowest alphanumic name, i.e. 1111 before 2222, and aaaa before bbbb.
If the call matches ANY of your trunks, that’s good enough for Asterisk, and it moves the call on to the next level of processing, which is to compare the DID sent with the call with your inbound routes. It appears to process then in alphanumeric order, so whichever Trunk matches first will end up listed in the CDR.
If the call is NOT coming from a valid trunk, then Asterisk/FreePBX asks whether you have enabled “Allow Anonymous SIP Calls” from the general settings page. If you have, then that is also good enough for Asterisk, and the call gets sent on for processing the DID against an inbound route.
If neither of these are present, Asterisk answers the call and plays a message that says that “the number you have dialed is not in service at this time.”
As far as FreePBX/Asterisk is concerned, when a call comes in, as long as it is coming from an authorized host, or you’ve enabled anonymous calls, that’s all that matters.
And as long as the DID matches, the call will go wherever you want it to go.
So, I guess, other than having a interesting discussion about call processing, I’m not really sure what the problem here is?