Hello
I have an HAP Ac3 with a standard configuration at a customer's site.
Router does NAT masquerade, as the default config.
All firewall helpers are off.

I upgraded from 6.48.6 to 7.1.5 and it worked
upgraded till 7.4 and worked.
from 7.4.1 and then on 7.5 the Gigaset 690 doesnt register anymore.
I tried enabling the sip helper, it now register but I have holes in audio stream.
I downgrade on the 6.48.6 and it works.

What can I check ?
On the firewall connections on the 7.4.1 and 7.5 I see the connections udp going up and then after a few secs, disappears from the conntrack table.
With the SIP helpers it stays there, with the timeout of 1h (my conntrack timeouts are defaults).
On the 6.48.6 it has a timeout of 3min but periodically resets to 3 minutes and the connections stays up without any problems.

On version 6.48.6, under firewall/connections/tracking, the udp stream timeout was 3 minutes. The default udp stream timeout is still the same on upgrading my rb951g to version 7.5. Perhaps you could double-check that the udp stream timeout has not changed.

viewtopic.php?t=178364
Probably same thing.
Short version, UDP streams are not detected properly and you have to increase general UDP timeout instead.
I have not tested this and didn't encounter any issues, I'm not using the RouterOS default timeouts anyway.

I have solved reverting to latest long-term on v6.
I didnt have possibility to make further test since the customers needed a working VOIP Phone.

this is reverted unsolved,
reverting to v6 can't be the solution

Just have that same issue. after about 3 min all VoIP stops working.
I'm 100% certain it's this version of firmware because only for user that have 7.4.x and 7.5 user this happened.
we checked with ISP and VoIP operator and every time it happens when there is version 7.4.x and 7.5 involved :/
After reverting to 7.3.1 everything starts working properly again

this is reverted unsolved,
reverting to v6 can't be the soluction

If the bug is in the release 7.4.x and 7.5, the SOLUTION is to downgrade.

If it broke everyone's voip, I'm sure there would be more than just a handful of people reporting an issue.

I am currently using 7.5 and have been regularly updating ROS with no issues on my voip services. I use asterisk connecting to multiple providers.

You could post your config or revert and open a ticket with support on it.

CCR2004-16G-2S+ Ros7.5
About 70 PPPoE Users and all using VoIP, all of them looks OK since 13 days (time that I upgraded router).
Elia seems you back luck this time dude ... Or is a problem with device model + RoS version.

Try disabling your fasttrack firewall rule if you have one.

Tried. No diffeewnce

ROS V7 uses a 5.x Linux Kernel, with a new type of sip helper. For me it now actually works, where I had to use lots of workarounds in 6.x release.

On the client I enabled the SIP helper, and added 2 rules to the firewall: No NAT, no STUN.

pfff run into the same issue with v7.7. The problem is i cannot roll back. This is a new 5009 router that doesn't run v6

I have tried also with 7.7 with the SIP helper on and off.
no changes.
It appears that I have solved setting an higher udp timeout (the same issue as RDP) from 10 to 20secs.

I can also confirm that after moving to ROS 7.8 from latest 6.X version SIP was broken.

Once I updated the UDP timeout to 20 seconds, from the 10 seconds, and killed the existing connections in the IP->Firewall->Connections tab, then SIP started working again. No need to enable the SIP Helper, just the UDP change was required.

Thanks,

Chris

I can also confirm that after moving to ROS 7.8 from latest 6.X version SIP was broken.

Once I updated the UDP timeout to 20 seconds, from the 10 seconds, and killed the existing connections in the IP->Firewall->Connections tab, then SIP started working again. No need to enable the SIP Helper, just the UDP change was required.

Thanks,

Chris

Do you control the other end of the SIP connection ? If positive, that would help to understand why a UDP reply takes longer than 10 seconds to be received.
On another hand, I thought UDP NAT timeouts would be much longer than 10 seconds (googling on UDP NAT timeout, I got default n Linux is 3 minutes).

My VOIP provider is localphone.

My two SIP clients (Grandstream GXP1630 and Siemens N510) were both unable to connect to localphone, until I made the UDP timeout change.

I made a whole of tests.
Now we are at 7.10.2
I tried changing the udp timeout to 30, but no avail.
sometime works, sometimes no.

I have upgraded yesterday a bunch of rb, with latest 6.49.x . I upgraded them since I wanted to get rid of issues of BGP connections stuck sometimes in "open sent".
After upgrading to v7, in some situations, the voip ceased to work. The timeout went to 0 and so the connection was dropped in conntrack.
I tried enabling the sip helper (never enabled before), the timeout goes to 60min... but the voip is intermittent.
I downgraded, very same firewall config, and it worked flawlessy again.
Till now, I cannot safely upgrade everything to v7, there are some issues that I need to clear, but in 95% of my devices, I dont have issues.

For example:
Hap AC3 with a gigaset ip 690, with v6 works, with v7 dont work.
Another freepbx with v6 works, with v7 dont works... the SIP provider is the same.

Any updates to this? Facing some really strange issues with a client using OnSIP, and I think this might be related. Funny thing is, not all my RBs/clients seem to be affected. This one is RB750Gr3, ROS 7.15.3, fasttrack enabled.

Setting UDP timeout to 120s (per provider's recommendation) seems to have helped. But, I'm seeing multiple/duplicate connection tracks (doesn't seem to be causing issues, though). I may try disabling fasttrack, but only if they continue reporting issues.

My final solution is:
UDP timeout to 30
set a static DHCP lease to ATA device or SIP Phone, set netwatch to ping it every 5 sec.
Issue disappeared. The issue seems to be related to the ARP entries getting removed automatically (since the default lifetime is 30sec).

Hi, I'm very glad you solved the problem, but I and the forum would be so much happier
if you also mark your case in this forum as solved.

See the pictures below.
Where you click on the following places on the thread that solved your problem.

So the AI can take over and know what the problems are with the respective solution.

At board style: Canvas


At board style: prosilver