3.1 Introduction

3.2 Initializing the Application

3.3 Making Switch Connections for NMS ISDN

3.4 Initializing Natural Access

3.4.1 Specifying B Channel CTA Contexts

3.4.2 Specifying Dummy D Channel CTA Contexts

3.5 Setting Up D Channels

3.5.1 Network Access Identifiers (NAIs)

3.5.2 Initializing an NMS ISDN Protocol Stack Instance Initializing A Stack Instance Using the NMS ISDN Daemon 44

Initializing A Stack Instance Using isdnStartProtocol 45

3.6 Starting ISDN TCP Instances

3.6.1 Loading Parameters

3.6.2 Starting a TCP on a CTA Context

3.7 Stopping an ISDN Protocol Stack Instance

3.1 Introduction

This chapter:

• Explains how an NMS ISDN application performs ISDN initialization tasks.

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

• Shows how to initialize Natural Access, and how to 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 a TCP on each B channel context, loading parameters for each one (if necessary).

3.2 Initializing the Application

An NMS ISDN application performs the following initialization tasks for each trunk or NFAS group:

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 switching is not enabled. For more information, see Section 3.3, Making Switch Connections for NMS ISDN.
   
   
   Figure 6. Routing Channel Data to On-Board Resources

2. The application initializes Natural Access, and creates a separate context for each B channel on the trunk or NFAS group that it will interact with. For more information, see Section 3.4, Initializing Natural Access.
   The application must also create a separate dummy context for the
   D channel. This context is used only to refer to the stack instance on the channel with other NMS ISDN library functions (such as isdnStopProtocol). Signaling from a D channel is not accessed through this context; instead, the channelizer in the protocol stack routes the signaling for each B channel to the context for that B channel.
   
   
   Figure 7. Creating CTA Contexts for Channels

3. The application initializes an ISDN protocol stack instance on the D channel context, using the isdnStartProtocol function from the NMS ISDN library. This function starts up an ISDN protocol stack instance on the dummy context in Channelized stack mode. In the function invocation, the trunk is specified using its network access identifier (NAI) and NFAS group number (for duplicate NAI values). For more information, see Section 3.5, Setting Up D Channels and Appendix .
   Note: Duplicate NAI values are not supported prior to Natural Access 4.0.
   
   Figure 8. Calling isdnStartProtocol

4. The application starts a TCP on each B channel context, loading country-specific parameters for each one (if necessary). For more information, see Section 3.6, Starting ISDN TCP Instances.
   
   
   Figure 9. Starting TCPs on B channel Contexts

3.3 Making Switch Connections for NMS ISDN

To allow an application access to ISDN channels, several CT bus switch connections must be made. In your configuration file, if Clocking.HBus.ClockMode=STANDALONE (or EnableMVIP=NO for agmon), these settings are automatically made when the board boots. However, if Clocking.HBus.ClockMode=MASTER_A, MASTER_B, or SLAVE (or EnableMVIP=YES for agmon), the application must make these settings, using the Natural Access 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, Setting Up D Channels.)

