I have two Cisco phones serviced by Nextiva cloud phone service. They have been working fine for months.
Since installing the PepLink 20 which seems to be otherwise working, the phones are behaving strangely.
On one of them, I have dialtone and can call my cell phone from it, but I can’t hear anything after the dialtone ends and one would expect to hear the phone on the other end ringing. The cell phone rings and I can hear sound from the desk phone. That means dial-tone is working, dialing is working, outbound sound transmission is working, but inbound sound transmission is not working.
On the other phone, I also get a dialtone, but calling doesn’t work. The phone just sounds dead after dialing a number and the remote phone (my cell phone in this case) doesn’t ring.
Any ideas for making VOIP work with the PEP Balance 20? Is this expected?
I would recommend the following steps to resolve this:
Create an outbound policy rule in the Balance for VoIP traffic, or use separate rules specifying the source IP address of the phones. Using the priority algorithm, you can keep the VoIP traffic on a primary WAN link and failover to the secondary WAN. It is important for the phone to use the same WAN link for VoIP calls as it does to register to the cloud service.
It may also be necessary to run “Compatibility Mode” in the Balance under: Network> Service Passthrough> SIP.
This is slightly off-topic, but should I be manually downloading the latest firmware? The device came with 5.3 and I see that 5.4 is available on the PEPLink website, but when I use the admin UI to download the latest firmware, it says I already have the latest version.
Great stuff. I found that FAQ as well. I don’t see “VOIP” as a protocol in the rule UI.
Should I be setting up a rule that sends all traffic from the phone’s source IP addresses (all protocols) to prioritize the WAN link I want the phones to use? The phone IPs are set through DHCP, so I’m not sure they will remain the same. Do I have to reserve addresses for them?
Or is the idea that I put all traffic to the appropriate “destination” IP of the Nextiva service through one of the WAN connections? (I’ll have to figure out what the Nextiva address is then.)
Thanks again for walking me through this. I’m probably not the first, nor will be the last.
Yes, you can either configure DHCP reservation for the IP phone or you can have the Outbound Policy based on destination IP or Domain Name. Please give it a try.
I noticed that one of the existing phones had a static IP in the 10.0.1.x address range, while the PEPLink was using 192.168.1.x address range. I changed the PEPLink to use 10.0.1.x addresses and left the bottom 10 addresses outside the DHCP assignment range so I can use them as static addresses.
I gave each of the phones static addresses and created priority rules for each so they use the same WAN connection by default. (I don’t know how to find the Nextiva destination address, so this seemed easier.)
This also fixed my wireless printer because it was getting a 10.0.1.x address from the wireless router. Things seem to be working now, though I’m not sure how the wireless router and the PEPLink are going to cooperate in assigning 10.0.1.x addresses…
We use a lot of VoIP behind Peplink routers. I would suggest you make an outbound rule to feed the ports being used through one particular WAN. That way you don’t care what IP the phones are using, and if you add a phone it just works. If you are using SIP, that would be 5060-5063, and 10,000-20,000, both UDP. If you are using a different VoIP protocol the ports could be different.
Group: I ran into this problem with our SimpleSignal service and Polycom phones. The resolution was to completely disable the VoIP ALG from a concealed page in the Balance firmware. Apparently it’s due to the PL not handling NAT correctly for TCP, even in “Compatibility Mode” (which, we found, doesn’t totally disable the ALG). (And, yes, we use TCP: It’s more reliable and sufficiently real-time for VoIP, despite what the UDP proponents say.)
Once we disabled it entirely, most problems vanished.
The only other problem you might be having is during a WAN failover or link-full situation. In that case the lack of a SIP proxy can break inbound calling until your devices re-register over the new WAN link. PL is working on a fix (see: here), but I haven’t heard when it might be implemented.
I just noticed this thread and have some nextiva phone issues as well with my balance 310. I’m going through a couple of the suggestions here and will update if anything works / does not work.
