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

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

Conductor with Virtual TP - UCM Centric - transaction timeout

Hi,

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 8.6.2.23900, 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.

Logs

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)

CUCM :

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 ?

Thanks,

JC

  • TelePresence
Everyone's tags (3)
13 REPLIES

Conductor with Virtual TP - UCM Centric - transaction timeout

Just found this CSCuj85594

Conditions:

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.

Workaround:

Increase SIP message size on CUCM

Trying and let you know...

JC

Conductor with Virtual TP - UCM Centric - transaction timeout

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

Re: Conductor with Virtual TP - UCM Centric - transaction timeou

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...

Re: Conductor with Virtual TP - UCM Centric - transaction timeou

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

Re: Conductor with Virtual TP - UCM Centric - transaction timeou

Here is the screenshot of CUCM SIP flow.

Re: Conductor with Virtual TP - UCM Centric - transaction timeou

No problem with my CUCM 9.1 lab.

So issue seems to be linked to 8.6.2 version.

New Member

Was this specific to 8.6.2

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.

Joe

New Member

Did you find a solution for

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

Thanks

Cornel

New Member

Hello, I have encountered

Hello,

 

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?

 

Thanks,

//Jun

2241
Views
0
Helpful
13
Replies
This widget could not be displayed.