Showing results for 
Search instead for 
Did you mean: 

Conductor with Virtual TP - UCM Centric - transaction timeout


I've just added Conductor and virtual TP Server to my CUCM 8.6.2 in order to provide videoconferencing capabilities for all my endpoints (standard IP Phone 8945 / 9951, MX200, CTS , TX9000) using Ad Hoc.

RendezVous is not configured yet.

Here are my versions : Conductor XC2.2.1 , TP Server (virtual) 3.1(1.96) , CUCM, phones with up to date fw.

Conductor is added as a conference bridge on CUCM and is registered. TP Server is active as a conference bridge from Conductor point of view.

When doing an Ad Hoc conference from 3 * ip Phone 8945, I've around 30 seconds video (and only 1 pip at the bottom of ip phones screen) then it hangs. Around 30 seconds later session is automatically disconnected on one of the phone and other phones revert back to a p2p call.


Conductor : B2BUA disconnected call on the Ingress saying "Failed to send out mid-dialog request due to a transaction timeout"

TP Server :

10109:29:57.333 APPInfoconference "0050311000010x3d7ec306f11500c" created
10209:29:57.817 SIPInfoIncoming call
10309:29:57.818 APPInfocall 1: new incoming SIP call from "MAJCHRZAK JC."
10409:29:57.898 SIPInfoIncoming call
10509:29:57.899 APPInfocall 2: new incoming SIP call from "TEST CONDUCTOR 1"
10609:29:57.957 SIPInfoIncoming call
10709:29:57.958 APPInfocall 3: new incoming SIP call from "TEST CONDUCTOR 2"
10809:29:58.143 APPInfocall 2: now joined conference "0050311000010x3d7ec306f11500c"
10909:29:58.564 APPInfocall 3: now joined conference "0050311000010x3d7ec306f11500c"
11009:29:58.673 APPInfocall 1: now joined conference "0050311000010x3d7ec306f11500c"
11109:30:33.336 SIPErrorEnding call due to INVITE transaction timeout
11209:30:33.336 CMGRInfocall 1: disconnecting, "MAJCHRZAK JC." - timeout
11309:30:33.336 SIPErrorBYE transaction failed due to network error
11409:30:33.337 APPInfocall 1: tearing down call from "MAJCHRZAK JC." - destroy at far end request; timeout
11509:30:33.357 SIPErrorEnding call due to INVITE transaction timeout
11609:30:33.357 CMGRInfocall 2: disconnecting, "TEST CONDUCTOR 1" - timeout
11709:30:33.357 SIPErrorEnding call due to INVITE transaction timeout
11809:30:33.357 CMGRInfocall 3: disconnecting, "TEST CONDUCTOR 2" - timeout
11909:30:33.357 SIPErrorBYE transaction failed due to network error
12009:30:33.357 SIPErrorBYE transaction failed due to network error
12109:30:33.357 APPInfocall 2: tearing down call from "TEST CONDUCTOR 1" - destroy at far end request; timeout
12209:30:33.357 APPInfocall 3: tearing down call from "TEST CONDUCTOR 2" - destroy at far end request; timeout
12309:33:01.435 SIPWarningReceived out-of-call request
12409:33:01.435 SIPWarningReceived out-of-call request
12509:33:01.436 SIPWarningReceived out-of-call request
12609:33:01.958 APPInfoconference "0050311000010x3d7ec306f11500c": deleted via API (no participants)


I've set traces to Detailed and I can see the first INVITE-> TRYING -> RINGING -> 200 OK w/SDP exchanges between CUCM and Conductor

Then 3 seconds later there is a Re-INVITE w/SDP  from Conductor  (for what reason I don't know), and the CUCM says TRYING but no more than this.

Maybe my timeout from Conductor pov and the no answer to the Re-INVITE are the same...

I've seen some bug related to Re-INVITE CSCuh79981, maybe I'm facing this issue.

Any other idea ?




Just found this CSCuj85594


Calls from CUCM would route through Conductor to TPS and connect. After 30sec, TPS would send a re-invite back to CUCM. The SIP re-invite was dropped at CUCM as the message size was to large causing the call to drop.


Increase SIP message size on CUCM

Trying and let you know...



Unfortunately SIP Max Incoming Message Size is already set to 1100  so I'm not matching CSCuj85594


I hope 1100 is a typo - should be 11000 or bigger... (default is 5000)

In the CiscoLive 2013 slidedeck BRKEVT-2811 they mention even 12000...


You're right it's a typo error. Value is the Suggested Value.


Here is the screenshot of CUCM SIP flow.


No problem with my CUCM 9.1 lab.

So issue seems to be linked to 8.6.2 version.


Was this specific to 8.6.2 version, I have a cluster that is having a very similar problem and the max sip incoming message size is already set to 11000.  The calls from this cluster to the conductor/TP are coming through a Intercluster Trunk.  The cluster that is "attached" via the SIP trunk to the Conductor is running 9.1.2 and it works fine.  

I am trying to determine if the problem is due to the ICT is the issue or the version of the CUCM.

The error in the TP is Error ending call due to network error during ACK transaction.

Thanks for any help.



Did you find a solution for the problem? Upgrade to 9.1.2 is the way?






I have encountered similar problem on my customer's site.

The symptom was almost same as this. Exactly same entry of TS event log ("Ending call due to INVITE transaction timeout") has been appeared.


However, the environment was,

  CUCM : 10.5

  Conductor : 2.4.1

  TS : virtual TS 4.0

  Jabber for Windows (video client) : 10.5


Is this problem still exist and have never fixed yet?





To the older postings, especially regards TelePresence / video I strongly recommend to use later or better said the up to date version of CUCM.


Besides that, often when calls fail there is something wrong in the network, like firewalls/algs/nat

where it should not be, configurations or DNS records are not ok and so on.


Sip is a protocol which sends out a message and in many cases expects a message back.

If for what ever reason that message does not arrive or is changed it will most likely fail.


Please remember to rate helpful responses and identify


Hi Jun,


Did you find a solution to this problem.


I also have the same versions and have the same problem.






Thanks, Martin,

I'm sorry to late reply.

And, John,

I have never found any solution about this. However, it's in the customer's network and there may be  some router/firewall between CUCM and TS, I heard.

Now we're asking to test that putting TS onto the same network with CUCM and how it will work.







My problem was related to the "SIP Max Incoming Message Size".


Even though I was running 10.51.   My CUCM had been upgraded many times and the setting was set at 5000 which I guess came from earlier versions.   As soon as I changed this setting it all sprang into life.


Hope this helps someone.



Content for Community-Ad