cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8216
Views
5
Helpful
17
Replies

SIP Calls Drop. Receive Bye From Cube 15min,30min, 45min

Jay Schulze
Level 1
Level 1

Hello,

 

Running into an odd issue. I've seen several others having this problem with calls dropping after 15min duration. But this is a bit different. Sometimes long duration calls drop at 15min. Some at 30min, others at 45min. And sometimes not at all. Call flow is such.

 

8831-sip--CUCM--sip--Cube--ITSP

 

I'm convinced this is likely a problem with the refresh timer. But I can't explain why it wouldn't just fail only at 15min. It's also interesting to note I've only seen this on the 8831. I tried getting the issue with debugs from the cube but of course it didn't happen once I turned on ccsip message.

 

From the callmanager traces I see the bye arrive from cube with Reason Q.850 cause=102. 

 

The CUCM version is 9.1.2  and cube is 15.2(4)M1. I did see some odd defect in 15.1 related to this where the refresh on the cube would send out 3 invites to the ITSP on an update. I guess it would have only 33% chance of getting it right. Any help someone could provide I'd appreciate it.

17 Replies 17

Brian Meade
Level 7
Level 7

Usually it's a bit of a race condition so you may not see it ever 15 minute interval.  We'll need a "debug ccsip messages" from the CUBE to really see which side is the source of the problem.

mpattersonel
Level 1
Level 1

I had a similar problem a few weeks ago. With an identical call flow. 

What was occurring was on the ITSP end there was a problem where SIP messages were getting lost between a SBC and Call Server. SIP messages would basically stop in one direction for a few seconds at a time.  It would then cause the CUBE to expiry and send a BYE.  

The ``delays`` on the ITSP were random and would not occur on every SIP message. So it was basically luck of the draw if the message was traversing when it was in a problem. 

If this is same as your scenario it could explain why it is random when it fails.

I changed the SIP Timers on the CUBE as a work around to give the ITSP more time  and  retries to respond, while the issue was worked on that side of things. 

Thanks for the replies.

So was able to capture it while had debugs running. This time it disconnected after an hour. Same cause=102.

 

Now here is where it gets interesting in the debugs. I see an invite is sent 3 seconds from callmanager. I assume this is a refresher with the same call-id. Cube receives it and sends out to ITSP. With a new call-id. We then receive a bye from ITSP cause=86. Which then of course is sent to callmanager. Here are the relevent sections of debugs.

 

Received from cucm to cube:

