I had a (brief) look at the packetcable protocol and it appears to be based on SIP but with more security/billing procedures bolted on
also it appears these things operate on "premium" bandwidth away from the main Internet / with guaranteed quality of service (might also explain the wider brouhaha over net neutrality!)
Close. PacketCable is based on MGCP, although there was a push for SIP early on.
Although it would be technically possible to communicate digitally with the box I very much doubt the cable companies are going to permit small customers to connect in such a manner (at least not for a fair few years) as it wouldn't be worth their while dealing with the more complex support and security issues.
Actually, it is not possible to communicate digitally with the TTM (it just isn't designed that way), you would have to bypass it to talk to the DOCSIS network directly, which I don't think is possible given the security involved. The only thing close would be something called a stand-alone MTA, but you would have to build one yourself (I don't know if anyone ever sucessfully made one). As you indirectly observed earlier, PacketCable is intimately tied to DOCSIS...the modem is critical for reserving the bandwidth required, and even PacketCable call servers are involved in dynamically requesting bandwidth on a per-call basis. In addition, the devices must pass extensive sercurity checks involving certificates and KDC servers before they are even allowed to communicate with the call servers.
Although I don't doubt someone might eventually figure out how to defeat the PacketCable security measures and use the network directly, I don't think it will be anytime soon and I would be even be surprised if they did.
The only potential gotcha would be whether these FXS ports provide a CPC signal when the remote party hangs up (to enable the use of kewlstart)...
All our TTMs provide Call Party Control, or what we commonly call Forward Disconnect, so kewlstart should work.