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@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?