DELInstallations said:
The QOS doesn't come in an item you control....you don't control the ISP or modem, so you're only modifying what is on your LAN. As you also stated, you don't know what goes on into your ATA. The biggest item is when you take an already digital signal and redigitize it.....a panel (or fax) and send it on VOIP. It's usually the reason why slower speed comms methods work but the higher speed ones do not.
Not quite sure what you mean there. This is probably more than you want to hear, but in case people are curious.
In a typical home setup:
modem <--> router <--> lan/wireless <--> VoIP ATA
For outbound traffic (which is the most speed limited) the modem acts as a funnel, and randomly drops packets if too much data is headed out. With QoS, you are moving the funnel effect back into the router, and can tell the router to selectively drop packets so that the VoIP traffic always had bandwidth, essentially reserving outbound bandwidth for the VoIP traffic, and the modem has no role then to play in traffic management, because (for outbound) it is never saturated.
You can't control what happens after it leaves your modem,of course - the big bad internet carriers can honor or strip the QoS tags from packets (some honor, some strip, some reprioritize to suit themselves).
For inbound traffic, which on most circuits is 5-10x as wide of bandwidth, you really have no control. It's like a reverse funnel -- QoS on your LAN side does pretty much nothing for you, unless you're running inadequate hardware that gamers, video, etc. is saturating purely on the LAN side (and if you're saturating your LAN, not WAN, you really shouldn't be doing anything yourself with networking
)
Now this presumes of course you provided (or at least can program) your router, and know how. It's why Ooma recommends:
modem <--> VoIP ATA <--> router <--> your lan
They built QoS and a simple router function into their ATA so people who don't know how to configure their router can still benefit from the QoS, but if you have a complicated Router setup, this screws you up. But it works well for people who treat the router as plug and play.
Regardless, I agree completely with the more generalized thing you are saying -- VoIP is not a good thing for primary alarm functions.
DELInstallations said:
Alarmrelay, while I don't agree with a lot of their policies and how their SOP's for certain items and signals affect the integrity of the service, the largest item is they are at least a CS and brick/mortar.
I would still not run TCP/IP to them as a primary form of comms. Their SOP's for TCP/IP monitoring leave a lot to be desired.
My basic choices are these:
1) Happy with Uplink, it's been working nicely, it will be primary. So...
2a) Go without secondary,
2b) Limp along with VoIP secondary and NextAlarm using SIA (did some more testing, it was mostly 100%, but doesn't work with their web features at all, and haven't tested through to their CS yet).
2c) Go with NextAlarm's ABN - not going to do that, I don't want another device to fool with and an additional cable to run in the attic.
2d) Switch to AlarmRelay, and use their native M1G monitoring via ethernet device
2e) Keep POTS line and pay the extra $20+/mo -- pass
To me either limping along, or switching to AlarmRelay, seem like it gives a tiny bit of additional protection for no real money or effort. Just trying to decide which.