Patent ID: 12250339

DETAILED DESCRIPTION

A description of example embodiments follows.

As described above, some POTS-based services including, e.g., so-called “Life Safety” applications (fire and burglar/safety alarms, elevator phones, and entry systems, among other examples), are sensitive to latency. When such services are switched to a fiber- or LTE-based MFVN, these services may encounter latency issues during transmissions, via protocols such as IP, between (i) a customer appliance such as a MFVN device, which may support, e.g., a fire panel, and (ii) a remote/network controller and/or a remote device/appliance such a MFVN device, the latter of which may support, e.g., an alarm monitoring station.

Embodiments introduce an intelligent relay protocol to compensate for latency-sensitive applications such as alarm transmissions. The improved protocol, referred to herein as “alarm protocol relay” (APR), alleviates the challenges of latency and poor cell signal transmission using an algorithmic compensation methodology.

In an embodiment, a relay agent at the customer appliance and a proxy agent at, e.g., a remote/network controller or a remote device/appliance, work together to compensate for any latency introduced in challenging locations. The controller may be, e.g., a remote/network component implemented in either software or hardware, including, for example, as part of a session border controller (SBC) or other suitable network element known to those of skill in the art; the remote device/appliance may be, e.g., a MFVN device or other suitable known device. Such an inventive approach keeps the transmission real time and provides error correction and compensation to assure successful end-to-end transmission.

The relay agent and proxy agent may be implemented using computer software instructions. One or more processing devices at the customer appliance may be configured to execute the instructions for performing the operations and steps discussed herein for the relay agent, e.g., steps701-705of method700described hereinbelow in relation toFIG.7. Likewise, for instance, processing device(s) at, or used to implement, a remote/network controller and/or at a remote device/appliance may be configured to execute the instructions for performing the operations and steps discussed herein for the proxy agent, e.g., the transmission monitoring, error identifying, and/or error correcting steps of method700. The processing device(s) may be an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), and/or a network processor, among other examples.

The APR protocol, according to an embodiment, includes two phases. In the first phase, shown inFIG.1, an alarm call connection135is set up between a fire panel140and an alarm/fire monitoring station143. In the second phase, shown inFIG.2, the relay agent141(executing via, e.g., the customer appliance, such as a MFVN device) and proxy agent142(executing via or implemented by, e.g., a remote/network controller or remote device/appliance) work together to perform compensation for latency and retransmissions for communications between the fire panel140and the alarm/fire monitoring station143over the alarm call connection135.

Referring now toFIG.1, the first phase begins at105, when the fire panel140dials the destination phone number of the monitoring station143. The relay agent141running on the customer appliance collects the digits of the destination phone number from the fire panel140prior to answering. At110, the customer appliance141provides a ringing tone to the fire panel140. At115, the relay agent141sends the collected digits to the proxy agent142. In response to receiving the collected digits, the proxy agent142at120establishes a connection to the alarm/fire monitoring station143. This functions to give a “head start” to the alarm connection.

Once the connection between the proxy agent142and the monitoring station143is established120, the proxy agent142informs the relay agent141at125that this connection has been established. At130, the relay agent141establishes a connection between the customer appliance141and the fire panel140by answering the alarm call placed by the fire panel140, and a real-time, end-to-end connection between the fire panel140and the monitoring station143thereby results at135.

By first establishing the connection120between the proxy agent142and the alarm/fire monitoring station143before providing answer signaling130to the fire panel140from the relay agent141at the customer appliance141, referred to herein as a “head start” method, latency is reduced.

Referring now toFIG.2, the second phase, according to an embodiment is shown. In this second phase, communication between the fire panel (FP)140and the monitoring station143is monitored and the relay agent141and proxy agent142work together to compensate for latency and transmission errors. Left-hand region144shows communications between FP140and the relay agent141at the customer appliance. Right-hand region145shows communications between the proxy agent142(which may be, e.g., executing at/part of a remote/network controller or remote device/appliance) and monitoring station143. Middle region146conceptually illustrates where error identification/detection and/or correction may occur for data/packets exchanged among FP140and monitoring station143.

