8.4. Programming Considerations - BRI/SC Only

• 8.4.1. BRI/SC Configuration
• 8.4.2. BRI/SC Terminal Initialization
• 8.4.3. BRI/SC Tone Generation Configuration

This section provides the following information, which pertains only to BRI/SC protocols:

• BRI/SC Configuration
• BRI/SC Terminal Initialization
• BRI/SC Tone Generation Configuration

8.4.1. BRI/SC Configuration

Unlike the PRI firmware, the BRI firmware requires the application to first configure the desired protocol and features via the cc_SetDChanCfg( ) function. This is necessary for BRI/SC protocols as there is only one BRI firmware file containing multiple protocols and the firmware needs to know which protocol is to be configured. The protocol also needs to know whether the station is to be configured as a Network side or User side station.

NOTE:

North American protocols often require TE devices configured as the User side to transmit a Service Profile Identifier (SPID), which is then acknowledged by the switch. The SPID is programmed using the cc_SetDChanCfg( ) function. See Section 8.4.2. BRI/SC Terminal Initialization below for more information.

After the firmware is downloaded to the board, each station that requires D channel signaling must be configured individually using the cc_SetDChanCfg( ) function. For example, to configure 16 stations, 16 cc_SetDChanCfg( ) operations must be performed, with each operation specifying the appropriate station ID (for example, "briS1" to "briS16").

The D channel of each line can be configured at any time and as many times as needed. This includes changing between Network and User sides as well as changing protocols, SPIDs, and other attributes, such as tone generation (see Section 8.4.3. BRI/SC Tone Generation Configuration below). If calls are active at the time of reconfiguration, the application will receive CCEV_DISCONNECTED events for any calls that existed when the cc_SetDChanCfg( ) function was issued. Those calls are disconnected by the application through normal call tear-down procedures. All data links are then severed and reconnected (some configurations do not require reconnection).

NOTE:

The SPID, directory number, and subaddress of a User-side line can be changed at any time without reconfiguring the channel. See the cc_SetParmEx( ) function description in Chapter 5. ISDN Function Reference for more information.

It is recommended that the cc_SetDChanCfg( ) operations be performed by a separate system configuration task and not as part of a call processing task or thread.

8.4.2. BRI/SC Terminal Initialization

The BRI North American protocols may require terminal initialization settings prior to establishing any layer 3 connectivity. Dialogic API support for terminal initialization consists of the cc_SetDChanCfg( ), cc_SetParmEx( ) and cc_TermRegisterResponse( ) functions, and the following events:

• CCEV_TERM_REGISTER
• CCEV_RCVTERMREG_ACK
• CCEV_RCVTERMREG_NACK

North American protocols often require TE devices to be fully initializing. This means that the Service Profile Identifier (SPID) must be transmitted and acknowledged by the switch. For the User side, the SPID is programmed in the D channel configuration using cc_SetDChanCfg( ). When the SPID is accepted or rejected by the switch, the application receives either a CCEV_RCVTERMREG_ACK or a CCEV_RCVTERMREG_NACK, respectively.

NOTE:

When attaching to a real switch, the SPID must be requested from the switch operator before a connection is attempted.

For the Network side, the application is notified of a TE registration request via the CCEV_TERM_REGISTER board level event. The application must respond to the event using the cc_TermRegisterResponse( ) function on the board level device to fully initialize the terminal.

Refer to the function descriptions for cc_TermRegisterResponse( ) and cc_SetDChanCfg( ) for more information on terminal initialization. Also see the Call Scenarios in Appendix A for the sequence of messages and events required for BRI terminal initialization.

8.4.3. BRI/SC Tone Generation Configuration

Tones can be generated and played on any B channel with the use of the BRI/SC board's on-board DSP chip. In-band tones can be activated either by the host application and/or the firmware. This allows the application to combine in-band call progress-related information with the out-of-band signaling information.

The firmware applies tones only to stations configured as the Network side. The firmware must be configured by the host application to apply the call progress tones as well as to which PCM to use.

Under a Network configuration, and when enabled, the firmware automatically generates a dial tone when a SETUP message is received from a user and more digits are required. A ringback tone is generated when the network sends an ALERT message. After a call is connected, no other tones are generated.

The cc_SetDChanCfg( ) function is used to configure the firmware tone control. In addition, the application can change the values in the firmware tone template table (see Table 29. Tone Template Table) using the cc_ToneRedefine( ) function. To apply user-defined tones (that is, tones other than those in the firmware tone template table), the application uses the cc_PlayTone( ) and cc_StopTone( ) functions. For information on these functions, see the function descriptions in Chapter 5. ISDN Function Reference.

Click here to contact Dialogic Customer Engineering