TMS vs MCU redial behavior

[Patrick Sparkman]

Within TMS there is an option, "Connection Attempts for Scheduled Calls" and a coorisponding "Connection Timeout for Schedule Calls (in seconds)".  There is also a similar function within the 8510 MCU, "Failed preconfigured participants redial behavior".

1. We schedule all of our meetings within TMS, how do these two systems coordinate the redial of failed calls and participants, or do they at all?
2. When using a TMS, does it override the MCU's redial function?
3. Since TMS adds all scheduled calls into the preconfigured participant list, which method of redial behavior would be the most benificial or pratical since it is found within both the TMS and 8510 MCU?

[Tomonori Taniguchi · Accepted solution]

The "Connection Timeout for Scheduled Calls" on TMS and the "Failed preconfigured participants redial behavior" on MCU provide similar redial service.

If you use "Connection Timeout for Scheduled Calls" on TMS, then "Failed preconfigured participants redial behavior" on MCU should be configured as "Never redial".

For recommendation, if you are monitoring CCC and conference log on TMS, recommend to use "Connection Timeout for Scheduled Calls" on TMS so that you able to manage log of redial call instead of waiting of call status update from MCU.

[Patrick Sparkman]

What would be a good combination of settings for "Connection Attempts for Scheduled Calls" and "Connection Timeout for Schedule Calls (in seconds)"?  Idealty I would like for TMS to do is redial a failed call for up to atleast 20 minutes.

I like the MCU's redial method and timing for a failed call, however since we use TMS, I'd like to try to stick to it managing the redialing.

[Tomonori Taniguchi]

Yes, if you manage schedule conference by TMS, I’d recommend using "Connection Timeout for Scheduled Calls" on TMS for redialing feature.

Please note we have improve robustness of this feature (fixed few issues relating this feature) on TMS13.2 release, therefore highly recommend using TMS13.2 or newer release.

[Patrick Sparkman]

Yes, we're on 13.2.  According to the help documentation for TMS, these two options work together to initate failed call redialing.

To acheive the redial of a failed call for up to 20 minutes

• What would the suggested timeout (in seconds) be for a call?
• What would the suggested # of attempts be for a call?

I suppose what is stumping me is if I have a timeout of 5 minutes, does that mean 1 attempt will last for 5 minutes.  How does the timeout in seconds relate to the attempts and how long TMS will try to redial (total time for all attempts)?

From your earlier message, now that I know they will work side by side, I'll disable the MCU redial method.

[Garvan Long]

When you are testing this make sure you are in front of an enpoint thats part of the schedueld call to see what impact it has on the users. When i tested this previously you would get a message on the screen for each call attempt which can be distracting to participants and in some case i belive we were also getting an audible beep for the connection attempt when using the MCU.

This featue relies on the users being well behaved and system being left on. Many customer scenarios the VC units are booked for a site and no one turns up for that venue to turn the system on or answer the call

[Tomonori Taniguchi · Accepted solution]

The parameter of "Connection Timeout for Scheduled Calls” is the number of seconds to wait for a successful connection before making redial call.

So if you configure 300 seconds on “Connection Timeout for Scheduled Calls”, TMS will wait 300 seconds before timeout that particular call cycle and this time start counting from call initiation of that particular call cycle.

If a system does not connect within this time, the call will be disconnected and retried the number of times set in the Connection Attempts for Scheduled Calls.

So if you would like to redial scheduled participant up to 20 min from conference starting time in every 1 min. cycle, then configuration should be follow.

Connection Attempts for Scheduled Calls: 19

Connection Timeout for Scheduled Calls (in seconds):   60

TMS attempt redial 19 times starting after approximate 1 min from conference starting time (assume Endpoint is boot up before schedule conference time) and last redial call make approximate 19 min after conference starting time (just few seconds later than 19 min.).

So there is no additional redial call initiated after 20 min of conference call started.

[Patrick Sparkman]

@Garvan

All of our primary endpoints are set to auto answer, so once TMS starts a conference all endpoints get connected right away, unless it's a Movi user of course.

@Tomonori

Thanks for the clarification, I figured it was something like that, however I just wanted to make sure.

[Tomonori Taniguchi]

No problem, I have seen one customer configure timeout to 30 sec. & attempts number to 29 times which redial up to 15 min from conference starting time (works it perfectly as designed).

Personally conference redial should be kept within 10 min otherwise people may start waiting for conference to be start for long time or need to re-explain initial discussion for those participated quite late phase.

[Patrick Sparkman]

Yeah, I'm still trying to think of a reasonable amount of retries vs time between retries.  Since most of our primary rooms are auto answer, the redial is mostly for those that are using an E20, Movi, or anyone external to our organization.  A little bit of a relief so we don't have to site by TMS to try to keep getting those participants reconnected.  We always schedule our conferences with a 15 minute buffer to the start to allow for endpoints/participants to get connected and to weed out any technical issues that might arise.  So in our case our redial attempts will take place during the buffer up to at least the start of the conference.

[Garvan Long]

I see quite a few people schedule dial out to Movi but personally i  find it a bit strange to schedule a dedicated device.

I would try and replicate existing behaviour for audio confernce calls. Movi and E20 should be considers similar a desk phone which you dont typically schedule  and dial out to as part of an audio conference  as its not a shared resource. The user typically dial in for an audio confernece from thier chosen device.

I think the main reason people dial out to users is because the default information from TMS indicating  how to connect to the call may not be that clear to the average user and it percived as easier to dial them than try and explain.

As long as it works and the users are happy with the end result that all that matters.

[Patrick Sparkman]

Garvan Long wrote:
I think the main reason people dial out to users is because the default information from TMS indicating  how to connect to the call may not be that clear to the average user and it percived as easier to dial them than try and explain.

You actually hit it spot on Garvan!  The reason why we schedule and dial out to E20 and Movi endpoints within our organization.

We deal with alot of faculty and staff at our college, most would rather just have to deal with their duties and know when it's time for a conference their involved in that we being the IT department will automatically handle and intiate all of the calls on our end, which leaves them to deal with their regular duties within the college.