|
|
System processing of ISDN D-channel messages generally follows the International Telecommunications Union guidelines documented in ITU-T Q.931. This chapter provides an overview of system D-channel message processing, and how it relates to the use of inpulse rules, outpulse rules, and templates. This discussion begins with a look at how ISDN D-channel messages are used to establish and clear a simple call.
D-channel messages establish and manage ISDN calls in much the same way supervision signals and call progress tones handle non-ISDN calls. Actions such as seizing a circuit or going on-hook are represented by D-channel messages such as SETUP and DISCONNECT. Figure 3-1 shows the D-channel messages used to establish and clear a simple ISDN call.
Most D-channel messages include additional information needed for call processing, such as the calling party number, called party number, and channel ID. These data, referred to as information elements (IEs), varies depending on the message, action being performed, and connected equipment. Mandatory and optional IEs for D-channel messages are defined in ITU-T Q.931.
Other D-channel messages are part of the standard ISDN message set. These messages allow complete control over call establishment and clearing, network maintenance, and the passing of other call-related information between switches.
The ICC card supports several ISDN protocols. The NI-2, AT&T 4ESS, AT&T 5ESS, and NTI protocol implementation supports both user-side and user-side symmetrical modes. The EURO, NTT, and TS014 protocol implementation supports user-side and network-side modes. The system also supports the symmetrical form of European ISDN, which is called the QSIG protocol.
The system constructs and interprets ISDN D-channel messages by using a combination of inpulse and outpulse rules, ISDN message templates, ISDN supervision templates, host commands, and host reports. Each has a specific purpose in system ISDN call processing, as follows:
Table 3-1 lists the standard ISDN messages as defined in the International Telecommunications Union document ITU-T Q.931.
The following sections define each of these messages and the system processing associated with them. In general, the following processing rules apply:
The call clearing ISDN D-channel messages are described below.
The DISCONNECT message clears a connection. The expected response to a DISCONNECT is RELEASE. The processing of the DISCONNECT is affected by the setting of the Enable ISDN Manual Disconnect feature flag and the enabling or suppression of the ISDN Port Change of State ($EA) report.
The enabling or suppression of the $EA reports is controlled by disconnect control bits (D/R bits) in byte offsets 29 and 30 (disconnect control) of the ISDN Port Control ($49) command that established the call.
The setting of the D/R bits of the $49 command determines how the system processes transmitted DISCONNECT messages. The $49 command should include additional and/or customized cause values and any other IEs that need to be included in the message. Although you can use the ISDN TX token and ISDN transmit message templates to transmit DISCONNECT messages, use of the control options in the $49 command is more efficient and consistent with the use of the DISCONNECT message.
The DISCONNECT ISDN D-channel message processing, with the Enable ISDN Manual Disconnect feature flag settings and $EA report enabled or suppressed, is summarized in Table 3-2.
Table 3-2 DISCONNECT ISDN D-channel Message Processing with the Enable ISDN Manual Disconnect Feature Flag and $EA Report Enabled/Suppressed
With the Enable ISDN Manual Disconnect system feature enabled, two timing associated results are possible, dependent upon the reported DISCONNECT message. A received DISCONNECT message starts timer T305 by default. A received DISCONNECT message that also has a progress indicator IE descriptor of 8, starts timer T306.
The T305 timer scenario is the default. The system reports a DISCONNECT message to the host via an ISDN Port Change of State ($EA) report, and the RELEASE message is not triggered until an ISDN Port Control ($49) command is received by the system from the host, or until a 4-second timer (T305) expires.
The T306 timer scenario acts in the following manner: The system reports the DISCONNECT message with a progress indicator IE descriptor of 8—in-band information or appropriate pattern is now available—to the host via an $EA report. The RELEASE message is not triggered until a $49 command is received by the system from the host, or until a fixed 60-second timer (T306) expires.
Timer T306 is used when the network wishes to provide in-band tones and announcements when disconnecting the call. The T306 timer is implemented on ICC T1-PRI/NTT, ICC E1-PRI/EURO, and ICC E1-PRI/TS014 protocols.
Refer to the Cisco VCO/4K System Administrator's Guide for further information on the Enable ISDN Manual Disconnect feature flag.
Refer to the Cisco VCO/4K Extended Programming Reference for further information on command and report functions.
The RELEASE message clears a connection. There are three conditions that can cause a RELEASE message, referred to as condition 1, condition 2, and condition 3.
The system processes the RELEASE automatically. All RELEASE IEs are reported to the host and a RELEASE COMPLETE message is returned. Note that the ISDN TX token and ISDN transmit message template can also be used to transmit a RELEASE.
The system sends a RELEASE message with a cause IE of Normal Clearing to the ICC ISDN span. If the state of the port on the span is Processing Received SETUP, the system sends an ISDN Port Change of State ($EA) report to the host. The report contains an event code of Release Complete with a status code of No Error. Note that the processing of this condition sets the ICC ISDN span port to idle.
The system sends a RELEASE COMPLETE message with a cause IE of Preempted to the ICC ISDN span. The system also sends an ISDN Port Change Of State ($EA) report to the host. The report contains an event code of Release Complete with a status code of Glare. Note that the processing of this condition sets the ICC ISDN span port to idle.
Refer to the "System Host Configuration" section for further information on the Host Setup Timer. Refer to the "ISDN Outpulse Rule Processing" section for further information on the GLARE and NOHOST tokens.
The expected response to a RELEASE is RELEASE COMPLETE.
The RELEASE COMPLETE message acknowledges receipt of a RELEASE message and is the final step in clearing a connection. No response is expected.
System processing of received RELEASE COMPLETE is automatic. All RELEASE COMPLETE IEs are reported to the host. RELEASE COMPLETE is transmitted automatically in response to a received RELEASE message.
The RESTART message requests a restart (set to idle) for the D-channel, or individual B-channel, specified. Response to a successful request is the RESTART ACKNOWLEDGE message.
System processing of received RESTART is automatic. RESTART transmission is not supported.
For a D-channel RESTART message, a System Card Status ($D9) report is generated indicating the ICC ISDN span has been reset. When this processing has completed, a RESTART ACKNOWLEDGE is returned.
For a B-channel RESTART message, the call on that channel is cleared and the port is set to idle. All RESTART IEs and the RESTART event are reported to the host in an ISDN Port Change of State ($EA) report. When this processing has completed, a RESTART ACKNOWLEDGE is returned.
The RESTART ACKNOWLEDGE message indicates that a previous RESTART has been performed.
The host automatically transmits a RESTART ACKNOWLEDGE message in response to a received RESTART message, as described in the "RESTART" section.
This section describes the call establishment ISDN D-channel messages.
The ALERTING message indicates that called-user alerting has been initiated.
The ISDN RX token and ISDN receive message templates control how the system processes received ALERTING messages. The ISDN TX token and ISDN transmit message and supervision templates determine how ALERTING messages are transmitted.
The CALL PROCEEDING message indicates that the call establishment requested by a SETUP message has been accepted and that no further call establishment messages will be accepted.
The ISDN RX token and ISDN receive message templates control how the system processes received CALL PROCEEDING messages. The ISDN TX token and ISDN transmit message and supervision templates determine how CALL PROCEEDING messages are transmitted.
The CONNECT message indicates the call has been accepted and should be connected.
The system automatically processes received CONNECT messages either inside or outside of rule processing. The system makes B-channel connection and returns a CONNECT ACKNOWLEDGE message. In interworking cases, the B-channel is not connected on the far end until the CONNECT has been processed. The ISDN TX token and ISDN transmit message and supervision templates determine how CONNECT messages are transmitted.
The CONNECT ACKNOWLEDGE message indicates that the call connection has been established.
The ISDN RX token and ISDN receive message templates control how the system processes received CONNECT ACKNOWLEDGE messages. The network does not expect a response to this message, therefore, any processing is specific to the application (such as billing, etc.). CONNECT ACKNOWLEDGE is automatically transmitted in response to a received CONNECT message.
The PROGRESS message provides additional information required for call establishment.
The ISDN RX token and ISDN receive message templates control how the system processes received PROGRESS messages. The ISDN TX token and ISDN transmit message and supervision templates determine how PROGRESS messages are transmitted.
The SETUP message initiates call establishment.
When a new call originates, the system generates a D-channel SETUP message. The host constructs a message by the ISDN Port Control ($49) command and an ISDN transmit message template.
When a system receives a SETUP message with acceptable parameters (CHAN ID, CD NUM, BEARER IEs, etc.), the system must generate a CALL PROCEEDING message and send it to the network. The system performs this action autonomously by executing a default inpulse rule containing an ISDN RX and ISDN TX token. The ISDN transmit message template controls the CALL PROCEEDING message creation, and the system informs the host of the SETUP message.
The host can also generate a CALL PROCEEDING message via the $49 command and an ISDN transmit message template, just as it does the SETUP message. In this case, the default inpulse rule only specifies an ISDN RX token for the incoming SETUP message data and the host reporting requirements.
The host can reject a call establishment request; the correct message to accomplish this is a RELEASE COMPLETE with a cause IE of NETWORK CONGESTION. The host initiates the RELEASE COMPLETE message with the $49 command.
This section describes the call information phase ISDN D-channel message.
The USER INFORMATION message transfers information data from one point to another.
The ISDN RX token and ISDN receive message templates control how the system processes received USER INFORMATION messages. The ISDN TX token and ISDN transmit message templates determine how USER INFORMATION messages are transmitted.
The maintenance ISDN D-channel messages are described below.
The SERVICE message is supported in only the 4ESS, 5ESS, and NTI ISDN protocols. This message changes the current status of the channel to in-service, out-of-service, or maintenance. Response to a successful request is the SERVICE ACKNOWLEDGE message.
The system automatically processes received SERVICE messages. The specified channel is placed into the specified state. In the cases of out-of-service and maintenance, the channel is placed into far-end out-of-service or far-end maintenance. The system generates an ISDN Port Change of State ($EA) report to inform the host of the change in status. Received SERVICE messages are processed only for individual channels—the system ignores SERVICE messages which use a slot map to specify multiple channels. Transmission of service messages is performed according to the ISDN protocol's specification. For the 4ESS, 5ESS, and NTI ISDN protocols, the system automatically performs SERVICE transmission as part of channel maintenance. A SERVICE message is sent once an hour for each channel in far-end out-of-service or far-end maintenance. The SERVICE message contains the requested state of the channel as maintained by the system.
The SERVICE ACKNOWLEDGE message indicates that a received SERVICE message has been processed.
The system automatically processes received SERVICE ACKNOWLEDGE messages. No further processing is performed. SERVICE ACKNOWLEDGE transmission is automatic. This message is sent upon successful completion of a SERVICE message.
This section describes the miscellaneous ISDN D-channel messages.
The CONGESTION CONTROL message indicates the establishment or termination of flow control.
The ISDN RX token and ISDN receive message templates determine how the system processes received CONGESTION CONTROL messages. The ISDN TX token and ISDN transmit message templates determine how CONGESTION CONTROL messages are transmitted.
The FACILITY message requests a specific facility or service. The expected response to a FACILITY message is either a FACILITY ACKNOWLEDGE message (facility request accepted) or a FACILITY REJECT message (facility request rejected).
The ISDN RX token and ISDN receive message templates determine how the system processes received FACILITY messages. The ISDN TX token and ISDN transmit message templates determine how FACILITY messages are transmitted.
The FACILITY ACKNOWLEDGE message accepts a FACILITY request.
The ISDN RX token and ISDN receive message and supervision template processing determine how the system processes received FACILITY ACKNOWLEDGE messages. The ISDN TX token and ISDN transmit message templates determine how FACILITY ACKNOWLEDGE messages are transmitted.
The FACILITY REJECT message rejects a FACILITY request.
The ISDN RX token and ISDN receive message and supervision template processing determine how the system processes received FACILITY REJECT messages. The ISDN TX token and ISDN transmit message templates determine how FACILITY REJECT messages are transmitted.
The NOTIFY message conveys information pertaining to a call across the interface.
The NOTIFY message is sent by the called user to the network or by the network to the calling user.
System processing does not currently support REGISTER.
The STATUS message responds to a STATUS ENQUIRY message. The current call state is reported.
The system automatically processes received STATUS messages. STATUS is automatically transmitted in response to a received STATUS ENQUIRY message. No indication of this processing is provided to the host.
The STATUS ENQUIRY message requests a STATUS message from a peer Layer 3 entity. Response to a successful request is STATUS.
The system automatically processes received STATUS ENQUIRY messages. A STATUS message is transmitted; no indication of this processing is provided to the host.
Six combinations of IE storage control tokens and transmission control tokens are used to construct an information element (IE) for use in an outgoing D-channel message. Use the ISDN transmit message template to construct the IE. The combinations and their associated rules are described in Table 3-3.
Table 3-3 Token Combinations which Build Information Elements in Outgoing D-channel
Messages
|
Whenever a D-channel message with a channel ID IE is transmitted, the system automatically populates the channel number within the IE with the channel number being used. D FLD, DATA, and FLD tokens must include this byte.
Host-specified IE content is automatically included in transmit message construction. System processing ensures that the resultant IE ordering is correct.
For ISDN calls, the system primarily uses inpulse rules to process received SETUP messages. This SETUP message processing is analogous to an incoming seizure for a non-ISDN call, and triggers default inpulse rule processing, if defined. Because initial SETUP messages are received over the D-channel and there is no B-channel associated with the call at this point, the system assigns a default inpulse rule to the D-channel (port 24) of the ICC ISDN span. Refer to "System Administration Support," for ICC ISDN span configuration information.
Almost all of the existing inpulse rule tokens are supported for ISDN calls, except the WINK NOW token. Since there is no ISDN equivalent to a wink, this token is ignored.
The reporting control tokens—REP END, REP EACH, REP NEXT, and NO REP—in an inpulse rule govern timing of the ISDN Port Change of State ($EA) report and the ISDN Inpulse Rule Complete ($ED) report. The contents of the ISDN message template being processed determine the content of the reports.
Tokens which control in-band events are not applicable to an ISDN call until a B-channel has been selected. These tokens (signaling, mode, collection setup, digit collection, and some supervision control) are ignored unless an incoming B-channel has been assigned to the call.
The ANSWER token can respond to a SETUP D-channel message. Processing of this token generates a CONNECT message to the network if a B-channel has been selected. This message contains a channel ID IE if it is the initial response to the SETUP message.
ISDN messages can also be transmitted using the ISDN TX [xx] token.
WAIT TIME [xx], GOTO RULE [xx], DO ORULE [xx], and DO IRULE [xx] all retain their functionality for ISDN calls.
All collected digits are considered the equivalent of ISDN message template D FLD action tokens when two specific conditions are met. First, digit collection is in-band. Second, a B-channel has to be established for interworking scenarios in which an inpulse rule is processed for a non-ISDN port. To format these digits using a message template, use a D FLD number (1 through 4, and ANI) which corresponds to the digit field used in the original inpulse rule.
The FLD, I FLD, and D FLD action tokens used in ISDN message templates control digit storage for ISDN D-channel messages only. These tokens are discussed in the "ISDN Message Templates" section.
Refer to the Cisco VCO/4K System Administrator's Guide for further information on inpulse rule tokens.
The ISDN D-channel SETUP message is processed in one of two ways, depending upon whether a default inpulse rule has been defined.
If a default inpulse rule has been defined, the following process describes the SETUP message processing:
1. The default inpulse rule is executed when the system receives an ISDN D-channel SETUP message.
2. The system sends an ISDN Inpulse Rule Complete ($ED) report to the host—unless the rule contains a NO REP token.
3. At the end of rule processing, the Host Setup Timer is started—unless it has been disabled. Refer to the "System Host Configuration" section for further information on the configuration of the Host Setup Timer.
If the host does not respond before the timer expires, one of the following occurs:
If the state of the port on the span is Processing Received SETUP, the system sends an ISDN Change of State ($EA) report to the host. The report contains an event code of Release Complete with a status code of No Error.
Note that the processing of this condition sets the ICC ISDN span port to Idle.
The ISDN message templates handle the ISDN messages in the D-channel that the system does not automatically process. The ISDN RX [xx] token calls these templates.
If no default inpulse rule has been defined, the following describes the SETUP message processing:
1. The system sends an ISDN Port Change of State ($EA) report to the host. The IE content of the SETUP message is included in this report.
2. The Host Setup Timer is started—unless it has been disabled. Refer to the "System Host Configuration" section for further information regarding the configuration of the Host Setup Timer.
3. If the host does not respond before the timer expires, the system sends a RELEASE message with a cause IE of Normal Clearing to the ICC ISDN span.
If the state of the port on the span is Processing Received SETUP, the system sends an ISDN Change of State ($EA) report to the host. The report contains an event code of Release Complete with a status code of No Error.
Note that the processing of this condition sets the ICC ISDN span port to Idle.
For ISDN calls, the system uses outpulse rules in much the same way as for non-ISDN calls. An outpulse rule is started by the ISDN Port Control ($49) command. Information can be passed into the three FLD action tokens used in ISDN message template processing.
 |