Continuing with the second APR phase depicted byFIG.2, in a first transmission at205, packets labeled A-B-C-D-E-F originating from the FP140are transmitted from the relay agent141to the proxy agent142intact. Likewise, in a second transmission at210, packets labeled H-I-J originating from the monitoring station143are transmitted intact from the proxy agent142to the relay agent141. In a third transmission at215, packets labeled K-L-M-N-O-P-Q arrive at proxy agent142as “K-L-M-P-Q-O” and require correction at220, by proxy agent142, to insert missing packet “N” and be reordered for transmission to monitoring station143. According to an embodiment, to facilitate error correction, e.g., at220, when an original transmission such as215(e.g., packets K-L-M-N-O-P-Q) is initially received by relay agent141from the FP140, relay agent141may delay sending the transmission to proxy agent142for a certain amount of time. During this delay period, relay agent141may analyze, e.g., the packets, their formatting, and/or their placement/ordering and generate a “ground truth” record of the transmission. Next, the ground truth analysis may be sent by relay agent141to proxy agent142—in advance of the transmission215. The relay agent141may then release the delayed transmission, e.g.,215, so that it can be sent to proxy agent142. Finally, when the actual transmission is received by proxy agent142at220, proxy agent142may, e.g., compare the actual transmission to the previously-received ground truth analysis to identify/detect error(s), and correct any error(s) that may be present. It is further noted that, for detecting and/or correcting error(s), proxy agent142may additionally or alternately employ system logic that corresponds to a given communication protocol according to which transmissions are made. For example, in an embodiment, proxy agent142may recognize, e.g., a Contact ID protocol or other known communication protocol, and may detect and/or correct error(s) based on requirements, e.g., header/data formats and/or tones/frequencies, etc., specified by the protocol. Further details of exemplary transmissions according to Contact ID and other known protocols are provided hereinbelow in relation toFIGS.4A-Band5.

Continuing withFIG.2, in a fourth transmission at225, packets labeled R-S-T-U arrive out of order as “R-T-U-S” and require correction at230, by relay agent141, to be reordered for transmission to FP140. According to an embodiment, to facilitate error correction, e.g., at230, when an original transmission such as225(e.g., packets R-S-T-U) is initially received by proxy agent142from the monitoring station143, proxy agent142may delay sending the transmission to relay agent141for a certain amount of time. During this delay period, proxy agent142may analyze, e.g., the packets, their formatting, and/or their placement/ordering and generate a “ground truth” record of the transmission. Next, the ground truth analysis may be sent by proxy agent142to relay agent141—in advance of the transmission225. The proxy agent142may then release the delayed transmission, e.g.,225, so that it can be sent to relay agent141. Finally, when the actual transmission is received by relay agent141at230, relay agent141may, e.g., compare the actual transmission to the previously-received ground truth analysis to identify/detect error(s), and correct any error(s) that may be present. It is further noted that, for detecting and/or correcting error(s), relay agent141may additionally or alternately employ logic that corresponds to one or more communication protocols being used to transmit data. For example, in an embodiment, relay agent141may recognize, e.g., a Contact ID protocol or other known communication protocol, and may detect and/or correct error(s) based on requirements, e.g., header/data formats and/or tones/frequencies, etc., specified by the protocol. It should be noted that these transmissions215and225and corrections thereof220,230, are meant to show examples of packet insertion/repackaging/reordering/etc. performed by relay agent141and/or proxy agent142and can occur in other sequences. Likewise, other types of corrections may be implemented by embodiments.

FIG.3is a simplified block diagram of a system330for communication control, according to an example embodiment. Specifically, system330includes POTS device331, punch-down block332, customer appliance333, relay agent334, network335, SBC336, second agent337, remote appliance338, third agent339, private branch exchange (PBX) device340, and destination device341. Further, in system330, customer appliance333, e.g., a MFVN device, implements agent334where agent334may be configured to implement the functionality of relay agent141(FIG.1). Likewise, a remote/network controller (not shown), e.g., in network335and/or as part of SBC336, implements second agent337which may be configured to implement functionality of proxy agent142(FIG.1), while remote appliance338, e.g., a MFVN device, implements third agent339which may be configured to implement the functionality of proxy agent142.

