 is the parameter that identifies the person. The information that is provided to the FOH will be used by the FOH to create a suitable message for each ASP. Information that is provided to the OPH is used to interpret the corresponding ASP. Thus, the OPH translates local procedure calls into gev and dev operations, and vice versa. The OPH must have access to specifications of all ASPs that are implied by a specific procedure call. Since all three ASPs concern the same operation, all ASPs are collected into a common operation specification (which, in software applica- tions, is compiled and made available to the OPH. Such compiled code is often called stub). In AML syntax, the specification for the operation chAddr of the abstract protocol may look as shown in Fig. 5.24. This form of specification is called symbolic operation specification, since it does not specify how the different information elements that constitute an ASP shall be represented. OPERATION chAddr -operation name PROPERTIES {,synch,,} Request -primitive type (person, AddrPar) AddrPar::=CHOICE{postCode, streetName, streetNumb} Confirm -primitive type (person) Refuse -primitive type (person, cause{noSuchPerson, noSuchPostCode, ...}) TIME CONSTRAINT ACTIVITY TIME 100 ms Fig. 5.24 Symbolic operation specification Considering the information that the OPH must hand over to the FOH, the spec- ification must identify all ASPs within the operation, and the parameters of every ASP. The syntax for operation specifications in AML is defined by the ASN.1 macro notation (see ITU-TX.208). Other functions that may be performed by an OPH are to control operation syn- chronization properties, destructiveness and timing aspects within an abstract pro- tocol (see the headings PROPERTIES, TIME CONSTRAINT and ACTIVITY TIME in the operation specification. Operation properties are described more in detail in Sect. 7.4.5). 5.4 Message Handling Only operation classes that define a response can be synchronous (REQUEST, OFFER, INVITE). A synchronous operation must be respon