Conductor with Virtual TP - UCM Centric - transaction timeout

[Jean-Christophe Majchrzak]

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 :

101	09:29:57.333	APP	Info	conference "0050311000010x3d7ec306f11500c" created
102	09:29:57.817	SIP	Info	Incoming call
103	09:29:57.818	APP	Info	call 1: new incoming SIP call from "MAJCHRZAK JC."
104	09:29:57.898	SIP	Info	Incoming call
105	09:29:57.899	APP	Info	call 2: new incoming SIP call from "TEST CONDUCTOR 1"
106	09:29:57.957	SIP	Info	Incoming call
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)

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

[Jean-Christophe Majchrzak]

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

[Jean-Christophe Majchrzak]

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

[MARTIN STREULE]

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

[Jean-Christophe Majchrzak]

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

[Jean-Christophe Majchrzak]

Here is the screenshot of CUCM SIP flow.

[Jean-Christophe Majchrzak]

No problem with my CUCM 9.1 lab.

So issue seems to be linked to 8.6.2 version.

[joeharb]

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

[cornel.chirculete]

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

Thanks

Cornel

[Jun Takai]

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

[Martin Koch]

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.

[jchorlton]

Hi Jun,

Did you find a solution to this problem.

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

Thanks

John

[Jun Takai]

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.

Thanks,

//Jun

[jchorlton]

Hi,

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.

John