(12-04-2014 07:24 AM)bnelson Wrote:  Remstar:

Changing to TCP an a non 5060 port has worked for us in stubborn scanner situations. Scanners are generally kinda lazy and don't hit TCP ranges...yet.

I too am having trouble getting sip trust control to work properly. It works great if we only use our registration server's A-record, but using DNS-SRV records for redundancy results in a rejection since the SRV record technically doesn't match the actual name of the server communicating. The A-records are being stored in the local DNS cache, and are provisioned into the cache manuallly.

Anybody had success using this feature? Shuffling ports, and suggesting higher power routers with a decent firewall are not always good options.

(12-04-2014 07:34 AM)bnelson Wrote:  Our service supports using TCP as the SIP transport. Adds some latency, but it can be useful for situations like this, better battery life on mobile, bypassing SIP-ALG on verizon 4G hotspots, etc...

It does use more resources on the server however.

---

Edit: I just tested the "Allow IP Call" = No and I am no longer able to make an unsolicited call to the extension.

Looks like newer firmware versions may have fixed this since I last tried. I will test more, and update here with results. Looks like the sip trust control is not required to kill generic sip vicious scanner calls. A more advanced scann attack might still be able to gather the extension, but I'll cross that bridge when it happens...