Patent Description:
Internet Protocol (IP)-communications units or stations that employ multicast technology for page/party communications in local area networks (LANs) are commercially available from GAI-Tronics Corporation in Mohnton, Pennsylvania. GAI-Tronics Corporation, for example, manufactures both conventionally housed and ruggedized products for providing voice over Internet protocol (VoIP) telephones, Public Address and General Alarm (PA/GA) systems and other communication system units or stations. GAI-Tronics Corporation's multicast technology-based IP units are useful in many applications (e.g., an intraplant paging system to complete an industrial plant's communication, monitoring, and emergency notifications) and in many environments such as on an oil rig or in a refinery or railway system, among others.

Currently, to connect the page/party audio of multicast technology-based IP communications stations among disparate facilities with respective LANs would typically require a dedicated and expensive wide area network (WAN) to allow all IP units to communicate with each other.

<CIT> discloses a method to connect two multicast LANs via an intermediate network that only supports unicast, using gateways that tunnel the multicast traffic between themselves.

<CIT> discloses IP units for multicast communication supporting page audio and party line calls.

The above and other problems are overcome, and additional advantages are realized, by the illustrative embodiments.

In accordance with an illustrative embodiment, a gateway is configured to send Internet protocol (IP) unit multicast audio call traffic via the Internet and comprises a communications interface to a local area network (LAN) to which IP units are connected. The IP units are configured to send and receive page audio with respect to other IP units and to participate in a party line call with other IP units using multicasts. The gateway further comprises a communications interface to the Internet, a memory device and a processor. The memory device is configured to store an IP address for each of one or more gateways in at least one designated inter-LAN group that are located in different LANs and that perform inter-LAN communication with the gateway, and to store configuration information comprising sockets for page audio and party line calls assigned to the IP units in the LAN. The processor is configured to request from a remote database the IP addresses of the gateways that are assigned to each inter-LAN group that performs inter-LAN communication with the gateway and to store the IP addresses in the memory device, each inter-LAN group comprising designated IP units from different LANs that can communicate with each other via multicast, receive a multicast from an IP unit in the LAN and convert the multicast to respective unicasts using the IP addresses of gateways in the designated inter-LAN group before transmission thereto via the Internet, the multicast destined for IP units in one or more different LANs that correspond to the designated inter-LAN group. Further, the processor is configured to receive unicasts from the Internet and convert the unicasts to a multicast provided to a corresponding socket based on the configuration information of the IP units in the LAN.

In accordance with an aspect of an illustrative embodiment, the processor is further configured to request from a server the IP addresses of gateways assigned to one or more inter-LAN groups and to store the IP addresses in the memory device and corresponding group identifiers. For example, the server is configured to store the configuration information of the IP units in the respective LANs.

In accordance with an aspect of an illustrative embodiment, the processor is configured to convert multicast real-time protocol (RTP) traffic in the multicast to unicast RTP traffic and to route the unicast RTP traffic to the IP addresses of the gateways in a designated one of the groups.

In accordance with an illustrative embodiment, a method is provided for sending multicast audio call traffic among Internet protocol (IP) units via the Internet and comprises providing gateways at respective local area networks (LANs) of IP units. The IP units are configured to send and receive page audio with respect to other IP units and to participate in a party line call with other IP units using multicasts. The method further comprises assigning IP units from different ones of the LAN to more than one Internet groups and, for each Internet group, storing the IP addresses of the gateways corresponding to the IP units assigned to that Internet group at each of the gateways that correspond to that Internet group. The method also comprises receiving, at a gateway, a multicast from an IP unit in its LAN that corresponds to at least one of page audio and party line audio, and converting the multicast to respective unicasts using the stored IP addresses of the corresponding gateways in the designated one of the Internet groups, before transmitting the unicasts via the Internet.

In accordance with an aspect of an illustrative embodiment, the unicasts comprise streams of packets with overhead information and audio payload. The overhead information identifies the IP unit that is the source of the audio payload and provides a sequence number to allow an IP unit receiving the packets to organize and mix the streams in accordance with the at least one of page audio and party call audio in the multicast.

In accordance with an aspect of an illustrative embodiment, the method further comprises receiving unicasts from the Internet at corresponding gateways in the designated Internet group, and the corresponding gateways converting the unicasts to a multicast.