Multiple different configurations and/or permutations of relay agent334, second agent337, and third agent339are possible in system330, according to embodiments. For example, in a first configuration, relay agent334may communicate (via, e.g., leg345aof connection344) with second agent337, while remote appliance338and third agent339are not present. In a second example configuration, relay agent334may communicate (via, e.g., legs345aand345bof connection344) with third agent339at remote appliance338, while second agent337is not present. Further, in yet a third example configuration, relay agent334may communicate (via, e.g., leg345aof connection344) with second agent337, and in turn second agent337may communicate (via., e.g., leg345bof connection344) with third agent339.

In an implementation, POTS device331may be, e.g., a burglar/security/elevator/fire alarm, an emergency call box, an elevator phone, an access control/entry system, or any other suitable POTS device known to those of skill in the art.

According to an aspect, optional punch-down block332may be, e.g., a “66 block” (used to connect sets of wires in a telephone system), or any other suitable known punch-down block.

In an embodiment, customer appliance333and/or remote appliance338may be, e.g., a Granite EPIK™ device (Granite Telecommunications, LLC, Quincy, MA) or any other suitable device known to those of skill in the art. According to an aspect, customer appliance333and remote appliance338may be configured to implement relay agent334and third agent339, respectively. In one such aspect, customer appliance333and/or remote appliance338may provide “Class-5” telephone switching functionality, such as tone generation and tone detection, among other examples. This functionality may be used by customer appliance333to implement relay agent334and/or method700(discussed in more detail hereinbelow in relation toFIG.7). Details of an exemplary tone detection technique according to some embodiments are provided hereinbelow in relation toFIGS.6A-D.

According to an example embodiment, customer appliance333may be a computer-based system for communication control. The customer appliance333may include a processor and a memory with computer code instructions stored thereon. In such an embodiment, the processor and the memory, with the computer code instructions, are configured to cause customer appliance333to implement any embodiments or combination of embodiments described herein. According to an aspect, functionality implemented by the processor and memory may include tone generation and/or detection function(s) described herein.

Further, in yet another example embodiment, customer appliance333may include a non-transitory computer program product for communication control. The computer program product may include a computer-readable medium with computer code instructions stored thereon. According to such an embodiment, the computer code instructions are configured, when executed by a processor, to cause an apparatus associated with the processor to implement any embodiments or combination of embodiments described herein. According to an aspect, functionality implemented by the computer-readable medium, computer code instructions, and processor may include tone generation and/or detection function(s) described herein.

In an implementation, network335may include network elements such as SBC336, which may be used to protect Session Initiation Protocol (SIP)-based voice over Internet Protocol (VoIP) networks, among other examples. Further, according to an embodiment, network335may offer, e.g., time-division multiplexing (TDM) functionality, and may support one or more known communications protocols.

Similar to customer appliance333, in an aspect, the remote/network controller (not shown) and remote appliance338may be configured to implement second agent337and third agent339, respectively.

Further, according to an implementation, if present, optional remote appliance338may support, e.g., Primary Rate Interface (PRI)342, SBC/Multiprotocol Label Switching (MPLS)343, and/or other known connection(s), to destination device341, or, if present, to optional PBX340. The optional remote appliance338may further be configured to communicate with network335and/or SBC336, as well as other known network elements. If optional remote appliance338is not present and optional PBX340is present, then PBX340may connect, e.g., via PRI342to a (not shown) public switched telephone network (PSTN) and/or via SIP to a data center (not shown) such as may be part of network335.

In an embodiment, optional device340may be, e.g., a PBX or other suitable known telephone system, and may interface with optional remote appliance338, if present, via, e.g., PRI342and/or a SBC/MPLS handoff343. If present, optional PBX340may be configured to provide functionality such as analog-to-digital conversion for destination device341. Further, in an aspect, optional remote appliance338, optional PBX340, and/or destination device341may be equipment that is owned/maintained by, e.g., a fire monitoring company.

