onent handling recomponents primitives, e.g., reimporents TC-INVOKErequest( dialld, class, invld, linkedld, opld, primPar, TimeOut) Fig. 6.6 Component handling in TCAP, phase 1 A "component" contains information about an LSM event (an operation identi- fier and a set of primitive parameters), the type of invoke (e.g. TC-INVOKEre- quest), and an invocation identifier. The idea is that the TC user can store a whole set of "components," all belonging to the same dialogue, before sending anything. The TC-INVOKErequest therefore also delivers a dialogue identifier (dialld) for each component. Since TCAP applies the strange ROSE "linked operation" con- cept that we discussed in Sect. 6.2.3, a linked operation identifier (linkedId) is also included in the definition of a "component." The purpose with the class parameter in the TC-INVOKErequest is not explained by the standard. To the author's under- standing, communicating TC users should know to which operation class an opera- tion belongs, and the TCAP layer has no reason to know. This phase is handled by the component handler alone (i.e., it is invisible on the network level), which encodes these data for each components and stores all com- ponents that belong to the same dialogue in a common table for the actual TC user (identified by an actor-agent interface identifier (AAli)). Whenever the TC user is ready for it, he may order the TCAP agent to send all components of a particular dialogue to a named remote TC user. There are several operations defined for that, but let's just look at the TC-BEGINrequest: the primary parameters of this primitive are defined as: dialld, destination address (destAddr) and application-context identifier (applContextld) that refers the actual "application protocol." Another parameter is the origination address (origAddr), to which we will come back later. A TC-BEGINrequest starts phase 2 (see Fig. 6.7). In this phase, the TCAP message is composed for sending (as user-data for the transaction handler). As this model shows, besides encod