As you mention MCU. First of all it can be that you do not need or do registrations of specific conferences,
as you use a prefix registration or you have set up some kind of neighbor zone matching on it.
If its only a h323 registration you used, I am not 100% sure how it behaves as it will not be
a independent registration, it will just be a change in the exinsting h323 reg which covers all
the prefixes and e164 numbers.
If its sip I would expect to see it on the VCS reg. history as well.
In addition, depending on your software version and where you look (cli / webinterface) you
might not see all if your VCS is part of a cluster and you just looked on the other one.
And there might be more reasons why you do not find it in the registration history.
Please rate the answer using the stars below this message!
My VCS is not part of a cluster, and I am running X7.0.3. The VCS is the gatekeeper for the MCU. The MCU is setup for H323 only. I looked in the logs on the VCS for the full E.164 (100684), 100 is the prefix. Then I just checked for 684. there is nothing in the VCS-Control registration history for 7:10am, but it shows the registration successful message in the VCS-Control Event log for that time.
Yes, and if you look at the registration of the MCU in the current registrations you will see that the registration
itself has a creation time and that will most likely be further away in the past than the registration you wonder about.
Like I said its a change of the registration as the one registration contains all aliases but not a new one.
So logically speaking it does not seem to be a wrong behavior, but sure maybe confusing.
But as you see you found it in the event logs, so you know what you have to search for.
You could file a feature request for it if it bothers you.
What I dislike when I just checked it on X7.1, it shows the request and adding of the registration but not
the removal in the event log.
You will see which conference is active. Ad-Hoc or booked conferences will only register when they
get active, on ad-hoc for example if somebody is dialed in.
As I do not know your settings nor what you want to archive its hard to say if this is ok or not :-)
Do you have an issue with your conferences, or was your initial post just out of interest?
It began because I was troubleshooting the conference 100684. I wanted to check for the registrations, and that's when I noticed that I could not find it any where, past or present.
What ultimately happened today was this. I have 2 8420 media blades in an MSE 8000. There was a conference scheduled from TMS and it was put onto blade 2 using 100684. The mcu2 registered the conference (according to the event logs) to the VCS control, but when a user on an EX60 tried to dail in minutes later, the VCS transferred the call to MCU 1 and started an ad hoc. both MCUs have the same prefix, but different ranges of conference IDs.
this should not have happened, and I'm trying to figure out why. I just wanted to know why I don't see the conference registraion in the "registration" section of the VCS-Control. The way it is not is not sensible. If the MCU log states that it registered the the VCS a certain alais, then that alais should be listed in the registration page.
not 100% sure if that deployment is supported, I guess I would have used two different prefixes and properly
separate the address space.
What's the reason that you use the same prefix together with tms booking on both blades?
There are some scenarios where you can not combine all features you want, so you might have to separate them.
Depending on the settings (TMS and prefix settings on the MCU) I had seen different behavoirs regards the
aliases, sometimes the conference showed up as the full e164 number in an other case as the suffix w/o the prefix.
I had only seen trouble when ad-hoc conferences were allowed and participants had
dialed in to early and the conference got created afterwards.
In general. Maybe the TelePresence Conductor could help you or a 8510 blade with 80SD/nHD ports on
a single blade or a cluster with currently up to 3 blades = 60 HD ports.
We use multiway, and want to be able to use the capacity of both blades for multiway, so that's why the prefix has to be the same on both. It's also the perscribed method in the Multiway deployment guide for MCU capacity and resilience.
I have had problems with users calling in too early before a conference and starting an adhoc call, creating a duplicate alias ID problem on the MCU, but that is not the case today. It would be nice to disable adhoc calls, but we rely heavily on Multiway. Too bad they could not come up with a way to do multiway without adhoc enabled!