# Creating transparent IEs

The application supplies the data (in hexadecimal format) for the transparent IEs in a buffer referenced in one of the standard ACU messages. The following macros refer to the transparent IE buffer:

Macro | Description
--- | ---
acumessage_tsp_ie_list_size | Size of transparent IE buffer, in bytes. acumessage is a standard ACU message (for example ACU_CONN_RQ). For example, Acu_conn_rq_tsp_ie_list_size. Do not include a null terminator when calculating this value.
acumessage_a_tsp_ie_list | Pointer to transparent IE buffer. Do not include a null terminator in this string.

To use transparent IEs, the application must disable the stack's syntax checking mechanism. To do this, set the NS_IE_RELAY_BEHAVIOUR bit in the ns_behaviour substructure referenced in the ISDN_PROTOCOL_PARMS_Q931CC structure passed to isdnStartProtocol. By default, this bit is 0. The following code fragment shows how to set this bit prior to calling isdnStartProtocol:

myStartProtocol()
{
struct ISDN_PROTOCOL_PARMS_Q931CC parms;
...
memset(&parms,0,sizeof(ISDN_PROTOCOL_PARMS_Q931CC));
parms.size = sizeof(ISDN_PROTOCOL_PARMS_Q931CC);
parms.services_list[0] = ACU_VOICE_SERVICE;
/* Other services may be added here */
parms.services_list[1] = ACU_NO_SERVICE;
parms.ns_behaviour = NS_IE_RELAY_BEHAVIOUR;
...
isdnStartProtocol ( ctahd,
ISDN_PROTOCOL_Q931CC,
networkoperator,
country,
partner,
SM->nai,
&parms ); /* Instead of NULL */
...
}

## Transparent IE formatting rules

The following rules apply to transparent IE formatting:

- If the buffer contains more than one IE, the IEs must appear in the same order as they appear in the Q.931 message. For example, the channel ID (IE ID = 0x18) cannot be followed by bearer capability (IE ID = 0x04).

- When the stack's syntax checking mechanism is disabled, the stack does not perform syntax checking on transparent IEs. It is the application's responsibility to build the transparent IEs according to the specifications for the variant the application is using.

- The application should not use the transparent IE method and the macro method to access the same IE in the same ACU message. For example, if the application sets the macros for the called party number and includes the called party number IE (IE ID = 0x70) in the transparent IE buffer in the same ACU message, both IEs are present in the final SETUP message.

Certain information elements are automatically generated by the stack in Q.931 messages. The stack checks to see if any of the transparent IEs sent to it correspond to these information elements. If it finds a transparent IE equivalent for an automatically generated information element, it uses the transparent IE instead. See the following table for a list of IEs automatically generated by the stack.

- The transparent IE buffer must not be null-terminated.

- When calculating the size of a transparent IE buffer, do not include a null terminator. The following table lists IEs automatically generated by the stack:

Name | Applies to variant
--- | ---
bc | All variants
llc | All variants except HKT, NTT, QSI, SWD
hlc | All variants except E10
cause | All variants
chan_id | All variants

- The transparent IE must be formatted correctly, as shown in the following table. The multiple octet IEs in a Q.931 message follow an ascending numerical order by IE ID (for example, octet #1). Single octet IEs can appear at any point in the message. In the table, u and v represent bits that can be changed by the user:

  IE type | Information element id: octet #1 | Information element id: octet #2 | Information element id: octet #3
  Single octet IE | 0x1uuuuuuu | Not present | Not present
  Multiple octet IE | 0x0uuuuuuu | 0xvvvvvvvv | Follow as many octets as specified in octet #2