In accordance with an aspect of an illustrative embodiment, the method further comprises storing, using at least one of the gateways and a server, configuration information comprising sockets for page audio and party line calls assigned to the IP units in the LAN corresponding each of the gateways.

In accordance with an aspect of an illustrative embodiment, the method further comprises corresponding ones of the gateways in the designated Internet group providing the multicast to a corresponding socket based on the configuration information of the IP units in the LANs associated with the corresponding gateways.

Additional and/or other aspects and advantages of the illustrative embodiments will be set forth in the description that follows, or will be apparent from the description, or may be learned by practice of the illustrative embodiments. The illustrative embodiments may comprise VoIP telephone units and systems and methods for operating same having one or more of the above aspects, and/or one or more of the features and combinations thereof. The illustrative embodiments may comprise one or more of the features and/or combinations of the above aspects as recited, for example, in the attached claims.

The above and/or other aspects and advantages of illustrative embodiments will be more readily appreciated from the following detailed description, taken in conjunction with the accompanying drawings, of which:.

Throughout the drawing figures, like reference numbers will be understood to refer to like elements, features and structures.

Reference will now be made in detail to illustrative embodiments, which are illustrated in the accompanying drawings. The embodiments described herein exemplify, but do not limit, the claims by referring to the drawings.

Illustrative embodiments will be described herein with reference to one or more Internet protocol (IP) units, several of which are described in more detail below as examples. Generally, an IP-based product or unit <NUM>, when operated as a VoIP telephone in a Phone operational mode, allows the user to make session initiation protocol (SIP)-based IP telephone calls such as point-to-point calls, voice pages and party line communications. The calls can be in hands free or handset mode, depending on how the unit is built <NUM> (i.e., with handset, or with flush mounted speaker and microphone and hot dial button or help button). The IP unit <NUM> ensures that a SIP server/IP PBX is available for proper registration. Some example operations of a VoIP telephone are described in commonly owned <CIT>.

The IP unit <NUM> can also have a serverless page/party (SP2) function as described in <CIT>. An IP unit <NUM> with SP2 function is a paging and intercom system that combines the simplicity of "press to page, release to party" operation with multicast voice over Internet protocol (VoIP) technology to provide virtually instant communication in the most demanding of environments. An IP unit <NUM> with SP2 function is wired to the nearest network switch using CAT5/CAT5E Ethernet cable, or Fiber Optic Cable, for example. Local power is supplied to the IP unit <NUM> either as a separate power cable or contained in a hybrid power / network cable. Multiple IP units <NUM> with SP2 function can operate in a "serverless" system. While other paging systems rely on servers to route calls and administrate the system, the SP2 function employs multicast technology, bypassing the need for servers and resulting in a number of benefits described below.

One type of illustrative IP unit <NUM> described below with reference to <FIG> has a universal application platform (UAP) for operating as a multi-functional device over Ethernet in any of a plurality of operational modes. The operational modes can include, but are not limited to, "serverless" page-party (SP2) system mode, VoIP phone mode, IP access panel mode (e.g., alarm activation for a central public address/general alarm (PA/GA) system), point-to-point intercom mode, and so on, for example, all by utilizing graphical user interface (GUI) screens on a touch screen display that are designed specifically for each operational mode.

Additional aspects of illustrative IP-based units <NUM> are described below in connection with <FIG>, <FIG> and <FIG>.

It is desired to connect point-to-point audio and the page/party audio of a SP2/UAP system among disparate facilities (e.g., for communications between an oil rig and a land-based facility). An example implementation depicted in <FIG> comprises plural local area networks (LANs) wherein the IP units <NUM> in a LAN or subnet 12a are unable to communicate with IP units <NUM> in another LAN or subnet 12b, 12c,. Accomplishing inter-LAN or subnet <NUM> communications can require using a dedicated and expensive wide area network (WAN) to allow all IP units <NUM> to communicate with each other. An alternative to using such an expensive, dedicated WAN, however, is to utilize the Internet in place of the WAN to connect these disparate systems in accordance with an illustrated embodiment described below in connection with <FIG>.

A system without inter-LAN or subnet <NUM> communications (i.e., <FIG>) will now be described, followed by a description of the illustrative embodiment of <FIG> employing inter-LAN or subnet <NUM> communications. With reference to <FIG>, a plurality of IP units <NUM> are deployed in string or ring topologies, with each telephone being linked only to its neighbors except for the two end IP units <NUM> that are connected to a wider network via other devices. In the example VoIP system <NUM>, each of plural groups 12a,. ,12n of IP units <NUM> has its own separate subnet and virtual local area network (VLAN) via fiber 14a,. ,14n to which all group members <NUM> are connected (e.g., to constrain multicast packets). The use of a VLAN allows local multicast to be contained within the group <NUM> or string. VLAN IDs need not be unique across the system <NUM>.

Due to the bidirectional fiber <NUM>, switches <NUM> are configured for port blocking to prevent network loops. Each subnet terminates at a switch <NUM> that supports a spanning tree protocol (e.g., STP) to prevent network loops. Each end IP unit in a group <NUM> can be connected to a switch <NUM><NUM> and <NUM><NUM>, that is, there can be two network switches per string or group <NUM>. Each switch <NUM> is connected to the wider network <NUM> via a Layer <NUM> router <NUM>. Since only one router is active at a time, routers <NUM> can run a redundancy protocol (e.g., virtual router redundancy protocol or VRRP) so that a group <NUM> or string can survive a loss of one of the routers <NUM>. The active router <NUM> operates as a gateway for the string subnet of a group <NUM>. Switches <NUM><NUM> and <NUM><NUM> in a group <NUM> have direct connection between them (e.g., either a physical link or on OSI Layer <NUM> connection through a service provider) via the network cloud <NUM>. In the event of a loss of a link within a string of a group <NUM>, a route remains from each telephone <NUM> to the active router <NUM> or gateway and from each telephone <NUM> to all of the other telephones <NUM> in the string (for multicast conferencing).

With continued reference to <FIG>, a SIP server <NUM> and operator station <NUM> are also connected to the cloud <NUM>. Connections to the "cloud" or network <NUM> are omitted from <FIG> for clarity. As stated above, the network <NUM> consists of routers <NUM> forming a single Layer <NUM> network architecture, supporting multiprotocol label switching (MPLS) or similar data-carrying protocol. To achieve redundancy, the VoIP telephones <NUM> are connected in a fiber ring <NUM>, connected to the wider network <NUM> by means of network routers <NUM>. It is possible, however, to have a spur (i.e., only one end terminates at a switch <NUM>), resulting in a loss of redundancy. The network <NUM> to which the fiber rings <NUM> of groups <NUM> are connected is configured to allow large numbers of groups <NUM> to be deployed, and with a group <NUM> having as many as <NUM> IP units <NUM>, for example, or more. The network <NUM> allows IP units <NUM> in any group <NUM> to communicate with a common SIP server <NUM> in the network without conflict. In addition, the groups <NUM> have sufficient resilience to survive a loss of any one telephone <NUM> or link associated with each group <NUM>.

In accordance with an advantageous illustrative embodiment depicted in <FIG>, the Internet <NUM> can be used in a system <NUM> to add the ability to allow point-to-point audio and serverless page/party (SP2) communication among IP units <NUM> of different local area networks (LANs) 212n's. Internet service providers (ISP), however, typically block multicast traffic in order to minimize unnecessary traffic onto the Internet. When IP units (e.g., SP2/UAP-type IP units <NUM>) utilize multicast traffic to pass page/party audio among the IP units <NUM> on a LAN, a gateway device 202n configured in accordance with an illustrative embodiment is used to convert multicast real-time transport protocol (RTP) traffic into unicast RTP traffic and vice versa.

In accordance with the illustrative embodiment of <FIG>, the gateway <NUM> is configured allow multicast traffic from IP units <NUM> destined for remote LANs <NUM> to be routed to the Internet <NUM> by converting multicast RTP traffic into unicast RTP traffic, thereby avoiding being blocked by any ISP. Unicast RTP traffic is routed to all other gateways <NUM> that belong to an inter-LAN or Internet group (e.g. a group prescribed by a license and configuration server <NUM> as shown in <FIG>). Each receiving gateway <NUM> is configured to convert RTP traffic inbound from the Internet <NUM> back into multicast traffic and broadcast it over its connected LAN <NUM>. These operations are performed by the gateways 202n in the Internet group prescribed by the license and configuration server <NUM>. In other words, for the inter-LAN or Internet group illustrated in <FIG>, gateway 202A can unicast RTP to gateways 202B and 202C. Gateway 202B can unicast RTP to gateways 202A and 202C. Gateway 202C can unicast RTP to gateways 202A and 202B. It is to be understood that the license and configuration server <NUM> can coordinate other Internet groups having the same or different LANs 212n and different numbers of LANs as members.

In order for the gateways 202n to determine their destinations in their Internet group(s), they are configured to determine the outward or public IP address of all gateways <NUM> in a particular inter-LAN or Internet group. This is done, for example, by the gateways 202n contacting the license and configuration server <NUM> shown in <FIG>. The host name of the server <NUM> is configured in each gateway <NUM>, along with pertinent client information to identify those group or groups with which the gateway 202n identifies. The license and configuration server <NUM> can, for example, maintain a database such as a table comprising one or more inter-LAN or Internet group identifiers, and the IP address of each gateway assigned to the respective inter-LAN or Internet groups. The license and configuration server <NUM> performs network address translation (NAT) and management of subscription fees for inter-LAN communication support services. Each gateway <NUM> contacts the server <NUM> and acquires the IP addresses of all gateways <NUM> in its assigned Internet group(s), thereby allowing each gateway <NUM> to directly unicast RTP via each gateway's internet IP address to all other gateways <NUM> in the Internet group. The server <NUM> can be configured to provide this service as a subscription service that requires a monthly or annual fee, for example, or as a complimentary service. The customer/user can access the server <NUM> via the web and configure the gateways <NUM> that should be part of a selected Internet group. As an additional service, the configuration aspect of the server <NUM> can provide the configuration of the IP units <NUM> on each LAN 212n, thereby eliminating the need for a local configuration server on each LAN <NUM>.

Additional monitoring can be performed to ensure an end-to-end path for each gateway <NUM> to reach other gateways <NUM> in its Internet group. This can be done, for example, using a heartbeat protocol to ensure that the connection is available at all times.

Inter-LAN call traffic in accordance with the advantageous illustrative embodiment depicted in <FIG> has no impact on the local operation of a system of IP units <NUM> with SP2 function on a particular LAN 212n. The gateway 202n is configured to broadcast converted inbound RTP to the proper multicast socket on the LAN 212n from which the connected IP units <NUM> are configured to receive and broadcast over their amplifier/earpiece. In operation, the IP units <NUM> are not aware of the existence of the gateway 202n, and the gateway 202n is not aware of the IP units <NUM> in its LAN 212n. The gateway 202n simply sets up a bridge between different LANs 212n to transfer normally blocked multicast RTP over the internet.

More specifically, as described in <CIT>, an IP unit <NUM> with the SP2 function employs multicast technology that enables multiple IP devices configured to listen on a given broadcast address to receive pages over a network from a single source and to listen to and participate on a party line. IT personnel or other administrator can allocate or program multicast addresses/ports or sockets to respective party and page lines employed by IP units <NUM>. One or more IP units <NUM> can be designated as master stations to manage configuration and updating of any IP unit <NUM> in its system or LAN <NUM> using a mutual provisioning mode and a command channel. For example, multicast addresses are allocated to designated page sockets and party line sockets used by IP units <NUM> with SP2 function in the LAN 212n in accordance with a system configuration. Once configured, an IP unit <NUM> with SP2 function operates to listen to its configured page sockets for received audio, to transmit audio on its configured page sockets, and to participate in party line conferencing on its configured partly line sockets in accordance with the system configuration. In other words, the IP units <NUM> can listen for RTP on sockets to which they are configured to listen as part of a designated group and convert the RTP to audio for playback. Each IP unit <NUM> in a group can be listening to a party line, and multiple people can broadcast on the same party line, without the need for an IP-PBX or similar device.

For example, for party line operation, a party-line selector switch <NUM> (<FIG>) on the IP unit <NUM> has a multicast address/port or socket assigned for each of the five party lines to both transmit and listen to when selected. The IP unit <NUM> listens to the page sockets. When a party line is selected and the handset is off-hook, if configured, the amplifier audio is muted, and the audio from the selected multicast socket is routed to the earpiece and the audio from the handset microphone is transmitted on the multicast socket.

In addition to the five party line sockets, the IP unit <NUM> can listen on up to, for example, eight other configurable page sockets for inbound page audio. Each page socket has a priority associated with it from <NUM> to <NUM>. For page operation, the IP unit <NUM> can broadcast received page audio while the unit is off-hook in a party-line conversation. A multicast socket is used to transmit and listen to the page line. Page audio is typically not monitored in the earpiece, but the IP unit <NUM> can be configured such that one station hears the page audio of another in the earpiece when the press bar is depressed. The IP unit <NUM> performs idle listening to all configured page sockets routing received page audio appropriately to the amplifier. Audio is not routed to the page line until the handset is off-hook and the pressbar is depressed. When the pressbar is depressed, the audio from the designated page line socket is routed to the earpiece and the audio from the microphone is routed to the page line socket.

Audio is therefore received from the LAN 212n by extracting the encoded payload data within RTP packet streams on sockets that: (a) the IP unit <NUM> is configured to listen for; and (b) the gateway 202n is aware of when converting unicast RTP traffic from the Internet to multicast messages for IP units <NUM> in its corresponding LAN 212n. Accordingly, the IP units <NUM> with SP2 function on each LAN 212n can be unaware of the gateway 202n on that LAN 212n and simply receive multicast audio on the multicast sockets to which they are listening. Further, the IP units <NUM> do not have to communicate with the license and configuration server <NUM> or Internet <NUM>.

The RTP layer is the core mechanism behind the transmission and reception of audio with an IP unit <NUM>. For the most part, the RTP layer of transmitted packets is structured according to RFC <NUM>. Compressed frames are transmitted from an IP unit <NUM> across the network using RTP over IP at a rate of either <NUM> or 100MBit/s auto-negotiated. Multicast addressing is used so that each packet may be received by multiple IP units <NUM>. Each packet of data is structured to include, for example, a unique RTP stream ID (e.g., a synchronization source (SSRC) identifier that uniquely identifies the source of a stream) and other overhead information, in addition to the encoded audio payload. Each layer of the packet structure conforms to the relevant Internet standard RFC. For example, incoming multicast packets can include a unique source ID in addition to a sequence number. The sequence number is incremented for each packet, which allows a receiving IP unit <NUM> to properly sequence them to recreate the digital audio stream. The source ID or SSRC included in each RTP packet is a fixed number unique to each IP unit <NUM>. The receiving IP unit <NUM> can receive multiple streams from multiple IP units <NUM>. The SSRC is used to keep the streams organized so that the RTP stream from each transmitting IP unit <NUM> can be properly mixed in the receiving IP unit <NUM>.

With reference to <FIG>, the license and configuration server <NUM> is configured to receive configuration information from system users or administrator, who can assign IP units <NUM> in a LAN <NUM> to one or more inter-LAN or Internet group(s) comprising the IP units <NUM> of one or more other LANs 212n (block <NUM>). The license and configuration server <NUM>, in turn, updates its database of inter-LAN or Internet groups and the corresponding IP addresses of the gateways 202n assigned to each of these groups (block <NUM>). Each gateway <NUM> can send a request for the IP addresses of the gateways assigned to its group(s) (block <NUM>), and the license and configuration server <NUM> responds to these requests with the requested information (block <NUM>). A gateway <NUM>, in turn, uses the IP addresses of the gateways 202n in its selected inter-LAN or Internet group to convert a multicast message into a unicast message to each respective IP address in its group.

With reference to <FIG>, a gateway <NUM> is configured to obtain the IP addresses of the gateways 202n assigned to its selected inter-LAN or Internet group (e.g., from the license and configuration server <NUM>) (block <NUM>). When outgoing call traffic is received from an IP unit <NUM> in the gateway's LAN <NUM> (block <NUM>) and the call traffic contains multicast RTP traffic (e.g., for SP2 function page/party audio) (block <NUM>), the gateway converts the multicast RTP traffic into unicast traffic using the IP addresses of the gateways assigned to its selected inter-LAN or Internet group (block <NUM>). The converted call traffic is transmitted to other the LANs using the Internet (block <NUM>).

