Hi,
I'm looking to tweak setting to help my SIP phone reestablish connection on Internet failover. To start off I'd like to make sure I understand the concepts. If I understand correctly the UDP timeouts work as follows..

"UDP Timeout" applies to a UDP connection initiated outbound but no reply yet
"UDP Stream" applies to a two way UDP conversation

Assuming that's correct, what timeout applies if an established connection breaks down, if you keep sending but stop getting replies? That's what happens when Internet fails over, the connection already exists so it hangs on to the previous NAT, meaning it's not going to receive an answer. Do the continuing unsuccessful outbound packets refresh the "UDP Stream" timeout even though there are no more replies?

I believe this is the setting you want to ammend for your UDP timeouts
However - be careful with this, don't set it to a year and think that's fine. Leaving too long may mean that gaps between calls are shorter than your timeout at which point your router will start trying to reconnect old calls.
I would push up to 60s - I think the most I have ever ran is 10mins. If you are using a cloud hosted PBX or similar then this is less a thing on firewall and more a thing on host keepalive.

Thanks, my SIP device is Gigaset N300A. If keeps connections open by sending SIP Options Pings every few seconds, there's no need for long connection timeouts. 30 seconds is plenty.

And of course as stated for my requirement the last thing I want is the connection to stick any longer than necessary.

The setting you mention, "udp-timeout" is only relevant to the first outbound packet, before it's answered. Default is 10 seconds but just as a test I can reduce it down to one second and the phone still registers fine. The connections created as it does so have a 30 second timeout, which actually shows they're using the SIP setting rather than either of the UDP timeouts.

I still don't know the answer to my question, which is whether the Stream or SIP timeouts will still be in effect if the connection stops getting replies, or whether it will fall back to the one-way "udp-timeout"

The current default is 30S, it was 10S for quite a few versions, but there were plenty of people having issues with the 10S value.

The current default is 30S, it was 10S for quite a few versions, but there were plenty of people having issues with the 10S value.

In my network the problem is caused by these timeouts being too long. Before I started my tests just now udp-timeout was 10 seconds which is the default 9n this router (RB4011 6.49.13). That's near to the polling interval for the phone giving a risk that unanswered polls will still keep the connection open, which is what causes the fault.

I found no adverse effects even dropping it down to one second but for the moment I'm compromising on 8s. To be honest I can't imagine a situation where a UDP packet is sent, and the answer takes more than a second to arrive.

You say there were issues with 10s. What circumstances was a UDP reply taking more than 10s (but less than 20)?

Current settings which so far are looking hopeful ..

How did this get marked as "Solved", is that automatic if any reply is posted whether the question was answered or not?

RDP connection dying was one thread
viewtopic.php?p=992900

That's interesting although it's not a matter of a UDP reply taking more than 10 seconds.

I would class that as design error in ROS 7. Requiring three packets before it considers it a stream means that any normal keep-alive will trigger only "udp-timeout". Presumably in ROS 6 the stream is established by two packets, hence RDP with its 15s keep-alive working fine with a 10s timeout.

Is there and documentation explaining exactly what timeouts come into effect, and the interaction between "udp-stream-timeout", "udp-timeout" and "sip-timeout"?

You're definitely on the right track with the UDP timeout concepts! From my experience, when an established connection goes down and you're still sending packets without replies, it's really the UDP stream timeout that matters. I've noticed that if the phone keeps sending packets, it might hold onto the connection longer than expected because it's waiting for a response. But if those packets aren't getting through during a failover, that timeout will eventually kick in, and the connection will drop. I had to tweak those settings a bit when I was dealing with similar issues, and adjusting the stream timeout helped my SIP phone reconnect more quickly after an internet failover.

I'm finding it bit frustrating looking for the details. For example as I understand it udp-timeout starts when the first packet is sent or received. That one is fairly clear but the others aren't.

1. How many packets before udp-stream-timeout comes into effect? 9I've seen it stated that 7.x takes three, and it's implied that's a change from 6.x)
2. Does it have to be two way to be considered a stream?
3. If no more replies are received after the stream is established, what is the timeout behaviour? Does the connection stay up as long as one unanswered packet is sent within the udp-stream-timeout?

4. When does "sip-timeout" come into effect? On the first recognisable SIP packet, or only once there's two way?
5. What is considered SIP anyway, is it just determined by port or does it need a recognisable SIP request or response?
6. Once a connection is established as SIP how does it behave if it stops getting replies? Does it stay up as long as at least one packet passes either way within sip-timeout? Or does it have to contain a valid SIP request or response?

Test just now with udp-timeout=8s, udp-stream-timeout=60s and sip-timeout=30s

If I delete one of the SIP connections it almost instantly establishes with 30s timeout, cycling between up to 28 or so, down to 10 or so. Up to that point the only traffic is outbound, what Gigaset call "NAT keepalive" which are sent every 20s. So I think I can answer a couple of the undocumented unknowns ...

4. When does "sip-timeout" come into effect? On the first recognisable SIP packet, or only once there's two way?
...... First packet, no reply needed. (Making udp-timeout irrelevant)

5. What is considered SIP anyway, is it just determined by port or does it need a recognisable SIP request or response?
...... It must be simply by port, those keepalives don't contain any SIP method.

And a hint towards the last unknown..

6. Once a connection is established as SIP how does it behave if it stops getting replies? Does it stay up as long as at least one packet passes either way within sip-timeout? Or does it have to contain a valid SIP request or response?
....... One-way traffic established the connection type, which suggests unanswered traffic would refresh the timeout.