A customer is reporting that when an endpoint already in an ad hoc call is then scheduled via TMS, the ad hoc call is disconnected in favor of the scheduled call. I was able to reproduce this. Here are our variables;
TMS 13.2.2
Administrative Tools>Configuration>Network Settings> set to ON
VCS X7.2.1
C90 TC6.1.1
EX90 TC6.1.1
1700MXP F9.3.1
C90 is in ad hoc call with EX90. A conference between the EX90 and 1700MXP is scheduled via the Booking>New conference page in TMS to start immediately. In the Add Participants window the EX90 is not shown to be in a conference, and so TMS does not throw a warning saying the EX90 can't be booked. We save the conference and the EX90 is disconnected from its ad hoc call, to be connected a moment later to the 1700MXP.
We have also tried this with Administrative Tools>Configuration>Network Settings> set to OFF. No change in behavior. I saw in another post where Kjetil Ree said that, "You cannot prevent TMS from disconnecting ad-hoc calls when scheduled calls are starting. Scheduled calls always take precedence." Is there really no way to change this behavior?
I saw in the TMS14.2.1 release notes a couple of Bug IDs (CSCuf79069, CSCug27660) that may be coming into play, but I didn't find the error strings in the logs.
So, the important question is: Is there a way to prevent a TMS scheduled call from disconnecting an ad hoc call in progress?
They might consider upgrading TMS as I am unable to reproduce this issue in TMS 14.2.1 - connected two systems in ad-hoc, then scheduled the same systems for immeadiate start using the Booking tab in TMS, and got the following error when trying to save the conference:
"The system is not available for booking at the requested time" and it lists the date and the system names of the two relevant systems currently in an ad-hoc call.
/jens
Please rate replies and mark question(s) as "answered" if applicable.
What you are describing is expected behavior. Scheduled calls always take precedence over ad hoc calls, and this cannot be changed.
The two bugs Bob refers to are not relevant to what he is seeing.
@Jens: When TMS discovers an ad hoc call, it considers the systems involved to be unavailable for the next five minutes (and then auto extends as the call goes along). That is why you cannot book systems that are in an ad hoc call for a new conference starting immediately.
Thank you for the response, but I am confused. I described the same scenario as Jens, but in my case TMS is supposed to replace the ad hoc call with the scheduled call and in Jens case it isn't?
TMS is always supposed to disconnect ad hoc calls when a scheduled call is about to start.
The difference between Jens' and your scenario is that for him, TMS refused to let the user book a conference that starts now; for you, TMS allowed it. But are you sure you scheduled it to start (exactly) now, and not a couple of minutes into the future?
I was 99.99% sure that I was starting conferences exactly now. After re-running my tests a couple of times I am now 100% sure that I am starting conferences exactly now. I even waited for my ad hoc call to pass the 5 minute mark before starting to schedule the call that would interrupt it.
Hmm... I now see the same as you do. Strange, as I was quite sure that what I explained earlier was the expected behavior. I'll have to investigate a bit more.
@Mahesh: I was using 14.3-beta1 in my tests ans observed the same results, so upgrading isn't likely to change anything.
@Bob: I am out of the office this week, but I'll do my best to look into this the week after. TMS's behavior here isn't properly documented in the external doc, so I think I should write a paragraph or two for our admin guide once we agree on how this is supposed to work!
