<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Thanks Nick! This clears up the mystery of why the router was behaving different from default.</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
-sreekanth</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Nick Barnett <nick@barnett.email><br>
<b>Sent:</b> Tuesday, April 27, 2021 9:11 PM<br>
<b>To:</b> Sreekanth Narayanan (sreenara) <sreenara@cisco.com>; cisco-voip <cisco-voip@puck.nether.net><br>
<b>Subject:</b> Re: [cisco-voip] Outbound SIP connection failing in CUBE due to some timer... maybe.</font>
<div> </div>
</div>
<style type="text/css">
<!--
p.x_MsoNormal, p.x_MsoNoSpacing
        {margin:0}
-->
</style>
<div>
<div>One final follow-up on this... turns out that YES there was a PSTN switching issue... but also we could have increased a timer on survivability.tcl on the ingress leg. Just leaving this here in case anyone ever does a search.</div>
<div><br>
</div>
<div>application<br>
</div>
<div>service survivability<br>
</div>
<div>param setup-timeout 15<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>On Mon, Apr 19, 2021, at 8:24 AM, Nick Barnett wrote:<br>
</div>
<blockquote type="cite" id="x_qt" style="">
<div>The PSTN issue was resolved by the time I could get more traces. i still have no idea what timer was popping, TAC couldn't figure it out either... so I guess hope you don't ever have a mystery 7 second timer that cuts off your calls.<br>
</div>
<div><br>
</div>
<div>On Fri, Apr 16, 2021, at 11:25 AM, Nick Barnett wrote:<br>
</div>
<blockquote type="cite" id="x_qt-qt" style="">
<div>Unfortunately, I only had ccsip and ccapi inout debugs running... I'll add those 2 other sip debugs the next time. This is what I had handy from last night. I'm sure new traces would be very helpful, but can't get to it right now and wanted to at least
 respond.<br>
</div>
<div><br>
</div>
<div>Here is a sanitized copy of the cancel.  The time between the trying and the cancel is always between 6.8 and 6.9 seconds.  <br>
</div>
<div><br>
</div>
<div>CANCEL sip:<a href="mailto:17633334444@voip.centurylink.com">17633334444@voip.centurylink.com</a>:5100 SIP/2.0<br>
</div>
<div>Via: SIP/2.0/UDP voip.centurylink.com:5060;branch=z9hG4bK2804DC216B<br>
</div>
<div>From: sip:1652223333@10.10.10.10;tag=7FF3BC40-14BB<br>
</div>
<div>To: <sip:<a href="mailto:17635670707@voip.centurylink.com">17635670707@voip.centurylink.com</a>><br>
</div>
<div>Date: Thu, 15 Apr 2021 18:39:42 GMT<br>
</div>
<div>Call-ID: <a href="mailto:C6AB9407-9D5011EB-88BF8F36-4C717595@voip.centurylink.com">
C6AB9407-9D5011EB-88BF8F36-HI-MOM@voip.centurylink.com</a><br>
</div>
<div>CSeq: 102 CANCEL<br>
</div>
<div>Max-Forwards: 70<br>
</div>
<div>Timestamp: 1618511989<br>
</div>
<div>Reason: Q.850;cause=0<br>
</div>
<div>Content-Length: 0<br>
</div>
<div><br>
</div>
<div>That pesky 0 for the cause code is making life difficult.<br>
</div>
<div><br>
</div>
<div>On Fri, Apr 16, 2021, at 10:29 AM, Sreekanth Narayanan (sreenara) wrote:<br>
</div>
<blockquote type="cite" id="x_qt-qt-qt" style="">
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
Nick,<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
What's the disconnect cause from the CUBE? 102?<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
Do you have logs for this call? Would be clear which timers are expiring, causing the problem.<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
debug ccsip message<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
debug ccsip error<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
debug ccsip info<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:11pt; color:rgb(0,0,0)">
-sreekanth<br>
</div>
<div id="x_qt-qt-qt-appendonsend"><br>
</div>
<div>
<hr style="display:inline-block; width:98%">
<br>
</div>
<div id="x_qt-qt-qt-divRplyFwdMsg" dir="ltr">
<div><span class="x_qt-qt-font" style=""><span class="x_qt-font" style=""><span class="x_font" style="font-family:Calibri,sans-serif"><span class="x_qt-qt-colour" style="color:rgb(0,0,0)"><b>From:</b> cisco-voip <cisco-voip-bounces@puck.nether.net> on behalf
 of Nick Barnett <nick@barnett.email><br>
