Repro's handling of Timer C

[resiprocate]

Repro's handling of Timer C

[TheQue42]

It definitely seems wrong to use a single timer c for all txns, since 1xx will/should restart the timer, and that means that a 180 response on one transaction, can keep all transactions going.

[sgodin]

I just re-read the RFCs and examined the repro code and I agree with your analysis, I think repro should be tracking timer C per client transaction. Here's a quote from the RFC that makes it pretty clear: 11. Set timer C In order to handle the case where an INVITE request never generates a final response, the TU uses a timer which is called timer C. Timer C MUST be set for each client transaction when an INVITE request is proxied. The timer MUST be larger than 3 minutes. Section 16.7 bullet 2 discusses how this timer is updated with provisional responses, and Section 16.8 discusses processing when it fires. I'll add this to the issues list. I anyone has cycles to work on a pull request for this, then please also consider that there are some TFM test cases for TimerC that may need adjusting as well. Best Regards, Scott Godin

…

On Wed, Jan 19, 2022 at 1:47 AM Taisto Qvist ***@***.***> wrote: It definitely seems wrong to use a single timer c for all txns, since 1xx will/should restart the timer, and that means that a 180 response on one transaction, can keep all transactions going. — Reply to this email directly, view it on GitHub <#209 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVU2UPZ7KNLXUUSJFEEOT3UWZNADANCNFSM5MGQQWNA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[IvanRibakov]

Answering one of my earlier questions:

2. Is it possible to continue routing call to other targets after one of them triggered Timer C?

Probably not after TimerC expiry, but a similar behaviour can be achieved if using Q-Value Target Handler Baboon by adjusting following configuration parameters:

• QValueCancelBetweenForkGroups = true
• QValueMsBeforeCancel = ...

[sgodin]

A fix for this has been merged into master.