• 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 Clocking.HBus.ClockMode keyword is set to be a master (MASTER_A or MASTER_B) or slave (SLAVE). Specifically, if Clocking.HBus.ClockMode=STANDALONE, no connections are made between the HDLC controller and signaling streams. This setting is for trunks which are included in NFAS groups. (For more information about these keywords and about NFAS, see the NMS 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	Clocking.HBus.ClockMode= STANDALONE	Clocking.HBus.ClockMode= MASTER_A, MASTER_B, OR SLAVE
Four trunk T1 board (for example, 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 (for example, 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, Clocking.HBus.ClockMode is set to STANDALONE only for trunks included in NFAS groups. NFAS is not supported on E1 trunks, so you would probably not use this configuration.
AG two trunk T1 board (for example, AG Dual T)	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
AG two trunk E1 board (for example, AG Dual E)	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, Clocking.HBus.ClockMode is set to STANDALONE only for trunks included in NFAS groups. NFAS is not supported on E1 trunks, so you would probably not use this configuration.
AG 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
AG 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, Clocking.HBus.ClockMode is set to STANDALONE only for trunks included in NFAS groups. NFAS is not supported on E1 trunks, so you would probably not use this configuration.

The isdncta demonstration program (documented in Chapter 7) illustrates how an application makes these connections.

3.4 Initializing Natural Access

To begin call control operations, the application:

1. Initializes Natural 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 context and returns a context handle.

4. Opens services on the CTA contexts using ctaOpenServices.
   Note: If D channel backup is defined in your configuration, Natural Access must not be initialized on the context bearing the backup D channel. See
   Appendix B for more information.

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

3.4.1 Specifying B Channel CTA Contexts

Create a separate context for each B channel on each trunk or NFAS group that your application will interact with. To open CTA contexts under Natural 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 (not supported in Natural Access 4.0)	MVIP 95: Local stream 4 MVIP 90: stream 18
  All other 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 the modes involving signaling defined in the ADI documentation, since ISDN signaling is not carried in the B channels.

Under Natural Access, set these values in the CTA_MVIP_ADDR structure passed to ctaOpenServices.

3.4.2 Specifying Dummy D Channel CTA Contexts

Create a separate dummy context for each D channel on each trunk or NFAS group that your application will interact with. The context for a D channel is used only to refer to the stack instance on the channel in other NMS ISDN library function calls (such as isdnStopProtocol). Signaling from a D channel is not accessed through the dummy context; instead, the channelizer in the protocol stack routes the signaling for each B channel to the context for that B channel.

The following table shows how the number of trunks on a board is related to the number of D channels available.

Boards with...	Can support up to...
Four trunks	4 separate D channels.
Two trunks	2 separate D channels.
One trunk	1 D channel (not supported by Natural Access 4.0 and later).

To open dummy contexts under Natural 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 Natural Access, set these values in the CTA_MVIP_ADDR structure passed to ctaOpenServices.

3.5 Setting Up D Channels

Initialize an ISDN protocol stack instance on each D channel context, using isdnStartProtocol from the NMS ISDN library. This function starts up an ISDN protocol stack instance on the dummy context in Channelized stack mode.

Note: If D channel backup is defined in your configuration, Natural Access must not be initialized on the context bearing the backup D channel. See
Appendix B for more information.

3.5.1 Network Access Identifiers (NAIs)

A trunk is referred to by a numerical value, called a network access identifier (NAI). All NAIs for a given board are defined in the configuration file. NAI values are used as Interface Identifier values inside ISDN Q.931 messages sent across the network. When you initialize an ISDN protocol stack instance for a context (using isdnStartProtocol), you specify the NAI of the trunk to associate with the context. From then on, the application can communicate with the D channel on that trunk via the context handle. For example, when an event is received, the context handle indicates the trunk on which the event occurred.

In most configurations, NAIs are unique for each trunk, so the NAI value can be used to refer to a specific trunk on a particular board.

Some variants support duplicate NAI values, where NAIs are not unique across NFAS groups or the board. For these configurations, the application must provide both the NAI and NFAS group number to refer to a trunk when calling isdnStartProtocol.

Different board types support different numbers of D channels, with different NAIs.

The table below shows what each board type supports:

Digital Trunk Interface Board Type	Number of D Channels	NAIs	Number of NFAS groups
Four-trunk boards	Up to 4	0 through 3	Up to 4
Two-trunk boards	Up to 2	0 through 1	Up to 2
One-trunk boards	1	0	0

The NAI and NFAS group number of a trunk are specified in the configuration file. For more information about this file, see the NMS ISDN Installation Manual.

3.5.2 Initializing an NMS ISDN Protocol Stack Instance

To initialize an NMS ISDN protocol stack instance on a context:

• Run the ISDN daemon, or

• Invoke isdnStartProtocol in an application program.

  
   Initializing A Stack Instance Using the NMS ISDN Daemon
  
  

To initialize an ISDN protocol stack instance, you can run the isdncta daemon supplied with the NMS ISDN software. This daemon starts the ISDN protocol stack, and also makes the switch connections needed to support NMS ISDN (see Section 3.3, Making Switch Connections for NMS ISDN).When an ISDN protocol stack instance is initialized using the daemon, applications which use the standard Natural Access call control API will operate with the ISDN TCP in the same way they would operate with any other TCP.

The daemon initializes an ISDN protocol stack instance by calling isdnStartProtocol. On the command-line, indicate the NAI to use and, if multiple CCID is configured, the NFAS group number for this NAI. To learn how to launch isdncta, see Section 7.3, ISDN Daemon: isdncta.

Initializing A Stack Instance Using isdnStartProtocol

To initialize an ISDN protocol stack instance from within your application, call the isdnStartProtocol function in the ISDN library.

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

To direct isdnStartProtocol to initialize a stack instance in Channelized stack mode, set the protocol, partner_equip, and parms arguments as follows:

Argument	Set to...
protocol	ISDN_PROTOCOL_CHANNELIZED
partner_equip	The type of equipment connected to the board. Set to: · EQUIPMENT_NT, if the board is connected to network equipment · EQUIPMENT_TE, if the board is acting as network equipment
parms	Pointer to a parameter structure to configure the stack. If the application needs to change any of the parameters for Natural Call Control, it should pass the structure name ISDN_PROTOCOL_PARMS_CHANNELIZED in this call. This structure is identical to the ISDN_PROTOCOL_PARMS_ Q931CC structure.1 (See the NMS ISDN Messaging API Developer's Reference Manual for more information on NMS ISDN parameters.) If the application will not need to change parameters, pass NULL to accept the default settings. The default parameters for the Channelized stack mode enable the required service access points (SAPIs).
n	Where n is an unsigned integer representing the NFAS group number, used for duplicate NAI values only. Note: Multiple CCID must be enabled by setting enable_Multiple_CCID to 1 in parms.

The behavior bits that govern the stack's automatic responses (such as CC_SEND_CALL_PROC_RQ) must not be modified in Channelized configuration. The only exceptions to this rule are the behavior bits governing overlapped sending/receiving (see Section 4.8).

Three other bits in the ISDN_PROTOCOL_PARMS_CHANNELIZED structure are also important when calling isdnStartProtocol to initialize the ISDN stack:

Structure Member	Action
NS_EXPLICIT_INTERFACE_ID	Setting this bit forces the interface identifier value to be sent in output call control messages (SETUP, PROCEEDING, etc.). Applies to the USA variants.
NS_SEND_USER_CONNECT_ACK	Setting this bit forces a CONNECT_ACK message to be sent by the TE side upon receipt of a CONNECT message. Applies to the ETSI and Europe variants.
NS_PRESERVE_EXT_BIT_IN_CHAN_ID	This bit is only applicable when the variant is DMS, USA, or incoming call. If set, the channel ID's octet 3.3's extension bit is set to the value received in a SETUP message inside the PROCEEDING or ALERT messages.

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

For more information about isdnStartProtocol, see the NMS ISDN Messaging API Developer's Reference Manual.

3.6 Starting ISDN TCP Instances

When all ISDN protocol stack instances have been created, the application starts an ISDN TCP instance for each B channel context. To start a TCP instance:

1. The Natural Access Parameter Management Service loads the NMS ISDN TCP parameters and default values.

2. The application modifies the values, if necessary.

3. The application calls nccStartProtocol (NCC service)
   or adiStartProtocol (ADI service) to start the TCP instance.

3.6.1 Loading Parameters

When you install NMS ISDN software, parameter files are installed. The parameters in these files configure the TCP.

Some parameters determine the amplitude, frequency, length and pattern of the busy tone, ring tone and reorder tone. Since the tones differ from country to country, these parameters are country-specific, and should not be modified. Other parameters determine the service to request when placing an outbound call, the mode the TCP runs in, the channel direction, and the signal sending mask. These parameters can be modified to suit your application.

The parameter files relevant to your application differ depending upon whether you are using the NCC Service or the ADI Service for call control. To learn more about loading and changing parameters, see Appendix A.

3.6.2 Starting a TCP on a CTA Context

Once a context is opened and the TCP parameters are loaded, the application starts a TCP on that context using the loaded parameters. Once a TCP has started on a context, the application can use call control functions to place and answer calls on that context.

Note: To start a TCP from within an application, the TCP must have been downloaded to the board at system initialization time. The oamsys program downloads all TCPs specified in the configuration file, oamsys.cfg. For more information about the configuration file, see the NMS ISDN Installation Manual and the NMS OAM System User's Manual.
(For versions prior to Natural Access 4.0, this function is performed by the agmon program using the ag.cfg configuration file. For more information about agmon, see the AG Runtime Configuration and Developer's Manual.)

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

• Under the NCC service, nccStartProtocol starts a TCP on a context. For NMS ISDN call control, protname passed to nccStartProtocol should be isd0. protstartparms should be NULL, so the default TCP parameters (loaded as described in Appendix A) are used.
  When nccStartProtocol is called, NCCEVN_STARTPROTOCOL_DONE is returned. If the TCP is started successfully, the event value field contains CTA_REASON_FINISHED. Otherwise, the value field contains another reason code.

• Under the ADI service, adiStartProtocol starts a TCP on a context. For NMS ISDN call control, protoname passed to adiStartProtocol should be isd0. protoparms should be NULL, so the default TCP parameters (loaded as described in Appendix A) are used.
  When adiStartProtocol is called, ADIEVN_STARTPROTOCOL_DONE is returned. If the TCP is started successfully, the event value field contains ADI_REASON_FINISHED. Otherwise, the value field contains another reason code.
  Note: If your application terminates, all channels associated with the application are terminated, all TCP instances are shut down, and an idle pattern is broadcast on all B channels.

3.7 Stopping an ISDN Protocol Stack Instance

To stop an ISDN protocol stack instance:

• Stop the ISDN daemon, if it is running, or

• Call isdnStopProtocol from within the application that called isdnStartProtocol.

Either method 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 contains SUCCESS. Otherwise, another reason code appears here.

For more information about isdnStopProtocol, see the NMS ISDN Messaging API Developer's Reference Manual.