In an embodiment, a network connection344, such as a private network connection, among other examples, may be established between customer appliance333and remote appliance338via network335. The connection344may include, for example, a first portion345afrom customer appliance333to network335, and a second portion345bfrom network335to remote appliance338. In an embodiment, network connection344may be, e.g., a wired connection, a cellular/LTE or other known wireless connection, a LAN (local area network) or WAN (wide area network) connection, or any other suitable network connection known to those of skill in the art. Similarly, in an aspect, by utilizing network connection344, telephone connection346may be established between POTS device331and destination device341. Further, according to an embodiment, latency compensation347(implemented via, e.g., relay agent334and/or second agent337) and/or optional latency compensation348(implemented via, e.g., second agent337and/or third agent339) may be applied to telephone call346.

In an implementation, device341may be, e.g., an alarm monitoring station or other suitable known device.

Hereinbelow, in relation to method700ofFIG.7, a description of system330implementing example embodiments of APR phase1(FIG.1) and phase2(FIG.2) is provided.

FIGS.4A and4Bare images440and444, respectively, of a recording of a telephone call between a first device441and a second device442where the telephone call may be controlled according to an example embodiment. In an aspect, images440and444may be displayed by an “analyzer” component or tool associated with the APR protocol. The first device441may be, e.g., fire panel140(FIG.1) or POTS device331(FIG.3). Likewise, second device442may be, e.g., alarm monitoring station143(FIG.1) or destination device341(FIG.3). As shown inFIGS.4A and4B, first device441sends transmissions446a-eto second device442. Likewise, second device442sends transmission447to first device441.FIG.4Ashows the recording at time443, whileFIG.4Bshows the same recording at time445. According to an implementation, transmissions446a-eand/or447may undergo frequency analysis by the analyzer component as described in more detail hereinbelow in relation toFIGS.6A-D.

In an embodiment, transmissions446a-eand/or447may be transmitted via, e.g., end-to-end connection135(FIG.1) or telephone connection346(FIG.3). Further, according to an aspect, transmissions446a-eand447may correspond to, e.g., transmissions205/215and transmissions210/225, respectively, ofFIG.2. Details of monitoring transmissions446a-eand/or447, and identifying and/or correcting error(s) in the transmissions are provided hereinbelow in relation to method700ofFIG.7.

FIG.5is a user interface550displaying a set of tones559a-lsent and/or received as part of a telephone call that may be controlled according to an example embodiment. According to an implementation, interface550may be displayed by an analyzer component associated with the APR protocol. Further, in an embodiment, tones559a-lmay be identified or detected based on a frequency analysis technique employed by the analyzer component and described in more detail hereinbelow in relation toFIGS.6A-D. In an aspect, the telephone call displayed by user interface550may occur between, e.g., fire panel140(FIG.1), POTS device331(FIG.3), or first device441(FIG.4A) and alarm monitoring station143(FIG.1), destination device341(FIG.3), or second device442(FIG.4A). Further, in an embodiment, the telephone call may take place via, e.g., end-to-end connection135(FIG.1) or telephone connection346(FIG.3). As shown inFIG.5, user interface550displays tones559a-lfor a communications protocol type551. In an implementation, communications protocol type551is a “Contact ID” protocol. However, embodiments of the present disclosure are not limited to a particular type of communications protocol; instead, any suitable communications protocol known in the art may be used.

Continuing withFIG.5, for each of tones559a-l, user interface550displays a tone type552, tone frequency553, start time554in milliseconds (ms), end time555in ms, length556in ms, squelch threshold557, and squelch response558in ms. For example, in an embodiment, tone559amay have a type552of “Signal,” a frequency553of 1400 (which may be in, e.g., hertz (Hz)), a start time554of 9994 ms, an end time555of 10994 ms, a length556of 1000 ms (e.g., based on subtracting start time 9994 ms from end time 10994 ms), a squelch threshold557of 0.0125, and a squelch response558of 2 ms.

