3.1 Introduction

3.2 Overview

3.3 Making Switch Connections for AG ISDN

3.4 Initializing CT Access

3.4.1 Specifying B Channel CTA Contexts

3.4.2 Specifying D Channel CTA Contexts

3.5 Accessing D Channels

3.5.1 About Network Access Identifiers (NAIs)

3.5.2 Initializing ISDN Protocol Stack Instances

3.6 Starting the NOCC TCP

3.6.1 Setting mediamask (AG Quad T/E only)

3.7 Stopping an ISDN Protocol Stack Instance

3.1 Introduction

This chapter:

• Describes how to make switch connections (if necessary) to route D channel and B channel information to appropriate resources.

• Shows how to initialize CT Access, and create CTA contexts for B channels and D channels.

• Explains how to initialize ISDN protocol stack instances on D channel CTA contexts.

• Explains how to start the "no call control" Trunk Control Program (TCP) on B channel CTA contexts.

3.2 Overview

An AG ISDN application performs the following initialization tasks:

1. If necessary, the application makes switch connections to route D channel data to the HDLC controller, and to route B channel information to DSP resources. Note that certain default connections are automatically made if MVIP switching is not enabled. For more information, see Section 3.3, Making Switch Connections for AG ISDN.
   
   
   Figure 15. Routing Channel Data to On-Board Resources

2. The application initializes CT Access, and creates a separate CTA context for each B channel and D channel it will interact with. For more information, see Section 3.4, Initializing CT Access.
   
   
   Figure 16. Creating CTA Contexts for Channels

3. The application initializes ISDN protocol stack instances on each D channel CTA context, using the isdnStartProtocol function from the AG ISDN library. This function starts up an ISDN protocol stack instance on the D channel CTA context in ACU or LAPD stack mode. In the function call, the trunk is specified using its network access identifier (NAI) and, if duplicate NAI values are defined, the NFAS group number this NAI belongs to. For more information, see Section 3.5, Accessing D Channels.
   
   
   Figure 17. Calling isdnStartProtocol

4. The application starts a special "no call control" Trunk Control Program (nocc TCP) on each B channel context. This puts the CTA context in a state where voice or media functions can be used without call control. For more information, see Section 3.6, Starting the NOCC TCP.
   
   
   Figure 18. Starting nocc TCPs on B channel Contexts

3.3 Making Switch Connections for AG ISDN

To allow an application access to ISDN channels, several switch connections must be made. In your configuration file, if Clocking.HBus.ClockMode=StandAlone (ClockRef = NET1 for CT Access 3.x), these settings are automatically made when the board boots. However, if Clocking.HBus.ClockMode is any other value, the application must make these settings, using the CTA switching service or swish utility.

The connections to be made are:

• On each trunk, streams and timeslots carrying D channel information to and from the HDLC controller (if any) must be connected to streams and timeslots accessible by the ISDN protocol stack. These connections must be full duplex. They must be made before the ISDN protocol stack is initialized. (Initialization is described in Section 3.5.2, Initializing ISDN Protocol Stack Instances.)

• The streams and timeslots carrying voice information to and from the trunk must be connected to the streams and timeslots carrying voice information to and from the DSP resources. The connections must be full duplex.

The connections differ depending upon whether the NetworkInterface.T1E1.SignalingType (DigitalMode in CT Access 3.x) keyword is set to PRI or RAW. Specifically, if NetworkInterface.T1E1.SignalingType=RAW, no connections are made between the HDLC controller and signaling streams. This setting is for trunks which are included in NFAS groups and do not have a D-channel in operation. For more information about these keywords and about NFAS, see your AG ISDN Installation Manual.

Note: Connections are listed in MVIP-95 nomenclature unless otherwise specified.

The following table shows the connections made by default:

	Default Connections
