Rogers 5G Home Internet and Grandstream ATA

Help & Support
1

Hi:

This post is to share what I have found trying to use the Grandstream HT801v2 over the Rogers 5G Home Internet service.

The basic ATA configuration was entered as suggested on the wiki for the HT802v2, initially using SIP/UDP and unencrypted RTP/UDP on a landline (cable) Internet service. This went well, so I updated the configuration to go encrypted, SIP/TLS and SRTP. Again, all worked well and by this time my number had been ported to my VoIP.ms account.

Now it was time to move the ATA to the Rogers 5G Home Internet service. The ATA registered without issue and numbers could be dialed and the phone ring with caller ID. This worked both for inbound and outbound calls, BUT, there was no voice connection in either direction, ever.

I opened a support ticket and got the ā€œscriptā€ response, make sure your firewall ports are open, the ALG is disabled, etc., etc., etc. After weeks of jumping through the helpdesk hoops they gave up and said it was a network provider or ATA manufacturer issue. Little did they know it was both!

I worked with Grandstream for over a week and they failed to find the cause. And after pouring over dozens and dozens of pcap traces from the HT801v2, a softphone client and a Cisco SAP112 ATA the problem came to light. The HT801v2 sends out all RTP packets with the UDP checksum set to zero. Zero is not a typical checksum value. And the technology used in the Rogers 5G Home Internet service requires a checksum or it drops those packets. Iā€™m not sure if itā€™s at the 5G modem or somewhere further in their network. If the VoIP server never sees RTP packets from the ATA then it does not know where to send its RTP packets to, so thatā€™s why voice was broken in two directions.

To prove this was the issue I used iptables to link a Python script that could grab the packet with the zero checksum value, calculate what it should be and update the packet then send it out to the 5G network. This worked! Voice for the calls now passed through the 5G network.

Iā€™ve shared this information with Grandstream and I hope they can update the firmware to correct this problem. Iā€™ve tested firmware versions 1.0.5.7 - 1.0.9.1 and all have this problem.

I hope this helps someone, and Iā€™ll update the post if something changes. For now I have the Cisco ATA on the 5G network.

2

This was a very interesting writeā€‘up. The level of detail you went into with the packet captures and checksum analysis is impressive, and it explains a problem that most people would never think to look for. Iā€™m glad you documented it. This kind of information is incredibly useful and I hope it helps someone. Looking forward to any updates you discover.

3

Is your internet connection (WAN side) assigned an IP address within the 100.64.0.0/10 subnet (100.64.0.0 to 100.127.255.255)? Most North American mobile carriers use this range. If so, your ISP is employing CGNAT (Carrier-Grade NAT), which offers very little transparency regarding port translation, packet drops, security controls or session timeouts.

While SIP is lightweight, it utilizes multiple UDP ports for voice streams (RTP) that are difficult to manage as a single session, especially when you donā€™t control the upstream NAT. I suspect the UDP checksum validation is a security measure within their NAT implementation to prevent DoS attacks or state table overflows; standard routing (no NAT) typically ignores this.

I am impressed by the depth of your analysis and your work at the packet level. Since your current fix is a script to calculate checksums, have you considered switching from UDP to TCP for your SIP signaling? Because TCP is stateful, it generally handles NAT traversal and ā€˜keep-aliveā€™ sessions much better. While it adds a small amount of overhead, VoIP is lightweight enough that the bandwidth impact should be negligible.

4

The IP is a Rogers address range according to whois.

Rogers 5G network is certainly using IP and Port translation as my ATA SIP source port does not match the source port shown on the VoIP.ms portal when the device is registered.
I have also seen in the pcap traces that the RTP/UDP port advertised in the SDP messages passed between the server and ATA when a call is setup is different after passing through the Rogers network. This requires the VoIP server to employ symmetric RTP to reply to the received RTP source IP/port rather than the SDP advertised IP/port.
See: Asterisk SIP and RTP Routing

My SIP connection uses SIP/TLS which uses TCP. SIP was never the problem, only the RTP/UDP with the checksum set to zero.
I noticed my aging Cisco SPA112 has a setting in the RTP section to use UDP checksum or not. Iā€™m not sure why you would want to send your data without a checksum. I canā€™t imagine that on a low power device like an ATA that it adds so much processing overhead that it is best left at zero.
With your packets travelling through the Internet of so many unknown network providers I believe the best option is to enable UDP checksum. You donā€™t want to go through my experience, do you?

5

I agree that checksum is mandatory when passing through an uncontrolled network such as the Internet. Back when the VoIP and UDP protocols were drafted, processing power was a premium so the authors gave the flexibility to the user to enable the checksums only when needed. In some cases, like in my PC, the IP stack/driver always leave the TCP and UDP checksums at zero because the calculation is offloaded to the NIC. In a corporate environment, they can choose to save processing power on the endpoints and have the checksum calculated by the ALG (Application Layer Gateway) or SBC (Session Border Controller). Speaking of ALG, I suspect that Rogers may be using one to ensure that all the VoIP packets are correctly prioritized and not in conflict inside their network. Seeing the UDP port change between the source and destination clearly indicates some kind of NAT (L3/L4) or Gateway (L7) is involved. ALG is usually a good sign because it shows that the Roger cares about voice service quality over their IP network. What is sad for customers like us is that the first level of technical support for consumer-grade internet service do not know anything about it and keep saying that it is ā€œthe customerā€™s faultā€. You end up having to do some reverse engineering like you did to diagnose the problem. 99% of people would not be able or willing to do half of what you did.

Unfortunately, one solution may just be to retire your current Grandstream ATA and buy a new one that calculates UDP checksums natively. It may be a small price to pay to get some peace of mind in terms of stability and simplicity. Even if they acknowledge the problem, companies like Grandstream will not develop any firmware updates for discontinued products but will, most likely, add the feature to their current products.

I also have a problem with a HT802 (first generation) that is unable to reestablish the SIP session when the router (provided by the ISP) that it is connect to resets after a firmware update (triggered by the ISP). The reset causes the etherrnet link to go down and back up, then the ATA is expecting the DHCP server to be available immediately, which is not the case. I known that the second generation (HT802v2) does not have that issue. Grandstream will not fix the first generation. I had two solutions: find a workaround (which I did) or throw the discontinued ATA to the trash and buy a new one. This is unfortunately the world of low cost ā€œdisposableā€ IT devices that we live in. With a 100K$ Enterprise VoIP system, it would probably have been a different story.

6

Rogers 5G network certainly does have an ALG. When I tried the ATA with SIP/TCP and RTP/UDP unencrypted their ALG would change the Contact field and insert IPv6 addresses! VoIP.ms reported back that they could see this change and their service doesnā€™t work over IPv6. Thatā€™s why I switched to encrypted mode, it keeps prying eyes and ALGā€™s out.

1 Like
7

Now that you know that Rogers is definitely altering your RTP packets, and I am sure that no one at the Internet support will ever be able to help you with that (given that they ever know that an ALG is involved in the first place), I wish you good success in finding a durable solution.

Please post your final solution here, even if it is buying a new ATA. It will, at lease, give all the audience a message that would say ā€œDonā€™t even try to get this ATA with this internet service working togetherā€. :grinning_face:

8

Until Grandstream can provide a firmware update which would allow the user to turn on/off RTP/UDP checksum support, Iā€™m using a Cisco SPA112 with the setting ā€œNo UDP Checksumā€ set to no.

9

Grandstream has indicated to me that they will provide a UDP checksum option in a future firmware release, but no timeline was given.