IE20030693A1 - Voice and data exchange - Google Patents

Abstract

A voice and data exchange for use in telecommunications comprises a private automatic branch exchange (PABX) having a HTTP server and webpages for controlling PABX. In order to increase the functionality and versatility of the PABX system, a client computer can communicate with the server via a non-proprietary interface, facilitating remoter maintenance and control of the PABX.

Description

VOICE AND DATA EXCHANGE This invention relates to a voice and data exchange. That is to say, a private automatic branch exchange (PABX) system that serves as an interface between several external telephony lines and several local extensions.

PABX systems are in very widespread use. Most generally, a PABX enables several external telephony lines to be shared amongst a greater number of internal extensions. Traditionally, a PABX served as an interface between analogue POTS lines and analogue extensions to handle analogue voice calls. However, it is increasingly common for the external lines to be digital lines (for example, ISDN lines) and for the internal extensions to be a mixture of analogue voice lines and digital lines, for example for computer data or digital fax calls.

PABX systems have simultaneously increased in functionality and reduced in cost and maintenance requirements. This means that any operation that requires an engineer to attend a site at which a PABX system is installed had become relatively more expensive. Therefore, efforts have been made to keep to a minimum the number of procedures that require the attendance of an engineer by providing the PABX with remote maintenance and control capabilities. This allows many engineering tasks to be performed remotely, for example, using a web browser executing on a remote client computer to display web pages to interface with a control system of the PABX over a data link such as one of the external lines or a local Ethernet interface.

To provide this functionality, existing PABX systems run applets on the individual client computers. This imposes a requirement that the browsers installed on the client computers need to be able to run these applets. The applets then communicate with the page server resident in the PABX via a proprietary interface. This tends to increases the cost of the hardware and software of the client computers and requires that a client computer be specifically prepared for use in controlling the PABX.

From a first aspect, this invention provides a PABX having a control system that includes a HTTP server, webpages that are required to control the PABX being provided by the HTTP server. In such a system, no applets need be used and there is no need for a IE 03 06 9 3 proprietary link between the client computer and the PABX. Moreover, file transfer into and out of the PABX is simplified because the standard and open HTTP protocol is used rather than a proprietary protocol.

In addition to serving pages to configure the system, the HTTP server in an embodiment of the invention may serve to transfer files into out of the PABX. This is required, for example, for upgrading software within the PABX or for retrieving diagnostic data from the PABX.

To support computer-telephony integration (CTI) applications, a second aspect of the invention provides a PABX within which a TAPI service provider is embedded. This can be implemented more simply than the conventional approach of running an application on a server on a LAN. Thus, different CTI applications can be installed on the individual client computers on the LAN. Each client then communicates with the PABX directly instead of communicating with it through the intermediary of a server. In order to implement CTI on an existing LAN, a PABX incorporating this feature can be installed on a LAN without the need to reconfigure the LAN itself or to install an additional server on the LAN.

On many existing PABXs, diagnostics information and a history of the system’s operation can be viewed by attaching a computer to a serial port on the PABX. Embodiments of the invention have a store (such as RAM memory) within which a large amount of history of the system’s operation can be held. A PABX system embodying the invention may include a serial (RS232) port through which data in the store can be accessed. In addition, a third aspect of this invention is to provide a PABX what has a network interface, such as an Ethernet interface to a LAN, through which the content of the store can be accessed remotely. This adds remote diagnostic and maintenance functionality to the PABX. For example, in the case of a technical query from a customer, a network operator can remotely access several days’ history leading up to the start of a problem, or the history surrounding some operation or programming action carried out by the customer. As compared with a PABX in which data can be accessed only through a local serial port, this has the effect of greatly reducing the number of visits to customer sites by service personnel and therefore achieving huge savings in time and cost.

IE Ο5 06 3 3 The provision of a network link can offer further functionality. The PABX can become a data enabled element as well as a voice switch. This can lead to numerous advantages through the application of the appropriate software. Examples of this would be allowing a users PC and phone to be twinned so that software on the PC such as call managers etc. are fully aware of the status of the phone and can be passed information such as Caller ID etc. Further embodiments might perform redirection of an incoming call to voice mail or mobile automatically depending on whether a computer is switched on (i.e. whether a user is at his or her desk). Another convenient feature, also made possible is interactive popup’s on a network computer screen advising users what options are available (such as transfer call redirect etc.) depending on the status of the call at their phone.