In an aspect, squelch threshold557may be a threshold value or factor employed when using a known technique (e.g., a Fourier transform) to identify audio signals or tones, e.g., tones559a-l, from a stream of digital values. Further, in an implementation, threshold557may be determined by, for example, initializing its value to 0.1, and then repeatedly dividing the value by 2.0 until either a signal/tone is identified or a limit, such as 0.0001, is reached. According to an embodiment, threshold557may also differ according to, or be specified by, a protocol being used, such as Contact ID or FSK, among other examples.

As another example, in an aspect, tone559cmay have a type552of “DTMF” (dual-tone multi-frequency signaling used for push-button telephones), a frequency553of “DTMF2” (e.g., corresponding to a telephone ‘2’ key, which frequency may be a combination of a 697 Hz “low” tone and a 1336 Hz “high” tone), a start time554of 14360 ms, an end time555of 14420 ms, a length550of 60 ms, a squelch threshold557of 0.025, and a squelch response558of 20 ms.

Referring again toFIG.5, in an implementation, a tone type552of “Signal” may indicate a tone sent for purposes of signaling and/or handshaking between two devices according to a given communications protocol, e.g., Contact ID, while a tone type552other than “Signal” (such as “DTMF”) may indicate a data transmission sent following completion of signaling and/or handshaking. Thus, in an embodiment, according to the Contact ID protocol, handshaking may be conducted by first sending a single (or “pure”) tone of 1400 Hz (e.g., tone559a), followed by a single tone of 2300 Hz (e.g., tone559b). In an aspect, after handshaking is complete, any number of data transmissions may be sent, e.g., tones559c-l. Further, according to an implementation, a final data transmission, e.g., tone559l, may correspond to a “checksum” digit or packet that enables a device to perform integrity verification for a received message. In an embodiment, following successful receipt, a device may send a single tone (not shown) of 1400 Hz as a “kiss-off” signal indicating that communications have ended. According to an aspect, if a transmitting device does not receive a kiss-off signal within, e.g., a present amount of time, it may perform one or more retransmissions of a message.

In an embodiment, tones559c-lmay correspond to, e.g., packet/data transmissions205/215and/or210/225(FIG.2). Details of monitoring packets559c-land identifying and/or correcting error(s) in the packets are provided hereinbelow in relation to method700ofFIG.7.

FIGS.6A,6B,6C, and6Dare graphs600,610,620, and630, respectively, of frequency analyses according to an example embodiment. According to an aspect, graphs600,610,620, and630may be displayed by the analyzer component associated with the APR protocol. In an implementation, the analyzer may use a known technique, such as Fourier transform, to identify audio signals or tones by searching through a data stream, e.g., a stream of digital values, while adjusting a threshold factor and a sampling window size. According to an embodiment, the threshold factor may be determined according to the technique described hereinabove in relation to squelch threshold557ofFIG.5. In an aspect, window size may be determined by, for example, initializing its value to a suitably high number, and then repeatedly dividing the value by 2.0 until either a signal/tone is identified or a limit, such as 128, is reached. Further, in an implementation, the sample count for a given window size may be calculated by, e.g., dividing the window size by 1,000 and then multiplying by an audio sample rate.

As shown inFIG.6A, graph600reflects a window size601of 2048. Further, graph600indicates that data packet602includes a peak603of approximately 1400 Hz (corresponding to −31.0 dB [decibel]); peak603is also displayed visually604.

As shown inFIG.6B, graph610, like graph600, reflects window size601of 2048. Further, graph610indicates that data packet605includes a peak606of approximately 2300 Hz (corresponding to −35.1 dB); peak606is also displayed visually607.

As shown inFIG.6C, graph620reflects a window size608of 128. Further, graph620indicates that data packet602includes a peak609of approximately 1400 Hz (corresponding to −28.0 dB); peak609is also displayed visually611.