<b>Sent:</b> Friday, April 16, 2021 6:53 PM<br>
<b>To:</b> cisco-voip <cisco-voip@puck.nether.net><br>
<b>Subject:</b> [cisco-voip] Outbound SIP connection failing in CUBE due to some timer... maybe.</span></span></span></span></div>
<div> <br>
</div>
</div>
<div>
<div>Yes, very vague subject. Sorry about that. Some calls to certain wireless carriers on our ITSP connections have started failing.
<br>
</div>
<div><br>
</div>
<div>Win10 Jabber client (off of 12.5.su3) -> CUBE -> ITSP<br>
</div>
<div><br>
</div>
<div>The call goes out Lumen, the 401 auth and challenge response are fine, the INVITE is then sent with SDP. We get a TRYING response which we immediately ACK. Up until this point, the entire call flow is NORMAL. <br>
</div>
<div><br>
</div>
<div>If we don't receive a 18X response within  7 Seconds, the, the CUBE sends a cancel. Yes, the CUBE.<br>
</div>
<div><br>
</div>
<div>It appears that the far end is taking too long to send the 18X message. we involved our carrier and they can see the 18X come back a split second later (sometimes), but our side has already closed the connection.<br>
</div>
<div><br>
</div>
<div>I looked at all of the sip-ua timers and retry settings. nothing adds up to 7 seconds. Most timers are set to 500 msec. I'm not sure where to look? It's not on the sip profile.<span style=""> </span><span style="">i tried bumping up the connect, update,
 info and trying timers (one at a time), but it didn't make any difference. Maybe I was supposed to do something to make sip-ua changes "kick in" like bounce the sip service which I didn't do... not sure on that part.</span><br>
</div>
<div><br>
</div>
<div>Please tell me there is something simple I'm missing. Pointers?<br>
</div>
<div><br>
</div>
<div id="x_qt-qt-qt-x_sig91721560">
<div class="x_qt-qt-qt-x_signature">Thanks,<br>
</div>
<div class="x_qt-qt-qt-x_signature">Nick<br>
</div>
<div class="x_qt-qt-qt-x_signature"><br>
</div>
<div class="x_qt-qt-qt-x_signature"><br>
</div>
<div class="x_qt-qt-qt-x_signature">p.s. : some possibly relevant config  and the timers and retries from my sip-ua<br>
</div>
<div class="x_qt-qt-qt-x_signature"><br>
</div>
<div class="x_qt-qt-qt-x_signature">retry invite 2<br>
</div>
</div>
<div>retry response 6<br>
</div>
<div>retry bye 10<br>
</div>
<div>retry cancel 10<br>
</div>
<div>retry prack 10<br>
</div>
<div>retry update 6<br>
</div>
<div>retry rel1xx 6<br>
</div>
<div>retry notify 10<br>
</div>
<div>retry refer 10<br>
</div>
<div>retry info 6<br>
</div>
<div>retry register 6<br>
</div>
<div>retry subscribe 6<br>
</div>
<div>retry keepalive 6<br>
</div>
<div>retry options 6<br>
</div>
<div>timers trying 500<br>
</div>
<div>timers expires 180000<br>
</div>
<div>timers connect 500<br>
</div>
<div>timers connection aging 5<br>
</div>
<div>timers disconnect 500<br>
</div>
<div>timers prack 500<br>
</div>
<div>timers update 500<br>
</div>
<div>timers rel1xx 500<br>
</div>
<div>timers notify 750<br>
</div>
<div>timers refer 500<br>
</div>
<div>timers hold 2880<br>
</div>
<div>timers info 500<br>
</div>
<div>timers register 500<br>
</div>
<div>timers buffer-invite 0<br>
</div>
<div>timers keepalive down 30<br>
</div>
<div>timers keepalive active 120<br>
</div>
<div>timers dns registrar-cache 3600<br>
</div>
<div>timers options 500<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div id="x_qt-qt-sig91721560">
<div class="x_qt-qt-signature">Thanks,<br>
</div>
<div class="x_qt-qt-signature">Nick<br>
</div>
</div>
<div><br>
</div>
<div>_______________________________________________<br>
</div>
<div>cisco-voip mailing list<br>
</div>
<div><a href="mailto:cisco-voip%40puck.nether.net">cisco-voip@puck.nether.net</a><br>
</div>
<div><a href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</div>
<div><br>
</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div id="x_qt-sig91721560">
<div class="x_qt-signature">Thanks,<br>
</div>
<div class="x_qt-signature">Nick<br>
</div>
</div>
<div><br>
</div>
<div>_______________________________________________<br>
</div>
<div>cisco-voip mailing list<br>
</div>
<div><a href="mailto:cisco-voip%40puck.nether.net">cisco-voip@puck.nether.net</a><br>
</div>
<div><a href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</div>
<div><br>
</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div id="x_sig91721560">
<div class="x_signature">Thanks,<br>
</div>
<div class="x_signature">Nick<br>
</div>
</div>
<div><br>
</div>
</div>
</body>
</html>