[Freeswitch-users] Timer D (32 seconds) being triggered after ACK in TCP INVITE Transaction

[João Vitor Arruda]

Hello,

I have a scenario where freeswitch bridges a call received with TCP on leg
A to a destination with TCP on leg B
When the destination rejects the call with 486 (Busy Here) that is sent
back to leg A which receives the ACK as expected.

So from the leg A perspective we have:

INVITE
100 Trying
180 Ringing
486 Busy Here
ACK

After the ACK freeswitch seems to be starting the Timer D (32 seconds) even
for that TCP transaction.

This is what the log show when the ACK is received:

tport.c:2771 tport_wakeup() tport_wakeup(0x561ffce1c3e0): events IN
tport.c:2868 tport_recv_event() tport_recv_event(0x561ffce1c3e0)
tport.c:3205 tport_recv_iovec() tport_recv_iovec(0x561ffce1c3e0) msg
0x561ffcf2f700 from (tcp/192.168.100.100:34863) has 394 bytes, veclen = 1
tport.c:3023 tport_deliver() tport_deliver(0x561ffce1c3e0): msg
0x561ffcf2f700 (394 bytes) from tcp/192.168.100.100:34863/sip next=0
nta.c:2877 agent_recv_request() nta: received ACK
sip:6111 at 172.16.100.1;transport=tcp
SIP/2.0 (CSeq 1)
nta.c:3017 agent_recv_request() nta: ACK (1) is going to INVITE (1)
tport.c:2298 tport_set_secondary_timer() tport(0x561ffce1c3e0): reset timer
2020-11-26 17:37:16.622026 [DEBUG] switch_scheduler.c:144 Deleting task 292
switch_ivr_schedule_hangup (372ca1ff-4466-48c5-a5a0-a22612a217ed)

then 32 seconds later


nta.c:9106 outgoing_timer_dk() nta: timer D fired, terminate INVITE
(28652323)
tport.c:2298 tport_set_secondary_timer() tport(0x561ffcf30a80): reset timer
nta.c:8804 outgoing_reclaim_queued() outgoing_reclaim_all(0, 0,
0x7f52bceb8958)
nta.c:8927 _nta_outgoing_timer() nta_outgoing_timer: 0/0 resent, 0/0 tout,
1/1 term, 1/1 free
tport.c:2298 tport_set_secondary_timer() tport(0x561ffce1c3e0): reset timer
nta.c:5824 incoming_reclaim_queued() incoming_reclaim_all(0, 0,
0x7f52bceb8958)
nta.c:7186 _nta_incoming_timer() nta_incoming_timer: 0/0 resent, 0/0 tout,
0/0 term, 1/1 free
nta.c:1289 agent_timer() nta: timer not set



Based on the RFC 3261 section-17.1.1.2 (
https://tools.ietf.org/html/rfc3261#section-17.1.1.2) it seems that Timer D
should zero seconds for reliable transport (TCP):

The ACK MUST be sent to the same address, port, and transport to which the
original request was sent.  The client transaction SHOULD start timer D
when it enters the "Completed" state, with a value of at least 32 seconds
for unreliable transports, and a value of zero seconds for reliable
transports Timer D reflects the amount of time that the server transaction
can remain in the "Completed" state when unreliable transports are used.

Should this be considered a BUG?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20201126/2cceb4e3/attachment-0001.html>