With continued reference to <FIG>, the gateway <NUM> is configured to receive incoming call traffic via the Internet (block <NUM>). If the incoming call contains RTP traffic (block <NUM>), the gateway converts the RTP traffic to multicast RTP traffic (block <NUM>) before transmitting it to the IP units with SP2 function in its LAN <NUM>.

An IP unit <NUM> typically has a speaker 61a and microphone 61b integrated with the unit faceplate, or provided in a handset <NUM>, and an optional push to talk (PTT) non-latching push button, as shown in <FIG> and described in connection with <FIG>. Some IP units <NUM> may have up two separate memory number auto dial non-latching push buttons (e.g., buttons 47a and 47b in <FIG>). The microphone 61b on the unit <NUM> remains muted unless the PTT is depressed. On receiving a call, the alerting ring tone can be emitted from the speaker <NUM>. The power requirements for these IP units <NUM> can be fulfilled from batteries charged by a local solar panel, for example, or provided via wireless power (e.g., Power Over the Ethernet) or wired power. If a call is in progress, then pressing a memory number auto-dial push button ends the call; otherwise, it initiates a call to a preprogrammed number. Where a IP unit <NUM> has been fitted with two memory number auto-dial push buttons 47a, 47b as illustrated in <FIG>, for example, pressing either push button ends a call that is in progress or initiates a call to the preprogrammed number associated with that push button. Buttons can be optionally prioritized. It can also be optional for a push button to end a call if in its configuration. The number of fitted push buttons is only limited by the number required for the application.

With reference to <FIG>, the IP-based unit <NUM> is configured in a housing with a handset <NUM>, but could also be hands free. The GUI screen <NUM> in <FIG> shows operational mode selection buttons <NUM> with the SP2 mode button <NUM> selected on an SP2 mode screen. The SP2 mode screen <NUM> in <FIG> includes party line buttons <NUM> (e.g., five buttons although a different number of party line buttons can be provided) and paging destinations indicated at <NUM>. In this mode of operation, the IP unit <NUM> provides the full capabilities of the hardware-based SP2 currently available and described in commonly-owned <CIT>,
but also with several enhancements. These enhancements include but are not limited to, for example, the ability to access more than the current maximum of five party lines indicated at <NUM>. Instead of party lines being numbered <NUM> through <NUM>, they can now be named using GUI screens on the touch screen display <NUM>. In addition, the IP unit <NUM> can indicate party lines that are currently in use by others to allow quick party-line selection. The example illustrated IP unit16 has the ability to transmit to <NUM> page zones that are numbered <NUM> through <NUM>. With the enhancements of GUI screens on a touch screen display <NUM>, zones can be also named (e.g., alphanumerically and/or using GUI symbols). The display <NUM> can indicate which zones have activity and which zone is currently being broadcast through the unit <NUM>'s amplifier and speaker <NUM>. It is understood, however, that other types of IP units can be used in accordance with the illustrative embodiments to send IP calls to IP units in other LANs.

An IP unit <NUM> with SP2 function is fast. Since no server is needed to set up call routing and conference bridges, the IP unit <NUM> with SP2 function can provide immediate one way paging and full-duplex "party line" communication. Also, since an IP unit <NUM> with SP2 function can operate in serverless system, it can easily be integrated into an existing IP network. This can significantly reduce the installation cost of an SP2 system and simplify plant data architecture. An IP unit <NUM> with SP2 function is simple since there is no keypad required and no extensions to memorize. The user simply lifts the handset, selects a paging zone, squeezes the handset pressbar, and makes an announcement over system speakers. The user can release the pressbar and talk on one of the five available party lines. IP units <NUM> with SP2 function can be supplied with a handset <NUM> for paging and intercom as illustrated in <FIG> and <FIG>, or without a handset as illustrated in <FIG> for where only paging coverage is needed, for example.

<FIG> illustrates an example IP unit <NUM>. As shown in <FIG>, a VoIP telephone unit <NUM> can be provided, for example, with a control block or module <NUM>, a signal conditioning block or module <NUM>, a power block or module <NUM> and a handset <NUM> or hands free microphone <NUM> and speaker <NUM>. The control module <NUM> is described in more detail below. The signal conditioning module <NUM> is connected to an Ethernet network wirelessly or using fiber optic cable or copper, for example, via an Ethernet interface <NUM>. The unit <NUM> is provided with a touch screen display <NUM>, a video camera sensor and lens <NUM>, and an external user interface port <NUM>. The unit <NUM> can have a power block or module <NUM> to receive power via Power over the Ethernet (PoE) or POE Plus, although other power sources can be used.

A wireless communication interface (e.g., IEEE <NUM>, WiFi, Bluetooth™ or other protocol) <NUM> can be provided to allow wireless communication between the unit <NUM> and another device such as a smart phone, sensor, Internet of Things (IoT) device, and so on. The packet structure in the RTP layer employed in accordance with the illustrative embodiments can be configured to accommodate different signal traffic and different applications such as commands or transferred data sent from an IP unit to another IP unit in a different LAN, wherein the commands or transferred data comprises power signals, sensor data, device commands and the like for remote operation of and communication with various devices (e.g., devices in HVAC systems, lighting control systems, security systems, entertainment systems, and so on).

