|
|
Call supervision signals relate to the on-hook and off-hook status of a port and its associated line or trunk. On-hook means that the connected equipment is idle; off-hook indicates that the connected equipment is active. When equipment at one end of a network arrangement goes off-hook, this state change is conveyed over lines/trunks to the far-end connected equipment in the form of a seizure. When an inward seizure into the system is detected, call processing normally directs the system to seize an outgoing port and attempts to a create a logical connection between the two ports.
During supervision processing, the system may briefly change the port's on-hook/off-hook status (creating either a wink or hook flash) to signal the connected equipment. When the outgoing port becomes active (off-hook), the incoming port is considered answered and a stable call is established. Supervision timers may interact with call supervision signals during supervision processing. When the equipment at either end goes on-hook, disconnect processing occurs and the call is torn down throughout the network.
This section describes the following signals: seizure, wink/hook flash, answer, and disconnect.
Seizures are signals between connected equipment requesting service, and are the first step in establishing a stable call. In the circuit-switched network, a series of seizures creates a signaling path between network components, allowing supervision signaling to and from the parties at either end. In terms of system applications, seizures involve physical state changes in the line/trunk circuit between a system and connected equipment. The nature of this state change depends on the circuit type. For example, seizing a T1 port establishes a data signaling path. Seize effects for each line/trunk type are discussed in the "Network Interface Port Supervision Capabilities" section.
Figure 3-1 shows a seizure state change.
Inward seizures occur when connected equipment goes off-hook. Outward seizures are performed during outpulse rule processing via a SEIZE token. Normally, the host issues an Outgoing Port Control ($69) command that either hunts an outgoing port from a resource group or selects it by port address. This $69 command also calls an outpulse rule which contains a SEIZE token. The outgoing port is seized when this token is processed. Once a port is seized, it cannot be allocated to another call until it is released by call disconnect or Permanent Signal processing. Depending on resource group and physical configurations, line/trunk circuits are susceptible to "glare" conditions. Glare occurs in cases of simultaneous seizures, when an incoming line seizes in on the same port that the system seizes outward. When glare is detected, host reports are generated indicating a glare condition (refer to the "Supervision Event Reporting" section for supervision reporting information).
In the network, wink signals are normally used in conjunction with address signaling. A wink may indicate that the distant end is ready to receive autopsied address digits or as a positive acknowledgment that all address digits were received. During call processing, the system can generate a wink on an incoming port to request digits, or it can wait to detect a wink before outpulsing digits on an outgoing port.
A wink is a brief off-hook/on-hook signal on an unanswered (on- hook) circuit as shown in Figure 3-2. Because winks are generally associated with digit collection and outpulsing prior to final answer, wink generation/detection normally takes place during intermediate supervision.
Hook flash signals are similar to winks, but occur after a port is physically answered (off-hook). A hook flash indicates a change in the status of the call (depending on the application) and consists of a brief on-hook/off-hook signal (as shown in Figure 3-3).
The nature and duration of these signals varies between line/trunk types. General wink and hook flash generation and detection capabilities for the T1 card type are shown in Table 3-1. Wink and hook flash characteristics for T1 card I/O modules are provided in the "Network Interface Port Supervision Capabilities" section.
| Card Type | Wink | Hook Flash | ||
|---|---|---|---|---|
| Generate | Detect | Generate | Detect | |
T1 | Yes | Yes | Yes | No |
Answer supervision indicates when connected equipment has become active and a two-way signaling/voice path exists. In general network scenarios, answer supervision is passed backward (from the far end to the near end) to indicate that the called party has answered and to start billing. At the system level, when the system detects answer supervision on an outgoing port, it establishes a stable call between the incoming and outgoing ports. The system can also answer an incoming call before connecting the incoming and outgoing ports.
The system can both detect and generate answer supervision. The system detects answer supervision in the form of either out-of-band or in-band signaling. True answer occurs when the far end goes off-hook and is indicated by out-of-band signaling. Answer supervision template processing allows detection of other supervision events (such as in-band call progress tones) to determine when a port is considered answered. Refer to "Answer Supervision Template Processing," for more information.
Generating answer supervision over the incoming port is known as answerback. Answerback is passed back through the public network until it reaches the local CO (LEC) for the calling party. When the CO equipment detects answerback, it begins billing the subscriber for a completed call. (Billing considerations are discussed in "Answer Supervision Template Processing.") The system controls answerback signaling using inpulse rules and answer supervision templates. Sending answerback using an ANSWER inpulse rule token is discussed in the "Answerback" section. Refer to the "Answer Supervision Template Processing" section for information on sending answerback during answer supervision template processing.
Call disconnect occurs when the equipment at either end goes on-hook (see Figure 3-4). The call path through the network is torn down and the resources/network components involved in the call are returned to their idle state.
Commands used in system call setup, such as the Incoming Port Control ($6A) and Outgoing Port Control ($69) commands, can specify processing to be performed for the ports in a call when the call is torn down. Call teardown can occur in response to either an external event or host command. An external event, such as an on-hook or error condition, triggers processing based on the call setup conditions and the port's COS. When a command is used for call teardown, the processing is generally specified in the command.
Reorder processing and Permanent Signal processing are ways of forcing an off-hook port to disconnect. The system attempts to release the port connection (if allowed by the hardware type) at the beginning of Permanent Signal processing. Both Reorder and Permanent Signal processing prompt the caller to hang up using fast busy tone. Although Reorder processing can overflow into Permanent Signal processing, certain error conditions bypass Reorder and enter Permanent Signal processing directly. Reorder or Permanent Signal processing is not performed for any port with COS = A. Ports with COS = A are set directly to CP_IDLE.
Reorder processing is terminated when the port goes on-hook. If the port is still off-hook after 15 seconds, a physical release is performed and the port starts through Permanent Signal processing.
Permanent Signal processing begins with the system performing a physical release on the port. At this time, the port is set to listen to quiet for 30 seconds. If no on-hook is detected after 30 seconds, the port is set to listen to reorder tone for 15 seconds. If on-hook still has not been detected after 15 seconds, the port is set to listen to quiet until it goes on-hook or the system is reset. When the port goes on-hook, either during or at the end of Permanent Signal processing, it is idled and available for allocation to a new call.
Once a port goes on-hook, it remains idle for a brief period before becoming available for allocation; this delay period is known as guard timing. The length of this guard time varies between interface port types (refer to the "Guard Timing" section for additional information).
Network interface circuits provide incoming and outgoing interfaces between the system and the switched network. The switched network includes central office (CO) trunks, trunks from other common carriers, other switching equipment, and voice equipment such as telephones, voice storage devices, and synthetic speech generators.
Each equipment type has distinct physical characteristics. These characteristics dictate which system network interface circuit is used in connecting to the equipment. The VCO/4K supports both T1 and E1 digital interfaces. For detailed information pertaining to the interface requirements of these interfaces, refer to the Cisco VCO/4K Card Technical Descriptions.
The VCO/4K can directly interface with T1 digital carrier systems operating at a DSX-1 level. Each T1 span supports twenty-four 56-Kbps voice channels and complies with Bell System DS-1 specifications for transmission at 1.544 Mbps. Each T1 span carries a receive (to the T1 card) and a transmit (from the T1 card) data stream. Supervision signaling on T1 I/O modules is the equivalent of E+M two-state signaling.
Incoming T1 ports seize in by setting the A signaling bit to 1 in the Rx (receive) data stream. The system seizes out on an outgoing T1 port by sending 1 signaling bits in the Tx (transmit) data stream.
T1 ports can both generate and detect wink signals. When a T1 port generates a wink, it transmits a 1 signaling bit toward the connected equipment for 250 ms. T1 ports detect wink signals when they receive 1 signaling bits for a period between 110 ms and 350 ms.
Hook flash signals are generated by transmitting 0 signaling bits toward the connected equipment for 250 ms. T1 circuits do not detect hook flash.
When the connected equipment on the outgoing side answers, it sends a 1 signaling bit over the Rx data stream. The system generates answerback by sending a 1 signaling bit in the Tx data stream on the incoming port.
When the A signaling bit in the Rx stream from either end changes to a 0 for 30 ms or more, the system disconnects the call.
The generation and detection of call supervision signals falls under the control of inpulse and outpulse rule processing. Seizures are performed by SEIZE outpulse rule tokens. Wink, hook flash and answerback generation is controlled by inpulse rule tokens. Wink, hook flash, and answer supervision detection is handled by a combination supervision control outpulse rule tokens and answer supervision templates.
WINK NOW and WINK ENAB tokens produce wink and hook flash signals on ports during inpulse rule processing. The system immediately generates a wink or hook flash when a WINK NOW token is encountered during inpulse rule processing. WINK ENAB tokens are used with IP ANI and IP FIELD [xx] digit collection tokens. When rule processing encounters an IP ANI or IP FIELD [xx] token, the system enables the MF or DTMF digit receiver in the call's resource chain. A WINK ENAB token in the rule causes a wink or hook flash signal when the receiver is enabled.
Default inpulse rules (executed when incoming ports seize in) generate signals on the incoming port. However, WINK NOW and WINK ENAB tokens in inpulse rules called during outpulse rule processing (DO IRULE token in the outpulse rule) generate signals on the outgoing port. Interactions between inpulse and outpulse rules are discussed in the Cisco VCO/4K System Administrator's Guide.
For on-hook T1 circuits, executing a WINK NOW or WINK ENAB token provides a wink signal on the port. WINK NOW and WINK ENAB tokens generate a hook flash on off-hook T1 circuits.
ANSWER tokens supply answer supervision over the incoming port. This token is ignored if the port executing the rule has an outgoing class of service. Executing an ANSWER inpulse rule token performs the same action as when an ANSBK or ANSREP condition token is processed in an answer supervision template (refer to "Answer Supervision Template Processing," for details on answer supervision template processing).
In conjunction with call supervision signals, inpulse rules can provide audible supervision signaling to callers in the form of call progress tones and voice prompts. Call progress tone generation using TONE NOW [xx] tokens is discussed in "Tone Generation." Available voice prompts presented by SPEAK [xx] tokens are listed in the Cisco VCO/4K System Administrator's Guide.
 |
Note SPEAK [xx] tokens may interfere with supervision signaling. Application developers should set up delays during inpulse rule processing when a WINK ENAB or WINK NOW immediately follows one or more SPEAK [xx] tokens. Insert a WAIT TIME 1 token between the final SPEAK [xx] token and the WINK NOW or WINK ENAB token. Refer to the "Supervision Timing" section on for more information on delay timing. |
Supervision control outpulse rule tokens perform outward seizures and define supervision processing based on answer supervision templates.
SEIZE tokens perform outward seizures on outgoing trunks. Although a resource control command (such as a $69 or $6A) can select an outgoing port and begin outpulse rule processing for the port, the port remains unseized until a SEIZE token is executed. SEIZE tokens should precede any supervision control tokens (WAIT SUP [xx] or FINAL SUP [xx] tokens) in the rule. If the outgoing port is already seized, the token is ignored (additional SEIZE tokens are ignored after the initial seizure).
WAIT SUP [xx] and FINAL SUP [xx] tokens provide detection and processing for wink and hook flash signals as well as answer supervision, applying the supervision templates established using the Answer Supervision Template utility. The additional data entry fields in these tokens specify the template to process.
Applications can use supervision timers for two basic purposes: creating pauses during inpulse and outpulse rule processing (delay timing), and continuing call processing if supervision is not detected within an acceptable time (supervision error or grace timing). Delay, supervision, error, and grace timers are all under the control of the application and may be modified via system administration. Additional timers used during disconnect processing, known as guard timers, affect resource allocation. These timers are set by the system software and cannot be changed.
Connected equipment may require delays during inpulse and outpulse rule processing. WAIT TIME [xx] tokens in inpulse rules cause rule processing to pause for 1 to 10 seconds. For brief delays during outpulse rule processing, WAIT TIME [xx] tokens suspend rule processing for 250 ms to 2.5 seconds. For instructions on using WAIT TIME [xx] tokens in inpulse and outpulse rules, refer to the Cisco VCO/4K System Administrator's Guide.
TIME SUP [xx] outpulse rule tokens control supervision error timers. These tokens specify the time limit allowed for expected supervision events to be detected during answer supervision template processing. TIME SUP [xx] tokens should immediately precede WAIT SUP [xx] and FINAL SUP [xx] supervision control tokens. Depending on the Time event field setting (ERROR or FAIL) in the specified answer supervision template, the timer's expiration may indicate either a recoverable supervision error or a complete call failure. The additional data entry field of the TIME SUP [xx] token specifies the timer limit (1 to 60) in seconds. Refer to "Answer Supervision Template Processing," for more information on using TIME SUP [xx] tokens.
TIME SUP [xx] outpulse rule tokens may also be used for grace timing. Grace timers provide time for a change in the system to occur; when the timer expires, the system assumes the change occurred or event occurred (even if no change/event was detected) and acts accordingly.
Grace timing is useful in supervision processing when it is uncertain whether an answer supervision event (such as true answer or voice) will occur, due to the types of equipment involved or unusual circumstances surrounding the call scenario. Instead of waiting for a positive indication of answer, template processing watches for the absence of negative indicators (SITs, reorder tone, or busy tone). When a grace timer expires for an outgoing port, the system considers the port answered and assumes the incoming and outgoing ports are involved in a stable call (regardless of the on-hook/off-hook status of the ports).
TIME SUP [xx] tokens should immediately precede a WAIT SUP [xx] or FINAL SUP [xx] supervision control tokens. When the system begins processing the template specified in the supervision control token, the timer starts. If the timer expires and the condition token in the template's Time field is ANSBK or ANSREP, answerback is sent to the incoming port and the system establishes a stable call between the ports.
Refer to "Answer Supervision Template Processing," for more information on TIME SUP [xx] outpulse rule tokens and answer supervision templates.
To prevent allocation conflicts and internal processing errors, the system places ports into a guarded state for a brief period after their deallocation. This period is known as guard timing. For example, network interface ports enter CP_GARD (guard) state after call disconnect, before transitioning to CP_IDLE. During guard timing, the port cannot be allocated to another call.
The guard timer value for the T1 I/O card type is listed in Table 3-2.
| Card Type | Value |
|---|---|
T1 I/O Module | 800 ms |
Posted: Sat Sep 28 14:42:55 PDT 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.