Problems with autoconnect and double-calling

[Nick Halbert-Lillyman]

I'm having some issues with TMS autoconnect.  In TMS Administrative tools > Conference Connection/Ending Options, there are options for connection attempts and connection timeout, but I can't see any options for time between connection attempts.

This leads to endpoints sometimes recieving two calls from the MCU (TS 8710) at the same time, sometimes connecting twice, once as audio-only.  The second connection attempt starts while the first conneciton attempt is still ringing.

Does anyone know how I can set the time between attempts, or can suggest another way to avoid endpoints being called twice at the same time?                   

[Martin Koch]

You use a vcs? Sounds a bit more that this could come from the VCS. Did you check in the

call logs if its two calls from the TS or if the call gets forked by the VCS?

Typical scenarios, findme, matching search rules with the same priority, loops, cpls, ...

[Tomonori Taniguchi]

The time between connection attempts should be almost identical as Connection Timeout but may have additional 1 or 2 seconds for new connection message process.

As Martin mention, if deployment with VCS and have multiple search rules with same priority, VCS may send multiple setup/invite to Endpoint/UA.

Typical case if you have two search rules (for example one with alias only for H.323 and one with full URL for SIP) with same priority (and far end device registered on VCS both with H323 and SIP), device will receive two incoming call almost same time (time gap due to signaling process).

If there is search rules with same priority (or findme with same ringing group), I suggest to modify the priority configuration and retest your scenario to see whether that help resolving the issue you are experiencing.

[Nick Halbert-Lillyman]

Looking through the logs, here's what I've observed:

VCS search history shows 3 calls, 30 seconds apart (which is consistent with our TMS settings - 3 attaempts with a 30 second timeout).

The first search is "Found", the next two searches are "Cancelled".  This is consistent with me answeing only one call, then ignoring the subsequent calls that came in once the first call was connected.  Note that I didn't answer the first call until the second had started ringing - i.e. I had two incoming calls.

TS Server logs show two "endpoint" entries for the same URI -

e.g.

endpoint 3074: tearing down call to 123@ourdomain.com

endpoint 3075: tearing down call to 123@ourdomain.com

Note that this issue seems to be intermittent and I can't reproduce it consistently, but it's definitely happening to a number of our users - I log onto TS Server during thier scheduled conferences and can see them connected twice etc.

Is there somewhere else on VCS I should be looking other than search history?

Thanks in advance!

[Tomonori Taniguchi]

What version of TMS in your deployment?
There is few conference management bugs related call retry which has been fixed with TMS13.2 (but this bug that TMS won’t complete retry call as configured so bit different from what you are experiencing).

I suggest to take diagnostic log (debug level) from VCS, H.323/SIP log from 8710 TPS and conference log from TMS to understand what call has been initiate and initiated by which product.

BTW, does endpoint 3074 and 3075 tearing down in same timing in log?

[Nick Halbert-Lillyman]

I'm running TMS 13.2 (not 13.2.1)

Yes, endpoints 3074 and 3075 get torn down at the same time in the logs.

OK I'll have a go at getting those logs.

[Nick Halbert-Lillyman]

While I did manage to capture logs, they are probably a bit big to post here (I've logged a TAC case though).

After further testing, here's what I've observed:

Our TMS is configured for 3 connection attempts with a timeout of 30 seconds for each attempt.  If I don't answer the first connection attempt, after 30 seconds it makes another attempt - the problem being that the first one doesn't stop ringing, so I've got two incoming calls.  It wil then start a third call after a further 30 seconds (i.e. 1 minute after the scheduled start time), meaning I have 3 incoming calls at the same time.

Should the first call stop ringing after the configured timeout value in TMS?

[Tomonori Taniguchi]

Interesting…, I just tested this in lab but couldn’t replicate two incoming call…, but I don’t think TMS send “disconnect” message before sending out dial command to MCU for Endpoint yet establish the call.

The quick workaround is to set CPL on VCS and proxy the call for 25 sec. (if call setup timeout is 30 sec. on TMS schedule conference).

With proxy timeout configuration, VCS will manage how long allow device to “ring” calling far end device.

This may useful no only this specific case but the case you don’t want personal VC next of you kept ringing (or VC system in board member office kept ringing for a while…).

[Nick Halbert-Lillyman]

Thanks very much - I've never really worked with CPL - are you able to tell me how to configure as you have described, or point me to relevant documentation?

[Tomonori Taniguchi · Accepted solution]

Here is simple CPL for managing call setup timeout.

Assume all endpoint registered with xxx@customer.com as device URL and you want to disconnect the call in 25 sec. if far end device doesn't accept the incoming call.

=== Sample CPL ========================

http://www.tandberg.net/cpl-extensions" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd">

*@custer.com">

=======================================

1. Create CPL file with extension ".xml" (for example AutoTimeout.xml, just copy above sample and save it as .xml file).
2. Upload CPL file to VCS from VCS Configuration > Call Policy > Configuration, "Select the new Call Policy file", then click "Upload file". 
   • If successfully upload the CPL file, then you should see "File upload successful" message on GUI.
   • You may review CPL that has upload on CPL by clicking "Show Call Policy file" in same page
3. Change Policy mode to "Local CPL".

Now ready for making test call. If Endpoint doesn't accept the call within 25 sec., then VCS will terminate the un-answered call.

BTW, if you want to disable CPL temperately, you may change “Call Policy mode” to “Off” without removing uploaded CPL file.

[Nick Halbert-Lillyman]

Thanks very much.

For the above to work, does VCS need to be able to access the tandberg.net and w3.org URLs?

The network that the VCS is on does not have internet connectivity...

[Tomonori Taniguchi]

The CPL should works without accessing those link…(I believe...).

Just tested same CPL with VCS that doesn’t have default gateway and verified that CPL still works as expected.

[Nick Halbert-Lillyman]

Thanks so much, I will try applying CPL and report back.

[Nick Halbert-Lillyman]

OK  - this looks it has worked, thanks Tomonori!

I'm still interested as to why TMS doesn't make TP server disconnect, but this definitely gets me out of trouble.

[Tomonori Taniguchi · Accepted solution]

Good and thanks for sharing the result which will help other may experience same challenge or looking for additional solution.

Especially with large deployment, disconnecting the unnecessary call (not set to auto answer and a way from device) will utilize the VCS resource as well as it will free up call resource on VCS as well as MCU (while ringing, it still hold resource).

So not only this particular case, this type of call management may become handle for managing deployment and resource utilization.