Content server re-registering to VCS-C

[aaronmwu1]

I have a TCS S5.0 registered to the VCS-C X7.0.1.  About every day I get emails from our TMS stating that "The system has changed the gatekeeper status"

Gatekeeper address:	10.xx.xx.xx
E.164 Alias:
Gatekeeper status:	Registered

System:	ASH-TCS -   ASH-TCS01.network.abc.com
System Status:	Idle
System Type:	TANDBERG Content   Server
Software:	ASH-TCS S5.0
Hardware:	49AXXXX -

(modified IP address and alias)

In the VCS event log I see its re-registering all of our recording aliases, this is one of the examples:

Jul 10 08:55:26	tvcs: Event="Registration Accepted" Service="SIP" Src-ip="10.xx.xx.xx" Src-port="5060" Protocol="TCP" AOR="TCS-abc@abc.com" Contact="sip:TCS-dmvanita@10.xx.xx.xx:5060;transport\=tcp" Duration="30" Level="1" UTCTime="2013-07-10 12:55:26,177"
Jul 10 08:55:26	tvcs: Event="Registration Requested" Service="SIP" Src-ip="10.xx.xx.xx" Src-port="5060" Protocol="TCP" AOR="TCS-abc@abc.com" Contact="sip:TCS-abc@10.xx.xx.xx:5060;transport\=tcp" Duration="30" Level="1" UTCTime="2013-07-10 12:55:26,175"

(modified IP address and recording aliases for identity)

I don't see any errors on the VCS event logs or any issues when I ran a TCP dump from the VCS (according to our network techs).  Any experience this issue before?

[Martin Koch]

Besides the fact that there are updated versions out and you might want to think of upgrading to X7.2.2 and S5.2.

Did you try to reboot the TCS? Its a windows server, would not be the first time that a strange tcs behavior gets

fixed by a restart.

That the error looks like h323 the logs are sip registrations.

I can not see something here with TC5.2, VCS X7.2.2 and TMS 13.2.1

When h323 connection get lost its most likely a router/firewall/l3-gw in between which

has some timeout value or layer3 functionality. I would check on that, especially the

l3 (alg, inspection, helper, ...) features are often overseen by the network admins,

some might not even show up in the config untill you disable them.

[aaronmwu1]

We do plan to upgrade soon, I didnt see anything in the release notes of the newer versions that will resolve this issue.  Other than the S5.2 release notes "corrected an issue where the content server would not handle a default VCS registration expiry time of 45 seconds"  Right now the expiry time is set to 30 seconds on the VCS, would that be the issue???

We have rebooted the TCS multiple times already.

There is no firewalls in between the TCS/VCS/TMS, they are on the same switch on the same rack.

[Martin Koch]

As the message said the status changed, do you have the message before that?

I mean this one says its registered, so its the one how it should be, shouldn't be there one

which shows the failed event?

Did you check the bug toolkit for vcs, tms and tcs could also be a reporting bug.

Also look deeper in the eventlog and also the registration history of the vcs.

Also the logs of the TCS might tell you more.

The 45sec sounds like the sip timeout. Anyhow can you make a screenshot of the h323 and sip settings and timeout values of the VCS, maybe somebody else has an idea.

Aaron: Please rate my postings if you think they were helpful :-)

[aaronmwu1]

I would receive these messages before the registrations of the recording aliases:

Jul 10 11:34:35

tvcs: Event="Registration Removed" Reason="Endpoint unresponsive" Service="SIP" Src-ip="10.xx.xx.xx" Src-port="5060" Protocol="TCP" AOR="TCS-abc@abc.com" Contact="sip:TCS-abc@10.xx.xx.xx:5060;transport\=tcp" Level="1" UTCTime="2013-07-10 15:34:35,347"

I'll have to double check the bug toolkit as I didn't see the issue there before.  I have attached screen shots of the VCS H.323 and SIP settings.

[Martin Koch]

If its really the sip registration then at least you could try to increase the timeouts, but then it would

be a TMS reporting bug in addtion ;-)

Can you try to increase the sip timeout.

Can you try try: sip

standard reg. refresh min.: 300

standard reg. refresh max.: 600

not sure if you run a cluster, but then sip outbound might be anyhow

better than using the quite short timeouts.

We are even running much longer timeouts (needed for example for the power saving of the

jabber video ipad client) and do not have any problems.

And upgrading your infrastructure might be a good idea anhow.

[aaronmwu1]

I increased the SIP timeouts to min 300 and max 600 and still have the same issue.  We do not run a cluster.

[Martin Koch]

Not sure, which hardware do you run? So if you have the new one, upgrade to S5.2

and also the VCS to X7.2.2 (though I would think if there is really no router in between

that its more the TCSs fault) and see if this fixed your issue, if not I would open a case

towards TAC, you can escalate this thred on the right top to a service request.

If you think this was helpful, please rate the answers using the stars below.

[Magnus Ohm]

Hi

I concur with Martin when it comes to upgrading your systems to a more recent version.

As I understand this issue is only visible in TMS as a message that the gatekeeper status has changed but there is no real issue as the TCS has re-registered?

An obvious question that falls into my mind is if you have always seen this symptom since deployment? If you have been running the same versions for a while and you suddenly start to see this symptom it could be related to the TCS.

TMS reacts on events and the event might be legit from a TMS perspective as it reflects what it gets in even if the TCS re-registers and the issue is gone.

I would try to run the repair function on the TCS server.

ControlPanel --> Add/Remove programs --> TCS Software --> Change --> Repair and follow the wizard

Backup your TCS before doing this (I never seen a issue running this before though but just in case )

The repair will restart all services and verify all settings and fix minor issues which includes services that might be in a bad state... It could be an alternative to try if an upgrade is not just around the corner..

/Magnus

[Wayne DeNardi]

With the "Endpoint Unresponsive" error, I'd look at the network connectivity of the TCS box... is almost looks like that the box is not being contactable for a period of time, so the system is dropping the registrations, then when the connectivity returns, the TCS is re-registering itself.

Note: S5.3 is the latest version of software for TCS.  We're running that here (with VCS X7.2.2 and TMS 14.1.1).

[Magnus Ohm]

Indeed wayne and if you look in the windows eventlogs under system log look for tcp/ip events. If you see that the nic is disconnecting it might also indicate a hw issue. But usually this sceanrio causes the tcs to freeze.

/Magnus

Sent from Cisco Technical Support iPhone App

[MIKE ZINNER]

I had a similar problem and fixed with this little batch file that runs every night at midnight.

net stop TCSCE

net start TCSCE

Save it with the extension .bat then use Windows task scheduler to run it every night at midnight, or whenever you're least likley to have someone using it.  Since I did that, I've not had it unregister.

[Brian Meade]

I came across this today from google.  I found there's a bug created for this that is a duplicate of another bug:

This redirects to the following bug:CSCuh76732

https://tools.cisco.com/bugsearch/bug/CSCue78942