Method of controlling telephone connections for internet protocol communications

Abstract

A structure for encapsulating a message to be exchanged between an IP phone and an entity within an Ethernet-based PBX, comprising a Protocol Header and an IP Message body wherein the Protocol Header includes an indication of Protocol Type for denoting whether the message is an IP message or an encapsulated non-IP message, Device Number for denoting by means of a MAC (Media Access Control) an address for said entity within said PBX to which said message is to be transmitted or from which said message is to be received, and Message Type for identifying the type of message contained in the IP Message Body.

Description

FIELD OF THE INVENTION

[0001] The present invention relates generally to Internet Protocol (IP) telephony, and more particularly to a method of controlling IP telephones within a LAN-implemented or Ethernet PBX using a specialized messaging protocol.

BACKGROUND OF THE INVENTION

[0002] With the increasing pervasiveness of the Internet, Voice-over-IP (VoIP) is rapidly displacing additional TDM (Time Division Multiplexing) voice communications. In order to establish communications with Ethernet PBXs, an IP transport control messaging protocol is required to be established between the phone and PBX system.

SUMMARY OF THE INVENTION

[0003] According to the present invention, a byte oriented and easily adaptable messaging protocol is provided for communications between IP telephones and Ethernet voice-LAN systems. The messages are required to implement essential tasks such as IP phone registration with the system upon phone power up or reset, the application of device tones to IP phones, and connection control for establishing full-duplex voice paths between IP phones. The messaging protocol of the invention also supports additional administrative and telephony functions.

[0004] The general message template consists of a Protocol Header and an IP Message body. The Protocol Header, in turn, includes an indication of the Protocol Type, Device Number and Message Type. The Device Number identifies the entity sharing the same MAC (Media Access Control) address that the messages are destined to or coming from, Message Type identifies the type of message contained in the IP Message Body. The protocol Type denotes whether the message is an IP message (e.g. Mitel proprietary Minet IP message) or an encapsulated non-IP message (e.g. Mitel proprietary Minet (MTS 22) message). The Minet (MTS 22) messaging protocol is implemented in Mitel PBX models SX50, SX200, SX2000, IPERA 2000 for communicating With associated telephones such as Mitel models SS4001, SS4015, SS4025, SS4150, SS4015IP and SS4025IP.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] A preferred embodiment of the present invention will now be described more fully with reference to the accompanying drawings in which:

[0006] FIG. 1 is a message flow diagram showing registration of an IP phone with an Ethernet PBX; and

[0007] FIG. 2 is a message flow diagram showing the establishment of a full duplex voice path between a pair of IP phones.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

[0008] The messaging protocol and collection of specific messages of the present invention have particular application to the assignee's legacy mix of assembly and higher level languages. Consequently, reference to Minet and MinetIP messages occur throughout this disclosure to indicate the preferred embodiment and best mode implementation of the invention.

[0009] The Minet messaging extensions are structure based and are long word aligned, the result of which is that a user with a packet Sniffer will detect filler bytes in between short and long words.

[0010] In order to control a Mitel IP Phone, both Minet and Minet IP messages are required. A common message wrapper is defined to house the messages. The general message template consists of a Protocol Header and a Minet IP Message body that may or may not consist of an MTS22 Minet payload “wrapper”.

[0011] Protocol Header:

ProtoType: 4 bytes, unsigned long integer, Protocol Type
devNum:    4 bytes, unsigned long integer, Device Number
msgType:   4 bytes, unsigned long integer, Message Type

[0012] The message body follows the Protocol Header as shown in the structure below:

typedef struct_IPSP_MSG {
PROTOCOL_HEADER_MSG hdr;
union_msg {
MINET_WRAPPER_MSG            MWM;
DEVICE_REGISTRATION_MSG      DRM;
DEVICE_REGISTRATION_ACK_MSG  DRAM;
DEVICE_UNREGISTER_MSG        DUM;
DEVICE_UNREGISTER_ACK_MSG    DUAM;
OPEN_RX_STREAM_REQUEST_MSG   ORSRM;
OPEN_RX_STREAM_ACK_MSG       ORSAM;
CLOSE_RX_STREAM_REQUEST_MSG  CRSRM;
CLOSE_RX_STREAM_ACK_MSG      CRSAM;
OPEN_TX_STREAM_REQUEST_MSG   OTSRM;
OPEN_TX_STREAM_ACK_MSG       OTSAM:
CLOSE_TX_STREAM_REQUEST_MSG  CTSRM;
CLOSE_TX_STREAM_ACK_MSG      CTSAM;
APPLY_TONE_REQUEST_MSG       ATRM;
REMOVE_TONE_REQUEST_MSG      RTRM;
DEVICE_PING_REQUEST_MSG      DPRM;
DEVICE_PING_ACK_MSG          DPAM;
DEVICE_IP_UPDATE_REQUEST_MSG DIURM;
DEVICE_IF_UPDATE_ACK_MSG     DIUAM;
} msg;
} IPSP_MSG;
typedef struct {
protocolType_t               protoType;
deviceNumber_t               devNum;
messageType_t                msgType;
} PROTOCOL_HEADER_MSG:

