<div dir="ltr"><div dir="ltr">Hello,<br><br>I have a scenario where freeswitch bridges a call received with TCP on leg A to a destination with TCP on leg B<br>When the destination rejects the call with 486 (Busy Here) that is sent back to leg A which receives the ACK as expected.<br><br>So from the leg A perspective we have:<br><br>INVITE<br>100 Trying<br>180 Ringing<br>486 Busy Here<br>ACK<br><br>After the ACK freeswitch seems to be starting the Timer D (32 seconds) even for that TCP transaction.<br><br>This is what the log show when the ACK is received:<br><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div>tport.c:2771 tport_wakeup() tport_wakeup(0x561ffce1c3e0): events IN</div></div><div><div>tport.c:2868 tport_recv_event() tport_recv_event(0x561ffce1c3e0)</div></div><div><div>tport.c:3205 tport_recv_iovec() tport_recv_iovec(0x561ffce1c3e0) msg 0x561ffcf2f700 from (tcp/<a href="http://192.168.100.100:34863">192.168.100.100:34863</a>) has 394 bytes, veclen = 1</div></div><div><div>tport.c:3023 tport_deliver() tport_deliver(0x561ffce1c3e0): msg 0x561ffcf2f700 (394 bytes) from tcp/<a href="http://192.168.100.100:34863/sip">192.168.100.100:34863/sip</a> next=0</div></div><div><div>nta.c:2877 agent_recv_request() nta: received ACK <a href="mailto:sip%3A6111@172.16.100.1">sip:6111@172.16.100.1</a>;transport=tcp SIP/2.0 (CSeq 1)</div></div><div><div>nta.c:3017 agent_recv_request() nta: ACK (1) is going to INVITE (1)</div></div><div><div>tport.c:2298 tport_set_secondary_timer() tport(0x561ffce1c3e0): reset timer</div></div><div><div>2020-11-26 17:37:16.622026 [DEBUG] switch_scheduler.c:144 Deleting task 292 switch_ivr_schedule_hangup (372ca1ff-4466-48c5-a5a0-a22612a217ed)</div></div><div><div><br></div></div></blockquote>then 32 seconds later<br><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><br></div></div><div><div>nta.c:9106 outgoing_timer_dk() nta: timer D fired, terminate INVITE (28652323)</div></div><div><div>tport.c:2298 tport_set_secondary_timer() tport(0x561ffcf30a80): reset timer</div></div><div><div>nta.c:8804 outgoing_reclaim_queued() outgoing_reclaim_all(0, 0, 0x7f52bceb8958)</div></div><div><div>nta.c:8927 _nta_outgoing_timer() nta_outgoing_timer: 0/0 resent, 0/0 tout, 1/1 term, 1/1 free</div></div><div><div>tport.c:2298 tport_set_secondary_timer() tport(0x561ffce1c3e0): reset timer</div></div><div><div>nta.c:5824 incoming_reclaim_queued() incoming_reclaim_all(0, 0, 0x7f52bceb8958)</div></div><div><div>nta.c:7186 _nta_incoming_timer() nta_incoming_timer: 0/0 resent, 0/0 tout, 0/0 term, 1/1 free</div></div><div><div>nta.c:1289 agent_timer() nta: timer not set</div></div></blockquote><div dir="ltr"><br><br>Based on the RFC 3261 section-17.1.1.2 (<a href="https://tools.ietf.org/html/rfc3261#section-17.1.1.2">https://tools.ietf.org/html/rfc3261#section-17.1.1.2</a>) it seems that Timer D should zero seconds for reliable transport (TCP):<br><br><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">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.<br><br></blockquote>Should this be considered a BUG?</div><div dir="ltr"><br></div></div>