|
|
United States-English | |
|
|
 |
|
hp OpenCall SS7 platform Application Developer's Guide: For Release 3.1 on Linux > Appendix B TUP Addendum
Call Control |
|
|
This section describes how HP OpenCall SS7 TUP behaves when controlling call setup and call teardown procedures. The equivalent information for HP OpenCall SS7 ISUP is in the following chapters: For each procedure, this section provides: The diagrams in this section use the following convention: Prmt_Name(xxx) where: Prmt_Name is the primitive name and xxx is the message type. Call setup is triggered when a message from the application is received by the TUP library containing the SETUP_REQ primitive and IAM (or IAI). The request to setup a call may be unsuccessful due to various factors, such as failure to receive a specific TUP message or dual seizure. The following scenarios illustrate the behavior of the TUP library in these various circumstances. The application issues a SETUP_REQ to HP OpenCall SS7 TUP. The primitive is locally rejected. Refer to the HP OpenCall SS7 TUP API man pages for details on how the failure condition is reported to the application. This situation occurs in the following cases:
A dual seizure is detected the TUP layer when it receives an initial address message for a circuit for which it has already sent an initial address message. In such a case, the call accepted is the one being processed by the controlling side and the call being processed by the non-controlling side is given up. The controlling side is defined as follows:
Having determined the controlling side, the other side is the non-controlling side. The scenario shown in Figure B-6 “Setup - Dual Seizure Case 1 - Non-Controlling Side ” and Figure B-7 “Setup - Dual Seizure Case 1 - Controlling Side ” corresponds to the case where a circuit is seized on both sides at the same time. In Figure B-6 “Setup - Dual Seizure Case 1 - Non-Controlling Side ”, as a result of the SETUP_REQ, HP OpenCall SS7 TUP issues an IAM ( IAM-1) to the network. The issued IAM crosses the IAM (IAM-2) received from the peer, on its way to HP OpenCall SS7 TUP. Consequently, HP OpenCall SS7 TUP receives this IAM when already engaged in the processing of an outbound call. In this case, HP OpenCall SS7 TUP gives up and issues a SETUP_FAILURE_IND primitive with a DUAL_SEIZURE cause. The application may use this information to re-attempt the call setup on another circuit. There is no automatic call setup re-attempt as another circuit has to be selected. Figure B-6 “Setup - Dual Seizure Case 1 - Non-Controlling Side ” shows the scenario on the non-controlling side. Figure B-7 “Setup - Dual Seizure Case 1 - Controlling Side ” shows the same scenario on the controlling side. In the scenario shown in Figure B-8 “Setup - Dual Seizure Case 2 ”, the application issues a SETUP_REQ primitive on a circuit for which an incoming IAM message has just been treated. The outgoing call is refused with a return status. The most likely cause is that the SETUP_IND is queued in the Up List of HP OpenCall SS7 TUP waiting for the application to read it. The application may re-try a call setup on another circuit. In the scenario shown in Figure B-9 “Setup - Failure to Receive ACM ”, an ACM must be received as a response to the IAM within T2. If the ACM is not received within T2, HP OpenCall SS7 TUP abandons the call attempt and issues a START_RELEASE_IND (T2_TIMEOUT) primitive to the application. Once the application acknowledges, a CLF is sent to the network. In the scenario shown in Figure B-10 “Setup - Failure to Receive ANN (or ANC) ”, an ANN must be received as a response to the IAM within Twann. If the ANN is not received within Twann, HP OpenCall SS7 TUP abandons the call attempt and issues a START_RELEASE_IND to the application. Once the application acknowledges, a CLF is sent to the network. When an unsuccessful backward setup message is received from the network after the sending of an IAM message, then the TUP library issues a RELEASE_IND primitive to the application. In all cases, the TUP layer enters a state to wait for the application to perform the release of the call using the RELEASE_REQ primitive. However, in the special case of an SLB signal, the scenario given in Figure B-46 “Re-answer Procedure - Outgoing Side - After SLB (CTUP Only) ” may also occur.
In the scenario shown in Figure B-13 “Incoming Call Setup With Immediate Release ”, a CLF message is received immediately following the incoming IAM message. In the scenario shown in Figure B-14 “Successful Call Setup - Outgoing Side ”, an IAM (or IAI) message is sent. An ACM message is received before T2 expires. An ANN (or ANC) message is received before Twann expires. In the scenario shown in Figure B-15 “Successful Call Setup - Incoming Side ”, an IAM (or IAI) message is received. An ACM message is sent followed by an ANN (or ANC) message. In the case where an overlap operation is used after the initial address message has been sent, the remaining address signal may be sent in one-digit subsequent address messages (SAO) or in a multi-digit message (SAM). The INFORMATION_REQ and INFORMATION_IND primitive are used to carry SAM or SAO messages between the application and the TUP layer. In the scenario shown in Figure B-18 “Solicited Information Exchange - Outgoing Side ”, an IAM message is sent to the network. This is followed by 2 SAM messages. Subsequently, a GRQ message is received from the network, and a GSM message is sent in response. After the information exchange, an ACM message is received followed by an ANN message. Figure B-19 “Solicited Information Exchange - Incoming Side ” shows the incoming side of this scenario. In the scenario shown in Figure B-19 “Solicited Information Exchange - Incoming Side ”, an IAM message is received from the network. This is followed by 2 SAM messages (and an SAO message between the 2 SAM messages). Subsequently, a GRQ message is sent and a GSM message is received in response. After the information exchange, the ACM and ANN messages are sent. Figure B-18 “Solicited Information Exchange - Outgoing Side ” shows the outgoing side of this scenario. This section describes the use of GRQ (General Request Message) and GSM (General Forward Setup Information Message). The GRQ/GSM protocol can be initiated only during call setup. A unique GSM must be sent in response to a GRQ and must only contain answers to all the requests contained in the GRQ. This is shown in Figure B-20 “Incoming IAM (or IAI) Leading to GRQ and GSM ” and Figure B-21 “Outgoing IAM Leading to GRQ and GSM ”. Any information received in the GSM other than that specifically requested in the associated GRQ is ignored. If a second GSM is received (in response to a GRQ), it is ignored. This is shown in Figure B-22 “Incoming IAM (or IAI) and Two GSMs Received ”. Normally, the side which sent the GRQ should wait until it receives the GSM before sending an ACM. This is shown in Figure B-23 “ACM Sent After GSM Received ”. However, there is an exception (shown in Figure B-24 “ACM Sent Before GSM Received ”) for the case of an international network that is completely SS7. However, in a fully SS7 international network, the international transit exchange is not required to delay sending the ACM even if the GRQ/GSM cycle has not been completed (that is, it ignores the GSM). This is shown in Figure B-24 “ACM Sent Before GSM Received ”. If a GRQ is received before the GSM is sent in reply, the second GRQ is ignored. This is shown in Figure B-25 “Second GRQ Received Before GSM Sent ”. If the call attempt fails (for example, a CGC, NNC, CFL, etc., is received) during the period when an exchange is waiting for a GSM, then the appropriate backward call failure is sent without waiting for the GSM. This is shown in Figure B-26 “Call Failure During Wait for GSM ”. If the GSM is not sent before T2 expires (20 - 30 seconds, waiting to receive ACM), the call attempt fails (a CLF is sent). This is shown in Figure B-27 “ACM Timeout Because of Failure to Send GSM ”. The Continuity Check is a procedure for checking a circuit. It can be requested, when supported by the selected flavor, in an IAM, an IAI, or a CCR message. The following sections describe a number of Continuity scenarios. A Continuity Check is performed on the current circuit if the continuity check indicator in the IAM message is set to ‘Continuity Check required on this circuit’. The outgoing side sends a Continuity message with a successful indication after a correct check of the transmission path (a loop is required on the incoming side, a tone is sent from the outgoing side and is returned in time). In the case presented below, the loopback tone is not detected by the application, and consequently the T8 timer expires. A CCF message indicating ContinuityFailure is sent by HP OpenCall SS7 TUP. After a failed continuity check, a re-check is done automatically as depicted in the Continuity Recheck. If the continuity recheck procedure is a success, only the outgoing side sends a CLF message to finish the procedure. The timer Twccr is equivalent to the ISUP ITU 88 timer T27 (4 minutes): "waiting for CCR message". Upon Twccr timeout a SETUP_FAILURE_IND (TWCCR_TIMEOUT) primitive is sent to the application.
An explicit request for continuity recheck can also be issued by the application to HP OpenCall SS7 TUP. It is ignored if the circuit is not idle. If the T8 timer expires during the continuity recheck phase, either activated after a continuity failure during call setup, or after an explicit continuity recheck request, the following occurs.
The re-answer procedures provided in the TUP protocol allow for a call to be re-established after one of the following clear messages has been sent:
The OPR message may be used in case of operator calls, in order to generate re-ringing of a subscriber who has just gone on-hook. The objective is for an operator to get the subscriber to go off-hook. The OPR signal is transparently transmitted to/from the application by means of the primitives OPERATOR_SIGNAL_IND and OPERATOR_SIGNAL_REQ.
In the following scenarios, the use of OPR is shown in italic font because it is optional in the re-answer procedure. The called side (shown in Figure B-42 “Re-answer Procedure - Incoming Side - RAN After CBK ”) goes on-hook first. It sends a CBK message and starts Twclr (to wait for a CLR message). When it goes off-hook again immediately afterwards, it stops Twclr and sends a RAN message to the calling side (shown in Figure B-43 “Re-answer Procedure - Outgoing Side - RAN After CBK ”). The calling side (shown in Figure B-43 “Re-answer Procedure - Outgoing Side - RAN After CBK ”), receives the CBK message and starts Twran (to wait for a RAN message). It receives the RAN message before Twran expires. The calling side (shown in Figure B-44 “Re-answer Procedure - Outgoing Side - RAN After CCL ”) goes on-hook first. It sends a CCL message and starts Twclr (to wait for the CLR message). When it goes off-hook again immediately afterwards, it stops Twclr and sends a RAN message to the called side (shown in Figure B-45 “Re-answer Procedure - Incoming Side - RAN After CCL ”). The called side (shown in Figure B-45 “Re-answer Procedure - Incoming Side - RAN After CCL ”), receives a CCL message and starts Twran (to wait for a possible RAN message). It receives the RAN message before Twran expires. This procedure is available for operator calls when the operator provides Trunk Offering. If an SLB message (not available in ITUP) is received as a response to the setup message sent by the operator, the call may be established after the busy called side goes on-hook. The scenario is shown in Figure B-46 “Re-answer Procedure - Outgoing Side - After SLB (CTUP Only) ” (for the outgoing side) and Figure B-47 “Re-answer Procedure - Incoming Side - After SLB (CTUP Only) ” (for the incoming side). A call can be released by either party, calling or called. If the application wishes to release a circuit, it will send a RELEASE_REQ primitive with a CLF message containing the cause for releasing the circuit. The circuit status is modified to TRANSIENT, and the CLF message is sent to the SS7 network. If the called part initiates the release, the application is notified with a RELEASE_IND from the TUP library. In scenario shown in Figure B-48 “Normal Call Release - Initiated from Calling Party ”, the application managing the call initiates the release. The HP OpenCall TUP layer starts 2 timers when sending the Clear Forward Message:
The CLF message is repeated every T6 until either an RLG is received or T7 expires. If T7 expires, a reset circuit procedure is initiated. In the scenario shown in Figure B-49 “Normal Call Release - Initiated from Called Party ”, the Clear-back signal is sent in the backward direction indicating that the called party has cleared the call. The call is not released immediately at the calling side to allow for the possible reception of a re-answer signal as shown in “Re-answer Procedures”. In the scenario shown in Figure B-50 “Normal Call Release - Initiated from Called Party After Twran Expiry ”, the called party does not go on-hook and no RAN message is received from network. When Twran expires, the call is automatically released by the TUP layer by issuing a START_RELEASE_IND primitive to the application. In the scenario shown in Figure B-51 “Normal Call Release - Outgoing Release in Backward Direction ”, the application sends a Clear-back signal in the backward direction indicating to the calling part that the call is cleared. The call is not released immediately at the calling side to allow for the possible reception of a re-answer signal as shown in “Re-answer Procedures”. In the scenario shown in Figure B-52 “Normal Call Release - Call Failure Signal Received ”, a CFL message is received. A CLF is sent and T6 and T7 are started. The release is completed (the circuit returns to IDLE) when the RLG message is received. In the scenario shown in Figure B-53 “Normal Call Release - Call Failure Signal Sent ”, a CFL message is sent and T4 and T5 are started. A CLF is received and T4 and T5 are stopped. When the release is completed (the circuit state returns to IDLE), the RLG message is sent. In the scenario shown in Figure B-54 “Abnormal Call Release - Failure To Receive RLG After Sending CLF ”, a CLF message is sent and T6 and T7 are started. T6 expires and another CLF message is sent. When T7 expires, a MAINTENANCE_SYSTEM_IND primitive is sent to the application. An RSC message is sent (and T18 and T19 are started). When the RLG message is received, the reset is completed (the circuit state returns to IDLE). In the scenario shown in Figure B-55 “Abnormal Call Release - Failure To Receive CLF After Sending CBK ”, a CBK message is sent and Twclr is started. Twclr expires and a CFL message is sent (and T4 and T5 are started). A CLF message is received (and T4 and T5 are stopped). When the release is completed (the circuit state returns to IDLE), the RLG message is sent. In the scenario shown in Figure B-56 “Abnormal Call Release - Failure To Receive CLF After Sending CFL ”, a CFL message is sent and T4 and T5 are started. T4 expires and another CFL message is sent (and T4 is re-started). T5 expires and a MAINTENANCE_SYSTEM_IND primitive is sent to the application (and T4 is stopped). An RSC message is sent (and T18 and T19 are started). A CLF message is received (and T18 and T19 are stopped). When the reset is completed (the circuit state returns to IDLE), the RLG message is sent. The circuit reset mechanism is used to reset a circuit to an IDLE condition, thereby making the circuit available for new traffic. In the scenario shown in Figure B-57 “Successful Reset from Application- Incoming ” (case of an incoming call), the Reset procedure is initiated by the application by issuing a RESET_REQ (RSC) primitive. The TUP library sends an RSC message to the network. A CLF message is received. When the circuit state is set to IDLE, an RLG message is sent to the network. In the scenario shown in Figure B-58 “Successful Reset from Application- Outgoing ” (case of an outgoing call), the Reset procedure is initiated by the application by issuing a RESET_REQ (RSC) primitive. The TUP library sends an RSC message to the network. When an RLG message is received, the circuit state is set to IDLE. In the scenario shown in Figure B-59 “Reset from Network - Incoming Exchange - Successful Procedure ” (case of an incoming call), the Reset procedure is initiated by the network. The TUP Layer accepts the signal as a clear-forward signal and responds by sending a release-guard signal, after the circuit has been made idle. This scenario is applicable to an incoming exchange in any phase of call set-up or during a call. The application has to reply promptly though HP OpenCall SS7 TUP and does not set a timer (waiting for RESET_RESP from the application). In the scenario shown in Figure B-60 “Reset from Network - Outgoing Exchange - Successful Procedure ” (case of an outgoing call), the Reset procedure is initiated by the network. The TUP Layer accepts the signal as a clear-back or call failure signal and responds by sending a clear forward signal. The circuit state is set to IDLE when an RLG message is received. The application has to wait for RESET_CONF. In the scenario shown in Figure B-61 “Circuit Reset - Successful Procedure ”, HP OpenCall SS7 TUP initiates a Reset procedure if it receives an unexpected message (a RAN message) after it sends an IAM message. As a result, it sends a START_RESET_IND primitive to the application. The primitive contains an additional information (StartReset) indicating the cause of the setup failure: UNEXPECTED_MESSAGE. The application must respond to this indication as soon as possible via a START_RESET_IND_ACK primitive. On reception of the latter primitive, HP OpenCall SS7 TUP sends an RSC message to the network and starts timers T18 and T19. On receipt of the RLG message, a RESET_CONF primitive is sent to the application. In the scenario shown in Figure B-62 “Circuit Reset - Failure to Receive RLG ”, HP OpenCall SS7 TUP initiates the reset procedure because of the reception of an unexpected message. The network fails to respond with an RLG message. As a result, HP OpenCall SS7 TUP retransmits an RSC message every T18, until the procedure is stopped by the application via a STOP_REQ primitive or until the first T19 time-out. After T19:
This is the same as for ISUP, but instead of the RLC after the BLO, a CLF, or RLG signal is sent depending on whether it is an incoming or an outgoing call. The BLO message has to be acknowledged. If not, the repetition procedure is applied. This is the same as for ISUP, but instead of an RLC, respond with a CLF for outgoing call and RLG for all other cases. See also “Generic TUP Circuit Group Message Handling”. The GRS message is always sent twice to avoid erroneous group reset operations. On the reception side, if only one message is received within 5 seconds, then the operation is canceled. Table B-12 “Timers Used for Group Reset ” gives the timers used for group reset. Table B-12 Timers Used for Group Reset
In the scenario shown in Figure B-63 “Group Reset From Network - Normal Case - Range Not Zero ”, a GRS message is received for 2 circuits for which the current state is not IDLE. On the first GRS, a timer T20 is started, and the state is set to "Wait for second GRS". On the second GRS, a GROUP_RESET_IND primitive is sent to the application, then a RESET_IND primitive is sent for each circuit. The GRA group reset acknowledgment message is sent back only after all the expected RESET_RESP and the GROUP_RESET_RESP (without the GRA associated message) primitives have been received from the application (when all the circuits are in the appropriate state). In the scenario shown in Figure B-64 “Group Reset From Network - Normal Case - Range Zero ”, a GRS message is received for 2 circuits for which the current state is not IDLE. On the first GRS, a timer T20 is started, and the state is set to "Wait for second GRS". On the second GRS, a GROUP_RESET_IND primitive is sent to the application, which responds with a GROUP_RESET_RESP (with GRA associated message) primitive indicating to the remote end that a group reset procedure is started. Then, a START_RESET_IND primitive is sent to the application for each circuit involved in the group. For each START_RESET_IND_ACK primitive, an RSC message is sent to the network, and the remote end will respond with an RLG message. In this scenario shown in Figure B-65 “Group Reset From User - Normal Case ”, a GROUP_RESET_REQ request is sent by the user. All the circuits of the group are remotely and locally unblocked, and the GRS message is sent to the network. Then, TUP waits for the Acknowledgment message GRA before returning the circuit state to IDLE. In the case where the range parameter value is 0 in the GRS sent, then for all the circuits involved an RSC will be received from network, and a RLG sent in response (see “Group Reset From Network - Normal Case”). In the scenario shown in Figure B-66 “Group Reset - Failure Case - No Acknowledgment Received From Network ”, the application sends a GROUP_RESET_REQ primitive. If no response is received from the remote end, GRS messages are repeated according to the T21 and T22 mechanism. In the case shown in Figure B-67 “Group Reset - Failure Case - No Response Received From Application ”, the GROUP_RESET_RESP primitive is sent back by the application but not all RESET_IND primitives have been acknowledged. The GRA message cannot be sent back to the network and an error is returned to the application. In the scenario shown in Figure B-68 “Double Reset - Normal Case - Range Not Zero ”, a circuit is to be reset twice; first by a Circuit Reset RSC, and then by a Circuit Group Reset (it belongs to the group). After the list of circuits involved in the group is established, HP OpenCall SS7 TUP finds that circuit is already being reset, therefore, it does not produce a RESET_IND for it. The application responds to the first RESET_IND by a RESET_RESP, and then to the other RESET_IND. On receipt of GROUP_RESET_RESP, as all the circuits of the group are in the appropriate state, HP OpenCall SS7 TUP can send the GRA. Note that it is likely that the RESET_RESP corresponding to the Circuit Reset contains an RLG message and no additional info, thus causing an RLG message to be sent to the network. In the scenario shown in Figure B-69 “Double Reset - Normal Case - Range Zero ”, a circuit is to be reset twice; first by a Circuit Reset RSC, then by a Circuit Group Reset (it belongs to the group). RESET_IND procedure as well as the START_RESET_IND is involved for it because at the remote end, group reset procedure is waiting for an RSC for each circuit. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
