Mailing List Archive

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
Re: Outbound SIP connection failing in CUBE due to some timer... maybe. [ In reply to ]
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@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
Re: Outbound SIP connection failing in CUBE due to some timer... maybe. [ In reply to ]
Was this working before?I had problems before on a 4331 CUBE. I had to redo the password on the CUBE to Lumen.it was the same password that was already there. and a reboot didn't fix it.


On Friday, April 16, 2021, 08:32:22 AM PDT, Sreekanth Narayanan (sreenara) via cisco-voip <cisco-voip@puck.nether.net> 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 messagedebug ccsip errordebug ccsip info
-sreekanthFrom: cisco-voip <cisco-voip-bounces@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
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
Re: Outbound SIP connection failing in CUBE due to some timer... maybe. [ In reply to ]
This was working. It broke yesterday at like 11am. Lumen says ATT has an interconnect issue. ATT is clueless about it though. It's all over the place though. Some calls that are routing through ATT are failing. Some that end on Tmobile are failing. I will try to refresh the auth password on it... that's a weird one.

On Fri, Apr 16, 2021, at 11:04 AM, Carlo Calabrese wrote:
>
> Was this working before?
> I had problems before on a 4331 CUBE. I had to redo the password on the CUBE to Lumen.
> it was the same password that was already there. and a reboot didn't fix it.
>
>
>
> On Friday, April 16, 2021, 08:32:22 AM PDT, Sreekanth Narayanan (sreenara) via cisco-voip <cisco-voip@puck.nether.net> 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@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
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip


Thanks,
Nick
Re: Outbound SIP connection failing in CUBE due to some timer... maybe. [ In reply to ]
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@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:17635670707@voip.centurylink.com>
Date: Thu, 15 Apr 2021 18:39:42 GMT
Call-ID: C6AB9407-9D5011EB-88BF8F36-HI-MOM@voip.centurylink.com <mailto:C6AB9407-9D5011EB-88BF8F36-4C717595@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@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
Re: Outbound SIP connection failing in CUBE due to some timer... maybe. [ In reply to ]
Just keep in mind ccsip and the ccapi can generate high cpu as well as log traffic. Syslog off the router is good so you don’t over run the buffer. Or set up a 1-5 meg buffer.

Not sure of your call volume but don’t forget cpu load. Granted the 44xx platform is beafy but sometimes that’s overlooked with trying to resolve an issue.

Might take a bit but if you can get sbc logs from your itsc for your test call they can prove useful too

We had to do that before for tac to review an issue. We also learned of cube crashes resulting in router reboots because the iOS coders assumed everyone followed standards. And data back missing something crashed it

Kent

> On Apr 16, 2021, at 10:27, Nick Barnett <nick@barnett.email> 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@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:17635670707@voip.centurylink.com>
> Date: Thu, 15 Apr 2021 18:39:42 GMT
> Call-ID: C6AB9407-9D5011EB-88BF8F36-HI-MOM@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@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
Re: Outbound SIP connection failing in CUBE due to some timer... maybe. [ In reply to ]
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@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:17635670707@voip.centurylink.com>
> Date: Thu, 15 Apr 2021 18:39:42 GMT
> Call-ID: C6AB9407-9D5011EB-88BF8F36-HI-MOM@voip.centurylink.com <mailto:C6AB9407-9D5011EB-88BF8F36-4C717595@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@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 <mailto:cisco-voip%40puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-voip
>


Thanks,
Nick
Re: Outbound SIP connection failing in CUBE due to some timer... maybe. [ In reply to ]
Sounds like ATT and Verizon’s. “Cleared while testing”. Response….

> On Apr 19, 2021, at 7:24 AM, Nick Barnett <nick@barnett.email> wrote:
>
> 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@voip.centurylink.com <mailto:17633334444@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:17635670707@voip.centurylink.com <mailto:17635670707@voip.centurylink.com>>
>> Date: Thu, 15 Apr 2021 18:39:42 GMT
>> Call-ID: C6AB9407-9D5011EB-88BF8F36-HI-MOM@voip.centurylink.com <mailto:C6AB9407-9D5011EB-88BF8F36-4C717595@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@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 <mailto:cisco-voip%40puck.nether.net>
>> https://puck.nether.net/mailman/listinfo/cisco-voip <https://puck.nether.net/mailman/listinfo/cisco-voip>
>>
>
>
> Thanks,
> Nick
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net <mailto:cisco-voip@puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-voip <https://puck.nether.net/mailman/listinfo/cisco-voip>
Re: Outbound SIP connection failing in CUBE due to some timer... maybe. [ In reply to ]
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.

application
service survivability
param setup-timeout 15


On Mon, Apr 19, 2021, at 8:24 AM, Nick Barnett wrote:
> 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@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:17635670707@voip.centurylink.com>
>> Date: Thu, 15 Apr 2021 18:39:42 GMT
>> Call-ID: C6AB9407-9D5011EB-88BF8F36-HI-MOM@voip.centurylink.com <mailto:C6AB9407-9D5011EB-88BF8F36-4C717595@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@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 <mailto:cisco-voip%40puck.nether.net>
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>
>
> Thanks,
> Nick
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net <mailto:cisco-voip%40puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-voip
>


Thanks,
Nick
Re: Outbound SIP connection failing in CUBE due to some timer... maybe. [ In reply to ]
Thanks Nick! This clears up the mystery of why the router was behaving different from default.

-sreekanth
________________________________
From: Nick Barnett <nick@barnett.email>
Sent: Tuesday, April 27, 2021 9:11 PM
To: Sreekanth Narayanan (sreenara) <sreenara@cisco.com>; cisco-voip <cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] Outbound SIP connection failing in CUBE due to some timer... maybe.

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.

application
service survivability
param setup-timeout 15


On Mon, Apr 19, 2021, at 8:24 AM, Nick Barnett wrote:
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@voip.centurylink.com<mailto:17633334444@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:17635670707@voip.centurylink.com<mailto:17635670707@voip.centurylink.com>>
Date: Thu, 15 Apr 2021 18:39:42 GMT
Call-ID: C6AB9407-9D5011EB-88BF8F36-HI-MOM@voip.centurylink.com<mailto:C6AB9407-9D5011EB-88BF8F36-4C717595@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@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<mailto:cisco-voip%40puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip



Thanks,
Nick

_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip%40puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip



Thanks,
Nick