5i' MONTAGE: FIN DE LA RECOMMANDATION Q.82 en-t | te de cette page Recommendation Q.83 CALL COMPLETION SUPPLEMENTARY SERVICES 1 Call waiting 1.1 General This Recommendation provides information on the functions in ISDN entities and the information flows between the entities which are required to provide the call waiting supplementary service. The call waiting supplementary service will permit a sub- scriber to be notified of an incoming call (as per basic call pro- cedures) with an indication that no interface information channel is available. The user then has the choice of accepting, rejecting or ignor- ing the waiting call (as per basic call procedures). 1.2 Description 1.2.1 General description The ISDN call waiting service allows notification to subscriber B of the incoming call to be out-of-band and this is the assumed case for this definition. In addition, as a service pro- vider option audible in-band indications may be provided. Where this option is provided, the application of in-band indications, in relation to particular call types and channels, is for further study. Where applied, tones should be in accordance with Recommendation E.180. The maximum number of calls that can be handled (e.g. active, held, alerting, waiting) for each ISDN number on a given interface is specified at subscription time. 1.2.2 Qualifications on the applicability to telecommunication services This supplementary service is considered meaningful when applied to the telephony teleservice, speech and 3.1 kHz audio bearer services. Furthermore, it may also be meaningful when applied to other services. 1.3 Derivation of the functional model for call waiting service The model used for illustrating the call waiting supplementary service procedures is given below: FIGURE, p. CCA is the functional entity that serves the user and is responsible for initiating functional requests and interacting with the network. CC is the functional entity within the network that cooperates with its peers to provide the services requested by CCA. r1and r2are relationships between functional entities wherein information flows occur in order to process call attempts on ser- vice requests. 1.4 Information flow diagrams This paragraph contains the information flow diagram for the successful sequences of call waiting. The following flow diagrams are identified: - Figure 1-1/Q.83: call waiting notifica- tion: case 1; - Figure 1-2/Q.83: call waiting notifica- tion: case 2; - Figure 1-3/Q.83: call waiting notifica- tion: case 3; - Figure 1-4/Q.83: call waiting acceptance by clearing the A call: case 1; - Figure 1-5/Q.83: call waiting acceptance by clearing the A call: case 2; - Figure 1-6/Q.83: call waiting acceptance by holding the A call: case 1; - Figure 1-7/Q.83: call waiting acceptance by holding the A call: case 2; - Figure 1-8/Q.83: call waiting rejection; - Figure 1-9/Q.83: call waiting cancella- tion. 1.4.1 Call waiting terminology Throughout the stage 2 description the following terminology will be used: i) Subscriber B: This is the subscriber who is provided by the network with call waiting service on a particular interface. ii) User at B: This is the one user who reacts to the call waiting at B. iii) User C: This is the user who has originated a call to B which causes the call waiting service to be invoked. iv) One user at A: This represents a user who is engaged in a call with a user at B (this call can be in any state). v) Information channel control: A terminal that has information channel control is active on a call, is alerting for an incoming call, has an outgoing call in a state following or including the outgoing call proceeding state, or has a call on hold with reservation. 1.4.2 Call waiting procedures with successful outcome The call waiting procedures with successful outcome are hereafter described by means of generic information flow diagrams. 1.4.2.1 Call waiting notification The call waiting notification procedures are given in Figures 1-1/Q.83 to 1-3/Q.83. Two categories are identified: i) Figures 1-1/Q.83 and 1-2/Q.83 describe the case where the served user is notified of an incoming call and the net- work requires an interface channel to his user access and it has detected that all information channels are in use (no information channel available). ii) Figure 1-3/Q.83 describes the case where the served user is notified of an incoming call and the network requires an interface channel to his user access and it has detected that an existing free information channel, which is the only compatible terminal, is in the busy condition (information channel available). The following procedures are valid for call waiting with no information channel available. When an incoming call from a user C arrives at the functional entity controlling the access at B and encounters the channel's busy condition and the network determined user busy conditions do not result, then the call shall be offered to B by means of the Setup procedure with the "no information channel" indicated. The following actions will be taken by the terminals connected to the user B access: i) Incompatible terminals will not react. ii) Terminals not presently controlling the infor- mation channel that are compatible with the incoming call will respond by initiating the release procedure indicating a no infor- mation circuit/channel available condition. iii) Terminals presently controlling the informa- tion channel that do not support the call waiting service and are compatible with the incoming call will respond either by initiating the release procedure indicating a user busy condition or by acting as incompatible terminals (e.g. no reaction). iv) Terminals presently controlling the information channel that support the call waiting service and that are compati- ble with the incoming call will respond by initiating the call pro- gress (reporting) procedure and will give a local alert to the human user by giving an audible and/or visual (in-band) indication. When a positive response is received from the terminals at B within the normal basic call period, that (those) user(s) is (are) being informed about the incoming call, then the calling user at C will be given an indication that the called user(s) is (are) being informed. This will be performed by the network at the B side by sending of the ringing tone; some networks may instead generate a special call waiting tone, provided the bearer capability is either speech or audio 3.1 kHz. In addition, optionally, a call waiting out of band indication may be sent to the C user. Case 1 : Both B Channels busy, one terminal controlling a B Channel supports call waiting. Figure 1-1/Q.83 shows the generic information flow diagram for call waiting notification when the incoming call from user C is delivered at the user B access by broadcast data link without available information channels. The following user B access terminals are assumed: - TE1: Being a compatible terminal not supporting call waiting occupying channel B1and having a call reference CR1. This terminal is assumed to be located in FE6. - TE2: Being a compatible terminal not presently controlling the information channel. This terminal is assumed to be located in FE6`. - TE3: Being a compatible terminal supporting call waiting, occupying channel B2and having a call reference CR2. This terminal is assumed to be located in FE6". The new incoming call from C is assumed to have a call refer- ence CR3. Case 2 : Both B Channels busy, both terminals controlling the B Channels support call waiting. Figure 1-2B/FQ.83 shows the generic information flow diagram for call waiting notification when the incoming call from user C is delivered at the user B access by broadcast data link without available information channels. The following user B access terminals are assumed. - TE1: Being a compatible terminal supporting call waiting occupying channel B1and having a call reference CR1. This terminal is assumed to be located in FE6. - TE2: Being a compatible terminal not presently controlling the information channel. This terminal is assumed to be located in FE6`. - TE3: Being a compatible terminal supporting call waiting, occupying channel B2and having a call reference CR2. This terminal is assumed to be located in FE6". The new incoming call from C is assumed to have a call refer- ence CR3. Case 3 : One B Channel busy, the terminal controlling the busy B Channel supporting call waiting. Figure 1-3/Q.83 shows the generic information flow diagram for call waiting notification when the incoming call from user C is delivered at the user B access by broadcast data link with an available information channel, but the only compatible terminal is presently controlling an information channel. If the thus compatible terminal has call waiting facilities available, it alerts its user (audible or visible indication) and notifies the network (REPORT). The user then can decide whether to accept the waiting call or not. 1.4.2.2 Call waiting acceptance If a user at B requests, within a specified period, to connect to the waiting call, two procedures may be required by user B with regard to the active call with a user at A. i) Procedure one will terminate the specified active call with a user at A, while the call between a user at C and the user at B is completed in the normal manner (see Figures 1-4/Q.83 and 1-5/Q.83). ii) Procedure two will place the specified active call with a user at A into a held state, while the call between a user at C and the user at B will be completed in the normal manner. The previously active call between a user at A and the user at B is put into the held state. From this state other supplementary ser- vices, for example, three party service may be used (see Figures 1-6/Q.83 and 1-7/Q.83). This acceptance provokes the initiation of a Hold sequence by the terminal to the network. The network will hold the previous call between a user at A and the user at B, while the waiting call from a user at C will be connected by a Setup responseB/Fconfirm sequence. Since more than one terminal controlling the information channels can respond positively to a call waiting offering, the network will subsequently apply a clear procedure to the remaining terminals having responded positively after having received the Setup response/confirmation order. Figure 1-1/Q.83, p. 2 Figure 1-2/Q.83, p. 3 Figure 1-3/Q.83, p. 4 Figure 1-4/Q.83, p. 5 Figure 1-5/Q.83, p. 6 Figure 1-6/Q.83, p. 7 Figure 1-7/Q.83, p. 8 1.4.2.3 Call waiting rejection The user at B can also, within the specified period, reject the new incoming call from user C. In this case, call clearing pro- cedures (see Figure 1-8/Q.83) will apply at the basic access inter- face. If the terminals controlling the information channels have initiated the Report (alerting) procedures, the network will wait after the reception of the first release sequence from a terminal for the possible reaction of the other terminal. If all the users reject the waiting call, the network shall initiate the clearing of the call indicating the user determined busy condition of the called users to the calling user C. 1.4.2.4 Call waiting notification ignored If the specified period expires without any acceptance from B of the incoming call, then the network shall inform B of this situation and also inform C that this call cannot be connected. Normal release applies to the call attempt from C by sending an appropriate clearing indication to the calling user (see Figure 1-9/Q.83). A rejection of the waiting call by one terminal will not stop the call waiting timer, as another terminal may accept the waiting call within the specified period. 1.5 SDL diagrams for functional entities This section contains the SDL diagrams for the network func- tion entity FE5. The entire SDL is a variation of the basic call r2-r1CALL SENT state. The relationships "r1" and "r2" have been deleted in func- tional entity FE5 between functional entities FE4 (r2) and FE6 (r1). (See S 1.3.) 1.6 Functional entity actions The functional entity actions are identical to the actions required for the circuit mode switched bearer services speech, 3.1 kHz audio unrestricted and alternate speech/unrestricted infor- mation transfer. Blanc Figure 1-8/Q.83, p. 9 Figure 1-9/Q.83, p. 10 Figure 1-10/Q.83 (feuillet 1 sur 7), p. 11 Figure 1-10/Q.83 (feuillet 2 sur 7), p. 12 Figure 1-10/Q.83 (feuillet 3 sur 7), p. 13 Figure 1-10/Q.83 (feuillet 4 sur 7), p. 14 Figure 1-10/Q.83 (feuillet 5 sur 7), p. 15 Figure 1-10/Q.83 (feuillet 6 sur 7), p. 16 Figure 1-10/Q.83 (feuillet 7 sur 7), p. 17 1.7 Allocation of functional entities to physical locations The following allocation of functional entities to physical locations of the call waiting supplementary service are applicable: i) Case 1 FE1 FE3 FE4 FE5 FE6 FE2 FE7 FE8 LE TE TE LE TR FE1, FE2 and FE6 are the functional entities which represent the users of the call waiting supplementary service (e.g. may be physically located in TE or NT2 equipment). FE1 represents user A, FE2 user C and FE6 user B. FE6 is the service requesting terminal and FE1 and FE2 the remote terminals. FE3, FE4, FE5, FE7 and FE8 are the functional entities which represent the network functions. FE5 represents the network access providing exchange, FE4 and FE8 the transit exchanges, FE3 and FE7 the remote local exchanges. ii) Case 2 FE1 FE3 FE4 FE5 FE6 FE2 FE7 FE8 NT2 TE TE LE LE (PRA) (BA) FE1, FE2, FE5 AND FE6 are the functional entities which represent the users of the call waiting supplementary service. FE1 represents user A, FE2 user C. FE6 is the service requesting terminal while FE5 represents the service providing NT2. FE3, FE4, FE7 and FE8 are the functional entities which represent the local network functions. iii) Case 3 FE1 FE3 FE4 FE5 FE2 FE7 FE8 LE FE6 TE NT2 LE FE1, FE2, FE3, FE6 and FE7 are the functional entities which represent the users of the call waiting supplementary ser- vice. FE1 and FE3 represent user A, FE2 and FE7 represent user C while FE6 represents user B. FE6 is the service requesting terminal, FE1 and FE2 the remote terminals and FE3 and FE7 the remote NT2s. FE4, FE5 and FE8 are the functional entities which represent the local network functions. iv) Case 4 FE1 FE3 FE4 FE5 FE2 FE7 FE8 NT2 FE6 NT2 LE LE FE1, FE2, FE5 and FE6 are the functional entities which represent the users of the call waiting supplementary service. FE1 represents user A, FE2 user C and FE5 and FE6 user B, FE6 being the service requesting terminal. FE5 being the service providing NT2 and FE1 and FE2 the remote terminals. FE3, FE4, FE7 and FE8 are the functional entities which represent the local network functions. v) Case 5 FE1 FE3 FE4 FE5 FE2 FE7 FE8 TE TE/NT2 LE FE1, FE2 and FE5 are the functional entities which represent the users of the call waiting supplementary service. FE1 represents user A, FE2 user C and FE5 and FE6 user B, FE5 is as well as the service requesting as the service providing terminal while FE1 and FE2 are the remote terminals/NT2s. FE3, FE4, FE7 and FE8 are the functional entities which represent the local network functions. 2 Call hold 2.1 Introduction References: CCITT Recommendation I.253, S 2, Call hold (Stage 1) Service description. This paragraph includes treatment of the network options as described in the Stage 1 service description. Specifically, (1) optional notification to the held party indicating that the call has been placed on hold, and (2) optional notification to the held party that a call has been retrieved. 2.1.1 Definition The call hold service allows a user to interrupt communica- tions on an existing call/connection and then subsequently, if desired, re-establish communications. A B Channel may or may not be reserved after the communication is interrupted to allow the origi- nation or possible termination of other calls. Reservation must be provided by the service provider as a user option. The Call Hold service includes the Retrieve operation which re-establishes com- munication on a B Channel between the served user and the held party. 2.2 Definition of functional model 2.2.1 Functional model description Figure 2-1/Q.83, p. r, along with its subscripts, represents different information flow relationships between functional entities. FE3 and FE4 are shown as dashed circles to represent their optional nature in the context of the Call Hold Service. 2.2.1.1 Description of functional entity 1 Functional entity 1 supports the following functionality: _________________________ The applicability of the hold service a "call" versus a "connection" requires further study. The applicability of this service definition to other access resources (e.g., H-channels, logical channels) for other services requires further study. 1) access the service providing capabilities of functional entity 2 by way of functional service requests (e.g., hold request, retrieve request); 2) receive functional indications relating to the call from functional entity 2 and relay them to the "user" of the call (e.g., hold confirmation, retrieve confirmation). 2.2.1.2 Description of functional entity 2 Functional entity 2 supports the following functionality: 1) receive the functional service requests from functional entity 1 and relay them into the network (e.g., receive the hold request from functional entity 1 and relay an optional notification of the held call toward user B); 2) perform the holding function (functional entity action 201); 3) send functional indications relating to the call to functional entity 1 (e.g., hold confirmation, retrieve confirma- tion); 4) reserve an information channel, if reservation is subscribed to (functional entity action 203); 5) perform reservation management (functional entity action 204); 6) perform the retrieve function (functional entity action 202). 2.2.1.3 Description of functional entity 3 Functional entity 3 supports the following functionality: 1) receive the optional notification of call hold and the optional notification of retrieval and relay them toward functional entity 4; 2) identify the call at the FE3/FE4 interface that the optional notifications apply to (functional entity action 205). 2.2.1.4 Description of functional entity 4 Functional entity 4 supports the following functionality: 1) receive the optional notification of call hold and the optional notification of retrieval and inform (relay them to) user B. 2.2.2 Relationship to basic service Figure 2-2/Q.83, p. The call control agent (CCA) is the functional entity that serves the user and is responsible for initiating functional requests and interacting with the network. Call control (CC) is performed by functional entities within the network to provide the services requested by the CCA. Blanc 2.3 Information flow description 2.3.1 Information flow diagram for successful operation Figure 2-3/Q.83, p. 2.3.2 Definition of individual information flows 2.3.2.1 Hold request 2.3.2.1.1 Meaning of hold request Hold request is the information sent from FE1 to FE2 to request that a call be placed on hold by the network. 2.3.2.1.2 Information content for hold request The following information is contained in the hold request: - an identifier of the call to which the hold request applies. 2.3.2.2 Hold confirmation 2.3.2.2.1 Meaning of hold confirmation Hold confirmation is the information sent from FE2 to FE1 that confirms that a call has been put on hold for the user by the net- work. 2.3.2.2.2 Information content for hold confirmation The following information is contained in the hold confirma- tion: - an identifier of the call to which the hold con- firmation applies. 2.3.2.3 (Optional) notification of hold 2.3.2.3.1 Meaning of (optional) notification of hold (Optional) notification of hold is the information sent from FE2 towards B indicating that the call between FE1 and FE2 has been placed on hold. 2.3.2.3.2 Information content for (optional) notification of hold The following information is contained in the (optional) notification of hold: - an identifier of the call to which the (optional) notification of hold applies. 2.3.2.4 Retrieve request 2.3.2.4.1 Meaning of retrieve request Retrieve request is the information sent from FE1 to FE2 to request the reconnection of a held call. 2.3.2.4.2 Information content for retrieve request The following information is contained in the retrieve request: - an identifier of the call to which the retrieve request applies; - an optional indication that: 1) any channel is acceptable for retrieval, or 2) a specified channel is preferred for retrieval, or 3) a specified channel is exclusively required for retrieval. 2.3.2.5 Retrieve confirmation 2.3.2.5.1 Meaning of retrieve confirmation Retrieve confirmation is the information sent from FE2 to FE1 that confirms that communications was able to be re-established and that the held call is now reconnected. If an optional indication concerning the B channel over which communications was to have been re-established was included in the retrieve request, then the retrieve confirmation serves as an acknowledgement that retrieval was carried out as requested. 2.3.2.5.2 Information content for retrieve confirmation The following information is contained in the retrieve confir- mation: - an identifier of the call to which the retrieve confirmation applies; - an identifier of the channel over which the held call is reconnected. 2.3.2.6 (Optional) notification of retrieval 2.3.2.6.1 Meaning of (optional) notification of retrieval (Optional) notification of retrieval is the information sent from FE2 towards B indicating that the B channel between FE1 and FE2 has been reconnected. 2.3.2.6.2 Information content for (optional) notification of retrieval The following information is included in the (optional) notif- ication of retrieval: - an identifier of the call to which the (optional) notification of retrieval applies. 2.4 Functional entity actions - 201 - Perform the holding func- tion - 202 - Perform the retrieve func- tion - 203 - Perform the reservation function - 204 - Perform the reservation management to insure that: When a user (as identified by a terminal, other possibili- ties for further study) places a call on hold and reservation applies, a B channel should always be available on that user's interface for the user to retrieve that call from hold; or setup, retrieve, or connect to another call. One B channel should be kept available for the user as long as the user: (i) has one or more calls on hold with reservation and, (ii) is not currently connected to any other call. That is, the network should not reserve more than one B channel for a user, regardless of how a user is defined (as identified by a terminal, other possibilities for further study). - 205 - identify the call at the FE3/FE4 interface that the optional notifications apply to. 2.5 SDL diagrams for functional entities The SDL diagrams for functional entities 1, 2, 3 and 4 are shown in Figures 2-4/Q.83, 2-5/Q.83, 2-6/Q.83 and 2-7/Q.83. Blanc Figure 2-4/Q.83 (feuillet 1 sur 2), p. 21 Figure 2-4/Q.83 (feuillet 2 sur 2), p. 22 Figure 2-5/Q.83 (feuillet 1 sur 2), p. 23 Figure 2-5/Q.83 (feuillet 2 sur 2), p. 24 Figure 2-6/Q.83, p. 25 Figure 2-7/Q.83, p. 26 2.6 Network physical allocation scenarios H.T. [T1.83] __________________________________________ FE1 FE2 FE3 FE4 __________________________________________ Scenario 1 TE LE LE TE Scenario 2 TE NT2 NT2 TE Scenario 3 TE LE NT2 TE Scenario 4 TE NT2 LE TE __________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table [T1.83], p. 3 Completion of call to busy subscriber Under study. MONTAGE: RECOMMANDATION Q.85 sur le reste de cette page