Note Use of the null outpulse rule is not supported for ISDN calls. |
Most of the existing outpulse rule tokens are supported for ISDN calls, except the FINAL SUP [xx], SEIZE, and WAIT SUP [xx] tokens. For outgoing ISDN calls, use ISDN SUP [xx] in place of FINAL SUP [xx] and WAIT SUP [xx]. The ISDN transmit message templates provide the ISDN equivalent of a SEIZE.
Tokens which control in-band events are not applicable to an ISDN call until a B-channel has been selected. These signaling mode and digit field tokens are ignored unless an outgoing B-channel has been assigned to the call.
The outpulse rule tokens DO IRULE [xx], DO ORULE [xx], GOTO RULE [xx], REP END, TIME SUP [xx], and WAIT TIME [xx] retain their functionality for ISDN calls.
Digit fields are outpulsed with the standard digit field tokens for in-band digit outpulsing once a B-channel has been established, or for interworking scenarios in which an outpulse rule is processed for a non-ISDN port. Store digit fields collected from an ISDN B-channel as a D FLD for outpulsing. The field number (1 through 4, and ANI) corresponds to the D FLD number. Use the FLD, I FLD, and D FLD action tokens to identify the type of information contained in the field.
The system automatically translates digits, presenting them to the network in the proper format for the interface being used. For example, DTMF digits to be used in a D-channel message are converted to IA5 (ASCII coded digits) for use in the message. Digits collected over a D-channel can also be outpulsed as DTMF or as MF digits.
The ISDN SUP [xx] token allows the application designer to specify how events are handled following the transmission of a D-channel message. Event responses are defined using the ISDN supervision templates.
The ISDN TX [xx] token allows flexible construction of D-channel messages. Internal call record fields (1 through 4, and ANI) can be combined with the content of ISDN transmit message templates and host-specified information, supplied via the $49 command, to generate messages to the network.
ISDN supervision templates and message templates are discussed in "System Administration Support." ISDN commands and reports are described in the Cisco VCO/4K Extended Programming Reference.
Refer to the Cisco VCO/4K System Administrator's Guide for further information on outpulse rule tokens.
ISDN glare occurs if the system initiates an outgoing call on a B-channel at the same time the network initiates an incoming call on that same B-channel. This scenario assumes the system is processing the channel ID IE in the received SETUP message.
When processing a glare condition, the system reacts in one of two ways, depending upon whether or not a default inpulse rule has been defined.
If the port has a default inpulse rule containing a GLARE token, the inpulse rule specified by GLARE is executed.
If the port has a default inpulse rule, but the rule does not contain a GLARE token, the system executes the same process as it does for ports with no default inpulse rule defined.
If the port has no default inpulse rule defined, the system sends a RELEASE COMPLETE message with a cause IE of Preempted to the ICC ISDN span. The system also sends an ISDN Port Change of State ($EA) report to the host. The report contains an event code of Release Complete, with a status code of Glare. Note that the processing of this condition sets the ICC ISDN span port to Idle.
Refer to the "D-channel Message Processing" section for more information on channel ID IE processing.
The following guidelines are intended to assist application designers develop ISDN applications that make the most efficient use of system processing. These are guidelines only, and should not preclude other application design approaches. In some cases, more efficient ISDN processing can mean less efficient host link processing. These guidelines are presented to help you understand how the system processes ISDN calls. The four guidelines are described below.
Specifying IEs in the ISDN Port Control ($49) command requires the system to copy the information into a buffer for use in an outpulse rule. Using an ISDN transmit message template eliminates the need to copy to the buffer.
Allowing the system to assign the B-channel to a call simplifies the internal processing required to track the call. Use PROCESS CHAN ID in response to the SETUP message whenever possible.
When the system reports each D-channel message as it is received, the internal processing required to track and store these messages is simplified.
Specifying a B-channel by call ID in an ISDN Port Control ($49) command requires more internal processing than setting the call ID bytes to $00 00 and supplying the B-channel address. Use call ID only if no B-channel has been assigned to the call.
Posted: Fri Jan 23 12:20:33 PST 2004
All contents are Copyright © 1992--2004 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
