Call Disconnect after 30 mins. CUCM Q.850 Cause=41

[pematthe]

All,  I have tried searching but no-one seems to have a definitive answer. 

I have scenarios where calls to the PSTN via a SIP provider are cleared after 30minutes duration everytime.  I have done various diagnostics and narrowed it down to the CUCM sending a SIP BYE to the endpoint and to the CUBE / SIP provider.  Debug on the CUBE shows:

Received:

BYE sip:callmanager@172.27.199.1:5060;transport=tcp SIP/2.0
"output truncated"
CSeq: 102 BYE
Reason: Q.850;cause=41
Content-Length: 0

Cause 41 being "temporary failure"

The path is fine between CUBE and CUCM (same subnet), the internal ip-phone / jabber client receives "Call Preservation" mode and the call is killed.

A packet capture between the ip-phone and CUCM shows "BYE" initiated from CUCM.  We don't see any glitch in the data path there either. Other posts relating to call preservation mode refer to a disconnect in the network path between CUCM and phone unit.  I doubt this is the case, internal calls stay up all the time.

FYI - BE6000S

CUCM 11.0.1.20000-2

CUBE CISCO2921/K9  v15.5(3)M

[R0g22]

What is the session timer set to and who is the session refresher ? The logs should tell you that and you should be able to figure out who is messing up the dialog. If you can share the complete logs, I can look at them.

[pematthe]

I have timed it and it is 29 mins and 30 seconds exactly when the call drops, every time. 

In CUCM, >> System >> Service Parameters >>SIP the min-SE value is 1800 and the SIP Session Expires timer is 1800.  I have changed both of these to something else and it made no difference. 

I have also changed the min-SE in the associated CUBE and again, no change.

What logs are needed?  I have a PCAP between the jabber client and CUCM, CUBE debug ccsip messages or is it something from RTMT?

[pematthe]

BUMP - anybody?

[R0g22]

Enable the following for a test call please -

debug ccsip message
debug ccsip error
debug voice ccapi inout

[pematthe]

Exactly 29 minutes and 28 seconds call clear from CUCM with cause code 41.  Debug of the failure output from CUBE attached

[R0g22]

Logs are not complete. All I see is a SIP BYE.

[pematthe]

I only run the debug for the time when the call failed on the associated CUBE system.. The SIP BYE is originated from CUCM with error code / cause = 41. I need to understand why CUCM is killing the call

[R0g22]

You need the complete log. You can't just see a 41 in a BYE and interpret why is CUCM disconnecting the call.

[pematthe]

Full call debug attached.  Call died at 17 minutes, that the first time I have seen that.

[Suresh Subramanian]

>> Your call seems cleared with cause=16 (referece Call-ID: f879de00-b4b10a95-199bb-bc71bac@172.27.199.11) 008565: Jul 15 09:07:09.971: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: BYE sip:01189761593@172.27.199.1:5060;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 172.27.199.11:5060;branch=z9hG4bK1a5b7722d0c61 From: "The Purple Group" <02392006341>;tag=318492~4aca1d00-fcbd-60df-8ac5-ac9f97ba2d7d-27795643 To: <01189761593>;tag=CB74D308-F26 Date: Sun, 15 Jul 2018 08:49:25 GMT Call-ID: f879de00-b4b10a95-199bb-bc71bac@172.27.199.11 User-Agent: Cisco-CUCM11.0 Max-Forwards: 70 P-Asserted-Identity: "The Purple Group" <02392006341> CSeq: 102 BYE Reason: Q.850;cause=16 Session-ID: 0bc3723500105000a000f45c899da0d3;remote=a80cc56d33a91ddcb4cef186ab318492 Content-Length: 0] >> There is another BYE received from CUCM with cause=41 (reference Call-ID: da11e380-b4b103ac-19968-bc71bac@172.27.199.11), but it doesn't have the complete logs captured for that faulty call. 008366: Jul 15 08:49:31.675: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: BYE sip:01189761593@172.27.199.1:5060;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 172.27.199.11:5060;branch=z9hG4bK1a5891a208ea5 From: "The Purple Group" <02392006341>;tag=318210~4aca1d00-fcbd-60df-8ac5-ac9f97ba2d7d-27795639 To: <01189761593>;tag=CB59D3B0-8BF Date: Sun, 15 Jul 2018 08:19:56 GMT Call-ID: da11e380-b4b103ac-19968-bc71bac@172.27.199.11 User-Agent: Cisco-CUCM11.0 Max-Forwards: 70 P-Asserted-Identity: "The Purple Group" <02392006341> CSeq: 102 BYE Reason: Q.850;cause=41 Content-Length: 0 //Suresh Please rate all the useful posts.

[Suresh Subramanian]

your call seems cleared with cause=16 (Call-ID: f879de00-b4b10a95-199bb-bc71bac@172.27.199.11)

008565: Jul 15 09:07:09.971: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

BYE sip:01189761593@172.27.199.1:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 172.27.199.11:5060;branch=z9hG4bK1a5b7722d0c61

From: "The Purple Group" <sip:02392006341@172.27.199.11>;tag=318492~4aca1d00-fcbd-60df-8ac5-ac9f97ba2d7d-27795643

To: <sip:01189761593@172.27.199.1>;tag=CB74D308-F26

Date: Sun, 15 Jul 2018 08:49:25 GMT

Call-ID: f879de00-b4b10a95-199bb-bc71bac@172.27.199.11

User-Agent: Cisco-CUCM11.0

Max-Forwards: 70

P-Asserted-Identity: "The Purple Group" <sip:02392006341@172.27.199.11>

CSeq: 102 BYE

Reason: Q.850;cause=16

Session-ID: 0bc3723500105000a000f45c899da0d3;remote=a80cc56d33a91ddcb4cef186ab318492

Content-Length: 0]

 >> There is another BYE received from CUCM with cause=41 (Call-ID: da11e380-b4b103ac-19968-bc71bac@172.27.199.11), but it doesn't have the complete logs captured for that faulty call.

008366: Jul 15 08:49:31.675: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

BYE sip:01189761593@172.27.199.1:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 172.27.199.11:5060;branch=z9hG4bK1a5891a208ea5

From: "The Purple Group" <sip:02392006341@172.27.199.11>;tag=318210~4aca1d00-fcbd-60df-8ac5-ac9f97ba2d7d-27795639

To: <sip:01189761593@172.27.199.1>;tag=CB59D3B0-8BF

Date: Sun, 15 Jul 2018 08:19:56 GMT

Call-ID: da11e380-b4b103ac-19968-bc71bac@172.27.199.11

User-Agent: Cisco-CUCM11.0

Max-Forwards: 70

P-Asserted-Identity: "The Purple Group" <sip:02392006341@172.27.199.11>

CSeq: 102 BYE

Reason: Q.850;cause=41

Content-Length: 0

//Suresh Please rate all the useful posts.