You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've noted a couple of issues with the 2xx retransmissions in RTCSession.
On rare occasions, I have noted unexpected 200 transmissions - an ACK has been received, but 200s are retransmitted regardless. I suspect this is due to a race condition with set/clear timeout calls in the browser. JavaScript is fundamentally single-threaded, so a timeout expiring results in an extra event being added to a queue. If we are currently processing an incoming ACK at the moment the timer expires (before we clear the retransmit timer), we end up sending an additional 200 response immediately after the ACK processing finishes, and then continue sending 200 responses because the supposedly cleared timer has been reset.
I've also noticed that the 2xx retransmission schedule is a bit odd. The timeout doubles after each retransmission until it reaches T2, then retransmissions stop. I think this is an incorrect interpretation of section 13.3.1.4 - the doubling is supposed to stop, not the retransmissions. The retransmissions should only stop in one of the following cases:
An ACK is received
64*T1 seconds have passed (timer H)
A pull request with my suggested changes will follow shortly.
The text was updated successfully, but these errors were encountered:
gavllew
pushed a commit
to crocodilertc/JsSIP
that referenced
this issue
Jul 10, 2013
I've noted a couple of issues with the 2xx retransmissions in
RTCSession
.On rare occasions, I have noted unexpected 200 transmissions - an ACK has been received, but 200s are retransmitted regardless. I suspect this is due to a race condition with set/clear timeout calls in the browser. JavaScript is fundamentally single-threaded, so a timeout expiring results in an extra event being added to a queue. If we are currently processing an incoming ACK at the moment the timer expires (before we clear the retransmit timer), we end up sending an additional 200 response immediately after the ACK processing finishes, and then continue sending 200 responses because the supposedly cleared timer has been reset.
I've also noticed that the 2xx retransmission schedule is a bit odd. The timeout doubles after each retransmission until it reaches T2, then retransmissions stop. I think this is an incorrect interpretation of section 13.3.1.4 - the doubling is supposed to stop, not the retransmissions. The retransmissions should only stop in one of the following cases:
A pull request with my suggested changes will follow shortly.
The text was updated successfully, but these errors were encountered: