[stuff about tuning algorithm to channel characteristics]
None of this says that you shouldn't also optimize for the packetized case too. I think that you can negotiate the right behavior at start up time based on detected channel characteristics. I think that the biggest impact is in the framing overhead, or lack of it.
You are always trading off bandwidth, speech quality and MIPs.
I agree with this, but it is still possible to do all this through an abstract interface layer. One can "query the line characteristics" of a transmission layer and then limit the selection of algorithms based on those characteristics. Example: we have a class TransmissionLayer, and two derived classes "syncrhonouslayer" and "asynchronouslayer" (subclass as appropriate). Note, no underlying link type is being refered to. It could be a network or a modem. Now we have a bunch of algorithms (codecs), CodecA is optimized for a synchronouslayer with atleast 16kpbs. CodecB for asynchronous packet networks. At the application layer, the user chooses a way of connecting. The application instantly picks the best codec (supported by both ends) for that transmissionlayer. it alo updates the user interface automatically, e.g. displaying a "half duplex" mode for one type of link, or "conference call' for another. Some types might not support all encryption types because of cpu limits (also detected) There's no reason this could not be programmed. It would also be highly portable, highly maintainable, and more easily adoptable. Direct-to-hardware hardwired algorithm software is good for proof of concept. But I'm thinking ahead, to a time when a multimedia protocol will be just another transport layer ontop of which cool applications are running. (like http+mime runs over TCp) -Ray