Call drops after 75 minutes on a SIP Trunk

[asharsidd]

One of our customer has a SIP trunk for inbound/outbound calls.

They are having an issue with call dropping after like 75 minutes. The duration is not confirmed as sometimes it drops even before 75 minutes.

They had the same issue before when call use to drop after 30 minutes but then their provider asked them to add the following lines which kind of resolved it but now it's dropping after 75 mins (approx).

I have attached some running config and debugs. Provider says that the 'BYE' message is coming from our end (Call manager/Gateway).

Is there any setting in Call manager or gateway which is causing this issue?

CCM: System version: 7.1.3.32900-4

CUBE-10#sh ver

Cisco IOS Software, 3800 Software (C3825-ADVIPSERVICESK9-M), Version 12.4(24)T4, RELEASE SOFTWARE (fc2)

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2010 by Cisco Systems, Inc.

Compiled Fri 03-Sep-10 09:15 by prod_rel_team

ROM: System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1)

CUBE-10 uptime is 27 weeks, 3 days, 44 minutes

voice-card 0

!

!

voice call send-alert

voice rtp send-recv

!

voice service voip

allow-connections sip to sip

fax protocol cisco

sip

  options-ping 180

!

!

!

voice class codec 1

codec preference 1 g729r8

codec preference 2 g711alaw

!

!

!

!

!

voice class sip-profiles 1

request INVITE sip-header Allow-Header modify ", UPDATE" ""

!

dial-peer voice 10 voip

description *** Outbound to Gamma - SIP Provider ***

translation-profile outgoing OUTBOUND

huntstop

destination-pattern 9T

voice-class codec 1

voice-class sip early-offer forced

voice-class sip profiles 1

session protocol sipv2

session target ipv4:10.0.222.69

dtmf-relay rtp-nte

fax-relay sg3-to-g3

no vad

!

!

gateway

timer receive-rtp 1200

!

sip-ua

retry invite 1

retry response 2

retry bye 2

retry cancel 1

retry options 1

timers trying 200

!

!

!

Debug Output:

Jul 11 12:17:54.579 BST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

BYE sip:079XXXXXXX@10.0.222.69:5060 SIP/2.0

Via: SIP/2.0/UDP 10.0.222.65:5060;branch=z9hG4bK100B17D

From: "anonymous" <sip:anonymous@10.0.222.65>;tag=B891B2E8-282

To: <sip:079XXXXXXX@10.0.222.69>;tag=3519367399-656588

Date: Mon, 11 Jul 2011 11:15:27 GMT

Call-ID: D687F817-AADB11E0-A725957A-CA524E0B@10.0.222.65

User-Agent: Cisco-SIPGateway/IOS-12.x

Max-Forwards: 70

Timestamp: 1310383074

CSeq: 128 BYE

Reason: Q.850;cause=16

Content-Length: 0

Jul 11 12:17:54.591 BST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 10.0.222.65:5060;branch=z9hG4bK100B17D

To: <sip:079XXXXXXX@10.0.222.69>;tag=3519367399-656588

From: "anonymous" <sip:anonymous@10.0.222.65>;tag=B891B2E8-282

Call-ID: D687F817-AADB11E0-A725957A-CA524E0B@10.0.222.65

CSeq: 128 BYE

Allow: INVITE, BYE, OPTIONS, CANCEL, ACK, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH

Contact: <sip:079XXXXXXX@10.0.222.69:5060>

Content-Leng

[linuxchild · Accepted solution]

Hello

I had a pb that looks like this one , but it was each 10 min , here is what I have done

voice service voip

allow-connections h323 to h323

allow-connections h323 to sip

allow-connections sip to h323

allow-connections sip to sip

fax protocol t38 version 0 ls-redundancy 2 hs-redundancy 0 fallback none

h323

  session transport udp

sip

  bind media source-interface FastEthernet0/0

  sip-profiles 100

!

voice class sip-profiles 100

request INVITE sip-header Allow-Header modify " UPDATE, " " "

request REINVITE sip-header Allow-Header modify " UPDATE, " " "

response 200 sip-header Allow-Header modify " UPDATE, " " "

response 180 sip-header Allow-Header modify " UPDATE, " " "

[asharsidd]

Thanks.

Did it resolve your issue of call drop then?

[linuxchild]

yes, this config solved my pb

[Ess Emque]

Hello, sorry to bring up the old post. I had this issue and also the sip profiles fixed this for me.

But can you explain what is doing? It is fixed, but I want to better understand what we fixed. I understand that is removing the UPDATE option from the invite. But why would having the UPDATE option cause the call to drop?

Is the provider not accepting UPDATE? And if yes, what is now sent, instead of UPDATE to refresh the session?

Thank you

Ess

[Ayodeji Okanlawon]

Ess,

First of all this is a very good question you have brought up. I have seen many people use this and I am sure most people done know why it is working. So lets try and figure it out..

The answer to this lies in a bug with some version of CUBE..

CUBE: Session refresh via sip UPDATE is consumed by CUBE

CSCty36625

Description

Symptom:
SIP to SIP calls may disconnect on CUBE enterprise after the session refresh timer expires if the far end device attempts to do session refresh via SIP UPDATE messages instead of using a SIP re-invite.

Conditions:
This was seen on a SIP to SIP CUBE running on a 3945 with IOS version 15.1(4)M2.

Workaround:
Use SIP profiles to remove "UPDATE" from the Supported header to prevent the far end device from sending SIP updates to CUBE. For example:

voice class sip-profiles 2
request ANY sip-header Allow-Header modify "UPDATE[,]* " ""
response ANY sip-header Allow-Header modify "UPDATE[,]* " ""
!
dial-peer voice 1 voip
voice-class sip profiles 2

The second answer to this is that when the UPDATE method is removed, then session refresh is done via REINVITE message that contains a session refresh parameter

Looks like CUBE works better when session refresh is done with re-INVITEs rather than UPDATE

[phamvinhdat · Accepted solution]

I have similar problem in the past with version 7. Call dropped after 30 mniutes. In working with TAC, they suggest to increase the "SIP Session Expires Timer" to the max from Service Parameter ==> Call Manager Services. It did help in my case.

Dat

[asharsidd]

Thanks.

Let me apply these settings and test.

If anyone else has a better resolution do let us know.

[kking2008]

I too had this issue (CUCM 7.1.5, CUBE 15.1T(3) ) and it was resolved by increasing the Service parameter in timer CCM.

[asharsidd]

Thanks guys.

I increased the timer and added those commands as well under the voice class.

Customer confirmed they had a call which lasted for 3 hours and it didn't drop.

Cheers all.