I’ve been having problems with the Canadian clustered server. I was using Zoiper and when I switched to ca.voip.ms I was unable to make outbound calls. The reason was I was using a verified caller ID, and it was trying to add a 1 in front of it. So instead of 9025554321 it was trying to pass 19025554321 as my caller ID. The problem was the system was recognizing it as different because of the additional digit at the front. So the system would decline the call and send me an email saying I wasn’t using a verified caller ID number.
I figured out I was able to add the additional digit and verify the number again. And after I selected it as my outbound caller ID I was finally able to make outbound calls on zoiper.
However, I’m experimenting with different soft phones and I decided to try ground wire. When I use the Canadian clustered server I am completely unable to make outbound calls no matter what. I tried playing with some settings but nothing was working.
But after switching everything over to the Montreal1 server everything works perfectly.
I’m really excited for the new clustered server and the benefit that it could potentially bring. Better clarity and reliability sounds like a really good deal. But so far I’ve had nothing but problems with the new architecture, and I’m wondering if anybody else has tried it out or has any thoughts they would like to add.
I was beta testing on the cluster server and had problems, too. I tried all kinds of troubleshooting tricks to no avail. I had a great exchange with tech support to try more troubleshooting but even after that I kept running into inconsistencies in completing calls. After hours of trying I finally gave up.
I them moved the DIDs I was using - with the exact same settings I had on the cluster server - to Chicago1 and it works perfectly.
Like you, I am excited for the clustered server for the reliability it will potentially provide. There’s some issue with the implementation or perhaps they need to create a step by step setup guide (if, for some reason, the setup is different than what we do with the many deployed servers). It just needs more time for them to figure out the nagging issues that cause the inconsistency you describe and i experienced.
I have faith in Ray and the team. It will get there and the service will be even better for their efforts on this project.
We sincerely value the feedback and information provided concerning any issues encountered within our service. In reference to your mention of Groundwire experiencing difficulties with the new CA server, could you please provide us with further details regarding this matter? Specifically, we would like to know if the issues pertain to incoming calls, outgoing calls, or the echo test.
In line with the aforementioned feedback, if there are any specific issues that are not functioning as intended, I kindly request that you provide me with all relevant details. This will enable me to communicate effectively with our team. Our objective is to deliver the highest quality and most consistent service possible, and your reports are invaluable in achieving this goal. Thank you for your cooperation.
Hi William, with Groundwire connected to ca.voip.ms, inbound calls seemed to be working, but outbound calls would not connect. When making outbound calls, Groundwire displayed the message ‘Busy’ and terminated the call. I did not perform an echo test (4443)
With Zoiper, inbound and outbound calls were working. But I had to verify and use a phone number with country code added (+1) in order to enable outbound calls.
Thank you for your prompt response. If you have any screenshots available, it would be greatly appreciated if you could upload them to the thread. This would be a beneficial addition to our discussion.
I have tested ca.voip.ms too using our Yealink T31P phone, Grandstream DP750, Groundwire app on Android and also iOS.
Not on one device I can make calls or receive calls.
I also switched to ca.voip.ms. I can make and receive calls, but when a call is received, it takes a very long time (more than 10s?) before I can actually talk to the caller. Happens on two different phones/numbers, both with Groundwire. Once the call is working, it is fine, and latency is low. I’m planning to revert to a montreal server, like I had it configured before.
Just to add my experience with ca.voip.ms. I am in the process of setting things up. My Grandstream HT802 connects fine via TLS/SRTP and inbound/outbound calls work fine. I setup a few subaccounts for PC and Android and installed the Linphone app. Initially, both worked fine with TLS/SRTP, but today my Android phone would just produce static on any call. Registration was still OK. Checking the media stats, it appeared that SRTP was not being used on the call, despite being properly configured on both the voip.ms and Linphone app side. Reverting to UDP worked fine.
I tried the Zoiper app, and it worked fine with TLS/SRTP. Very strange.
In the end, I’ve switched over to toronto8.voip.ms and all is working fine via TLS/SRTP for all clients.
UPDATE!! Hey guys, I just made a major discovery in this problem. I got ca.voip.ms working great with Groundwire. Initial testing confirms it’s working, but I’ll need extended time with it to make sure it’s reliable.
Here’s what I did: I went into Groundwire Settings > Accounts > (picked my ca.voip.ms account) > Advanced Settings > Scroll down to ‘Caller ID’ and entered the verified CallerID number from my VoIP.ms account settings > Save
It now seems to work as expected, which is a huge improvement. However, there is one small caveat I’ve noticed: When placing an outbound call, the call recipient will only see your phone number, and not your ‘Display Name’ from the Groundwire settings. I think this is quite a bummer as I love being able to have my name display when calling others.
I have also tried entering my name in the Caller ID field on Groundwire, and it also makes the software function normally. Unfortunately, my name is still not visible to call recipients. It only shows the number.
I would also like to mention that outbound calls sometimes take a few seconds to connect, and I am pretty sure I’m unable to hear an outbound ringing sound when making outbound calls.
Please let me know if this helps, and if anyone has anything to add I’ve love to hear what you have to say!!
I have another update in regards to the ca.voip.ms server. It seems like outbound calls are being routed to the Value tier ($0.0052/min) when I have settings configured for Premium tier ($0.009/min). This may explain why the outgoing Caller ID Name is sometimes not displayed.
I tried an echo test (4443) today and it still doesn’t work. I saved my SIP logs and sent it to Gemini, here’s what Gemini said:
Based on the SIP log you provided, here is an analysis of why your call to the echo test (4443) on ca.voip.ms is failing to connect.
Summary of the Issue
The log shows that your Groundwire application successfully sends a call request (INVITE) to the ca.voip.ms server. The server acknowledges receiving this request by sending back a SIP/2.0 100 trying response. However, after that initial acknowledgment, the server never sends any further updates. The call simply sits in a “trying” state for approximately 45 seconds until you manually end it, which then sends a CANCEL message to the server.
In a normal call flow, after the 100 Trying message, the server should send another response, such as 180 Ringing or 200 OK, to establish the call.[1][2] The absence of these messages is the primary reason the call does not connect.
Detailed Log Analysis
Call Initiation (INVITE): At 14:01:54.771, your device sends an INVITE request to sip:4443@ca.voip.ms. This is the correct start to a call.
Server Acknowledgment (100 Trying): At 14:02:55.067, the server correctly responds with SIP/2.0 100 trying. This confirms that your request reached the voip.ms server and it has started processing it.[3]
No Further Response: For the next 45 seconds, the log shows no further SIP responses from the server regarding your call attempt. The connection remains pending.
Call Cancellation (CANCEL): At 14:03:39.985, you hang up the call from your device. Groundwire then sends a CANCEL request to the server to terminate the pending call attempt.
Cancellation Acknowledged (200 canceling): At 14:03:40.426, the server acknowledges your CANCEL request, and the call attempt is officially terminated.
Potential Causes and Troubleshooting Steps
The issue lies with the voip.ms server not processing the call after its initial acknowledgment. Here are the most likely causes and steps you can take to resolve the issue:
Server-Side Issue: The problem may be on the provider’s end. The specific server node (ca.voip.ms) you are connected to might be experiencing issues or may have a problem routing the echo test call.
Action: Contact VoIP.ms support and provide them with the Call-ID from your log: 7FE0A69AEDADA6A1260F461B1FD057B108511CD5. They can use this unique identifier to check their server logs and determine exactly why the call was not processed.
Transport Protocol Issue: Your log indicates you are using TLS for SIP transport (Via: SIP/2.0/TLS). While secure, TLS can sometimes be problematic with certain network firewalls or routers.
Action: In your Groundwire account settings for VoIP.ms, navigate to “Advanced Settings” and change the “Transport Protocol” from TLS (sip) to TCP or UDP. Then, try the echo test call again. If it works, it suggests an issue with how your network is handling TLS traffic.
NAT Traversal Problems: Although the initial request is getting through, there could be a Network Address Translation (NAT) issue preventing the subsequent responses from the server from finding their way back to your device.
Action: In Groundwire’s advanced account settings, look for STUN settings. Ensure STUN is enabled. You can try different STUN servers, but the default stun.acrobits.cz is generally reliable. Trying a different transport protocol (like TCP) as mentioned above is also a good way to troubleshoot NAT issues.
The log does not indicate a problem with your device, Groundwire’s configuration, codecs, or your local network setup. The evidence points to the server failing to process the call after receiving it. Contacting your provider with the specific Call-ID is the most direct path to a resolution.