sponding PDU and finds that the userData is for the ASH. 9. The SDU is received over x0. 10. The ASH the PDU and finds that the remote logical node accepts the associa- tion. The ASH now selects an idle(local) AEid value (here x1), and informs the discriminator to send whatever comes over x1 to the given destSAPI, using the Aid value ai1 in the discrimination protocol message. 11. Finally, the ASH confirms the association to the SE by delivering the associa- tion endpoint value x1. A similar scenario is implemented as part of the TCAP standard. TCAP supports something called structured dialogue, based on transaction identifiers (corre- sponds to Aid) and dialogue identity (corresponds to AEid). The important differences in this scenario, compared to the previous one, are: Any mix of different types of service elements can be supported. Note, however, that association handling introduces extra delays in communication and demands extra transport capacity, compared to static discrimination methods. 5.4 Message Handling The association-handling procedures give some guarantee that peer-SEs are compatible. If the responding ASH finds that it has no SE with the given SEid (or no SE that can handle protocol PRB), it will reject the association request. Communication will not break down, and the calling ASH may have other sources (directories) that can be contacted to find the called SE. In the CON- CSP case, there is no negotiation between CCs. The success of communication over a connection therefore relies on the fact that there have not been any con- figuration changes or functional modifications of the called logical node. If such changes have been made and the calling logical nodes is not aware, communica- tion between peer-SEs will break down. From the SEs point of view, there is no difference between how they use the services of the CC and SAH, and the ASH and discriminator, respectively. The SE delivers the same information to the CC and ASH, and to the SAH and the discrim- inator, i.e. these interfaces are indepe