Solstice X.25 9.2 Developer's Guide

6.4 NLI Commands

This section describes the available NLI commands in alphabetical order. Refer to Table 6-1 for a summary of the available commands and related structures.

6.4.1 `N_Abort`--Abort Indication

Description

N_Abort is used when the X.25 driver needs to send a Disconnect to the application, but there is no resource available in the system to construct a full Disconnect Indication message. For this reason, this message should rarely be received. The control part of an Abort Indication message has a format defined in the xabortf structure. There is no data part.

Note -

This message only appears in a getmsg, never in a putmsg. Example 6-1 shows how a getmsg can be constructed.

The xabortf structure is shown below:

struct xabortf {
      unsigned char xl_type; /* Always XL_CTL */
      unsigned char xl_command; /* Always N_Abort */
 };

6.4.2 `N_CC`--Call Response/Confirmation

Synopsis

#include <stream.h>
 #include <netx25/x25_proto.h >

 struct strbuf ctlb;

 struct xccnff confirm;
 .
 .
 .
 ctlb.len = sizeof(struct xccnff);
 ctlb.buf = (char *)confirm;

 putmsg(x25_fd, &ctlb, NULL,0);

Description

N_CC is used when calls are being accepted. When used with putmsg, N_CC is a Call Response, when used with getmsg, it is a Call Confirmation. Example 6-1 shows how a getmsg can be constructed. When used with getmsg, ctlb.len is replaced by cltb.maxlen. The control part of the Call Request or Indication is defined by the xccnff structure. There is no data part.

The xccnff structure is shown below:

struct xccnff {
      unsigned char xl_type; /* Always XL_CTL */
      unsigned char xl_command; /* Always N_CC */
      int conn_id; /* The connection id quoted on the associated
                      indication. */
      unsigned char CONS_call; /* When set, indicates CONS call */
      unsigned char negotiate_qos; /* When set, negotiate
                                      facilities etc. else use
                                      indicated values */
      struct xaddrf responder; /* Responding address */
      struct qosformat rqos; /* Facilities and CONS qos: if
                                negotiate_qos is set */
 };

The members of the xccnff structure are:

Table 6-8 Call Response/Confirmation Message


Member	Description
`conn_id`	Connection identifier. `conn_id` must be returned in the Call Response so that listening operates properly. This must be the same connection identifier as was included in the Connection Request or Indication.
`CONS_call`	Indicates that OSI CONS procedures should be used for responses. If you are not using OSI CONS, this value should be 0.
`negotiate_qos`	A non-zero value shows that facilities and quality of service (QOS) are being negotiated. A zero value means the initiator is requesting all default values.
`responder`	The responding address.
`rqos`	Selected facilities and OSI CONS QOS parameters to be passed to the initiator.

6.4.3 `N_CI`--Call Request/Indication

Synopsis

#include <stream.h>
 #include <netx25/x25_proto.h >

 struct strbuf ctlb;
 struct strbuf datab;

 struct xcallf call;
 char          cud[MAX_LENGTH];
 .
 .
 .
 ctlb.len = sizeof(struct xcallf);
 ctlb.buf = (char *)call;

 datab.len = cudlen;
 datab.buf = cud;

 putmsg(x25_fd, &ctlb, &datab, 0);

Description

N_CI is used when calls are requested or indicated across the X.25 interface. When used with putmsg, N_CI is a Call Request, when used with getmsg, it is a Connect Indication. Example 6-1shows how a getmsg can be constructed. The control part of the Call Request or Indication is defined by the xcallf structure. The data part of the message will contain any call user data.

The xcallf structure is shown below:

struct xcallf {
 	unsigned char xl_type; /* Always XL_CTL */
 	unsigned char xl_command; /* Always N_CI */
 	int conn_id; /*connection id returned in Call Response or
                    Disconnect */
 	unsigned char CONS_call; /*When set, indicates a CONS call*/
 	unsigned char negotiate_qos; /* When set, negotiate
                                     facilities etc. or else use
                                     defaults */
 	struct xaddrf calledaddr; /* The called address  */
 	struct xaddrf callingaddr; /* The calling address */
 	struct qosformat qos; /* Facilities and CONS qos: if
                              negotiate_qos is set */
 };

The members of the xcallf structure are:

