Summary

  • RFC 3441's ordered AAL2 profile intersection chose a compatible profile list; it did not, by itself, map every service to an AAL2 profile row.
  • The vsel, dsel and fsel parameters expressed preferred row-to-service bindings. They did not prove which row a live transmitter used, that an ATM bearer was established, or that media reached a caller.

A list of codec names looks like a small matter until two gateways must use it to construct one voice connection. In an AAL2 network, a profile describes rows of packetization and codec information. Call control can offer an ordered profile list; gateways have their own locally supported lists; the common profiles must be found without confusing that set with the service assignment inside one profile.

RFC 3441 addressed that seam by defining an ATM package for the Media Gateway Control Protocol. MGCP let an external call agent control media-gateway endpoints. The package added local connection options for ATM bearer type, adaptation layer, service settings, traffic management and dimensioning, as well as parameters for codec and profile negotiation. The package was Informational, not a universal deployment report: its syntax says what a conforming exchange can represent, not which products implemented it or how many calls used it.

The distinction begins with the profile lists. A gateway's L-list describes profiles it locally supports. The call agent may provide a C-list, ordered by its own preferences. During a two-sided call, the remote descriptor contributes an R-list. RFC 3441 specifies that gateways apply an ordered intersection according to call direction and local policy. A surviving profile is evidence of compatibility within those lists and that policy; it is not yet a bearer circuit, a service, or carried media.

The RFC's example makes the intermediate nature of that result visible. Gateway 1 supports custom 100, itu 3, itu 1, itu 8; its call agent offers itu 8, itu 9, atmf 7, itu 3, itu 1, custom 100. Applying the originating gateway's priority produces itu 8, itu 3, itu 1, custom 100. The result travels to gateway 2 as the remote profile list. Gateway 2 then intersects that list with its local profiles and its own call-agent offer, producing itu 3, itu 1; it selects itu 3. The first gateway's preference for itu 8 did not force the terminating side to use it.

What happens inside itu 3 is a second question. The originator had attached vsel and dsel service bindings to its first profile, itu 8. Those bindings did not describe itu 3, so gateway 2 could not simply carry them over when itu 3 became the selection. It used locally available bindings for that profile and returned its own indications: voice mapped to preferred codec rows, while voiceband data—including fax in that example—mapped to a different set. The profile intersection had not settled the service mapping; the selected profile changed which bindings were relevant.

RFC 3441 names the voice, voiceband-data and fax selectors vsel, dsel and fsel. They are service-to-profile-row preferences, not a contract that a particular row will be used for every packet. The RFC says the AAL2 transmitter may switch among rows on the fly after a profile is bound to a connection. An application may restrict such switching according to the current service state, trading flexibility for simpler behavior, but the preference parameters themselves do not impose that restriction. A profile name therefore cannot be read as a per-packet codec receipt.

The other package fields belong to still different layers. ATM connection type, virtual-circuit identity and path-setup options address the bearer. AAL options describe adaptation. Traffic-management options describe ATM service categories and parameters. Codec selections describe media preferences. MGCP command acceptance, an SDP descriptor, a negotiated profile, a bearer setup response, cells on a virtual circuit, and intelligible sound are not interchangeable observations. The general media-gateway architecture in RFC 2805 and the base control protocol in RFC 3435 explain why the controller, gateway and network each own different parts of this chain. RFC 3108 supplies related SDP descriptions for ATM bearer characteristics, but does not turn profile agreement into proof of transport.

This division is useful precisely because the endpoints do not have one shared decision-maker. The call agent owns its offer and policy. Each gateway owns its locally supported profiles and applicable service bindings. The ATM network owns whether a virtual circuit can be established under its service parameters. The sending gateway owns the actual row used at a moment. A remote descriptor can report negotiated intent; it cannot attest that cells crossed the network or that the receiver reconstructed and played the intended service.

The article's scope is the profile-list and service-row boundary in RFC 3441. It does not claim a current MGCP deployment, vendor behavior, a completed ATM call, codec quality, reserved capacity, user-perceived voice quality or measured interoperability. The specification establishes an exchange model and preference vocabulary. Those records should not be promoted into later receipts without independent evidence.

Sources: RFC 3441; RFC 3435; RFC 2805; RFC 3108; RFC 3054; RFC 3336; RFC 3337. Record pages: RFC Editor; IETF Datatracker.