Such a PABX can also act as a full IP data router for the LAN to which it is attached i.e. a single box can act as the conduit for both voice and data into and out of the LAN.

In a further extension to this, the PABX may advantageously present an API between the PABX and a softswitch element. (A softswitch is a virtual PABX, which is resident typically on a Linux or windows server i.e., it is software only). The API may allow the softswitch and the PABX to communicate and exchange information regarding their respective states. This can allow the PABX and the Softswitch to act as a single switching system.

The main advantages of this approach are that: a) The user’s critical communications needs can be dedicated to the high reliability PABX while still allowing voice over IP PABX advantages to be accessed as and when the user requires while still maintaining a low entry cost; b) Allows the number of extension of the PABX to be increased above the normal set level (through the addition of Ethernet phones); and c) Allows each computer to become a voice extension (through the use of appropriate software and audio device such as a headset).

With any computer-controlled system, it can be difficult to isolate the cause of a system crash, especially when the circumstances of the crash cannot readily be reproduced. This ΙΕ ο 3 06 93 is especially so in a system such as a PABX where high availability is essential and the system is configured to re-boot as soon as possible after a crash.

From a fourth aspect, this invention provides a control computer for a PABX and software/firmware for that control computer configured such that, in the event that the system crashes and goes to power up again, the system executes code to store information relating to the system state prior to the crash. For example, the system may store in a secure area of memory the content of the memory location where the stack for the processes executing before the crash were located. Therefore, when the system starts to run again the stack information is preserved.

Advantageously, in such a system, on power-up or in response to a user command, the stack information is transferred to a remote diagnostic system. For example, the data may be streamed to a serial port. Alternatively or additionally in embodiments of the third aspect of the invention, the data may be obtained through use of diagnostic tools communicating with the PABX over the LAN. Diagnostic tools can then process the stack information to reproduce exactly the lines of code being run up to the point of the crash. This feature effectively acts as an embedded emulator greatly assisting the development of more efficient, more compact and more bug-free code.

Known PABXs can download new system code remotely. However, the boot code, which resides in the boot sector of the on-board flash memory, cannot normally be changed. Therefore, making any changes to boot code to enhance the system (or correct errors in the boot-code) necessitates the return of the PABX to the factory for reprogramming. The reason for this is that to change the contents of the boot sector, it first has to be erased before being reprogrammed. During this procedure, there is a “window of opportunity” within which the boot code is incomplete. A loss of system power in this period will be catastrophic because when power returns and the system tries to reboot, the boot code will have been partially (or totally) erased and so rendered useless. Therefore, a further aim of this invention is to provide a PABX in which changes can safely be made to the boot-code without having to return the unit to the factory.

From a fifth aspect, this invention provides a PABX in which the system boot code has breakout points inserted at intervals which allow the addition of new sections of code to IE Ο 3 OS 9 3 the boot code. Typically, when a breakout point is reached during execution of the bootcode, the content of memory locations associated with the breakout determines whether the boot-code: (a) Proceeds as normal (in the case of no modifications being required) or (b) Jumps to a section of memory (either boot sector or any other sector) containing extra code which is then run as if it is in the boot-code.

After execution of the code in case b, the processor can resume execution of boot-code either directly after the breakout point or at another address in the boot sector thereby effectively leaving out a section of the boot-code.

Effectively, some locations in the boot sector can be programmed without first erasing any of the boot sector.

Typically, the boot sector is stored in re-programmable read-only (e.g. Flash) memory.

The advantage of this is that the boot-code is never vulnerable due to the boot sector having to be erased.

To increase security, activation of the code associated with these breakout points may depends on provision of authorisation information. Such authorisation information may include one or more of: (1) A key; (2) A valid address; and (3) A key.

If any of these elements is missing, the new code cannot be run and the default is to execute the existing boot-code.

Typically, manufacturers of PABX systems may produce several models with different capacities and capabilities. As with most manufacturing tasks, it is advantageous in terms IE 0 3 06 93 of cost and convenience to minimise the number of different products that must be manufactured to fill a customer demand.

From a sixth aspect, this invention provides a PABX system that can be reconfigured from a first set of capacities and capabilities to a second set of capacities and capabilities through an action performed in software.

