he distinction between the component and the transaction handlers, the dialogue identifier (dialld) that defines a dialogue in TC user interfaces is called transaction identifier (transld) in the TR-BEGINrequest primitive (it does however not make life easier for the interpreter of the standard). In the TCAP protocol it is called originating transaction identifier (origTransactio- nld) which implies that peer TCAP agents use separate identifiers to refer to the same dialogue. This implies that, in further communication within the same dia- logue, both an origTransld and a destTransld must be included in TCAP messages. Let's now look at how TC users identify each other: Both the TC-BEGINrequest and the TR-BEGINrequest include the parameters destination address (destAddr) and origination address (origAddr). From an AMLn modeling point of view, there is no need to constrain the generation of an origAddr to a parameter of these primi- tives. An alternative method (with some benefits over storing origAddr in the actual TC user) is to store the translation between the actor-agent interface identifier (AAli) and the address of the actual TC user in T-ROa and T-RE tables in the trans- action handler when the TC user is configured to TCAP. Thus the TCAP standard is overspecifying this issue. The origAddr and the destAddr refer to the addressing system of the underlying connectivity service, which in reality is SCCP, although the standard leaves open the possibility of using other connectivity layers and their addressing systems as well. Thus, TCAP does not use any actor layer identifiers (ALi) and actor suffix (As) that are independent of the addressing system of the used connectivity layer. Since the TCAP agent does support multiple actors, this problem had to be solved by introducing an addressing facility in SCCP that includes a parameter for TC user identification. This parameter is the subsystem number (SSN), defined by SCCP (another possibility for identifying TC users is the global title (GT) address- ing mechanism