The repertoire of HDLC encapsulations that CM DSLAMs can serve out on SDSL and IDSL circuits depends very strongly on the networking model used on the DSLAM side — see this page for the explanation.

NOTE: This page describes HDLC encapsulations seen by the user. The black magic of setting EncapsulationType on the DSLAM is described on this other page.

Cross-connect netmodel

The repertoire of encapsulations available with the cross-connect netmodel is essentially unlimited and is determined not by the DSLAM, but by whatever is on the upstream end of the ATM or FR PVC running through the Layer 2 backhaul network. CM breaks the cross-connect netmodel down into two submodes:

In the per-VC forwarding mode (more common) the DSLAM imposes a Q.922 header structure on the HDLC frames going over the SDSL bit pipe, but not much else. The Q.922 header structure allows the DSLAM to distinguish between multiple virtual circuits going over the same SDSL link, and the DSLAM is smart enough to cross-connect them independent of each other. With ATM backhaul (most common) each virtual circuit cross-connected in this manner can be either forwarded transparently (without regard to any encapsulation past the Q.922 header) or translated per FRF.8. (FRF.5 is also supported.) With FR backhaul the per-VC forwarding functionality reduces to a standard Frame Relay switch.
In the per-port forwarding mode absolutely any HDLC-based encapsulation can be served out on the line: the DSLAM takes the full frame payload between the opening flag and the FCS and forwards it transparently between the SDSL port and the backhaul PVC. For example, this mode can be used to serve out straight PPP (RFC 1662) or Cisco HDLC.
The DSLAM also provides an option to serve out straight PPP (RFC 1662) while translating it to PPPoFR (RFC 1973) or PPPoA (RFC 2364) on the backhaul PVC side.

Canonical routed circuit configuration

The canonical way to serve out a routed SDSL circuit is as follows:

The Redback router serves out an ATM PVC with a routed RFC 1483 encapsulation.
That ATM PVC is brought to the DSLAM in the cross-connect netmodel.
The SDSL port is configured with NetModel=Cross-Connect and EncapsulationType=Q922-1490.
A cmSubIfaceTable entry is created to cross-connect DLCI 16 to the backhaul ATM PVC.
The DSLAM will do FRF.8 translation from ATM RFC 1483 to FR RFC 1490 when configured in this manner and the user will see the standard routed RFC 1490 encapsulation on DLCI 16.

Internally terminated bridged circuits

Bridged SDSL circuits served out with the IP, VWAN, CopperVPN and HDIA netmodels are terminated internally by the DSLAM, hence the DSLAM controls the encapsulation used on the line. (As explained here, the DSLAM is too dumb to serve out a routed DSL circuit with the IP netmodel, hence this section focuses on bridged circuits.)

The CopperEdge supports two different HDLC encapsulations on internally terminated bridged circuits:

Standards-based option: setting EncapsulationType=rfc1490 yields a standard RFC 1490 bridged encapsulation on DLCI 16, exactly the same as bridged DSL circuits from other DSLAM brands that use HDLC such as Covad IDSL.
CM's preferred proprietary option: they call it RFC 1483 (EncapsulationType=rfc1483), but such labeling is disingenious because IETF RFC 1483 does not constitute a sufficient description to an uninitiated learner of what CM serves out on the line. Instead we call it CM 1483 and have a separate page with a detailed description.

It is a great mystery why CM had invented their proprietary 1483 encapsulation when using RFC 1490 is the obvious natural choice and an option they had (or wanted) to support anyway. Perhaps we'll never know. But CM 1483 is the required configuration for CopperRocket bridges and Netopia R7100 routers operating in the router behind a bridge mode — those mainstream CPE devices don't support bridged RFC 1490.

Given the availability of CopperRockets on the surplus market and the economic insensibility of replacing it with hardware that would need to be made new at much greater cost, the question of connectivity to bridged CM SDSL circuits becomes of real interest only when one is dealing with an IMUX bundle.

Internally terminated routed circuits

Unless some improvements have been made in a newer version of the DSLAM software that we don't know about, internally terminated routed circuits (not cross-connect) can only be served out in the following two configurations, neither of which is practically useful:

With DSLAM software versions earlier than 7.0, an internally-terminated routed circuit can only be served out on the special voice VC in the HDIA netmodel.
DSLAM software version 7.0 has the new CopperVPN netmodel which apparently offers the choice of MAC or IP encapsulation.

See this page for the full gory details about various netmodels.

When the DSLAM is able to serve out an internally terminated routed circuit (under the special conditions listed above), it appears to be standard RFC 1490, but we have no way to test it because the required configuration is so funky.