Sponsor: VoiceMeUp - Corporate & Wholesale VoIP Services

VoIP Mailing List Archives
Mailing list archives for the VoIP community
 SearchSearch 

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


 
Post new topic   Reply to topic    VoIP Mailing List Archives Forum Index -> freeSWITCH Users
View previous topic :: View next topic  
Author Message
joao.arruda at gmail.com
Guest





PostPosted: Thu Dec 03, 2020 6:49 pm    Post subject: [Freeswitch-users] Timer D (32 seconds) being triggered afte Reply with quote

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:


Quote:
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 ([email]sip%3A6111@172.16.100.1[/email]);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
Quote:



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):

Quote:
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?
Back to top
Display posts from previous:   
Post new topic   Reply to topic    VoIP Mailing List Archives Forum Index -> freeSWITCH Users All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group

VoiceMeUp - Corporate & Wholesale VoIP Services