[0013] Protocol Type:

INVALID_PROTOCOL_TYPE 0x00000000
MINET_MTS22           0x00000001
MITEL_INTERNAL        0x00000002

[0014] The Protocol Type denotes whether the message is a Minet IP message or an encapsulated Minet (MTS 22) message.

[0015] Device Number:

Phone              0x00000000
Device #1 i.e. PKM 0x00000001
Device #2          0x00000002
...                ...
Device #n          0x0000000n

[0016] The Device Number denotes which entity sharing the same MAC address the messages are destined to or coming from.

[0017] Message Type:

INVALID_MESSAGE_TYPE      0x00000000
DEVICE_REGISTRATION       0x00000001
DEVICE_REGISTRATION_ACK   0x00000002
DEVICE_REGISTRATION       0x00000003
DEVICE_DEREGISTRATION_ACK 0x00000004
OPEN_RX_STREAM            0x00000005
OPEN_RX_STREAM_ACK        0x00000006
CLOSE_RX_STREAM           0x00000007
CLOSE_RX_STREAM_ACK       0x00000008
OPEN_TX_STREAM            0x00000009
OPEN_TX_STREAM_ACK        0x0000000a
CLOSE_TX_STREAM           0x0000000b
CLOSE_TX_STREAM_ACK       0x0000000c
MINET_WRAPPER             0x0000000d
APPLY_TONE                0x0000000e
REMOVE_TONE               0x0000000f
DEVICE_PING               0x00000010
DEVICE_PING_ACK           0x00000011
DEVICE_IP_UPDATE          0x00000012
DEVICE_IP_UPDATE_ACK      0x00000013
INVALID_MSG_TYPE          0x00000014

[0018] Minet IP Registration Sequence

[0019] As shown in FIG. 1, when the IP Phone 1 powers up or resets, it must register with the PBX 3. The phone 1 originates a Registration Request and receives a Registration Acknowledgement in return. The PBX 3 checks the Device ID of the phone (its MAC address) and verifies if it has it in the CDE database. If not, the system sends the phone 1 an MTS22 Minet for PIN Request. The phone buffers the key entries and sends up one message containing the PIN Reply (also an MTS22 Minet message).

[0020] The following messages are used to register and de-register the phone 1 with the PBX 3:

[0021] Device Registration request message sent from the IP Phone

[0022] ProtoType=MITEL_INTERNAL

[0023] DevNum=N where N=0, 1, 2, . . . n

[0024] msgType=DEVICE_REGISTRATION

[0025] DEVICE_REGISTRATION_MSG

devId:                 6 unsigned byte array
mac_addr[6]            MAC address of Phone.
                       Note that due to long word alignment, there
                       may be 2 bytes of filler between the MAC
                       address and the next defined field.
devType:               4 bytes, unsigned long integer, Type of device
                       (i.e., SET, PKM, . . .)
devNumber:             4 bytes, unsigned long integer, Number of
                       device: Master, Slave01, Slave02, . . .
ipAddress:             structure
ip_addr                4 bytes, unsigned long integer, IP Address
                       of device,
ip_port                2 bytes, unsigned short integer, port number
                       of protocol medium.
                       Note that due to long word alignment, there
                       may be two bytes of filler between this
                       field and the next.
DeviceCaps:            structure: Functionality supported by this
                       device
strmCodec              4 bytes, unsigned long integer (bitmap),
                       System selected CODEC to use. Multiple
                       CODECs may be logically Ored into this
                       field.
numTxStreams:          4 bytes, unsigned long integer, Number of
                       Tx streams supported by the device
numRxStreams:          4 bytes unsigned long integer, Number of
                       Rx streams supported by the device
prefStrmFrameSizeInMS: 4 bytes, unsigned long integer, Devices
                       preferred frame size for streams (in ms)
silenceSupp:           4 bytes, unsigned long integer:
                       silenceSupp = 0: device does not support
                       silence suppression
                       silenceSupp = 1: device supports silence
                       suppression
toneGeneration:        4 bytes, unsigned long integer:
                       toneGeneration = 0: device does not support
                       local tone generation.
                       toneGeneration = 1: device supports local tone
                       generation

[0026] Device Registration request Acknowledgment message sent from system

[0027] ProtoType=MITEL_INTERNAL

[0028] DevNum=N where N=0, 1, 2, . . . n

[0029] msgType=DEVICE_REGISTRATION_ACK

[0030] DEVICE_REGISTRATION_ACK_MSG

reqStatus: 4 bytes, unsigned long integer, Success/Failure Result of the
           request
sysToken:  4 bytes, unsigned long integer, System defined “token” that
           must be passed back with any follow up message related
           to this message i.e. Device Unregister.

[0031] Device De-Registration Request message sent from IP Phone.

[0032] ProtoType=MITEL_INTERNAL

[0033] DevNum=N where N=0, 1, 2 . . . n

[0034] msgType=DEVICE_DEREGISTRATION

[0035] Note that the IP Phone will not unregister itself, but rather an associated device such as a PKM may be removed and hence deregistered.

[0036] DEVICE_UNREGISTER_MSG

sysToken:  4 bytes, unsigned long integer, System defined “token”
           taken from the Registration Acknowledgment from the
           system.
devType:   4 bytes, unsigned long integer, Type of device (i.e., SET,
           PKM, etc. . .)
devNumber: 4 bytes, unsigned long integer, Number of device: Master,
           Slave01, Slave02, . . .
ipAddress: structure
ip_addr    4 bytes, unsigned long integer, IP Address of device,
ip_port    2 bytes, unsigned short integer, port number of protocol
           medium.

[0037] Device De-Registration Acknowledgment message sent from system

[0038] ProtoType=MITEL_INTERNAL

[0039] DevNum=N where N=0, 1, 2 . . . n

[0040] msgType=DEVICE_DEREGISTRATION_ACK

[0041] DEVICE_UNREGISTER_ACK_MSG

[0042] reqStatus: 4 bytes, unsigned long integer, Success/Failure Result of the request

[0043] devNumber: 4 bytes, unsigned long integer, Number of device: Master, Slave01, Slave02, . . .

DETAILED DESCRIPTION OF REGISTRATION PARAMETERS

[0044] devType:

INVALID_DEVICE_TYPE 0x00000000
IP_SUPERSET4001     0x00000001
IP_SUPERSET4015     0x0000009f
IP_SUPERSET4025     0x000000a0
IP_SUPERSET4150     0x00000004
PKM                 0x00000005
AIM                 0x00000006
SYMBOL_PROXY        0x00000007
SYMBOL_SET          0x00000008
TELEWORKER_PROXY    0x00000009
TELEWORKER_SET      0x0000000a
E2T_PROXY           0x0000000b
MAX_DEVICE_TYPE     0x0000000c

[0045] devNumbers:

[0046] MASTER_DEVICE 0×00000000

[0047] Were Set=0, and any attached devices will be numbered MASTER_DEVICE+n where n>=1

[0048] reqStatus (Success/failure codes):

MTL_SUCCESS         0x00000000
MTL_FAILURE         0x00000001
MTL_NO_PERMISSIONS  0x00000002
MTL_NO_RESOURCES    0x00000003
MTL_INVALID_DEVICE  0x00000004
MTL_INVALID_REQUEST 0x00000005

[0049] devCodecs bitmap:

NO_CODEC_SUPPORT	0x0	(000 00000000)
G711_ULAW64	0x1	(000 00000001)
G711_ALAW64	0x2	(000 00000010)
G728	0x4	(000 00000100)
G729	0x8	(000 00001000)
G729_ANNEXB	0x10	(000 00010000)
G729_ANNEXA_w_ANNEXB	0x20	(000 00100000)
G723	0x40	(000 01000000)
G7231_ANNEXC	0x80	(000 10000000)
Placeholder1	0x100	(001 00000000)
Placeholder2	0x200	(010 00000000)
Placeholder3	0x400	(100 00000000)
INVALID_CODEC	0x7FF	(111 11111111)

[0050] For system maintenance purposes, it is desirable to provide a mechanism for testing the presence of an operating IP phone 1 in the system by generation of echo (PING) messages to the phone 1. The following messages are used to implement this functionality:

[0051] Device ICMP Echo (Ping) request to the phone

[0052] ProtoType=MITEL_INTERNAL

[0053] DevNum=N where N=0, 1, 2, . . . n

[0054] msgType=DEVICE_PING

[0055] DEVICE_PING_REQUEST_MSG

hostIpAddress: structure
               ip_addr 4 bytes, unsigned long integer, IP Address of device to
                       PING,
               ip_port 2 bytes, unsigned short integer, port number is
                       IGNORED.
                       Note that due to long word alignment, there may be two
                       bytes of filler following this field.
numRequests    4 bytes, unsigned long integer, Number of ping requests
               to send
pktSize        4 bytes, unsigned long integer, Size of data packet to
               send (in bytes)