For example, a PABX system embodying the invention may, before shipment, be programmed with a key, which either confirms their status as a full system (e.g. 4 ISDN lines and 12 extensions) or a restricted system (e.g. 2 ISDN lines and 8 extensions). Once a restricted system is shipped to the customer, the system capacity can be increased by using an “Upgrade Server” software option under the control of the Network Operator. Most preferably, this can be performed remotely.

This has the advantage of allowing the manufacturer to build and ship one product while allowing the network operator to supply a product to a customer with minimum dimensions while having the possibility of upgrading the system at a future date by simply using a software upgrade. No extra hardware modules are necessary and therefore no installer visits are necessary. This results in significant savings in time and cost and since no intervention is necessary to add or take away hardware modules in case of changing customer requirements, increased reliability.

In further embodiments of the invention, the voicecard (for voicemail and auto-attendant) running as a daughter module in the system can be modified by remote download in two major ways; 1. New runtime code and new pre-recorded voice messages and prompts can be downloaded remotely over the system ISDN lines to update the system to suit changing customer requirements. No installer intervention is necessary hence saving time and cost and increasing reliability. 2. While the codec component used in the voicecard leaves the factory configured for 2 channel operation, using the voicecard download facility the codec can be upgraded to 4 channel operation, again without any installer intervention. ΙΕ ο 3 ο 6 9 3 This method allows the same voicecard PCB to be upgraded to cater for an increased number of voicemail channels.

The advantage of the above features is that they allow the use of one generic voicecard PCB subassembly for many languages and customer I country configurations. Hence savings in time and costs associated with manufacturing / configuring / handling different PCB assemblies is greatly reduced and reliability is increased. If increased storage time is needed (for either the 2-channel or 4-channel version), the same PCB can be equipped at the factory with a larger flash memory.

An embodiment of the invention will now be described in detail, by way of example, and with reference to the accompanying drawings, in which: Figures 1 to 19 are schematics of the embodiment.

The embodiment is a PABX system that acts as an interface between up to four digital ISDN (T) line ports from a public network and the internal ports of the system. The ports on the internal side of the system consist of; · Four Analog Extensions, • Eight Proprietary Digital Extensions, • ISDN S-Bus, • Music-On-Hold Port, • Paging (PA) Port, · Ethernet LAN Port.

System Interfaces ISDN “T” Interfaces The “T” Interface lines connect the system to the NTls provided by the network operator (PTT). The system has a maximum capacity of four lines if the fourth IE Ο 3 08 93 (configurable) port is set up as a “T” interface. Note: Only the fourth port is configurable the other three are permanent “T” interfaces.

Each interface has a capacity of two “Bearer” or “B” channels which have a data rate of 64 Kbits/sec each and which may be used for routing either speech or data calls through the public network.

The signalling associated with the pair of B channels on a “T” interface is carried on the “D” (signalling) channel of that interface.

Analog The analog extensions will accept devices of either the DTMF (Tone) dialling or Decadic 10 (Pulse) dialling type and thus cater for a range of terminal types (Telephone, Fax, Answering Machine).

Digital Systemphone The two-wire digital extensions can only be populated with MDS proprietary Digital Sytemphones, which feature an LCD display and an extensive array of keys which show line status, extension status and allow the use and programming of system functions.

S-Bus The internal S-Bus (if the configurable ISDN port is selected as such) allows the connection of ISDN compatible terminals (TEls) to the internal side of the system. Examples are ISDN Phones, Group 4 Fax, PC with Terminal Adapter etc.

Ethernet The 10/100 BaseT Ethernet Port allows the connection of the system to a corporate LAN to allow interworking of the LAN Server and the PABX to provide CTI (Computer Telephony Integration) services and allows the system to act as a router to allow PCs on the LAN to access the Internet through the ISDN lines.

Through the browser interface, a PC on the LAN (or a single PC attached to the system directly via a crossover cable) can be used to configure the system.

IE Ο 3 06 9 3 Switching The switching function within the system is realised by a digital time and space switching component (Infineon “DELIC”). All channels are switched in 8-bit Digital PCM format.

The various physical layer transceivers for the different interfaces listed above are all connected to the DELIC through various TDM highways and all have the effect of converting the different interface formats into standard 8-bit PCM timeslots which are switchable by the DELIC.

