Ask Your Question

Debugging faulty VOIP app - Best approach?

asked 2021-04-19 08:53:52 +0000

HappySailor gravatar image

Hi there, We are attempting to fix an issue which is affecting our small school since months. We are using a Panasonic NS500 PBX unit which is cable connected to our LAN, to manage phone calls. The NS500 is an hybrid system which manages analog-in phone calls and SIP/TLS calls between hardphones and softphones. SIP server is local.

While there are no issues at all when using hardphones, softphone to softphone calls are experiencing random issues (no audio). I would say that 30% softphone-to-softphone calls have (no) audio issue, and when this happens, users are required to dial again until the audio is working. Usually the second dial attempt works as expected. Softphones are based on the official Panasonic iOS/Android app.

Unfortunately Panasonic is not really eager to help solving the issue although we suspect the system is prone to glitches, also due to the architecture's complexity: image description

  • Softphones app connects to the local PBX through the Internet or in LAN, depending on current location
  • The first time the app is fired, it will attempt to connect using the best connection, so both remote and local connection attempts are made at the same time. Once connection is established, the quickest connection will be used
  • Any subsequent connection attempt by the Softphone, will be made through the last-time connection (remote or local). If this fails, then a new connection attempt is made using the other connection method (remote or local)
  • Any softphone app, prior being used must authenticate to Panasonic servers which are hosted on Amazon AWS

So Panasonic keeps asking us to double check settings on the router, which in their opinion is causing the issue. We wonder how this can be, as the issue appears randomly.

LAN Scenario:

image description

  • Peplink router model Balance One using 5 WANs
  • Core LAN + 4 VLANs - Hardphones and PBX are connected to VLAN 400
  • Softphones are connected to the SIP server either through Staff VLAN, or through the Internet:
  • SIP-ALG is disabled
  • Softphones are configured to use TLS

A the moment I am using Wireshark to capture traffic on VLAN 400, where the PBX resides, but I could also capture traffic on the router end.

To make things easier and to exclude as much as possible routing issues, I have momentarily connected the softphones to the same VLAN as the PBX.

When capturing traffic, you can clearly see TCP traffic between the softphone, the app and the authentication servers over the internet. At a given point, when the callee will answer, Wireshard will show UDP packets flowing between the softphones. When the (no audio) issue occurs, since the callee will answer to the phone call, wiresharks show UDP traffic only from the caller: there's no UDP traffic from callee, which explains why there's no audio.

There are no errors in the firewall log, which could help spotting any LAN request being blocked

Without knowing what "handshake" schemes are in effect it is difficult to understand where the issue occurs.

How would ... (more)

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2021-04-19 11:49:11 +0000

BigFatCat gravatar image

updated 2021-04-19 11:53:08 +0000

The lack of UDP packets could be the issue. Can you move the sniffer closer to the source of the missing UDP packets? VOIP uses RTP packets for the audio. It is usually UDP packets. Wireshark needs to be configured to look for RTP packets. This is different depending on what version you are using. WARNING - listening to calls is probably illegal Wireshark can playback g711u. I would make test calls and use those calls for troubleshooting.

edit flag offensive delete link more


UDP packet are encrypted (TLS) so there are no issues on this. The question is, why the calle is not sending any UDP packets? Could it be the faulty phone is sending UDP packets to a wrong address? Of course I'd need capture traffic on the faulty phone, which is an iPhone...

HappySailor gravatar imageHappySailor ( 2021-04-19 12:24:12 +0000 )edit

DTLS, understood. Can you decode any of the SIP to verify the SDP negotiation? That is where SIP will negotiate IP and port for the audio. Also, you can try to capture traffic of a good call and bad call at the softphone edge. You can verify if a bad call is sending packets and to which VLAN, IP and etc. No packets, then go to Panasonic and ask why.

BigFatCat gravatar imageBigFatCat ( 2021-04-19 20:39:40 +0000 )edit

Will investigate and post back

HappySailor gravatar imageHappySailor ( 2021-04-22 07:17:24 +0000 )edit

Thanks. I am very interested.

BigFatCat gravatar imageBigFatCat ( 2021-04-24 16:42:19 +0000 )edit

answered 2021-04-19 11:53:55 +0000

hugo.vanderkooij gravatar image

Do you allow softphones to connect directly from 1 softphone to another? As that is how your voice data normally travels with SIP. This might be required between VLAN's in your setup and not anticipated.

In some firewalls this is taken care of by listening to the SIP requests and open the ports dynamically as needed. But in some cases you need to open large UDP ranges between segments.

In you case you need to capture on 2 softphones and see what the send and receive to see if you can point to a firewall.

Don't rule out an issue with the windows firewall if you run a softphone on Windows.

edit flag offensive delete link more


  • softphones communicate through PBX. All UDP traffic goes back and forth to the PBX which in turn will forward to the other softphone
    • when both softphones are connected to the same VLAN as the PBX, there cannot be any firewall/port restriction
    • How do you manage traffic capture on softphones?
HappySailor gravatar imageHappySailor ( 2021-04-19 12:21:23 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2021-04-19 08:53:52 +0000

Seen: 504 times

Last updated: Apr 19 '21