Voip.ms Debugging Random Registration Issues

[Kimball]

I’m new to VoIP, setting up my first system for my small business. Transitioning off of a traditional POTS system. While I am new to VoIP in general and FreePBX in particular, I am a software engineer and feel pretty at-home learning all the configurations, tools etc for everything.

I think I have a pretty good handle on how things should be set up. Here is where I am in the process:
Purchased a bunch of Clearly IP phones for the office. They are on people’s desks next to old pots phones. Set up FreePBX on a dedicated server also purchased from ClearlyIP, following the YouTube guides from Crosstalk. All the phones on desks are working fine with FreePBX - we can call each other’s extensions, leave voice mails, conference calls, park calls, etc.

I also set up a trunk with voip.ms, again following the guides from Crosstalk as well as the wiki on voip.ms. MOST of the time everything works just great. We can make outbound calls. We can receive inbound calls. I’ve set up ring groups. I’ve got on-demand call recording set up that emails to the owner of the extension as soon as the call terminates. Everything is more or less perfect, and we are ready for our main phone number to port… EXCEPT: seemingly randomly, multiple times a day, I’ll pick up my new VoIP phone to place a test call to my cell phone and I’ll get the “That number has not yet been registered” message. If I also immediately use my cell phone to call one of the DIDs I have at voip.ms, I’ll get a “call failed” message on my phone after it tries for like 30 seconds.

If I simply wait 30 seconds to a minute, and try either an incoming or outgoing call again, everything works fine.

Seems to me like an issue with voip.ms, so I reached out to their support, and explained everything. They insist that the problem is with the INVITE format with my SIP sessions, and that I have to follow the following format:

From: "CallerID name" callerID number < sip:[sipaccount]@[server].voip.ms >
To: < sip:[Number]@[server].voip.ms >
Contact: < sip:[sipaccount]@[your_IP]:SIPport;transport=UDP >

In using sngrep to inspect my SIP traffic, I see though that on successful calls that format is never used, and instead there is a challenge/response sort of back and forth where FreePBX initially sends an INVITE which is met with a 401 UNAUTHORIZED, which FreePBX responds with ACK, then a fresh INVITE that includes and Authorization: header. The response from voip.ms is then 100 Trying, then the session starts up.

My FROM: format looks like this:

From: "COMPANY NAME" <sip:[my cid redacted]@[ip redacted]>;tag=[uuid redacted]

I have not yet used sngrep to inspect a failed call (just learned about sngrep this am, and have been periodically trying calls all am - but of course it has not failed yet).

I assume that my registration with voip.ms is dropping, but when a call fails the voip.ms user portal says my FreePBX box is currently registered (there could just be lag there, though - it’s not super-real-time), and if I grab trunk status from asterisk it always shows something like:

Endpoint:  VOIP.ms                                              Not in use    0 of inf
    OutAuth:  VOIP.ms/[username redacted]
        Aor:  VOIP.ms                                            0
      Contact:  VOIP.ms/sip:[username redacted]@seattle3.voip.m d56ce2f3c4 Avail        13.893
  Transport:  0.0.0.0-udp               udp      3     96  0.0.0.0:5060
   Identify:  VOIP.ms/VOIP.ms
        Match: 208.100.60.44/32

So I have a few questions:

1. Is voip.ms support nuts? Are they trying to get me to configure things for the older chan/SIP, rather than PJSIP?
2. I’ve seen several older forum posts where people report exactly the same behavior, and simply changing to a different endpoint at voip.ms seems to have solved the problem… but did it really? Or did those forum topics just auto-close when people gave up trying to solve the actual problem? I really like that 13ms ping time to the current endpoint, and would like to stay geographically close to me.
3. Does anyone here have good experience with voip.ms? Should I be looking for a different trunk provider? Their support has been… less than stellar. I’ve been back and forth with them more than a dozen times since Thursday, (nearly a week now) and they insist that FreePBX is only for advanced users and they don’t really offer “advanced support”. trigger eye roll

Thanks!

[lgaetz (Lorne Gaetz)]

When in comes to trunk SIP registration, is generally not connected in any way to outbound calls. So outbound call failure while the trunk is successfully registered is certainly possible. The registration action is the mechanism by which the provider knows to send calls to your PBX.

Ideally you will see the actual signaling packets during one of these failed calls, but there may be enough info in the call trace to indicate what is going on. You can isolate a call trace from the full log using the technique here, and if you wish to have help interpreting it, you can share via pastebin.

In case you’re not already aware, voip.ms went thru a very prolonged, very painful period of DDOS disruption a few months ago. I would expect things to be working perfectly now, but it’s possible there are still brief disruptions.

edit - grep the asterisk full log for case insensitive occurrences of lagged, reachable and unreachable on your voip.ms endpoint(s).

[Kimball]

Thanks @lgaetz - I’ve set up a tail on /var/log/asterisk/full grepping for all the voip.ms interactions. Hopefully something interesting pops up. Looks like so far today there have been no issues. If I can capture something interesting I’ll pastebin it here.

I did read about the problems with voip.ms, and they definitely do appear to be a tiny company…but the price is right, and unless we have prolonged problems with them, we’re willing to go with a smaller player. Our phones are just one of multiple paths we have set up for customer interaction (we are not running a call center or anything) and we only really need a single DID. Our current phone system only has 3 lines, and I don’t recall the last time I ever saw all 3 lines in use. In short: we’re also a tiny company, with tiny phone needs.

[Kimball]

Ok, I have an update. I was able to capture the asterisk full log for both a failed and a successful call. I also had sngrep up for both calls, and have screenshots of the call flows. Based on what I see, for BOTH calls everything from my FreePBX install looks correct (identical, in fact). The difference is the response I’m getting from voip.ms to the initial INVITE to start the call.

Here are pastebins for the calls.
First, the failed call: [2021-12-07 16:03:27] VERBOSE[5241] netsock2.c: Using SIP RTP Audio TOS bits 184 - Pastebin.com
Second, the successful call: [2021-12-07 16:17:51] VERBOSE[5241] netsock2.c: Using SIP RTP Audio TOS bits 184 - Pastebin.com

Here are screenshots of sngrep for both calls…

Failed:

Success:

Are there other logs I should inspect to see if there is anything else I can learn? Can I point the finger firmly at voip.ms? Should I simply try different endpoints (i.e., maybe the Seattle servers are borked, and I should try somewhere else?)

Thanks!

[david55]

The only reason that the logs look different is that the provider has answered without trying to forward the call in the failed case. It has answered and then done an in band announcement, which some might like, but is wrong to me, especially for a PABX, as you can’t easily mechanically detect the failure and reason, and, if you are reselling, might charge your users for a failed call.

They are not telling you why they failed the call.

[Kimball]

Thanks @david55 - so when I contacted their support they said the issue was that my FreePBX was not formatting the From: header correctly when placing a call. I think we can call that utter malarkey at this point.

[dicko]

Hard to diagnose as you blanked out the From: header

[Kimball]

Hi @dicko,

I only blanked out the bits that are directly identifiable. If you look at my original post, my From header (in both success and failed calls) is in this format:

From: “COMPANY NAME” <sip:[my cid redacted]@[ip redacted]>;tag=[uuid]

The header for both working and failed calls is identical.

[david55]

Their suggested format would be a significant abuse of SIP protocol and potentially difficult to achieve with some clients. It is actually syntactically invalid, as you are only allowed one quoted string, and it is an alternative to a token sequence, not something your can mix and match with it.

It is possible that they have multiple SIP instances and some of them require From user to be the account ID, and some are able to use other information to identify the billable user. A lot of ITSPs require the From user to be the account name.