7.1 Introduction

7.2 QDIMGR

7.3 Using the NCC Service

7.3.1 Using the Loop Start Signaling Protocol

LPS0 Capability Mask

Release Guard

Call Transfer on Loop Start Lines

7.4 Using the ADI Service

7.4.1 Unsupported ADI Functions

7.4.2 Supported ADI Vocoders

Monitoring Signaling Bits

Playing and Recording While Not Connected

7.5 Using the Local Phone and Audio Interfaces

7.6 Determining DSP Resources

7.7 Automatically Repeated Call Attempts

7.1 Introduction

This chapter describes specifics on using the Natural Access NCC and ADI services with QX hardware.

7.2 QDIMGR

QDIMGR is the service manager for the ADI and NCC services when used with QX 2000 boards. You specify the service and service manager names when initializing Natural Access, creating event queues, and opening services.

Figure 25. QDI Service Manager

7.3 Using the NCC Service

The QX 2000 board uses the NCC service component of Natural Access to perform call control. Therefore, a call control program for a QX 2000 board is the same as a call control program for an AG board. See Appendix F for some differences when migrating from AG boards to QX boards. See the Natural Call Control Service Developer's Reference Manual for details about the NCC service.

WARNING:

Automatically Repeated Call Attempts For certain countries, your application must maintain control of calls internally generated by the equipment. Failing to implement this requirement will void the regulatory approval granted to NMS for this NMS equipment. See Section 7.7 for the requirements for each country.

7.3.1 Using the Loop Start Signaling Protocol

The Natural MicroSystems loop start protocol (LPS0) is intended for use with analog interfaces. The analog variations act like a telephone terminal, connected to a local switch or PBX through a local loop. These variations run on the NMS QX 2000 and AG 2000 analog line interface boards.

LPS0 Capability Mask

When using the NCC service, an application can call nccQueryCapability to determine the capabilities of a protocol. nccQueryCapability returns a capabilitymask.

The capabilitymask of the analog loop start protocol is: 0x00020071

The following table shows which capabilities the capabilitymask has indicated as supported by the LPS0 protocol:

Capability	Support
NCC_CAP_AUTOMATIC_TRANSFER	Yes
NCC_CAP_ACCEPT_CALL	Yes
NCC_CAP_MEDIA_IN_SETUP	Yes
NCC_CAP_HOLD_CALL	Yes
NCC_CAP_HELD_IN_ANY_STATE	No
NCC_CAP_SUPERVISED_TRANSFER	Yes
NCC_CAP_DISCONNECT_IN_ANY_STATE	Yes
NCC_CAP_SET_BILLING	Yes
NCC_CAP_CALLER_ID	Yes
NCC_CAP_EXTENDED_CALL_STATUS	No
NCC_CAP_OVERLAPPED_SENDING	No
NCC_CAP_SEND_CALL_MESSAGE	No
NCC_CAP_SEND_LINE_MESSAGE	No
NCC_CAP_CAPABILITY_UPDATES	No

The following sections describe operations that are specific to the loop start protocol within the framework of Natural Call Control.

Release Guard

If a call is placed immediately after releasing a call, the line is not taken off-hook until sufficient time has elapsed to ensure that the COs consider the line idle after the previous call. The release guard is controlled by the NCC.X.ADI_LPS.releaseguardtime parameter.

Note: The QX LPS0 protocol queues a command to place a call during the above situation and proceeds with dialing when the release guard time expires.

Call Transfer on Loop Start Lines

Call transfer operations use mostly the same parameters as outbound call placement operations. These parameters are stored in the NCC_PLACECALL_PARMS and NCC_CALLPROG_PARMS structures. For more details about the parameters stored in these structures, refer to the Natural Call Control Service Developer's Reference Manual.

Additional parameters you can specify with the loop start protocol are prefix dial strings for transfer and reconnect. These are specified by modifying the NCC.X.ADI_LPS.connstring or NCC.X.ADI_LPS.xferstring parameters.

