The following illustrations show the sequence of messages passed between the three nodes in the following scenarios:
Successful call forward - unconditional (Q.SIG) - The served user node is directed to forward calls unconditionally (CFU), and the diversion attempt succeeds.
Failed call forward - unconditional (Q.SIG) - The served user node is directed to forward calls unconditionally (CFU), and the diversion fails because the diverted-to node refuses the call.
Successful call forward - no response (Q.SIG) - The served user node is directed to forward calls if the called party does not respond (CFNR), and the diversion attempt succeeds.
Failed call forward - no response (Q.SIG) - The served user node is directed to forward calls if the called party does not respond (CFNR), and the diversion attempt fails because the diverted-to node refuses the call.
Aborted call forward - no response (Q.SIG) - The served user node is directed to forward calls if the called party does not respond (CFNR), and the diversion attempt fails because the called party picks up before the diverted-to party answers.
These illustrations are based on Figures C.1, C.2, and C.3 in Appendix C of ISO/IEC 13873. The ACU interface represents the interaction between the SS-DIV control entity with the user. Certain modifications are necessary to take into account that the real Q reference point is in the application, and not in the stack. Therefore, some data that would not be sent to the user is sent to the application.
Also, Figures C.1 and C.2 of the ISO/IEC specification have been combined into a single ACU interface because the diversion services are always invoked on the originating node (for example, diversion by forward switching is not supported).
The following illustration shows the message types passed between nodes when a call forward - unconditional succeeds. In this scenario, the application on PINX 2 is set up to forward all calls destined for user B to user C.
Note: This scenario is identical to call forward - busy (CFB) except for the operation IDs.
The following illustration shows the message types passed between nodes when a call forward - unconditional fails because the diverted-to node rejects the call or returns an error. In this scenario, the application on PINX 2 is set up to forward all calls destined for user B to user C.
Note: This scenario is identical to call forward - busy (CFB) except for the operation IDs.
The following illustration shows the message types passed between nodes when a call forward - no response succeeds.
In this scenario, the application on PINX 2 is set up to forward all calls destined for user B to user C if user B does not respond within a period of time.
The following illustration shows the message types passed between nodes when a call forward - no response fails because the diverted-to node rejects the call or returns an error.
In this scenario, the application on PINX 2 is set up to forward all calls destined for user B to user C if user B does not respond within a period of time.
The following illustration shows the message types passed between nodes when a call forward - no response is aborted during the forwarding attempt because the served user node senses that the user to whom the call was originally destined has answered.
In this scenario, the application on PINX 2 is set up to forward all calls destined for user B to user C if user B does not respond within a period of time.