TIPS No sound - Vultr/IPBX 2021

[Tom Clark]

I'm still trying to get IPBX 2021 working through Vultr. I have configured a chan_sip extension in IPBX 2021 with a corresponding SIP account on Linphone on my Mac. I have configured an inbound trunk from VoIP.ms to point to the Linphone extension. I am able to dial the VoIP DID and the call routes to Linphone. I can answer the call in Linphone and both the caller and Linphone recognize that the phone has been answered, which is more than I can say for when I tried routing the call to my Grandstream GXP2200. The roadblock I can't seem to get past is the dreaded no sound problem. I added a port forwarding entry in pfSense:

Interface: WAN
Protocol: UDP
Destination: WAN address
Destination port range: From Port: 5060. To Port: 5060
Redirect target IP: My Mac's IP
Redirect Target Port: SIP
NAT Reflection: Use system default
Filter rule association: Rule NAT

Is there anything I did wrong? Any ideas on how to solve this?

 

[wardmundy]

Forward UDP 10000-20000 to your Mac's IP address with NAT=yes on the FreePBX extension.

 

[Tom Clark]

Forward UDP 10000-20000 to your Mac's IP address with NAT=yes on the FreePBX extension.

I was able to get it to work with NAT=yes without having to forward UDP 10000-20000 to my Mac. What are ports 10000-20000, and why did it work without forwarding those ports?

 

[wardmundy]

Some routers know how to handle RTP automatic routing while others don't. Yours apparently does.

 

[Samot]

Everyone should really start using Chan_PJSIP on new turn ups. Chan_SIP gets removed in under 2 years.

 

[Tom Clark]

Some routers know how to handle RTP automatic routing while others don't. Yours apparently does.

Maybe, maybe not. I noticed that when I opened up those ports it solved the problem I was having with my Yealink W52P not being able to register on IPBX 2021 on Vultr, so I have you to thank for that.

 

[Tom Clark]

Everyone should really start using Chan_PJSIP on new turn ups. Chan_SIP gets removed in under 2 years.

Once I get everything migrated to the cloud, I'll check into chan_pjsip.

 

[Tom Clark]

Forward UDP 10000-20000 to your Mac's IP address with NAT=yes on the FreePBX extension.

Is it possible to forward that address range to two different IPs on my lan? I would like incoming calls to go to my Yealkink W52P and Grandstream GXP2200. I assume that I should assign the GXP2200 extensions port 5061 to differentiate them from port 5060 I use on the W52P, correct?

 

[Samot]

Is it possible to forward that address range to two different IPs on my lan? I would like incoming calls to go to my Yealkink W52P and Grandstream GXP2200. I assume that I should assign the GXP2200 extensions port 5061 to differentiate them from port 5060 I use on the W52P, correct?

Let's clear up somethings. Since your PBX is in the cloud and **that** is what is listening on 10000-20000, opening those ports on your router where the phones isn't going to do anything. You also shouldn't have open up any media ports as the media is never a new request, the PBX sending a call to a phone won't know the media port to send media to until the endpoint tells it what port to use for media. At that point the router where the endpoint is will deal with letting the media through as it becomes an outbound request.

Additionally, phones and other IP devices start with a single port (such as 8000 for example) and increment it based on cycle of the vendors choosing. Some might use 8001 for a second active call but some might use 8002 or 8005 and increment accordingly as more calls are active on the device.

Finally, you shouldn't need to do any port forwarding on the router for individual phones. The router should be handling NAT properly and dealing with this.

 

[kenn10]

@Tom Clark Is your locale PBX still active on your local LAN? If so, that is when things can get wonky. When your system is totally in the cloud, as @Samot has said, you don't want ports forwarded. I covered that in my previous posts on your original thread. If you have any type of SIP ALG turned on in the router, you may need to turn it off. Once your extensions register to the cloud PBX, they communicate as needed with no port forwarding required.

If you are trying to keep local PBX running on your LAN in the interim, there can be a lot of issues that crop up over what traffic goes to what devices until you decommission your old system. If all your cloud pbx extensions worked when you had them on PJSIP, you might want to keep them on PJSIP. You can still provision your trunks on chan_sip until you are ready to change them.

 

[Tom Clark]

@Tom Clark Is your locale PBX still active on your local LAN? If so, that is when things can get wonky. When your system is totally in the cloud, as @Samot has said, you don't want ports forwarded. I covered that in my previous posts on your original thread. If you have any type of SIP ALG turned on in the router, you may need to turn it off. Once your extensions register to the cloud PBX, they communicate as needed with no port forwarding required.

If you are trying to keep local PBX running on your LAN in the interim, there can be a lot of issues that crop up over what traffic goes to what devices until you decommission your old system. If all your cloud pbx extensions worked when you had them on PJSIP, you might want to keep them on PJSIP. You can still provision your trunks on chan_sip until you are ready to change them.

My local PBX has been turned off.

I turned off the two port forwarding additions I made, and for some reason I can't explain the Yealink W52P base station is still able to connect to the Vultr PBX, even though it had been unable to since I first started running IPBX 2021 in the cloud.

I made a test call from my cell to the DID I have with VoIP.ms and made sure that both ends of the call could hear each other. The CDR log from VoIP.ms shows the call coming in and it's duration, but the CDR log from Vultr does not.

 

[kenn10]

Try restarting the pbx from the command line with fwconsole restart and see if that doesn't kick off CDR storage. If not, there may be an issue with one of your cdr config files in the /etc/asterisk directory. Did you copy any of the config files from the old system to the new? Also, have you done a complete restart of the underlying linux OS? That may also be worth a try.

This has nothing to do with CDR but you may also want to restart your router just to clear out any arp cache that may be remaining from your old setup.

 

[Tom Clark]

Try restarting the pbx from the command line with fwconsole restart and see if that doesn't kick off CDR storage. If not, there may be an issue with one of your cdr config files in the /etc/asterisk directory. Did you copy any of the config files from the old system to the new? Also, have you done a complete restart of the underlying linux OS? That may also be worth a try.

This has nothing to do with CDR but you may also want to restart your router just to clear out any arp cache that may be remaining from your old setup.

I didn’t copy any config files. I did a restart of the OS, but that was before I noticed the issue with the CDRs. I‘ll do the fwconsole and router restarts when I have a free moment.

 

[wardmundy]

@Samot: Some (crappy) routers don't handle the RTP port handoff correctly with NAT. Forwarding the ports is a last resort when NAT=yes fails. In this case, you would be limited to one internal SIP phone, but it's better than nothing.

 

[Tom Clark]

Calls are working now. It was the NAT=yes that did it. Now I’m working on getting voicemail messages via email.