Application module interface for bidirectional signaling and bearer channels in a private branch exchange (PBX) environment

An application module interface is disclosed that allows one or more modules to access voice or data channels in a private branch exchange environment that contains one or mole B channels (bearer channels) for transmitting voice or data signals, and one or more D channels (signaling channel) for transmitting data. The application module interface provides a control channel that allows a module to obtain and vary the status and configuration of a telephone terminal. The application module interface provides access to both directions of two B channels (B1 and B2) and one D channel. The application module interface is the only interface required to connect the two B channels (B1 and B2) and one D channel to or from the telephone terminal and the add-on module. A frame format includes a start bit (logic “1”), a number of data bits allocated to the D channels (D, D′) and B channels (B1, B1′, B2, B2′), and eight stop bits (logic “0”). A tip/ring, module allows an analog device, such as a facsimile machine or modem, to access the digital voice and data channels associated with the private branch exchange switch. An RS-232 or a Universal Serial Bus module allows a personal computer or other enabled device to interact with and control the operation of a telephone terminal for computer telephony integration applications.

FIELD OF THE INVENTION

The present invention relates generally to private branch exchange (PBX) switches, and more particularly, to a method and apparatus for allowing one or more modules to access voice or data channels on the private branch exchange.

BACKGROUND OF THE INVENTION

Within a corporate environment, telephone service is typically provided by a private branch exchange switch. A private brunch exchange switch is an on-site facility, that is typically owned or leased by a company or another entity. The private branch exchange interconnects the telephones within the facility and provides access to the public telephone system. Typically, a private branch exchange environment uses digital telephone terminals and digital switching. Digital private branch exchange switches were designed to handle analog voice traffic, with the switch performing an analog-to-digital conversion (DAC) so that digital switching can be used internally on the entity premises. Increasingly, however, private branch exchanges (PBX) are carrying data traffic as well as voice traffic. Typically, data calls are generally switched through a modem-pool to the private branch exchange for transmission to the Public Switched Telephone Network (PSTN).

While a private branch exchange allows an entity to efficiently provide access to communication services without necessarily having dedicated telephone lines for each employee, the private branch exchange often limits the types of communications equipment that may be connected to the PBX and the types of services that may be accessed over the PBX. For example, since the telephone terminals connected to the PBX are digital, it is often difficult, if not impossible, to connect an analog device to the PBX. In addition, the communications protocols and hardware specifications of a given private branch exchange are often proprietary to the manufacturer of the PBX. Thus, it is often difficult, if not impossible, to connect equipment manufactured by another manufacturer to the PBX.

Adjunct processors have been proposed for use with private branch exchanges (PBXs) to supplement and enhance the telecommunications services provided by the PBX. For example, a voice mail system is often used with a PBX to provide users with voice messaging capabilities. In order to work together, the PBX and the adjunct processor must be able to communicate with each other. This is typically accomplished by means of a digital control data link, such as the DCIU link, commercially available from AT&T, that interconnects the PBX control processor with the adjunct processor.

In addition, other interfaces have been proposed or suggested that allow other types of equipment to be connected to a private branch exchange. For example, the 8411 terminal, commercially available from Lucent Technologies Inc., of Murray Hill, N.J., provides a tip/ring interface that allows analog devices to be connected to the private branch exchange and an RS-232 (passageway) interface that allows a computer to be connected to the PBX and permits Computer Telephone Integration (CTI). These other interfaces, however, including the 8411 terminal, are typically designed specifically to provide specific features and to operate with the particular communications protocol and/or hardware specification of a given private branch exchange manufacturer, or telephone terminal manufacturer. Current interfaces are unable to support additional features that may be desired by a customer.

As apparent from the above-described deficiencies with conventional techniques for connecting devices to a private branch exchange switch, a need exists for a standard interface to the private branch exchange that allows one or more modules to access voice or data channels on the private branch exchange. A further need exists for an interface to the private branch exchange that utilizes an integrated digital telephone chip. Yet another need exists for an interface to the private branch exchange that permits a module to support additional features for the private branch exchange.

SUMMARY OF THE INVENTION

Generally, an application module interface is disclosed that allows one or more modules to access voice or data channels in a private branch exchange environment that contains one or more B channels (bearer channels) for transmitting voice or data signals, and one or more D channels (signaling channel) for transmitting data. In addition, the application module interface provides a control channel that allows a module to obtain and vary the status and configuration of a telephone terminal.

According to one aspect of the invention, the application module interface provides access to both directions of two B channels (B1and B2) and one D channel. The application module interface is the only interface required to connect the two B channels (B1and B2) and one D channel to or from the telephone terminal and the add-on module. In one embodiment, the application module interface utilizes a frame format that includes a start bit (logic “1”), a number of data bits allocated to the D channels (D, D′) and B channels (B1, B1′, B2, B2′), and eight stop bits (logic “0”). Thus, there are two D channels (D, D′) for transmitting the D data in both directions and four B channels for transmitting the B1and B2data in both directions.

A tip/ring module allows an analog device, such as a facsimile machine or modem, to access the digital voice and data channels associated with the private branch exchange switch. In addition, an RS-232 (passageway) or a Universal Serial Bus module allows a personal computer or other enabled device to interact with and control the operation of a telephone terminal for computer telephony integration (CTI) applications. The application module interface is physically located after the telephone terminal. The application module interface has a logical position, however, between the telephone terminal and the private branch exchange. Thus, the application module interface can monitor, use, alter, supply or simply pass through any of the two B channels (B1and B2) or one D channel (signaling channel) to the telephone terminal.

DETAILED DESCRIPTION

FIG. 1illustrates a private branch exchange switch110connected to a telephone terminal120. According to a feature of the present invention, the telephone terminal120is connected to (or provides) an application module interface130, discussed further below, that allows one or more modules140to access voice or data channels. For example, one illustrative implementation of the module140allows an analog device, such as a facsimile machine (not shown) or modem (not shown), to access the digital channels associated with the private branch exchange switch110. In addition, the application module interface provides a control channel, discussed below, that permits a module to obtain and vary the status and configuration of a telephone terminal.

It is noted that the application module interface130may be embodied as a separate unit independent of the telephone terminal120, as shown inFIG. 1, or may be integrated with the telephone terminal120, in a manner discussed below. The telephone terminal120may be embodied, for example, as a ProLogix™ terminal6416or6424, commercially available from Lucent Technologies, Inc. of Murray Hill, N.J. In addition, the telephone terminal120can be embodied as one or more of a handset, a loudspeaker and a headset.

Typically, a private branch exchange switch110, such as a Definity™ PBX or a Merlin Legend™ PBX, commercially available from Lucent Technologies, Inc. of Murray Hill, N.J., contains two B channels (bearer channels), for transmitting voice or data signals, and one D channel (signaling channel) for transmitting data. It is noted that the D channel is sometimes referred to as the “S” channel.

According to a feature of the present invention, the application module interface130provides access to both directions of the two B channels (B1and B2) and the one D channel. In addition, in accordance with a further feature of the invention, the application module interface130provides a local control channel, C, for communicating with the application module(s)140connected to a telephone terminal120. The particular frame format used by the application module interface130is discussed below in conjunction withFIG. 3. A representative control channel format used by the application module interface is discussed below in conjunction withFIG. 4.

