Telepresence Server, Active Control drops conference after 30 seconds

[r.rung]

Dear Support Community,

i have the following Installation:

CUCM Version 10.5(1)

Telepresence Conductor Version XC2.3

virtual Telepresence Server Version: 4.0(2.8)

EX60 TC 7.1.4

Cisco 9971, Firmware 9.4(1)SR1

Some Other Phones (7962, 6941)

All Endpoints are Registered to CUCM.

When i make a Rendezvous Conference without Active Control Enabled, everything works fine.

When i enable Active Control (according to ActiveControlDeploymentGuideR3.pdf) the conference terminates after 30 seconds.

the conference terminates even if i have only one participant in the conference and no matter which of the phones i use.

In CUCM i configured the relevant Setting in the SIP Profile (according to ActiveControlDeploymentGuideR3.pdf)

on the EX60 i can use Active Control, so i see the list of participants and i am able to change the layout of the conference within these 30 seconds.

any ideas why this happens?

the conductor log shows nothing unnormal

the Telepresence Server Log looks like this:

327	14:17:09.170	APP	Info	conference "8080.MeetMe_mtg" created
328	14:17:09.264	SIP	Info	Incoming call from 192.168.33.xxx:37124
329	14:17:09.264	APP	Info	call 24: new incoming SIP call from "15@xxx.info"
330	14:17:09.379	APP	Info	call 24: "Buero_EX60_Test" now joined conference "8080.MeetMe_mtg"
331	14:17:09.386	IX	Info	call 24: Connecting unencrypted to 192.168.xx.xx:31135 for protocols: ping,xccp
332	14:17:09.814	CMGR	Info	call 24: ActiveControl negotiated
333	14:17:46.736	SIP	Error	call 24: Ending call due to INVITE transaction timeout
334	14:17:46.736	CMGR	Info	call 24: disconnecting, "15@xxx.info" - timeout
335	14:17:46.736	APP	Info	call 24: tearing down call from "Buero_EX60_Test" - destroy at far end request; timeout
336	14:17:46.736	SIP	Error	call 24: BYE transaction failed due to network error
337	14:17:46.740	SIP	Warning	Cannot determine destination transaction for incoming message
338	14:17:46.741	SIP	Warning	Received out-of-call request
339	14:17:48.989	APP	Info	conference "8080.MeetMe_mtg": deleted via API (no participants)

[nick.mueller]

From the logs you shared and what you describe it sounds like the problem is happening during the transition from the 'lobby' screen to the actual conference.

During this transition the TP Server will send a SIP re-INVITE to renegotiate media.  It seems like CUCM is possibly not responding properly to this re-INVITE, and is improperly stripping iX protocol. This can cause the re-INVITE to fail and the call to terminate.

I would open a TAC case, but if you wish to continue troubleshooting here you should post a Conductor diagnostic log capturing from just before the first dial in until after failure so we can get a look at the SIP messaging.

I would also take a moment to confirm that you have ticked the box for iX protocol on the SIP Profile used by your SIP Trunk to Conductor as well as the SIP Profile used by your TP endpoints.  Then reset both the SIP Trunk  and the TP endpoints from CUCM.

NPM

[r.rung]

Hello Nick,

thanks for your repley.

yes the box for iX Protocol is activated in the SIP Profile for Conductor. But it is not activated for my 9971 Phone with the camera because this one uses the Default SIP Profile. i tried to configure the same SIP Profile for my 9971 Phone as my Coductor has (with "iX" enabled), but it does not solve the problem.

well it sounds quite logically what you write, i found this here in the logs:

 X-TAATag: 68628182-3415-4e99-87a5-2577ef569b11
 Reason: SIP ;cause=408;text="Failed to send out mid-dialog request due to a transaction timeout"
 Content-Length: 0

so i am in vacation now, but i will continue with this problem when i am back at work.

but if you want to have a look at the diagnostic logging from my lab environment i would be happy.

[nick.mueller · Accepted solution]

From the Conductor log it appears that CUCM is closing the connection upon re-INVITE during the transition from the lobby.

There are multiple possible reasons, but the best way to determine "why" would be to initiate a trace on CUCM.  Specifically an SDI/SDL (later versions of CUCM are SDL-only) trace on the CUCM node 10.0.2.52.  Look for the incoming re-INVITE to the IP Phone and examine the log lines nearby for a reason why.

You may also try a few other things:

#1: look in CUCM Service Parameters under the publisher, then Cisco Call MAnager for the advanced parameter "Max incoming message size" (there is an advanced button you have to click at the top to expose this parameter).  If you upgraded your CUCM from an older version, this value may need to be raised to 11000 to handle the re-INVITE from the Conductor.

#2: try disabling iX protocol on the SIP Profile to Conductor, and in the Conductor meeting alias.

NPM

[r.rung]

Dear Nick,

thanks a lot. CUCM Traces showed this:

00784488.001 |16:38:41.996 |AppInfo  |SIPTcp - Ignoring large message from 192.168.x.x:[53622]. Only allow up to 5000 bytes. Resetting connection.

so your solution #1 was correct.