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

[Nick Barnett]

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.

On Fri, Apr 16, 2021, at 11:25 AM, Nick Barnett wrote:
> 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
> 
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net <mailto:cisco-voip%40puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-voip
> 


Thanks,
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20210419/5e69b1ba/attachment.htm>