unexpected call from "Asterix"

[stevech]

I wonder why I received a call with a CID/CNAM as Asterix (of server fame)? No recent calls made; no voice mail, etc. Of course, when I went off-hook to talk to Mr. or Ms. Asterisx, there was silence.

After-wards, outgoing calls all got a fast busy; incoming OK.
Power cycled the GS ATA and all seems normal now. (It's on the LAN side of the router.)
Hadn't been fiddling with LAN or router; no ISP service outages or IP address change.

[gls101]

I realize that you started this thread quite a while ago, but I had the same problem, and it's now completely resolved.

Initially, I tried running the Grandstream ATA behind my router, and I had almost continuous problems with call stability. (At least I didn't get any Asterisk calls then, or many others, for that matter!)

I got tired of screwing around with it, and moved the ATA in front of the router. That solved ALL of my stability problems, but then the Asterisk calls began.

I would get as many as three calls in a row, almost always in the middle of the night, with a CID of "asterisk". When I would check the call log, the call wouldn't be listed.

I finally opened a ticket, and tech support explained to me that the calls weren't coming through Voipo's servers - people were actually sweeping random IP addresses looking for unsecured PBXes to make free calls through.

After a couple of tries, Voipo second level support was able to program my ATA so it would respond ONLY to Voipo's servers. It now completely ignores connect attempts from anyone but Voipo. This has worked perfectly for me since then.

I can honestly say that Voipo is now working for me as well as AT&T CallVantage EVER did (and that's saying something).

Gary Sanders

[stevech]

via a trouble ticket, VoIPo did two things to my system:
1) changed my SIP ports to non-standard port numbers. I suppose they noted this in my profile on their servers. And I suppose they won't Forget these someday when they rebuild their servers. My experience with other operators is that they don't retain special settings for customers and more trouble tickets get filed later to effect a re-do.

The impetus for the non-standard port numbers, VoIPo claims, is that bad guys are attacking my Grandstream ATA which is on the LAN side of my router. They're trying to steal service. This does not make sense to me, as I don't port-forward any SIP related ports at all; how could they get to my ATA? I wonder if the tech mis-diagnosed this. If so, the calls were originated by VoIPo's Asterix. Each time the phone rang, and this was quite a few, there's just silence, and no log of the call in VPanel.

2) The tech said my ATA had not been connecting to do provisioning updates for several months. I asked "well, wouldn't your system notice that and tell you to attend to this?". Answer: Hmm, well, no. So my ATA was re-flashed with the firmware du jour and it began to provision again.

Meanwhile the unwanted calls with CNAM = Asterix have stopped.

[voipinit]

via a trouble ticket, VoIPo did two things to my system:
1) changed my SIP ports to non-standard port numbers. I suppose they noted this in my profile on their servers. And I suppose they won't Forget these someday when they rebuild their servers. My experience with other operators is that they don't retain special settings for customers and more trouble tickets get filed later to effect a re-do.

The impetus for the non-standard port numbers, VoIPo claims, is that bad guys are attacking my Grandstream ATA which is on the LAN side of my router. They're trying to steal service. This does not make sense to me, as I don't port-forward any SIP related ports at all; how could they get to my ATA? I wonder if the tech mis-diagnosed this. If so, the calls were originated by VoIPo's Asterix. Each time the phone rang, and this was quite a few, there's just silence, and no log of the call in VPanel.

2) The tech said my ATA had not been connecting to do provisioning updates for several months. I asked "well, wouldn't your system notice that and tell you to attend to this?". Answer: Hmm, well, no. So my ATA was re-flashed with the firmware du jour and it began to provision again.

Meanwhile the unwanted calls with CNAM = Asterix have stopped.

Port forwarding is not required for some routers, they allow voip traffic to pass. If all your ports were closed your ATA would never be able to communicate, so you would not have any service.

The fact that there were no log entries for the call, support the theory that the call was NOT going through VOIPo's network.

Your new ports should be in VOIPo's provisioning profile for your ATA (the ports are stored in the ATA), it is not likely to be lost, but yes it is possible.

[stevech]

Port forwarding is not required for some routers, they allow voip traffic to pass. If all your ports were closed your ATA would never be able to communicate, so you would not have any service.

The only ports forwarded from the WAN to my LAN by my router are 80 (my webserver), VNC and 8080/8081 for webcams.

My router has the following settings that apparently allow the inbound ATA traffic. I've never studied what the Application Layer (Level) Gateway settings do, in terms of IP layer ports.

ALG...
SIP enabled
RTSP: enabled

And other ALG settings that don't seem relevant such as MMS and PPTP among others (which I should probably disable if unused).

I wonder then if the ALG for SIP/RTSP allows non-VoIPo SIP servers to access my ATA on the LAN side? What I don't get is that my VoIP provider should, I'd think, have authentication configured in the ATA so that only their SIP server can connect and ring my phone. Other SIP servers would be violating my and my providers' intent. Isn't SIP based on TCP rather than UDP (RTSP is UDP-like, and used for the bearer traffic after SIP finishes?).

So my understanding is that ALG in the router precludes the need for doing port or port range forwarding ("virtual server" in lay terms of the GUI).

My router is a Cradlepoint MBR900 connected to a cable modem and the router has a USB port with a Verizon LTE modem in it as the fail-over; works quite well.