Overview
This article was created to help you determine if there are missing packets on the network that your Chronicall server is located on. The missing packets usually originate from the connections between the Chronicall server and the PBX switches, or phone hosts that Chronicall logs from.
Cause
The usual cause is underlying network issues, which Chronicall has no control over.
Resolution
Below you will find the steps to gather more information on your missed packets. You will want to work with your Network Administrator to troubleshoot your missing packet issues if present.
Check For Missed Packets
Log onto the Chronicall server, and navigate to the below file path to access the tomcat logs. These should contain any relevant networking errors.
- Tomcat Logs
- 32 Bit - C:\Program Files (x86)\Xima Software\Chronicall\tomcat\logs
- 64 Bit - C:\Program Files\Chronicall\tomcat\logs
- Linux - var/lib/Xima\ Software/Chronicall/tomcat/logs
Search the tomcat logs for "missed" for missed packets,"error" for general errors, and "TFTP" for TFTP errors.
A single missed packet is not likely to cause a big rift in the data that Chronicall logs. Many missed packets could result in significant data loss.
In the Chronicall tomcat logs, you'll see lines similar to this:
Wed Oct 29 14:03:51 EST 2014 [Expecting Packet: 22679 received: 22699] Site: 1 Address: 192.168.2.240 -- Too early to tell if it is lost or out of order.
Wed Oct 29 14:03:53 EST 2014 [Missed Packet: expecting 22679 received: 22700] Site: 1 Connection: 10 Address: 192.168.2.240
Note: We only get the "Too early" message when the setting called Order UDP Packets is set to true as well as IP Office New Logging. You can find these hidden setting by holding shift and clicking on Advanced Settings inside Chronicall > Admin(System) > Advanced Settings. Without this setting, if we miss a packet, there is no possible way to recover it.
With these settings enabled, if packets come out of order, we can still put them in the correct order. Once we get the actual "Missed Packet" message, we've stopped looking for packet 22679 and it's gone for good, even if by some chance it comes in later.
Apply Fix
If you see missed packet or TFTP errors, and your PBX is Avaya IP Office 9.0 or 9.1 (UDP), please see
this article. IP Office 10.0 and above (TCP) Avaya IPO requires a CTI PRO License for each PBX Switch, and in turn provides a much better connection to log data. You can
review this article to verify your setup.
Compare XML Logs to Tomcat Logs
The logs seem to indicate we are missing network packet 22679. We can look in the server_edition.xml logs for the time frame surrounding the first unexpected packet. Search for 22678 (the last packet received in the right order), and we can see from the results below that we're clearly missing 22679.
- XML Logs
- 32 Bit - C:\Program Files (x86)\Xima Software\Chronicall\logs
- 64 Bit - C:\Program Files\Chronicall\logs
- Linux - var/lib/Xima\ Software/Chronicall/logs
<pbx-event connection-id="10" op-code="0" packet="22678" time="2014-10-29 14:03:50.387">
<data length="33">
<hex length="33">00 00 58 96 00 00 00 06 00 00 00 00 27 CF 9E AF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00</hex>
</data>
</pbx-event>
<pbx-event connection-id="10" op-code="172" packet="22680" time="2014-10-29 14:03:51.383">
<data length="218">
<hex length="37">00 00 58 98 00 00 00 02 00 00 00 AC 27 CF A2 92 FF 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00</hex>
<ascii length="180">CALL:S 10.3.1,0.30428.0,0,0,1,0,0,0,Line 10,,,5.5,0.0,100.4,88111283,2.0,,,,100,,100,,0,16,0,1,0.0,,,,,,,0,2,0,0,0,0,,,0,,0,0,0,0,,3835,0,0,,0,,3,0,0,0,0,0,0,1,618,1,,,,,,,,,,,,,,,</ascii>
<hex length="1">00</hex>
</data>
</pbx-event>
So, we see packet 22678, and 22680, but we don't see 22679 anywhere in the file (in this example, within 16 minutes of 22678). You can also check the next log(s) if you want to make sure that it didn't come in the next hour or two. Usually though, if you don't get it within a minute, you aren't going to ever get it.
In this situation, we clearly missed the packet, as in Chronicall never received and it was lost somewhere in the network.
If we don't receive a packet, there's nothing Chronicall can do to make up for the data that was lost.
Missed packets indicate network issues, which is outside the scope of our support. You will want to reach out to your Network Administrator to troubleshoot the missed packets between servers.
