Just had a useful session with a Shoretel TAC guy – the problem being dropped calls when using Shoreware Communicator. The diagnosis was that there is too much jitter on the network, and it was TmsNcc.log that showed up the problem:
Here are two sides of a call from the log file – we had to get the exact time of the call and the numbers being called from and to in order to determine the call GUID. Once the GUID was obtained, we could use a find in Notepad to find the related messages:
G-MST: 4000001E "00040000-0fbf-4e89-e048-001049194446" ("192.168.3.2","192.168.0.144"),2(ULaw),rsn:1,09:23:05.602 (UTC),pl:20,(s:86, r:73, l:0),(j:2,u:0,o:0) flgs:0x00000000 "sip:TGrp_1,email@example.com:5441",vpn:0 G-MST: 2000003E "00040000-0fbf-4e89-e048-001049194446" ("192.168.0.144","192.168.3.2"),2(ULaw),rsn:1,09:23:05.568 (UTC),pl:20,(s:73, r:86, l:0),(j:3,u:0,o:0) flgs:0x00000000 "sip:firstname.lastname@example.org:5441",vpn:0
In the above, the long number is the call GUID we were searching on, and the “sip:TGrp_1” line (scroll to the right) is the incoming leg of the call, coming in off the ISDN and to the user’s softphone. You can see the IP address of the Shoregear E1K (192.168.3.2) and also of the user’s PC.
The second line with “sip:100” is extension 100 leg of the call, out via the trunk.
The statistics are a bit cryptic for each of these lines, so let’s just look at one:
(s:86, r:73, l:0),(j:2,u:0,o:0)
This section of the logged message is saying that there were 86 packets sent, 73 packets received and 0 packets lost. The second set of figures in brackets shows values for jitter (in this case 2), underrun and overrun.
The values in the second section should all be zero in an ideal world. The j:2 part in this particular example indicates that the jitter buffer had to be adjusted twice during the call, and with a soft client this is not very well tolerated. In some instances the jitter figure was up as high as 14, which the TAC engineer told me was a killer for softphones. We’ve been finding that hard phones actually deal with this a lot better.
So, I guess we need to review the QoS on the network then… 😦