The touch screen display <NUM> can be ruggedized, that is, it can consist of an impact-resistant screen or screen layer, for example, whereby the glass is laminated or bonding is used to prevent glass breakage from breaking any seal deployed inside the unit <NUM> for HA-compliance reasons. In accordance with one illustrative embodiment, the touch screen display <NUM> can be an automobile-grade liquid crystal display (LCD) screen (e.g., a <NUM>" display) capable of withstanding a considerable range of temperatures (e.g., -<NUM>° C to <NUM>° C), and having optional full sun and/or wide view visibility, that is expected in the automobile environment. Further, the display <NUM> is mounted in a housing of a unit <NUM> to withstand vandalism and weather and, as needed, to comply with HA classification requirements.

The unit <NUM> is provided with a magnetic hook switch sensor (e.g., coupled to the handset <NUM>'s cradle, not shown), the output <NUM> of which can be coupled to the signal conditioning block or module <NUM> for providing on-hook/off-hook status data of the handset <NUM> to the control module <NUM>. As stated above, the signal conditioning module <NUM> is configured to provide public address (PA) speaker audio <NUM>, as well as earpiece/speaker audio <NUM> from the control module <NUM> for the handset or hands free speaker and receive microphone audio <NUM> from the handset or separate microphone for the control module <NUM>. The signal conditioning module <NUM> is also configured to provide input data from the touch screen <NUM> and DC power to the VoIP control board <NUM>. General Purpose Monitored Inputs/Outputs (I/O) are provided as generally indicated at <NUM>.

The signal conditioning module <NUM> and the control module <NUM> are configured to process Ethernet data <NUM>. The control module <NUM> in a unit <NUM> can comprises a programmable processor <NUM> and integral or separate memory <NUM>. As stated above, the microprocessor <NUM> can be, for example, a digital signal processor (DSP) or system on chip (SOC) with standard VoIP/SIP software. The control module <NUM> can employ, for example, an audio CODEC (e.g., <NUM> G711A/U Law) to provide full duplex hands free speech; that is, when in a call, the units <NUM>'s audio will be full duplex (i.e., transmit and receive simultaneously with no switching).

In accordance with aspects of the illustrative embodiments, the units <NUM> are programmed (e.g., via software code instructions executed by their respective processors <NUM> and, for example, in accordance with a universal application platform <NUM>) to establish and terminate point-to-point calls and participate in party line calls, among other operations in accordance with each of the plurality of operational modes. As stated above and in accordance with an embodiment, the VoIP telephone unit <NUM> is a configurable multi-function device with universal application platform <NUM> that is pre-programmed to operate in any of a plurality of modes of operation. The plurality of operational modes can be, but are not limited to, two of more of the following modes: a VoIP telephone mode, a serverless page-party station mode, an access panel mode, a serverless point-to-point intercom mode, a party line call mode, and a video call mode, and so on.

It will be understood by one skilled in the art that this disclosure is not limited in its application to the details of construction and the arrangement of components set forth in the above description or illustrated in the drawings. The embodiments herein are capable of other embodiments, and capable of being practiced or carried out in various ways. Also, it will be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. Unless limited otherwise, the terms "connected," "coupled," and "mounted," and variations thereof herein are used broadly and encompass direct and indirect connections, couplings, and mountings. In addition, the terms "connected" and "coupled" and variations thereof are not restricted to physical or mechanical connections or couplings. Further, terms such as up, down, bottom, and top are relative, and are employed to aid illustration, but are not limiting.

The components of the illustrative devices, systems and methods employed in accordance with the illustrated embodiments can be implemented, at least in part, in digital electronic circuitry, analog electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. These components can be implemented, for example, as a computer program product such as a computer program, program code or computer instructions tangibly embodied in an information carrier, or in a machine-readable storage device, for execution by, or to control the operation of, data processing apparatus such as a programmable processor, a computer, or multiple computers.

Also, functional programs, codes, and code segments for accomplishing the illustrative embodiments can be easily construed as within the scope of claims exemplified by the illustrative embodiments by programmers skilled in the art to which the illustrative embodiments pertain. Method steps associated with the illustrative embodiments can be performed by one or more programmable processors executing a computer program, code or instructions to perform functions (e.g., by operating on input data and/or generating an output). Method steps can also be performed by, and apparatus of the illustrative embodiments can be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit), for example.

The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an ASIC, a FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein.

Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example, semiconductor memory devices, e.g., electrically programmable read-only memory or ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory devices, and data storage disks (e.g., magnetic disks, internal hard disks, or removable disks, magneto-optical disks, and CD-ROM and DVD-ROM disks). The processor and the memory can be supplemented by, or incorporated in special purpose logic circuitry.

Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of claims exemplified by the illustrative embodiments. A software module may reside in random access memory (RAM), flash memory, ROM, EPROM, EEPROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In other words, the processor and the storage medium may reside in an integrated circuit or be implemented as discrete components.

Computer-readable non-transitory media includes all types of computer readable media, including magnetic storage media, optical storage media, flash media and solid state storage media. It should be understood that software can be installed in and sold with a central processing unit (CPU) device. Alternatively, the software can be obtained and loaded into the CPU device, including obtaining the software through physical medium or distribution system, including, for example, from a server owned by the software creator or from a server not owned but used by the software creator. The software can be stored on a server for distribution over the Internet, for example.

Claim 1:
A gateway (<NUM>) configured to send Internet protocol unit multicast audio call traffic via the Internet (<NUM>) comprising:
a communications interface connectable to a local area network (<NUM>) to which Internet protocol units (<NUM>) are connected, the Internet protocol units (<NUM>) being configured to send and receive page audio with respect to other Internet protocol units (<NUM>) and to participate in a party line call with other Internet protocol units (<NUM>) using multicasts;
a communications interface connectable to the Internet (<NUM>);
a memory device configured to store
an Internet protocol address for each of one or more gateways (<NUM>) in at least one designated inter-local area network group that are located in different local area networks (<NUM>) and that perform inter-local area network communication with the gateway (<NUM>), and
configuration information comprising sockets for page audio and party line calls assigned to the Internet protocol units (<NUM>) in the local area network (<NUM>);
a processor configured to
request from a remote database the Internet protocol addresses of the gateways (<NUM>) that are assigned to each inter-local area network group that performs inter-local area network communication with the gateway (<NUM>) and to store the Internet protocol addresses in the memory device, each inter-local area network group comprising designated Internet protocol units (<NUM>) from different local area networks (<NUM>) that can communicate with each other via multicast,
receive a multicast from an Internet protocol unit (<NUM>) in the LAN and convert the multicast to respective unicasts using the Internet protocol addresses of gateways (<NUM>) in the designated inter-local area network group before transmission thereto via the Internet, the multicast destined for Internet protocol units (<NUM>) in one or more different local area networks (<NUM>) that correspond to the designated inter- local area network group, and
receive unicasts from the Internet (<NUM>) and convert the unicasts to a multicast provided to a corresponding socket based on the configuration information of the Internet protocol units (<NUM>) in the local area network (<NUM>).