For the past couple of weeks I’ve been trying to get Asterisk to work with Starlink. Starlink itself works really great. And I mean really, really great. It is fast and low latency. Starlink is at least as good as my Comcast cable connection. We’re seeing around 100 mbps download speeds and 80 to 90 mbps upload. But we have several layers of NAT to deal with. It looks like two within Starlink itself and one in our router.
Our router, a Linksys/Cisco RV016, is a bit old but it just works. Its LAN is on 192.168.10.0/24 Network because Starlink’s LAN is on 192.168.1.0/24. Starlink has a NAT dealing with their network on 100.64.0.0/10 and then a NAT to the public internet at 98.97.something. The router has “Port Forwarding” on for both SIP at Port 5060 and the RTP Ports.
I think I have everything setup right. I can make outgoing call just fine using a Grandstream ATA to a real phone. Get good audio both in and out. But now the problem: Incoming calls ring thru to the Grandstream ATA and the phone rings, but when Answered there is no audio in either direction. We’re using “SIP Registration” with Flowroute and we know that’s working as the Phone Rings when called.
The layers of NAT must be working for the outgoing calls to work? So the question is what is wrong with incoming calls?
Now it is a FreePBX Server, but I didn’t post this at the FreePBX Forum because this looks more like an Asterisk problem. FreePBX just builds the configuration for Asterisk to use and Asterisk is really processing the calls.
Attached is the log with both “pjsip set logger on” and “rtp debug on”. And most of the PJSIP configuration.
The layers of NAT are not really working. You’re retransmitting the answer to Flowroute, so either they aren’t getting it, the IP address in the Contact header is incorrect, or the ACK just isn’t getting to you. Asterisk is also sending RTP to Flowroute at the given IP address+port they specified.
I don’t believe Flowroute really does NAT mitigation, so things have to allow the flow of SIP and RTP and that doesn’t seem to be happening.
In Nat scenarios it’s always easier to send something than to receive something. That’s why outgoing calls usually work more often as of my experience.
I saw that your endpoint definition to flowroute doesn’t have direct_media = no, you could add that although I don’t think it will solve your problem as your sip trace doesn’t look like as if direct media would be set up. But it won’t harm in anyway. Also I would set rtp_keepalive to 1 to make asterisk send rtp packets from the first second on. Sometimes it helps.
Aside from that unfortunately I didn’t see another thing on your config that you could try. It would be interesting how it would work with a provider that has better Nat detection.
Thanks TheNextDay and Daivd551! And thanks for your suggestions. Unfortunately the Asterisk Server and Starlink are out in the county. A bit of a drive away. I’ll get out there tomorrow. Another question: doesn’t Asterisk pick the RTP Ports to use based on the settings in rtp.conf? If so one would think that the first use of the Ports would come from the “inside” of the NAT somewhat like the “SIP Registration” packets?
I’ve been told that SIP is a NAT-nasty protocol. After around 20 years or so of working with Asterisk I never really understood that. Now I do!!
It picks the local ports based on rtp.conf, and, when SIP is in a friendly environment (no NAT), the remote side tells it which ports to use for the remote side.
It can’t send until it:
knows a valid media address for the remote side;
has something to send (Playback, explicit silence enabled, incoming media from the other side, etc.)
The only way it is going to meet the first condition in a NAT scenario, without valid ICE, is if the remote party sends something first.
Well I just got back from out in the county. No luck. I set “direct_media = no” didn’t help. Set “rtp_keepalive = 1” no help. Rechecked all of the IP Addresses. Does anybody know what the IP Address of 207.223.78.121 is? Asterisk is sending all of its RTP Packets there.
Because their address appears in a Contact header, an SDP c= line, a Via header or the IP source address of incoming traffic. Obtain logs and and find out which of these.
(They may well be the real VoIP service that your ITSP resells to you, but I’m not an expert on that market.)