Language selection

Search

Patent 2339320 Summary

Third-party information liability

Some of the information on this Web page has been provided by external sources. The Government of Canada is not responsible for the accuracy, reliability or currency of the information supplied by external sources. Users wishing to rely upon this information should consult directly with the source of the information. Content provided by external sources is not subject to official languages, privacy and accessibility requirements.

Claims and Abstract availability

Any discrepancies in the text and image of the Claims and Abstract are due to differing posting times. Text of the Claims and Abstract are posted:

  • At the time the application is open to public inspection;
  • At the time of issue of the patent (grant).
(12) Patent: (11) CA 2339320
(54) English Title: METHOD OF CONTROLLING TELEPHONE CONNECTIONS FOR INTERNET PROTOCOL COMMUNICATIONS
(54) French Title: METHODE DE CONTROLE DE CONNEXIONS TELEPHONIQUES POUR COMMUNICATIONS PAR PROTOCOLE INTERNET
Status: Expired
Bibliographic Data
(51) International Patent Classification (IPC):
  • H04L 12/66 (2006.01)
  • H04L 69/16 (2022.01)
  • H04L 69/168 (2022.01)
  • H04M 11/06 (2006.01)
  • H04L 29/06 (2006.01)
(72) Inventors :
  • FRISCH, CRAIG (Canada)
  • MOSKAL, ANDRE (Canada)
  • NASON, CHRISTOPHER JAMES (Canada)
(73) Owners :
  • MITEL NETWORKS CORPORATION (Canada)
(71) Applicants :
  • MITEL KNOWLEDGE CORPORATION (Canada)
(74) Agent: PERRY + CURRIER
(74) Associate agent:
(45) Issued: 2006-12-05
(22) Filed Date: 2001-03-02
(41) Open to Public Inspection: 2002-09-02
Examination requested: 2001-03-02
Availability of licence: N/A
(25) Language of filing: English

Patent Cooperation Treaty (PCT): No

(30) Application Priority Data: None

Abstracts

English 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.


French Abstract

Structure pour encapsuler un message à échanger entre un téléphone IP et une entité dans un PBX basé sur Ethernet, comprenant un titre de protocole et un corps de message IP, dans lequel le titre de protocole comprend une indication du type de protocole pour dénoter si le message est un message IP ou un message encapsulé non IP, le numéro de dispositif pour dénoter au moyen d'un MAC (contrôle d'accès au support) une adresse pour ladite entité dans ledit PBX auquel ledit message doit être transmis ou à partir duquel ledit message doit être reçu, et le type de message pour identifier le type de message contenu dans le corps de message IP.

Claims

Note: Claims are shown in the official language in which they were submitted.




20

I Claim:

1. A method of communication between an IP phone and a network-implemented
PBX,
comprising:
generating a message to be exchanged between said IP phone and said PBX;
encapsulating said message with 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
MAC (Media Access Control) an address 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; and
transmitting the encapsulated message.

2. The method of claim 1, wherein said message is a Device Registration
request
transmitted by said IP Phone to said PBX responsive to one of either power-up
or resetting of
said IP phone.

3. The method of claim 2, further comprising generating, encapsulating and
transmitting a
Device Registration request Acknowledgment message from said PBX to said IP
phone.

4. The method of claim 3, further comprising generating, encapsulating and
transmitting a
Device De-Registration Request message from said IP phone to said PBX.

5. The method of claim 4, further comprising generating, encapsulating and
transmitting a
Device De-Registration Acknowledgment message from said PBX to said IP phone.

6. The method of claim 1, wherein said message is a Device ICMP Echo (Ping)
request
transmitted by said PBX to said IP Phone for testing presence of said IP
phone.

7. The method of claim 6, further comprising generating, encapsulating and
transmitting a
Device ICMP Echo (Ping) results message from said IP phone to the PBX.





21

8. The method of claim 3, further comprising generating, encapsulating and
transmitting a
device tone generation request message from said PBX to said IP phone
responsive to
registration of said IP phone with said PBX and said IP phone going off-hook.

