There is an open issue with onsip that is covered in ticket WTZ-776-31675
Christina summarized as follows:
"The SPA is doing a DNS query on sip.onsip.com to determine where it should send the response to, after it has received a request from its outbound proxy.
So this is definitely a bug. It should not be doing name resolution when it is generating, or sending a response. This breaks the SIP transaction, as we have seen, because it is entirely possible, and plausible that sip.onsip.com (or any domain) may have changed since the SPA last registered. This is why responses are routed by the Via headers."
The last replies in the ticket from us to Onsip was asking if they would share a account with us for testing. We did not get a response.
In engineering court.
"We have decided to move forward with developing a fix to resolve the
issue with routing SIP responses using the Via header. Currently, we
have a pretty healthy queue of projects. It will take us some time to
allocate resources to develop the fix. I will send you an update when
we have a beta to release.
Would you like us to send a beta to you for testing?
It would be very helpful for CyberData to have a test account with
OnSIP for ongoing interoperability. We're also gearing up to release
new SIP-enabled products and would love to test with OnSIP. Would you
be able to set up a test account for us?"
Noted by Wayne 09/28/2017
Registration fixes to try.
On the SIP tab, the "Keep Alive Interval" is by default set to 10000 ms. That means that every 10 seconds the cuberdata device is going to sent out a keep alive packet to the router/firewall.
There is a possibility that this interval is too short and may be construed as a Denial of Service attack and is shutting the port off periodically.
You can try to change the interval to a longer period like 30000 (30 seconds) or 60000 ( 60 seconds) to see if that helps keep the port open but not trigger a closure, or you could turn off the keep alive completely by changing from 10000 to 0 (zero). Don't forget to save and reboot after making changes.
we had a case with a customer that was using OnSIP with our product and they did not have a DNS "A" record for the outbound proxy server sip.onsip.com set up on their local dns server so lookups were failing. This may be related also to the ticket previously mentioned.
If this is a possible issue, check this by temporarily replacing "sip.onsip.com" in the outbound proxy server box with "126.96.36.199" (don't forget to save and reboot) to keep changes. Note the IP address was obtained by pinging SIP.ONSIP.com. You would not want to keep that IP address there permanently as the background server at the url name may change to a different IP over time.
Network setting considerations:
On the Network setup of the CyberData Devicer, if possible, verify/change the DNS1 and DNS2 ip addresses to the primary and secondary IP addresses of your local Internet service providers DNS servers
Using Google's public DNS servers (188.8.131.52 and 184.108.40.206) can cause enough time delays on invites and registration that could affect the status of the device.
If you have a SBC, you might also try checking the box for "Disable Rport Discovery" so the device does not try sending responses directly to the WAN server, but goes thru the proxy server.