Board	NetworkInterface.T1E1[x]. SignalingType=PRI	NetworkInterface.T1E1[x]. SignalingType=RAW
Four-trunk T1 board (e.g., AG Quad T, CG 6000C)	Full duplex, between trunk voice information and DSP resources: · Trunk A: 0:0..22 => 17:0..22, 16:0..22 => 1:0..22 · Trunk B: 4:0..22 => 17:24..46, 16:24..46 => 5:0..22 · Trunk C: 8:0..22 => 17:48..70, 16:48..70 => 9:0..22 · Trunk D: 12:0..22 => 17:72..94, 16:72..94 => 13:0..22 Full duplex, between HDLC controller and signaling streams: · Trunk A: 2:0 => 21:0, 20:0 => 3:0 · Trunk B: 6:0 => 23:0, 22:0 => 7:0 · Trunk C: 10:0 => 25:0, 24:0 => 11:0 · Trunk D: 14:0 => 27:0, 26:0 => 15:0	Full duplex, between trunk voice information and DSP resources: · Trunk A: 0:0..23 => 17:0..23, 16:0..23 => 1:0..23 · Trunk B: 4:0..23 => 17:24..47, 16:24..47 => 5:0..23 · Trunk C: 8:0..23 => 17:48..71, 16:48..71 => 9:0..23 · Trunk D: 12:0..23 => 17:72..95, 16:72..95 => 13:0..23
Four-trunk E1 board (e.g., AG Quad E, CG 6000C)	Full duplex, between trunk voice information and DSP resources: · Trunk A: 0:0..29 => 17:0..29, 16:0..29 => 1:0..29 · Trunk B: 4:0..29 => 17:30..59, 16:30..59 => 5:0..29 · Trunk C: 8:0..29 => 17:60..89, 16:60..89 => 9:0..29 · Trunk D: 12:0..29 => 17:90..119, 16:90..119 => 13:0..29 Full duplex, between HDLC controller and signaling streams: · Trunk A: 2:0 => 21:0, 20:0 => 3:0 · Trunk B: 6:0 => 23:0, 22:0 => 7:0 · Trunk C: 10:0 => 25:0, 24:0 => 11:0 · Trunk D: 14:0 => 27:0, 26:0 => 15:0	Full duplex, between trunk voice information and DSP resources: · Trunk A: 0:0..29 => 17:0..29, 16:0..29 => 1:0..29 · Trunk B: 4:0..29 => 17:30..59, 16:30..59 => 5:0..29 · Trunk C: 8:0..29 => 17:60..89, 16:60..89 => 9:0..29 · Trunk D: 12:0..29 => 17:90..119, 16:90..119 => 13:0..29 Note: Generally, NetworkInterface.T1E1[x]. SignalingType is set to RAW only for trunks that are included in NFAS groups and do not have a D-channel in operation. NFAS is not supported on E1 trunks, so you would probably not use this configuration.
Two-trunk T1 board (e.g.AG Dual T, CG 6000C)	Full duplex, between trunk voice information and DSP resources: · Trunk A: 0:0..22 => 17:0..22, 16:0..22 => 1:0..22 · Trunk B: 4:0..22 => 17:24..46, 16:24..46 => 5:0..22 Full duplex, between HDLC controller and signaling streams: · Trunk A: 2:0 => 21:0, 20:0 => 3:0 · Trunk B: 6:0 => 23:0, 22:0 => 7:0	Full duplex, between trunk voice information and DSP resources: · Trunk A: 0:0..23 => 17:0..23, 16:0..23 => 1:0..23 · Trunk B: 4:0..23 => 17:24..47, 16:24..47 => 5:0..23
Two-trunk E1 board (e.g., AG Dual E, CG 6000C)	Full duplex, between trunk voice information and DSP resources: · Trunk A: 0:0..29 => 17:0..29, 16:0..29 => 1:0..29 · Trunk B: 4:0..29 => 17:30..59, 16:30..59 => 5:0..29 Full duplex, between HDLC controller and signaling streams: · Trunk A: 2:0 => 21:0, 20:0 => 3:0 · Trunk B: 6:0 => 23:0, 22:0 => 7:0	Full duplex, between trunk voice information and DSP resources: · Trunk A: 0:0..29 => 17:0..29, 16:0..29 => 1:0..29 · Trunk B: 4:0..29 => 17:30..59, 16:30..59 => 5:0..29 Note: Generally, NetworkInterface.T1E1[x]. SignalingType is set to RAW only for trunks that are included in NFAS groups and do not have a D-channel in operation. NFAS is not supported on E1 trunks, so you would probably not use this configuration.
One-trunk T1 board	Full duplex, between trunk voice information and DSP resources: MVIP 95: 0:0..22 => 5:0..22, 4:0..22 => 1:0..22 MVIP 90: 16:0..22 <=> 18:0..22 Full duplex, between HDLC controller and signaling streams: MVIP 95: 2:0 => 9:0, 8:0 => 3:0 MVIP 90: 17:0 <=> 20:0	Full duplex, between trunk voice information and DSP resources: MVIP 95: 0:0..23 => 5:0..23, 4:0..23 => 1:0..23 MVIP 90: 16:0..23 <=> 18:0..23
One-trunk E1 board	Full duplex, between trunk voice information and DSP resources: · MVIP 95: 0:0..29 => 5:0..29, 4:0..29 => 1:0..29 · MVIP 90: 16:0..29 <=> 18:0..29 Full duplex, between HDLC controller and signaling streams: · MVIP 95: 2:0 => 9:0, 8:0 => 3:0 · MVIP 90: 17:0 <=> 20:0	Full duplex, between trunk voice information and DSP resources: · MVIP 95: 0:0..29 => 5:0..29, 4:0..29 => 1:0..29 · MVIP 90: 16:0..29 <=> 18:0..29 Note: Generally, NetworkInterface.T1E1[x]. SignalingType is set to RAW only for trunks that are included in NFAS groups and do not have a D-channel in operation. NFAS is not supported on E1 trunks, so you would probably not use this configuration.

3.4 Initializing CT Access

To begin operations, the application initializes CT Access:

1. Initializes CT Access services (including the ISDN service), using ctaInitialize.

2. Creates one or more event queues, using ctaCreateQueue. Each function call creates a queue and returns a handle. Make sure at least one queue is attached to the ADI service manager.

3. Creates one or more contexts, using ctaCreateContext. Each call creates a CTA context and returns a CTA context handle.

4. Opens services initialized in step 1 on the CTA contexts using ctaOpenServices.

For more information about initializing CT Access, see the CT Access Developer's Reference Manual.

3.4.1 Specifying B Channel CTA Contexts

Create a separate CTA context for each B channel that your application will interact with. To open CTA contexts under CT Access, use ctaCreateContext followed by ctaOpenServices. In each call to ctaOpenServices, specify:

• stream - For B channel contexts, set stream to the voice stream(s) for the on-board DSPs. These streams are:

  Board	DSP Resource Stream
  AG-T1, AG-E1	MVIP 95: Local stream 4 MVIP 90: stream 18
  All other NMS digital trunk interface boards	MVIP 95: Local stream 16

• timeslot - For B channel contexts, set to a base timeslot in stream.

• mode - For B channel contexts, set mode to ADI_VOICE_DUPLEX. This mode allows voice (inband) transmission and reception. Do not use modes involving signaling that are defined in the ADI documentation, since ISDN signaling is not carried in the B channels.

Under CT Access, these values are included in the CTA_MVIP_ADDR structure passed to ctaOpenServices.

3.4.2 Specifying D Channel CTA Contexts

The application must also create a separate CTA context for each D channel it will interact with. Four-digital trunk boards can each support up to four separate D channels. Two-digital trunk boards can each support up to two separate D channels. One-digital trunk boards can support one D channel each.

To open D channel CTA contexts under CT Access, use ctaCreateContext followed by ctaOpenServices. In each call to ctaOpenServices, stream, timeslot and mode should be set to 0, since no DSP processing resources are needed to control the D channel data stream.

Under CT Access, these values are included in the CTA_MVIP_ADDR structure passed to ctaOpenServices.

3.5 Accessing D Channels

Once one or more CTA contexts have been created for the D channels, initialize a separate ISDN protocol stack instance for each of these CTA contexts, and associate a specific D channel with each one. When this is done, a D channel is ready to send and receive messages.

3.5.1 About Network Access Identifiers (NAIs)

A trunk is referred to by its network access identifier (NAI). When you initialize an ISDN protocol stack instance for a CTA context (using isdnStartProtocol), you specify the NAI of the trunk to associate with the CTA context. If duplicate NAI values are defined, the NFAS group number must be supplied. From then on, the application can communicate with the D channel on that trunk via the CTA context handle. For example, when an event is received, the CTA context handle indicates the trunk on which the event occurred.

Different board types support different numbers of D channels, with different NAI numbers. The following table shows what each board type supports:

Board type	Number of D channels	NAI default values
Four-trunk board	Up to 4	0 through 3
Two-trunk board	Up to 2	0 through 1
One-trunk board	1	0

3.5.2 Initializing ISDN Protocol Stack Instances

Use isdnStartProtocol to initialize ISDN protocol stack instances.

