This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Remote User Disconnect - Log Review

0

Hi Everyone, we have remote users who use a VPN and also Citrix to access our systems. Our remote users are randomly getting kicked off their VOIP calls to customers. I have setup a batch file to run on startup that will use dumpcap.exe to capture logs in 5 minute intervals to make log reviews easier (hopefully).

Batch file looks like: "C:\Program Files\Wireshark\dumpcap.exe" -i 2 -b duration:300 -w C:\sharklogs\basefile.pcapng

I am currently only capturing logs from their network adapter, not the VPN virtual adapter for now.

I want to analyze the logs from an instance when a remote user gets disconnected.

The users VPN connection and Citrix do not drop, only the VOIP call and my VOIP vendor says their more sensitive to network issues then a VPN or Citrix.

So now that I have these logs being created, I am very unfamiliar with what I will actually need to look for in the logs, that verbiage I need to locate and what it means for hunting down network issues, packet loss etc. Any help would be immensely appreciated.

asked 12 Sep '16, 13:09

RG-Admin's gravatar image

RG-Admin
6112
accept rate: 0%

Maybe its time to hire a networking professional, and force your VoIP vendor to cough up more details about what he means by being 'more sensitive to network issues'.

(12 Sep '16, 15:43) Jaap ♦

The more details are as follows:

Latency and jitter for toll quality: < 100 msecs total 100 msecs less 42 msecs allocated for the ShoreTel system yields a 58 msec budget for the network. When G.729a encoding is used, 100 msecs less 62 msecs allocation for the ShoreTel system yields a 38 msec budget for the network.

Latency and jitter for acceptable quality: < 150 msecs total 150 msecs less 42 msecs allocated for the ShoreTel system yields a 108msec budget for the network. When G.729a encoding is used, 150 msecs less 62 msecs allocated for the ShoreTel system yields an 88 msec budget for the network

Packet loss: < 1% for voice calls, and no packet loss for fax and modem calls

(12 Sep '16, 15:51) RG-Admin

I have logging running full time one of my remote users PCs and have captured the logs for the disconnects. Now I need to determine how to read the logs to find relevant info. Does anyone have a link to a good guide on how to look through these to find answers?

(16 Sep '16, 12:31) RG-Admin

I don't have any guide to link at but here are several thoughts:

Our remote users are randomly getting kicked off their VOIP calls to customers.

This does not seem to be related to latency or packet loss unless the latter is really heavy. Even if the audio quality is really bad (due to high packet loss or due to high "jitter" which means irregularity of latency), a VoIP call would continue until one of the parties would hang up unless the VoIP equipment monitors the voice transmission quality and actively terminates the call if the monitoring shows that a pre-set quality threshold is undershot.

In a lossy network, it may take long to set up and to hang up a call because the signalling messages get lost and have to be retransmitted, but during the call there is no mandatory signalling exchange whose failure would cause the calls to be actively dropped. However, some systems do exchange "keepalive" signalling messages mid-call only to verify that the remote party still knows about the call. But these are retransmitted using the same rules like the call set up and call hang up ones, and rarely sent more frequently than once every 5 minutes.

If people don't complain about call quality becoming terrible (not just bad) some time before the call drops, a loss of session keepalive messages is unlikely to be the reason.

So first of all ask your VoIP vendor whether the calls are dropped due to some quality monitoring system activity or session keepaliving activity. Their records should be clear about that.

I am currently only capturing logs from their network adapter, not the VPN virtual adapter for now.

Several points here:

  • as you capture only at client end, you won't notice any eventual packet loss in the direction from client to the VPN access point

  • depending on your VPN type and setup, it may be hard to detect packet loss because unless the VPN uses TCP as transport, the protocol fields allowing you to identify packet relationships and sequential numbers are encrypted.

  • not all virtual network adapters created by the VPN client software support capturing well. On my Cisco VPN adaptor, I cannot capture anything useful although some packets can be seen. So look also for some logs of the softphone your agents run on their PCs, these might tell you something about the audio quality.

(16 Sep '16, 13:29) sindy