That's pretty normal. Your PBX sets up the channel, not Twilio. It doesn't connect out to you to set up the channel. So there is no need for inbound. Like VLANs for VoIP, loads of people repeat the myth of port forwarding. But it's relatively rare that you need that for the PBX, and "never" for phones themselves.

That's pretty normal. Your PBX sets up the channel, not Twilio. It doesn't connect out to you to set up the channel. So there is no need for inbound. Like VLANs for VoIP, loads of people repeat the myth of port forwarding. But it's relatively rare that you need that for the PBX, and "never" for phones themselves.

Port forwarding is absolutely required if you have external phones. Unless you go VPN.

That's pretty normal. Your PBX sets up the channel, not Twilio. It doesn't connect out to you to set up the channel. So there is no need for inbound. Like VLANs for VoIP, loads of people repeat the myth of port forwarding. But it's relatively rare that you need that for the PBX, and "never" for phones themselves.

Port forwarding is absolutely required if you have external phones. Unless you go VPN.

Your PBX sets up the channel, not Twilio. It doesn't connect out to you to set up the channel.

Twilio doesn't connect to me to setup the channel when there's an incoming/originating call?

I don't see how they could ever connect to my PBX if it's behind NAT without either a VPN or the port being forwarded.

No, you connect to them. The connection is always there, it doesn't get set up at the time of a call. It is a trunk. You are thinking of HTTP which sets up a new connection for every interaction. Very different.

SIP Registration keeps the UDP ports open only for so long (I believe the ERL defaults to 90 seconds). So long as your registrations occurs on regular intervals that are lower than the UDP timeout, your port is effectively being forwarded automatically. Some routers do this much better than others - ERLs are pretty great and we recommend them. SonicWalls are the devices that we have the biggest headache with. If you can, enable NAT timeout on the PBX and keep that frequency low - that will keep the UDP port open forever and does take care of most problems with Port Forwarding. (Though I still prefer Fort Forwarding!)

When the PBX registers to the server/carrier, it gets the public IP information from the registration request and add its it to the call routing. You have to be careful though - just because you can receive calls doesn't mean you will have audio available - those can come on different ports and from different Public IPs. Smarter routers (like the ERL) understand the context of the transmission because they understand the dual-method involved in VoIP (RTP and SIP) and can fix mistakes other routers cant.

Getting rid of my silly double NAT setup fixed my SIP registration with Twilio. Apparently there was a SIP ALG setting in my ISP provided modem/router, too. Not sure exactly which of the two was the culprit, but either way, both were bad.