@AmirSP I run a VOIP ATA as well, but, the modem runs in Bridge mode with a router behind it. So far, I haven't noticed any problems.
Fwiw, have a look at the following post and see if any of the modem settings are applicable to your modem. You might have to change settings to get the ATA working again. I'm assuming that the modem is running in its default Gateway mode.
Re: Some services (apps) are not working after swi... - Rogers Community
Ok, if the VOIP provider indicates that all of their Rogers customers have the same problem, then that's on Rogers. Only solution on the Rogers side of this is to talk with the product manager, whom ever that might be. I would bet that the product manager wouldn't have any idea of what has been changed.
There is also the chance that this is a Comcast issue as all of this equipment is Comcast equipment. I'll have to look around later tonight to see if anything like this has come up.
Are you running encrypted communications between the VOIP provider and the ATA? Voip.ms allows this. But, you have to set this up on the VOIP account setting and on the ATA settings. When its up and running you should see an encrypted comms indication on the voip account. If your not using encrypted comms, but its allowed, I'd set that up to see if it makes any difference.
@CommunityHelps this is a case that should be forwarded to the XBx product manager or to the Ignite Systems product manager if one person handles everything.
Neither Rogers nor Comcast publish changelogs when they make software changes or configuration changes when they push out updates, at least not publicly. (Changelogs do exist but not all support techs have access to them.). I don't know whether or not @CommunityHelps can assist you with this or shed any details as to why the Ignite Gateway is handling VoIP traffic differently.
Support for passing VoIP traffic on consumer firewalls is often problematic. It may work fine for a while, get broken by a software update, or may work if you have only one SIP client behind the firewall but break horribly with multiple clients. The problem stems from VoIP protocols and NAT not playing nicely with one another. When things break, your VoIP ATA may lose registration, may not ring when you have an incoming call, or calls could suddenly drop.
Some routers try to fix the problem by giving you a configuration option to either enable or disable SIP ALG or SIP Application-level Gateway (Google it). However, this is typically implemented as a magical "black box", with no configuration options, so enabling SIP ALG often causes more problems than it fixes.
To be honest, I really don't know what Rogers (or Comcast) do (or do not do) to try to make the Ignite Gateway play nicely with SIP clients. Rogers and Comcast would rather have you subscribe to their Home Phone service rather than a 3rd-party VoIP provider. However, it is also in Rogers' best interests to do whatever they can to make Wi-Fi calling work for their mobile customers. Me? I always found the Ignite Gateways to sometimes work when it comes to passing VoIP traffic... but usually not.
As for what does work, you can put your Ignite Gateway into Bridge Mode and use a router running OpenWrt. Its default NAT and Firewall configuration allow my VoIP ATA to maintain its registration, accept incoming calls, and I have never had a call drop. The "downside" is that OpenWrt's firewall is more permissive, by design, to allow as many applications as possible to work "out of the box", but this is typical of consumer routers that need to cater to non-experts.
Another option, that I currently use, that works exceptionally well is pfSense. Beware that pfSense does allow SIP traffic to pass in its default configuration, nor are there any "wizards" in the UI to make configuration easy. However, it does provide you with full control over how Outbound NAT works and how the firewall manages connections and state tables. You also need to configure your own firewall rulesets to allow inbound and outbound VoIP (SIP) traffic to pass, and you might need to configure the firewall differently depending on whether your VoIP provider compensates for NAT issues or whether you need to make accommodations yourself.
Another way for pfSense to pass SIP traffic is to configure siproxd. The actual configuration has more options than what you may think looking at the help page, but it does work well and allows you to implement a fairly tight security policy.
@Datalink wrote:
Are you running encrypted communications between the VOIP provider and the ATA? Voip.ms allows this. But, you have to set this up on the VOIP account setting and on the ATA settings. When its up and running you should see an encrypted comms indication on the voip account. If your not using encrypted comms, but its allowed, I'd set that up to see if it makes any difference.
+1 for this. It involves enabling and configuring SIP-TLS (SIP Transport Layer Security) and SRTP (Secure Real-Time Transport Protocol), which protects signalling traffic between your VoIP ATA and VoIP provider and your actual voice traffic. Also, when you use TCP as your transport protocol, your VoIP ATA will send regular "keep-alive" traffic, which should prevent the NAT connections on Ignite Gateway's firewall from timing out.
@AmirSP fwiw, I'm running a Grandstream ATA as well. Our XB7 is running in Bridge mode with an Asus router behind it. The router WAN MTU is set to 1500. That MTU size for Rogers hasn't changed for, forever, as far as I know. If the ATA isn't registering, I'd wonder about the SIP/ALG setting. I don't believe that the XBx modems have a SIP/ALG enable/disable setting, so that might be a setting that only tech support might have access to, if they can find it. I wonder if that setting has changed for your account for some reason? The SIP/ALG setting should be disabled, so that the voip server can communicate with the ATA, using the voip company's signaling protocol. The SIP/ALG, when enabled will intercept the signal from the voip company and use the modem's protocol instead, hence the requirement to disable that setting.
Edit 1: Are you using encrypted or unencrypted ports between the voip server and the ATA. Each one will use different ports. I'm wondering if the modem security setting has changed to a higher security setting which might result in blocking the port that the ATA is using to communicate with the voip server??
@AmirSP This same sort of thing happened to me as well, with my ATA SIP client in a default configuration. The Ignite Gateway's debugging capabilities are virtually non-existent -- there is no way to even view which NAT translations are currently active -- but I suspect that the UDP NAT translation simply timed out and got torn down, after which, the ATA lost registration.
@AmirSP wrote:
That is the only thing that makes sense here but what would be the solution ? To be clear this started like a month ago when I posted this topic and still exists and only on Rogers Ignite modems.
So what setting should I change on the Modem to fix this ?
Well, that's the frustrating thing; the Ignite gateways do not provide any advanced configuration options that give you any control over how NAT works, no debugging tools, nor do they publish any changelogs. Comcast can push out updates that fundamentally change how the gateway operates, you have no idea what changed other than an application suddenly broke, and then they blame you for that breakage. That's insane.
SIP not playing nicely with NAT is a well-known problem. The IETF pubished RFC 6314 , which spells out a lot of these issues and offers some strategies and best practices to overcome NAT traversal issues. However, when the SIP client, SIP server and Firewall each do what they think is best to fix the problem, all you get are more problems.
My solution is to run my Ignite Gateway in Bridge Mode and use my own firewall. Out of the box, my firewall will not allow SIP to work at all; I get it to work by implementing very specific changes. I have some control over how my SIP ATA works and can configure it however I please (although I abide by configuration guidelines provided by the VoIP service), I have some control over how my VoIP service works, and I have full control over how my firewall works. My current configuration is as secure and as stable as it can be.
@AmirSP wrote:
I did a PCAP and I can see that server responses are not getting delivered to the ATA.
Rogers Modem stops delivering the Notify Response from Server after a while , like the connection expires or something and there is nothing we can do about it. This is Rogers problem and they should fix it !.
Could please log into your gateway with a web browser and confirm which Model of Ignite gateway that you have (under Gateway > Hardware > System Hardware) and the Software Image Name that you are running (under Gateway > Software)?
Also which VoIP service and which VoIP ATA are you using? Did your VoIP ATA receive any software updates before it started losing registration?
I would also send a message to @CommunityHelps and ask them to check the changelogs for any updates that got pushed out to your gateway since the beginning of March (or whenever you started experiencing difficulties with your VoIP service) to see what could have broken your VoIP connectivity.
-
2889 views
-
0 Likes
-
-