9. The method of claim 8, further comprising generating, encapsulating and
transmitting a
Remove Tone device tone generation request message from said PBX to said IP
phone.

10. The method of claim 9, further comprising generating, encapsulating and
transmitting
an Open Receive Stream Request from said PBX to said IP phone for establishing
an audio path
from said PBX to said IP phone.

11. The method of claim 10, further comprising generating, encapsulating and
transmitting
an Open Receive Stream Acknowledgement from said IP Phone to said PBX.

12. The method of claim 11, further comprising generating, encapsulating and
transmitting
a Close Receive Stream Request from the PBX to the IP Phone.

13. The method of claim 12, further comprising generating, encapsulating and
transmitting
a Close Receive Stream Acknowledgement from the IP Phone to the PBX.

14. The method of claim 11, further comprising generating, encapsulating and
transmitting
an Open Transmit Stream Request from said PBX to said IP phone for
establishing an audio
path from said IP phone to said PBX.

15. The method of claim 14, further comprising generating, encapsulating and
transmitting
an Open Transmit Stream Acknowledgement from the IP Phone to said PBX.

16. The method of claim 15, further comprising generating, encapsulating and
transmitting
a Close Transmit Stream Request from the PBX to the IP phone.

17. The method of claim 16, further comprising generating, encapsulating and
transmitting
a Close Transmit Stream Acknowledgement from the IP phone to the PBX.





22

18. The method of claim 1, wherein said message is a Device IP address update
request
message transmitted by said PBX to said IP phone for initiating update of any
change in IP
address of said IP phone.

19. The method of claim 18, further comprising generating, encapsulating and
transmitting
a Device IP address update acknowledgement from the IP phone to said PBX.

20. The method of claim 1, wherein said message is a legacy call control
message.


Description

Note: Descriptions are shown in the official language in which they were submitted.


CA 02339320 2001-03-02
Method of Controlling Teleuhone Connections for Internet Protocol
Communications
Field of the Invention
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
With the increasing pervasiveness of the Internet, Voice-over-IP (VoIP) is
rapidly displacing traditional 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 P BX system.
Summary Of The Invention
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.
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

CA 02339320 2001-03-02
2
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, SS401 SIP and SS4025IP.
Brief Description Of The Drawings
A preferred embodiment of the present invention will now be described more
fully with reference to the accompanying drawings in which:
Figure 1 is a message flow diagram showing registration of an IP
phone' with an Ethernet PBX; and
Figures 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
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.

