CA2348114A1 - Multi-protocol ip phone - Google Patents
Multi-protocol ip phone Download PDFInfo
- Publication number
- CA2348114A1 CA2348114A1 CA002348114A CA2348114A CA2348114A1 CA 2348114 A1 CA2348114 A1 CA 2348114A1 CA 002348114 A CA002348114 A CA 002348114A CA 2348114 A CA2348114 A CA 2348114A CA 2348114 A1 CA2348114 A1 CA 2348114A1
- Authority
- CA
- Canada
- Prior art keywords
- phone
- protocol
- virtual
- signalling
- mgcp
- 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.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/102—Gateways
- H04L65/1043—Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Telephonic Communication Services (AREA)
Abstract
Multi-protocol IP phone, IP fax and wiretap are described herein.
Description
TITLE OF THE INVENTION
MULTI-PROTOCOL IP PHONE
FIELD OF THE INVENTION
The present invention relates to voice over Internet protocols (VoIP). More specifically, the present invention is concerned with a multi-protocol IP phone.
BACKGROUND OF THE INVENTION
Voice over the Internet protocols (VoIP) enables transmission of the voice over the Internet. This technology provides an alternative and ultimately someday a replacement to public switch telephone networks (PSTN).
Many VoIP signalling protocols are known including for example: Session Initiation Protocol (SIP) (RFC 2543), Media Gateway Control Protocol (MGCP) (RFC 2705), Megaco Protocol (RFC 3015) and H.323.
Many major telephony companies are researching (and eventually deploying) more than one signalling protocol. However, signalling protocols are designed independently and usually do not have built-in translation from one to the other. Even if translators between those protocols are being developed, there are potential benefits to have a device that supports multiple signalling protocols simultaneously.
Moreover, current VoIP either enable a single phone acting as a peer in a peer-to-peer architecture or as a slave in a master-slave architecture. Usually, the total control of the phone implied by the master-slave architecture would make it impossible for an IP phone to simultaneously act as a slave and as a peer.
Indeed, on some master-slave architecture (like in MGCP or Megaco) the master knows every event occurring on the IP phone. The master also controls every signal applied on the IP phone. The problem that arises, when an MGCP IP phone wants to support a peer-to-peer protocol like SIP, is that the signals and events needed for the peer-to peer protocol conflict with those managed by the master.
For example, when a user picks up a phone implementing the MGCP to make a call, the Call-Agent (the master in a MGCP network) is notified of the "off hook" event and asks the MGCP phone to generate a "dial tone" signal. If a peer-to-peer device such as a SIP User Agent, tries to call the same phone, the Call-Agent will not be aware of it since the different signalling protocols are not aware of each other. When the MGCP phone receives the SIP invitation for a call, it should start to ring.
The MGCP Call-Agent does not request this "ring" signal. This would usually work, but when the user will pick up the phone to answer the SIP
call, the Call-Agent must not be notified of this "off hook" event because no "dial tone" signal must be applied. If the phone goes "off hook" without the Call-Agent knowing it, the Call-Agent continues to consider the phone "on hook" and could possibly accept an incoming MGCP call and try to make the phone ring until it is notified of an "off hook" transition (which will never happen since the phone is already "off hook"). The problem described here between a peer-to-peer protocol and a master-slave protocol, can also occur between two master-slave protocols. If an IP
phone is managed for example by a MGCP Call-Agent and is also managed by a Megaco Call-Agent, the same kind of conflict will happen in the management of the events and signals.
By default every signalling protocol listens on a different User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) port. For example, MGCP gateways currently listen on UDP port 2427, SIP User Agents listen on UDP port 5040 and MEGACO gateways listen on UDP port 2944 or 2945. Therefore, there is no problem running different protocols such as SIP, MGCP and Megaco simultaneously on one device because the signalling messages are de-multiplexed at the UDP/TCP layer. However, one of the drawbacks of devices from the prior art is the concurrent control that a single protocol wants on a single device (1P phone).
DESCRIPTION OF THE PREFERRED EMBODIMENT
According to a first embodiment of the present invention, there is provided a multi-protocol IP phone that is configured to simultaneously receive calls from a plurality of supported signalling protocols such as SIP, MGCP and Megaco and to make a call using any of the supported signalling protocols. This is achieved by hiding the events and signals of one signalling protocol from the other supported signalling protocols. The segregation also applies to the media flow.
The signalling protocol segregation is advantageously realized through a user interface. Indeed, in addition to the traditional phone interface that includes dual tone multifrequency (DTMF) buttons, flash button, hold button, etc., the multi-protocol IP phone includes other user interface elements that allow selection, information on status and/or other operation on a particular signalling protocol.
For example, a "Line Button" for each supported signalling protocol. This "Line Button" advantageously includes a light to indicate the usage of the line. In addition to the "Line Button", an IP phone, according to the first embodiment of the present invention, also includes "Hold" and "Speaker" buttons that regulate the IP phone operation outside the control of the signalling protocol.
Other interface elements may also be provided to allow different functions for each of the protocols implemented on the IP phone.
The IP phone may take many forms, from a device having a design similar to a traditional phone, to a software implementation on a computer.
According to the first embodiment of the present invention, each protocol that is implemented on the IP phone controls a virtual IP
phone inside the physical IP phone. For example, inside a multi-protocol IP phone supporting SIP, MGCP and Megaco, there would be one virtual SIP IP phone, one virtual MGCP IP phone, and one virtual Megaco IP
phone. These virtual IP phones share the unique resource of the physical 5 IP phone without their respective signalling protocol being "aware" of the implementation of the other signalling protocols.
According to the first embodiment of the present invention, there is only one user interface (phone interface) and the user can interact with only one virtual IP phone at the time. Therefore, only one virtual IP
phone can be active at the time. The user will be able decide which virtual IP phone is active by using the "Line Button".
When one of the virtual IP phones is active, all user interactions, excluding usage of the interface elements that regulate the IP phone operation outside the control of the signalling protocol, such as the "Line Button", "Hold Button" and "Speaker Button", are reflected as events in the virtual IP phone. Signals requested to an active virtual IP
phone are applied to the physical IP phone as if no other signalling protocol was implemented.
Since user input is allowed only for the active virtual IP
phone, no event is ever received in an inactive virtual IP phone. Signals requested to an inactive virtual IP phone are not applied to the physical IP
phone. For example, brief signals (DTMF) applied on an inactive virtual IP
phone are lost forever, as they would be if the user were away from the phone when they were played. Other signals ("dial tone", "ring back tone", "busy tone", etc.) are advantageously memorized but not generated in the physical IP phone. The related signalling protocol doesn't know that the signals do not reach the user. If the signals have to stop before the virtual IP phone ever becomes active, the user will never know they were requested. If the virtual IP phone becomes active before the end of the signals, then the signals are applied to the physical IP phone, as they would normally be. An exception to this rule is when the signalling protocol needs the virtual IP phone to ring while it is inactive. In this case, instead of applying a normal ring to the physical IP phone, a single brief ring will be applied to the physical phone and the light of the "Line Button"
associated with the signalling protocol will flash.
Few rules are required to regulate which virtual IP phone is active. Since the signalling protocols are unaware of the concept of an active virtual IP phone, they advantageously do not request the activation and deactivation of the virtual IP phones.
Some of the triggers for activation/deactivation may not even be implemented in a particular signalling protocol. The usage of "Line Button", "Hold Button" and "Speaker Button" that are often part of the user interface of a conventionally PSTN phone doesn't make sense in the signalling protocol context.
Other events that are implemented in some signalling protocols activate or deactivate a virtual IP phone as a transparent side effect. For example, when a call is received for a specific signalling protocol, the "ring" signal is requested on the appropriate virtual IP phone.
MULTI-PROTOCOL IP PHONE
FIELD OF THE INVENTION
The present invention relates to voice over Internet protocols (VoIP). More specifically, the present invention is concerned with a multi-protocol IP phone.
BACKGROUND OF THE INVENTION
Voice over the Internet protocols (VoIP) enables transmission of the voice over the Internet. This technology provides an alternative and ultimately someday a replacement to public switch telephone networks (PSTN).
Many VoIP signalling protocols are known including for example: Session Initiation Protocol (SIP) (RFC 2543), Media Gateway Control Protocol (MGCP) (RFC 2705), Megaco Protocol (RFC 3015) and H.323.
Many major telephony companies are researching (and eventually deploying) more than one signalling protocol. However, signalling protocols are designed independently and usually do not have built-in translation from one to the other. Even if translators between those protocols are being developed, there are potential benefits to have a device that supports multiple signalling protocols simultaneously.
Moreover, current VoIP either enable a single phone acting as a peer in a peer-to-peer architecture or as a slave in a master-slave architecture. Usually, the total control of the phone implied by the master-slave architecture would make it impossible for an IP phone to simultaneously act as a slave and as a peer.
Indeed, on some master-slave architecture (like in MGCP or Megaco) the master knows every event occurring on the IP phone. The master also controls every signal applied on the IP phone. The problem that arises, when an MGCP IP phone wants to support a peer-to-peer protocol like SIP, is that the signals and events needed for the peer-to peer protocol conflict with those managed by the master.
For example, when a user picks up a phone implementing the MGCP to make a call, the Call-Agent (the master in a MGCP network) is notified of the "off hook" event and asks the MGCP phone to generate a "dial tone" signal. If a peer-to-peer device such as a SIP User Agent, tries to call the same phone, the Call-Agent will not be aware of it since the different signalling protocols are not aware of each other. When the MGCP phone receives the SIP invitation for a call, it should start to ring.
The MGCP Call-Agent does not request this "ring" signal. This would usually work, but when the user will pick up the phone to answer the SIP
call, the Call-Agent must not be notified of this "off hook" event because no "dial tone" signal must be applied. If the phone goes "off hook" without the Call-Agent knowing it, the Call-Agent continues to consider the phone "on hook" and could possibly accept an incoming MGCP call and try to make the phone ring until it is notified of an "off hook" transition (which will never happen since the phone is already "off hook"). The problem described here between a peer-to-peer protocol and a master-slave protocol, can also occur between two master-slave protocols. If an IP
phone is managed for example by a MGCP Call-Agent and is also managed by a Megaco Call-Agent, the same kind of conflict will happen in the management of the events and signals.
By default every signalling protocol listens on a different User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) port. For example, MGCP gateways currently listen on UDP port 2427, SIP User Agents listen on UDP port 5040 and MEGACO gateways listen on UDP port 2944 or 2945. Therefore, there is no problem running different protocols such as SIP, MGCP and Megaco simultaneously on one device because the signalling messages are de-multiplexed at the UDP/TCP layer. However, one of the drawbacks of devices from the prior art is the concurrent control that a single protocol wants on a single device (1P phone).
DESCRIPTION OF THE PREFERRED EMBODIMENT
According to a first embodiment of the present invention, there is provided a multi-protocol IP phone that is configured to simultaneously receive calls from a plurality of supported signalling protocols such as SIP, MGCP and Megaco and to make a call using any of the supported signalling protocols. This is achieved by hiding the events and signals of one signalling protocol from the other supported signalling protocols. The segregation also applies to the media flow.
The signalling protocol segregation is advantageously realized through a user interface. Indeed, in addition to the traditional phone interface that includes dual tone multifrequency (DTMF) buttons, flash button, hold button, etc., the multi-protocol IP phone includes other user interface elements that allow selection, information on status and/or other operation on a particular signalling protocol.
For example, a "Line Button" for each supported signalling protocol. This "Line Button" advantageously includes a light to indicate the usage of the line. In addition to the "Line Button", an IP phone, according to the first embodiment of the present invention, also includes "Hold" and "Speaker" buttons that regulate the IP phone operation outside the control of the signalling protocol.
Other interface elements may also be provided to allow different functions for each of the protocols implemented on the IP phone.
The IP phone may take many forms, from a device having a design similar to a traditional phone, to a software implementation on a computer.
According to the first embodiment of the present invention, each protocol that is implemented on the IP phone controls a virtual IP
phone inside the physical IP phone. For example, inside a multi-protocol IP phone supporting SIP, MGCP and Megaco, there would be one virtual SIP IP phone, one virtual MGCP IP phone, and one virtual Megaco IP
phone. These virtual IP phones share the unique resource of the physical 5 IP phone without their respective signalling protocol being "aware" of the implementation of the other signalling protocols.
According to the first embodiment of the present invention, there is only one user interface (phone interface) and the user can interact with only one virtual IP phone at the time. Therefore, only one virtual IP
phone can be active at the time. The user will be able decide which virtual IP phone is active by using the "Line Button".
When one of the virtual IP phones is active, all user interactions, excluding usage of the interface elements that regulate the IP phone operation outside the control of the signalling protocol, such as the "Line Button", "Hold Button" and "Speaker Button", are reflected as events in the virtual IP phone. Signals requested to an active virtual IP
phone are applied to the physical IP phone as if no other signalling protocol was implemented.
Since user input is allowed only for the active virtual IP
phone, no event is ever received in an inactive virtual IP phone. Signals requested to an inactive virtual IP phone are not applied to the physical IP
phone. For example, brief signals (DTMF) applied on an inactive virtual IP
phone are lost forever, as they would be if the user were away from the phone when they were played. Other signals ("dial tone", "ring back tone", "busy tone", etc.) are advantageously memorized but not generated in the physical IP phone. The related signalling protocol doesn't know that the signals do not reach the user. If the signals have to stop before the virtual IP phone ever becomes active, the user will never know they were requested. If the virtual IP phone becomes active before the end of the signals, then the signals are applied to the physical IP phone, as they would normally be. An exception to this rule is when the signalling protocol needs the virtual IP phone to ring while it is inactive. In this case, instead of applying a normal ring to the physical IP phone, a single brief ring will be applied to the physical phone and the light of the "Line Button"
associated with the signalling protocol will flash.
Few rules are required to regulate which virtual IP phone is active. Since the signalling protocols are unaware of the concept of an active virtual IP phone, they advantageously do not request the activation and deactivation of the virtual IP phones.
Some of the triggers for activation/deactivation may not even be implemented in a particular signalling protocol. The usage of "Line Button", "Hold Button" and "Speaker Button" that are often part of the user interface of a conventionally PSTN phone doesn't make sense in the signalling protocol context.
Other events that are implemented in some signalling protocols activate or deactivate a virtual IP phone as a transparent side effect. For example, when a call is received for a specific signalling protocol, the "ring" signal is requested on the appropriate virtual IP phone.
If no other virtual IP phone is active, the ringing virtual IP phone becomes active. Not only does the physical IP phone now ring, but when the user will pick up the phone, it will also automatically be in the active virtual IP
phone and answer the received call. Another example of implicit activation is when the user picks up the phone and no virtual IP phone is presently active, the default virtual IP phone becomes active and receives the "off hook" event.
The combination of an active virtual IP phone and events hidden from the signalling protocols allow services such as making an MGCP call, putting it on hold to answer a received SIP call, and switching between the two without interaction between the SIP and MGCP signalling protocols.
The IP phone according to the present invention may include a virtual IP phone manager, advantageously in the form of software, to abstract the physical IP phone from each signalling protocol.
A multi-protocol IP phone, according to embodiments of the present invention, could either have a unique phone number (usable by a user of any supported signalling protocol) or have one different phone number by supported signalling protocol.
For example, in SIP, the mapping between the phone number and the IP address and port of the phone is done in a SIP
Redirect Server. In MGCP and Megaco, the mapping in done through the Call-Agent. If all of these databases are independent, it is possible to have the same phone number in each database for a unique multi-protocol IP
Phone. In each database, this unique phone number would refer to the same IP address, but to a different port number (the port number depends on the signalling protocol). This is advantageous since it allows the multi-protocol IP Phone user to give one single phone number, which is reachable by every supported signalling protocol.
According to a second embodiment of the present invention, there is provided an IP Phone having multiple MGCP endpoints without the Call-Agent ever knowing, resulting in multiple MGCP lines with their own individual phone number inside the IP Phone.
According to a third embodiment of the present invention, the supported signalling protocols are managed in the residential gateway and the "Virtual IP Phone Manager" is also located in the residential gateway.
Although the present invention as been described by way of reference to a phone, it is believed to be within the reach of a person skilled in the art to apply the teaching of this first embodiment to conceive a multi-protocol fax machine or a multi-protocol wiretap.
A multi-protocol fax, according to the present invention, could be in the form of hardware such as a conventional fax, or could alternatively be in the form of a computer so programmed as to receive a fax message from any of the predetermined signalling protocols and print the message or convert it into a computer readable format such as TIFF
(Tag Image File Format).
A multi-protocol wiretap according to the present invention would allow copying of the mixed media flow and would forward it, for example, to a server via an IP network such as the Internet. The server would advantageously be configured to backup the phone conversation and relay it upon demand to a remote computer.
Although the present invention has been described hereinabove by way of preferred embodiments thereof, it can be modified without departing from the spirit and nature of the subject invention, as defined in the appended claims.
phone and answer the received call. Another example of implicit activation is when the user picks up the phone and no virtual IP phone is presently active, the default virtual IP phone becomes active and receives the "off hook" event.
The combination of an active virtual IP phone and events hidden from the signalling protocols allow services such as making an MGCP call, putting it on hold to answer a received SIP call, and switching between the two without interaction between the SIP and MGCP signalling protocols.
The IP phone according to the present invention may include a virtual IP phone manager, advantageously in the form of software, to abstract the physical IP phone from each signalling protocol.
A multi-protocol IP phone, according to embodiments of the present invention, could either have a unique phone number (usable by a user of any supported signalling protocol) or have one different phone number by supported signalling protocol.
For example, in SIP, the mapping between the phone number and the IP address and port of the phone is done in a SIP
Redirect Server. In MGCP and Megaco, the mapping in done through the Call-Agent. If all of these databases are independent, it is possible to have the same phone number in each database for a unique multi-protocol IP
Phone. In each database, this unique phone number would refer to the same IP address, but to a different port number (the port number depends on the signalling protocol). This is advantageous since it allows the multi-protocol IP Phone user to give one single phone number, which is reachable by every supported signalling protocol.
According to a second embodiment of the present invention, there is provided an IP Phone having multiple MGCP endpoints without the Call-Agent ever knowing, resulting in multiple MGCP lines with their own individual phone number inside the IP Phone.
According to a third embodiment of the present invention, the supported signalling protocols are managed in the residential gateway and the "Virtual IP Phone Manager" is also located in the residential gateway.
Although the present invention as been described by way of reference to a phone, it is believed to be within the reach of a person skilled in the art to apply the teaching of this first embodiment to conceive a multi-protocol fax machine or a multi-protocol wiretap.
A multi-protocol fax, according to the present invention, could be in the form of hardware such as a conventional fax, or could alternatively be in the form of a computer so programmed as to receive a fax message from any of the predetermined signalling protocols and print the message or convert it into a computer readable format such as TIFF
(Tag Image File Format).
A multi-protocol wiretap according to the present invention would allow copying of the mixed media flow and would forward it, for example, to a server via an IP network such as the Internet. The server would advantageously be configured to backup the phone conversation and relay it upon demand to a remote computer.
Although the present invention has been described hereinabove by way of preferred embodiments thereof, it can be modified without departing from the spirit and nature of the subject invention, as defined in the appended claims.
Claims (3)
1. A multi-protocol IP phone as described in the present application.
2. A multi-protocol IP fax as described in the present application.
3. A multi-protocol wiretap as described in the present application.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002348114A CA2348114A1 (en) | 2001-05-17 | 2001-05-17 | Multi-protocol ip phone |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002348114A CA2348114A1 (en) | 2001-05-17 | 2001-05-17 | Multi-protocol ip phone |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2348114A1 true CA2348114A1 (en) | 2002-11-17 |
Family
ID=4169068
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002348114A Abandoned CA2348114A1 (en) | 2001-05-17 | 2001-05-17 | Multi-protocol ip phone |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2348114A1 (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1492313A1 (en) * | 2003-06-27 | 2004-12-29 | Alcatel | Hybrid telecommunications terminal, that may function in functional or stimuli mode |
| EP1536611A2 (en) * | 2003-11-28 | 2005-06-01 | Telogy Networks Inc. | Internet telephone and fascimile device |
-
2001
- 2001-05-17 CA CA002348114A patent/CA2348114A1/en not_active Abandoned
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1492313A1 (en) * | 2003-06-27 | 2004-12-29 | Alcatel | Hybrid telecommunications terminal, that may function in functional or stimuli mode |
| EP1536611A2 (en) * | 2003-11-28 | 2005-06-01 | Telogy Networks Inc. | Internet telephone and fascimile device |
| EP1536611A3 (en) * | 2003-11-28 | 2008-01-02 | Telogy Networks Inc. | Internet telephone and fascimile device |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100629088B1 (en) | Distributed Call System | |
| US6754180B1 (en) | System, method, and computer program product for support of bearer path services in a distributed control network | |
| US7466810B1 (en) | Distributed system for sharing of communication service resources between devices and users | |
| US20010036176A1 (en) | Apparatus and method for telephony service interface to software switch controller | |
| TW200304296A (en) | Apparatus and method for computer telephone integration in parkcet switched telephone networks | |
| US20040008837A1 (en) | Combining multimedia services with traditional telephony services in a public branch exchange | |
| GB2391134A (en) | Communication system architecture for voice first collaboration | |
| TW200304303A (en) | Apparatus and method for computer telephone integration in packet switched telephone networks | |
| JP2004336756A (en) | Computer telephony integration adapter | |
| AU777728B2 (en) | Distributed communications network including one or more telephony communication devices having programmable functionality | |
| JP2007006047A (en) | Voice ip telephone method and device | |
| JP2005253064A (en) | System and method for facilitating third-party call control and device control relative to third-party call control | |
| JP2008236241A (en) | Telephone system and switching device thereof | |
| WO2006015525A1 (en) | A method for point-to-point calling between two multimedia terminals in the private network | |
| JP2005012380A (en) | Multimedia data transfer system, call connection controller, and terminal cooperation method used therfor, and program therefor | |
| EP2107752B1 (en) | Application server for extending a call intended for one terminal connected to a gateway to all the terminals connected to this gateway | |
| EP2064831B1 (en) | Dynamic key exchange for call forking scenarios | |
| CA2348114A1 (en) | Multi-protocol ip phone | |
| JP2003348229A (en) | Contact center system | |
| JP7523004B2 (en) | Telephone System | |
| TWI244855B (en) | Method of communication protocol for voice over Internet protocol (VoIP) gateways | |
| EP0998109B1 (en) | A communication network utilizing autonomous servers to establish a communication session | |
| JP2006005501A (en) | VoIP NETWORK, MEDIA PROXY SERVER, AND EXTRA SERVICE PROVIDING METHOD FOR USE THEREIN | |
| JP2008125010A (en) | Ip telephone communication system, ip telephone communication method, and program therefor | |
| JP2004147137A (en) | Communication system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |