TMS not accuarately reporting SX20 system status

[Darren McKinnon]

What could be causing TMS to not accurately show the system status of an SX20?  HTTP is enabled on the endpoint and when I force refresh in TMS, it corrects what is displayed.  TMS users are getting concerned when they see a system is not in a call, while, infact it is.

I haven't noticed this with all of my SX20s, just a few, but then again, I'm not getting worked up over systems status either, usually.

TMS: 14.2.2

SX20: TC6.0.1.65

Thanks!

Darren

[Kjetil Ree]

Hi,

Could you verify that the feedback address is set correctly on the endpoint? SSH to the endpoint and do "xstatus HttpFeedback 3 URL". You would expect the value to be "http:///tms/public/feedback/code.aspx".

-Kjetil

[Darren McKinnon]

Thanks for your quick reply.  I have verified that both systems have the correct path, using the IP address of my TMS server. 

More thoughts?

[Kjetil Ree]

There are two mechanisms for updating the system status in TMS:

1. Managed systems tell TMS about connecting and disconnecting calls by posting feedback to TMS.
2. As a backup mechanism, TMS's database scanner service runs every four hours, asking the systems for an updated status.

When one does a "force refresh" manually, TMS uses the same code path as in 2), which is why one mainly should focus on mechanism 1) first.

Could you:

• Check the TMS logs for any WARNs or ERRORs. Look in log-web-public for mechanism 1) releated problems, and in log-TMSDatabaseScanner for mechanism 2) related problems.
• Provoke the problem, and then check the IIS logs on the TMS server for incoming requests from the endpoint to /tms/public/feedback/code.aspx.
• If both items above look good: Disable HTTPS on the endpoint; do a Wireshark trace on the TMS server (pre-filtering on a problematic endpoint) and look at the feedback event. You could also consider comparing the feedback event received from a problematic endpoint with a feedback event received from an endpoint you know to be good. The XML used in these events should be human readable, so it's possible to quite a bit of troubleshooting on your own.

Regards,

Kjetil

[Martin Koch]

At least when the system is behind firewall there is a bug in the TC6.

I do not really think that this is related, but you never know and TC6.0 is not the freshest anymore,

did you try to upgrade the endpoint to TC6.3 to see if the issue still occurs?

It would be interesting to see if the endpoint can properly reach the TMS, for that follow Kjetils advise

Please remember to rate helpful responses and identify helpful or correct answers.

[Wayne DeNardi]

We've seen this happen on some of our TC series endpoints before, and when it's happening we don't get any CDRs from the device in TMS either.  It's been reported as bug CSCuj79984.

Basic cause seems to be that the HttpFeedback 3 URL gets lost on a reboot of the codec, then it has to be forced to pick up the right setting again which stays in place and works as expected until the next reboot/power outage.

Wayne

--

Please remember to rate responses and to mark your question as answered if appropriate.

[Wayne DeNardi]

From our testing this morning, the feedback URL and missing call detail records we were seeing (mentioned above) seems to have been fixed in TC6.3.  Were you able to try TC6.3 on your devices Darren?

Wayne

--

Please remember to rate responses and to mark your question as answered if appropriate.

[Darren McKinnon]

I am having this issue right now.  The codec in question is still running TC6.0, however, the feedback URL is correct. I'm not certain how to check the logs mentioned above.  Where do I find the IIS logs? 

[Darren McKinnon]

I've upgraded the 2 SX20 codecs in question to TC6.3 and I'm waiting to hear from the site admin if they are still experiencing the problems.  I think things have been good for the past week since the upgrade.

[Wayne DeNardi]

Thanks for keeping us up to date Darren.  I can confirm that TC6.3 has fixed all the issues we were having with the devices not reporting and the feedback3 URL being lost on reboot.  Hope it fixes the issye for you too.

Wayne

--

Please remember to rate responses and to mark your question as answered if appropriate.

[Magnus Ohm]

Hi

The bug is set to fixed in TC6.3, tests done so far on this version shows that the issue is no longer reproducible.

/Magnus