BT Monarch MF4 RXer

6.6 Narrative Description of the Handling of a Call

6.6.1 As an indication of the way in which the work of handling the exchange is divided up

between the different processes, this sub-section provides a narrative description of the handling

of a basic extension-to-extension call.

The MF Signalling Receivers

3.9.16 The MF Signalling Receivers are designed to accept signals conforming to the internationally agreed system (referred to in British Telecom as Signalling System Multi-Frequency No. 4 - SSMF4) in which each signal is represented by a combination of 2 frequencies - one in the Band 697 Hz to 941 Hz, and the other in the Band 1209 Hz to 1633 Hz.

On receipt of an "off hook" signal from an extension provided with an MF keyphone Class of Service, the CPU immediately sets up a connection in the "send" direction to an MF Receiver port on the Services Card, and in the "receive" direction to dial tone (Port 8 on the Services Card), thus connecting dial tone to the extension user. The MF digits are accepted by the receiver and forwarded to the CPU, via the Binder and Signalling-In highway, in appropriately coded form using the 8 signalling bits A to H, as described in Part 2. When the CPU concludes that all the digits have been received, it releases the connection to the MF Receiver and sets up a call from the originating extension to the required extensions, or other destination, in the usual way.

3.9.18 Considering now the operation of one receiver, the incoming MF signals, in binary

encoded form are captured from the incoming speech highway at the appropriate port time, and

after conversion to analogue are applied to the input of a standard MF signal receiver. Provided

that one signal, and only one signal is present in each of the signalling bands, and provided the

levels of the 2 signals are both within the prescribed limits, and their presence exceeds a

predetermined duration (the "Recognition Time"), DC signals are passed to the Signal

Encoding Circuit, where they are converted to binary and sent in serial form via the Binder to

the appropriate port on the 256 kbit/s Signalling-In highway.

6.6.2 The first step in handling a call from an extension occurs when the slow foreground part

ofxSCAN detects a call condition containing a valid port number in a time slot from the CSI

serving the extension line unit. XSCAN sends an acknowledgement to the CSI, which then

becomes transparent to signalling in both directions; the loop from the extension will therefore

be detected by XSCAN when it next scans that time slot. When XSCAN detects the loop, it

sends a "new call" message with the EN of the calling extension to CPRO, and puts the extension

into a "temporary parked" state to prevent the loop from causing more "new call" messages.

6.6.3 When CPRO receives the "new call" message, it allocates a Call Record for the call and

checks the COS of the calling extension to see whether the extension is expected to use

loop/ disconnect pulsing, or multi-frequency pulsing (SSMF4), or either (the rest of this

description assumes that the extension is expected to use either type of signalling). If the

extension is expected to use SSMF4, CPRO asks XSCAN to seize an SSMF4 digit receiver, then

enters a wait state until a reply is received from XSCAN.

6.6.4 When XSCAN receives the "seize" message, it allocates a free SSMF4 receiver and sends a "seize OK" message to CPRO.

6.6.5 When CPRO receives the "seize OK" message, it relates it to the appropriate call by the Call Record Number, then sends messages to XSCAN to set the state of the extension to "dialling", to connect the calling extension, and to enable the SSMF4 receiver. It then enters a further wait state until digits have been received.

6.6.6 When XSCAN receives the "set state to dialling" message, it changes the state of the extension from "temporary parked" to "dialling" and puts the extension's time slot on to a list of time slots which are scanned every 8ms, to allow loop/disconnect pulses to be assembled into digits. The "connect" messages cause the selected SSMF4 receiver to be connected to listen to the extension and the extension to be connected to listen to the dial tone port. The "enable SSMF4 receiver" message causes the signalling output of the SSMF4 receiver to be scanned for digits.

The extension user will hear dial tone, and can dial or key the number for the extension he requires.

6.6.7 If the extension instrument is a dial telephone, the first digit will be assembled from the loop/disconnect pulses and XSCAN will send a "digit received" message to CPRO. When CPRO receives this message, the fact that it came from the extension EN rather than the SSMF4 receiver EN will indicate that the SSMF4 receiver is no longer needed. CPRO will send messages to XSCAN to connect silence to the SSMF4 receiver and to set the state of the receiver to "free".

6.6.8 If on the other hand the extension is an SSMF4 keyphone, the first digit will be detected from the SSMF4 receiver, so that the "digit received" message to CPRO will bear the EN of the SSMF4 receiver rather than the EN of the extension. CPRO will recognise from this fact that the SSMF4 receiver is still required. but as the extension need no longer be scanned for loop/ disconnect pulses, CPRO will send a message to XSCAN to set the state of the extension to "listening" .

6.6.9 In either case, when the first "digit received" message is received from XSCAN by CPRO, dial tone must be disconnected; this is done by connecting the calling extension to silence. CPRO then waits until enough digits have been received to identify the called extension.

When the last digit has been received, ifit was from a dial telephone, CPRO sends a message to XSCAN to set the state of the extension to "listening"; if an SSMF4 receiver was used, CPRO sends a message to XSCAN to set the state of the receiver to "free".

6.6.10 CPRO then refers to the data base to see whether calls to the required extension are barred or diverted; if they are not, CPRO refers again to the data base to obtain the EN of the called extension, and sends a message to XSCAN to mark the called extension.

6.6.11 When XSCAN receives the "mark" message from CPRO, it checks to see if the EN of the called extension is associated with a time slot. If the EN is not associated with a time slot. then XSCAN attempts to seize a free time slot on the shelf serving the extension, and sends a message to the CSI to power up the extension port. If the extension port acknowledges the power up message, then the CSI will become transparent to signalling; XSCAN will temporarily park the extension and send a "mark OK" mess sage to CPRO. If the called extension is associated with a time slot or if a time slot to the extension cannot be seized XSCAN replies with a "mark fail" message which gives the reason for failure.

6.6.12 If CPRO receives a "mark fail" message, it sends a message to XSCAN to connect the calling extension to engaged tone or NU tone as appropriate. If CPRO receives a "mark OK" message, it sends messages to XSCAN to connect ringing tone to the calling extension, and to ring the called extension, and enters a wait state until the called extension answers or the calling extension clears.

6.6.13 When XSCAN receives the "ring extension" message, it sets the state of the called

extension to "marked" and applies ring current to the called extension. The exchange ring

current supply is continuous; cadencing is carried out by the XSCAN slow foreground task for

each extension separately, so that ringing always starts as soon as the called extension is marked.

Four different ring current cadences are available.

6.6.14 When the called extension answers, XSCAN slow foreground task will detect the

loop, disconnect ring current, and send a "called subscriber answer" message to CPRO.

6.6.15 When CPRO receives the "called subscriber answer" message, it sends messages to

XSCAN to connect the calling extension to the called extension, and the called extension to the

calling extension (two paths must be set up through the switch, as each path provides only

unidirectional transmission), and to set the state of each extension to "speech". CPRO then

enters a wait state until one of the two extensions clears.

6.6.16 When one extension clears, this will be detected by XSCAN slow foreground task

which will send a "clear" message to CPRO; first party clear is used.

6.6.17 When it receives the "clear" message, CPRO will send messages to XSCAN to set the

state of both extensions to "free", and will release the call record used during the call.

6.6.18 When XSCAN receives the "set state to free" messages, the extension which has

cleared will become dormant, but the other extension will generate a new call if the loop persists

for long enough to be detected as a new call by XSCAN slow foreground task.