[cisco-voip] Outbound SIP connection failing in CUBE due to some timer... maybe.

[Nick Barnett]

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:17633334444 at voip.centurylink.com:5100 SIP/2.0
Via: SIP/2.0/UDP voip.centurylink.com:5060;branch=z9hG4bK2804DC216B
From: sip:1652223333 at 10.10.10.10;tag=7FF3BC40-14BB
To: <sip:17635670707 at voip.centurylink.com>
Date: Thu, 15 Apr 2021 18:39:42 GMT
Call-ID: C6AB9407-9D5011EB-88BF8F36-HI-MOM at voip.centurylink.com <mailto:C6AB9407-9D5011EB-88BF8F36-4C717595 at 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-bounces at puck.nether.net> on behalf of Nick Barnett <nick at barnett.email>
> *Sent:* Friday, April 16, 2021 6:53 PM
> *To:* cisco-voip <cisco-voip at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20210416/e17690d7/attachment.htm>