Conversation
…mer D A client transaction lingers in Completed to absorb retransmitted final responses. RFC 3261 17.1.1.2 gives an INVITE client transaction Timer D — 32 seconds on unreliable transports; 17.1.2.2 gives a non-INVITE one Timer K, which is T4. Init() set timer_d_time to Timer_D for both, so every OPTIONS, BYE, INFO and REGISTER transaction stayed in the transaction layer roughly six times longer than the RFC asks for. The behaviour is not wrong on the wire — the transaction simply absorbs retransmissions longer than it has to — but the table grows: a proxy or B2BUA that keep-alives many peers with OPTIONS holds thousands of terminated-but-not-removed transactions. Timer_K was already declared and populated by SetTimers, and was the only timer of the set never read. TestClientTxCompletedWaitPerMethod covers both kinds.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A client transaction lingers in
Completedto absorb retransmitted finalresponses. RFC 3261 gives the two transaction kinds different timers for
that wait:
32 seconds for unreliable transports";
is
T4for unreliable transports.ClientTx.Initsetstimer_d_time = Timer_Dfor both kinds, so everyOPTIONS,BYE,INFOandREGISTERtransaction stays in thetransaction layer roughly six times longer than the RFC asks for (32s
against the default T4 of 5s).
Nothing wrong happens on the wire — the transaction simply absorbs
retransmissions longer than it has to — but the transaction table grows.
It shows up on a proxy or B2BUA that keep-alives its peers with
OPTIONS:with one probe per peer every few seconds, thousands of transactions that
should already be gone are still held.
Timer_Kis already declared and populated bySetTimers; before thischange it was the only timer of the set that nothing ever read.
Fix
Pick the wait by the method of the request the transaction was created
for:
The reliable-transport branch is untouched: there the wait is 0 for both
kinds, which is what 17.1.1.2 and 17.1.2.2 say.
Test
TestClientTxCompletedWaitPerMethodbuilds a client transaction for eachof four cases and checks the wait it got:
Timer_DTimer_KThe TCP rows are there because the change is confined to the unreliable
branch, and that is worth holding: a later change must not start arming a
timer over a reliable transport. On the current code the OPTIONS-over-UDP
row fails.
Compatibility
No public API change. Behaviour changes only in how long a terminated
non-INVITE client transaction is retained, and only towards what the RFC
prescribes.