820421: May  6 09:00:42.976: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
2014-05-06 09:00:43            2365082: Received:
2014-05-06 09:00:43            2365083: INVITE sip:87183541169@10.38.246.166:5060;transport=tcp SIP/2.0
2014-05-06 09:00:43            2365084: Via: SIP/2.0/TCP 10.38.246.136:5060;branch=z9hG4bK28bab16dbd5664
2014-05-06 09:00:43            2365085: From: "Marcos Vazquez" <sip:6103729700@10.38.246.136>;tag=3831180~dfbf10b3-6c69-4443-852f-cbf609935a6f-35009402
2014-05-06 09:00:43            2365086: To: <sip:87183541169@10.38.246.166>;tag=5EBA2282-19C8
2014-05-06 09:00:43            2365087: Date: Tue, 06 May 2014 15:00:42 GMT
2014-05-06 09:00:43            2365088: Call-ID: cc044c80-3681eb06-fca99-88f6260a@10.38.246.136
2014-05-06 09:00:43            2365089: Supported: 100rel,timer,resource-priority,replaces
2014-05-06 09:00:43            2365090: Min-SE:  1800
2014-05-06 09:00:43            2365091: User-Agent: Cisco-CUCM9.1
2014-05-06 09:00:43            2365092: Allow: INVITE, OPTIONS, I
2014-05-06 09:00:43            2365093: NFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
2014-05-06 09:00:43            2365094: CSeq: 106 INVITE
2014-05-06 09:00:43            2365095: Max-Forwards: 70
2014-05-06 09:00:43            2365096: Expires: 300
2014-05-06 09:00:43            2365097: Allow-Events: presence, kpml
2014-05-06 09:00:43            2365098: Supported: X-cisco-srtp-fallback
2014-05-06 09:00:43            2365099: Supported: Geolocation
2014-05-06 09:00:43            2365100: P-Asserted-Identity: "Marcos Vazquez" <sip:6103729700@10.38.246.136>
2014-05-06 09:00:43            2365101: Remote-Party-ID: "Marcos Vazquez" <sip:6103729700@10.38.246.136>;party=calling;screen=yes;privacy=off
2014-05-06 09:00:43            2365102: Contact: <sip:6103729700@10.38.246.136:5060;transport=tcp>
2014-05-06 09:00:43            2365103: Content-Type: application/sdp
2014-05-06 09:00:43            2365104: Content-Length: 371
2014-05-06 09:00:43            2365105:
2014-05-06 09:00:43            2365106: v=0
2014-05-06 09:00:43            2365107: o=CiscoSystemsCCM-
2014-05-06 09:00:43            2365108: SIP 3831180 1 IN IP4 10.38.246.136
2014-05-06 09:00:43            2365109: s=SIP Call
2014-05-06 09:00:43            2365110: c=IN IP4 10.96.5.28
2014-05-06 09:00:43            2365111: b=TIAS:64000
2014-05-06 09:00:43            2365112: b=AS:64
2014-05-06 09:00:43            2365113: t=0 0
2014-05-06 09:00:43            2365114: m=audio 31146 RTP/AVP 18 0 116 101
2014-05-06 09:00:43            2365115: a=rtpmap:0 PCMU/8000
2014-05-06 09:00:43            2365116: a=ptime:20
2014-05-06 09:00:43            2365117: a=rtpmap:116 iLBC/8000
2014-05-06 09:00:43            2365118: a=ptime:20
2014-05-06 09:00:43            2365119: a=maxptime:60
2014-05-06 09:00:43            2365120: a=fmtp:116 mode=20
2014-05-06 09:00:43            2365121: a=rtpmap:18 G729/8000
2014-05-06 09:00:43            2365122: a=ptime:20
2014-05-06 09:00:43            2365123: a=fmtp:18 annexb=no
2014-05-06 09:00:43            2365124: a=rtpmap:101 telephone-event/8000
2014-05-06 09:00:43            2365125: a=fmtp:101 0-15
2014-05-06 09:00:43            2365126: 5820422: May  6 09:00:42.978: //3024943/CC044C80000B/SIP/Msg/ccsipDisplayMsg:

Sent to ITSP:

 Sent: Which looks like 3 are sent.
2014-05-06 09:00:43            2365128: INVITE sip:12.194.190.26:5060;transport=udp SIP/2.0
2014-05-06 09:00:43            2365129: Via: SIP/2.0/UDP 12.17.223.243:5060;branch=z9hG4bK2D699C1126
2014-05-06 09:00:43            2365130: P-Asserted-Identity: "Marcos Vazquez" <sip:6103729700@12.17.223.243>
2014-05-06 09:00:43            2365131: From: "Marcos Vazquez" <sip:6103729700@12.17.223.243>;tag=5EBA1628-22FC
2014-05-06 09:00:43            2365132: To: <sip:7183541169@12.194.190.26>;tag=8088820710430052_c2b05.1.1.1385369448756.0_9843675_19511361
2014-05-06 09:00:43            2365133: Date: Tue, 06 May 2014 15:00:42 GMT
2014-05-06 09:00:43            2365134: Call-ID: A324CBCE-D45D11E3-A02BFA49-774AEE39@12.17.223.243
2014-05-06 09:00:43            2365135: Supported: 100rel,timer,resource-priority,replaces,sdp-an
2014-05-06 09:00:43            2365136: at
2014-05-06 09:00:43            2365137: Min-SE:  1800
2014-05-06 09:00:43            2365138: Cisco-Guid: 3422833792-0000065536-0000746374-2297832970
2014-05-06 09:00:43            2365139: User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
2014-05-06 09:00:43            2365140: Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
2014-05-06 09:00:43            2365141: CSeq: 105 INVITE
2014-05-06 09:00:43            2365142: Max-Forwards: 70
2014-05-06 09:00:43            2365143: Timestamp: 1399388442
2014-05-06 09:00:43            2365144: Contact: <sip:6103729700@12.17.223.243:5060>
2014-05-06 09:00:43            2365145: Expires: 60
2014-05-06 09:00:43            2365146: Allow-Events: telephone-event
2014-05-06 09:00:43            2365147: Content-Type: application/sdp
2014-05-06 09:00:43            2365148: Content-Length: 334
2014-05-06 09:00:43            2365149:
2014-05-06 09:00:43            2365150: v=0
2014-05-06 09:00:43            2365151: o=CiscoSystemsSIP-GW-UserAgent 8182 4488 IN IP4 12.17.223.243
2014-05-06 09:00:43            2365152: s=SIP Call
2014-05-06 09:00:43            2365153: c=IN IP4 1
2014-05-06 09:00:43            2365154: 2.17.223.243
2014-05-06 09:00:43            2365155: t=0 0
2014-05-06 09:00:43            2365156: m=audio 18760 RTP/AVP 18 0 100 101
2014-05-06 09:00:43            2365157: c=IN IP4 12.17.223.243
2014-05-06 09:00:43            2365158: a=rtpmap:18 G729/8000
2014-05-06 09:00:43            2365159: a=fmtp:18 annexb=no
2014-05-06 09:00:43            2365160: a=rtpmap:0 PCMU/8000
2014-05-06 09:00:43            2365161: a=rtpmap:100 X-NSE/8000
2014-05-06 09:00:43            2365162: a=fmtp:100 192-194
2014-05-06 09:00:43            2365163: a=rtpmap:101 telephone-event/8000
2014-05-06 09:00:43            2365164: a=fmtp:101 0-15
2014-05-06 09:00:43            2365165: 5820423: May  6 09:00:42.978: //3024942/CC044C80000B/SIP/Msg/ccsipDisplayMsg:
2014-05-06 09:00:43            2365166: Sent:
2014-05-06 09:00:43            2365167: SIP/2.0 100 Trying
2014-05-06 09:00:43            2365168: Via: SIP/2.0/TCP 10.38.246.136:5060;branch=z9hG4bK28bab16dbd5664
2014-05-06 09:00:43            2365169: From: "Marcos Vazquez" <sip:6103729700@10.38.246.136>;tag=3831180~dfbf10b3-6c69-4443-852f-cbf609935a6f-35009402
2014-05-06 09:00:43            2365170: To: <sip:87183541169@10.38.246.166>;tag=5EBA2282-19C8
2014-05-06 09:00:43            2365171: Date: Tue, 06 May 2014 15:00:42 GMT
2014-05-06 09:00:43            2365172: Call-ID: cc044c80-3681eb06-fca99-88f6260a@10.38.246.136
2014-05-06 09:00:43            2365173: CSeq: 106 INVITE
2014-05-06 09:00:43            2365174: Allow-Events: telephone-event
2014-05-06 09:00:43            2365175: Server: Cisco-SIPGateway/IOS-15.2.4.M1
2014-05-06 09:00:43            2365176: Content-Length: 0
2014-05-06 09:00:43            2365177:
2014-05-06 09:00:43            2365178: 5820424: May  6 09:00:43.479: //3024943/CC044C80000B/SIP/Msg/ccsipDisplayMsg:
2014-05-06 09:00:43            2365179: Sent:
2014-05-06 09:00:43            2365180: INVITE sip:12.194.190.26:5060;transport=udp SIP/2.0
2014-05-06 09:00:43            2365181: Via: SIP/2.0/UDP 12.17.223.243:5060;branch=z9hG4bK2D699C1126
2014-05-06 09:00:43            2365182: P-Asserted-Identity: "Marcos Vazquez" <sip:6103729700@12.17.223.243>
2014-05-06 09:00:43            2365183: From: "Marcos Vazquez" <sip:6103729700@12.17.223.243>;tag=5EBA1628-22FC
2014-05-06 09:00:43            2365184: To: <sip:7183541169@12.194.190.26>;tag=8088820710430052_c2b05.1.1.1385369448756.0_9843675_19511361
2014-05-06 09:00:43            2365185: Date: Tue, 06 May 2014 15:00:43 GMT
2014-05-06 09:00:43            2365186: Call-ID: A324CBCE-D45D11E3-A02BFA49-774AEE39@12.17.223.243
2014-05-06 09:00:43            2365187: Supported: 100rel,timer,resource-priority,replaces,sdp-an
2014-05-06 09:00:43            2365188: at
2014-05-06 09:00:43            2365189: Min-SE:  1800
2014-05-06 09:00:43            2365190: Cisco-Guid: 3422833792-0000065536-0000746374-2297832970
2014-05-06 09:00:43            2365191: User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
2014-05-06 09:00:43            2365192: Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
2014-05-06 09:00:43            2365193: CSeq: 105 INVITE
2014-05-06 09:00:43            2365194: Max-Forwards: 70
2014-05-06 09:00:43            2365195: Timestamp: 1399388443
2014-05-06 09:00:43            2365196: Contact: <sip:6103729700@12.17.223.243:5060>
2014-05-06 09:00:43            2365197: Expires: 60
2014-05-06 09:00:43            2365198: Allow-Events: telephone-event
2014-05-06 09:00:43            2365199: Content-Type: application/sdp
2014-05-06 09:00:43            2365200: Content-Length: 334
2014-05-06 09:00:43            2365201:
2014-05-06 09:00:43            2365202: v=0
2014-05-06 09:00:43            2365203: o=CiscoSystemsSIP-GW-UserAgent 8182 4488 IN IP4 12.17.223.243
2014-05-06 09:00:43            2365204: s=SIP Call
2014-05-06 09:00:43            2365205: c=IN IP4 1
2014-05-06 09:00:44            2365206: 2.17.223.243
2014-05-06 09:00:44            2365207: t=0 0
2014-05-06 09:00:44            2365208: m=audio 18760 RTP/AVP 18 0 100 101
2014-05-06 09:00:44            2365209: c=IN IP4 12.17.223.243
2014-05-06 09:00:44            2365210: a=rtpmap:18 G729/8000
2014-05-06 09:00:44            2365211: a=fmtp:18 annexb=no
2014-05-06 09:00:44            2365212: a=rtpmap:0 PCMU/8000
2014-05-06 09:00:44            2365213: a=rtpmap:100 X-NSE/8000
2014-05-06 09:00:44            2365214: a=fmtp:100 192-194
2014-05-06 09:00:44            2365215: a=rtpmap:101 telephone-event/8000
2014-05-06 09:00:44            2365216: a=fmtp:101 0-15
2014-05-06 09:00:44            2365217: 5820425: May  6 09:00:44.479: //3024943/CC044C80000B/SIP/Msg/ccsipDisplayMsg:
2014-05-06 09:00:44            2365218: Sent:
2014-05-06 09:00:44            2365219: INVITE sip:12.194.190.26:5060;transport=udp SIP/2.0
2014-05-06 09:00:44            2365220: Via: SIP/2.0/UDP 12.17.223.243:5060;branch=z9hG4bK2D699C1126
2014-05-06 09:00:44            2365221: P-Asserted-Identity: "Marcos Vazquez" <sip:6103729700@12.17.223.243>
2014-05-06 09:00:44            2365222: From: "Marcos Vazquez" <sip:6103729700@12.17.223.243>;tag=5EBA1628-22FC
2014-05-06 09:00:44            2365223: To: <sip:7183541169@12.194.190.26>;tag=8088820710430052_c2b05.1.1.1385369448756.0_9843675_19511361
2014-05-06 09:00:44            2365224: Date: Tue, 06 May 2014 15:00:44 GMT
2014-05-06 09:00:44            2365225: Call-ID: A324CBCE-D45D11E3-A02BFA49-774AEE39@12.17.223.243
2014-05-06 09:00:44            2365226: Supported: 100rel,timer,resource-priority,replaces,sdp-an
2014-05-06 09:00:44            2365227: at
2014-05-06 09:00:44            2365228: Min-SE:  1800
2014-05-06 09:00:44            2365229: Cisco-Guid: 3422833792-0000065536-0000746374-2297832970
2014-05-06 09:00:44            2365230: User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
2014-05-06 09:00:44            2365231: Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
2014-05-06 09:00:44            2365232: CSeq: 105 INVITE
2014-05-06 09:00:44            2365233: Max-Forwards: 70
2014-05-06 09:00:44            2365234: Timestamp: 1399388444
2014-05-06 09:00:44            2365235: Contact: <sip:6103729700@12.17.223.243:5060>
2014-05-06 09:00:44            2365236: Expires: 60
2014-05-06 09:00:44            2365237: Allow-Events: telephone-event
2014-05-06 09:00:44            2365238: Content-Type: application/sdp
2014-05-06 09:00:44            2365239: Content-Length: 334
2014-05-06 09:00:44            2365240:
2014-05-06 09:00:44            2365241: v=0
2014-05-06 09:00:44            2365242: o=CiscoSystemsSIP-GW-UserAgent 8182 4488 IN IP4 12.17.223.243
2014-05-06 09:00:44            2365243: s=SIP Call
2014-05-06 09:00:44            2365244: c=IN IP4 1
2014-05-06 09:00:44            2365245: 2.17.223.243
2014-05-06 09:00:44            2365246: t=0 0
2014-05-06 09:00:44            2365247: m=audio 18760 RTP/AVP 18 0 100 101
2014-05-06 09:00:44            2365248: c=IN IP4 12.17.223.243
2014-05-06 09:00:44            2365249: a=rtpmap:18 G729/8000
2014-05-06 09:00:44            2365250: a=fmtp:18 annexb=no
2014-05-06 09:00:44            2365251: a=rtpmap:0 PCMU/8000
2014-05-06 09:00:44            2365252: a=rtpmap:100 X-NSE/8000
2014-05-06 09:00:44            2365253: a=fmtp:100 192-194
2014-05-06 09:00:44            2365254: a=rtpmap:101 telephone-event/8000
2014-05-06 09:00:44            2365255: a=fmtp:101 0-15
2014-05-06 09:00:45            2365256: 5820426: May  6 09:00:45.147: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
2014-05-06 09:00:45            2365257: Received:

 

