07-18-2011 04:31 AM - edited 03-16-2019 05:59 AM
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
Solved! Go to Solution.
07-18-2011 05:44 AM
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, " " "
07-18-2011 06:29 AM
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
07-18-2011 05:44 AM
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, " " "
07-18-2011 06:22 AM
Thanks.
Did it resolve your issue of call drop then?
07-18-2011 07:41 AM
yes, this config solved my pb
10-20-2015 12:39 PM
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
10-20-2015 03:20 PM
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..
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
07-18-2011 06:29 AM
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
07-18-2011 07:05 AM
Thanks.
Let me apply these settings and test.
If anyone else has a better resolution do let us know.
07-18-2011 08:01 AM
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.
07-19-2011 01:33 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide