|
|
VCO/4K system administrators control supervision processing by using the VCO/4K master console to configure a combination of supervision control outpulse rule tokens and supervision templates. Outpulse rule tokens invoke either answer (in-band) or ISDN (D-channel signaling) supervision on a port.
Five outpulse rule tokens determine supervision control processing: ANS SUP [xx], ISDN SUP [xx], WAIT SUP, FINAL SUP, and TME SUP [xx].
Outpulse rules containing WAIT SUP and FINAL SUP tokens may cause a call progress analyzer (CPA) port to be allocated to the call chain. If the template specified by the outpulse rule token requires detection of in-band call progress tones, a CPA port is allocated to the call at the beginning of rule processing.
The following sections provide detailed processing information for each supervision control outpulse rule token.
The ISDN SUP [xx] token designates a specific ISDN supervision template for processing ISDN D-channel signaling events. The ISDN SUP [xx] token functions as a setup token for subsequent WAIT SUP or FINAL SUP tokens. When the system encounters this token, call processing stores the number of the ISDN supervision template for later processing. The additional data entry field specifies the supervision template. The value for the additional data entry field can be a number from 1 to 24. The ISDN SUP [xx] token can be used in conjunction with the ANS SUP [xx] token to provide concurrent supervision of both in-band and ISDN signaling events.
The WAIT SUP token invokes intermediate supervision during outpulse rule processing, according to the events in the previously specified template. When this token is executed, outpulse rule processing pauses while answer supervision template processing and/or ISDN supervision template processing begins for the specified templates. If a supervision event is detected that successfully ends template processing (based on template configuration), the WAIT SUP token is satisfied and outpulse rule processing resumes.
If a supervision event is detected that indicates a supervision error or call failure, rule processing is aborted.
The supervision template to be used in WAIT SUP processing is determined by previous ANS SUP [xx] and/or ISDN SUP [xx] tokens. See the "ANS SUP [xx]" section and the "ISDN SUP [xx]" section.
A TIME SUP [xx] token works in conjunction with ANS SUP [xx], ISDN SUP [xx], WAIT SUP, and FINAL SUP tokens to perform grace or supervision timing. This token should immediately precede a WAIT SUP or FINAL SUP token in an outpulse rule. The additional data entry field of the TIME SUP [xx] token specifies the timer's duration (1 to 60) in seconds. The system response to the timer's expiration is indicated by the Answer Supervision or ISDN Supervision Template identified by the accompanying WAIT SUP or FINAL SUP token. If the timer expires during template processing, the system performs the action specified by the condition token in the template's Time event field.
When a TIME SUP [xx] token is executed, a system timer is set. The timer starts when template processing begins. If the timer expires before another supervision event is detected (one that ends rule processing), the system responds to the expiration as indicated by the condition token assigned to the Time event template field. The TIME SUP [xx] token functions as a grace timer when the condition token specified in the Time field is OK, OKREP, ANSBK or ANSREP. The timer expiration can also indicate a call failure or supervision error (FAIL or ERROR condition token in the Time event field).
Each answer supervision template is a set of system responses to the detection of specific supervision events. Supervision events include detection of call progress tones such as dial tone, ringback (detection and cessation), busy tone, reorder, special information tones (SITs), and pager cue tones, and the detection of presence or cessation of voice. Wink, hook flash, and true answer signaling events also fall under the category of supervision events.
Using the templates, system administrators can indicate which supervision events may be detected during call processing. Condition tokens assigned to each event in a template specify the system's response when a particular event is detected. Call processing applies the templates when it waits for intermediate and final supervision. When a supervision event is detected, the system references the template and performs the action specified by the condition token assigned to the event's field. When the system responds to the event, the supervision control outpulse rule token is satisfied and rule processing continues.
Eight condition tokens specify individual system responses (or combinations of responses) to a supervision event. Condition tokens are specified for each signaling event to be detected. Events not assigned condition tokens (set to the IGNORE token) are disregarded during template processing. Events marked with condition tokens that end template processing satisfy a WAIT SUP or FINAL SUP outpulse rule token when detected. Only events marked with a REP condition token fail to end template processing. Processing continues until an event marked with one of the seven other condition tokens is detected or a supervision/grace timer expires (TIME SUP [xx] token in the outpulse rule).
One of eight condition tokens can be assigned to each supervision event in each template. The same condition token can be assigned to as many events as required. For example, in a particular call scenario, the detection of busy tone, reorder tone, and SITs may indicate a call failure. A FAIL token can be assigned to the event field for all three of these call progress tones.
Condition tokens are discussed below in functional order. Combination tokens such as OKREP and ANSREP are paired with the tokens OK and ANSBK, respectively. Each subsection describes the token's affect on template processing and report generation, and provides general usage guidelines.
Supervision events marked with REP tokens are reported to the host when detected but do not end template processing. An Outgoing Port Change of State ($DA) or Incoming Port Change of State ($DB) report is generated containing one of two Change byte codes (10 or 80) and the appropriate Answer Supervision code for the event. Template processing continues until an event marked with another type of condition token is detected. REP tokens function the same for both intermediate and final supervision.
Events assigned REP tokens can be used to inform the host of a call's progress without interfering with outpulse rule processing. For example, REP tokens can signal the host when to begin billing for services such as voice mail. REP tokens are also useful in experimental answer supervision templates to determine the supervision events that may be encountered in a particular call scenario and the order in which they occur.
Supervision events marked with OK tokens end template processing when detected but are not reported to the host. When the event is detected during intermediate supervision, the WAIT SUP outpulse rule token is satisfied and rule processing continues. When the event is detected during final supervision (after an outpulse rule containing a FINAL SUP setup token), template processing ends. However, the port is only considered answered if the OK token was assigned to the Answer event field.
Events assigned OK tokens require detection for outpulse rule processing to continue, but do not need to be reported to the host (reducing host link traffic). This condition token is commonly assigned to events such as dial tone in intermediate supervision templates (called by a WAIT SUP outpulse rule token). The event must be detected before outpulsing digits, for example.
Events assigned OKREP tokens are handled similarly to OK tokens, but also generate a report to the host.
Supervision events marked with ANSBK tokens end template processing when detected and cause the system to answer back over the incoming port (assuming it has not already been answered). No report is sent to the host when the event occurs. When the event is detected and answerback sent, a WAIT SUP outpulse rule token is satisfied and rule processing continues. Because the outgoing port is considered answered when answerback is sent, the call automatically goes to stable state when outpulse rule processing completes (unless a FINAL SUP token is specified).
Events assigned ANSBK tokens may serve as both intermediate and final supervision. When ANSBK tokens are used in a template called by a WAIT SUP outpulse rule token, a FINAL SUP token is not necessary (assuming the WAIT SUP can only be satisfied by an event assigned ANSBK or ANSREP). ANSBK tokens can be assigned to the Time event field for grace timing during supervision processing. Because answerback signals initiate billing during network calls, ANSBK tokens should be assigned carefully.
Events assigned ANSREP tokens are handled similarly to ANSBK tokens, but also generate a report to the host.
Specifies that the signaling event should be treated as a supervision error and causes a rehunt for another outgoing port if the outgoing resource group is configured for rehunting. The error count for the outgoing port is incremented, and an Outgoing Port Change of State ($DA) report is generated indicating a supervision error and status of rehunt. Template processing ends and the outpulse rule is aborted. The incoming port is left in CP_SETUP state if no rehunt is performed. If a rehunt is performed successfully, outpulse rule processing starts again on the new outgoing port.
 |
Note The rehunt threshold assigned to the outgoing resource group may affect call processing if multiple supervision errors are detected during a call attempt. If the number of supervision errors exceeds the rehunt threshold, the system considers the call attempt as failed (call failures are discussed in the "FAIL" section). Rehunt thresholds are set via the Smart Console. |
ERROR events should be assigned to supervision events that are unexpected during supervision processing but are not fatal. For example, assigning an ERROR token to Reorder tone manages situations where the system encounters a bad trunk circuit. If the outgoing resource group is configured for rehunting, another trunk circuit is selected and the call continues without host intervention.
Specifies that the signaling event indicates a failed call. The outgoing port is removed from the call (no rehunt performed) and the incoming port is left in setup. An Outgoing Port Change of State ($DA) report is generated indicating a failed call attempt. Template processing ends when the event is detected and the outpulse rule is aborted. FAIL events indicate that the call cannot be completed regardless of whether another outgoing port is selected. FAIL tokens are frequently assigned to busy tone, SITs (identifying an invalid dialed number or a number that requires a 1 for long-distance service, for example) and supervision timing (ring/no answer.)
Specifies that the signaling event causes outpulse rule processing to abort. Template processing ends, and the outgoing port returns to the state it was in prior to outpulse rule processing (CP_IDLE, CP_ATT, CP_SETUP or CP_STAB) but is not removed from the call. An Outgoing Port Change of State ($DA) report is generated, indicating an outpulse rule failure. The QUIT condition can occur any time during outpulse rule processing, even after the port is considered answered. QUIT tokens are similar to FAIL tokens, but differ in that the call retains the outgoing port when the token is processed. These tokens are designed especially for use in conjunction with supervision timers that begin after a call becomes stable.
In addition to the 24 configurable templates, three preconfigured templates exist for simple wink and answer supervision scenarios that do not require call progress tone detection. When used with WAIT SUP tokens, these templates wait for wink and true answer (respectively) during intermediate supervision. When used with a FINAL SUP outpulse rule token, the true answer template waits for true answer during final supervision. The supervision events and system responses for the three templates are shown in Table 5-1.
| Outpulse Rule Token | Event | Condition Token |
|---|---|---|
ANS SUP W / WAIT SUP | Wink | OK |
Answer | ERROR | |
Time | ERROR | |
ANS SUP A / WAIT SUP | Wink | ERROR |
Answer | ANSBK | |
Time | ERROR | |
ANS SUP A / FINAL SUP | Wink | ERROR |
Answer | ANSREP | |
Time | ANSREP |
ANS SUP W is satisfied when a wink signal is detected, and treats the detection of true answer or the expiration of the supervision timer as supervision errors. ANS SUP A sends answerback when true answer is detected and treats the detection of a wink or the timer expiration as supervision errors. Both of the preconfigured templates require a specific supervision event for rule processing to continue. The ANS SUP A / FINAL SUP combination, however, reacts to either the detection of true answer or the expiration of a grace timer by sending answerback over the incoming port. A wink detected during this template processing indicates a supervision error.
Preconfigured templates are not displayed and cannot be changed or deleted by system administration. The other eight signaling events (dial tone, ringback, etc.) are not detected when a preconfigured template is used. No CPA is required to process these templates. A TIME SUP [xx] token must precede a preconfigured outpulse rule token in the rule for the timer expiration response (condition token in the Time event field) to be performed.
Event reporting during answer supervision template processing is controlled by the condition token assigned to the event. Events marked with REP, OKREP, ANSREP, ERROR, FAIL and QUIT tokens generate host reports when detected. No reports are produced when events marked with OK or ANSBK are detected. Supervision processing information is distributed over four bytes in the Outgoing Port Change of State ($DA) and Incoming Port Change of State ($DB) reports. For more information on system commands and reports, refer to the Cisco VCO/4K Extended Programming Reference.
ISDN Supervision Templates are used to define a set of system responses to the detection of specific ISDN messages, such as ALERTING, CONNECT, PROGRESS, and CALL PROC (call proceeding).
ISDN calls are not marked stable when a template is executed unless the template has been designed for this purpose. The receipt of a CONNECT message causes the state of the port to go stable.
After the end of an outpulse rule and before receipt of a CONNECT message, the system reports all received D-channel messages to the host as supervision outside an outpulse rule (change byte = $08) in an ISDN Port Change of State ($EA) report. When the system receives an ISDN CONNECT message, the call is considered answered and changes to stable. The ISDN CONNECT message is also propagated back to the incoming port if the incoming port is not considered answered.
Ten condition tokens specify individual system responses, and combinations of responses, to a signaling event. Condition tokens also use the detection of the event as an indicator of error conditions and failed calls. Condition tokens are defined for each signaling event; events are disregarded when no token is defined for the event.
Indicates that an event was detected during processing of the ISDN SUP [xx] outpulse rule token. The event is not reported to the host when it occurs. When the event is detected, the ISDN SUP [xx] token is satisfied and template processing ends. Outpulse rule processing continues with the token following the ISDN SUP [xx] until the rule completes or the call goes to stable state.
Indicates that an event was detected during processing of the ISDN SUP [xx] outpulse rule token. An ISDN Port Change of State ($EA) report to the host is generated. When the event is detected, the ISDN SUP [xx] outpulse rule token is satisfied and template processing ends. Outpulse rule processing continues with the token following the ISDN SUP [xx] token until the rule completes or the call goes to stable state.
Valid only for the CONNECT event. Indicates that a CONNECT event was detected during processing of the ISDN SUP [xx] outpulse rule token and that answerback was sent to the incoming port (assuming it has not already been answered). The event is not reported to the host when it occurs. When the event is detected and answerback sent, the ISDN SUP [xx] outpulse rule token is satisfied and template processing ends. Outpulse rule processing continues with the token following the ISDN SUP [xx] token until the rule completes or the call goes to stable state. Because the outgoing port is considered answered when answer back is sent, the call automatically goes to stable state when outpulse rule processing completes. For ISDN-to-ISDN calls, answerback takes the form of a CONNECT event message generated for the incoming call. Use of this token provides the correct answer supervision of non-ISDN incoming calls.
Valid only for the CONNECT event. Indicates that the system detected a CONNECT event during processing of the ISDN SUP [xx] outpulse rule token and sent answerback to the incoming port (assuming it has not already been answered).
The system generates an ISDN Port Change of State ($EA) report to the host. When the event is detected and answerback sent, the ISDN SUP [xx] outpulse rule token is satisfied and template processing ends. Outpulse rule processing continues with the token following the ISDN SUP [xx] token until the rule completes, or the call goes to stable state. Because the outgoing port is considered answered when answerback is sent, the call automatically goes to stable state when outpulse rule processing completes. For ISDN-to-ISDN calls, answerback takes the form of a CONNECT event message generated for the incoming call.
Use of this token provides the correct answer supervision for non-ISDN incoming calls.
Indicates that an event will be reported to the host when detected. An ISDN Port Change of State ($EA) report is generated containing the event indicator. Events marked with REP condition tokens do not satisfy an ISDN SUP [xx] outpulse rule token; template processing continues until an event marked with another type of condition token is detected.
Indicates that a signaling event has detected a failed call. The event is not considered a supervision error. The outgoing port is removed from the call and the incoming port is left in setup. The system generates an ISDN Port Change of State ($EA) report, indicating a failed call attempt. Template processing ends when the event is detected and the outpulse rule is aborted.
Used to indicate that an event caused outpulse rule processing to abort. Template processing ends and the outgoing port returns to the state it was in prior to outpulse rule processing, but is not removed from the call. An ISDN Port Change of State ($EA) report is generated, indicating an outpulse rule failure. The QUIT condition token event can occur at any time during outpulse rule processing, even after the port is considered answered.
This section provides general usage guidelines and suggestions for designing answer supervision templates. These guidelines supply a basic approach for designing new supervision templates. Once an initial set of templates is created, you can easily modify templates to meet changing application requirements.
Before designing answer supervision templates, you should first determine the supervision requirements of their application. These requirements are defined by the following:
Other considerations may also influence template design. You can use flowchart and reference table techniques in the early development stages. Flowcharts identify the sequence of supervision signals the system must generate and detect in specific call scenarios. Reference tables can be applied to resource tracking to indicate the network interfaces, service circuits, and other resources involved in a call scenario. Designers can compare the resources against the supervision signaling sequence to determine if the resource's generation and detection capabilities correctly match the signaling requirements.
For each call scenario, supervision events can be functionally grouped into three general categories:
You should first assign condition tokens to expected supervision events, signals that normally occur during a successful call attempt. The detection of an expected event allows call processing to continue, or in the case of final supervision, to create a stable call. Expected events may also trigger billing for the call. Two condition tokens, OK and ANSBK, control autonomous system processing of expected supervision events.
OK tokens are best used in conjunction with intermediate supervision processing. When an event marked with an OK token is detected, supervision processing completes and call processing continues. No signaling is generated and the event is not reported to the host. OK tokens should be assigned to events that indicate an intermediate step in the completion of the call, such as detecting a wink or dial tone before outpulsing digits. OK tokens may also be used for final supervision. In a template used for final supervision, if an OK token is assigned to true answer, supervision processing ends and the system establishes a stable call.
ANSBK tokens should be applied to templates used for final supervision processing. When assigned to true answer, ANSBK tokens can propagate answer supervision back to the near end service providers which often start billing the calling party when the near-end CO detects answerback. The detection of any supervision event, however, can generate answerback. By assigning ANSBK to Voice and ignoring true answer, for example, answerback is sent only when the far end goes off hook and voice is heard. You should consider two key factors before assigning ANSBK tokens:
When an ANSBK token is assigned to the Time (timer expiration) field, the system performs grace timing on the outgoing port.
The detection of expected supervision events can also cause host action. REP, OKREP and ANSREP condition tokens generate reports, alerting the host of the supervision event detected and the system's response to the event. The host can either react to these reports by issuing additional commands affecting call processing or by simply recording this information for billing or tracking purposes. OKREP and ANSREP tokens perform the same actions as OK and ANSBK (respectively) while also producing a host report. REP tokens by themselves do not affect call processing, although the host may alter call handling based on their reports.
During the early stages of template design, you may assign REP tokens to various supervision events in a template and then apply the template to many experimental call scenarios. This test approach identifies possible occurrences of supervision events and also allows developers to test the report parsing functions of their host application.
The information contained in reports can allow the host to effectively direct the system when exception conditions occur. For example, assume the system detects a set of supervision events out of their expected sequence. The system may simply report the events without being aware that an error or exception condition has occurred. The host, however, can be programmed to anticipate the events in their proper order. When the host receives a report for an unexpected event, it can immediately identify the exception condition and issue commands to manage the situation. By placing this intelligence into their host, you can implement effective exception handling in their applications.
Two tokens, ERROR and FAIL, manage supervision error and call failure conditions. QUIT tokens control supervision processing when exception conditions occur.
ERROR tokens indicate that an error in the outgoing facility is preventing normal call processing. The system, however, can recover from this condition and normal processing can continue. ERROR tokens should be used for error cases that indicate problems with the specific line or trunk being used. For example, the detection of reorder tone may indicate a malfunctioning circuit. In this situation, an ERROR token assigned to reorder causes the system to abort the rule, rehunt another outgoing port (if the resource group is configured for rehunting) and retry outpulse rule and supervision processing on another circuit in order to complete the call. When assigned to the time (timer expiration) event, ERROR tokens control supervision error timing. ERROR tokens are useful in both intermediate and final supervision templates.
FAIL tokens manage more critical errors, applying to situations when call processing simply cannot complete. Unlike ERROR tokens, FAIL tokens do not cause a rehunt for another outgoing port. The most common assignment for FAIL tokens is busy tone processing when the call attempt fails because the far end is already engaged in another connection. Special Information Tones (SITs), indicating network conditions causing call failures, are also candidates for a FAIL token. These tones can indicate incorrect or invalid calling numbers, among other conditions. FAIL tokens used with supervision timers can limit the period the system waits for expected supervision events. For example, instead of waiting indefinitely for true answer, the system declares a call failure if the far end does not go off-hook within a specified period. FAIL tokens apply equally well to both intermediate and final supervision templates processing.
Event fields without specific action requirements use the IGNORE token. These fields represent one of two cases:
Certain supervision events may occur during a call scenario without affecting call processing or providing significant information. Likewise, event fields for signals with no likelihood of occurring should also be set to IGNORE.
To optimize CPA processing performance, do not assign condition tokens to supervision events that will not occur during call processing, or those that do not affect call handling in any way. For example, assigning REP tokens to all template fields (other than for debugging or test purposes), including fields for events that will not occur or are insignificant, creates unnecessary host report processing overhead, lessens CPA efficiency, and can cause a CPA resource to be unnecessarily allocated to the call.
This section describes a simple call processing scenario. During call processing, an outpulse rule containing supervision control tokens for both intermediate supervision and final supervision is executed. This outpulse rule tokens and parameters are as follows:
At the start of rule processing, the system allocates an outpulse channel and a CPA port to the call's resource chain. When the WAIT SUP token is executed, the system compares signaling events detected by the CPA against the answer supervision template specified in the preceding ANS SUP [xx] token, in this case template #1 (see Table 5-2).
According to template #1, the expected intermediate supervision event is dial tone. When the CPA detects dial tone, the WAIT SUP token is satisfied and outpulse rule processing continues with the OP DTMF token. If busy, reorder or SIT tones are detected, the call is marked as a failed attempt and the outpulse rule is aborted. The detection of wink or true answer indicates a supervision error. The outpulse rule is aborted and a rehunt begins if the outgoing resource group is configured for rehunting. The detection of any other signaling events (ringback, voice, etc.) has no effect on call processing. No supervision timing is performed.
Assuming dial tone was detected, outpulse rule processing continues. The DTMF digits stored in digit field 1 are outpulsed (refer to the outpulse rule tokens and parameters listed above), and outpulse rule processing ends. The TIME SUP 30 token starts a 30-second grace timer when the FINAL SUP token is executed. Final supervision events are compared against answer supervision template #2 (see Table 5-3).
Template #2 supports a ring/no answer scenario with grace timing. If ringback is detected during the wait for final supervision, it is reported to the host but the FINAL SUP token is not satisfied. If busy tone or SIT tones are detected, the call is marked as a failed attempt and the outpulse rule is aborted. The detection of reorder tone or a wink indicates a supervision error; the outpulse rule is aborted and a rehunt begins if the outgoing resource group is configured for rehunting.
If ringback cessation or true answer is detected, the event is reported to the host and answerback is sent over the incoming port and the FINAL SUP token is satisfied. If the 30-second supervision timer expires before any other signaling events are detected, the port is answered back, a report is sent to the host, and the ports are set to stable state. Dial tone, voice detection/cessation, hook flash, and pager cue tone detection have no effect on call processing when answer supervision template #2 is used.
| Template Field | Condition Token |
|---|---|
Dial Tone | OK |
Ring Back | IGNORE |
Busy | FAIL |
Reorder | FAIL |
SIT Tones | FAIL |
Ring Cess. | IGNORE |
Voice Det. | IGNORE |
Voice Cess. | IGNORE |
Wink | ERR |
Answer | ERR |
Time | IGNORE |
Hookflash | IGNORE |
Pager Cue | IGNORE |
ISUP Tone | IGNORE |
ISUP Cess. | IGNORE |
| Template Field | Condition Token |
|---|---|
Dial Tone | OK |
Ring Back | REP |
Busy | FAIL |
Reorder | ERR |
SIT Tones | FAIL |
Ring Cess. | ANSREP |
Voice Det. | IGNORE |
Voice Cess. | IGNORE |
Wink | ERR |
Answer | ANSREP |
Time | ANSREP |
Hookflash | IGNORE |
Pager Cue | IGNORE |
ISUP Tone | IGNORE |
ISUP Cess. | IGNORE |
Posted: Sat Sep 28 14:42:56 PDT 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.