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 220.127.116.1100, 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 :
|101||09:29:57.333||APP||Info||conference "0050311000010x3d7ec306f11500c" created|
|103||09:29:57.818||APP||Info||call 1: new incoming SIP call from "MAJCHRZAK JC."|
|105||09:29:57.899||APP||Info||call 2: new incoming SIP call from "TEST CONDUCTOR 1"|
|107||09:29:57.958||APP||Info||call 3: new incoming SIP call from "TEST CONDUCTOR 2"|
|108||09:29:58.143||APP||Info||call 2: now joined conference "0050311000010x3d7ec306f11500c"|
|109||09:29:58.564||APP||Info||call 3: now joined conference "0050311000010x3d7ec306f11500c"|
|110||09:29:58.673||APP||Info||call 1: now joined conference "0050311000010x3d7ec306f11500c"|
|111||09:30:33.336||SIP||Error||Ending call due to INVITE transaction timeout|
|112||09:30:33.336||CMGR||Info||call 1: disconnecting, "MAJCHRZAK JC." - timeout|
|113||09:30:33.336||SIP||Error||BYE transaction failed due to network error|
|114||09:30:33.337||APP||Info||call 1: tearing down call from "MAJCHRZAK JC." - destroy at far end request; timeout|
|115||09:30:33.357||SIP||Error||Ending call due to INVITE transaction timeout|
|116||09:30:33.357||CMGR||Info||call 2: disconnecting, "TEST CONDUCTOR 1" - timeout|
|117||09:30:33.357||SIP||Error||Ending call due to INVITE transaction timeout|
|118||09:30:33.357||CMGR||Info||call 3: disconnecting, "TEST CONDUCTOR 2" - timeout|
|119||09:30:33.357||SIP||Error||BYE transaction failed due to network error|
|120||09:30:33.357||SIP||Error||BYE transaction failed due to network error|
|121||09:30:33.357||APP||Info||call 2: tearing down call from "TEST CONDUCTOR 1" - destroy at far end request; timeout|
|122||09:30:33.357||APP||Info||call 3: tearing down call from "TEST CONDUCTOR 2" - destroy at far end request; timeout|
|123||09:33:01.435||SIP||Warning||Received out-of-call request|
|124||09:33:01.435||SIP||Warning||Received out-of-call request|
|125||09:33:01.436||SIP||Warning||Received out-of-call request|
|126||09:33:01.958||APP||Info||conference "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...
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.
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?