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?