D/A and A/D Conversion.

In the case of channels destined for the four analog extensions, conversion of the outgoing signals into analog format takes place in the four channels of a codec component just before they go to the analog ports.

Likewise, incoming analog signals undergo conversion from analog to digital in codec channels before entering the digital switching core for switching to its destination.

As in the case of the analog telephony ports, external music entering the MOH (input) port (from a CD player for example) is converted into digital format by a codec channel before being switched to one or more line ports in digital format. Similarly, when paging out through the PA Port, the source (originating from an extension) is switched by the digital core and is then converted to analog format by a codec channel for transmission to the PA speaker attached to the PA (output) port.

In the case of the proprietary MDS Digital systemphones and internal S-Bus phones, the channels travel down to the phones in digital format and are finally converted to analog format in a codec in the systemphone or S-Bus phone.

DTMF Receivers.

There system includes two DTMFs controlled by the microcontroller. Through multiplexers, each of these can be connected to any of the four speech paths coming from the analog extensions. These are used for decoding digits dialled from a DTMF (tone dialling) telephone for the purpose of call setup. ,Ε Ο 3 Ο 6 9 ϊ System Control The system control architecture is based around a single microcontroller (MOTOROLA MPC855T) which runs multiple slave tasks in parallel, the time allocated to each task being controlled by a scheduler.

The slave tasks carry out low level functions as follows: i) ISDN “T” Line Interface and “So-Bus” Slaves i. Implementation of Layers 1, 2 and 3 of Euro-ISDN protocol for the Set-up / Teardown of ISDN calls to and from the public ISDN or internal ISDN terminals, ii. DTMF dialling over the ISDN. ii) 4 Analog Extension Slave i. Extension On / Off Hook monitoring, ringing to extensions, codec configuration and control, ii. SLIC control, DTMF reception, iii. CLI transmission in DTMF or FSK format etc. iii) 8 Digital Systemphone Slave i. Setup and teardown of calls to and from proprietary digital extensions (Layer 1 activation and deactivation and proprietary upper layer signalling). iv) Call Control Slave i. Co-ordination of ISDN, systemphone and analog extension slaves for the purposes of call set-up I cleardown, switching, implementation of system features etc.

IE 0 3 06 9 3 The software for the MPC855T Microcontroller, along with system parameters, is stored in compressed format in the bottom half of a 16 MBit Flash memory. (The top half is reserved for temporary storage of a new version of code which has just been remotely downloaded and has not yet been copied to the lower half).

Two 64 MBit SDRAMs are used for temporary storage required by the Microcontroller. Also, after power-up, the system software is unzipped from the compressed format stored in Flash and subsequently run from SDRAM.

An internal software watchdog is provided to reset the microcontroller in the event of a software crash while an external brownout detector resets the system in the event of a power supply brownout.

Figure 1 shows the System in Block Diagram format.

POWER SUPPLY SECTION The Power Supply converts mains input voltage of 180Vac - 264Vac to outputs of; -40V @ 300mA for -24V @ 110mA for +15V@ 500mA for -100V@ 30mA for +5V @ 200mA for +3.3V @ 1.5A for Digital, Long Line Analog and S-Bus Power Feed. Analog Extension SLIC Circuitry.

Ethernet Router / DSL Daughter Card.

Analog Extension SLIC Circuitry.

Codec Circuitry for Analog Extensions.

Main System Power - all Digital Circuitry.

All outputs are overload and short circuit protected.

The unit provides a PF [Power Fail] signal to the battery back-up module, which signals the system of mains failure. Interface voltages of -46V, -27V and 15V are also provided to the Battery Back-Up Module.

CONTROL SECTION.

MPC 855T Microcontroller and Memory.

The heart of the control section comprises a Motorola MPC 855T 32-bit Microcontroller (IC1) along with IC2, a 16 Mbit FLASH Memory (AM29LV160 or HY29LV160) and two Mbit SDRAMs IC3 and IC4 (HY57V643220CT-7). Crystal X4 (32.768 KHz) and IE 0 3 0 6 9 S Oscillator X5 (5 MHz) along with associated circuitry provide the clocks required by the microcontroller.

An internal multiplier circuit in the MPC 855T multiplies the 5 MHz by 10 to give a Processor clock speed of 50 MHz.

A Brownout Detector circuit IC22 (MAX809) monitors the 3V3 power rail and resets the system if it goes below the threshold.

DELIC: DSP Embedded Line and Port Interface Controller I Digital Switch.

Central to the switching architecture of the embodiment is the Infineon “DELIC” (IC5).

The DELIC is an ISDN Line and Interface Port Controller. All of the lines and internal ports are connected to it through various physical layer devices. No matter what kind of traffic is handled by the various physical layer devices, by the time it gets to the DELIC, it is always in standard 8-bit PCM format allowing the DELIC to switch it transparently.

The physical layer devices are connected to the DELIC by several types of interfaces: • ISDN and Digital Port transceivers (2 x Infineon “VIP”) connect to the DELIC by means of the “ΙΘΜ-2000” time-division multiplexed highway.

• Analog port transceiver (Infineon “SICOFI-4 TE” codec) connects to the DELIC using the “IOM-2” TDM highway to provide 4 codec channels.

• Additional Analog Ports for Ext. MOH and PA Port also use a codec (Infineon “SICOFI-2 TE”) which connects to the DELIC using the “IOM-2” highway to provide 2 codec channels.

• While the Ethernet port transceiver (AMD AM79C874 “NetPHY”) connects directly to the MPC855T via the “Media Independent Interface” (Mil), it’s traffic ultimately gets transferred from the microcontroller to the DELIC for switching out onto the ISDN lines to provide internet access from PCs on the LAN for example.

The data is transferred from the Mil to an SCC (Serial Communications Controller) within the Processor and then out onto a PCM highway connected to the DELIC. Hence, the |E 0 3 0 6 θ 3 Ethernet data is also available to the DELIC in 8-bit timeslot format to be switched in any direction.

The main functions carried out by the DSP core in the DELIC are as follows; • Implementation of Layer 1 state machines for ISDN line and digital (Upn) Systemphone Ports.

• Non-blocking switching of 8—bit PCM timeslots.

• HDLC control to implement LAPD to allow for D channel handling.

HDLC is also used in some cases for B channel handling (e.g. during remote download of new system software).

In addition, spare capacity (processing power, program memory, data memory) in the DELIC DSP core can be used to carry out additional processing for features such as tone generation, conferencing, paging.

The DELIC has a full microprocessor address / data bus and is mapped into the microcontroller’s address space. All configuration of the DELIC and it’s attached VIPs takes place across this interface. Changes in status in any of the ports in the devices attached to the DELIC are relayed to the processor via interrupts.

Versatile ISDN Port / Transceiver.

Two VIPs are used in the embodiment. Configuration of the modes in which the VIPs and their individual ports operate takes place in the DELIC under the control of the microcontroller over the microcontroller address / data bus.

• VIPO (IC6) is configured to implement the front-end physical layer for eight 2-wire Digital Systemphone ports. The technique used is time compression multiplexing (otherwise known as Upn or “Ping-Pong”) which involves the parties at either end transmitting and receiving in turn rather than simultaneously. Payload and signalling information is transmitted in “2B +D” format as in the case of ISDN.

IE Ο 3 06 93 • VIP1 (IC7) is configured to electrically and functionally implement the front-end physical layer (Layer 1) for four ISDN S/T Interface ports as per ITU-T 1.430 and ETS 300 012. For “T” or “S” operation, the DELIC and VIP effectively implement “TE” or “NT” mode and the “F” or “G” state machines respectively as defined in ITU-T 1.430. The VIP is a front-end ISDN S/T transceiver conforming to 1.430 which implements all physical aspects of transmission to allow activation of Layer 1 (i.e. bit timing, framing, pulse amplitudes, data encoding / decoding to AMI etc).

The Microcontroller and the DELIC and VIP1 components together provide all Layer 1, 2 and 3 functionality to ETSI specifications as follows; Layer 1 : : ETS 300 012, Layer 2 : ETS 300 125, Layer 3 : ETS 300 102.

In this embodiment, the first three ports are permanently configured as T (Line) interfaces while the fourth can be configured by the user as either a T or an internal So Bus.

Configuration takes place via a jumper and system programming via the Ethemet browser.

Interface Circuitry for VIP0 and VIP1 (Pages 8 and 9).

