Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
CA 02348114 2001-05-17
1
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
CA 02348114 2001-05-17
2
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
CA 02348114 2001-05-17
3
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
CA 02348114 2001-05-17
4
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
CA 02348114 2001-05-17
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",
CA 02348114 2001-05-17
6
"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.
CA 02348114 2001-05-17
7
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
CA 02348114 2001-05-17
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
CA 02348114 2001-05-17
9
(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.
