To answer your question: it is possible to run a SIP trunk under your circumstances because your circumstances are no different than those of any other cable subscriber.
DOCSIS is a Layer 1 & 2 protocol, while SIP trunks essentially operate over IP & UDP which are Layer 3 protocols. I don't think it helps to mix them.
With most SIP trunking providers, when the PBX on your LAN registers with the SBC, the SBC uses NAT punching techniques to find the right private IP, if there is a NAT to cross.
Your deployment concerns are going to be:
- Making sure your router doesn't interfere with SIP traffic (disable SIP ALGs - most implementations break SIP)
- Hoping that your ISP doesn't traffic shape SIP
- Checking that your connection to the SBC is solid enough (<30ms RTT, <1% packet loss, <10ms jitter)
Since you are concerned about QOS - this is something that is simply not possible with packets over the internet. Many SIP trunking providers will sell a managed service product that comes with private data T1 connectivity to their backbone - so essentially they're taking & owning the QOS problem.
Now, I've been told that routers with inbound QoS policies are capable of leveraging the TCP congestion avoidance mechanism by dropping ACKs in order to rate-shape inbound traffic. I've never seen this done in practice, or at least never seen it work; is this a real thing? If so, is it effective? Wouldn't it result in a run of dropped packets every time that a new connection ramped up to speed, before the congestion algorithm could start slowing things down?
I doubt it, certainly for queues as these are relatively TCP friendly anway. Some routers might have tried this strategy to build tcp-friendly policers but I doubt this would be a decent solution. First of all, an ACK can be accompanied by data so you can't really only drop 'ACK's. Secondly, even if that is true for some streams, why would you drop only on the return path? For the TCP stream it's just as good to simply drop the original data and that way you don't waste bandwidth and processing resources between your edge router and receiver.
More likely is to have H-QoS, with a 30Mbps queue/scheduler on the circuit/user level and then multiple smaller-tier queues feeding into that. A simple setup could be to let both TCP and UDP feed into two different 25Mbps queues, so TCP can still leave 5Mbps for UDP and vice versa. Of course more complex variations exist.
Also, consider that ssthresh is usually adapted fairly quick towards your available bandwidth (here 30Mbps - your voice BW). While TCP does not stop increasing cwnd at ssthresh, it will only increase slowly afterwards and disturbing your voice stream only slightly when congestion is reached. However, at the start of the TCP connection, before ssthresh is adapted to a realistic value this will probably significantly disturb your voice flow (albeit shortly). Finally, while it might work okay with only a few TCP streams, when somebody starts 100s of TCP connections (e.g. P2P app) it gets more difficult. It's unlikely that all ssthresh and cwnd values stabilize (quickly) to guarantee fairness, even more if those connections are quite volatile (as is often the case with P2P).
Also, next to drops notice that a saturated connection also has a negative impact on your jitter, this might sometimes be just as problematic (or even worse) than a few packet drops.
In addition to that, however, what if the traffic utilizing the circuit is largely UDP? If a request for a large amount of UDP data is sent to a server, it's naturally going to send the data as quickly as feasible, flood the queue and cause dropped voice packets - but maybe I'm overreacting to that scenario. Is UDP used for any high-throughput internet technologies these days?
You're 100% correct, UDP has no fairness built-in. Many real-time multimedia applications (voip, video conferencing, ...) still use UDP. Tunnels (e.g. for VPN) also usually use UDP to avoid TCP-in-TCP retransmit timer conflicts. So yes, you certainly can have quite some high-throughput UDP traffic on a connection.
More specifically, have you ever personally seen a QoS method that let VoIP work without constant quality problems on a frequently-saturated internet connection without ISP-provided QoS? Have you ever heard of a DSL or cable provider implementing edge router QoS for an application like this? I've only ever heard of that offered as part of MPLS products, is that pretty much a necessity if someone wants downstream QoS?
Well, here the question is of course if many modern internet connections are frequently saturated. In my experience the available BW for a fixed connection often exceeds the average usage. There are always exceptions but usually the bulk of the people have loads of BW, it might still get saturated somewhere, but not that often on your direct access circuit. However, you might encounter it more often in mobile access as this is a relatively low-bandwidth low-reliability shared medium. Currently 4G helps a lot but that will only last this long as mobile BW usage is still growing heavily.
Yes, I have heard providers implementing QoS for multimedia applications. For which applications that might differ a lot from provider to provider. Assume they just qualify traffic as BE unless there is a good reason to do otherwise. But some might indifferently prioritize SIP/RTP.
MPLS is certainly not a necessity for QoS, any decent BNG today also includes quite significant QoS options.
Best Answer
VoIP over the public Internet can be a problem, but it usually works good enough, most of the time, although there can be times where it sucks. Most ISPs have extra cost features where they will honor some of your QoS markings and policies.
(I know Verizon Business, among others, has some specific packages for QoS, and you may need to adjust your policies and markings sent to it to match one of its packages. We have a problem where we use multiple ISPs, and the QoS packages don't match between them, so we need to fine tune for the particular ISP, or pick a close enough package.)
The problem arises when the traffic must pass through other ISPs. You have no control over what happens in that case. The larger ISPs will have better (possibly direct) connections to many VoIP providers, as the VoIP providers will try to directly connect to the large ISPs or a Tier 1 ISP that directly connects to the large ISPs.
There may also be a possibility of having a VoIP provider, especially a telco like AT&T or Verizon, connect SIP trunks directly into your data center(s).
The big monkey wrench in the works today is the requirement for E911. You, and the VoIP provider, will need to maintain a database of where each phone is connected so that emergency services will get not only the address of a 911 call, but the floor and section of the floor. (We have spent large sums of money to meet the E911 requirements.) While this requirement is not necessarily in every state today, it is being phased in for all the states, and it is not something you can ignore if you don't yet have the requirement (it is far easier to put it in place as you roll out VoIP than it is to try to retrofit it at a later time).