Troubleshooting: Retransmission timeout reached on transmission

Hello, from time to time, I’m receiving several of these messages on the Asterisk console:

...
[2023-09-12 09:14:27] WARNING[27861]: chan_sip.c:4119 retrans_pkt: Retransmission timeout reached on transmission 8324b72c6cac44c7a0d6424bdf8dbabc for seqno 104 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 6400ms with no response
[2023-09-12 09:14:27] WARNING[27861]: chan_sip.c:4119 retrans_pkt: Retransmission timeout reached on transmission 88709ff97c084f10b9321d2ac005a237 for seqno 104 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 6401ms with no response
[2023-09-12 09:14:27] WARNING[27861]: chan_sip.c:4119 retrans_pkt: Retransmission timeout reached on transmission e2cb314f4611451bb5d9d5218fa18629 for seqno 104 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 6400ms with no response
[2023-09-12 09:14:27] WARNING[27861]: chan_sip.c:4119 retrans_pkt: Retransmission timeout reached on transmission 73e3a21d6c1a4cc09c848f6a603e8a69 for seqno 104 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 6400ms with no response
[2023-09-12 09:14:27] WARNING[27861]: chan_sip.c:4119 retrans_pkt: Retransmission timeout reached on transmission f9d78cbd6f0240e78b54c81c91087464 for seqno 107 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 6400ms with no response
...

I checked, and there aren’t many simultaneous calls happening on this Asterisk:

superimec*CLI> core show channels verbose
Channel              Context              Extension        Prio State   Application  Data                      CallerID        Duration Accountcode PeerAccount BridgeID
SIP/8463-00044120    ddd                  8463                1 Ringing AppDial      (Outgoing Line)           8463            00:00:05
SIP/8925-00044116    ligacaoramal         8140                4 Up      Dial         SIP/8140,60,tTg           8925            00:00:51                         0971c6cf-90e4-4dab-9
SIP/8786-00044118    ddd                  8101                2 Up      Queue        servicedesk,tT            8786            00:00:44
SIP/8181-00044114    ddd                                      1 Up      AppDial      (Outgoing Line)           8181            00:01:05                         a5e9df4a-9d37-4f25-b
SIP/8140-00044117    ddd                                      1 Up      AppDial      (Outgoing Line)           8140            00:00:51                         0971c6cf-90e4-4dab-9
SIP/8206-00044111    ligacaoramal         8186                4 Up      Dial         SIP/8186,60,tTg           8206            00:01:14                         396a255e-d4b1-494a-9
SIP/8117-000440cb    ddd                                      1 Up      AppDial      (Outgoing Line)           8117            00:07:57                         f32dfb22-3203-4af2-9
SIP/8200-0004411e    oi                   8101                1 Ringing AppQueue     (Outgoing Line)           8200            00:00:06
SIP/8177-0004411f    ligacaoramal         8463                4 Ring    Dial         SIP/8463,60,tTg           8177            00:00:05
SIP/oi-00044110      ura                  3                   1 Up      Queue        ura-cd-logistica,t,,,300  4133836067      00:01:15
SIP/8301-000440fe    ddd                                      1 Up      AppDial      (Outgoing Line)           8301            00:02:59                         aea8f894-d081-463d-8
SIP/8232-00044121    ddd                  3                   1 Ringing AppQueue     (Outgoing Line)           8232            00:00:02
SIP/8245-000440a2    ligacaoramal         8181                4 Up      Dial         SIP/8181,60,tTg           8245            00:01:05                         a5e9df4a-9d37-4f25-b
SIP/8186-00044112    oi                                       1 Up      AppDial      (Outgoing Line)           8186            00:01:14                         396a255e-d4b1-494a-9
SIP/8261-000440ca    ligacaoramal         8117                4 Up      Dial         SIP/8117,60,tTg           8261            00:07:57                         f32dfb22-3203-4af2-9
SIP/8913-000440fd    ligacaoramal         8301                4 Up      Dial         SIP/8301,60,tTg           8913            00:02:59                         aea8f894-d081-463d-8
Message/ast_msg_queu messages             8282                6 Up      Hangup       (Empty)                                   641:19:5
16 active channels
8 active calls
129930 calls processed

I’m using Debian 9 and Asterisk 16.4.0.

I have already configured the externip and localnet in the sip.conf to prevent NAT-related issues.

I don’t know what’s happening that’s causing these errors, and I need help to understand what’s going on and resolve this issue.

Please, I would like guidance on how to understand and identify the source of this problem in order to then resolve it.

So far, I haven’t received any reports from users, and I’d like to resolve this before it becomes a bigger issue.

Thanks.

What causes them is sending a re-INVITE and never getting any response after the maximum number of retries.

chan_sip is no longer supported, but the main difference with chan_pjsip is that it doesn’t use adaptive timeouts, so the failure will be at 32 seconds, not at 6.4.

A question about these re-INVITEs, when do they occur? Does this happen when registering a SIP, when making or receiving calls, or when a call is terminated?

Despite knowing that chan_sip has been discontinued, I have a customer base with production Asterisk systems that use chan_sip and that I need to maintain. Updating to chan_pjsip will take time.

I need to know if this affects calls in any way and if it’s possible to identify the source of the issue, as well as if it’s possible to resolve it.

Thanks.

Re-INVITEs happen within a call. They happen for various reasons, including to route media directly, to update the connected line information, and refresh session timers.

Actually, I think BYE also counts as a critical request.

Another reason for re-INVITE is T.38 fax attempts.

Thanks, but that is not the case.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.