If the phone isn’t properly set up for NAT, or can’t be, Asterisk will not be able to send media to it until it has received media from it, and even then, for that to work, symmetric_rtp must be enabled. Asterisk will, initially, obey the standards, and send media to the address in the c= line in the SDP. Only with the conditions above will it violate the standards and use the address from which it is receiving media.
Note if Asterisk is behind NAT and its media address and local networks are not properly set, you will end up with a stalemate, even if the other side has the equivalent of symmetric RTP enabled. One side has to send a usable address in its c= line for media to work when both are behind different NATs (ignoring the possibility of using ICE).
I’m using a STUN server on both the server and the phone. NAT is enabled on both ends and symmetric
RTP is enabled on the phone. RTP traffic continues to be routed to the private IP address of the phone. I’m using the public google stun server.
Actually it is best if you provide the complete INVITE, 200 OK and ACK message, as you may be getting away with private addresses for more than just the media. You can replace the addresses with public-phone-ip, private-phone-ip, public-asterisk-ip, and private-asterisk-ip.
As @david55 said. Until you can upgrade to at least Asterisk 16, I don’t recommend switching to pjsip, unless we discover a specific problem where it might help.
Please confirm that in Asterisk SIP Settings (General tab), External Address and Local Networks are correctly set. Media Transport Settings should all be blank. On the chan_sip tab, you should have NAT set to yes, IP Configuration set to Static IP, Override External IP left blank. If you change any of these, after Submit and Apply Config you must restart Asterisk.
In the router on the server side, forward UDP ports 10000-20000 to the LAN address of the PBX.
If no luck, at the Asterisk command prompt, type sip set debug on
make a failing test call, paste the Asterisk log for the call at pastebin.freepbx.org and post the link here. If you are too new to post links, just post the last eight hex characters of the URL.
Actually, I’m only halfway there. I was able to dial into voicemail which I couldn’t do before, but trying to call an outside line, I still couldn’t hear audio either way. Still troubleshooting.
I set everything up as you suggested. I haven’t looked at the RTP debug info since the phones started working between extensions and to voicemail. Here’s my log SIP log
The remote extension is 102. I dumped everything to a file during the test so there’s other activity in the log.
Ok. So, either no one knows what’s going on with my routing issue or I said something to make everything think I fixed it… Not sure which but I can see this is a dead thread.
As I continue to update this job. I have updated my FreePBX server to 16
PBX Version:16.0.19
PBX Distro:12.7.8-2204-1.sng7
Asterisk Version:13.38.3
With no change in operation. I converted my one extension to PJSIP. I even deleted the extension and re added it which required the newly generated password to be saved in the phone and the phone connects. I can call voicemail and I can call other extensions in the office, but I can’t get any audio when I’m making calls to public numbers. No in bound audio and no outbound audio, but the phone I’m dialing does ring.
The only think I thought was odd, but I don’t know what’s going on anyway, is when the phone I’m calling answers (I’m letting it go to voicemail so I can see if there is any outbound audio), the FreePBX server takes over the line and creates a bridge?? from the phone number on the FreePBX server to the number I called. I assume that’s normal, but this is what I get using sngrep,
Those IP addresses aren’t associated to my phone or to FreePBX at all. I don’t know where they came from. They aren’t my private IP address and they aren’t my public addresses on the server or my phone.
I figured it out. My router in DMZ mode was not properly NAT’ing traffic. When I turned off DMZ and used port forwarding the phones worked to make calls to outside numbers and inside numbers.
My intent was to make the server available to phones on the public internet. I’ve been using this system for about 6 years, but all the phones were on the local network with the server. I didn’t want to expose 5060 to the outside world because of hackers, but now I needed to.
So, that port forwarding worked for the phones on the inside but, following recommendations in FreePBX’s firewall instructions, I put the server in the DMZ thinking all the forwarding would be taken care of. That isn’t what happened. All of this would be avoided if I had just added 5060 to port forwarding.
I’m not sure how this will affect other things I setup. for example, I’m pretty sure my let’s encrypt updates will fail because port 80 is not exposed and of course, I can no longer administer the server from outside because the 443 isn’t exposed and provisioning won’t work now either (even though the phone never provisioned from the server from the outside. Since I have the phone with me, I was able to provision it manually which isn’t always an easy task.
I hope that answers your question.
On second reading, I see that you recommended that. I didn’t do that because my server was on a DMZ, what purpose would port forwarding serve? Does port forwarding work even if the server is on the DMZ? I never thought of that.
99.9% of all ‘hacks’ are directed at UDP/5060, There are 100 reasons NOT to use that for registrations and invites and pretty well 0 FOR using it.
To use HTTP-01 as a protocol for LE is required but only for a few seconds of exposure every 60 days and that to a relatively easily protected URL Switching to DNS-01 if feasible requires no exposure ever to port 80,
Given a proper certification port 443 is relatively protected but a few firewall rules can further protect.
Given that certification, switching to TLS/5061 is recommended for your external endpoints, failing that using TCP/(random unused port in the high thousands) will further limit access