If an attempt is made to transfer a call and transfer is enabled while in the Connected state (NCC.X.ADI_LPS.xfersupport = 1), the LPS0 protocol executes the commands contained in the string specified by the xferstring parameter before dialing the called address that was passed to nccTransferCall.

7.4 Using the ADI Service

The QX 2000 board uses the ADI service component of Natural Access mainly to perform media functions. Therefore, a media program performing voice play and record is the same as a media program for an AG board. See Appendix F for some differences when migrating from AG boards to QX boards. Refer to the ADI Service Developer's Manual for details about the ADI service.

Note: Call control features are now managed by the Natural Call Control service. Refer to the Natural Call Control Service Developer's Reference Manual for more information about the NCC service.

7.4.1 Unsupported ADI Functions

The ADI Service Function Reference Manual is a detailed reference to all ADI service functions. The QX boards support all ADI service functions except the following:

Unsupported ADI Function	Description
adiAcceptIncomingAddress	Presents an incoming call without waiting for all digits.
adiGetEEPromData	Reads the on-board OEM data for the board.
adiGetTimeStamp	Converts an event timestamp to a count of the seconds elapsed since January 1, 1970.
adiModifyPlaySpeed	Sets the play speed.
adiSetBilling	Sets billing information relative to an incoming call.
adiSetExtendedArgs	Sets new arguments for the call control function that immediately follows it.
adiStartReceivingFSK1	Receives Frequency Shift Key (FSK) data.
adiStartSendingFSK1	Initiates sending FSK data.
adiStopReceivingFSK1	Stops receiving FSK data.
adiStopSendingFSK1	Stops sending FSK data.

1 Not supported on QX 2000/80-4L. Supported on QX 2000/100-4L.

If an unsupported ADI function is called in a QX 2000-based application, the error CTAERR_FUNCTION_NOT_AVAIL is returned.

See Appendix B for details about ADI service parameters and the specific defaults and allowed values for QX 2000 boards.

7.4.2 Supported ADI Vocoders

The QX boards support the following ADI vocoders:

ADI_ENCODE_ALAW	ADI_ENCODE_G726_16
ADI_ENCODE_G726_24	ADI_ENCODE_G726_32
ADI_ENCODE_G726_40	ADI_ENCODE_IMA_24
ADI_ENCODE_IMA_32	ADI_ENCODE_MULAW
ADI_ENCODE_NMS_16	ADI_ENCODE_NMS_24
ADI_ENCODE_NMS_32	ADI_ENCODE_NMS_64
ADI_ENCODE_OKI_24	ADI_ENCODE_OKI_32
ADI_ENCODE_PCM8M16	ADI_ENCODE_PCM11M8
ADI_ENCODE_PCM11M16	ADI_ENCODE_VOX_32

These vocoders are downloaded at board initialization.

Monitoring Signaling Bits

To monitor the signaling bits in loop start protocol:

1. Open a Natural Access context on a QX port.

2. Run the NOCC protocol with nccStartProtocol.

3. Enable bit detection with adiStartSignalDetector.

4. Exit the NOCC protocol with nccStopProtocol.

5. Run the LPS protocol with nccStartProtocol.

Depending on the mask value passed as an argument to adiStartSignalDetector, every change of the A bit or B bit status will be returned to the application.

Playing and Recording While Not Connected

You do not need to be in the call connected state to use media functions such as play and record. To play and record in a non-connected state:

1. Open a Natural Access context on a QX port.

2. Run the protocol with nccStartProtocol.

3. Run adiStartPlaying or adiStartRecording.

7.5 Using the Local Phone and Audio Interfaces

The local phone or audio interface can be used either for monitoring or as external audio source for messages recording or playing. To address these I/O ports, switching functions must be used.

For more information, refer to the QX 2000/100-4L MVIP-95 switch model shown in Figure 19.

For an example of the functionality of these interfaces, run ctatest (with the -A QDIMGR option) and select the commands OP and SP to open a Natural Access context and run the NOCC protocol. In another session, run the utility program swish and enter any of the following commands:

