home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-12-13 | 28.9 KB | 1,383 lines |
- .rs
- .\" Troff code generated by TPS Convert from ITU Original Files
- .\" Not Copyright ( c) 1991
- .\"
- .\" Assumes tbl, eqn, MS macros, and lots of luck.
- .TA 1c 2c 3c 4c 5c 6c 7c 8c
- .ds CH
- .ds CF
- .EQ
- delim @@
- .EN
- .nr LL 40.5P
- .nr ll 40.5P
- .nr HM 3P
- .nr FM 6P
- .nr PO 4P
- .nr PD 9p
- .po 4P
-
- .rs
- \v | 5i'
- .LP
- \fBMONTAGE:\ FIN DE LA RECOMMANDATION Q.82 en\(hyt\* | te de cette page\fR
- .sp 2P
- .LP
- \v'37P'
- \fBRecommendation\ Q.83\fR
- .RT
- .sp 2P
- .sp 1P
- .ce 1000
- \fBCALL COMPLETION SUPPLEMENTARY SERVICES\fR
- .EF '% Fascicle\ VI.1\ \(em\ Rec.\ Q.83''
- .OF '''Fascicle\ VI.1\ \(em\ Rec.\ Q.83 %'
- .ce 0
- .sp 1P
- .LP
- \fR \fB1\fR \fBCall waiting\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 1.1
- \fIGeneral\fR
- .sp 9p
- .RT
- .PP
- 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.
- .PP
- The \fBcall waiting supplementary service\fR will permit a subscriber to
- be notified of an incoming call (as per basic call procedures) with an
- indication that no interface information channel is available.
- .PP
- The user then has the choice of accepting, rejecting or ignoring the waiting
- call (as per basic call procedures).
- .bp
- .RT
- .sp 2P
- .LP
- 1.2
- \fIDescription\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 1.2.1
- \fIGeneral description\fR
- .sp 9p
- .RT
- .PP
- The ISDN call waiting service allows notification to subscriber\ B of the
- incoming call to be out\(hyof\(hyband and this is the assumed case for
- this
- definition. In addition, as a service provider option audible in\(hyband
- indications may be provided.
- .PP
- Where this option is provided, the application of in\(hyband indications,
- in relation to particular call types and channels, is for further study.
- Where applied, tones should be in accordance with Recommendation\ E.180.
- .PP
- 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.
- .RT
- .sp 1P
- .LP
- 1.2.2
- \fIQualifications on the applicability to telecommunication\fR
- \fIservices\fR
- .sp 9p
- .RT
- .PP
- 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.
- .RT
- .sp 1P
- .LP
- 1.3
- \fIDerivation of the functional model for call waiting service\fR
- .sp 9p
- .RT
- .PP
- The model used for illustrating the call waiting supplementary
- service procedures is given below:
- .RT
- .LP
- .rs
- .sp 10P
- .ad r
- \fBFIGURE, p. \fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- 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.
- .PP
- r\d1\uand r\d2\uare relationships between functional entities wherein information
- flows occur in order to process call attempts on service
- requests.
- .RT
- .sp 1P
- .LP
- 1.4
- \fIInformation flow diagrams\fR
- .sp 9p
- .RT
- .PP
- This paragraph contains the information flow diagram for the
- successful sequences of call waiting.
- .PP
- The following flow diagrams are identified:
- .RT
- .LP
- \(em
- Figure\ 1\(hy1/Q.83:
- call waiting notification: case\ 1;
- .LP
- \(em
- Figure\ 1\(hy2/Q.83:
- call waiting notification: case\ 2;
- .LP
- \(em
- Figure\ 1\(hy3/Q.83:
- call waiting notification: case\ 3;
- .LP
- \(em
- Figure\ 1\(hy4/Q.83:
- call waiting acceptance by clearing the A\ call: case\ 1;
- .LP
- \(em
- Figure 1\(hy5/Q.83:
- call waiting acceptance by clearing the A\ call: case\ 2;
- .LP
- \(em
- Figure 1\(hy6/Q.83:
- call waiting acceptance by holding the
- A\ call: case\ 1;
- .LP
- \(em
- Figure 1\(hy7/Q.83:
- call waiting acceptance by holding the
- A\ call: case\ 2;
- .LP
- \(em
- Figure 1\(hy8/Q.83:
- call waiting rejection;
- .LP
- \(em
- Figure 1\(hy9/Q.83:
- call waiting cancellation.
- .bp
- .sp 1P
- .LP
- 1.4.1
- \fICall waiting terminology\fR
- .sp 9p
- .RT
- .PP
- Throughout the stage\ 2 description the following terminology will be used:
- .RT
- .LP
- i)
- Subscriber B: This is the subscriber who is provided by the network with
- call waiting service on a particular interface.
- .LP
- ii)
- User at B: This is the one user who reacts to the call
- waiting at B.
- .LP
- iii)
- User C: This is the user who has originated a call to B
- which causes the call waiting service to be invoked.
- .LP
- 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).
- .LP
- 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.
- .sp 1P
- .LP
- 1.4.2
- \fICall waiting procedures with successful outcome\fR
- .sp 9p
- .RT
- .PP
- The call waiting procedures with successful outcome are hereafter described
- by means of generic information flow diagrams.
- .RT
- .sp 1P
- .LP
- 1.4.2.1
- \fICall waiting notification\fR
- .sp 9p
- .RT
- .PP
- The call waiting notification procedures are given in
- Figures\ 1\(hy1/Q.83 to 1\(hy3/Q.83.
- .PP
- Two categories are identified:
- .RT
- .LP
- i)
- Figures\ 1\(hy1/Q.83 and 1\(hy2/Q.83 describe 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 all information
- channels are in use (no information channel available).
- .LP
- ii)
- Figure\ 1\(hy3/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).
- .PP
- The following procedures are valid for call waiting with no
- information channel available.
- .PP
- 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 \*Qno information channel\*U
- indicated.
- .PP
- The following actions will be taken by the terminals connected to the user\
- B access:
- .RT
- .LP
- i)
- Incompatible terminals will not react.
- .LP
- ii)
- Terminals not presently controlling the information channel that are
- compatible with the incoming call will respond by initiating the
- release procedure indicating a no information circuit/channel available
- condition.
- .LP
- iii)
- Terminals presently controlling the information 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).
- .LP
- iv)
- Terminals presently controlling the information channel
- that support the call waiting service and that are compatible with the
- incoming call will respond by initiating the call progress (reporting)
- procedure and
- will give a local alert to the human user by giving an audible and/or visual
- (in\(hyband) indication.
- .PP
- 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.
- .PP
- \fICase\ 1\fR : Both B Channels busy, one terminal controlling a B Channel
- supports call waiting.
- .bp
- .PP
- Figure\ 1\(hy1/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.
- .PP
- The following user B access terminals are assumed:
- .RT
- .LP
- \(em
- TE1: Being a compatible terminal not supporting call waiting occupying
- channel\ B\d1\uand having a call reference CR1. This terminal is
- assumed to be located in FE6.
- .LP
- \(em
- TE2: Being a compatible terminal not presently controlling
- the information channel. This terminal is assumed to be located in FE6`.
- .LP
- \(em
- TE3: Being a compatible terminal supporting call waiting,
- occupying channel\ B\d2\uand having a call reference CR2. This terminal is
- assumed to be located in FE6".
- .PP
- The new incoming call from C is assumed to have a call reference CR3.
- .PP
- \fICase 2\fR :\ Both B Channels busy, both terminals controlling the B
- Channels support call waiting.
- .PP
- Figure\ 1\(hy2B/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.
- .PP
- The following user B access terminals are assumed.
- .RT
- .LP
- \(em
- TE1: Being a compatible terminal supporting call waiting
- occupying channel\ B\d1\uand having a call reference CR1. This terminal is
- assumed to be located in FE6.
- .LP
- \(em
- TE2: Being a compatible terminal not presently
- controlling the information channel. This terminal is assumed to be located
- in FE6`.
- .LP
- \(em
- TE3: Being a compatible terminal supporting call
- waiting, occupying channel B\d2\uand having a call reference CR2. This
- terminal is assumed to be located in FE6".
- .PP
- The new incoming call from C is assumed to have a call reference CR3.
- .PP
- \fICase 3\fR : One B Channel busy, the terminal controlling the busy B
- Channel supporting call waiting.
- .PP
- Figure\ 1\(hy3/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.
- .PP
- 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.
- .RT
- .sp 1P
- .LP
- 1.4.2.2
- \fICall waiting acceptance\fR
- .sp 9p
- .RT
- .PP
- 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.
- .RT
- .LP
- 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\(hy4/Q.83 and 1\(hy5/Q.83).
- .LP
- 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 services, for example, three party service
- may be used (see
- Figures\ 1\(hy6/Q.83 and 1\(hy7/Q.83).
- .LP
- 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.
- .LP
- 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.
- .bp
- .LP
- .rs
- .sp 47P
- .ad r
- \fBFigure 1\(hy1/Q.83, p. 2\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 47P
- .ad r
- \fBFigure 1\(hy2/Q.83, p. 3\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 47P
- .ad r
- \fBFigure 1\(hy3/Q.83, p. 4\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 47P
- .ad r
- \fBFigure 1\(hy4/Q.83, p. 5\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 47P
- .ad r
- \fBFigure 1\(hy5/Q.83, p. 6\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 47P
- .ad r
- \fBFigure 1\(hy6/Q.83, p. 7\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 47P
- .ad r
- \fBFigure 1\(hy7/Q.83, p. 8\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .sp 1P
- .LP
- 1.4.2.3
- \fICall waiting rejection\fR
- .sp 9p
- .RT
- .PP
- The user at B can also, within the specified period, reject the new incoming
- call from user C. In this case, call clearing procedures (see
- Figure\ 1\(hy8/Q.83) will apply at the basic access interface.
- .PP
- 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.
- .RT
- .sp 1P
- .LP
- 1.4.2.4
- \fICall waiting notification ignored\fR
- .sp 9p
- .RT
- .PP
- 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.
- .PP
- Normal release applies to the call attempt from C by sending an
- appropriate clearing indication to the calling user (see Figure\ 1\(hy9/Q.83).
- .PP
- 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.
- .RT
- .sp 1P
- .LP
- 1.5
- \fISDL diagrams for functional entities\fR
- .sp 9p
- .RT
- .PP
- This section contains the SDL diagrams for the network function
- entity FE5. The entire SDL is a variation of the basic call r\d2\u\(hyr\d1\uCALL
- SENT state.
- .PP
- The relationships \*Qr\d1\u\*U and \*Qr\d2\u\*U have been deleted in functional
- entity FE5 between functional entities FE4 (r\d2\u) and FE6 (r\d1\u).
- (See\ \(sc\ 1.3.)
- .RT
- .sp 1P
- .LP
- 1.6
- \fIFunctional entity actions\fR
- .sp 9p
- .RT
- .PP
- 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 information transfer.
- .RT
- .LP
- .rs
- .sp 25P
- .ad r
- Blanc
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 47P
- .ad r
- \fBFigure 1\(hy8/Q.83, p. 9\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 47P
- .ad r
- \fBFigure 1\(hy9/Q.83, p. 10\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 47P
- .ad r
- \fBFigure 1\(hy10/Q.83 (feuillet 1 sur 7), p. 11\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 47P
- .ad r
- \fBFigure 1\(hy10/Q.83 (feuillet 2 sur 7), p. 12\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 47P
- .ad r
- \fBFigure 1\(hy10/Q.83 (feuillet 3 sur 7), p. 13\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 47P
- .ad r
- \fBFigure 1\(hy10/Q.83 (feuillet 4 sur 7), p. 14\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 47P
- .ad r
- \fBFigure 1\(hy10/Q.83 (feuillet 5 sur 7), p. 15\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 47P
- .ad r
- \fBFigure 1\(hy10/Q.83 (feuillet 6 sur 7), p. 16\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 47P
- .ad r
- \fBFigure 1\(hy10/Q.83 (feuillet 7 sur 7), p. 17\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .sp 1P
- .LP
- 1.7
- \fIAllocation of functional entities to physical locations\fR
- .sp 9p
- .RT
- .PP
- The following allocation of functional entities to physical
- locations of the call waiting supplementary service are applicable:
- .RT
- .LP
- i)
- \fICase\ 1\fR
- .LP
- FE1
- FE3
- FE4
- FE5
- FE6
- .LP
- FE2\ <ACCESS>
- FE7\ <NETWORK>
- FE8\ <NETWORK>
- LE\ <ACCESS>
- TE
- .LP
- TE
- LE
- TR
- .LP
- 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.
- .LP
- FE3, FE4, FE5, FE7 and FE8 are the functional entities which
- represent the network functions.
- .LP
- FE5 represents the network access providing exchange, FE4 and FE8 the
- transit exchanges, FE3 and FE7 the remote local exchanges.
- .LP
- ii)
- \fICase 2\fR
- .LP
- FE1
- FE3
- FE4
- FE5
- FE6
- .LP
- FE2\ <ACCESS>
- FE7\ <NETWORK>
- FE8\ <ACCESS>
- NT2\ <ACCESS>
- TE
- .LP
- TE
- LE
- LE
- (PRA)
- (BA)
- .LP
- 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.
- .LP
- FE6 is the service requesting terminal while FE5 represents the
- service providing NT2.
- .LP
- FE3, FE4, FE7 and FE8 are the functional entities which represent the
- local network functions.
- .LP
- iii)
- \fICase 3\fR
- .LP
- FE1
- FE3
- FE4
- FE5
- .LP
- FE2\ <ACCESS>
- FE7\ <ACCESS>
- FE8\ <NETWORK>
- LE\ <ACCESS>
- FE6
- .LP
- TE
- NT2
- LE
- .LP
- FE1, FE2, FE3, FE6 and FE7 are the functional entities which
- represent the users of the call waiting supplementary service. FE1 and FE3
- represent user\ A, FE2 and FE7 represent user\ C while FE6 represents user\ B.
- .LP
- FE6 is the service requesting terminal, FE1 and FE2 the remote
- terminals and FE3 and FE7 the remote NT2s.
- .LP
- FE4, FE5 and FE8 are the functional entities which represent the local
- network functions.
- .LP
- iv)
- \fICase 4\fR
- .LP
- FE1
- FE3
- FE4
- FE5
- .LP
- FE2\ <ACCESS>
- FE7\ <NETWORK>
- FE8\ <ACCESS>
- NT2\ <ACCESS>
- FE6
- .LP
- NT2
- LE
- LE
- .LP
- 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.
- .LP
- FE5 being the service providing NT2 and FE1 and FE2 the remote
- terminals.
- .LP
- FE3, FE4, FE7 and FE8 are the functional entities which represent the
- local network functions.
- .LP
- v)
- \fICase 5\fR
- .LP
- FE1
- FE3
- FE4
- FE5
- .LP
- FE2\ <ACCESS>
- FE7\ <NETWORK>
- FE8\ <ACCESS>
- TE
- .LP
- TE/NT2
- LE
- .LP
- 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.
- .LP
- FE3, FE4, FE7 and FE8 are the functional entities which represent the
- local network functions.
- .sp 2P
- .LP
- \fB2\fR \fBCall hold\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 2.1
- \fIIntroduction\fR
- .sp 9p
- .RT
- .PP
- References: CCITT Recommendation I.253, \(sc\ 2, Call hold (Stage\ 1)
- Service description.
- .PP
- 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.
- .bp
- .RT
- .sp 1P
- .LP
- 2.1.1
- \fIDefinition\fR
- .sp 9p
- .RT
- .PP
- The \fBcall hold service\fR allows a user to interrupt
- communications on an existing call/connection
- .FS
- The applicability of the hold service a \*Qcall\*U versus a \*Qconnection\*U
- requires further study.
- .FE
- and then
- subsequently, if desired, re\(hyestablish communications. A B Channel
- .FS
- The
- applicability of this service definition to other access resources
- (e.g.,\ H\(hychannels, logical channels) for other services requires further
- study.
- .FE
- may or may not be reserved after the communication is interrupted to allow
- the origination 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\(hyestablishes communication
- on a B Channel between the served user and the held party.
- .RT
- .sp 2P
- .LP
- 2.2
- \fIDefinition of functional model\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 2.2.1
- \fIFunctional model description\fR
- .sp 9p
- .RT
- .LP
- .rs
- .sp 8P
- .ad r
- \fBFigure 2\(hy1/Q.83, p. \fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- 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.
- .sp 1P
- .LP
- 2.2.1.1
- \fIDescription of functional entity 1\fR
- .sp 9p
- .RT
- .PP
- Functional entity 1 supports the following functionality:
- .RT
- .LP
- 1)
- access the service providing capabilities of functional
- entity 2 by way of functional service requests (e.g., hold request, retrieve
- request);
- .LP
- 2)
- receive functional indications relating to the call from
- functional entity 2 and relay them to the \*Quser\*U of the call (e.g., hold
- confirmation, retrieve confirmation).
- .sp 1P
- .LP
- 2.2.1.2
- \fIDescription of functional entity 2\fR
- .sp 9p
- .RT
- .PP
- Functional entity 2 supports the following functionality:
- .RT
- .LP
- 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);
- .LP
- 2)
- perform the holding function (functional entity action
- 201);
- .LP
- 3)
- send functional indications relating to the call to
- functional entity 1 (e.g., hold confirmation, retrieve confirmation);
- .LP
- 4)
- reserve an information channel, if reservation is
- subscribed to (functional entity action 203);
- .LP
- 5)
- perform reservation management (functional entity action
- 204);
- .LP
- 6)
- perform the retrieve function (functional entity action
- 202).
- .bp
- .sp 1P
- .LP
- 2.2.1.3
- \fIDescription of functional entity 3\fR
- .sp 9p
- .RT
- .PP
- Functional entity 3 supports the following functionality:
- .RT
- .LP
- 1)
- receive the optional notification of call hold and the
- optional notification of retrieval and relay them toward functional entity\ 4;
- .LP
- 2)
- identify the call at the FE3/FE4 interface that the
- optional notifications apply to (functional entity action 205).
- .sp 1P
- .LP
- 2.2.1.4
- \fIDescription of functional entity 4\fR
- .sp 9p
- .RT
- .PP
- Functional entity 4 supports the following functionality:
- .RT
- .LP
- 1)
- receive the optional notification of call hold and the
- optional notification of retrieval and inform (relay them to) user\ B.
- .sp 1P
- .LP
- 2.2.2
- \fIRelationship to basic service\fR
- .sp 9p
- .RT
- .LP
- .rs
- .sp 14P
- .ad r
- \fBFigure 2\(hy2/Q.83, p. \fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- 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.
- .LP
- .rs
- .sp 17P
- .ad r
- Blanc
- .ad b
- .RT
- .LP
- .bp
- .sp 2P
- .LP
- 2.3
- \fIInformation flow description\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 2.3.1
- \fIInformation flow diagram for successful operation\fR
- .sp 9p
- .RT
- .LP
- .rs
- .sp 33P
- .ad r
- \fBFigure 2\(em3/Q.83, p. \fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- 2.3.2\ \ \fIDefinition of individual information flows\fR
- .sp 1P
- .RT
- .sp 2P
- .LP
- 2.3.2.1\ \ \fIHold request\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 2.3.2.1.1\ \ \fIMeaning of hold request\fR
- .sp 9p
- .RT
- .PP
- Hold request is the information sent from FE1 to FE2 to request
- that a call be placed on hold by the network.
- .RT
- .sp 1P
- .LP
- 2.3.2.1.2\ \ \fIInformation content for hold request\fR
- .sp 9p
- .RT
- .PP
- The following information is contained in the hold
- request:
- .RT
- .LP
- \(em
- an identifier of the call to which the hold request
- applies.
- .bp
- .sp 2P
- .LP
- 2.3.2.2\ \ \fIHold confirmation\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 2.3.2.2.1\ \ \fIMeaning of hold confirmation\fR
- .sp 9p
- .RT
- .PP
- 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 network.
- .RT
- .sp 1P
- .LP
- 2.3.2.2.2\ \ \fIInformation content for hold confirmation\fR
- .sp 9p
- .RT
- .PP
- The following information is contained in the hold
- confirmation:
- .RT
- .LP
- \(em
- an identifier of the call to which the hold confirmation
- applies.
- .sp 2P
- .LP
- 2.3.2.3\ \ \fI(Optional) notification of hold\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 2.3.2.3.1\ \ \fIMeaning of (optional) notification of hold\fR
- .sp 9p
- .RT
- .PP
- (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.
- .RT
- .sp 1P
- .LP
- 2.3.2.3.2\ \ \fIInformation content for (optional) notification of hold\fR
- .sp 9p
- .RT
- .PP
- The following information is contained in the (optional)
- notification of hold:
- .RT
- .LP
- \(em
- an identifier of the call to which the (optional)
- notification of hold applies.
- .sp 2P
- .LP
- 2.3.2.4\ \ \fIRetrieve request\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 2.3.2.4.1\ \ \fIMeaning of retrieve request\fR
- .sp 9p
- .RT
- .PP
- Retrieve request is the information sent from FE1 to FE2 to request the
- reconnection of a held call.
- .RT
- .sp 1P
- .LP
- 2.3.2.4.2\ \ \fIInformation content for retrieve request\fR
- .sp 9p
- .RT
- .PP
- The following information is contained in the retrieve
- request:
- .RT
- .LP
- \(em
- an identifier of the call to which the retrieve request
- applies;
- .LP
- \(em
- an optional indication that:
- .LP
- 1)
- any channel is acceptable for retrieval, or
- .LP
- 2)
- a specified channel is preferred for retrieval, or
- .LP
- 3)
- a specified channel is exclusively required for
- retrieval.
- .sp 2P
- .LP
- 2.3.2.5\ \ \fIRetrieve confirmation\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 2.3.2.5.1\ \ \fIMeaning of retrieve confirmation\fR
- .sp 9p
- .RT
- .PP
- Retrieve confirmation is the information sent from FE2 to FE1 that confirms
- that communications was able to be re\(hyestablished and that the held
- call is now reconnected. If an optional indication concerning the B channel
- over which communications was to have been re\(hyestablished was included
- in the retrieve request, then the retrieve confirmation serves as an acknowledgement
- that retrieval was carried out as requested.
- .RT
- .sp 1P
- .LP
- 2.3.2.5.2\ \ \fIInformation content for retrieve confirmation\fR
- .sp 9p
- .RT
- .PP
- The following information is contained in the retrieve
- confirmation:
- .RT
- .LP
- \(em
- an identifier of the call to which the retrieve confirmation applies;
- .LP
- \(em
- an identifier of the channel over which the held call is
- reconnected.
- .sp 2P
- .LP
- 2.3.2.6\ \ \fI(Optional) notification of retrieval\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 2.3.2.6.1\ \ \fIMeaning of (optional) notification of retrieval\fR
- .sp 9p
- .RT
- .PP
- (Optional) notification of retrieval is the information sent from FE2 towards
- B indicating that the B channel between FE1 and FE2 has been
- reconnected.
- .bp
- .RT
- .sp 1P
- .LP
- 2.3.2.6.2\ \ \fIInformation content for (optional) notification of retrieval\fR
- .sp 9p
- .RT
- .PP
- The following information is included in the (optional)
- notification of retrieval:
- .RT
- .LP
- \(em
- an identifier of the call to which the (optional)
- notification of retrieval applies.
- .sp 1P
- .LP
- 2.4
- \fIFunctional entity actions\fR \v'3p'
- .sp 9p
- .RT
- .LP
- \(em
- 201
- \(em
- Perform the holding function
- .LP
- \(em
- 202
- \(em
- Perform the retrieve function
- .LP
- \(em
- 203
- \(em
- Perform the reservation function
- .LP
- \(em
- 204
- \(em
- Perform the reservation management to insure
- that:
- .LP
- When a user (as identified by a terminal, other possibilities 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).
- .LP
- \(em
- 205
- \(em
- identify the call at the FE3/FE4 interface that the optional notifications
- apply to.
- .sp 1P
- .LP
- 2.5
- \fISDL diagrams for functional entities\fR
- .sp 9p
- .RT
- .PP
- The SDL diagrams for functional entities 1, 2, 3 and 4 are shown in Figures\
- 2\(hy4/Q.83, 2\(hy5/Q.83, 2\(hy6/Q.83 and 2\(hy7/Q.83.
- .RT
- .LP
- .rs
- .sp 29P
- .ad r
- Blanc
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 47P
- .ad r
- \fBFigure 2\(hy4/Q.83 (feuillet 1 sur 2), p. 21\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 47P
- .ad r
- \fBFigure 2\(hy4/Q.83 (feuillet 2 sur 2), p. 22\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 47P
- .ad r
- \fR \fBFigure 2\(hy5/Q.83 (feuillet 1 sur 2), p. 23\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 47P
- .ad r
- \fR \fBFigure 2\(hy5/Q.83 (feuillet 2 sur 2), p. 24\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 22P
- .ad r
- \fBFigure 2\(hy6/Q.83, p. 25\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .rs
- .sp 24P
- .ad r
- \fBFigure 2\(hy7/Q.83, p. 26\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .sp 1P
- .LP
- 2.6
- \fINetwork physical allocation scenarios\fR
- .sp 9p
- .RT
- .ce
- \fBH.T. [T1.83]\fR
- .ps 9
- .vs 11
- .nr VS 11
- .nr PS 9
- .TS
- center box;
- lw(36p) | lw(12p) | lw(24p) | lw(24p) | lw(24p) | lw(12p) .
- FE1 FE2 FE3 FE4
- _
- .T&
- lw(36p) | lw(12p) | lw(24p) | lw(24p) | lw(24p) | lw(12p) .
- Scenario 1 TE LE LE TE
- .T&
- lw(36p) | lw(12p) | lw(24p) | lw(24p) | lw(24p) | lw(12p) .
- Scenario 2 TE NT2 NT2 TE
- .T&
- lw(36p) | lw(12p) | lw(24p) | lw(24p) | lw(24p) | lw(12p) .
- Scenario 3 TE LE NT2 TE
- .T&
- lw(36p) | lw(12p) | lw(24p) | lw(24p) | lw(24p) | lw(12p) .
- Scenario 4 TE NT2 LE TE
- .TE
- .nr PS 9
- .RT
- .ad r
- \fBTable [T1.83], p. \fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 2P
- .LP
- \fB3\fR \fBCompletion of call to busy subscriber\fR
- .sp 1P
- .RT
- .PP
- Under study.
- .RT
- .LP
- .rs
- .sp 37P
- .sp 2P
- .LP
- \fBMONTAGE: RECOMMANDATION Q.85 sur le reste de cette page\fR
- .sp 1P
- .RT
- .LP
- .bp
-