Although the application module interface130is physically located after the telephone terminal120, as shown inFIG. 1, the application module interface130has a logical position (“linked position”) between the telephone terminal120and the private branch exchange110. In other words, signals can initially by-pass the telephone terminal120and can be processed by a module140via the application module interface130. Thus, as discussed further below, in various embodiments, the application module interface130can monitor, use, alter, supply or simply pass through any of the two B channels (B1and B2) or one D channel (signaling channel) to the telephone terminal120.

According to another feature of the invention, the application module interface130is the only interface required for connecting the control, C, and two B channels (B1and B2) and the one D channel to or from the telephone terminal120and the add-on module140. In addition, the application module interface130provides a number of hardware connections to the telephone terminal120and/or modules140, discussed in conjunction withFIG. 5, that permit the presence of a telephone terminal120and/or a module140to be detected, as well as to detect the disruption of an AMI connection, for example, due to a device losing power, or a transient event that corrupts the data stream and causes a loss of synchronization.

Integrated Telephone Chip Implentation

According to one feature of the present invention, the application module interface130may be implemented as part of an integrated digital telephone chip200, shown inFIG. 2. The integrated digital telephone chip200may be embodied, for example, as the Global Digital Telephone (GDT) chip (part T7951), commercially available from Lucent Technologies, Inc. of Murray Hill, N.J., as modified herein to implement the features and functions of the present invention. As discussed further below, each of the telephone terminals120and the modules140may be based on the same integrated digital telephone chip200.

As shown inFIG. 2, in addition to the application module interface130, the integrated digital telephone chip200includes one or more line interface unit(s) (LIU)210, a main audio processor220and a well-known high-level data link controller230. For a detailed discussion of a suitable line interface unit(s) (LIU)210, see, for example, Siemens Semiconductor, Component No. PEB2095 (ISDN Burst Tranceiver Circuit) data sheet (June 1992), incorporated by reference herein, as modified herein to provide features of the present invention. For a detailed discussion of a suitable main audio processor220, see, for example, Advanced MicroDevices, Component No. Am79C30A (Digital Subscriber Controller) data sheet (March 1989), incorporated by reference herein, as modified herein to provide features of the present invention.

Generally, the line interface unit(s)210support the two B channels (B1and B2) and one D channel. Generally, the main audio processor220performs the digital-to-analog (DAC) and analog-to-digital (ADC) conversions of the audio signals. The main audio processor (MAP)220performs CODEC functions (2 receive paths and 1 transmit path) and filter functions using digital signal processing (DSP) techniques to provide substantial flexibility and programmability. In one implementation, the main audio processor220provides three interfaces, namely, a handset interface, an internal speakerphone interface and a headset interface. A tone ringer output is provided to give a ringing signal independent of the operation of the voice signals. A dual-tone multi-frequency (DTMF) generator can be used to generate a signal consisting of two tones, where the frequency and amplitude of each tone is programmable.

Generally, the high-level data link controller (HDLC)230is used for the “D” channel. The high-level data link controller230provides HDLC framing, CRC generation and checking, zero insertion/deletion, and either flag or mark idling.

In the embodiment shown inFIG. 2, the data for the high-level data link controller230comes from the D channel of the line interface unit210. In an alternate implementation (not shown), the data for the high-level data link controller230can come from the D channel of the application module interface receiver (AMR) of the application module interface130. In either case, the data will be provided at the nominal 16 kilo-bits-per-second rate, but a control bit in the HDLC control register (not shown) is used to determine whether to use all bits or just every other bit (to support an 8 kilo-bits-per-second D channel).

In the embodiment shown inFIG. 2, the data for the D channel of the transmitter of the line interface unit210is selected by a multiplexer265from the transmitter of the high-level data link controller230or from the D′ channel of the application module interface receiver of the application module interface130. In an alternate implementation (not shown), the data for the D channel of the transmitter of the line interface unit210can be set to all one's.

Likewise, the data for the B1channel of the transmitter of the line interface unit210is selected by a multiplexer255from (i) the output of the main audio processor220(MAP-OUT), (ii) the B1′ channel of the application module interface receiver of the application module interface130, or (iii) can be set to all one's. In an alternate implementation (not shown), the data for the B1channel of the transmitter of the line interface unit210can be obtained from the B1channel of a peripheral port input (not shown). It is noted that the peripheral port is a synchronous interface that connects an external codec or an HDLC controller to the integrated digital telephone chip200.

Similarly, the data for the B2channel of the transmitter of the line interface unit210is selected by a multiplexer260from (i) the output of the main audio processor220(MAP-OUT), (ii) the B2′ channel of the application module interface receiver of the application module interface130, or (iii) can be set to all one's. In an alternate implementation (not shown), the data for the B2channel of the transmitter of the line interface unit210can be obtained from the B2channel of the peripheral port input (not shown).

As shown inFIG. 2, the data for the input to the main audio processor220(MAP-in) is selected by a multiplexer250from (i) the B1or B2channels of the receiver of the line interface unit210, (ii) the B1, B1′, B2or B2′ channels of the application module interface receiver of the application module interface130, or (iii) an “all quiet” signal.

The application module interface transmitter (AMX) of the application module interface130, shown inFIG. 2, uses a set of multiplexers270,275,280,285and290to select data for each of the six AMI data slots (D, D1′, B1, B1′, B2, B2′). As shown inFIG. 2, the data for the D channel of the application module interface transmitter is selected from (i) the D channel of the line interface unit210, or (ii) can be set to all zeroes. Alternatively, the D channel of the application module interface transmitter can also be selected from (i) the D channel of the application module interface receiver, or (ii) the transmitter of the high-level data link controller230. The D′ channel of the application module interface transmitter is generally set to all zeroes. Alternatively, the D′ channel of the application module interface transmitter can also be selected from (i) the D′ channel of the application module interface receiver, or (ii) the transmitter of the high-level data link controller230.

The data for the B1channel of the application module interface transmitter is selected from (i) the B1channel of the line interface unit210, or (ii) can be set to all zeroes. Alternatively, the B1channel of the application module interface transmitter can also be selected from (i) the B1or B1′ channel of the application module interface receiver, (ii) the output of the muin audio processor220; (ii) the B1channel of a digital signal processor (DSP) (not shown), or (iv) the B1channel of the peripheral port input (not shown).

It is noted that the digital signal processor port provides a means to connect a common digital signal processor chip, such as an 8051-type microcontroller, to the integrated digital telephone chip200to supplement the processing capability of the main audio processor220. The digital signal processor port can be connected either with the main audio processor220or with the application module interface130. In addition, the module140can be connected to the digital signal processor as well.

Likewise, the data for the B1′ channel of the application module interface transmitter is selected from (i) the output of the main audio processor220(MAP-out), or (ii) can be set to all zeroes. Alternatively, the B1channel of the application module interface transmitter can also be selected from (i) the B1or B1′ channel of the application module interface receiver, (ii) the B1channel of the line interface unit210; (iii) the B1′ channel of a digital signal processor (not shown), or (iv) the B1channel of the peripheral port input (not shown).

The data for the B2channel of the application module interface transmitter is selected from (i) the B2channel of the line interface unit210, or (ii) can be set to all zeroes. Alternatively, the B2channel of the application module interface transmitter can also be selected from (i) the B2or B2′ channel of the application module interface receiver, (ii) the output of the main audio processor220; (iii) the B2channel of a digital signal processor (not shown), or (iv) the B2channel of the peripheral port input (not shown).

Likewise, the data for the B2′ channel of the application module interface transmitter is selected from (i) the B2channel of the application module interface receiver, or (ii) can be set to all zeroes. Alternatively, the B2′ channel of the application module interface transmitter can also be selected from (i) the B2′ channel of the application module interface receiver, (ii) the B2channel of the line interface unit210; (iii) the B2′ channel of a digital signal processor (not shown), (iv) the B2channel of the peripheral port input (not shown), or (v) the output of the main audio processor220(MAP-out).

B and D Channel Data

When there are multiple application modules, as shown inFIG. 2, data from the two B channels (B1and B2) or the one D channel flows downstream from the telephone terminal120(the receiver of the LIU210) and through each application module140-1through140-N in series. Along the downstream path, the data is changed as needed. The last module140-N in the series chain sends its AMI output back upstream, again passing through each intervening module140-N-1through140-1, without modification.

As shown inFIG. 2, the integrated digital telephone chip200provides two receivers, referred to as an application module interface receiver and an application module upstream receiver (AMUFPR), and two transmitters, referred to as an application module interface transmitter and an application module upstream transmitter (AMUPX). The application module interface transmitter is the primary output for “downstream” communications with the application module interface130and the module(s)140-1through140-N. In other words, the application module interface transmitter is the one transmitter used on terminals, and as the downstream interface on modules140. Data from the two B channels (B1and B2) or the one D channel can be directed from a functional block of the integrated digital telephone chip200to the application module interface transmitter.

As shown inFIG. 2, the application module interface130and each module140includes an application module upstream transmitter. The application module upstream transmitter is the secondary output for the application module interface130for upstream communications from the chained modules140-1through140-N to the telephone terminal120. The application module upstream transmitter is not used on a telephone terminal120.

The application module interface receiver is the primary input for “upstream” communications between the application module interface130and the module(s)140-1through140-N. In other words, the application module interface receiver is the one receiver used on terminals, and as the downstream interface on modules140. Data from the two B channels (B1and B2) or the one D channel can be received by the application module interface receiver from a module140and directed to a functional block of the integrated digital telephone chip200.

As shown inFIG. 2, the application module interface130and each module140includes an application module upstream receiver. The application module upstream receiver is the secondary input for the application module interface130. The application module upstream receiver is used in application modules140to receive “upstream” AMI data from modules140-1through140-N that are farther “downstream.” Data from die two B channels (B1and B2) or the one D channel that is received by an application module upstream receiver can only be passed out on the application module upstream transmitter unchanged. The application module upstream receiver is not used on a telephone terminal120. For the last application module140-N in the series chain, there will be no valid data on the application module upstream receiver. In this case, the last application module140-N must initiate upstream B and D channel data flow by outputting the B and D data on its application module upstream transmitter.

Thus, there are two operating modes for the application module upstream transmitter. In a first mode, referred to as the “pass-through mode,” the application module upstream transmitter transmits B and D data from the application module upstream receiver. The pass-through mode is used by modules140in the middle of the series chain. In this case, timing for the application module upstream transmitter is based on the application module upstream receiver. There is a one bit time delay between frames (and data) received on the application module upstream receiver and the output on application module upstream transmitter.

In a second mode, referred to as the “turn-around mode,” the application module upstream transmitter transmits B and D data from application module interface transmitter sources. The application module upstream transmitter is used by the last application module140-N in the series chain. Here, timing for the application module upstream transmitter is the main 8 kilo-hertz (KHz) frame timing of the integrated digital telephone chip200, as discussed below.

Although a telephone terminal120is always the most upstream device, the telephone terminal120only uses application module interface receiver and application module interface transmitter pins, rather than application module upstream receiver and application module interface transmitter pins. Thus, while a telephone terminal120really only looks downstream to the integrated digital telephone chip200, the telephone terminal120appears as follows. The telephone terminal120transmits control channel data downstream on the application module interface transmitter. The telephone terminal120receives control channel data from upstream on the application module interface receiver (which is really from downstream). The telephone terminal120will thus enable its downstream control channel transmitted (AMX) and its upstream control channel receiver (AMR). It is noted that telephone terminals120must use the application module interface receiver, because B and D data from the application module upstream receiver can only be passed on to the application module upstream transmitter.

Control Channel Data

Control channel communications between the application module interface130and the application modules140-1through140-N utilize a point to point connection. The telephone terminal120sends control channel data to the first module140-1, and receives control channel data generated by the first module140-1. The first module140-1, in turn, in addition to sending and receiving control channel communications with the telephone terminal120, also sends control channel data to the second module140-2, and receives control data from the second module140-2. The contents of the control channel on the application module upstream transmitter is always the upstream control channel. Only the B and D data gets “turned around” in the manner described above for the “turn-around mode.” In addition, while the application module upstream transmitter is in the “turn-around mode,” the application module upstream receiver can still be used to receive control channel information from downstream modules. In this manner, a newly added downstream module140can be detected.

AMI Frame Contents

FIG. 3illustrates an illustrative format of a start/stop data frame300used by the application module interface130. As shown inFIG. 3, each 125 micro-second frame contains one start bit (logic “1”), three control channel bits, C, and 36 total data bits allocated to two D channels (D, D′), four B channels (B1, B1′, B2, B2′) and eight stop bits (logic “0”). Thus, there are two D channels (D, D′) for transmitting the D data in both directions. The two D bits typically contain the received D channel from the line interface unit210. The two D′ bits typically contain the transmit D channel destined for the line interface unit210.

The eight B1bits typically contain the received B1channel from the line interface unit210(voice or data). The eight B1′ bits typically contain transmit voice or data signal destined for the line interface unit210B1channel. The eight B2bits typically contain the received B2channel from the line interface unit210(voice or data). The eight B2′ bits typically contain transmit voice or data signal destined for the line interface unit210B2channel.

In the illustrative implementation, the data rate is 384 kilo-bits-per-second (Kbps), which makes the bit width 2.604 micro-seconds. AMI received data is sampled in the middle of each bit time. For each received frame300, the bit timing is resynchronized to the received start bit.

As shown inFIG. 3, each frame is 125 microseconds (8 KHz). The 8 KHz frame timing can be derived from the active line interface unit210, the received application module interface receiver signal, or an internal oscillator. In one implementation, the clock source is selected under software control from the external microprocessor. In normal operation, the telephone terminal120recovers the 8 KHz timing from the line interface unit210, and the modules140recover the 8 KHz timing from their received application module interface receiver signal. Once AMX or AMUPX communications begin outputting a frame, the output continues through all of the data fields and at least five stop bits. Any change or shift in the 8 KHz timing results in the application module interface transmitter omitting one to three stop bits or outputting extra stop bits. The application module interface transmitter or application module upstream transmitter will not start outputting a new frame in the middle of a current frame, which would make start bit detection unreliable. This applies both when the 8 KHz timing source is changed, for example, by software, and when the 8 KHz source itself (from the line interface unit210or application module interface receiver) slips. In addition, when the application module interface transmitter or application module upstream transmitter is first enabled, zeroes will be output until the 8 KHz frame time is reached. The AMI frame output then begins with a start bit, up to 125 microseconds after being enabled.

AMI Control Channel

As previously indicated, the AMI frame300(FIG. 3) includes three “C” bits for the control channel. The control channel field actually contains one flag bit and two data bits. A complete control channel data word is split over five consecutive AMI frames and contains a total of nine data bits and a parity bit, transmitted least significant data bit first. The parity bit creates “even parity” for the ten total bits, and is generated by the integrated digital telephone chip200. The first of the three “C” bits is the flag bit. The flag bit is set to one to indicate the start of a new control channel word, or zero otherwise.

FIG. 4illustrates a representative control channel format400, where bits are sent in order from left to right. Thus, each control channel word requires five frames (625 microseconds). When there is no control channel data to send, all three “C” bits are set to zeroes. An “invalid data” error is detected by a control channel receiver when the flag bit contains a one in two or more out of five consecutive frames. If an “invalid data” condition is detected, the control channel receiver flags the error and takes the newest one flag to be the start of a control channel word.

Control Channel Protocol

According to a further feature of the present invention, a start-up and tear-down mechanism is implemented using three hardware control signals. As previously indicated, the application module interface130does not utilize a separate frame synchronization in the illustrative embodiment. Thus, the start-up mechanism allows detection of a start bit. If an application module interface receiver is first enabled when AMI data is present, the application module interface receiver may mistakenly process a data bit as a start bit, and get out of synchronization, thereby invalidating all data. Thus, a cautious AMI start-up mechanism is needed. Likewise, should data get out of synchronization later, recovery must be fairly rapid to avoid significant loss of D-channel messages and corruption of voice signals.

FIG. 5illustrates the AMI electrical interface500. As shown inFIG. 5, the AMI electrical interface500includes a module present (MP) signal that indicates that a module140is plugged into the AMI electrical interface500. It is noted, however, that the module140may not be powered. In addition, the AMI electrical interface500includes a module receiving OK (MOD-OK) signal indicating that the module140is receiving valid AMI control channel messages. This signal is output from the module140and is active low in the illustrative embodiment.

The AMI electrical interface500also includes a phone receiving OK (PHONE-OK) signal indicating that the telephone terminal120is receiving valid AMI control channel messages. This signal is output from the telephone terminal120and is active low in the illustrative embodiment. An AMI to module (AMI→MOD) signal is the actual bitstream from the telephone terminal120to the module140. An AMI to phone (AMI→PHONE) signal is the actual AMI bitstream from the module140to the telephone terminal120. As discussed further below, the MP, MOD-OK and PHONE-OK signals form a hardware level handshake between the telephone terminal120and module140for AMI start-up and recovery, in accordance with the present invention.

FIGS. 6 and 7illustrate the AMI start-up procedure from the point of view of the telephone terminal120and a module140, respectively. It is noted that the telephone terminal120initializes with its application module interface receiver and application module interface transmitter disabled. The application module interface transmitter is high impedance. The module140enables its application module interface receiver about 30 milliseconds after the module140begins the AMI start-up process. The application module interface receiver of the module140will not be receiving valid data until the telephone terminal120enables its application module interface transmitter. Thus, the module140should ignore data errors during this phase of the AMI start-up and only start counting errors after a valid message has been received.

As shown inFIG. 6, during the initial start-up condition610, the application module interface receiver and the application module interface transmitter of the application module interface130in the telephone terminal120are off. In addition, the PHONE-OK signal (FIG. 5) is set to false. Once the phone recognizes that the module present (MP) signal (FIG. 5) is active at stage620, the phone will set the data fields in the application module interface transmitter to zeroes at stage630for at least 10 milliseconds, allowing the application module interface receiver of the module to synchronize to the received AMI start bits. After the end of the ten millisecond interval is detected at stage640, the phone will begin sending a control channel activity message, discussed below, once every ten milliseconds during stage650.

Meanwhile, as shown inFIG. 7, when the module receives the first AMI control channel activity message from the telephone terminal120, as detected at stage740, the module140will assert its module receiving OK (MOD-OK) signal (FIG. 5) and enable its application module interface transmitter during step750. The application module interface transmitter (AMUPX) of the module140is configure to output zeroes in all B and D data fields and no control channel data is sent so that the only ones output are start bits. Thus, the telephone terminal120can synchronize to the AMI start bits. The module140will then wait until the module140receives five link activity messages from the telephone terminal120, as detected during stage760, before the module140starts sending its own link activity message during stage770at ten milliseconds intervals. In this manner, the telephone terminal120can detect the module receiving OK (MOD-OK) signal and enable its application module interface receiver (at stage670) while only start bits are being sent. It is noted that 40 milliseconds will elapse between the five messages and the telephone terminal120needs up to 30 milliseconds to detect the MOD-OK signal and enable its application module interface receiver. Thus, there is a 10 millisecond interval before the module140sends its first message.

As shown inFIG. 6, the telephone terminal120detects the MOD-OK signal during stage660and enables its application module interface receiver. The telephone terminal120continues sending link activity messages every 10 milliseconds during stage670. As previously indicated, the module140starts sending link activity messages every 10 milliseconds during stage770after receiving the fifth link activity message from the telephone terminal120.

When the telephone terminal120detects the receipt of the first link activity message from the module during stage680, the telephone terminal120will assert the phone receiving OK (PHONE-OK) signal (FIG. 5) during stage690. The PHONE-OK signal indicates that the AMI connection is established and normal message activity may commence, as discussed below in the subsection entitled “Protocol.” Thus, during stage690, the telephone terminal120reduces the rate of the activity messages to one per 100 milliseconds. In addition, the telephone terminal120puts received D channel HDLC data onto its application module interface transmitter (AMX-D=LIUrx-D), and the telephone terminal120will allow I(B) channel data onto the application module interface transmitter. It is noted that all AMX-B* data will be zeroes until the module140sends a set voice channel configuration message, discussed below.

As shown inFIG. 7, when the module140detects the PHONE-OK signal during stage780, the module140should reduce its activity message rate to one per 100 milliseconds during stage790, and the module140may send a phone states request, discussed below, to obtain phone state information. Until the PHONE-OK signal is asserted by die telephone terminal120, only activity messages can be sent and no B or D channel data is allowed onto the application module interface130.

If the telephone terminal120fails to detect the MOD-OK signal during stage660, and receives an activity message from the module140within 500 milliseconds of detecting the module present (MP) signal, the telephone terminal120will disable its AMI transceiver and begin the start-up process over again. It is noted that the start-up process should take at most 110 milliseconds, with 30 milliseconds allocated for detecting the module present (MP) signal, 50 milliseconds allocated for detecting five activity messages from the telephone terminal120(during which time MOD-OK should be detected), and 30 milliseconds allocated for detecting the PHONE-OK signal.

The module140waits up to one second from initialization to detect that the PHONE-OK signal has been asserted by the telephone terminal120. If the one second time interval expires, the module140should reset its AMI transceiver, turn off the MOD-OK signal, and begin the start-up process over again after a delay of at least 30 milliseconds.

Recovery From Errors and Disconnects

Once the AMI connection has been established in accordance with the start-up process, the AMI connection may be disrupted, for example, due to a module140losing power, or a transient event that corrupts the data stream and causes a loss of synchronization. A disruption of the AMI connection may be detected using the hardware signals and the control channel protocol. If a disruption is detected, the detecting telephone terminal120or module140immediately turns off its receiving OK (PHONE-OK or MOD-OK) signal and disables its AMI transceiver. The detecting telephone terminal120or module140should then wait at least 30 milliseconds before attempting to restart the AMI, during stages695or795, respectively.

According to a feature of the present invention, a number of mechanisms may be utilized to detect the disruption of the AMI connection. A telephone terminal120or a module140may detect that its counterpart receiving OK (PHONE-OK or MOD-K) signal has been turned off. In addition, the telephone terminal120may detect that the module present (UP) signal has been turned off. A disruption can also be detected if a telephone terminal120or a module140fails to receive an activity message in a 250 millisecond interval, since control channel activity messages are normally sent every 100 milliseconds once the AMI connection is established. In addition, a disruption can also be detected if a telephone terminal120or a module140fails to receive an acknowledgement (ACK or NACK), discussed below, for an application message and its retransmission. Finally, a disruption can also be detected if excessive errors are received in the control channel data. In one embodiment, excessive is defined to be ten or more errors in a 100 millisecond interval.

Each telephone terminal120and module140maintains an error counter and increments the counter when the AMI control channel receiver reports a data error or a parity error, when a NACK is received, and when an unrecognized word is received with the ninth bit set (invalid first word of a message). Every 100 milliseconds each telephone terminal120and module140checks the error counter and then clears the error counter. It is noted that if the AMI connection is lost, the phone must restore its channel configuration to connect its audio section220and HDLC controller230(FIG. 2) directly to its line interface unit210.

The control channel receiver errors are parity errors and data errors. A parity error occurs when the ten bits (nine data bits plus one parity bit) make odd parity instead of even parity. A data error occurs when the control channel receiver detects an error in the non-data bit of the control channel field. It is again noted that the non-data bit is zero in all AMI frames300except those that contain the start of a new control channel word. A data error occurs if the non-data bit is one in two or more out of five consecutive frames.

Protocol

As discussed above in conjunction withFIG. 4, the control channel uses nine-bit data words (D0–D8) plus a parity bit (P) for error detection. The control channel protocol exploits the ninth bit to indicate the start of a message. In the illustrative embodiment, messages may be of two types, namely, an application message or a protocol control message. The application messages, discussed further below, come in various lengths and convey information, events and requests. According to a feature of the present invention, each application message must be acknowledged by the recipient, and only one application message may be outstanding (awaiting acknowledgement) at a time. If a second application message is sent before the first application message is acknowledged, the second application message will be ignored. If an error is detected during reception of an application message, the receiving unit should immediately send a negative acknowledgement (NACK) message. An outstanding or in-progress application message is retransmitted in response to a NACK message. If an application message is not acknowledged (ACK or NACK) within 50 milliseconds after the end of message transmission, the application message will be retransmitted. If the retransmission is not acknowledged within 50 milliseconds after the end of the message retransmission, the application module interface130is reset.

The protocol control messages, discussed further below, are single word messages used for acknowledgement and link activity. The protocol control messages do not require acknowledgement and thus are not retransmitted.

To cover the situation where an application message is properly received, but the acknowledgement is corrupted, a single-bit sequence number, S, is used in both application messages and acknowledgements. If an application message is received with the wrong sequence number, S, the application message will be acknowledged, but the message content will be ignored. An acknowledgement with the wrong sequence number, S, will be ignored. When a unit receives the first word of an application message that has the wrong sequence number, S, the unit can send the acknowledgement before receiving the entire message, since the body will be ignored anyway. The sending unit will accept an acknowledgement while it is still sending an application message only if it is retransmitting the application message. This would only happen in the following case:(i) Unit A sends an application message with sequence number, N;(ii) Unit B receives the application message and sends an ACK with sequence number, Not-N;(iii) The ACK gets corrupted so that Unit A does not receive a valid ACK;(iv) Unit A times out (50 milliseconds) and retransmits the application message with sequence number, N;(v) Unit B receives the first word of the retransmitted application message and recognizes that the sequence number is wrong. Unit B sends another ACK with sequence number, Not-N, and may do so before receiving the rest of the message. Unit B ignores the rest of the message.

This example illustrates the need for sequence numbers. Without sequence numbering, the retransmission (sent in step iv) would be considered a new message by Unit B (when received in step v).

Application messages are acknowledged even if the message is unknown or unsupported. The acknowledgement is protocol level, while the application message content is application level. Unknown and unsupported application messages will be ignored.

The first word of an application message conveys the length of the application message body (i.e., the length of the remainder of the message). The maximum length of the body is 15 words. To ensure that the control channel is operating, periodic activity messages are sent by both the telephone terminal120and modules140. It is again noted that the mechanism for the telephone terminal120to detect a module being disconnected or losing power is the hardware signals. Rather, the link activity messages are meant to ensure that the AMI control channel is functioning properly. In the illustrative embodiment, an activity message will be sent every 100 milliseconds. If no activity message is received for 250 milliseconds, then the application module interface130will be reset, in which case the telephone terminal120will resume a standard non-module configuration for the voice channels and D-channel.

It is noted that in order for the application module interface130to be useable for voice and data, the application module interface130must be virtually error free. Therefore, strong error detection mechanisms, such as cyclic redundancy checks (CRC), are not required for error detection in the control channel protocol. If a control channel word is received with the ninth bit equal to zero and an application message is not expected, then that word will be ignored. An invalid control channel word with the ninth-bit equal to one is considered to be an error and a negative acknowledgement (NACK) message will be sent.

Protocol Control Messages

FIG. 8illustrates a set of representative protocol control messages. Protocol control messages are single word messages with the following general format:

87654321010011XXXX
The ninth bit is always a one to indicate the start of a message, and bits four through seven are assigned a binary value of “0011” indicating a protocol control message. Bits zero through3identify the specific protocol control message.FIG. 8illustrates a set of representative protocol control messages. As shown inFIG. 8, a link activity message has a fixed coding of “100110000” and is used to prove that the control channel connection is working and active.

An acknowledgement message is coded as “10011111S”, where bit zero (S) is the sequence number bit. An acknowledgement is used to confirm that an application message has been received without error. The acknowledgement contains a single bit sequence number that equals the sequence number of the next expected application message. A negative acknowledgement (NACK) message is coded as “100110011” and indicates that an erroneous message was received. The error could be either a parity error, a data error, or an invalid first message word (including zero length for an application message).

Application Messages

Application messages are variable length messages. The first word of each application message has the following general format:

8765432101110Snnnn
The ninth bit is always a one to indicate the start of a message, and bits five through seven are always set to “110” indicating an application message. Bit four (S) is the sequence number bit. Bits zero through three (“nnnn”) indicate the length of the message that follows (i.e., a number between one and 15 indicating the number of words remaining in the message). Thus, the maximum total message length is 16 words, including the first application message header word. The bodies of the various individual application messages are summarized inFIG. 9for application message from a telephone terminal120and inFIG. 10for application messages from a module140. Each word of the body has its ninth bit set to zero. The first word of the body identifies the message and may include other information as well. It is noted that when the AMI connection is first established (or after a restart), the first application message sent by either side must have a sequence number, S, equal to zero.

Application Messages from Phone120

When the HDLC transmitter is unused, the telephone terminal120must send its S1-channel layer3messages to the module140by means of the AMI control channel. It is noted that the S1-channel is a D channel message regarding the B1 channel. The module140is responsible for sending the S1-channel transmit message, shown inFIG. 9, to the switch. The first word of the body identifies the application message as an S1-channel message. The rest of the application message body is the actual S1-channel layer3message which can be 1 to 6 words.

The phone states message provides the module140with information on various telephone states. The phone states message is sent in response to a request from the module140. The module140should request a phone states message after the AMI control channel is first established. The phone states message body contains five words as follows. The first word contains a phone states message identifier. The second word contains the telephone hook states, with the following code format: “0:MPKS:DVww.” Bit7(M) is set to one if Mute is on. Bit6(P) is set to one if the phone's overall hook state is off-hook. Bit5(K) is set to one if the handset switch-hook is off-hook. Bit4(S) is set to one if the speaker is on. Bit3(D) is set to one if the headset mode is active (or a separate headset jack is on). Bit2(V) is set to one if the voice path is disabled. Bits0–1(w) identify what is currently active if the phone is off-hook (P=1), with ww=00 indicating the handset, ww=01 indicating the speaker, ww=10 indicating the adjunct, ww=11 indicating the headset (if separate headset jack). It is noted that if the phone does not have a separate headset jack (i.e., the handset jack is used), then the handset will be shown as active. Group listen (spokesman) mode is indicated by the speaker being on (S=1), but the handset (or headset) being active (ww). Bits0–1should be ignored if the phone is on-hook (P=0). An adjunct is always active when it is on, so the adjunct state is revealed by ww.

The third word of the phone states message contains the line states and local modes, with the following code format: “0:ADSL:0TRF.” Bit7(A) is set to one for A-law voice or zero for μ-Law. Bit6(D) is set to one if the B-channel touch tone administration is set (dialing via B-channel messages versus DTMF). Bit5(S) is set to one if the line interface layer1state is active or is set to zero if layer1is down. Bit4(L) is set to one if the line interface loopback is active. Bit2(T) is set to one if the test mode is active. Bit1(R) is set to one if the select ring mode is active. Bit0(F) is set to one if feature (shift . . . ) is active.

The fourth word of the phone states message contains the ringer and handset volumes, with the following code format: “0:0rrr:Jhhh.” The ringer volume is specified in bits four through six. The handset volume is specified in bits zero through two. Bit3(J) is set to one if the phone has a handset jack.

The fifth word of the phone states message contains the speaker and headset volumes, with the following code format: “0:Jddd;Ksss.” The headset volume is specified in bits four through six. Bit7(J) is set to one if there is an independent headset jack (volume). The speaker volume is specified in bits zero through two. Bit3(K) is set to one if the phone120has a speaker.

In this manner, changes to modes, states, and settings can be conveyed by separate application messages from the telephone terminal120. It is noted that some states are controlled by D-channel messages and it is up to the module140to notice any such changes.

The line interface state change message, shown inFIG. 9, is sent when layer1of the protocol is established or lost (i.e., layer1comes up or goes down) or when the loopback state changes. The line interface state change message contains its information in a single word body coded as “0:1111:1SOL.” Bit2(S) is set to one if the state is layer1active. Bit0(L) is set to one if the line interface loopback is active (provided layer1is up, S=1).

The audio state change message, shown inFIG. 9, is sent by the telephone terminal120whenever its audio state changes. It is noted that this does not include changes to Mute, which are conveyed by a local button message, discussed below. The audio state change message includes what changed and the new state of all hook sources and what is now active. It is further noted that the active path may not have changed. For example, hanging up when the speakerphone is active. The audio state change message allows the telephone terminal120to request the voice path when the module also uses the B1 voice channel.

The audio state change message has a two word body. The first word identifies the message and the source of the state change, and is coded as “0:1111:0Nww,” where bits zero through one (ww) are the source, discussed below, and bit two (N) is the new state (set to one if the source is turning on, or going off-hook, and set to zero if the source is turning off, or going on-hook). The second word is coded as “0:MPKS:DVww,” in the same manner as the hook states word of the phone states message, discussed above. For both words, bits zero and one (ww) are coded as follows: 00 equals handset, 01 equals speaker, 10 equals adjunct and 11 equals headset (if there is a separate headset jack). It is noted that if the telephone terminal120does not have a separate headset jack (i.e., the handset jack is used), then the handset will be shown as active for the headset mode.

The phone hook state (bit6, P, in the second word) is the overall hook state of the telephone terminal120and does not include the hook state of the module140(reported to the phone via the module state change messages, discussed below). For example, if the handset is off book, and the user turns on the speaker phone (with group listen disabled), the following audio state change message will be sent: “0:1111:0101” and “0:1111:0001.” The first word indicates that the speaker has been turned on, and the second word indicates that mute is off, the phone is off-hook, the handset is off-hook, the speaker is on, the voice path is enabled, the headset mode is off and the speaker is active.

In a further example, the user in the first example now hangs up the handset, the following audio state change message will be sent: “0:1111:0000” and “0:0101:0001.” The first word indicates that the handset is going on-hook, and the second word indicates that mute is off, the phone is off-hook, the handset is on-hook, the speaker is on, the voice path is enabled, the headset mode is off and the speaker is active. It is noted that if mute had been on before the speaker was turned on, mute will be turned off when voice switches to the speakerphone. This change would be reflected in the audio state change message (Bit7, M, of word2).

The local button press message, shown inFIG. 9, is used to notify the module140when the user presses buttons, such as mute and volume, that do not generate a D-channel button state change message. It is noted that with the 6400-series telephone sets, the softkey navigation buttons, such as menu and next, always generate a D-channel button state change message, and are thus not considered local buttons. The message has either a one-word or a two-word body. Buttons that have only an on/off state use the one-word body, while buttons that have more information use the two-word body.

The first word of the body identifies the local button press message and the local button that was pressed. The local button press message is coded as “0:1110:bbbb,” where bits zero through three (bbbb) identify the button and possibly its on/off state as shown below.

It is noted that the states of mute, test, ring and feature, and the volume settings may be affected by other events that do not cause local button press messages. It is up to the module140to notice such events and options and handle them appropriately.

The dial key messages, shown inFIG. 9, are sent when the phone is set for DTMF touch tones and the user presses or releases a dialpad key. When the phone is set for B-channel dialing, button state change D-channel messages are sent instead. The dial key message uses a single ward body coded as “0:110R:kkkk,” where bit4(R) is set to zero for key press, or set to one for key release, and bits zero through three (kkkk) identify the key: with1to9for keys1to9,10for key0,11for key *, and12for key #.

The softkey label contents message, shown inFIG. 9, is sent only in response to a softkey label query message from the module. The softkey label contents message contains the 5-character softkey label and the button number in a six word application message body. The first word is coded as “0:1001:nnnn,” where bits zero through three (nnnn) are the softkey button numbers (1 to 12, or 1 to 15). The remaining five words contain the five characters of the softkey label.

The HDLC control confirmation message, shown inFIG. 9, is sent in response to a set HDLC control message from the module after the phone has switched HDLC routing to the application module interface130. The HDLC control confirmation message has a two-word body. The first word simply identifies the message with the fixed code of “0:0000:1110.” The second word is formatted as “0:Crrr:Lsss.” Bit7(C) is set to one to confirm that HDLC has switched from the telephone terminal120to the module140, or is set to zero to indicate that the phone already expected the module140to be doing HDLC. If C equals zero, the rest of the bits are ignored. Bit3(L) is the layer2status, with a value of one indicating link up, and a value of zero indicating link down. If L equals 1, then bits zero through two (sss) and bits four through six (rrr) are the S and R sequence numbers, respectively. The sequence numbers are provided so a that the module140may attempt to pick up control of layer2(HDLC) without having to reset the link.

Application Messages from Module140

The module140sends application messages to the telephone terminal120in order to set up configurations of the voice and signaling channels, control various telephone functions or states, and to pass received layer3S1-channel messages to the telephone terminal120.FIG. 10illustrates the bodies of the various individual application messages sent by the module140.

The set HDLC control message, shown inFIG. 10, instructs the telephone terminal120to let the module140handle HDLC and the D-channel link layer. Layer3D-channel messages will then be passed over the application module interface130control channel in application messages. The set HDLC control message has a single word body with a fixed coding of “0:0000:0101.” When the telephone terminal120establishes an AMI connection, the phone puts received HDLC data onto the application module interface130to the module140. In other words, the phone connects AMX-D to LIUrx-D. Hence, the module140should initialize its HDLC receiver and transmitter upon sending the set HDLC control message. In order to avoid losing D-channel messages, the phone120will wait until the HDLC is idle (no messages in progress) before connecting its line interface transmit D-channel (LIUtx-D) to the HDLC coming from the module140(AMR-D′). When the switch is made, the phone sends an HDLC control confirmation message, discussed above, to the module140. It is noted that there may be a glitch in the transmitted HDLC when the switch is made, but the HDLC control confirmation message takes 1.875 milliseconds to transmit, so that at least two valid flags should be sent after any glitch. The module140can thus begin transmitting D-channel messages right after receiving the HDLC control confirmation message. This is a one-way transfer of HDLC control. If the module140needs HDLC control, the module140has no reason to give control back to the telephone terminal120. The telephone terminal120will take control of HDLC again only if the AMI connection is lost or the telephone terminal120is reset.

The set voice channel configuration message, shown inFIG. 10, tells the telephone terminal120how to configure the digital voice channels. The phone changes voice channel configurations immediately upon receipt of this message. The set voice channel configuration message has a two-word body count. The first word simply identifies the message with the fixed code of “0:0000:1111.” The second word is coded as “0:ddvv:Xmmm,” and sets the configurations as follows. Bits4–5(vv) control the source of the phone's line interface transmit B1 channel “voice” (LIUtx-B1). Bits6–7(dd) control the source of the phone's line interface transmit I2 channel “voice” (LIUtx-B2). Bit3(X) controls whether voice/data channel information is sent to the module140on the application module interface130(AMX-B*). If X equals zero, zeroes are sent on all AMX voice channels. If X equals one, then the following connections are made: AMX-B1 is connected to LIUrx-B1 (B1voice from PBX); AMX-B1′ is connected to MAP-out (phone's transmit voice); AMX-B2 is connected to LIUrx-B2 (I2data from PBX); and AMX-B2′ is connected to AMR-B2. Initially, the telephone terminal120will send all zeroes on all AMX B channels. Bits0–2(mmm) determine what digital voice stream is connected to the phone's audio section (MAP-in).

Bits6–7(dd) choose what the phone sends on the I2-channel to the PBX (LIUtx-B2 source), with a value of 00 indicating all ones, a value of 01 corresponding to the phone audio transmit (MAP-out), a value of 10 corresponding to all ones, and a value of 11 corresponding to I2 channel from the module140(AMR-B2′). Bits4–5(vv) of the second word choose what the phone sends on the B1-channel to the PBX (LIU-B1 source), with a value of 00 indicating all ones, a value of 01 corresponding to the phone audio transmit (MAP-out), a value of 10 corresponding to all ones, and a value of 11 corresponding to the B1 channel from the module140(AMR-B1′).

Initially, the telephone terminal120will connect B1(LIEtx-B1) to its audio transmit path (MAP-out) and send all ones on I2. Bits0–2(mmm) control the digital source of the phone's receive audio section (to handset and speaker). Initially, receive audio is connected to the B1-channel from the PBX (LIUrx-B1). It is noted that these configurations do not control whether any audio output is active. Analog input/output control depends on the phone's audio state machine. The set voice channel configuration message controls only routing of the digital channel.

The following table shows the receive audio source slections:

The phone states request message, shown inFIG. 10, instructs the phone to send a phone states message back to the module140. The request has a single word body with the fixed code “0:0000:0011.” A module140should send a phone states request message to the telephone terminal120after the AMI connection is established in order to obtain the μlaw/A-law voice encoding setting, plus status of the line interface and any telephone states that may be of interest to the module140.

The module state change message, shown inFIG. 10, is used to inform the telephone terminal120of state changes in the module140that may be relevant to the telephone terminal120, such as a module140going off-hook using the B1 voice path. The message has a two word body with the first word using the fixed code “0:0001:1000.” The second word identifies the state change and the new state. The second word is coded as “0:0sss:wwww,” where bits4–6(sss) contain new state information and bits0–3(wwww) identify what changed. A wwww value of 0000 indicates that the B1 channel has a hook state change, with bit4set to one indicating off-hook and bit4set to zero indicating on-hook. A wwww value of 0010 indicates that the S1 channel layer2has come up or gone down, with bit4set to one indicating link up and bit4set to zero indicating link down. A wwww value of 0100 indicates that the S1 channel timeout has occurred. All other wwww values are reserved.

Any of the state bits (sss) that are unused by a given type of change (wwww) are set to zero. If the module140can affect the hook state, it must report its hook state changes to the telephone terminal120via a module state change message.

When the telephone terminal120is not using its HDLC controller, the module140must pass to the phone all layer3S1-channel messages received from the switch. The format of this message mirrors the S1-channel transmit message sent by the phone120to the module140, as discussed above. The first word of the body identifies the application message as an S1-channel message and is coded as “0:0000:0000.” The rest of the application message body is the actual S1-channel layer3message which can be 1 to 14 words.

The output local tone message, shown inFIG. 10, allows the module140to activate one of the non-finger sounds on the telephone terminal120, such as error beep, confirmation tone, or button click. The output local tone message is coded as a single word body as “0:1010:00TT,” where TT is equal to 00 for a button click, 01 for error beep or 10 for confirmation tone. TT equal to 11 is reserved and will be ignored by telephone terminals120that do not support a fourth tone.

The telephone control message, shown inFIG. 10, is used by the module140to turn the phone's speaker on or off, turn mute on or off, control volume settings, and other feature controls, The telephone control message has a two-word body with the first word using a fixed code of “0:0000:1010” and the second word identifying what to control, The second word has a format of “0:0xxx:wwww.” Bits four to six (xxx) are the new setting, the meaning of which depends upon bits zero to three (wwww) which determine what to control, as follows:

BINARYBUTTON/VALUEBUTTON STATE0000Speaker On/Off: Bit 4 is set to one to turn on,and is set to zero to turn off.0001Mute On/Off: Bit 4 is set to one to turn on, andis set to zero to turn off.0010Adjunct TO signal On/Off: Bit 4 is set to oneto turn on, and is set to zero to turn off (ifphone supports adjunct).0011Test Mode On/Off: Test Bit 4 is set to one toturn on, and is set to zero to turn off0100Feature (Shift) On/Off: Bit 4 is set to one toturn on, and is set to zero to turn off0101–0111Reserved1000Set Handset Volume: Bits 4–6 are the newvolume setting1001Set Speaker Volume: Bits 4–6 are the newvolume setting1010Set Ringer Volume: Bits 4–6 are the newvolume setting1011Set Headset Volume: Bits 4–6 are the newvolume setting (if phone has separate headsetjack)1100–1111Reserved

Turning the speaker on or off may cause the phone to generate an audio state message.

The generate recorder beep message, shown inFIG. 10, allows a recorder interface module to use the phone's T7951 single tone generator to inject a recorder warning beep into the transmit audio path. This adds the beep into both transmit voice and voice sidetone. Each message results in a single beep. Thus, the module controls the interval between beeps by how often the module140sends a generate recorder beep message. The message is ignored if the phone is off-hook.

The generate recorder beep message has a four word body, with the following format. The first word has a fixed code of “0:0000:1100.” The second word contains the T7951 single tone frequency code in bits zero through four (0:000f:ffff). The third word contains the T7951 single tone amplitude code in bits zero through six (0:1aaa:aaaa). The fourth word is the beep duration as a multiple of 10 milliseconds (0:dddd:dddd). Thus, a duration of 10 milliseconds to 2550 milliseconds is supported. It is noted that the actual beep duration could be up to 10 milliseconds less than that requested due to timing uncertainties in the phone120. A duration of zero is invalid and will be ignored.

The softkey label query message, shown inFIG. 10, allows the module140(or associated application) to obtain the text of one of the phone's softkey labels. The softkey label query message has a two-word body. The first word is the fixed code “0:0000:1001,” and the second word contains the softkey button number in bits zero through three: “0:0000:nnnn.” The message will be ignored by the phone if the phone does not support soft-keys or the softkey number is out of range (usually supporting values of 1 to 12 or 1 to 15). When querying for all softkey labels, the module140should wait for a softkey label contents message, discussed above, back from the telephone terminal120before sending the next softkey label query message (due to memory limitations in the phone).

Telephone Terminal Signaling and Bearer Channel Configurations

Signaling Channel

The signaling channel, D, supports two modes of operation. In a fist mode, referred to as the “normal telephony mode,” the telephone terminal120operates as if there is no module140attached. In the normal telephony mode, D-channels are terminated in the telephone terminal120via the HDLC controller230in the integrated digital telephone chip200(FIG. 2). The normal telephony mode is used when there is no module140attached, or the attached module140is not powered, deactivated or faulty. However, if the telephone terminal120detects that a module140is attached, the telephone terminal120will periodically attempt to establish communication while operating normally from a user's point of view.

A second mode, referred to as the “module mode,” is entered after a successful AMI connection start-up and the module140sets HDLC control, as discussed above. The telephone terminal120disables the D-channel HDLC controller230in the integrated digital telephone chip200and sends and receives level3D-channel messages via the AMI control channel. The telephone terminal120has also routed the D-channels to and from the PBX110via the AMI connection to the attached module140. The module140terminates the D-channel with its own HDLC controller230. D-channel messages to and from the telephone terminal120are sent over the AMI control channel. This terminate and regenerate operation is similar to the legacy equipment, such as the Definity™ linked data modules. This operation also affords the module140more control of the telephone terminal120.

Bearer Channels

FIG. 11summarizes the voice/bearer, B1and B2, channel configurations. (Telephone) voice paths refer to the routing of data to and from the main audio processor220of the integrated digital telephone chip200. In addition, the term “base” refers to the telephone terminal120. “LIU” indicates the line interface unit210of the integrated digital telephone chip200which terminates the bearer channels (B1 and B2) to and from the PBX110.

Module Implementations

FIG. 12illustrates a schematic block diagram of a tip/ring module1200that allows an analog device, such as a facsimile machine or modem, to be connected to the digital PBX environment110. As shown inFIG. 12, the tip/ring module1200includes a microcontroller1210that controls signaling between the attached telephone terminal120and PBX110. The microcontroller1210also controls the Tip/Ring interface1230. An EEPROM (Electrically Erasable Programmable Read Only Memory) IC1215is used for non-volatile options storage, such as ring rates and levels. The Subscriber Line Interface Controller (SLIC) IC1220is a commercially available interface to the attached user-provided telephony/communications equipment on a tip/ring interface1230, such as a modular-type RJ-11-type analog type interface.

FIG. 13illustrates a schematic block diagram of an RS-232 (passageway) module1300that allows a computer or workstation to be connected to the digital PBX environment110. As shown inFIG. 13, the RS-232 (passageway) module1300includes a microcontroller1310that controls signaling between the attached telephone terminal120and the PBX110. The microcontroller1310also controls the information to the attached personal computer (not shown) connected to connector1330, discussed below, which is used for a Computer Telephony Interface (CTI) function. An EEPROM (Electrically Erasable Programmable Read Only Memory) IC1315is used for non-volatile options storage, such as ring rates and levels. A commercial EIA Driver/Receiver device1320converts the serial data and control levels to and from the microcontroller1310to EIA-232 levels for connection to a personal computer (not are sent over the AMI control channel. This terminate and regenerate operation is similar to the legacy equipment, such as the Definity™ linked data modules. This operation also affords the module140more control of the telephone terminal120.

Bearer Channels

FIG. 11summarizes the voice/bearer, B1and B2, channel configurations. (Telephone) voice paths refer to the routing of data to and from the main audio processor220of the integrated digital telephone chip200. In addition, the term “base” refers to the telephone terminal120. “LIU” indicates the line interface unit210of the integrated digital telephone chip200which terminates the bearer channels (B1 and B2) to and from the PBX110.

Module Implementations

FIG. 12illustrates a schematic block diagram of a tip/ring module1200that allows an analog device, such as a facsimile machine or modem, to be connected to the digital PBX environment110. As shown inFIG. 12, the tip/ring module1200includes a microcontroller1210that controls signaling between the attached telephone terminal120and PBX110. The microcontroller1210also controls the Tip/Ring interface1230. An EEPROM (Electrically Erasable Programmable Read Only Memory) IC1215is used for non-volatile options storage, such as ring rates and levels. The Subscriber Line Interface Controller (SLIC) IC1220is a commercially available interface to the attached user-provided telephony/communications equipment on a tip/ring interface1230, such as a modular-type RJ-11-type analog type interface.

FIG. 13illustrates a schematic block diagram of an RS-232 (passageway) module1300that allows a computer or workstation to be connected to the digital PBX environment110. As shown inFIG. 13, the RS-232 (passageway) module1300includes a microcontroller1310that controls signaling between the attached telephone terminal120and the PBX110. The microcontroller1310also controls the information to the attached personal computer (not shown) connected to connector1330, discussed below, which is used for a Computer Telephony Interface (CTI) function. An EEPROM (Electrically Erasable Programmable Read Only Memory) IC1315is used for non-volatile options storage, such as ring rates and levels. A commercial EIA Driver/Receiver device1320converts the serial data and control levels to and from the microcontroller1310to EIA-232 levels for connection to a personal computer (not shown). The connector1330may be embodied as a standard EIA connector to physically connect the module to a personal computer via an EIA cable.

FIG. 14illustrates a schematic block diagram of a Universal Serial Bus (USB) module1400that allows a USB-enabled computer, workstation or other device to be connected to the digital PBX environment110. As shown inFIG. 14, the integrated digital telephone chip200may be embodied as a custom Gate array that interfaces the AMI from the digital telephone terminal120to the USB module. The HDLC controller230terminates the HDLC D-Channel to/from the PBX110attached to the digital telephone terminal telephone terminal120. The microcontroller1410may be embodied as a commercially available USB microcontroller that controls the signaling between the PBX, attached telephone terminal120and optionally a control device attached to the USB interface1460. An EEPROM (Electrically Erasable Programmable Read Only Memory) IC1415is used for non-volatile options storage, such as ring rates and levels. A small read only memory (ROM) IC1420is used for starting up the microcontroller1410and for re-programming purposes. A re-programmable memory device1430permits changes in the functionality of the microcontroller1410, via the USB interface1460, thereby permitting software upgrades to the module. A random access memory IC1440is used for proper microcontroller operation1410. A latch1450is used to de-multiplex the address/data from the microcontroller1410. A USB connector1460may be embodied as an industry standard device for downstream device connections to a USB hub.