MST decode / approx. 2% of callers cant be heard

[markukug]

Is there a way to convert/decode MST logs without being tier 3 or 4 engineer?

Any help is appreciated. Thanks in advance

We currently have an issue that (randomly) approx. 2% of the calls cant be heard by our agents (caller can hear us) and the caller then is being transferred somehow to antoher agent.
In CDR we find calls from the same caller at the same time answered by different agents of which at least one agent cant hear the caller.

[pre]The Software Version SMI page displays the software version of the active partition of this server.
Operating system: Linux 2.6.32-504.8.1.el6.AV3.x86_64 x86_64 x86_64
Built: Apr 1 10:18 2015
Contains: 00.0.441.0
CM Reports as: R017x.00.0.441.0
CM Release String: vcm-017-00.0.441.0
RTS Version: CM 7.0.0.2.0.441.22684
Publication Date: 25 June 2015
VMwaretools version: 9.4.10.37835 (build-2068191)

UPDATES:
Update ID Status Type Update description
--------------------------------- ------------ ----- ---------------------------
00.0.441.0-22684 activated cold 7.0.0.2.0-SP2

Platform/Security ID Status Type Update description
--------------------------------- ------------ ----- ---------------------------
CM Translation Saved: 2019-02-25 01:00:12
CM License Installed: 2019-02-15 11:24:20
CM Memory Config: Large[/pre]

 

[kyle555]

Got it from these forums... if you run a MST with trace analyzer enabled and you have dadmin, this line would decode everything on May 3rd from 11-12.

You probably won't understand much beyond the SIP messaging, which you could just as easily get from a traceSM. It'd at least prove CM is doing something funky that's worth patching. 7.0.0.2 is pretty old and early in the 7.0 stream.

/usr/bin/sudo /opt/ecs/bin/logc -c 'view%mta' -t 0503:1100-0503:1200 > /tmp/mstdecoded.m

 

[markukug]

Thanks kyle555. Unfortunately the command provided
"/usr/bin/sudo /opt/ecs/bin/logc -c 'view%mta' > /tmp/mstdecoded.m"
is not delivering a result due to "not authorized"-message.

User not authorized to execute mta, contact AVAYA
The reason may be that ACM is not running or
the Trace Analyzer may be disabled in ACM admin.

I now used "Definity Analyzer" Software to find out that this kind of calls exist and appear within a few milliseconds with very little difference in the trace.

Differences are:
- call reference: ALERTING: A5A5(9637) vs DD50(23888)
- timestamp: SETUP: 08:33:47.200 vs. 08:33:48:180
- Channel number / slot map: CALL PROCEEDING: 3 vs 12
- CONNECT: 40 01 ... vs 40 02 ...

Very suspicious: the same calling number at (almost) the same time on two different slots.