Table of Contents

Inpulse Rules

Beginning Inpulse Rule Processing
Ending Inpulse Rule Processing
Reports Produced by Inpulse Rule Processing

Outpulse Rules

Beginning Outpulse Rule Processing
Ending Outpulse Rule Processing
Reports Produced by Outpulse Rule Processing

Recursive (Looping) Rules
Null Outpulse Rule
Answer Supervision Templates

Inpulse and Outpulse Rules

Processing a call on a system network interface circuit requires a number of signaling and supervision actions. These actions are often common among many call types and are performed in the same sequence. After you have defined these sequences, the system stores them and uses them as needed in the form of inpulse and outpulse rules.

Define inpulse and outpulse rules through the system Data Base Administration Menu (refer to the Cisco VCO/4K System Administrator's Guide). Actions are represented by tokens; you can use up to 16 tokens in each inpulse and outpulse rule you define.

Rules can be "called" like subroutines in a command or, in the case of inpulse rules, executed by default when an incoming port seizes inward. Because rule processing takes place on the system, the amount of processing overhead for the host computer and the communications links is decreased.

This section presents a summary of inpulse and outpulse rules, focusing on the interaction between rules and the system command/report set. Detailed information on defining and using rules is contained in the Cisco VCO/4K System Administrator's Guide.

Inpulse Rules

An inpulse rule consists of up to 16 tokens. The tokens can be used to condition a trunk to wait for supervision events, collect MF, DTMF, or Dial Pulse (DP) digits, and store received digit fields in an internal system call record. You can define up to 30 inpulse rules.

The system can execute inpulse rules for any line or trunk, regardless of its class of service (COS). An inpulse rule can also specify to execute an outpulse rule. When the outpulse rule has been completed, the original inpulse rule processing continues.

Inpulse rule tokens available in the basic system software are listed in Table 2-1. Available system tones are listed in "Tone Values" (use the decimal values with inpulse rules). The column [xx] indicates if additional data is required to complete a token. Additional tokens for optional system software (TeleRouter, ISDN and ISDN with NFAS) packages are detailed in the documentation that accompanies those options. For a more detailed description of each of the inpulse rules, refer to the Cisco VCO/4K System Administrator's Guide.

Inpulse rule tokens are functionally divided into six groups:

• Reporting Control—Determines when change of state and address signaling for an incoming port are reported to the host.
  
  
• Signaling Mode—Indicates incoming digits for collection are either MF, DTMF, or DP.
  
  
• Digit Collection Setup—Defines the conditions for digit collection.
  
  
• Digit Collection—Enables the appropriate receiver (as indicated by the Signaling Mode token) and specifies the digit field in which digits are stored.
  
  
• Supervision Control—Presents in-band or out-of-band signaling to the distant end (i.e., answer, wink, tone, voice prompt) or waits a specified length of time before continuing rule processing.
  
  
• Processing Control—Allows construction of rules with more than 16 tokens for processing outpulse rules.
  
  
• Prompt/Record Control—Prompt and record control for the IPRC.
  
  

Beginning Inpulse Rule Processing

Inpulse rule processing can begin in one of the following ways:

• Ordered by a host command—An inpulse rule can be started by the host with an Outgoing Port Control ($69) or Incoming Port Control ($6A) command. The port for which the rule is specified must be off hook. Refer to "System Commands," for more information.
  
  
• Started by an autonomous event—An inpulse rule can be specified as the default rule for an incoming port. When an off hook (seize) is detected on a port with a default rule, inpulse rule processing begins.
  
  
• Started by an outpulse rule DO IRULE token—An inpulse rule can be started by a DO IRULE token in an outpulse rule.
  
  

Ending Inpulse Rule Processing

Inpulse rule processing ends normally when all instructions in the rule (or rules if GOTO RULE or DO IRULE/ORULE tokens are used) have been executed. Processing is aborted in the following cases:

• Ordered by host command—A resource control command is received that specifies the port involved in inpulse rule processing as the controlling port.
  
  
• Aborted by error condition—An MF/DTMF receiver or voice port was not available when required by rule processing, garbled MF digits were received or an MF timer expired, an outpulse channel or CPA port was not available (outpulse rule processing via DO ORULE token), or DTMF/DP timer expired (no CONT REP or CONT NREP token in rule).
  
  

Reports Produced by Inpulse Rule Processing

The following reports are produced by inpulse rule processing:

• MF Digit ($D0)—Contains any MF digits collected for a single digit field. Multiple $D0 reports can be produced by a single inpulse rule. This report shows if digit collection was successful; if unsuccessful, provides reason for failure. The report is produced if a digit collection token is preceded by a REP NEXT token or a REP EACH token has been processed in the rule.
  
  
• DTMF Digit ($D1)—Contains any DTMF or DP digits collected for a single digit field. Multiple $D1 reports can be produced by a single inpulse rule. This report shows if digit collection was successful; if unsuccessful, provides reason for failure and any digits correctly received up to that point. The report is produced if a digit collection token is preceded by a REP NEXT token or a REP EACH token has been processed in the rule, or a digit timer expired and CONT REP was used in collection setup.
  
  
• Resource Limitation ($D6)—Indicates an MF/DTMF receiver or IPRC port was not available when required for rule processing.
  
  
• Incoming Port Change of State ($DB)—Indicates the incoming port identified in the report has gone off hook. Report produced if a REP EACH token has been processed in the rule.
  
  
• Inpulse Rule Complete ($DD)—Indicates rule processing has ended for the port identified in the report. This report is a macro report that can contain MF Digit, DTMF Digit, and Incoming Port Change of State report segments. Content is based on the Reporting Control token used. If no Reporting Control token is used, this report contains all reports produced by the rule and not already reported.
  
  
• Voice Port Status ($DE)—Indicates that all voice prompts specified in a Voice Port Control ($6C) command have completed. This report is produced if a REP EACH token has been processed in the rule.
  
  

Outpulse Rules

An outpulse rule is a listing of tokens defined by an application designer or system administrator. You can use up to 16 tokens to condition a trunk to wait for supervision events, and outpulse MF/DTMF digits. Up to 30 outpulse rules can be defined.

Outpulse rules can be executed for any line or trunk in the system, regardless of its class of service (COS). An outpulse rule can also specify to execute an inpulse rule as part of outpulse rule processing; when the inpulse rule has been completed, the original outpulse rule processing continues.

Available outpulse rule tokens and available system tones are listed in Table 2-2 and Table 2-3. The column [xx] indicates if additional data is required to complete a token. Additional tokens for optional system software (TeleRouter, ISDN, and ISDN with NFAS software packages) are detailed in the documentation that accompanies those options.

Outpulse rule tokens are functionally divided into the following groups:

• Reporting control—Notifies the host of supervision events detected on an outgoing or incoming port.
  
  

Reporting for individual signaling events specified by WAIT SUP is controlled by either an intermediate answer supervision template, if preceded by an ANS SUP [xx] token, or controlled by an ISDN supervision template, if preceded by an ISDN SUP [xx] token.

Reporting for individual signaling events specified by FINAL SUP is controlled by either a final answer supervision template, if preceded by an ANS SUP [xx] token, or controlled by an ISDN supervision template, if preceded by an ISDN SUP [xx] token.

• Signaling Mode—Determines the type of outpulse signaling used; DTMF, MF, or TONE mode with OP DIGIT.
  
  
• Supervision Control—Conditions the port to detect and respond to answer supervision events before continuing with rule processing. Indicates which configurable answer supervision template or preconfigured template to use for supervision.
  
  
• Digit Field—Determines when and what digits or tones are outpulsed.
  
  
• Processing Control—Allows construction of rules with more than 16 tokens for processing an inpulse rule.
  
  

Beginning Outpulse Rule Processing

Outpulse rule processing can begin in one of the following ways:

• Ordered by host command—An outpulse rule can be started by the host using an Outgoing Port Control ($69) or an Incoming Port Control ($6A) command with an Outgoing Port Control segment. Refer to "System Commands," for more information.
  
  
• Started by an inpulse rule DO ORULE token—An outpulse rule can be started by a DO ORULE token in an inpulse rule.
  
  

Ending Outpulse Rule Processing

Outpulse rule processing ends normally when all instructions in the rule (or rules if GOTO RULE or DO IRULE/ORULE tokens are used) have been executed. Processing is aborted when a supervision or resource allocation error occurs.

Reports Produced by Outpulse Rule Processing

The following reports can be produced by outpulse rule processing:

• Outgoing Port Change of State ($DA)—In MF and DTMF processing, this report indicates the answer supervision template that was executed, and the individual supervision events detected. The report is generated only if a WAIT SUP [xx] or FINAL SUP [xx] supervision control token is used in the rule. If REP END token is used, a $DA report is produced to indicate outpulse rule processing has completed.
  
  

In MFCR2 processing, the $DA report includes the backward signaling codes. When REP NEXT is used in the outpulse rule template, the final backward supervision signaling code is reported to the host in the report.

• Incoming Port Change of State ($DB)—Indicates the answer supervision template executed, and the individual supervision events detected. The report is generated only if a WAIT SUP [xx] or FINAL SUP [xx] supervision control token is used in the rule. If a REP END token is used, a $DB report is produced to indicate outpulse rule processing has completed.
  
  

Recursive (Looping) Rules

You can use processing control tokens to create recursive rules, or rules for which processing eventually returns to the original rule. To create these "looping" rules use the DO IRULE, DO ORULE, and GOTO RULE tokens and continue until one of the following conditions occurs:

• An external event, such as a host command or a port on hook, is detected.
  
  
• Forty tokens are processed without any of the following tokens being encountered:
  
  
• Inpulse rule tokens—IP ANI, IP FIELD, WAIT TIME, SPEAK.
  
  
• Outpulse rule tokens—WAIT SUP [xx], FINAL SUP [xx], TIME SUP [xx], WAIT TIME, OP DIGIT, OP ANI, OP FIELD.
  
  

Looping allows single digit collection in inpulse rules, such as that employed when a user is prompted (by a Voice Response Unit or similar peripheral equipment) to answer questions by pressing a button on their phone. The inpulse rule below could be used for that purpose.

Null Outpulse Rule

In addition to user-defined outpulse rules, a predefined Null Outpulse Rule (rule 0) exists in the VCO/4K system software. This rule is not accessible by system administration and cannot be altered. The Null Outpulse Rule is defined as shown below:

The rule performs an outward seizure, starts a 30-second grace timer and waits for final answer. When the Null rule is specified in an Outgoing Port Control ($69) command executed for an outgoing port, the port is considered answered if either true answer is detected or the grace timer expires.

Answer Supervision Templates

Supervision processing is performed by a combination of supervision control outpulse rule tokens and answer supervision templates. The outpulse rule tokens WAIT SUP [xx] and FINAL SUP [xx] are used for intermediate supervision and final supervision, respectively. During outpulse rule processing, these tokens "call" specific answer supervision templates like subroutines. The templates indicate which signaling events must be detected and the system response to each event. When an event is detected, the system response specified in the template is performed; the supervision control outpulse rule token is satisfied and rule processing continues.

Call progress tone events detected during template processing include:

• Dial
  
  
• Busy
  
  
• Fast Busy (Reorder)
  
  
• Special Information Tone (SIT)
  
  
• Audible Ringback
  
  
• Ringback Cessation
  
  
• Presence of Voice
  
  
• Voice Cessation
  
  
• Pager Cue
  
  

Answer supervision templates accessed via system administration allow users to specify system actions for particular signaling events. Signaling events include the events listed above, plus wink, true answer, supervision timing and hook flash. Condition tokens assigned to each type of signaling event determine system action when these events are detected. Preconfigured templates corresponding to the outpulse rule tokens WAIT SUP A, WAIT SUP W and FINAL SUP A exist for simple wink and answer supervision scenarios. Refer to the Cisco VCO/4K System Administrator's Guide for more information on answer supervision templates.

Posted: Sat Sep 28 14:32:51 PDT 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.