I believe you can only specify NAT related addresses in the general section.
Your logs don’t match your configuration with respect to codecs, possibly because you have more codecs in the general section. (Not including disallow can break things if you haven’t got a disallow in general, but, in this case, you must, as you are not sending all possible codecs.)
Although not causing you a visible problem, I would note you have a standard cook book configuration so it is obsolete and wrong.
nat=yes - only needed if the ITSP is both behind NAT and doesn’t know how to compensate - change ITSP if they really need this.
externip : undocumented synonym for externaddr.
media_address : redundant with respect to externaddr
type=friend : should be type=peer (security)
insecure=port : rarely needed (although insecure=invite is needed. WRONG. it has no effect when there is no secret.)
canreinvite: should be directmedia
If 15.2 is your first version of Asterisk, you should have started with chan_pjsip.
Delete. It forces the use of workarounds for when the peer is behind NAT and doesn’t compensate for that. I wouldn’t expect a competent ITSP to have their customer facing machines behind NAT, and if they did do, I would expect them to use the equivalent of externaddr, etc. to hide that from the customers. (With the default setting, Asterisk uses heuristics to determine whether it needs to compensate for such situations, so nat=force_rport,comedia is usually not needed, even in those cases.}
I think ITSPs who specify, think that it turns on things needed for when Asterisk is the one behind NAT, but Asterisk always sends rport (and force_rport forces it at the wrong side to be useful), and the correct way of coping is to set externaddr. They then see reports that nat=yes has been replaced by the individual options, and rather than considering what those options mean and eliminating both of them, they literally translate their previous advice. In practice it doesn’t seem to do harm, even though they both require the protocol to be violated.
(Also, only one side can make effective use of comedia, and that has to be the one that isn’t behind NAT. If both sides need it, there will be a stalemate and no media will get exchanged in either direction.)
(Also, I’m not sure why this is described as inbound. The only reason I know of for needing a separate inbound section is when the peer can initiated calls from multiple addresses. Having an inbound section with the same host address as an outbound risks the outbound section being used for inbound calls, and if it isn’t sufficiently complete for that, things will break.)
Oops. I missed that there was no secret. In that case insecure=invite is not needed, as it has no effect; Asterisk cannot challenge for authentication if it doesn’t know what password will be used.
What’s odd is that we have three basic asterisk boxes, two on prem and one as an EC2 instance. The On prem servers work great with both Twilio and Vitality, the EC2 instance started having an issue with Twilio media (call connects but no sound). Firewall rules are the same and even opened 10000-20000 UDP and TCP from 0.0.0.0 for testing.
All three machines share the same extensions.conf and sip.conf.
In looking at the EC2 sip debugging I see lots of…
Retransmitting #3 (no NAT) to 184.108.40.206:5060:
It’s like the traffic is not making it to Twilio (and yes that public IP is white listed).
Here are the logs of a working and non working log… I am at a loss.