And then I don't see a response then send out a bye:

Sent:
2014-05-06 09:00:46            2365897: BYE sip:12.194.190.26:5060;transport=udp SIP/2.0
2014-05-06 09:00:46            2365898: Via: SIP/2.0/UDP 12.17.223.243:5060;branch=z9hG4bK2D69A54BC
2014-05-06 09:00:46            2365899: From: "Marcos Vazquez" <sip:6103729700@12.17.223.243>;tag=5EBA1628-22FC
2014-05-06 09:00:46            2365900: To: <sip:7183541169@12.194.190.26>;tag=8088820710430052_c2b05.1.1.1385369448756.0_9843675_19511361
2014-05-06 09:00:46            2365901: Date: Tue, 06 May 2014 15:00:44 GMT
2014-05-06 09:00:46            2365902: Call-ID: A324CBCE-D45D11E3-A02BFA49-774AEE39@12.17.223.243
2014-05-06 09:00:46            2365903: User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
2014-05-06 09:00:46            2365904: Max-Forwards: 70
2014-05-06 09:00:46            2365905: P-Asserted-Identity: "Marcos Vazquez" <sip:6103729700@12.17.223.243>
2014-05-06 09:00:46            2365906: Timestamp: 1399388446
2014-05-06 09:00:46            2365907: CSeq: 106 BYE
2014-05-06 09:00:46            2365908: Reason: Q.850;cause=86
2014-05-06 09:00:46            2365909: P-RTP-Stat: PS=180295,OS=3604444,PR=180354,OR=3607080,PL=0,JI=0,LA=0,DU=3603
2014-05-06 09:00:46            2365910: Content-Length: 0
2014-05-06 09:00:46            2365911:
2014-05-06 09:00:46            2365912: 5820458: May  6 09:00:46.479: //3024942/CC044C80000B/SIP/Msg/ccsipDisplayMsg:
2014-05-06 09:00:46            2365913: Sent:
2014-05-06 09:00:46            2365914: BYE sip:6103729700@10.38.246.136:5060;transport=tcp SIP/2.0
2014-05-06 09:00:46            2365915: Via: SIP/2.0/TCP 10.38.246.166:5060;branch=z9hG4bK2D69A6E75
2014-05-06 09:00:46            2365916: From: <sip:87183541169@10.38.246.166>;tag=5EBA2282-19C8
2014-05-06 09:00:46            2365917: To: "Marcos Vazquez" <sip:6103729700@10.38.246.136>;tag=3831180~dfbf10b3-6c69-4443-852f-cbf609935a6f-35009402
2014-05-06 09:00:46            2365918: Date: Tue, 06 May 2014 15:00:42 GMT
2014-05-06 09:00:46            2365919: Call-ID: cc044c80-3681eb06-fca99-88f6260a@10.38.246.136
2014-05-06 09:00:46            2365920: User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
2014-05-06 09:00:46            2365921: Max-Forwards: 70
2014-05-06 09:00:46            2365922: Timestamp: 1399388446
2014-05-06 09:00:46            2365923: CSeq: 101 BYE
2014-05-06 09:00:46            2365924: Reason: Q.850;cause=102
2014-05-06 09:00:46            2365925: P-R
2014-05-06 09:00:46            2365926: TP-Stat: PS=180239,OS=3604780,PR=180295,OR=3604444,PL=0,JI=0,LA=0,DU=3603
2014-05-06 09:00:46            2365927: Content-Length: 0
2014-05-06 09:00:46            2365928:

 

 

I am not sure increasing the Min-SE would address the problem, I think  it would just make it happen at a different interval. Right now it seems to occur at a 15 Min increment.

It does appear that the problem might be on the provider side of the call, so engaging them might be a good idea

If you did want to look at changing timers.

This link http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-callmanager/82250-failover-timer.html

explains altering SIP Timers for CUCM. The same "math" could be used to calculate an appropriate number for your environment.  You'd need to change these on the CUBE to have an impact. Example is just a good resource that explains how the Total Time is calculated.

A couple of IOS commands you can use to check what they currently are set to

show sip timers

show sip retry

I would make small changes till  you get to a point where it no longer occurs, and then change them back after the problem is corrected, assuming it is a ITSP/PSTN provider problem.

CUBE re-sending the Invites isn't too abnormal in a UDP SIP environment.  CUCM does this as well to make sure it gets to the other side.  It seems like maybe the carrier is killing the call before CUBE sends the Refresh Re-Invite, hence the cause code 86 saying the call has already been cleared.

 

One thing that's weird is none of the messages have a Session-Expires header which is usually used for negotiation the timers and selecting which side will be in charge of refreshing the connection.

That's a good point. That is weird. I see the min-se header. But not the session-expires when the invite is sent.

Will probably need to see the SIP messaging for the entire call to see if maybe there's a reason it gets left out of future messages.