As shown inFIG.6D, graph630, like graph620, has a window size608of 128. Further, graph630indicates that data packet605includes a peak612of approximately 2300 Hz (corresponding to −28.4 dB); peak612is also displayed visually613.

FIG.7is a flow diagram of a method700for communication control, according to an embodiment. The method700may be implemented by a relay agent, e.g., relay agent/customer appliance141(FIG.1) or relay agent334operating at customer appliance333(FIG.3). In an aspect, some or all portions of method700may be performed as part of implementing functionality of Session layer805and/or Presentation layer806of OSI model800, discussed in more detail hereinbelow in relation toFIG.8.

The method700starts at step701by receiving a telephone call from a POTS device, e.g., POTS device140(FIG.1) or331(FIG.3). The telephone call includes a telephone number corresponding to a destination device, e.g., device143(FIG.1) or341(FIG.3).

Next, at step702, method700provides a ringing tone (also referred to as a ringback tone or audible ringing) to the POTS device. For example, in an implementation, when routing of a call is successful and a destination device is not already busy, the recipient may be alerted to the incoming call. During this period of alerting, the caller may also receive a distinctive signal, e.g., a ringing tone or ringback tone.

The method700then, at step703, transmits, e.g., via network connection344and network335(FIG.3) or network70(FIG.9), the telephone number to a proxy agent, e.g., proxy agent/controller142(FIG.1).

At step704, method700receives, e.g., via network connection344and network335or70, a message from the proxy agent. The message indicates that a telephonic connection has been established between the proxy agent (e.g.,142) and the destination device (e.g.,143or341).

Last, at step705, responsive to receiving the message from the proxy agent, method700creates a real-time communications connection, e.g., telephone connection346(FIG.3), between the POTS device and the destination device by providing answer signaling for the received telephone call to the POTS device.

In an aspect, method700may further include monitoring transmissions, e.g., transmissions205,210,215, or225(FIG.2),446a-eor447(FIG.4A), or559a-l(FIG.5), on the real-time communications connection between the POTS device and the destination device. Responsive to the monitoring, method700may also identify one or more errors, e.g., errors220or230(FIG.2), in a given transmission.

According to an implementation, the one or more errors may be identified based on a discrepancy between a communications protocol and the given transmission. In an embodiment, method700may further correct the one or more errors by modifying the given transmission to be in accordance with the communications protocol. For example, in an aspect, the communications protocol may be a fire alarm and signaling code, e.g., NFPA 72®. According to NFPA 72®, a MFVN may be defined as a physical facilities-based network capable of transmitting real-time signals with formats unchanged that is managed, operated, and maintained by a service provider to ensure service quality and reliability from a subscriber location to PSTN interconnection points or other MFVN peer networks. In an implementation, to comply with the requirement that real-time signals have their “formats unchanged,” method700may modify the given transmission so that its original format—e.g., prior to the one or more errors occurring—is not changed due to an influence of the one or more errors. According to some embodiments, because an original format of the given transmission, e.g.,205,210,215, or225(FIG.2),446a-eor447(FIG.4A), or559a-l(FIG.5), is known by e.g., relay agent334, second agent337, and/or third agent339(FIG.3), such knowledge may be used to identify or recognize the discrepancy with the communications protocol and modify the given transmission to return it to the original format, e.g., as shown by recording images440(FIG.4A) or444(FIG.4B), by eliminating or removing the influence of the one or more errors.

Similarly, in an aspect, relay agent334, second agent337, and/or third agent339may understand requirements/mechanics for the communications protocol, e.g., NFPA 72®, and may be aware of what signal and/or packet sequences are expected while a transmission is taking place according to the protocol. Thus, in an embodiment, if relay agent334, second agent337, and/or third agent339detects that, e.g., packets are not in a proper order and do not meet logic and/or algorithm requirement(s) for the protocol, relay agent334, second agent337, and/or third agent339may intercede and rearrange or reorder the packets to comply with the requirement(s).

As yet another example, in an embodiment, and with reference toFIG.5, if method700detects that a first tone frequency, e.g., frequency553of tone559a, is not 1400 Hz or is missing, then method700may perform automatic error correction, such as by modifying of tone559ato be 1400 Hz or by inserting a tone with a frequency of 1400 Hz in an appropriate location. In an embodiment, method700may be aware of required frequencies, and their correct sequence and timing, for a given communications protocol.

Continuing withFIG.7, according to an aspect, the one or more errors may include a missing packet, e.g., error220(FIG.2), an out-of-order packet, e.g., error220or230(FIG.2), or a mistimed packet. Further, it is noted that embodiments of method700are not limited to correcting the aforementioned errors and embodiments may correct any errors that occur.

In an implementation, method700may further include correcting the one or more errors in the given transmission. According to an embodiment, method700may correct the one or more errors in the given transmission by inserting one or more packets into the given transmission, reordering one or more packets of the given transmission, or modifying a tone frequency of one or more packets of the given transmission. Further, it is noted that embodiments of method700are not limited to performing the aforementioned corrective actions and embodiments may implement any desired corrective actions known to those of skill in the art.

According to an aspect, method700may further include creating a secure tunnel by encrypting the real-time communications connection. In an embodiment, the secure tunnel may be facilitated by employing a lightweight VPN (virtual private network) tunneling mechanism. Further, in an implementation, utilizing the secure tunnel may provide benefits such as enabling compliance with an organization's or entity's security and/or firewall requirements. According to an aspect, because the secure tunnel enables end-to-end encryption of communications, the communications may be protected from, e.g., hacking and “phreaking” attacks. In contrast, existing approaches provide only partial or incomplete security and, thus, are vulnerable to communications being comprised, such as by call eavesdropping or snooping when security measures terminate at a PSTN.

FIG.8is a block diagram illustrating an OSI model800, according to an example embodiment. In an aspect, model800may be a conceptual model that provides a common basis for coordination of standards development for purpose of systems interconnection. As shown inFIG.8, in model800, communications between systems may be split into seven different abstraction layers: Physical801, Data Link802, Network803, Transport804, Session805, Presentation806, and Application807.

Continuing withFIG.8, in an implementation, model800may partition dataflows in a communication system into the seven abstraction layers801-807to describe networked communication from, e.g., physical implementation of transmitting bits across a communications medium to a highest-level representation of data of a distributed application. Each intermediate layer may serve a class of functionality to a layer above it and may be served by a layer below it.

Referring again toFIG.8, in an embodiment, each layer in model800may have well-defined functions, and functions of each layer may communicate and interact with those of layers immediately above and below as appropriate. For example, in an aspect, Physical layer801may include functions such as transmission and reception of raw bit streams over a physical medium. Data Link layer802may include functions such as transmission of data frames between two nodes connected by Physical layer801. Network layer803may include functions such as structuring and managing a multi-node network, including functions such as addressing, routing and traffic control, among other examples. Transport layer804may include functions such as reliable transmission of data segments between points on a network, including functions such as segmentation, acknowledgement, and multiplexing, among other examples. Session layer805may include functions such as managing communication sessions, e.g., continuous exchange of information such as via multiple back-and-forth transmissions between two nodes. Presentation layer806may include functions such as translation of data between a networking service and an application, including character encoding, data compression, and encryption/decryption, among other examples. Application layer807may include functionality for high-level protocols, such as resource sharing or remote file access, via e.g., HTTP, and other protocols known to those of skill in the art.

In some embodiments, relay agent141(FIG.1) or334(FIG.3), second agent142(FIG.1) or337(FIG.3), and/or third agent339(FIG.3) may provide functionality, such as repacking/reordering packets, inserting missing packets, latency compensation347, optional latency compensation348, etc., among other examples, that corresponds to Session layer805and/or Presentation layer806of OSI model800.

FIG.9illustrates a computer network or similar digital processing environment in which embodiments of the present disclosure may be implemented.

