Showing results for 
Search instead for 
Did you mean: 
Georg Kehrer

VCS-E Registration, Endpoint unresponsive

Dear All

I have the follow Situation:

- some EX90 and some Profile52(C-40 Codec)

- registered on VCS-Expressway with SIP and with H323

- Authenticated on the VCS-E via Local Database

Both System are "managed" via "Behind Firewall" and both system have access to the phonebook of the TMS

via HTTP

All thing works fine very well.

But now from Time to Time, the endpoints are makes an re-register, because  Endpoint unresponsive.

(Event="Registration Removed" Reason="Endpoint unresponsive" )

But still after a few second are see the message on the VCS-E endpoint still registered.

The interesting effect is that the Phonebook Directory which comes from TMS are not visible anymore,

until are makes an re-register on the VCS, after that the Phonebook on the VC Endpoint are visible.

Now it exists the parameter on the VCS (H323 protocol) "time to live" which has default of 1800 second.

How high can I increase this parameter?

Endpoint TC 6.1.2

VCS-E (7.1)

TMS (13.1.1)

Any Input still appreciated.

Best Regards


Alok Jaiswal
Cisco Employee

Hi Georg,

you can go maximum upto value of 65534. I think you should set the value to 1hr if you want to but i don't think this will resolve the problem.

If the endpoint is not register obviously it can't request for phonebook.

Again i will ask you to check is your firewall not blocking any thing? before the registration expires endpoint should send a re-regitration message. if for some reason VCS doesn't see it coming it will assume endpoint is un-responsive and removes the registration.



How is the system set up? Via provisioning (that would explain if the phonebook is received via the vcs) or

via TMS-Systems navigator (thats where you see "behind firewall").

In the case of the old style systems navigator the phonebook is a http(s) request to the tms which needs

to be public reachable.

Only one kind should be configured. That needs to be sorted out first.

If you use auto generated phonebooks an the systems navigator style management,

the TMS would remove the endpoints which are not reachable

but thats only that this specific endpoint would not show up in other phonebooks and not that it would not receive it.

But that all sounds more like symptoms and not like a cause.

Especially the h323 part has nothing to do with receiving the phonebook

This might also be caused by a firewall or router which closed the connection. I would say the

increase of the h323 timeout is even counterproductive if its a firewall/timer issue.

I would check on the routers/firewalls in between your infrastructure and this endpoint

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

Please remember to rate helpful responses and identify

Georg Kehrer

hi All

Regarding the point Firewall, there is on my Site nothing which can block., I have also no Problem this solution is working a long time go, but from time to time (~once per week)  I^ve got the Message:

9/15/2013 9:50:26 PMGatekeeper RegistrationGatekeeper IP Address: E.164 Alias: Gatekeeper Status: Registered
9/15/2013 9:50:26 PMGatekeeper Registration

Gatekeeper IP Address: E.164 Alias: Gatekeeper Status: Rejected

When I have this situation many time there exits not a problem, but I have also seen that the VC was registered with H.323 on the VCS but I haven't seen the Phonebook with the H323 entrys, as soon as make en re-register (de-register on the VCS) was the Phonebook correct.

That's so interesting, because the VC Endpoint has made a register again, system is also reachable via Alias.

I think the Problem could be if we have a short interrupt on the Internet or something else.

If I have also asked the Customer site, an he told me and show me that he has no interruption on his line.

So, I think I will increase the time to live and will see whats happen, is an attempt.



Sure you can try and keep us updated, but I would have the feeling that this is contra-productive.

Try to see if you can find a patern, like a specfic time when registrations get unresponsive or a specific duration of the registration or since the last call was made or something like that.

It would be great if you can predict when it is going to happen, then I would recomend to do a trace

upfront your vcs and on the endpoint of the customer, best starting 2 hours before the problem would occur

and then compare.

I still have the feeling its a layer3 problem.

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

Please remember to rate helpful responses and identify

Georg Kehrer

I have now tested with a time to live of 3600 sec.

(In the meantime I have tested with a EX90 which is only H323 registered)

So we have thought, this was not the problem, I have still the problem that the system was registered on the VCS-E (according the status on the EX90 and VCS-E everything OK)

But the Phonebook from the TMS, I saw all entrys with SIP protocol, than I have made a Re-registering (ON/OFF Gatekeeper on EX90) and see all entry comes as H323 entrys.

So Ihave update my system TC6.2.1 and will see whats happen in the next days.

Maybe also a Problem with TMS 13.1

The problem is I can't so easy to move 14.3.x.



If the endpoint is behind a firewall towards the TMS it can also be a BUG that the

Endpoint does not properly talk to the TMS anymore.

The impact / behavior of your issue might also be depnedent on your TMS settings

(routed pb entries, refresh time for phonebooks, ...)

Like I said before, it smells you use type: Cisco TMS endpoint phonebooks,

your deault call protocol is h323, the h323 registration for the endpoints fails,

the h323 phonebook entry for the system is removed, but they are still registered

with sip so tms publishs the sip entry which you can then see on the endpoint.

Check on the endpoint if it still thinks its h323 registerd

As I said before, this is most likely some Layer3 capability (ALG, NAT-Helper, Inspection. ...) messing with the registration.

Before you can not rule that out 100% (and most enterprise grade firewalls have these feartures

enabled by default and you might not see it in the config until its disabled)  that this is not disabled

its not worth looking into it any further.

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

Please remember to rate helpful responses and identify

Recognize Your Peers
Content for Community-Ad