AMTMitelCRE release notes: version 1.6.3.25 to 1.6.4.9

Notes on the latest release of all Amethyst Applications

Moderators: Leon van Heerden, Luanda_Junzi, Belinda Frick, Lee Hendricks

AMTMitelCRE release notes: version 1.6.3.25 to 1.6.4.9

Postby Belinda Frick » Thu Jun 21, 2012 2:28 pm

AMTMitelCRE version 1.6.3.25
  • Fixed bug in the jitter buffer - previous timestamp was not being cleared (this caused new RTP streams to be checked against the timestamp of the previous stream).
  • Fixed bug where last packet of each RTP stream was not being processed.
  • Reference numbers counter portion is now shorter (6 characters instead of 8). This allows up to 16,777,216 recordings per day in 6 hexadecimal characters. If they do more than that, it will simply expand to 7 characters.
  • Disabled on-startup processing of previously recorded RTP files.
  • Created Windows version of SaveRecCount - this was just for compiling the Windows version and doesn't do the synchronising to disk.

AMTMitelCRE version 1.6.3.26
  • RTP packets are now cleared from the UDP receiving threads when a recording stops - previously only the data already taken from the threads was being written to disk.
  • RTP packets received while a tap is not recording are now discarded instead of being kept in the buffers - this is the same behaviour as the old RTP receiving code.

AMTMitelCRE version 1.6.3.27
  • Fixed bug in TRecCount - was creating daily files instead of yearly files.

AMTMitelCRE version 1.6.3.28
  • Waits 2 seconds for the AMTMitel data before processing a recording.
  • Now prints DTA information to the log, same as cardservers do.


AMTMitelCRE version 1.6.3.29
  • Forgot to check the "waiting for amtmitel" recording list when call info arrived.


AMTMitelCRE version 1.6.3.30 (not for release)
  • Reduced AMTMitel call info request delay from 2 seconds to 500 milliseconds. This is to reduce the chance of getting incorrect call information. In testing, it didn't seem to make much difference as there were problems elsewhere (now fixed).
  • Last request is now delayed as well. AMTMitel was still processing the announced transfer event when this request came through on announced transfers.
  • Removed "Recorded(DT2)" log entry as it was not giving useful information.

AMTMitelCRE version 1.6.3.31 (not for release)
  • This should actually be 1.6.4.0.
    Added RTP statistics in the new DTA extrainfo field (total packets, lost packets, delayed packets, codecs used, etc).
  • In debug mode, the RTP codecs used are placed into the DTA reference field (trying to narrow down a Mitel WAN issue at Reeds).
  • Problems with recordings are now indicated by setting a system marker at position 1 (marker is "*1").
  • Potential issues in this version:
    • extrainfo is declared as ShortString in the DTA structure in the CRE. I think this will cause problems as more data is added.
    • the Mitel appears to be sending every 19.57 ms (approximately). This causes the delayed calls code to think we should be at a different time than we are. I think this code may be wrong, but Johan has asked me to change it to only report delays in consecutive packets.
    • Currently it marks a recording as problematic if any packets are lost or delayed for more than 100ms. Johan has asked me to make it 5 lost or delayed packets (where delay is 50ms or more late). To make that clear, problematic = (lost + delay >= 5)

AMTMitelCRE version 1.6.4.0
Fixes for RTP statistics:
  • Delayed packets calculation cannot work, as the Mitel sending rate is not exactly 20ms. Changed to consider a delayed packets as delay > 50ms between consecutive packets. The previous code is now called SlowPackets, but is not used in this version.
  • Only 5 lost or delayed packets are now considered to be a problem recording.
  • Fixed problem where locale issues cause the ThousandSeparator variable to be blank.


AMTMitelCRE version 1.6.4.1
  • Fixed bug in jitter buffer code - when there was a large gap in the data (bigger than the jitter buffer), the starting timestamp would be set correctly to the size of the jitter buffer. Then the code that tries to ensure the RTP interval is correct would choose the closest match in the jitter buffer (i.e. the packet with the timestamp causing the large gap). I've disabled that code in the case where the jitter buffer has overflowed. I'm not sure this is the best fix.
  • Now uses payload 96 as DTMF, even if the XML data says DTMF is payload 101. I've left this hard-coded, as I don't think it will change easily on Mitel.
  • The first lost packet is no longer counted as a delayed packet.


AMTMitelCRE version 1.6.4.2 (not for release)
  • Fixed major bug where the CRE would almost always be killed off if it tried to process a 2 GB PCM file. The problem is that the Delphi SetLength function for dynamic arrays causes an access violation when it tries to create a 2GB array. The Free Pascal version works perfectly, and just raises an out-of-memory exception.
  • Fixed bug where CRE would not create a recording if the RX SIF file exists and is zero bytes.
  • Added support for handling new format of filenames in ProcessOldRTP (not used in non-debug code as yet).
  • Fixed minor bug where PacketProcessor was not being freed.

AMTMitelCRE version 1.6.4.4 (not for release)
  • Fixed bug where recording before external start message was not being processed.
  • This version also fixes a bug where only one side of the external call control recording was being made.
  • This version seems to have a bug where the external call control recordings are filled with static - not sure why as yet.


AMTMitelCRE version 1.6.4.6 (dialer decryption)
  • Added code to handle requests for enabling/disabling encryption for a specific DN. Decryption is done by asking the SRC to decrypt for us, increasing the load on the SRC. The actual procecedure is done by removing the taps, and adding them back without encryption. The only issues are that if a call is already taking place, the SRC doesn't re-send the "stream start" message, but does change the stream already being sent to the unencrypted form, so the CRE has to jump through a few hoops to fix the current recording (see TPacketProcessor.InitRecording and TTappedDevice.SetEncryption).
  • Preferred IP is now reloaded. Hostname is re-read on a reload. The preferred IP is due to an issue found at a client when changing the network settings on a machine with multiple interfaces.

AMTMitelCRE version 1.6.4.7
  • Added option to not record immediately after encryption is enabled or disabled (Avaya dialer integration).
  • Added option to ignore large gaps in RTP timestamps (work-around for Mitel RTP bug).
  • Fixed potential bug in live listen where it was not using the correct SRTP parameters for unencrypted recordings.

AMTMitelCRE version 1.6.4.8
  • The CRE can now associate a third-party reference with a recording if that reference is provided by AMTMitel (requires AMTMitel version 1.6.4.0).
  • Codecs are no longer written to the reference field in debug mode.

Amethyst MitelCRE version 1.6.4.9
  • Changed encryption disable / enable to wait for previous instruction to finish before trying a new one.
Belinda Frick
 
Posts: 3808
Joined: Fri Nov 12, 2010 4:25 pm

Return to Releases

Who is online

Users browsing this forum: No registered users and 1 guest