The first three permanent‘T’ interfaces and the fourth ISDN Port (configurable as either T or So) are 8-pin RJ45 connectors conforming to ISO 8877 and ITU-T Recc. 1.430. Only four of the eight pins are used to carry the transmit and receive pairs. In the event of the fourth port being configured as an internal So bus, a DC voltage of 40V is applied between the transmit and receive pairs to feed power down to the terminals on the bus (TEls in ITU-T terminology). A push-fit connector can optionally be used to wire the S-Bus in cases where 4 - core telephone cable is preferered to RJ45 cable.

Synchronisation of System to C.O. Reference Clock by DELIC and VIP.

Before any ISDN lines are activated, the embodiment operates on a free running clock generated by the DELIC using Crystal XI (16.384 MHz) and configured by setting internal ΙΕ ο 3 0 6 95 registers in the DELIC. Both VIPs sit on the IOM-2000 TDM Highway and use the timing provided by the DELIC.

When an ISDN line is activated, VIP1 (ISDN) being connected to the central office (CO) provides a reference clock from the CO to the DELIC which must synchronise the two timing systems (internal from DELIC and external from the CO). It does this by means of an internal PLL (Phase Locked Loop) that ensures that the system is always synchronised to the CO so that no data is lost due to timing discrepancies when transmitting from the system to the ISDN. VIP1 also uses an external Crystal (X6) for increased clock accuracy to meet the requirements of CTR3 Euro-ISDN approvals.

Ethernet Port: MPC855T and Am79874 “NetPHY”.

The Ethernet LAN Port on the embodiment is realised by the MPC 855T (ICI), the Am79874 “NetPHY” (IC21) and the associated circuitry including crystal X3 and Shielded Ethernet Connector / Transformer Module CN5. CN5 is the point of connection to a node on an Ethernet.

If there is no LAN connection, a single PC can still be connected to the system via CN5 provided a crossover cable is used. This gives access to system programming via browser “webpages”. CN5 contains a transformer and EMI suppression chokes and together with the PHY and associated circuitry makes up the Ethernet physical layer interface.

The MAC (Media Access Controller) functionality is carried out by the MPC 855T and the connection between the Processor and PHY is via the Mil (Media Independent Interface). Each system embodying the invention has a unique MAC address.

In order to connect the Ethernet traffic into the main switching core of the system, one of the generic PCM highways on the DELIC is connected to one of the SCCs on the MPC855T so that the Ethernet traffic is passed to the DELIC in standard 8-bit PCM timeslot format. Therefore, if a PC on the LAN uses the system as a router for Internet access, the data from the PC arrives at the DELIC through the PHY and microcontroller and then gets switched by the DELIC out to the network via VIP1 which implements the T (Line) interface.

IE U3 06 9 3 Analog Extensions.

The Analog Extension section consists of two functional blocks; 1. A four-channel Codec, 2. Four extension driver “SLICs” and ring filter.

SICOFI-4 TE QUAD CODEC (D/A & A/D Converters).

This codec IC has a digital side and an analog side. On the digital side, information travels across two interfaces; a. Control / Status / Configuration Information to and from microcontroller. This quad codec IC is connected to the DELIC via one of it’s “IOM-2” TDM highways. The IOM-2 is very similar to a generic PCM highway but in addition, some of it’s timeslots are used for the control and status monitoring (serially) of physical layer interface components. However, in this case the IOM-2 interface is being used as a generic PCM highway as the SICOFI-4 TE cannot be controlled in this fashion. It therefore takes it’s commands and configuration information and relays status information back to it’s controller (in this case the microcontroller) via a four-wire serial SPI interface (/CS, DCLK, DIN, DOUT). The four channels are completely programmable for impedance matching, frequency response, correction, gain, tone generation etc. and all of these are controlled / configured over the SPI interface. b. Digitised Voice Information. Meanwhile its payload information on the digital side (the voice timeslots transiting to and from the DELIC switching core) travel on the PCM highway (FSC, DCL, BCL, DU,DD) in standard 8-bit timeslot format. The data rate on DU and DD is 768 kHz with a DCL (Data Clock) rate of 1.536 MHz and a BCL (Bit Clock) rate of 768 kHz. The frame synchronisation signal (FSC) from the DELIC is at 8 kHz and is common to all SICOFI and VIP components in the System regardless of whether they are on the IOM-2 or IOM-2000.

The circuitry around IC10 and IC27 is used to derive BCL from DCL (divide by 2) while also ensuring that BCL always has the correct phase relationship with the frame synch signal FSC.

IE Ο 3 Ο 6 θ 3 On the snalog side, each of the four channels has an input and output path; Vin => coming from the Analog Extension INTO the system.

Vout => going OUT TO the Analog Extension from the system.

For each extension, these two paths connect to a SLIC (Subscriber Line Interface Circuit) which takes care of all of the extension drive requirements.

Analog Extension Driver Circuits: Intersil HC55184 SLICs.

Each extension circuit comprises an Intersil HC55184 SLIC as shown in the figures. These take care of all functions such as extension feed and DC conditions, off-hook detect, polarity reversal for CLI transmission, current limiting and ringing.

The Ringing is produced as an amplified version of the signal appearing at input pin “VRS”. In this case, ringing is controlled by a filtered sinusoidal signal coming from the Processor and filtered by the circuitry based around IC26.

The state machine within each SLIC is controlled by the three pins FO, FI and F2 and in the case of the embodiment, these signals are piloted not by the microcontroller directly but by I/O pins on the SICOFI-4 TE which are ultimately controlled by writing to registers within the SICOFI-4 TE over the SPI interface.

The four Green LEDs which indicate the status of the four ISDN ports are also driven in this way (LD100 - LD400).

DTMF Receivers.

Two DTMF receivers are provided, IC15 & IC16 (HT9170D). Each of these can be connected to any of the four analog voicepaths coming into the system from the SLICs.

When an analog extension goes off hook, or whenever a DTMF receiver is required, it is assigned the next available receiver in a circular fashion. The data output from the DTMF receivers is read by the Microcontroller via input ports.

IE 0 3 06 9 5 Resistors R700, 701, 704, 705 set the input gain (and hence the sensitivity of the receivers). Resistors R702, 703 & Capacitors C703 & 707 set the valid tone on / off times. Crystal X2 provides a 3.579 MHz clock for the two receivers.

FSK Transmitter.

IC20 is an FSK Transmitter (CMX654), used for the transmission of CLI (Caller Line Identification) information down to the four analog extensions. Multiplexer ICI9 (74HC4051) directs the FSK information to the selected extension. These ICs and associated amplifier circuitry are fitted for markets where the format for CLI information is FSK (as opposed to DTMF). IC20 takes its 3.579 MHz clock signal from crystal X2.

MISCELLANEOUS FUNCTIONS Dialtone Dialtone is delivered to the various ports as follows; Analog: Each channel in the SICOFI-4 TE uses it’s own tone generators to provide dialtone (and other tones) for transmission down to it’s analog extension. The same Tone Generators also generate DTMF tones to send CLI information to the phones in markets where DTMF is used for CLI rather than FSK.

Systemphones: Similarly to each SICOFI-4 TE channel, each systemphone contains its own Tone Generators and these are used to generate dialtone (and other tones) locally in each phone.

ISDN Phones: Dialtone (and other tones) are transmitted down the B channels to ISDN phones or other devices on the S-bus that need them. The tones are generated by firmware routines using up spare DSP capacity in the DELIC core.

Music-On-Hold Internal music-on-hold melody (or beep) generation is carried out by a DSP routine in the Infineon DELIC. External music-on-hold sources (E.g. CD Player) can be plugged into IE 0 3 06 9 5 CN11 (Phono Jack). The analog signal is converted by the SICOFI-2 channel (in the input direction) to digital format after which it can be switched by the DELIC to any other port.

PA / Paging Port.

When paging, digitally encoded voice coming from any extension is switched by the DELIC to the SICOFI-2 channel (output direction) which, after buffering goes out to the speaker connected to phono jack CN10.

System Status LEDs.

There are 11 System Status LEDs (Light Emitting Diodes), nine of which are green in colour and two of which are Red as follows; LED Colour Function LD1 Red System Power / Status LD801 Red “Collision” on Ethernet Port LD800 Green “Link” on Ethernet Port LD100 Green Tl Status LD200 Green T2 Status LD300 Green T3 Status LD400 Green T4 / So Bus Status LD3000 Green ADSL / Ethernet Status LD3001 Green ADSL / Ethernet Status LD3002 Green ADSL / Ethernet Status LD3OO3 Green ADSL / Ethernet Status Data Port An RS232 port is provided via D9 connector CN13 to enable connection of a PC to the system (in the event that it can’t be connected to the Ethernet port using a crossover cable). IC25 (MAX3223) and associated capacitors provide a buffer circuit to convert from the Digital 5V world to the RS232 ±12V world. This port is intended for use as a Diagnostics aid. As it is positioned under the plastic main cover and not in the access area, it is not accessible during normal operation.

IE 0 3 0 6 θ 5 Auxiliary Relays Two relays (RL1 and RL2) are provided for auxiliary functions (door - opening, connection of a central bell etc.). Connection to each relay is via two poles. The connections for both relays are in the four-pole push-fit connector CN4 and are marked as “RL1” and RL2”.

Battery Connector.

If the optional Battery Backup (BBU) Module is fitted to the system to allow normal system operation during a mains power outage, the necessary 12V 7Ah battery is connected to the system via Push-fit connector CN12.

The battery is normally housed in a separate wall mountable plastic enclosure to match the system enclosure and the pair of battery cables supplied include a 5 A fuse on the positive (RED) battery lead to avoid rapid battery discharge in case of a short-circuit in the cabling outside the system.

Connectors for Ethernet / DSL Daughtercard Connectors CN6 (Shielded Ethemet RJ45) and CN8 (Standard RJ45) in the access area are for the optional Ethemet Router I DSL card and allow for the connection of different configurations of two-wire DSL Line and Ethemet LAN I WAN connections depending on the functionality of the daughtercard.

REMOTE DOWNLOAD Remote download is a feature whereby the system may be reprogrammed remotely over the ISDN network. Downloaded software arrives over the ISDN in compressed format and is first stored in the upper half of Flash memory.

After the new compressed file has been checked, the old version of code in the lower half of Flash is erased and the new version is copied into the lower half in its place. At this point, the system resets and starts up by unzipping the new version of code into SDRAM for normal boot-up. The upper half of Flash is now free to accept another code download.

IE Ο 3 06 9ϊ It is to be understood that the invention is not limited to the specific details described herein, which are given by way of example only, and that various modifications and alterations are possible without departing from the scope of the invention.

Claims (12)

CLAIMS:

1. A voice and data exchange for use in telecommunications, the voice and data exchange comprising a private automatic branch exchange (PABX), means for controlling the PABX and means for communicating with the controlling means of the PABX via a non-proprietary interface.

2. A voice and data exchange as claimed in Claim 1, in which the controlling means of the PABX comprises a server, pages provided by the server and a protocol for file transfer into and out of the PABX.

3. A voice and data exchange as claimed in Claim 1 or Claim 2, in which the PABX includes an embedded service provider to support computer-telephony integration (CTI) applications.

4. A voice and data exchange as claimed in any preceding claim, in which memory means are provided in the PABX for recording diagnostics information and a history of the PABX’s operation.

5. A voice and data exchange as claimed in Claim 4, in which the PABX includes a network interface through which the content of the memory can be accessed remotely.

6. A voice and data exchange as claimed in any preceding claim, in which the PABX can act as a data switch and a full IP data router for the network to which it is attached, and can present an API between a PABX and a softswitch element.

7. A voice and data exchange as claimed in any preceding claim, in which the PABX includes memory means and programmed means that, in the event of a crash, facilitate storage of information relating to the state of the PABX and its controlling means prior to the crash. IE 0 3 06 93

8. A voice and data exchange as claimed in Claim 5 and Claim 7, in which the stored information can be accessed through use of diagnostic tools communicating with the PABX over a network.

9. A voice and data exchange as claimed in any preceding claim in which the boot code of a PABX includes breakout points inserted at intervals, facilitating the addition of new sections of code to the boot code and the skipping of sections of boot code during execution; optionally in which the boot code is stored in re-programmable read-only memory.

10. A voice and data exchange as claimed in any preceding claim, in which the PABX can be reconfigured remotely from a first set of capacities and capabilities to a second set of capacities and capabilities.

11. A voice and data exchange as claimed in Claim 10, in which specific modules of the PABX can be modified by remote download.

12. A voice and data exchange for use in telecommunications, substantially in accordance with any of the embodiments herein described with reference to and as shown in the accompanying drawings.