CA2339320C - Method of controlling telephone connections for internet protocol communications - Google Patents
Method of controlling telephone connections for internet protocol communications Download PDFInfo
- Publication number
- CA2339320C CA2339320C CA 2339320 CA2339320A CA2339320C CA 2339320 C CA2339320 C CA 2339320C CA 2339320 CA2339320 CA 2339320 CA 2339320 A CA2339320 A CA 2339320A CA 2339320 C CA2339320 C CA 2339320C
- Authority
- CA
- Canada
- Prior art keywords
- phone
- message
- pbx
- bytes
- encapsulating
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/168—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP] specially adapted for link layer protocols, e.g. asynchronous transfer mode [ATM], synchronous optical network [SONET] or point-to-point protocol [PPP]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
A structure for encapsulating a message to be exchanged between an IP pho ne 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 identifyi ng the type of message contained in the IP Message Body.
Description
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
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
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.
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.
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;
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;
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 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
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 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.
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.
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...)
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...)
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):
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) 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.
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 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 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 action:
NEXT 0x00000000 RECONNECT 0x00000001 STOP 0x00000002 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.
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 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.
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 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
STREAM_ ID_IP_SET_RX_1 0x00000001 // B
STRF;AM_ ID_IP_SET_TX_2 0x00000002 // B2 TX
STRF:AM_ ID_IP_SET _RX_2 0x00000003 // B2 RX
devCodecs bitmap:
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) ANNEXA_w_ANNEXB 0x20 (000 00100000) _ 0x40 (000 01000000) 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 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:
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:
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 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.
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):
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) 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.
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 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 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 action:
NEXT 0x00000000 RECONNECT 0x00000001 STOP 0x00000002 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.
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 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.
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 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
STREAM_ ID_IP_SET_RX_1 0x00000001 // B
STRF;AM_ ID_IP_SET_TX_2 0x00000002 // B2 TX
STRF:AM_ ID_IP_SET _RX_2 0x00000003 // B2 RX
devCodecs bitmap:
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) ANNEXA_w_ANNEXB 0x20 (000 00100000) _ 0x40 (000 01000000) 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 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:
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:
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 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.
Claims (20)
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.
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.
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.
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.
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.
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.
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.
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.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA 2339320 CA2339320C (en) | 2001-03-02 | 2001-03-02 | Method of controlling telephone connections for internet protocol communications |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA 2339320 CA2339320C (en) | 2001-03-02 | 2001-03-02 | Method of controlling telephone connections for internet protocol communications |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2339320A1 CA2339320A1 (en) | 2002-09-02 |
| CA2339320C true CA2339320C (en) | 2006-12-05 |
Family
ID=4168484
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA 2339320 Expired - Lifetime CA2339320C (en) | 2001-03-02 | 2001-03-02 | Method of controlling telephone connections for internet protocol communications |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2339320C (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8065359B2 (en) | 2004-09-16 | 2011-11-22 | Nokia Corporation | Integrated method and apparatus to manage mobile devices and services |
-
2001
- 2001-03-02 CA CA 2339320 patent/CA2339320C/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| CA2339320A1 (en) | 2002-09-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7715413B2 (en) | Multi-network exchange system for telephony applications | |
| US9319530B2 (en) | Method and system for providing telemetry, verification and/or other access in a SIP-based network | |
| US7328271B2 (en) | Method of controlling telephone connections for internet protocol communications | |
| US6449269B1 (en) | Packet voice telephony system and method | |
| US7002912B2 (en) | Architecture for transporting PBX signaling codes via SIP | |
| KR20020034838A (en) | Media communication system, and terminal apparatus and signal conversion apparatus in said system | |
| WO2008017265A1 (en) | Method and system of conducting the media stream and method and system of conducting detection | |
| US6801521B1 (en) | System and method for distributed call signaling in telephony-over-LAN networks | |
| CN101146100B (en) | A realization method of SIP network phone based on transmission protocol SCTP and DCCP | |
| MX2008013691A (en) | System and method of remote testing in loopback mode using mgcp/ncs. | |
| US20030169768A1 (en) | Call initiation for legacy mobile circuit switched domain wireless systems | |
| WO2008064580A1 (en) | The method, system and application server to avoid the cross-talk of color ringing back tone | |
| US6549534B1 (en) | Apparatus and method for accessing wireless trunks on a communications network | |
| KR100705568B1 (en) | apparatus and method for processing SIP signaling in voice/data integration switching system | |
| US8230111B2 (en) | Method for transmitting signaling messages using alternate path | |
| US7006494B1 (en) | System and method for a virtual telephony intermediary | |
| CN102271137A (en) | Media server | |
| CA2339320C (en) | Method of controlling telephone connections for internet protocol communications | |
| US20090238176A1 (en) | Method, telephone system and telephone terminal for call session | |
| CN100502368C (en) | Method for building call between multimedia apparatus | |
| WO2008049371A1 (en) | A method and system for transferring service event | |
| CN104702807A (en) | VoIP communication system | |
| KR100809398B1 (en) | Method and system for transmitting SMS for VoIP service supproting Multi-protocol | |
| CN101243674B (en) | Method and apparatus for a fast installation of an IP user connection over a 3GPP Nb interface under application of the BICC 'delayed backward bearer establishment' and avoidance of failure | |
| WO2007143915A1 (en) | A method and apparatus for transmitting the key information of a user device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKEX | Expiry |
Effective date: 20210302 |