Appendix C Application Programmer’s Interface 91
TheQ.93B driver is an M-to-N mux STREAMS driver. Multiple application programs
can be plumbed above the driver,and multiple physical interfaces can be connected
below Q.93B. Applications can access any or all of the physical interfaces, and
messages received on the physical interfaces can be directed to any of the
applications. Todirect messages through the Q.93B driver, messages from
applications must include a physical interface name to identify the outgoing
interface and an SAP to identify the application to which the message should be
directed on the receiving host.
Send messages to Q.93B by applications according to the format illustrated in
FIGUREC-1; kernel applications use putnext(9f) to send the mblocks shown, and
user applications send two corresponding strbufs using putmsg(2).
FIGUREC-2 Message Format
The structure included in the M_PROTO mblock is defined asthe qcc_hdr_t
structure in the <atm/qcctypes.h> header file. In the second mblock, the Q.2931
header portion (9 bytes) of the Q.2931 message is blank and is later filled in by the
TABLEC-2 Fields in the M_PROTO mblock
Message Explanation
Ifname Null-terminated string containing the device name
Call_ID Unique number fromQ.93B for each interface.
Type Same as the Q.2931 message type except thereis a local non-Q.2931
message type SETUP_ACK. The SETUP_ACK message is used to provide
the Call_ID to the user.
Error_Code Errorreturned from Q.93B when an erroneous message is received from
the user.The same mblock chain is returned to the user with the
Error_Code fieldset. The user must always clear this field
Call_Tag Number assigned by the calling application layer to aSETUP message.
When a SETUP_ACK is received fromQ.93B, the Call_ID has been set;
use the Call_Tag fieldto identify the acknowledgment (ack) with the
original request.From that point on, use the Call_ID value to identify
the call.
Ifname
Call_ID
Type
Error_Code
M_PROTO M_DATA
mp Q.2931 Message
(9) (16)
Information
Elements (IEs)
Call_Tag
R
S
V