To...	Enter the command...
Open a switching context	SWISH: openswitch qx=qxsw 0
Record a message from the local phone	SWISH: makeconnection qx local:8:0 to local:5:0
Listen to a message on the local phone	SWISH: makeconnection qx local:4:0 to local:9:0
Record a message from the microphone	SWISH: makeconnection qx local:12:0 to local:5:0
Listen to a message on the headphone	SWISH: makeconnection qx local:4:0 to local:13:0
Close the context and exit	SWISH: closeswitch qx SWISH: exit

WARNING:

When modifying switching connections for recording, you must re-establish the default connection settings.

7.6 Determining DSP Resources

The QX 2000 board has one DSP which executes functions for detecting and generating voice and telephony signals for the four ports. Most ADI function calls implicitly use the functions which run on the DSP.

The speed of the DSP is measured in millions of instructions per second (MIPS). The QX 2000/100-4L board has 100 MIPS available. The QX 2000/80-4L board has 80 MIPS available. Each function which is run on a DSP consumes MIPS. If the total MIPS consumption for all the requested functions on all the ports of the board exceed the total MIPS available, then an error will occur.

The overhead for the DSP operating system is 5.7 MIPS. The following table shows the MIPS usage per port for the available functions:

Function	Reception	Emission
Automatic gain control	1.0	0.4
Echo cancellation	5.1
Tone detection	2.7
Tone generation		2.1
DTMF detection	1.2
DTMF generation		1.3
WAVE downsampling	1.3
WAVE upsampling		1.3
G.726 32 Kbit/s ADPCM	5.3	5.3
A-law/ mu-law to linear	0.3	0.2
Vox ADPCM	2.5	2.5
NMS framed PCM64 Kbit/s	0.7	0.2
NMS 32 Kbit/s ADPCM	3.6	3.4
NMS 24 Kbit/s ADPCM	3.6	3.4
NMS 16 Kbit/s ADPCM	3.6	3.4
FSK generation		2.3
FSK detection	5.1
OKI 6 kHz	1.9	1.9
OKI 8 kHz	1.8	1.8
IMA/DVI ADPCM 6 kHz	2.0	2.0
IMA DVI ADPCM 8 kHz	1.9	1.9

To determine the total number of MIPS required by your application:

1. Determine the MIPS required by each function.

2. Multiply the number of ports supported.

3. Add the DSP operating system overhead.

For example, running Voice play and DTMF detection on each port requires:

5.7 + 4 x ( 3.6 + 1.2 ) = 24.9 MIPS.

If an application requires functions which exceed the number of available MIPS for the QX 2000 board, reduce the number of ports available to the application.

7.7 Automatically Repeated Call Attempts

For certain countries, your application must also control calls internally generated by the equipment. Failure to implement this regulatory requirement will void the regulatory approval granted to NMS for this NMS equipment. The requirements for each country are listed here.

Country	Maximum Number of Call Attempts	Minimum Interval (sec) Between Numbers	Minimum Interval (mn) to Wait for a New Series
EU countries	15	5	-
Australia1	3	-	30
Bulgaria	12	2	60
Czech-Rep	12	5, then 60	-
Israel	15	30	-
Japan2	3 in 3 minutes 15	- 5	3 -
Korea	3	30	-
Malaysia	2	120	-
New Zealand3	5	60	-
Singapore	10	60	-
Slovakia	12	60	-
South Africa	0	60	-
Taiwan	2	60	-

1 Australia: For equipment with a service tone detector, a maximum number of 10 is allowed. The Call Attempt Series parameters apply to the Equipment without distinction between wrong number and ineffective call. Maximum intervals between numbers is 12 minutes. 2 Japan: There is a choice between the 2 requirements. 3 New Zealand: Not more than 5 call attempts to the same number are allowed within a 60 minute period with a minimum of 60 seconds between attempts, and a total of 10 call attempts to the same number.