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.
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. CANCEL sip:17633334...@voip.centurylink.com:5100 SIP/2.0 Via: SIP/2.0/UDP voip.centurylink.com:5060;branch=z9hG4bK2804DC216B From: sip:1652223333@10.10.10.10;tag=7FF3BC40-14BB To: <sip:17635670...@voip.centurylink.com> Date: Thu, 15 Apr 2021 18:39:42 GMT Call-ID: c6ab9407-9d5011eb-88bf8f36-hi-...@voip.centurylink.com <mailto:c6ab9407-9d5011eb-88bf8f36-4c717...@voip.centurylink.com> CSeq: 102 CANCEL Max-Forwards: 70 Timestamp: 1618511989 Reason: Q.850;cause=0 Content-Length: 0 That pesky 0 for the cause code is making life difficult. On Fri, Apr 16, 2021, at 10:29 AM, Sreekanth Narayanan (sreenara) wrote: > Nick, > > What's the disconnect cause from the CUBE? 102? > > Do you have logs for this call? Would be clear which timers are expiring, > causing the problem. > debug ccsip message > debug ccsip error > debug ccsip info > > -sreekanth > > > *From:* cisco-voip <cisco-voip-boun...@puck.nether.net> on behalf of Nick > Barnett <nick@barnett.email> > *Sent:* Friday, April 16, 2021 6:53 PM > *To:* cisco-voip <cisco-voip@puck.nether.net> > *Subject:* [cisco-voip] Outbound SIP connection failing in CUBE due to some > timer... maybe. > > Yes, very vague subject. Sorry about that. Some calls to certain wireless > carriers on our ITSP connections have started failing. > > Win10 Jabber client (off of 12.5.su3) -> CUBE -> ITSP > > 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. > > If we don't receive a 18X response within 7 Seconds, the, the CUBE sends a > cancel. Yes, the CUBE. > > 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. > > 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. 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. > > Please tell me there is something simple I'm missing. Pointers? > > Thanks, > Nick > > > p.s. : some possibly relevant config and the timers and retries from my > sip-ua > > retry invite 2 > retry response 6 > retry bye 10 > retry cancel 10 > retry prack 10 > retry update 6 > retry rel1xx 6 > retry notify 10 > retry refer 10 > retry info 6 > retry register 6 > retry subscribe 6 > retry keepalive 6 > retry options 6 > timers trying 500 > timers expires 180000 > timers connect 500 > timers connection aging 5 > timers disconnect 500 > timers prack 500 > timers update 500 > timers rel1xx 500 > timers notify 750 > timers refer 500 > timers hold 2880 > timers info 500 > timers register 500 > timers buffer-invite 0 > timers keepalive down 30 > timers keepalive active 120 > timers dns registrar-cache 3600 > timers options 500 Thanks, Nick
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