Table 6-9 Call Request/Indication Message


Member	Description
`conn_id`	For incoming calls, an attempt is made to match the called address and call user data with that of one of the listening applications. If a match is found, then the indication is passed to that application with a `conn_id` identifier, which must be returned in the Call Response or Clear Request to accept or reject the connection. Leave this value as 0.
`CONS_call`	Indicates that OSI CONS procedures should be used for the call.
`negotiate_qos`	A non-zero value shows that facilities and quality of service (QOS) are being negotiated. A zero value means the initiator is requesting all default values.
`calledaddr`	Holds the called address.
`callingaddr`	The calling address.
`qos`	Any facilities requested or indicated. To use the `qos` member, you must set `negotiate_qos`.

6.4.4 `N_DAck`--Data Ack Request/Indication

Synopsis

#include <stream.h>
 #include <netx25/x25_proto.h >

 struct strbuf ctlb;

 struct xdatacf dack;
 .
 .
 .
 ctlb.len = sizeof(struct xdatacf);
 ctlb.buf = (char *)dack;

 putmsg(x25_fd, &ctlb, NULL, 0);

Description

N_DAck acknowledges a previous Data Acknowledgment Request or Indication which had the D-bit set. The D-bit requests end-to-end, as opposed to local, acknowledgment. There is a one-to-one correspondence between D-bit data and acknowledgments, with one Data Acknowledgment being received/sent for each D-bit data packet sent/received. It is always the oldest outstanding D-bit packet that is being acknowledged.

Refer to "6.3.4 qosformat--Define OSI CONS QOS Parameters" for details of requesting acknowledgment using the reqackservice member of the qosformat structure. For OSI CONS calls, Data Acknowledgment must be negotiated on the connection.

When used with putmsg, N_DAck is a Data Acknowledgment Request, when used with getmsg, it is a Data Acknowledgment Indication. Example 6-1 shows how a getmsg can be constructed. The control part of the Data Acknowledgment Request or Indication is defined by the xdatacf structure. There is no data part.

The xdatacf structure is shown below:

struct xdatacf {
 	unsigned char xl_type; /* Always XL_DAT */
 	unsigned char xl_command; /* Always N_DAck */
 };

6.4.5 `N_Data`--Data

Synopsis

#include <stream.h>
 #include <netx25/x25_proto.h >

 struct strbuf ctlb;
 struct strbuf datab;

 struct xdataf control;
 char          data[MAX_LENGTH];
 .
 .
 .
 ctlb.len = sizeof(struct xdataf);
 ctlb.buf = (char *)control;

 datab.len = MAX_LENGTH;
 datab.buf = data;

 putmsg(x25_fd, &ctlb, &datab, 0);

Description

N_Data is used to transfer data across the X.25 interface. The synopsis shows a putmsg. Example 6-1 shows how a getmsg can be constructed. The control part of the Data packet is defined by the xdataf structure. The data part of the message contains the user data.

The xdataf structure is shown below:

struct xdataf {
 	unsigned char xl_type; /* Always XL_DAT */
 	unsigned char xl_command; /* Always N_Data */
 	unsigned char More; /* Set when more data is required
                            to complete the nsdu */
 	unsigned char setDbit, /* Set when data carries X.25 D-bit */
 	unsigned char setQbit; /* Set when data carries X.25 Q-bit */
 };

The members used by xdataf are.

Table 6-10 Data Message


Member	Description
`More`	Shows whether there is more of this network service data unit to be received/sent.
`setQbit`	Requests or indicates that the Q-bit is set when user data is transmitted/received. The Q-bit indicates that the data is intended for a device attached to the DTE and not for the DTE itself.
`setDbit`	Requests or indicates that the D-bit is set when user data is transmitted/received. The D-bit requests end-to-end acknowledgement.

Note -

No acknowledgement for this data is given to, or expected from, the application unless the D-bit is set and application-to-application Receipt Confirmation is being used.

6.4.6 `N_DC`--Clear Confirm

Synopsis

#include <stream.h>
 #include <netx25/x25_proto.h >

 struct strbuf ctlb;
 struct strbuf datab;

 struct xdcnff disc;
 char          cud[MAX_LENGTH];
 .
 .
 .
 ctlb.len = sizeof(struct xdcnff);
 ctlb.buf = (char *)disc;

 datab.len = cudlen;
 datab.buf = cud;

 putmsg(x25_fd, &ctlb, NULL, 0);

Description

N_DC is used to confirm a previous clear indication (N_DI). The example shows a putmsg. Example 6-1 shows how a getmsg can be constructed. The control part of the Data packet is defined by the xdcnff structure. If Fast Select is in use, the data part of the message contains any clear user data.

The xdcnff structure is shown below:

struct xdcnff {
 	unsigned char xl_type; /* Always XL_CTL */
 	unsigned char xl_command; /* Always N_DC */
 	unsigned char indicated_qos; /* When set, facilities
 	                                indicated */
 	struct qosformat rqos; /* If indicated_qos is set, holds
                               facilities and CONS qos */
 };

The members of the xdcnff structure are:

Table 6-11 Clear Confirm Parameters


Member	Description
`indicated_qos`	Non-zero value shows that facilities and QOS are being indicated.
`rqos`	Contains the facilities indicated. This is only used with the Charging Information facility.

6.4.7 `N_DI`--Clear Request/Indication

Synopsis

#include <stream.h>
 #include <netx25/x25_proto.h >

 struct strbuf ctlb;
 struct strbuf datab;

 struct xdiscf disc;
 char          cud[MAX_LENGTH];
 .
 .
 .
 ctlb.len = sizeof(struct xdiscf);
 ctlb.buf = (char *)disc;

 datab.len = cudlen;
 datab.buf = cud;

 putmsg(x25_fd, &ctlb, &datab, 0);

Description

N_DI is used when a Clear Request/Indication crosses the X.25 interface. When used with putmsg, N_DI is a Clear Request, when used with getmsg, it is a Disconnect Indication. Example 6-1shows how a getmsg can be constructed. The control part of the Call Request or Indication is defined by the xdiscf structure. If Fast Select is in use, the data part of the message contains any clear user data.

The X.25 cause and diagnostic bytes, cause and diag, are presented, as well as the CONS originator and reason codes mapped from these. For a Clear Request the user can specify a non-zero cause code. This has no effect for an OSI CONS call; the value is set to zero by the system.

The Clear Request from an application is confirmed unless it is a rejection of a previous Connect Indication. When it is not a rejection, the X.25 driver sends a Clear Confirm to the application when the Clear Confirmation is received. This guarantees that once the Clear Confirm is read by the application no more messages are sent on this stream. For this reason, after requesting disconnection, the application should read and discard all messages from the stream until the Clear Confirm is received.

For call rejection, no acknowledgment is sent. However, the application must supply the connection identifier presented in the Connect Indication so that the appropriate circuit is cleared. In the case of a Disconnect Indication, all messages sent downstream except connect messages are discarded silently.

The xdiscf structure is shown below:

struct xdiscf {
 	unsigned char xl_type; /* Always XL_CTL */
 	unsigned char xl_command; /* Always N_DI */
 	unsigned char originator, /* Originator and Reason mapped
                                  from */
 		reason, /* X.25 cause/diag in indications */
 		cause, /* X.25 cause byte */
 		diag; /* X.25 diagnostic byte */
 	int conn_id; /* The connection id (for reject only) */
 	unsigned char indicated_qos; /* When set, facilities
                                     indicated */
 	struct xaddrf responder; /* CONS responder address */
 	struct xaddrf deflected; /* Deflected address */
 	struct qosformat qos; /* If indicated_qos is set, holds
                              facilities and CONS qos */
 };

The members of the xdiscf structure are.

Table 6-12 Clear Request/Indication Parameters


member	Description
`originator`	OSI CONS mapping of the X.25 cause byte.
`reason`	OSI CONS mapping of the X.25 diagnostic byte. Refer to Chapter 9, Error Codes for further information.
`cause`	The X.25 cause byte.
`diag`	The X.25 diagnostic byte.
`indicated_qos`	Non-zero value shows that facilities and QOS are being indicated.
`responder`	Contains the responding address.
`deflected`	Used in conjunction with the `call_deflect` facility in the `qos` structure to convey the address of the remote DTE that the call is to be deflected to.
`qos`	Contains the facilities indicated. This is used with the Charging Information facility and the Call Deflection facility.

Note -

If a disconnect collision occurs, acknowledgement is taken to be complete.

6.4.8 `N_EAck`--Expedited Data Acknowledgement

Synopsis

#include <stream.h>
 #include <netx25/x25_proto.h >

 struct strbuf ctlb;

 struct xedatacf eack;
 .
 .
 .
 ctlb.len = sizeof(struct xedatacf);
 ctlb.buf = (char *)eack;

 putmsg(x25_fd, &ctlb, NULL, 0);

Description

N_EAck is used to acknowledge expedited data, carried by an X.25 Interrupt packet. The example shows a putmsg. Example 6-1 shows how a getmsg can be constructed. The control part of the Interrupt packet is defined by the xedatacf structure. There is no data part. An acknowledgment must be sent immediately on receipt of an Interrupt packet.

The xedatacf structure is shown below:

struct xedatacf {
 	unsigned char xl_type; /* Always XL_DAT */
 	unsigned char xl_command; /* Always N_EAck */
 };

6.4.9 `N_EData`--Expedited Data

Synopsis

#include <stream.h>
 #include <netx25/x25_proto.h >

 struct strbuf ctlb;
 struct strbuf datab;

 struct xedataf edata;
 char          data[MAX_LENGTH];
 .
 .
 .
 ctlb.len = sizeof(struct xedataf);
 ctlb.buf = (char *)edata;

 datab.len = cudlen;
 datab.buf = cud;

 putmsg(x25_fd, &ctlb, &datab, 0);

Description

N_EData is used when expedited data, carried by an X.25 Interrupt packet, crosses the X.25 interface. The example shows a putmsg. Example 6-1 shows how a getmsg can be constructed. The control part of the Interrupt packet is defined by the xedataf structure. The data part of the message contains the user data. The expedited data is a confirmed primitive and must be acknowledged (see "6.4.8 N_EAck--Expedited Data Acknowledgement") before another expedited data unit can be requested or indicated.

The xedataf structure is shown below:

struct xedataf {
 	unsigned char xl_type; /* Always XL_DAT */
 	unsigned char xl_command; /* Always N_EData */
 };

6.4.10 `N_PVC_ATTACH`--PVC Attach

Synopsis

#include <stream.h>
 #include <netx25/x25_proto.h >

 struct strbuf ctlb;

 struct pvcattf attach;
 .
 .
 .
 ctlb.len = sizeof(struct pvcattf);
 ctlb.buf = (char *)attach;

 putmsg(x25_fd, &ctlb, NULL, 0);

Description

N_PVC_ATTCH is used when an application wants to attach to a PVC.The control part of the PVC Attach is defined by the pvcattf structure. The example shows a putmsg. Example 6-1 shows how a getmsg can be constructed.

The pvcattf structure is shown below:

struct pvcattf {
        unsigned char     xl_type;      /* Always XL_CTL */
        unsigned char     xl_command;   /* Always N_PVC_ATTACH */
        unsigned short    lci;          /* Logical channel */
        uint32_t     link_id;      /* Link # */
        /* 0 for next 3 parameters implies use of default */
        unsigned char     reqackservice;
        unsigned char     reqnsdulimit;
        int               nsdulimit;
        int               result_code;     /* Non-zero - error */
};

The members used by pvcattf are:

Table 6-13 PVC Attach Parameters


Member	Description
`lci`	Contains the logical channel identifier of the required PVC.
`link_id`	Denotes the particular link identifier for the PVC.
`reqackservice`	If non-zero, denotes that the receipt acknowledgement service is requested by use of the D-bit. Setting `reqackservice` to 1 signifies receipt confirmation by the remote DTE. Setting `reqackservice` to 2 signifies receipt confirmation by the remote application. In the case of receipt confirmation by the remote DTE, no acknowledgements are expected or given over the X.25 interface. In the case of receipt confirmation by the remote application, there is a one-to-one correspondence between D-bit data and acknowledgements with one data acknowledgement being received/sent for each D-bit data packet sent/received over the X.25 interface.
`reqnsdulimit`	If this is non-zero, use value in `nsdulimit`.
`nsdulimit`	Specifies the packet concatenation limit for NSDUs. If you want to use this parameter, `reqnsdulimit` must be non-zero. (The X.25 driver does not look at `reqnsdulimit` if `nsdulimit` is zero.)
`result_code`	In the attach message sent to the user as acknowledgment, this member denotes whether the attach was successful. The possible values are defined in the `netx25/x25_proto.h` file.

6.4.11 `N_PVC_DETACH`--PVC Detach

Synopsis

#include <stream.h>
 #include <netx25/x25_proto.h >

 struct strbuf ctlb;
 struct strbuf datab;

 struct pvcdetf detach;
 .
 .
 .
 ctlb.len = sizeof(struct pvcdetf);
 ctlb.buf = (char *)detach;

 datab.len = cudlen;
 datab.buf = cud;

 putmsg(x25_fd, &ctlb, &datab, 0);

Description

N_PVC_DETACH is used when an application wants to detach from a PVC. This allows the use of a stream to be changed. The control part of the PVC Detach is defined by the pvcdetf structure. The data part of the message contains any call user data. The synopsis shows a putmsg. Example 6-1 shows how a getmsg can be constructed.

The pvcdetf structure is shown below:

struct pvcdetf {
 	unsigned char xl_type; /* Always XL_CTL */
 	unsigned char xl_command; /* Always N_PVC_DETACH */
 	int reason_code; /* Reports why */
 };

This structure has the following member:

Table 6-14 Listen Cancel Command/Response Parameters


Member	Description
`reason_code`	The reason for the detach, or a code indicating that a previous PVC Detach was successful.

Note -

The PVC Detach message is acknowledged to the user by returning another PVC Detach message.

6.4.12 `N_RC`--Reset Response/Confirm

Synopsis

#include <stream.h>
 #include <netx25/x25_proto.h >

 struct strbuf ctlb;

 struct xrscf rc;
 .
 .
 .
 ctlb.len = sizeof(struct xrscf);
 ctlb.buf = (char *)rc;

 putmsg(x25_fd, &ctlb, NULL, 0);

Description

N_RC is used to respond to a previous reset. When used in a putmsg it is a Reset Response. In a getmsg it is a Reset Confirm. Example 6-1 shows how a getmsg can be constructed. The control part of the Reset Response or Confirm is defined by the xrscf structure. There is no data part.

The xrscf structure is shown below:

struct xrscf {
 	unsigned char xl_type; /* Always XL_CTL */
 	unsigned char xl_command; /* Always N_RC */
 };

Note -

A Reset primitive is an acknowledged service (see the associated structure xrscf). A collision between a Reset Indication and a Reset Request is taken to acknowledge the Reset--no Reset Confirmation is then required before another Reset Request can be sent. Normally, Resets are handled by the application.

6.4.13 `N_RI`--Reset Request/Indication

Synopsis

#include <stream.h>
 #include <netx25/x25_proto.h >

 struct strbuf ctlb;

 struct xrstf reset;
 .
 .
 .
 ctlb.len = sizeof(struct xrstf);
 ctlb.buf = (char *)reset;

 putmsg(x25_fd, &ctlb, NULL, 0);

Description

N_RI is used for resets. When used in a putmsg it is a Reset Request. In a getmsg it is a Reset Indication. Example 6-1 shows how a getmsg can be constructed. The X.25 cause and diagnostic bytes, cause and diag, are presented as well as the CONS originator and reason codes that are mapped from these. Refer to Chapter 9, Error Codes for further information.

For a Reset Request, the user can specify a non-zero cause code. This has no effect for an OSI CONS call; the value is set to zero by the system.

The control part of the Reset Request or Indication is defined by the xrstf structure. There is no data part.

The xrstf structure is shown below:

struct xrstf {
 	unsigned char xl_type; /* Always XL_CTL */
 	unsigned char xl_command; /* Always N_RI */
 	unsigned char originator, /* Originator and Reason mapped */
 			reason, /* from X.25 cause/diag in indications */
 			cause, /* X.25 cause byte */
 			diag; /* X.25 diagnostic byte */
 };

Note -

A Reset primitive is an acknowledged service. It must be acknowledged before another Reset can be requested. A collision between a Reset Indication and a Reset Request is taken to acknowledge the Reset--no Reset Confirmation is then required before another Reset Request can be sent. Normally, Resets are handled by the application.

6.4.14 `N_Xcanlis`--Listen Cancel Command/Response

Synopsis

#include <stream.h>
 #include <netx25/x25_proto.h >

 struct strbuf ctlb;

 struct xcanlisf canlis;
 .
 .
 .
 ctlb.len = sizeof(struct xcanlisf);
 ctlb.buf = (char *)canlis;

 putmsg(x25_fd, &ctlb, NULL, 0);

Description

N_Xcanlis is used to cancel an interest in incoming calls.

When used with putmsg, N_Xcanlis is a Listen Cancel Command, when used with getmsg, it is a Listen Cancel Response. Example 6-1 shows how a getmsg can be constructed. The control part of the Listen Command or Response is defined by the xcanlisf structure. There is no data part.

Note -

The Cancel Request removes all listen addresses from the stream. There is no way of cancelling a Listen on a particular address, for example, when the use of the stream is about to be changed by the application.

The control part of a Listen Cancel Command or Response message has a format defined in the xcanlisf structure:

struct xcanlisf {
 	unsigned char xl_type; /* Always XL_CTL  */
 	unsigned char xl_command; /* Always N_Xcanlis */
 	int c_result; /* Result flag */
 };

This structure has the following member:

Table 6-15 Listen Cancel Command/Response Parameters


Member	Description
`c_result`	A non-zero value of the `c_result` flag indicates failure of the operation to cancel a Listen. This may indicate that the Listen was not present or that some connect event is outstanding. The closure of a stream on which there is a Listen also cancels the Listen, but in the case of the cancel command message, the stream remains open.

6.4.15 `N_Xlisten`--Listen Command/Response

Synopsis

#include <stream.h>
 #include <netx25/x25_proto.h >

 struct strbuf ctlb;
 struct strbuf datab;

 struct xlistenf listen;
 char          lisbuf[MAXLIS];
 .
 .
 .
 ctlb.len = sizeof(struct xlistenf);
 ctlb.buf = (char *)listen;

 datab.len = lislen;
 datab.buf = lisbuf;

 putmsg(x25_fd, &ctlb, &datab, 0);

Description

N_Xlisten is used to listen for incoming calls. When used with putmsg, N_Xlisten is a Listen Command, when used with getmsg, it is a Listen Response. Example 6-1 shows how a getmsg can be constructed. The control part of the Listen Command or Response is defined by the xlistenf structure.

The data part is treated as a byte stream of CUD and addresses conforming to the following definition:

unsigned char l_cumode;
 unsigned char l_culength;
 unsigned char l_cubytes [l_culength];
 unsigned char l_mode;
 unsigned char l_type;
 unsigned char l_length;
 unsigned char l_add[(l_length+1)>>1];

Not all variables need be present. Refer to the individual variable descriptions below for more details.

The fields l_cumode, l_culength and l_cubytes are used to match the CUD field of the incoming call against that specified in the Listen request.

Table 6-16 Variables for CUD matching


Variable Name	Description
`l_cumode`	Defines the type of matching: `X25_DONTCARE` The listener ignores the CUD; `l_culength` and `l_cubytes` are omitted. `X25_IDENTITY` The listener match is only made if all bytes of the CUD field are the same as the supplied `l_cubytes`. `X25_STARTSWITH`The listener match is only made if the leading bytes of the CUD Field are the same as the supplied `l_cubytes`.
`l_culength`	Length of the CUD in octets for an `X25_IDENTITY` or `X25_STARTSWITH` CUD Field match. If `l_culength` is zero, the `l_cubytes` are omitted. The range for `l_culength` is zero to 16 inclusive. If more than 16 bytes are present, the application still has to check the full CUD Field.
`l_cubytes`	String of bytes sought in the call user data field when `l_cumode` is `X25_IDENTITY` or `X25_STARTSWITH`.

The fields l_mode, l_type, l_length and l_add are used to match the called address field(s) of the incoming call against that specified in the Listen request.

Table 6-17 Variables for address matching


Variable Name	Description
`l_mode`	Defines the type of matching: `X25_DONTCARE` The listener ignores the address; `l_type,` `l_length`, and `l_add` are omitted. `X25_IDENTITY` The listener match is only made if all digits of the address are the same as the supplied `l_add`. `X25_STARTSWITH` The listener match is only made if the leading digits of the address are the same as the supplied `l_add`. `X25_PATTERN` The listener match is made on partial addresses, allowing the use of wildcard digits.
`l_type`	The type of the address entry; `l_type` can have two values, `X25_DTE` or `X25_NSAP`. It denotes the important addressing quantity. For X.25 (84) and X.25 (88), for example, NSAP addresses (or extended addresses) are the important addresses, while for X.25 (80), where there is no NSAP address, the DTE address is the important quantity. Applications can be distinguished by X.25 DTE subaddress where necessary. On many X.25 (84) and X.25 (88) networks, it is possible to listen on either `X25_DTE` or `X25_NSAP` addresses. This is not possible when running X.25 (84) or X.25 (88) over LLC2 on the LAN. In this case, the DTE address field is NULL and the `X25_NSAP` field is used.
`l_length`	Length of the address `l_add` in BCD digits--the common format for X.25 DTE and NSAP addresses. If `l_length` is zero, then `l_add` is omitted. The maximum values for `l_length` are 15 for `X25_DTE` and 40 for `X25_NSAP`.
`l_add`	Contains the address to be compared with the called address field of the incoming call packet. `l_add` is omitted when `l_length` is zero.

Note -

To use wildcards, represent * by 0x0F and ? by 0x0E. * represents 0 or more characters. ? represents a single character.

The xlistenf structure is shown below:

struct xlistenf {
 	unsigned char xl_type; /* Always XL_CTL */
 	unsigned char xl_command; /* Always N_Xlisten */
 	int lmax; /* Maximum number of CI's at a time */
 	int l_result; /* Result flag */
 };

The members of the xlistenf structure are.

Table 6-18 Listen Command/Response Parameters


Member	Description
`lmax`	Maximum number of Connect Indications that the listener can handle at one time. Note: listen requests are cumulative but the `lmax` value (number of simultaneously handled Connect Indications) is not. This means that several listen requests can be made on a single stream, in which case the `lmax` value contained in the last listen message specifies the number of simultaneously handled Connect Indications.
`l_result`	The result of the listen request is acknowledged upstream with the same message. An error in the parameters or a lack of resources to set up the listen causes this flag to be set to a non-zero value.

Note -

For example code using listening, refer to Chapter 4, Listening for Calls.

6.4 NLI Commands

6.4.1 N_Abort--Abort Indication

Description

6.4.2 N_CC--Call Response/Confirmation

Synopsis

Description

6.4.3 N_CI--Call Request/Indication

Synopsis

Description

6.4.4 N_DAck--Data Ack Request/Indication

Synopsis

Description

6.4.5 N_Data--Data

Synopsis

Description

6.4.6 N_DC--Clear Confirm

Synopsis

Description

6.4.7 N_DI--Clear Request/Indication

Synopsis

Description

6.4.8 N_EAck--Expedited Data Acknowledgement

Synopsis

Description

6.4.9 N_EData--Expedited Data

Synopsis

Description

6.4.10 N_PVC_ATTACH--PVC Attach

Synopsis

Description

6.4.11 N_PVC_DETACH--PVC Detach

Synopsis

Description

6.4.12 N_RC--Reset Response/Confirm

Synopsis

Description

6.4.13 N_RI--Reset Request/Indication

Synopsis

Description

6.4.14 N_Xcanlis--Listen Cancel Command/Response

Synopsis

Description

6.4.15 N_Xlisten--Listen Command/Response

Synopsis

Description

6.4.1 `N_Abort`--Abort Indication

6.4.2 `N_CC`--Call Response/Confirmation

6.4.3 `N_CI`--Call Request/Indication

6.4.4 `N_DAck`--Data Ack Request/Indication

6.4.5 `N_Data`--Data

6.4.6 `N_DC`--Clear Confirm

6.4.7 `N_DI`--Clear Request/Indication

6.4.8 `N_EAck`--Expedited Data Acknowledgement

6.4.9 `N_EData`--Expedited Data

6.4.10 `N_PVC_ATTACH`--PVC Attach

6.4.11 `N_PVC_DETACH`--PVC Detach

6.4.12 `N_RC`--Reset Response/Confirm

6.4.13 `N_RI`--Reset Request/Indication

6.4.14 `N_Xcanlis`--Listen Cancel Command/Response

6.4.15 `N_Xlisten`--Listen Command/Response