Client computer(s)/device(s)50and server computer(s)60provide processing, storage, and input/output devices executing application programs and the like. The client computer(s)/devices50can also be linked through communications network70to other computing devices, including other client computer(s)/device(s)50and server computer(s)60. The communications network70can be part of a remote access network, a global network (e.g., the Internet), a worldwide collection of computers, local area or wide area networks, and gateways that currently use respective protocols (TCP/IP, Bluetooth®, etc.) to communicate with one another. Other electronic device/computer network architectures are suitable.

Client computer(s)/device(s)50and/or server computer(s)60may be configured, alone or in combination, to implement the embodiments described herein, e.g., the method700, among other examples. The server computer(s)60may not be separate server computers but part of communications network70.

FIG.10is a diagram of an example internal structure of a computer (e.g., client computer(s)/device(s)50or server computer(s)60) in the computer system ofFIG.9. Each computer/device50and server computer60contains a system bus79, where a bus is a set of hardware lines used for data transfer among the components of a computer or processing system. The system bus79is essentially a shared conduit that connects different elements of a computer system (e.g., processor, disk storage, memory, input/output (I/O) ports, network ports, etc.) and enables the transfer of information between the elements. Attached to the system bus79is an I/O device interface82for connecting various input and output devices (e.g., keyboard, mouse, displays, printers, speakers, etc.) to the computer/device50or server computer60. A network interface86allows the computer/device50or server computer60to connect to various other devices attached to a network (e.g., communications network70ofFIG.9). Memory90provides volatile storage for computer software instructions92and data94used to implement an embodiment of the present disclosure (e.g., the method700, among others). Disk storage95provides non-volatile storage for computer software instructions92and data94used to implement an embodiment of the present disclosure. A central processor unit84is also attached to the system bus79and provides for the execution of computer instructions.

U.S. Pat. No. 10,986,555, with inventor Moshayedi, titled “Analog And Digital Communication System For Interfacing Plain Old Telephone Service Devices With A Network” (hereinafter “the '555 Patent”), is incorporated by reference in its entirety. The '555 Patent discloses an analog and digital communication system which establishes a connection between a POTS device and a destination device. According to an embodiment of the '555 Patent, the system includes a customer appliance that includes multiple ports, an internal power source device, a subscriber identification module (SIM) card, an electronic control unit, an analog to digital converter, and a processor device. In operation, at least one of the ports is operably connected to the POTS device. A controller communicates remotely with the customer appliance via a network to provide routing of a telephone call between the POTS device and the destination device. The controller is configured to at least one of transmit the telephone call or receive the telephone call via a closest PSTN handoff or via an internal customer appliance network establishing a connection between the customer appliance and a second customer appliance. Embodiments described herein, e.g., method700, may be implemented, in whole or in part, using embodiments described in the '555 Patent.

Embodiments or aspects thereof may be implemented in the form of hardware including but not limited to hardware circuitry, firmware, or software. If implemented in software, the software may be stored on any non-transient computer readable medium that is configured to enable a processor to load the software or subsets of instructions thereof. The processor then executes the instructions and is configured to operate or cause an apparatus to operate in a manner as described herein.

Further, hardware, firmware, software, routines, or instructions may be described herein as performing certain actions and/or functions of the data processors. However, it should be appreciated that such descriptions contained herein are merely for convenience and that such actions in fact result from computing devices, processors, controllers, or other devices executing the firmware, software, routines, instructions, etc.

It should be understood that the flow diagrams, block diagrams, and network diagrams may include more or fewer elements, be arranged differently, or be represented differently. But it further should be understood that certain implementations may dictate the block and network diagrams and the number of block and network diagrams illustrating the execution of the embodiments be implemented in a particular way.

Accordingly, further embodiments may also be implemented in a variety of computer architectures, physical, virtual, cloud computers, and/or some combination thereof, and, thus, the data processors described herein are intended for purposes of illustration only and not as a limitation of the embodiments.

The teachings of all patents, applications, and references cited herein are incorporated by reference in their entirety.

While example embodiments have been particularly shown and described, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the embodiments encompassed by the appended claims.