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
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
Any Input still appreciated.
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
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 PM||Gatekeeper Registration||Gatekeeper IP Address: E.164 Alias: Gatekeeper Status: Registered|
|9/15/2013 9:50:26 PM||Gatekeeper 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.
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.