pktDelay       4 bytes, unsigned long integer, Inter packet delay in
               Milliseconds
timeOut        4 bytes, unsigned long integer, Ping request timeout in
               Milliseconds
qosLevel       4 bytes, unsigned long integer, QOS level requested

[0056] Device ICMP Echo (Ping) results sent from the phone to the system

[0057] ProtoType=MITEL_INTERNAL

[0058] DevNum=N where N=0, 1, 2, . . . n

[0059] msgType=DEVICE_PING_ACK

[0060] DEVICE_PING_ACK_MSG

hostIpAddress: structure
               ip_addr 4 bytes, unsigned long integer, IP Address of device that
                       was PINGed,
               ip_port 2 bytes, unsigned short integer, port number is
                       IGNORED.
                       Note that due to long word alignment, there may be two
                       bytes of filler following this field.
pktsSent       4 bytes, unsigned long integer, Number of ICMP echo requests sent
pktsRecv       4 bytes, unsigned long integer, Number of ICMP echo replys received
pktLoss        4 bytes, unsigned long integer, Percentage of packets lost
rttMax         4 bytes, unsigned long integer, Maximum round trip time (in milliseconds)
rttMin         4 bytes, unsigned long integer, Minimum round trip time (in milliseconds)
rttAvg         4 bytes, unsigned long integer, Average round trip time (in milliseconds)

DETAILED DESCRIPTION OF PING PARAMETERS

[0061] qosLevel:

QOS_LEVEL_NONE 0×ffffffff
QOS_LEVEL_0    0×00000000
QOS_LEVEL_1    0×00000001
QOS_LEVEL_2    0×00000002
QOS_LEVEL_3    0×00000003
QOS_LEVEL_4    0×00000004
QOS_LEVEL_5    0×00000005
QOS_LEVEL_6    0×00000006
QOS_LEVEL_7    0×00000007

[0062] Once the IP phone 1 has been registered with PBX 3, and in response to a user going off-hook, the PBX 3 is required to provide tones to phone in order to provide the use with an indication of the call state (e.g. dial tone, busy, etc.) The following messages are used for the provisioning of device tones to the phone 1:

[0063] Apply Tone device tone generation request message to the phone:

[0064] ProtoType=MITEL_INTERNAL

[0065] DevNum=N where N=0, 1, 2, . . . n

[0066] msgType=APPLY_TONE

[0067] APPLY_TONE_REQUEST_MSG

sysToken:                4 bytes, unsigned long integer, System defined “token” that must
                         be passed back with the Remove Tone request.
sysStrmID:               4 bytes, unsigned long integer, System provided stream ID which
                         maps the voice streams to legacy B channels
tone [MAX_COMPLEX_TONE]: array of tone structures of frequencies the DSP is
                         to play
                         on_T1   2 bytes, unsigned long integer, Duration in ms of 1st ON period
                         off_T1  2 bytes, unsigned long integer, Duration in ms of 1st OFF period
                         on_T2   2 bytes, unsigned long integer, Duration in ms of 2nd ON period
                         off_T2  2 bytes, unsigned long integer, Duration in ms of 2nd OFF period
                                 num_cycles 2 bytes, unsigned long integer, Number of times to
                                 repeat the ON/OFF sequence
                         tail    2 bytes, unsigned long integer, After num_cycles, 0 = leave tone
                                 off, 1 = on
                         freq_1  2 bytes, unsigned long integer, 1st frequency component in Hz
                         freq_2  2 bytes, unsigned long integer, 2nd frequency component in Hz
                         level_1 2 bytes, unsigned long integer, 1st frequency signal level
                         level_2 2 bytes, unsigned long integer, 2nd frequency signal level
                         action  2 bytes, unsigned long integer, indicates the action to take on
                                 completion of the tone. The actions are either to continue to the
                                 next tone descriptor, reconnect to the audio stream, or just stop.
                                 Note that due to long word alignment, there may be 2 bytes of filler
                                 following this field.
toneId:                  4 bytes, unsigned long integer, System Tone ID of the tone
                         being applied
inject;                  4 bytes, unsigned long integer, specify whether to inject the
                         tone on top of voice or not. This is unused by the phone
                         since the tone will always take precedence over voice.

[0068] Remove Tone device tone generation request message to the phone

[0069] ProtoType=MITEL_INTERNAL

[0070] DevNum=N where N=0, 1, 2, . . . n

[0071] msgType=REMOVE_TONE

REMOVE_TONE_REQUEST_MSG

[0072]

sysToken:               4 bytes, unsigned long integer, System defined “token” that was
                        given with the Apply Tone request.
sysStrmID:              4 bytes, unsigned long integer, System provided stream ID which
                        maps the voice streams to legacy B channels
tone[MAX_COMPLEX_TONE]: array of tone structures of frequencies the DSP
                        was playing out to the CODEC that it is to
                        remove. Note that this is IGNORED BY IP
                        PHONE
                        on_T1      2 bytes, unsigned long integer, Duration in ms of 1st ON period
                        off_T1     2 bytes, unsigned long integer, Duration in ms of 1st OFF period
                        on_T2      2 bytes, unsigned long integer, Duration in ms of 2nd ON period
                        off_T2     2 bytes, unsigned long integer, Duration in ms of 2nd OFF period
                        num_cycles 2 bytes, unsigned long integer, Number of times to repeat the
                                   ON/OFF sequence
                        tail       2 bytes, unsigned long integer, After num_cycles, 0 = leave tone
                                   off, 1 = on
                        freq_1     2 bytes, unsigned long integer, 1st frequency component in Hz
                        freq_2     2 bytes, unsigned long integer, 2nd frequency component in Hz
                        level_1    2 bytes, unsigned long integer, 1st frequency signal level
                        level_2    2 bytes, unsigned long integer, 2nd frequency signal level
                        action     2 bytes, unsigned long integer, indicates the action to take on
                                   completion of the tone. The actions are either to continue to the
                                   next tone descriptor, reconnect to the audio stream, or just stop.

DETAILED DESCRIPTION OF TONE PARAMETERS

[0073] inject:

NOT_INJECTED     0×00000000
NORMAL_INJECTION 0×00000001
MAX_TONE_INJECT  0×00000002
MAX_COMPLEX_TONE 3
action:
NEXT             0×00000000
RECONNECT        0×00000001
STOP             0×00000002

[0074] FIG. 2 is a message flow diagram showing the messages required to establish communications between a pair of IP phones 1A and 1B via an IP Phone Service Provider 5 of PBX 3. The following messages are required to implement such communications:

[0075] Open Receive Stream Request to the phone:

[0076] ProtoType=MITEL_INTERNAL

[0077] DevNum=N where N=0, 1, 2, . . . n

[0078] msgType=OPEN_RX_STREAM

[0079] OPEN_RX_STREAM_REQUEST_MSG

sysToken:         4 bytes, unsigned long integer, System defined “token”
                  that must be passed back with the corresponding Close
                  Receive Stream Request.
sysStrmID:        4 bytes, unsigned long integer, System provided stream
                  ID. This field denotes the B channel the connection
                  should assume.
strmCodec         4 bytes, unsigned long integer (bitmap), System selected
                  CODEC to use. Multiple CODECs may be logically Ored
                  into this field.
strmFrameSizeInMS 4 bytes, unsigned long integer, Preferred CODEC frame
                  size for the RX stream (in milliseconds)
isMulticast       4 bytes, unsigned long integer
                  isMulticast = 0: no Multicast, ignore mcIpAddress.
                  isMulticast = 1: the steam must be bound to the
                  mcIpAddress Multicast address.
mcIpAdress:       structure
                  ip_addr 4 bytes, unsigned long integer, Multicast address to
                          receive on
                  ip_port 2 bytes, unsigned short integer, Multicast port number to
                          receive on.
                          Note that due to long word alignment, there may be two
                          bytes of filler following this field.
SrcIpAddress:     structure: IGNORED BY THE IP PHONE.
                  ip_addr 4 bytes, unsigned long integer, The ip address of the
                          device that will be transmitting to the phone.
                  ip_port 2 bytes, unsigned short integer, port number used by the
                          device that will be transmitting to the phone.
                          Note that due to long word alignment, there may be two
                          bytes of filler following this field.
noSilence         4 bytes, unsigned long integer,
                  noSilence = 0: no silence suppression applied by the
                  transmitting end
                  noSilence = 1: silence suppression is being applied by
                  the transmitting end

[0080] Open Receive Stream Acknowledgement from the IP Phone to the system:

[0081] ProtoType=MITEL_INTERNAL

[0082] DevNum=N where N=0, 1, 2, . . . n

[0083] msgType=OPEN_RX_STREAM_ACK

[0084] OPEN_RX_STREAM_ACK_MSG

reqStatus:       4 bytes, unsigned long integer, Success/Failure Result
                 of the request
sysToken:        4 bytes, unsigned long integer, System provided
                 “token” from the request message
rxConnectionID:  4 bytes, unsigned long integer, Device selected
                 stream/connection identifier. The IP Phone returns the
                 value of the sysStrmID (B channel) in this field
rxStrmIpAddress: structure
                 ip_addr 4 bytes, unsigned long integer, The local ip address
                         that will receive stream
                 ip_port 2 bytes, unsigned short integer, local port number to
                         receive on.

[0085] Close Receive Stream Request from the system to the IP Phone:

[0086] ProtoType=MITEL_INTERNAL

[0087] DevNum=N where N=0, 1, 2, . . . n

[0088] msgType=CLOSE_RX_STREAM

[0089] CLOSE_RX_STREAM_REQUEST_MSG

sysToken:  4 bytes, unsigned long integer, System defined “token” that
           was given with the Open Receive Stream Request.
sysStrmID: 4 bytes, unsigned long integer, Id of RX stream/connection
           (B channel) to close

[0090] Close Receive Stream Acknowledgement from the IP Phone:

[0091] ProtoType=MITEL_INTERNAL

[0092] DevNum=N where N=0, 1, 2, . . . n

[0093] msgType=CLOSE_RX_STREAM_ACK

[0094] CLOSE_RX_STREAM_ACK_MSG

reqStatus:   4 bytes, unsigned long integer, Success/Failure
             Result of the request
sysToken:    4 bytes, unsigned long integer, System
             provided “token” from the request message
rxStrmStats: structure: Stream statistics upon closure
             Packets.recv      4 bytes, unsigned long integer, number of RTP
                               packets received
             Bytes.recv        4 bytes, unsigned long integer, number of voice
                               octets received
             Errors.rxStream   4 bytes, unsigned long integer, number of
                               RTP errors received
             Jitter.rxStream   4 bytes, unsigned long integer, estimate of
                               average jitter over duration of call
             Duration.rxStream 4 bytes, unsigned long integer, duration of call
                               in seconds
             IpAddress.src:    structure
             ip_addr           4 bytes, unsigned long integer, the
                               local ip address
             ip_port           2 bytes, unsigned short integer, the local
                               port number.

[0095] Open Transmit Stream Request to the IP Phone:

[0096] ProtoType=MITEL_INTERNAL

[0097] DevNum=N where N=0, 1, 2, . . . n

[0098] msgType=OPEN_TX_STREAM

[0099] OPEN_TX_STREAM_REQUEST_MSG

sysToken:          4 bytes, unsigned long integer, System defined “token”
                   that must be passed back with the corresponding Close
                   Transmit Stream Request.
sysStrmID:         4 bytes, unsigned long integer, System provided stream
                   ID. This field denotes the B channel the connection
                   should assume.
strmCodec          4 bytes, unsigned long integer (bitmap), System selected
                   CODEC to use, Multiple CODECs may be logically Ored
                   into this field.
strmFrameSizeInMS  4 bytes, unsigned long integer, Preferred CODEC frame
                   size for the TX stream (in milliseconds)
destStrmIpAddress: structure
                   ip_addr 4 bytes, unsigned long integer, The IP address of the
                           device to transmit to.
                   ip_port 2 bytes, unsigned short integer, port number used by the
                           device that will be transmitting to the phone.
                           Note that due to long word alignment, there may be two
                           bytes of filler following this field.
qosLevel           4 bytes, unsigned long integer, QoS level requested. If
                   0×fffffff, then no 802.1Q tag, else if 0-7, assume 802.1Q
                   tag and set priority field to the qosLevel
noSilence          4 bytes, unsigned long integer
                   noSilence = 0: disable silence suppression on the Tx
                   stream
                   noSilence = 1: enable silence suppression on the Tx stream

[0100] Open Transmit Stream Acknowledgement from the IP Phone:

[0101] ProtoType=MITEL_INTERNAL

[0102] DevNum=N where N=0, 1, 2, . . . n

[0103] msgType=OPEN_TX_STREAM_ACK

[0104] OPEN_TX_STREAM_ACK_MSG

reqStatus:       4 bytes, unsigned long integer, Success/Failure Result
                 of the request
sysToken:        4 bytes, unsigned long integer, System provided
                 “token” from the request message
txConnectionID:  4 bytes, unsigned long integer, Device selected
                 stream/connection identifier. The IP Phone returns the
                 value of the sysStrmID (B channel) in this field
txStrmIpAddress: structure
                 ip_addr 4 bytes, unsigned long integer, The local IP address
                         that will transmit stream
                 ip_port 2 bytes, unsigned short integer, local port number the
                         phone will transmit from.

[0105] Close Transmit Stream Request to the IP Phone

[0106] ProtoType=MITEL_INTERNAL

[0107] DevNum=N where N=0, 1, 2, . . . n

[0108] msgType=CLOSE_TX_STREAM

[0109] CLOSE_TX_STREAM_REQUEST_MSG

sysToken:  4 bytes, unsigned long integer, System defined “token”
           that was given with the Open Transmit Stream Request.
sysStrmID: 4 bytes, unsigned long integer, Id of TX stream/connection
           (B channel) to close

[0110] Close Transmit Stream Acknowledgement from the IP Phone:

[0111] ProtoType=MITEL_INTERNAL

[0112] DevNum=N where N=0, 1, 2, . . . n

[0113] msgType=CLOSE_TX_STREAM_ACK

[0114] CLOSE_TX_STREAM_ACK_MSG

reqStatus:   4 bytes, unsigned long integer, Success/Failure Result of
             the request
sysToken:    4 bytes, unsigned long integer, System provided “token”
             from the request message
txStrmStats: structure: Stream statistics upon closure
             Packets.sent      4 bytes, unsigned long integer, number of RTP packets
                               sent
             Bytes.sent        4 bytes, unsigned long integer, number of voice octets
                               sent
             Errors.txStream   4 bytes, unsigned long integer, number of RTP errors sent.
                               IGNORE, NOT RELEVENT
             Jitter.txStream   4 bytes, unsigned long integer, estimate of average jitter
                               over duration of call IGNORE, NOT RELEVENT
             Duration.txStream 4 bytes, unsigned long integer, duration of call in seconds
             IpAddress.dest:   structure
             ip_addr           4 bytes, unsigned long integer, the local IP address used
                               to Tx
             ip_port           2 bytes, unsigned short integer, the local port number
                               used to Tx.

DETAILED DESCRIPTION OF CONNECTION PARAMETERS

[0115] reqStatus (Success/failure codes):

MTL_SUCCESS         0×00000000
MTL_FAILURE         0×00000001
MTL_NO_PERMISSIONS  0×00000002
MTL_NO_RESOURCES    0×00000003
MTL_INVALID_DEVICE  0×00000004
MTL_INVALID_REQUEST 0×00000005

[0116] SysStrmID:

[0117] IP Set Stream IDs: (NOTE: TX is always even) used for sysStrmID of Tx & Rx connect requests

STREAM_ID_IP_SET_TX_1 0×00000000 // B1 TX
STREAM_ID_IP_SET_RX_1 0×00000001 // B1 RX
STREAM_ID_IP_SET_TX_2 0×00000002 // B2 TX
STREAM_ID_IP_SET_RX_2 0×00000003 // B2 RX

[0118] devCodecs bitmap:

	NO_CODEC_SUPPORT	0×0	(000 00000000)
	G711_ULAW64	0×1	(000 00000001)
	G711_ALAW64	0×2	(000 00000010)
	G728	0×4	(000 00000100)
	G729	0×8	(000 00001000)
	G729_ANNEXB	0×10	(000 00010000)
	G729_ANNEXA_w_ANNEXB	0×20	(000 00100000)
	G723	0×40	(000 01000000)
	G7231_ANNEXC	0×80	(000 10000000)
	Placeholder1	0×100	(001 00000000)
	Placeholder2	0×200	(010 00000000)
	Placeholder3	0×400	(100 00000000)
	INVALID_CODEC	0×7FF	(111 11111111)

[0119] qosLevel:

QOS_LEVEL_NONE 0×ffffffff
QOS_LEVEL_0    0×00000000
QOS_LEVEL_1    0×00000001
QOS_LEVEL_2    0×00000002
QOS_LEVEL_3    0×00000003
QOS_LEVEL_4    0×00000004
QOS_LEVEL_5    0×00000005
QOS_LEVEL_6    0×00000006
QOS_LEVEL_7    0×00000007

[0120] One important system administration requirement for IP phone systems is to provide a mechanism for updating the IP address for a device (e.g. an IP phone) connected to the Ethernet PBX 3. The following messages are used to implement this functionality:

[0121] Device IP address update request to the phone:

[0122] ProtoType=MITEL_INTERNAL

[0123] DevNum=N where N=0, 1, 2, . . . n

[0124] msgType=DEVICE_IP_UPDATE

[0125] DEVICE_IP_UPDATE_REQUEST_MSG

devNumber     4 bytes, unsigned long integer, Number at device:
              Master, Slave01, Slave02, . . .
oldIpAddress: structure
              ip_addr 4 bytes, unsigned long integer, old IP Address of device
              ip_port 2 bytes, unsigned short integer,
                      old port number of device
                      Note that due to long word alignment, there may be two
                      bytes of filler following this field.
newIpAddress: structure
              ip_addr 4 bytes, unsigned long integer, new IP Address of device
              ip_port 2 bytes, unsigned short integer, new port number of
                      device

[0126] Device IP address update acknowledgement from the phone:

[0127] ProtoType=MITEL_INTERNAL

[0128] DevNum=N where N=0, 1, 2, . . . n

[0129] msgType=DEVICE_IP_UPDATE_ACK

[0130] DEVICE_IP_UPDATE_ACK_MSG

[0131] reqStatus: 4 bytes, unsigned long integer, Success/Failure Result of the request

PARAMETERS DESCRIPTION

[0132] reqStatus (Success/failure codes):

MTL_SUCCESS         0×00000000
MTL_FAILURE         0×00000001
MTL_NO_PERMISSIONS  0×00000002
MTL_NO_RESOURCES    0×00000003
MTL_INVALID_DEVICE  0×00000004
MTL_INVALID_REQUEST 0×00000005

[0133] devNumbers:

[0134] MASTER_DEVICE 0×00000000

[0135] Where Set=0, and any attached devices will be numbered MASTER_DEVICE+n where n>=1

[0136] Finally, as indicated above, the messaging protocol of the present invention allows for the encapsulation of “legacy” Minet messages (i.e. MTS 22 messages) to and from the IP phones. The following message format is used:

[0137] Wrapper structure for MINET messages to and from the IP Phone:

[0138] ProtoType=MINET_MTS22

[0139] DevNum=N where N=0, 1, 2, . . . n

[0140] msgType=MINET_WRAPPER

[0141] MINET_WRAPPER_MSG

msgLen:             4 bytes, unsigned long integer, length of
                    the following MINET message.
msg[MAX_MINET_SIZE] array unsigned char, the MTS22 MINET
                    message

[0142] Parameters Description

[0143] MAX_MINET_SIZE 160

[0144] In summary, according to the present invention a messaging protocol is provided along with a collection of messages which conform to the protocol, for controlling IP Phones within an Ethernet-based PBX system. The invention has particular applicability as a message interface from Mitel's IP Phones to Mitel's IP enabled PBXs. The message interface is compatible with an H323 Voice Gateway implementation.

[0145] Alternatives and variations of the invention are possible. For example, the protocol can be adapted to control voice/data switching on any IP centric node. In other words, the protocol is not constrained to phones but, rather, can be applied to any internet appliance that is a client to the IP centric PBX. Within the PBX, the protocol can be used by call control in order to control the switching fabric. All such embodiments, modifications and applications are believed to be within the sphere and scope of the invention as defined by the claims appended hereto.

Claims

1. A structure for encapsulating a message to be exchanged between an IP phone and an entity within an Ethernet-based PBX, comprising a Protocol Header and an IP Message body, wherein the Protocol Header includes an indication of Protocol Type for denoting whether the message is an IP message or an encapsulated non-IP message, Device Number for denoting by means of a MAC; (Media Access Control) an address for said entity within said PBX to which said message is to be transmitted or from which said message is to be received, and Message Type for identifying the type of message contained in the IP Message Body.

2. The structure of claim 1, further characterized as follows:

3. A Device Registration request message sent from the IP Phone in accordance with the structure of claim 1, characterized as follows:

4. A Device Registration request Acknowledgment message sent from the PBX in accordance with the structure of claim 1, characterized as follows:

5. A Device De-Registration Request message sent from the IP Phone in accordance with the structure of claim 1, characterized as follows:

6. A Device De-Registration Acknowledgment message sent from the PBX in accordance with the structure of claim 1, characterized as follows:

7. A Device ICMP Echo (Ping) request message to the phone in accordance with the structure of claim 1, characterized as follows:

8. A Device ICMP Echo (Ping) results message sent from the phone to the PBX in accordance with the structure of claim 1, characterized as follows:

9. An Apply Tone device tone generation request message to the phone in accordance with the structure of claim 1, characterized as follows:

10. A Remove Tone device tone generation request message to the phone in accordance with the structure of claim 1, characterized as follows:

11. An Open Receive Stream Request to the phone in accordance with the structure of claim 1, characterized as follows:

12. An Open Receive Stream Acknowledgement from the IP Phone to the PBX in accordance with the structure of claim 1, characterized as follows:

13. A Close Receive Stream Request from the PBX to the IP Phone in accordance with the structure of claim 1, characterized as follows:

14. A Close Receive Stream Acknowledgement from the IP Phone in accordance with the structure of claim 1, characterized as follows:

15. An Open Transmit Stream Request to the IP Phone in accordance with the structure of claim 1, characterized as follows:

16. An Open Transmit Stream Acknowledgement from the IP Phone in accordance with the structure of claim 1, characterize as follows:

17. A Close Transmit Stream Request to the IP Phone in accordance with the structure of claim 1, characterized as follows:

18. A Close Transmit Stream Acknowledgement from the IP Phone in accordance with the structure of claim 1, characterized as follows:

19. A Device IP address update request message to the phone in accordance with the structure of claim 1, characterized as follows:

20. A Device IP address update acknowledgement from the phone in accordance with the structure of claim 1, characterized as follows:

21. A Wrapper structure for messages to and from the IP Phone in accordance with the structure of claim 1, characterized as follows: