Dropped calls

My small business has a completely separate wired VOIP phone network. All 12 phones are connected to a cisco switch, and then to a Balance 20. The Balance 20 is connected to a 50Mbps Comcast high speed router/modem with the router placed in bridged mode.

We frequently get dropped calls, or phones down. My VOIP provider, Voisip, says that nothing is wrong with the internet at the times of the dropped calls. All RTP and SIP port forwarding in the modem is done correctly, and the router is in SIP compatibility mode (It won’t work otherwise).

VOISIP says there may be additional router specific rules that are required. Does anyone know if additional rules are required in the Balance 20 for reliable VOIP operation?


  1. Upgrade firmware to latest 6.2.2 from the website if not already.
  2. Make 2 custom Qos rules for sip and rtp and put them on high.
  3. Enable intrusive detection and dos prevention.
  4. Tell me what your firewall rules look like if any for inbound and outbound. You should only need outbound rule for sip and rtp since its a stateful firewall.
  5. Is your sip signalling port udp 5060?
  6. What does your outbound policy look like?
  7. What does your Health Check Settings look like?
  8. Do you have MTU set to Auto?
  9. Is your WAN traffic shaping configured accurately for your ISP speeds?
  10. Have you taken pcaps in the back page and analyzed your sip and rtp traffic?

*We have over 250 balance devices just for hosted VoIP networks and a lot integrated with computer networks as well. Im sure you just might have some configuration changes that are needed and with that you can expose whether it is the ISP, balance config. setup, or your SIP feature server errors.

Thank you. Answers as follows:

  1. Currently running 5.3.12. Will upgrade after hours. Tried over lunch but needed an unlock key for out of warantee product. Found it on Incontrol2
  2. Set for all supported VOIP protocols on high. I added RTP on High per your suggestion
  3. Already set for intrusive detection and dos prevention
  4. Firewall outbound: ANYprotocol from ANY source to ANY desitnation is ALLOWED
    Inbound: TCP from ANY source to ANY destination port 80 is DENIED
    TCP from ANY source to our PBX port 443 is ALLOWED
    TCP from ANy source to ANY destination port 443 is DENIED
    ANY protocol from ANY source to ANY destination is ALLOWED
  5. Port forwarding sip service UDP range 5004 to 5099 to our PBX
    Port forwarding RTP service UDP range 10000 to 65000 to our PBX
  6. Not sure where to find this on my software revision
  7. MTU is set to 1500
  8. Upload bandwidth set to 8Mbps. Download 30Mbps. Set for comcast 50Mbps modem service
  9. Not sure what you mean by pcaps or back page

Ok, just to clarify you have an onsite pbx, correct? Do you have their LynxVox 2000 series?

Yes. The onsite PBX handles all internal traffic and establishes a trunk to VOISIP, a VOIP service provider.

  1. Where the Compatibility mode is for sip, try defining your sip signaling ports.
  2. How many endpoints do you have and have many sip trunks do you have?
  3. Outbound Policy: Do you have the persistence algorithm with Source: ANY, Port: ANY, Destination: ANY?
  4. Set the WAN MTU to Auto.
  5. WAN Health Check Settings: try make it PING and numbers 5,5,10,15.
  6. Try applying NAT Mappings: Network IP of your phones.
  7. pcaps with wireshark - MANGA/support.cgi (in the URL once logged into the router)

Also, what model cisco switch are you using and what model phones?

Phones are Yealink. Cicso switch is a 16 input dumb switch. I am not at the location and don’t konw the model number

  1. Peplink only provides 3 signaling port inputs. The range recommended by Voisip extends beyond this
  2. There are 12 phones and 1 PBX
  3. Outbound Policy: Persistence Algorighm from ANY source to ANY destination protocol TCP port 443
  4. I will try this. VOISIP recommended 1500
  5. I pinged and got back 0 packets
  6. Phones are set by DHCP and NAT is turned on. What do you mean by “apply NAT Mappings”?
  7. On MANGA/support.cgi website there is no mention of pcaps or wireshark
  1. Under NETWORK then WAN toward the bottom you will see Health Check Settings, I meant set that to PING and make your numbers below it 5,5,10,15.
  2. There is a NAT Mappings Tab but you might now have this until you upgrade your firmware.
  3. When logged into the router you will go to the URL and erase everything in front of MANGA/ and put in support.cgi in front. Should look like MANGA/support.cgi then hit enter.
  4. Outbound Policy: Try making it persistance, source ANY, destination - the IP of your PBX or MAC, port ANY.

*Once you upgrade, under NAT Mappings: try putting in the IP of your pbx then check your ISP public ip for the outbound mappings.

  1. OK Done.
  2. I see a NAT mappings tab. What will this do?
  3. I was able to view the support.cgi page. I saw no pcaps or wireshark
  4. Outbound policy. OK. Done
  1. In that page you start a network capture and let it download. It’s not a large file size for the 20’s it wont take long. Download it and it opens up in wireshark, so make sure you install latest version of wireshark on your computer. Double click the LAN capture, WAN, or analyze both its up to you. From there you can set your filters for sip, rtp traffic, analyze VoIP calls if you capture any.

I am having trouble updating the firmware. I have 2 balance 20’s, one in warrantee and one not. The instructions for getting the unlock keys in the pepwave knowledgebase got me the unlock key for the one out of warrantee, but not for the one in warrantee. How do I get these unlock keys?

I think you need a team member for that, they should see this and respond shortly.

Hi Jeff, the unlock keys can be obtained through InControl2. You can just add the other serial number to your account and then you will see the unlock key.

Tim; Now the Balance 20 is dead. I have serial number 1824-DF42-4CC4. It it was not running 5.3.12 so I upgraded it to 5.3.12 before trying to upgrade it to 6.1. After upgrade it went completely unresponsive. Even the factory reset button does not bring it back. I cannot get a logon screen, or any returned packets at all!

Also, incontrol2 does not give me an unlock key for this warranted unit. Incontrol2 does, however, give me a firmware key for serial number 1824-c656-4489, which is not in warrantee.

What can I do to solve these problems?

Hi Jeff,

What is the color for status light of 1824-DF42-4CC4? Have you press and hold the reset button more than 10 seconds?

Please open ticket for us to follow up if RMA is needed.

Thank you.

Thanks TK. Both status LEDs are green. I have held the reset button for 10 seconds and the unit does reboot. When I plug my computer into port 1 there is no response to When I set my computer adapter address to and retry the pepwave at there is still no response. Checking the status of my adapter shows many packets sent to the balance 20, but no packets received back. I have opened up a ticket.

I now have the replaced Balance 20 router in place. Everything is back up and running with the latest pepwave software. We are still getting dropped calls. I and am trying to use your advice regarding wireshark. I have done a capture on the suppport.cgi page and downloaded a .TGZ file. Wireshark says the network dump file (which is a .tgz file) is not in a format that wireshark understands. What needs to be done to get Wireshark to read this .tgz file?


You just need extract it with 7zip or WinRAR. Then you can use Wireshark to read it.

Also, In your Outbound Firewall Rules, try this:

Rule: SIP
Protocol: UDP
Source IP & Port: ANY
Destination IP & Port: yourserverdomainname.com or IP/ Port 5060
Policy: Allow

*Create another rule for your sever RTP port range. Again, you need to know what sip signalling ports your platform uses and also what RTP ports it uses. Its a statefull firewall, so you should only need these rules for Outbound. This needs to be done, YOU MAY BE PORT HOPPING! Check your active session for SIP and if you see that your source and destination ports for sip are all out of wack then you are more than likely port hopping.