I looked up in the SIP RFC to see what it would mean if it's absent. Here's what it says.

This means that the absence of the Session-Expires header field
   implies no expiration of the session, using the mechanism defined in
   this specification.  Note that other mechanisms not defined in this
   specification, such as locally configured timers, may apply.

So in short if there is none. It'll mean there is no expiration.

That doesn't always mean that each vendor is 100% compliant though :D

 

My experience with the CUCM/CUBE SIP stack is that it doesn't handle the lack of Session-Expires header correctly and still sends refresh re-invites.

 

It seems like the problem though is the PSTN provider clearing the call before the session refresh possibly due to expecting one earlier even though it did not send a Session-Expires header.

 

To me, it looks like the issue is on the ITSP end here but it may take a while for them to investigate why they are clearing the call prematurely.

Very true. We all know how working with carriers goes :/ No offense to anyone who works at a carrier :)

But yes that is the next step to see if they receive it and why they didn't respond to it.

CUBE Re-INVITE doesn't look good. The RURI is not containing the phone number. "INVITE sip:12.194.190.26:5060;transport=udp SIP/2.0."

It should be like this "INVITE sip:7183541169@12.194.190.26:5060;transport=udp SIP/2.0"

In that case ITSP should send response with 4xx message for incomplete message/content but it doesn't and that's bit weird.

As ITSP didn't responded within time and message expiration time on INVITE message it set to  60 second , CUBE send BYE to ITSP with cause 86 (timeout) and to CUCM with cause 102 (timer expired).

 

Now the question is why CUBE Re-Invite doesn't contains the number as it is getting correct number from CUCM Re-Invite. Now to decode this we need full "debug ccsip all" logs from CUBE.

Definently some weird things going on in the invite. As Brian mentioned the session-expires header is missing. So one thing I went and looked back at the other 3 from the 15min intervals. And all 3 of those had the session-expires header. Could it be coincidence? Maybe, since I just have one example from the debugs.

 

To your point Manish. I do see that as well. But I see it formatted that way in all the invites except the initial one that went out to establish the call. So not sure if it has any impact or not.

 

But I do appreciate everyone's input. On the phone now with ATT. So we'll see what they have to say. It'll probably just be fixed and never here the reason why from them. But I'll let you know in case someone else runs into something similar.
 

Just an fyi. I worked with ATT on the issue. They never saw the invite for the refresh on their SBC. From the debugs we know it was sent out. So now we're in a standstill until I can get a packet cap. We have our cube connected on gig0/3 to a 4507. The ATT managed router is on the same 4507 on a gig port. So very unlikely packets are getting dropped there.

You certainly need to see where these Re-Invites are going.

It may be getting blocked or dropped and that is something which only be answered by packet capture.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: