Solstice X.25 9.2 Developer's Guide

3.3.1 Opening connections for OSI CONS Calls

The following example opens a connection for an OSI CONS call:

#define FALSE	0
 #define TRUE	1
 #define CUDFLEN 4
 #define EXPLEN 4
 #include <memory.h>
 #include <netx25/x25_proto.h>
 struct xaddrf called = { 0, 0, {14, { 0x23, 0x42, 0x31, 0x56, 
 0x56, 0x56, 0x56 }}, 0};
 /* Subnetwork "A" (filled in later), no flags, 
   * DTE = "23423156565656", null NSAP  */
 struct xcallf conreq;
 struct strbuf, ctlblk, datblk;
 struct xedataf exp; 

 main ()
 {
    .
    .
    .
    called.link_id = 0;
    /*
     * snidtox25 only fails if a 
     * NULL string is passed to it 
     */
    conreq.xl_type = XL_CTL;
    conreq.xl_command = N_CI;
    conreq.CONS_call = TRUE;
    /* This is a CONS call */
    conreq.negotiate_qos = TRUE;
    /* Negotiate requested */
    memset(&conreq.qos, 0, sizeof (struct qosformat));
    conreq.qos.reqexpedited = TRUE;  /* Expedited requested */
    conreq.qos.xtras.locpacket = 8;  /* 256 bytes */
    conreq.qos.xtras.rempacket = 8;  /* 256 bytes */
    memcpy(&conreq.calledaddr, &called, sizeof(struct xaddrf));
    memset(&conreq.callingaddr, 0, sizeof(struct xaddrf));
    .
    .
    .
 }

Note -

When negotiate_qos is true (non-zero), setting the QOS fields to zero means that the connection uses defaults for QOS and Facilities. If required, these can be set to different values but it is recommended that the entire QOS structure be zeroed first as shown. This is preferable to setting each field individually, as it allows for any future additions to this structure. Setting the calling address to null leaves the network to fill this value in.


The message is sent on the stream using the putmsg system call, with any call user data being passed in the data part of the message:

char cudf[CUDFLEN] = { 1, 0, 0, 0 };
 ctlblk.len = sizeof(struct xcallf);
 ctlblk.buf = (char *) &conreq;
 datblk.len = CUDFLEN;
 datblk.buf = cudf;
 if (putmsg(x25_fd, &ctlblk, &datblk, 0) < 0 ) {
 	perror("Call putmsg");
 	exit(1);
 	}

At this stage, the application should wait for a response to the Call Request. The response may be either a Connect Confirmation or a Disconnect (rejection) message.