Note: Once you reference the CTA context in an isdnStartProtocol function call, do not reference that context in any other function call except isdnStopProtocol (when you wish to stop the stack).

To start up an ISDN protocol stack instance for ISDN ACU call control or LAPD, set the protocol, partner_equip, and parms arguments as follows:

protocol

Set to:

ISDN_PROTOCOL_Q931CC for ACU stack mode, or

ISDN_PROTOCOL_LAPD for LAPD stack mode.

partner_equip

The type of equipment connected to the board. Set to one of the following:

If the board is...	And AG ISDN is to run in...	Set partner_equip to...
Connected to network	ACU stack mode	EQUIPMENT_NT
Connected to network	LAPD stack mode	EQUIPMENT_DCE
Acting as network	ACU stack mode	EQUIPMENT_TE
Acting as network	LAPD stack mode	EQUIPMENT_DTE

parms

Pointer to a parameter structure to configure the protocol stack. If the application needs to change any of the parameters described in Appendix B, pass a pointer to one of the following structures in this call:

ISDN_PROTOCOL_PARMS_Q931CC for ACU stack mode, or

ISDN_PROTOCOL_PARMS_LAPD for LAPD stack mode.

If the application does not need to modify parameters, pass NULL to accept the default settings. For ACU, all the services are supported by default.

The ISDNEVN_START_PROTOCOL event contains the completion status of the start request. If the ISDN protocol stack instance starts successfully, the value field in this event will contain SUCCESS. Otherwise, another value will appear here.

For more information about isdnStartProtocol, see Chapter 7.

3.6 Starting the NOCC TCP

Once all ISDN protocol stack instances have been created, start a "no call control" (NOCC) TCP on each B channel CTA context. This TCP puts the CTA context in a state where voice or media functions can be used without call control.

The method used to start a TCP differs depending upon whether you are using the NCC service or the ADI service for call control:

With this service...	Do this:	What happens:
NCC	Call nccStartProtocol for each B channel CTA context, specifying NOCC in the protname argument.	When nccStartProtocol is called, NCCEVN_STARTPROTOCOL_DONE is returned. If the NOCC TCP is started successfully, the event value field contains CTA_REASON_FINISHED. Otherwise, the value field contains another reason code.
ADI	Call adiStartProtocol for each B channel CTA context, specifying NOCC in the protoname argument.	When adiStartProtocol is called, ADIEVN_STARTPROTOCOL_DONE is returned. If the NOCC TCP is started successfully, the event value field contains ADI_REASON_FINISHED. Otherwise, the value field contains another reason code.

3.6.1 Setting mediamask (AG Quad T/E only)

mediamask is a field in the NCC_ADI_START_PARMS or ADI_CALLCTL_PARMS structure passed in the nccStartProtocol or adiStartProtocol call. It controls which DSP resources are reserved for each DSP function (DTMF detection, echo cancellation, etc.). If you are using an AG Quad T or AG Quad E, you may need to change the setting of mediamask depending upon the setting of the CCMode statement in your configuration file. CCMode defines the call control resource allocation for these boards.

• If CCMode = NONE, no resources are allocated for call processing. In this case, mediamask can be set to a non-zero value, but your application should not open more than 60 ports simultaneously.
  Set CCMode and mediamask this way if your application requires heavy use of DSP resources (i.e. for interactive voice response or another such task).

• If CCMode is set to HIGH, MEDIUM, or LOW, resources are allocated for call processing. In this case, mediamask must be set to zero. 120 ports then become available. Note, however, that only up to 60 ports can simultaneously use DSP resources.
  Set CCMode and mediamask this way if your application primarily performs switching (i.e. does not require heavy use of DSP resources).

If CCMode is set to HIGH, MEDIUM, or LOW and mediamask is non-zero, when nccStartProtocol or adiStartProtocol is called, an xxxEVN_START_PROTOCOL_DONE event is returned with the value field set to xxxERR_NOT_ENOUGH_ RESOURCES.

3.7 Stopping an ISDN Protocol Stack Instance

To stop an ISDN protocol stack instance, call isdnStopProtocol from within the application. This shuts down the ISDN protocol stack instance, and releases all on-board resources and buffers formerly used by the stack instance.

The ISDNEVN_STOP_PROTOCOL event contains the completion status of the stop request. If the stack instance stopped successfully, the value field in this event will contain SUCCESS. Otherwise, another reason code will appear here.

For more information about isdnStopProtocol, see Chapter 7.