Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Telepresence Server, Active Control drops conference after 30 seconds

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:

32714:17:09.170 APPInfoconference "8080.MeetMe_mtg" created
32814:17:09.264 SIPInfoIncoming call from 192.168.33.xxx:37124
32914:17:09.264 APPInfocall 24: new incoming SIP call from "15@xxx.info"
33014:17:09.379 APPInfocall 24: "Buero_EX60_Test" now joined conference "8080.MeetMe_mtg"
33114:17:09.386 IXInfocall 24: Connecting unencrypted to 192.168.xx.xx:31135 for protocols: ping,xccp
33214:17:09.814 CMGRInfocall 24: ActiveControl negotiated
33314:17:46.736 SIPErrorcall 24: Ending call due to INVITE transaction timeout
33414:17:46.736 CMGRInfocall 24: disconnecting, "15@xxx.info" - timeout
33514:17:46.736 APPInfocall 24: tearing down call from "Buero_EX60_Test" - destroy at far end request; timeout
33614:17:46.736 SIPErrorcall 24: BYE transaction failed due to network error
33714:17:46.740 SIPWarningCannot determine destination transaction for incoming message
33814:17:46.741 SIPWarningReceived out-of-call request
33914:17:48.989 APPInfoconference "8080.MeetMe_mtg": deleted via API (no participants)

 

 

Everyone's tags (2)
1 ACCEPTED SOLUTION

Accepted Solutions
New Member

From the Conductor log it

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

4 REPLIES
New Member

From the logs you shared and

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

New Member

Hello Nick,thanks for your

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.

 

New Member

From the Conductor log it

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

New Member

Dear Nick, thanks a lot. CUCM

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.

1472
Views
10
Helpful
4
Replies
CreatePlease to create content