Specifications

HighWire MTP-2 - 1.2, September 4, 2002 Using the Cross Bus Interface 31
4-2-4. Connecting to and
disconnecting from an MTP2
instance
When an application wishes to communicate with an MTP2, it must first open
a connection to the line card where the MTP2 will be located (as explained in
Section 4-2-3). It must then open the MTP2 sub-interface (defined in the
header file cbim2.h) by sending a CBI_M2_OPEN message. Once the
application has received a CBI_M2_OPEN response, it may send one or more
CBI_M2_REGISTER messages (one for each MTP2 with which it wishes to
communicate). Details of how to send a message are provided Section 4-2-5.
The MTP3 should fill in the sender_handle field of the CBI_IPS substructure
with a correlator of its own choosing. Subsequent messages received across
the interface will always contain this value in the receiver_handle field of the
CBI_IPS substructure, which is always the first member of any control buffer
structure. The MTP3 must wait for a CBI_M2_REGISTER response (after which
it must be able to receive messages) and a CBI_M2_AVAILABLE (after which
the MTP3 is free to send other MTP2 messages as it wishes according to the
SS7-defined protocol).
Disconnection may be initiated by either the MTP3 or the MTP2. The MTP2
instance will only initiate disconnection in the event of an unexpected
hardware or software failure.
4-2-5. Sending messages to MTP2 To send a message to MTP2, the MTP3 implementation must set up all the
fields in a control buffer using the appropriate structure defined in the header
file. MTP3 is free to use whatever sort of memory it likes (stack or otherwise)
for this buffer except that the memory must be flat. The buffer must be longer
than the defined structure by the amount returned on the CBI_M2_OPEN
response in the send_ctrl_tail_size field. If there is an associated data
Table 4-1 Sequence of events in disconnections
Cause of disconnection Sequence of events
Intended disconnection MTP3 sends a CBI_M2_UNREGISTER message to
an MTP2 and awaits a CBI_M2_UNREGISTER
response.
MTP2 failure MTP3 receives a CBI_M2_UNAVAILABLE message
from the library. Upon receipt of a
CBI_M2_UNAVAILABLE message, the MTP3
application must respond with a
CBI_M2_UNREGISTER message. Unregistration
proceeds as normal.
Total failure (hardware or
software) of connection to
line card
MTP3 receives an error code M2_RC_IO_ERROR
to a call to cbi_send() or cbi_recv(). MTP3
then takes all necessary steps to reopen the
connection to the line card, reopen the sub-
interface, and reregister with all the MTP2
instances.