|
|
This chapter presents examples that illustrate the interaction of template, rule, command, and report processing for ISDN calls. These examples consist of the following components:
For these examples, it is assumed that there are two ICC ISDN spans in the system—one with a D-channel at port address 00 00 00 1F (for incoming calls), and one at port address 00 00 00 37 (for outgoing calls). The port addresses of B-channels for incoming calls are between 00 00 00 08 and 00 00 00 1E, inclusive. The port addresses of B-channels for outgoing calls are between 0 00 00 20 and 00 00 00 36, inclusive. Additional system configuration information is shown in Figure 4-1 through Figure 4-7, and includes the following information:
These listings are shown as they would appear after entry into the system database via the system administration utilities. For more information on system administration, refer to "System Administration Support," of this document, and the Cisco VCO/4K System Administrator's Guide.
Each example begins with a brief introductory text explanation. Each figure following the introductory text shows system processing and information flow in two directions—between the system and host, and the system and connected equipment (user or network)—via the ICC ISDN span. Arrows under the message data (bytes) show the direction of information flow. Each area of the message data is labeled.
Example 1 shows a simple scenario in which the system receives an incoming SETUP message over the D-channel at port address 00 00 00 1F. The processing flow for this example is shown in Figure 4-8. It is assumed that the default inpulse rule has been defined as inpulse rule #1.
At the end of this scenario, the incoming call is in setup state awaiting further host action. If no command is received within the time frame specified by the Host Setup Timer, the call is torn down and the system issues a RELEASE COMPLETE message to the network over the D-channel. Refer to "System Host Configuration" section for further information on the Host Setup Timer.
Example 2 provides a variation on system processing of the SETUP message. Again, the system receives an incoming SETUP message over the D-channel at port address 00 00 00 1F. The processing flow for this example is shown in Figure 4-9. This time, only the channel ID and called party number are reported to the host. The entire calling party IE is stored in field 1 for later use. This time the default inpulse rule has been defined as inpulse rule #2.
Selective reporting of IEs allows the application designer to use the system to filter D-channel messages for the host. Storage of IEs in system digit fields facilitates the construction of outgoing D-channel messages; this use of digit fields is shown in Examples 6 and 7.
As in the previous scenario, the incoming call is placed into setup state awaiting further host action. If no command is received within six seconds, the call is torn down and the system issues a RELEASE COMPLETE message to the network over the D-channel.
Example 3 shows another variation on system processing of the SETUP message. As in the previous examples, the system receives an incoming SETUP message over the D-channel at port address 00 00 00 1F. Processing flow for this example is shown in Figure 4-10 and Figure 4-11. The default inpulse rule has been defined as inpulse rule #3.
This example continues by using a second ISDN message template to construct and transmit a D-channel message without host intervention. Using the information gathered from the SETUP message, the system constructs a CALL PROCEEDING message and transmits it back to the network before reporting to the host.
As in the previous scenario, the incoming call is placed into setup state awaiting further host action. If no command is received within six seconds, the call is torn down and the system issues a RELEASE COMPLETE message to the network over the D-channel.
Example 4 shows the interaction between the inpulse rule reporting control group of tokens and the ISDN message template reporting control group of tokens. The processing flow for this example is shown in Figure 4-12. The default inpulse rule has been defined as inpulse rule #4.
The REP EACH token in the inpulse rule generates an ISDN Port Change of State ($ED) report prior to the end of rule reporting. This means two reports are sent to the host instead of the one report in the previous examples. An application can make use of this intermediate reporting to begin processing for a scenario before completion of the rule.
As in all previous scenarios, the incoming call is placed into setup state awaiting further host action. If no command is received within six seconds, the call is torn down and the system issues a RELEASE COMPLETE message to the network over the D-channel.
Example 5, similar to example 4, shows the interaction between the inpulse rule reporting control group of tokens and the ISDN message template reporting control group of tokens. The processing flow for this example is shown in Figure 4-13. The default inpulse rule has been defined as inpulse rule #5.
This time, a NO REP token suppresses end of rule processing. A REP NEXT is used just before the ISDN RX [xx] token to cause reporting of IEs in an ISDN Port Change of State ($EA) report.
As in all previous scenarios, the incoming call is placed into setup state awaiting further host action. If no command is received within six seconds, the call is torn down and the system issues a RELEASE COMPLETE message to the network over the D-channel.
Example 6 builds upon example 3 by assuming the incoming call is in a setup state. The host issues an ISDN Port Control ($49) command, using the incoming B-channel as the controlling port. The system makes use of the bearer IE stored in field 3, and additional IE information included in the host command, to construct a SETUP message for transmission to the network. In this case, the outgoing SETUP is sent over the D-channel at address 00 00 00 37. Byte offsets 0 through 26 are returned to the host to provide the associated (outgoing) B-channel address and call ID.
At the end of this example, the incoming call is in a CP_WANS (waiting for answer) state. The outgoing call is in CP_WTFSUP (waiting for final supervision) state, waiting for a response to the call establishment request. Further host interaction and connect processing is necessary before the call is considered completed.
Following transmission of the SETUP message, the network responds with a CALL PROCEEDING message. When the system receives the CALL PROCEEDING message, it generates an ISDN Port Change of State ($EA) report. The processing flow for this example is illustrated in Figure 4-14 and Figure 4-15.
Example 7, similar to example 6, builds upon the previous examples by assuming the incoming call is in a setup state. The host issues an ISDN Port Control ($49) command, using the incoming B-channel as the controlling port. The system makes use of the calling party number stored in field 2, the bearer IE stored in field 3, and additional IE information included in the host command, to construct a SETUP message for transmission to the network. The outgoing SETUP is sent over the D-channel at address 00 00 00 37. Byte offsets 0 through 26 are returned to the host to provide the associated (outgoing) B-channel address and call ID.
Additional ISDN message templates are processed to handle received ALERTING and CONNECT D-channel messages. An ISDN supervision template determines when to consider the call answered and stable. Answer, in the form of a CONNECT message, is propagated to the incoming D-channel to complete the call scenario. At the end of this example, a stable ISDN-to-ISDN B-channel call exists. The processing flow for this example is shown in Figure 4-16, Figure 4-17, and Figure 4-18.
Example 8 shows how the call established in example 7 is torn down when the outgoing B-channel is released. In this example, the Enable ISDN Manual Disconnect feature flag is set to N. Therefore, the host is not involved in processing the DISCONNECT. The system responds to the received DISCONNECT message for the outgoing B-channel by returning a RELEASE message, then setting the B-channel to an idle state. The network finishes the processing by returning a RELEASE COMPLETE message for the outgoing B-channel. An ISDN Port Change of State ($EA) report is sent to the host, indicating the outgoing B-channel has been idled and is free for another call.
In response to the outgoing disconnect, the system sends a DISCONNECT message for the incoming B-channel. The response from the network is a RELEASE message. The system completes the processing by returning a RELEASE COMPLETE message, idling the incoming B-channel, and generating an ISDN Port Change of State ($EA) report to the host that indicates the incoming B-channel has been idled and is free for another call. The processing flow for this example is illustrated in Figure 4-19 and Figure 4-20.
Example 9 shows how the call established in example 7 is processed when the Enable ISDN Manual Disconnect feature flag is set to Y. In this example, the D and R bits of byte offset 29 (disconnect control) of the ISDN Port Control ($49) command are set to enable the system to send ISDN Port Change of State ($EA) reports to the host. Under these conditions, the system waits four seconds for the host to respond to the $EA report with the DISCONNECT message from the network.
 |
Note If the host does not respond to the $EA report within the 4-second time frame, the system
automatically sends the RELEASE message to the network. If the Enable ISDN Manual Disconnect feature flag is set to Y, do not set the D and R bits (in the $49 command that established the call) to suppress $EA reports. If $EA reports are suppressed, the system cannot send notification or cause IEs for the DISCONNECT to the host. Also, call processing will be delayed by 4 seconds. |
When the system receives a DISCONNECT from the network, it reports to the host via an $EA report that includes all the IEs within the DISCONNECT message. The host sends a $49 command back to the system, which triggers an outpulse rule that includes a RELEASE message with the appropriate IEs. The system then sends the RELEASE message to the network and sets the B-channel to an idle state. The network finishes the processing by returning a RELEASE COMPLETE message for the outgoing B-channel to the system. The system sends another $EA report to the host, indicating the outgoing B-channel has been idled and is free for another call.
The host can also initiate a DISCONNECT with the $49 command. In this case, the DISCONNECT is triggered by the command, which will either execute an outpulse rule or let the system formulate the DISCONNECT message on its own (equivalent to an automatic disconnect).
In response to the $49 command, the system sends a DISCONNECT message for the incoming B-channel to the network. The network responds to the system with a RELEASE message. The system completes processing by simultaneously returning a RELEASE COMPLETE message and idling the B-channel, and generating an $EA report to the host which indicates that the incoming B-channel has been idled and is free for another call. The processing flow for this example is shown in Figure 4-21 and Figure 4-22.
Posted: Fri Jan 23 12:14:36 PST 2004
All contents are Copyright © 1992--2004 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
