If the neighbouring domain is not controlled by a Sandman MCA, but by MCA-X, the interoperability proceeds in pretty much the same way. When a connection is set up from an endpoint in Sandman-1 to an endpoint in MCA-X, the sequence of steps is exactly the same as described above, except that now the pseudo-endpoint has to translate the `setup' operation in the appropriate signalling commands for MCA-X. It also has to translate the Sandman address into a MCA-X address. This may or may not be a network service access point (NSAP) address. Apart from this, there is little to distinguish this case from the one above. Connections from MCA-X to Sandman domains may proceed in very much the same way as well, if we stick a similar interface onto the MCA-X signalling that translates MCA-X control messages to their Sandman MCA counterparts.
Connections in the other direction, however, may also be implemented in a different manner. We may take up the position that we cannot expect MCA-X to be aware of the Sandman's operations. In this case, we would like the Sandman domain to appear to MCA-X as just another instantiation of MCA-X. In other words, we would like to allow MCA-X to use its native signalling protocol to communicate with the Sandman while making sure that these signalling messages get delivered to the appropriate interface on the Sandman side (e.g. the pseudo-endpoint mentioned previously). This is not particularly hard to do. For example, many MCAs use a specific vpi-vci value to send their signalling messages. All that is required now is that this vpi-vci has an endpoint in the interface. This is illustrated in Figure . Here, the switch doesn't touch the signalling messages coming in from MCA-X. They are sent to the control gateway without further ado and translated in the corresponding Sandman requests. Note that in this case also, there is need for address translation as the addressing used in MCA-X may (and probably will) differ from the addressing in the Sandman MCA.