CA 02339320 2001-03-02
3
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.
S 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".
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
1 S The message body follows the Protocol Header as shown in the structure
below:
typedef struct IPSP_MSG {


PROTOCOL HI:ADER_MSG hdr;


union msg (


MINET_WRAPPER_ MSG MWM;


DEVICE_REGISTRATION MSG DRM;


DEVICEREGISTRATION_ACK MSG DRAM;


DEVICE__UNREGISTER_MSG DUM;


2S DEVICE__UNREGISTER_ACK_MSG DUAM;


OPEN_RX STREAIvI_REQUEST MSG ORSRM;


OPEN PX STREAM_ACK_MSG ORSAM;


CLOSE_(;X STREAM_REQUEST_MSG CRSRM;


CLOSE RX_STREAM_ACK MSG CRSAM;


3 O 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;


3 S REMOVE, TONE_REQUEST MSG RTRM;


DEVICE_PING REQUEST_MSG DPRM;


DEVICE_PING ACK_MSG DPAM;


DEVIC'E_IP-UPDATt:-REQUEST-MSCiDIURM;


DEVI(=E_IP_UPDATE_ACK_MSG DIUAM;


f msg;


~ IPSP_MSG;


typedef struct {
protocolType_t protoType;
4S deviceNumber_t devNum;
messageType_t msgType;
{ PROTOCOL HEADER_MSG;

CA 02339320 2001-03-02
4
Protocol Type:
INVALID_PROTOCOL_TYPE 0x00000000
MINET_MTS22 0x00000001
MITEL INTERNAL 0x00000002
The Protocol Type denotes whether the message is a Minet IP message or an
encapsulated Minet (MTS 22) message.
Device Number:
Phone 0x00000000
Device #1 i.e. PKM 0x00000001
Device #2 0x00000002
Device #n Ox0000000n
The Device Number denotes which entity sharing the same MAC address the
messages are destined to or coming from.
Message Type:


INVALID_MESSAGE_TYPE 0x00000000


DEVICE_REGISTRATION 0x00000001


DEVICE_REGISTRATION_ACK 0x00000002


DEVICE_DEREGISTRATION 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 Ox0000000a


CLOSE_TX Ox0000000b
STREAM


_ Ox0000000c
CLOSE_TX_STREAM_ACK


MINET_WRAPPER Ox0000000d


APPLY_TONE Ox0000000e


REMOVE_TONE Ox0000000f


DEVICE_PING 0x00000010


DEVICE_PJNG_ACK 0x00000011


DEVICE_IP_UPDATE 0x00000012


DEVICE_IP_UPDATE_ACK 0x00000013


INVALID MSG TYPE 0x00000014



CA 02339320 2001-03-02
Minet IP Registration Seauence
As shown in Figure 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
5 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).
The following messages are used to register and de-register the phone 1 with
the PBX 3:
Device Registration request message sent from the IP Phone
Proto'Type = MITEL INTERNAL
DevNum = N where N=0,1,2,....n
msgType = DEVICE_REGISTRATION
DEVICE_REGISTRATION_MSG
devId: 6 unsigned byte array
mac_ addr[6J 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,
Slave0l, 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.
DevleeCaps: structure: Functionality supported by this device
StrillCodec 4 bytes, unsigned long integer (bitmap), System selected
CODEC to use. Multiple CODECs may be logically
Ored into this field.

CA 02339320 2001-03-02
6
riumTxStreams: 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=l: device supports silence
suppression
tOneGerieratl0n: 4 bytes , unsigned long integer:
toneGeneration =0: device does not support local
1 S tone generation.
toneGeneration =1: device supports local tone
generation
Device Registration request Acknowledgment message sent from
system
Proto'rype = MITEL-INTERNAL
DevNum = N where N=0,1,2,....n
msgT;ype = DEVICE_REGISTRATION__ACK
DEVICE REGISTRATION ACK MSG
reqStatus: 4 bytes , unsigned long integer, Success/Failure Result of the
request
sysTokeri: 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.
Device De-Registration Request message sent from IP Phone.
ProtoType = MITEI -INTERNAL
DevNum = N where N=0,1,2,....n
msgType = DEVICE-DEREGISTRATION
Note that the IP Phone will not unregister itself, but rather an associated
device such
as a PKM may be removed and hence deregistered.
DEVICE UNREGISTER MSG
sysTOkeri: 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...)

CA 02339320 2001-03-02
7
devNumber: 4 bytes , unsigned long integer, Number of device: Master, Slave0l,
Slave02, ...
ipAddress: structure
1p addr 4 bytes , unsigned long integer, IP Address of device,
lp-port 2 bytes , unsigned short integer, port number of protocol medium.
Device De-Registration Acknowledgment message sent from system
ProtoType = MITEL INTERNAL
DevNum = N where N=0,1,2,....n
msgType = DEVICE-DERECTISTRATION ACK
DEYICE_ UNREGISTER_ACK_MSG
reClStatus: 4 bytes , unsigned long integer, Success/Failure Result of the
request
devNumber: 4 bytes , unsigned long integer, Number of device: Master, Slave0l,
Slave02, ...
Detailed Description of Registration Parameters
devType:
INVALID DEVICE TYPE 0x00000000
IP_SUPERSET4001 0x00000001


IP_SUPERSET4015 Ox0000009f


IP_SUPERSET4025 Ox000000a0


IP_SUPERSET4150 0x00000004


PKM 0x00000005


AIM 0x00000006


SYMBOL_PROXY 0x00000007


SYMBOL_SET 0x00000008


TELEWORKER_PROXY 0x00000009


TELEWORKER_SET Ox0000000a


E2T_PROXY Ox0000000b


MAX_DEVICE_TYPE Ox0000000c



devNumbers:
MASTER DEVICE 0x00000000
Where Set=0, and any attached devices will be numbered MASTER_DEVICE + n
where n >= 1
reqStatus (Success/failure codes):

CA 02339320 2001-03-02
g
MTL_ SUCCESS 0x00000000


MTL_ FAILURE 0x00000001


MTL_ NO_I'ERMISSIONS0x00000002


MTL_ NO_RESOURCES 0x00000003


MTL INVALID DEVICE 0x00000004


MTL INVALID REQUEST
0x00000005



devC~odecs bitmap:
NO CODEC_SUPPORT 0x0 (000 00000000)


6711 ULAWG4 Oxl (000 00000001)


6711 ALAWC4 0x2 (000 00000010)


6728 0x4 (000 00000100)


6729 0x8 (000 00001000)


6729 ANNEXB Ox (000 00010000)
10


6729 ANNEXA_w ANNEXB 0x20 (000 00100000)


6723 0x40 (000 01000000)


67231 ANNEXC 0x80 (00010000000)


Placeholderl 0x100 (00100000000)


Placeholder2 0x200 (010 00000000)


Placeholder3 0x400 (100 00000000)


INVALID CODEC Ox7FF (111 11111111)


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
(PINCJ) messages to the phone 1. The following messages are used to implement
this
functionality:
Device ICMP Echo (Ping) request to the phone
Proto'Cype = MITEL-INTERNAL
DevNum = N where N=0,1,2,....n
msgType = DEVICE_PING
DEVICE PING REQUEST MS
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.

CA 02339320 2001-03-02
9
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


time0ut 4 bytes , unsigned long integer, Ping
request timeout in


Milliseconds


qosLeVel 4 bytes , unsigned long integer, QOS
level requested


Device ICMP Echo (Ping) results sent from the phone to the system
ProtoType = MITEI -INTERNAL
DevNum = N where N=0,1,2,....n
msgT:ype = DEVICE PING ACK
DE VICE_PING A CK 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.
pktsSerit 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)
rttMlri 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
qosLevel:
QOS _ LEVELNONE Oxffffffff


QOS _LEVEL0 0x00000000


QOS _LEVEL_1 0x00000001


QOS _ LEVEL2 0x00000002



CA 02339320 2001-03-02
QOS LEVEL 3 0x00000003


QOS_ LEVEL 4 0x00000004


QOS LEVEL_5 0x00000005


QOS LEVEL 6 0x00000006


5 QOS LEVEL 7 0x00000007


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
10 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:
Apply Tone device tone generation request message to the phone:
ProtoType = MITEL INTERNAL
DevNum = N where N=0,1,2,. . ..n
msgType = APPLY TONE
APPLY TONE REQ UEST MSG


sysTokeri: ~ 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_CO MPLEX TONE]: array of tone structures of
frequencies the DSP is


to play


ori_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


ori_T2 Z 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


tluril cycles 2 bytes, unsigned long integer,
Number of times to


repeat the ON/OFF sequence


tall 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


fre~2 2 bytes, unsigned long integer, 2nd frequency
component in Hz


level_1 2 bytes, unsigned long integer, 1 st frequency
signal level


level_2 2 bytes, unsigned long integer, 2nd frequency
signal level


actlori 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.


torieId: 4 bytes , unsigned long integer, System
Tone ID of the tone


being applied



CA 02339320 2001-03-02
11
lrijeCt; 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.
Remove Tone device tone generation request message to the phone
ProtoType = MITEL INTERNAL
DevNtzm = N where N=0,1,2,....n
msgType = REMOVE TONE
REMOVE TONE REQ UEST MSG


SysTokeri: 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


torie~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


Ori_T 1 2 bytes, unsigned long integer, Duration
in ms of 1 st ON period


off_Tl 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. Cycl es ? bytes, unsigned long integer, Number
of times to repeat the


ON/OFF sequence


tall 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


fret 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


aCtlon 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
inject:
NOT INJECTED 0x00000000
NORMAL_INJECTION 0x00000001
MAX_TONE_INJECT 0x00000002
MAX COMPLEX TONE 3
action:
NEXT 0x00000000
RECONNECT 0x00000001
STOP 0x00000002

CA 02339320 2001-03-02
12
Figure 2 is a message flow diagram showing the messages required to
establish communications between a pair of IP phones 1 A and 1 B via an IP
Phone
Service Provider S of PBX 3. The following messages are required to implement
such
communications:
Open Receive Stream Request to the phone:
ProtoType = MITEL INTERNAL
DevNum = N where N=0,1,2,....n
msgType = OPEN_RX-STREAM
OPEIy RX STREAM REQUES T MSG


1 sysTokeri: 4 bytes, unsigned long integer,
S 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 Eeld.


strmFrameSlzeIriMS 4 bytes, unsigned long integer,
Preferred CODEC frame


size for the RX stream (in milliseconds)


lSMultlcast 4 bytes, unsigned long integer


lsMulticast =0: no Multicast, ignore
mcIpAddress.


lsMultlcast =I : the. stream must
be bound to the


mclpAddress Multicast address.



mcIpAddress: structure


ip addr 4 bytes, unsigned long integer,
Multicast address to


receive on


lp-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.
lp-port 2 bytes , unsigned short integer, port number used by the
device that will be transmitting to the phone.

CA 02339320 2001-03-02
13
Note that due to long word alignment, there may be two
bytes of filler following this field.
noSllenCe 4 bytes, unsigned long integer,
$ riOSileriCe =0: no silence suppression applied by the
transmitting end
nOSllenee =1: silence suppression is being applied by
the transmitting end
Open Receive Stream Acknowledgement from the IP Phone to the
system:
ProtoType = MITEL_INTERNAL
DevNum = N where N=0,1,2,....n
msgType = OPEN-RX_STREAM ACK
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
rXConriectlOriID: 4 bytes, unsigned long integer, Device selected
strean>/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.
Close Receive Stream Request from the system to the IP Phone:
Proto'Type = MITEL-INTERNAL
DevNum = N where N=0,1,2,....n
msgType = CLOSE_RX-STREAM
CLOSE RX STREAM REQUEST MSG
sySTOkeri: 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

CA 02339320 2001-03-02
14
Close Receive Stream Acknowledgement from the IP Phone:
ProtoType = MITEI =INTERNAL
DevNum = N where N=0,1,2,. ...n
msgType = CLOSE. RX STREAM ACK
CLOSE RX T~ REAM ACK MSG
reqStatus: 4 bytes, unsigned long integer, Success/Failure Result of
the request
SysTokeri: 4 bytes, unsigned long integer, System provided "token"
from the request message
rxSttmStats: structure: Stream statistics upon closure
Paekets.reev 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
lltter.rxStream 4 bytes, unsigned long integer, estimate of average fitter
over duration of call.
Duration.rxStream 4 bytes, unsigned long integer, duration of call in seconds
IpAddress.sre: structure
ip addr 4 bytes, unsigned long integer, the local ip address
ip_port 2 bytes , unsigned short integer, the local port number.
Open Transmit Stream Request to the IP Phone:
Proto'Type = MITEL_INTERNAL
DevNum = N where N=0,1,2,....n
msgType = OPEN-TX_STREAM
OPEN TX STREAM REQUEST MSG
SysTOkeri: 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.
StrmCodee 4 bytes, unsigned long integer (bitmap), System selected
CODEC to use. Multiple CODECs may be logically Ored
into this field.
StrmFrameSlZeIriMS 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.

CA 02339320 2001-03-02
ip~Ort 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.
CIoSLeVeI 4 bytes, unsigned long integer, QoS level requested. If
Oxffffffff, then no 802.1Q tag, else if 0-7, assume 802.1Q
tag and set priority field to the qosLevel
10 riOSlleriCe 4 bytes, unsigned long integer
noSilence =0: disable silence suppression on the Tx
stream
noSilence =1: enable silence suppression on the Tx stream
15 Open Transmit Stream Acknowledgement from the IP Phone:
ProtoType = MITEL_INTERNAL
DevNum = N where N=0,1,2,....n
msgType = OPEN TX_STREAM ACK
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


txCOririeCtloriID: 4 bytes, unsigned long integer,
Device selected


strean~/connection identifier.
The IP Phone returns the


value of the sysStrmID (B channel)
in this field


txStrmIpAddress: structure


lp addr 4 bytes, unsigned long integer,
The local IP address that


will transmit sheam


lp_port 2 bytes , unsigned short integer,
local port number the


phone well transmit from.


Close Transmit Stream Request to the IP Phone
Proto'Type = MITE:L-INTERNAL
DevNum = N where N=0,1,2, . . ..n
msgType = CLOSIJ-TX STREAM
CLOSE TX STREAM REQUEST MSG
SySTokeri: 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

CA 02339320 2001-03-02
16
Close Transmit Stream Acknowledgement from the IP Phone:
ProtoT ype = MITEL_INTERNAL
DevNa~m = N where N=0,1,2,. . ..n
msgType = CLOSE. TX STREAM ACK
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: struchire: Stream statistics upon closure
Packets.Serit 4 bytes, unsigned long integer, number of RTP packets
sent
Bytes.serit 4 bytes, unsigned long integer, number of voice octets
sent
ErrOT'S.txStream 4 bytes, unsigned long integer, number of RTP errors sent.
IGNORE, NOT RELEVENT
Jltter.txStream 4 bytes, cosigned long integer, estimate of average fitter
over duration of call. IGNORE, NOT RELEVENT
Duratlon.txStream 4 bytes, unsigned long integer, duration of call in seconds
IpAddress.dest: structure
1p 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
reqStatus (Success/failure codes):
MTL_SUCCESS 0x00000000


MTL_FAILURE 0x00000001


MTL_NO_I'ERMISSIONS 0x00000002


MTL_NO_RESOURCES OxG0000003


MTL INVALLD DEVICE 0x00000004


MTL_INVALID REQUEST 0x00000005



SysStrmID:
IP Set Stream IDs: (NOTE: TX is always even) used for sysStrmID of Tx & Rx
connect requests
STREAM_ ID_IP_SET_TX_1 0x00000000 // B
1 TX


STREAM_ ID_IP_SET_RX_1 0x00000001 // B
1 RX


STRF;AM_ ID_IP_SET_TX_2 0x00000002 // B2
TX


STRF:AM_ ID_IP_SET _RX_2 0x00000003 // B2
RX



devCodecs bitmap:

CA 02339320 2001-03-02
17
CODEC_SUPPORT 0x0 (000 00000000)
NO


_ 0x1 (000 00000001)
G711_ULAW64


G711_ALAW64 0x2 (000 00000010)


6728 0x4 (000 00000100)


6729 0x8 (000 00001000)


G729_ANNEXB Ox (000 00010000)
10


ANNEXA_w_ANNEXB 0x20 (000 00100000)
G729


_ 0x40 (000 01000000)
6723


G7231_ANNEXC 0x80 (00010000000)


Placeholderl 0x100 (00100000000)


Placeholder2 0x200 (010 00000000)


Placeholder3 0x400 (100 00000000)


INVALID_CODEC Ox7FF (Ill 11111111)



qosLevel:
QOS_ LEVEL NONE 0xffffffff


QOS_ LEVEL 0 0x00000000


QOS_ LEVEL -1 0x00000001


QOS_ LEVEL 2 0x00000002


QOS_ LEVEL 3 0x00000003


QOS_ LEVEL 4 0x00000004


QOS_ LEVEL _5 0x00000005


QOS- LEVEL 6 0x00000006


QOS_ LEVEL 7 0x00000007


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
functi onality:
Device IP address update request to the phone:
Proto'Type = MITEL-INTERNAL
DevNum = N where N=0,1,2,. . ..n
msgType = DEVICE_IP UPDATE
DEVICE IP UPDATE REQUEST MSG
devNumber 4 bytes , unsigned long integer, Number of device:
Master, Slave0l, Slave02, ...
oldIpAddress: structure

CA 02339320 2001-03-02
18
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 f filler following this field.
newIpAddress: structure
1p addr 4 bytes , unsigned long integer, new IP Address of device
ip-port 2 bytes , unsigned short integer, new port number of
device
Device IP address update acknowledgement from the phone:
ProtoType = MITEL_INTERNAL
DevNum = N where N=0,1,2,....n
msgType = DEVICE IP UPDATE ACK
DEVICE IP UPDATE ACK MSG
reqStatus: 4 bytes , unsigned long integer, Success/Failure Result of
the request
Parameters Description
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



devNumbers:
40
MASTER DEVICE 0x00000000
Where Set=0, and any attached devices will be numbered MASTER DEVICE + n
where; n >= 1
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:

CA 02339320 2001-03-02
1~
Wrapper structure for MINET messages to and from the IP Phone:
ProtoType = MINET_MTS22
DevNum = N where N=0,1,2,....n
msgType = MINET. WRAPPER
MINE T 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
Parameters Description
MAX MINET SIZE 160
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.
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.

Representative Drawing
A single figure which represents the drawing illustrating the invention.
Administrative Status

For a clearer understanding of the status of the application/patent presented on this page, the site Disclaimer , as well as the definitions for Patent , Administrative Status , Maintenance Fee  and Payment History  should be consulted.

Administrative Status

Title Date
Forecasted Issue Date 2006-12-05
(22) Filed 2001-03-02
Examination Requested 2001-03-02
(41) Open to Public Inspection 2002-09-02
(45) Issued 2006-12-05
Expired 2021-03-02

Abandonment History

There is no abandonment history.

Payment History

Fee Type Anniversary Year Due Date Amount Paid Paid Date
Request for Examination $400.00 2001-03-02
Registration of a document - section 124 $100.00 2001-03-02
Application Fee $300.00 2001-03-02
Registration of a document - section 124 $50.00 2002-03-04
Maintenance Fee - Application - New Act 2 2003-03-03 $100.00 2003-02-18
Maintenance Fee - Application - New Act 3 2004-03-02 $100.00 2004-02-17
Maintenance Fee - Application - New Act 4 2005-03-02 $100.00 2005-02-17
Registration of a document - section 124 $100.00 2005-07-11
Registration of a document - section 124 $100.00 2005-07-18
Maintenance Fee - Application - New Act 5 2006-03-02 $200.00 2006-02-23
Final Fee $300.00 2006-09-21
Maintenance Fee - Patent - New Act 6 2007-03-02 $200.00 2007-02-08
Registration of a document - section 124 $100.00 2007-09-14
Registration of a document - section 124 $100.00 2007-09-14
Maintenance Fee - Patent - New Act 7 2008-03-03 $200.00 2008-02-08
Maintenance Fee - Patent - New Act 8 2009-03-02 $200.00 2009-02-12
Registration of a document - section 124 $100.00 2009-02-24
Registration of a document - section 124 $100.00 2010-01-14
Maintenance Fee - Patent - New Act 9 2010-03-02 $200.00 2010-02-18
Maintenance Fee - Patent - New Act 10 2011-03-02 $250.00 2011-02-17
Maintenance Fee - Patent - New Act 11 2012-03-02 $250.00 2012-02-08
Maintenance Fee - Patent - New Act 12 2013-03-04 $250.00 2013-02-13
Registration of a document - section 124 $100.00 2013-03-12
Registration of a document - section 124 $100.00 2013-03-12
Registration of a document - section 124 $100.00 2013-03-28
Registration of a document - section 124 $100.00 2013-03-28
Registration of a document - section 124 $100.00 2014-02-04
Registration of a document - section 124 $100.00 2014-02-04
Registration of a document - section 124 $100.00 2014-02-13
Maintenance Fee - Patent - New Act 13 2014-03-03 $250.00 2014-02-14
Maintenance Fee - Patent - New Act 14 2015-03-02 $250.00 2015-02-04
Registration of a document - section 124 $100.00 2015-05-04
Registration of a document - section 124 $100.00 2015-05-28
Maintenance Fee - Patent - New Act 15 2016-03-02 $450.00 2016-02-10
Maintenance Fee - Patent - New Act 16 2017-03-02 $450.00 2017-02-08
Registration of a document - section 124 $100.00 2017-03-10
Registration of a document - section 124 $100.00 2017-03-23
Maintenance Fee - Patent - New Act 17 2018-03-02 $450.00 2018-02-07
Registration of a document - section 124 $100.00 2018-12-03
Registration of a document - section 124 $100.00 2018-12-10
Registration of a document - section 124 $100.00 2018-12-10
Registration of a document - section 124 $100.00 2018-12-10
Registration of a document - section 124 $100.00 2018-12-10
Maintenance Fee - Patent - New Act 18 2019-03-04 $450.00 2019-02-07
Registration of a document - section 124 $100.00 2019-02-27
Maintenance Fee - Patent - New Act 19 2020-03-02 $450.00 2020-02-05
Owners on Record

Note: Records showing the ownership history in alphabetical order.

Current Owners on Record
MITEL NETWORKS CORPORATION
Past Owners on Record
FRISCH, CRAIG
MITEL CORPORATION
MITEL KNOWLEDGE CORPORATION
MITEL NETWORKS CORPORATION
MITEL NETWORKS ULC
MLN ACQUISITIONCO ULC
MOSKAL, ANDRE
NASON, CHRISTOPHER JAMES
Past Owners that do not appear in the "Owners on Record" listing will appear in other documentation within the application.
Documents

To view selected files, please enter reCAPTCHA code :



To view images, click a link in the Document Description column. To download the documents, select one or more checkboxes in the first column and then click the "Download Selected in PDF format (Zip Archive)" or the "Download Selected as Single PDF" button.

List of published and non-published patent-specific documents on the CPD .

If you have any difficulty accessing content, you can call the Client Service Centre at 1-866-997-1936 or send them an e-mail at CIPO Client Service Centre.


Document
Description 
Date
(yyyy-mm-dd) 
Number of pages   Size of Image (KB) 
Representative Drawing 2002-08-07 1 8
Claims 2001-03-02 15 512
Description 2001-03-02 19 693
Drawings 2001-03-02 2 36
Abstract 2001-03-02 1 16
Cover Page 2002-08-30 1 38
Claims 2005-01-27 3 98
Representative Drawing 2006-11-08 1 10
Cover Page 2006-11-08 2 43
Correspondence 2001-04-04 1 27
Assignment 2001-03-02 6 244
Assignment 2002-03-04 1 39
Correspondence 2002-04-17 1 14
Fees 2003-02-18 1 51
Fees 2004-02-17 1 52
Prosecution-Amendment 2004-07-27 2 73
Prosecution-Amendment 2005-01-27 5 163
Fees 2005-02-17 1 56
Correspondence 2005-06-22 9 463
Correspondence 2005-07-19 1 13
Correspondence 2005-07-19 1 15
Correspondence 2005-07-13 9 524
Assignment 2005-07-11 70 4,393
Assignment 2005-07-18 42 3,905
Correspondence 2005-07-27 1 21
Fees 2006-02-23 1 34
Correspondence 2006-09-21 1 38
Assignment 2007-09-14 39 2,305
Assignment 2007-09-14 39 2,319
Assignment 2009-02-24 12 749
Assignment 2010-01-14 12 738
Assignment 2010-01-13 51 2,926
Assignment 2013-03-12 29 1,211
Assignment 2013-03-12 18 680
Assignment 2013-03-28 94 5,139
Assignment 2014-02-13 45 2,104
Assignment 2013-03-28 95 5,213
Assignment 2014-02-04 19 608
Assignment 2014-02-04 19 566
Assignment 2015-05-04 14 501
Assignment 2015-05-28 53 3,950