Patent Application
20250184865
The present disclosure generally relates to establishing a call between a wireless terminal in a multi-cell network and a server and, in particular, establishing a call between a wireless terminal localized to a secondary base station in a multi-cell network and an end or external server using packet forwarding by a primary base station.
To reach non-local terminals via a Voice over Internet Protocol (VoIP) network, a wireless terminal may connect to an end or external server via a base station. Typically, a multi-cell network will include a primary base station (i.e., “master” base station) that is responsible for connecting the call to the end server and multiple secondary base stations (i.e., “slave” base stations) that connect a call from a user terminal to the primary base station.
Resource contention and processor loading issues can arise in the primary base station, especially during high call traffic, because all calls from other base stations must go through the VoIP processor of the primary base station to reach the end server. To help resolve the resource contention, additional processors and processor cores are often added to primary base stations. However, such hardware-based solutions are generally expensive and difficult to scale.
Disclosed embodiments are directed to establishing a call between a wireless terminal associated with a secondary base station of a multi-cell system and a server via network address translation-based forwarding, in kernel space or via a user-space application, by a primary base station of the multi-cell system. The embodiments provide a low cost, scalable, method for assisting primary base stations in multi-cell sites with handling high call traffic.
Disclosed embodiments are directed to the use of a firewall application in a primary base station to forward IP media packets streaming between a secondary base station and a pre-determined destination, such as an external or end VoIP server. Session Description Protocol (SIP) information from a VoIP call on a primary base station may be used to populate the firewall forwarding rules to allow forwarding of media packets from a secondary base station to and from a port and IP address specified in an SDP header.
In one aspect, disclosed embodiments are directed to a method, system, and computer-readable media for establishing a call between a wireless terminal and a server, the wireless terminal associated with a secondary base station of a multi-cell network, via network address translation-based packet forwarding by a primary base station of the multi-cell network. The method includes receiving, at the primary base station of the multi-cell network, a request to establish a call between the secondary base station of the multi-cell network and the server. The method further includes adding a set of forwarding rules to a network address translation table of the primary base station. The set of forwarding rules instruct the primary base station to forward packets of the call received from the server to the secondary base station and to forward packets of the call received from the secondary base station to the server.
Embodiments may include one or more of the following features, individually or in combination.
The adding of the set of forwarding rules to the network address translation table may be performed by an application running on one or more processors of the primary base station. The adding of the set of forwarding rules to the network address translation table may be performed by a kernel of an operating system running on one or more processors of the primary base station. The adding of a set of forwarding rules may include adding a first rule to change a destination address of the packets to an address of the secondary base station for packets inbound to the primary base station from the server; adding a second rule to change a source address of the packets to an address of the primary base station for packets outbound from the primary base station to the secondary base station; adding a third rule to change a destination address of the packets to an address of the server for packets inbound from the secondary base station to the primary base station; and adding a fourth rule to change a source address of the packets to an address of the primary base station for packets outbound from the primary base station to the server.
One or more of the following may include an IP address and a port value: the destination address of the packets, the address of the secondary base station, the source address of the packets, the address of the primary base station, and the address of the server. The set of forwarding rules may include a first subset of forwarding rules for forwarding real time protocol (RTP) packets and a second subset of forwarding rules for forwarding real time control protocol (RTCP) packets.
The method may further include determining whether the call has been terminated; and based on said determining whether the call has been terminated, deleting the set of forwarding rules. One or more outbound packets may flow from the primary base station to the server and/or secondary base station are disabled after the receiving of the request to establish a call between the secondary base station and the server.
The method may further include generating an entry for the call in a call table, wherein the entry includes an indication of whether the set of forwarding rules is enabled for the call, a destination address of the server, and a destination address of the secondary base station for the call. The method may further include determining whether the call has terminated; and based on said determining whether the call has ended, deleting the entry for the call in the call table. The set of forwarding rules may be indicated as enabled in the entry for the call if the set of forwarding rules has been added to the network address translation table. The entry for the call may further include one or more pointers identifying the call, said one or more pointers including a first pointer identifying a message flow between the primary base station and the server and a second pointer identifying a message flow between the primary base station and the second primary base station. The entry for the call may further include one or more media transport states of the call received via session description protocol (SDP), said one or more media transport states including one or more media states of a message flow between the primary base station and the server and a media transport state of a message flow between the primary base station and the secondary base station.
The method may further include determining whether to update or delete the set of forwarding rules based on one or more SIP signaling events. The method may further include determining whether one or more endpoints have changed; and based on said determining whether one or more endpoints have changed, deleting the set of forwarding rules and adding a new set forwarding rules to the network address translation table. The method may further include saving said one or more endpoints which have changed to a call table that includes a destination address of the server and a destination address of the secondary base station.
The method may further include receiving a call hold indication; deleting the set of forwarding rules based on said receiving a call hold indication; receiving a call resume indication; and adding a new set of forwarding rules to the network address translation table based on said receiving a call resume indication. The method may further include determining, prior to said deleting the set of forwarding rules, whether the call hold indication was received from the secondary base station; and proceeding, upon determining that the call hold indication was received from the secondary base station, with said deleting the set of forwarding rules.
The set of forwarding rules may be configured after one or more media port selections have been completed but before any media packets of the call have been received. The method may further include, after said adding a set of forwarding rules, deleting each packet flow between the primary base station and the server and the primary base station and the secondary base station tracked by a kernel connection tracker. The method may further include disabling an outbound redirect message from the primary base station to the server; and disabling an outbound redirect message from the primary base station to the secondary base station. The outbound redirect message from the primary base station to the server and the outbound redirect message from the primary base station to the secondary base station are internet control message protocol version 6 (ICMPv6) messages.
The method may further include creating, prior to said adding the set forwarding rules to the network address translation table, a shell process that includes a destination address of the secondary base station, a destination address of the server, and a source address of the primary base station. The shell process may be further configured to run an iptables command to add the set of forwarding rules to the network address translation table.
Where considered appropriate, reference numerals may be repeated among the drawings to indicate corresponding or analogous elements. Moreover, some of the blocks depicted in the drawings may be combined into a single function.
Reference will now be made in detail to the embodiments of the invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with these embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications, and equivalents that may be included within the scope of the invention as defined by the appended claims. Furthermore, in the following detailed description, numerous specific details are set forth to provide a thorough understanding of the present invention. However, it will be understood by those of ordinary skill in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the present invention.
Digital Enhanced Cordless Telecommunications (DECT) is a standard that primarily describes the wireless connection between cordless phones and their base stations. DECT uses Time Division Multiple Access (TDMA) to allow multiple handsets to communicate with the base station simultaneously. It divides the communication channel into multiple time slots, and each handset is assigned a specific time slot in which to transmit and receive information.
In embodiments, there are multiple base stations 110 and wireless communication terminals 130, which may roam among base stations 110 during operation. One base station may be set up as a primary base station and all other base stations may be set up as secondary base stations.
When a wireless terminal 130 is first used in the system 200, it is registered with the base stations (220, 230), which record its unique ID. Generally, when the wireless terminal 130 makes a call, the closest base station (220, 230) sets up the call, i.e., the base station (220, 230) to which the wireless terminal 130 is “localized.” This process is facilitated through a frequency/time slot pattern, with each base station (220, 230) and handset pairing given a unique pattern to avoid interference. As a wireless terminal 130 moves from the coverage area, i.e., cell 210, of one base station (220, 230) to another, the system performs a handover. This involves the base station with a weakening signal handing over the connection to the base station where the signal is getting stronger. This process is seamless to the user, who does not experience any interruption in their call.
The primary base station 220, which is connected to an Internet Protocol (IP) network, converts the call request to the appropriate VoIP protocol, e.g., Session Initiation Protocol (SIP), in which case an SIP INVITE request is sent out to the server 160 signaling the intention to establish a call. The server 160 processes the request and responds, with an SIP OK if everything is in order or with an appropriate SIP error message if there is a problem. The primary base station 220 receives the response from the server 160 and forwards the appropriate signaling back to the wireless terminal 130 through the secondary base station 230. Once the call is accepted, the primary base station 220 and the server 160 negotiate the technical parameters of the call, such as the codecs to be used.
In conventional approaches, two call legs are established: (1) a proxy call leg between the primary base station 220 and the secondary base station 230, and (2) an actual call leg between the primary base station 220 and the server 160. As noted above, resource contention and processor loading issues can arise in the primary base station 220, especially during high call traffic, because all calls must be processed by the VoIP processor 222 of the primary base station 220 to reach the server 160.
The VoIP processors 222, 232 of the primary base station 220 and secondary base station 230 each include a Call Control module 322, 332 (respectively) which is responsible for handling higher-level functions related to establishing, maintaining, and tearing down calls. In particular, the Call Control module 322, 332 handles signaling, setting up a channel for communication, and interfacing with end and/or external servers (e.g., a VoIP server). The Call Control module 322, 332 interacts with signaling protocols (e.g., SIP in the context of VoIP), manages resources of the base station, handles mobility aspects, such as handover, which occurs when a DECT handset moves between base stations.
The primary base station 220 and secondary base station 230 include a radio integrated circuit (IC) 314 and 315 (respectively) which handles the wireless radio frequency (RF) communication between the DECT base station and the DECT handsets. Each radio IC 314, 315 includes a radio transceiver 308 and 318 which handles the physical transmission and reception of RF signals, modulates the digital data to be transmitted wirelessly via RF signals, and demodulates received RF signals to retrieve the received digital data.
Each radio IC 314 and 315 includes a medium access control (MAC) module 320 and 324 (respectively), which is responsible for managing the Time Division Multiple Access (TDMA) time slots and ensuring that each device (e.g., base station or handset) transmits or receives in its allocated time, avoiding collisions. DECT allows for multiple parallel communications, such as voice, data, and control signals, over the same channel. The MAC module 320, 324 handles the multiplexing of these different types of communication into the TDMA structure.
In each radio IC 314, 315, the MAC module 320, 324 is in communication with the radio IC end of a Time Division Multiplexing (TDM) interface 316 and 326 which functionally connects the radio IC to the VoIP processor 222 and 232 of the base stations 220, 230 via the VoIP end of the TDM interface 310 and 312 (respectively). The data input and output by the VoIP end of the TDM interface 310, 312 is processed by other components of the VoIP processor 222, 232, as discussed in further detail below.
The Call Control 322, 332 may each interact with an information data base 372, 374 responsible for storing call-related information, such as SIP data. The Call Control 322, 332 interacts with a Voice over Internet Protocol application (VoIP APP) 370, 371, which handles call setup, management, and termination. Specifically, the VoIP application 370, 371 handles signaling protocols, such as Session Initiation Protocol (SIP), to establish, manage, and terminate calls over the IP network. For example, the VoIP application sends and receives signaling messages, such as INVITE, ACK, BYE, etc. The VoIP application 370, 371 is also responsible for the RTP (Real-time Transport Protocol) streams, including packetizing the voice data, handling sequence numbering, timestamping, etc.
The base stations 220, 230 also include the following: the Audio Manager 346, 348 for handling audio packets; TDM Control 350, 352 which interacts within the VoIP end of the TDM Interface 310, 312 (discussed above) to control time division multiplexing and demultiplexing; the digital signal processor (DSP) 364, 365; and the RTP module 334, 336, which is responsible for handling real time protocol (RTP) packets and real time protocol control (RTCP) packets.
In embodiments, the primary base station 220 includes an Iptables Manager application 358. The VoIP App 370 may interact with the Iptables Manager 358 and can provide updates to the Iptables Manager 358 based on Session Initiation Protocol (SIP) information including Session Description Protocol (SDP) received from the server 160 or the secondary base station 230 regarding a call.
The Iptables Manager 358 can be configured to modify forwarding rules handled by a kernel (and/or an application in user space) of the primary base station 220. In embodiments, the Iptables Manager 358 may modify rules within the network address translation (NAT) table 356 managed by the kernel (and/or a user-space application). In embodiments, the Iptables Manager 358 may modify rules within the NAT 356 by using the iptables command.
For example, the primary base station 110 may run a Linux operating system. In such a case, the iptables command controls the firewall operations, such as packet filtering, NAT management, and packet mangling by defining rule sets. The Iptables Manager 358 may add a set of forwarding rules to the NAT 356 handled, e.g., by the kernel, of the primary base station 220 using the iptables command. The forwarding rules can instruct the kernel to forward packets of the call received from the server 160 to the secondary base station 230 and to forward packets of the call received from the secondary base station 230 to the server 160, thereby completing the call without setting up a proxy call and without accessing the VoIP application 370 of the primary base station 220.
Generally, as data packets from the network enter the kernel, the packets are compared with the forwarding rules and acted on accordingly (e.g., accepted, dropped, or modified). The forwarding rules established in the NAT 356 can contain rules for modifying the source and destination IP address and port values in the IP packet header. Thus, as depicted in
In embodiments, the Iptables Manager 358 can add the set of forwarding rules to the NAT 356 managed by the primary base station 220 (e.g., by the kernel thereof) upon the primary base station 220 receiving a request to establish a call between the secondary base station 230 and the server 160. Similarly, in embodiments, the Iptables Manager 358 may delete the call forwarding rules from the NAT 356 based on determining that the call has been terminated. Thus, the NAT 356 may be returned to its original state after the call is terminated.
As discussed above, the Iptables Manager 358 may receive SIP information for the call from the VoIP APP 370. In embodiments, events from the SIP of the call may drive the Iptables Manager 358. For example, the Iptables Manager 358 may be driven by the SIP stack. In embodiments, all operations and API calls may be made within the SIP stack thread context. Thus, the Iptables Manager 358 may be single threaded.
Each call may include a call leg (e.g., call between primary base station 220 and secondary base station 230 or call between primary base station 220 and the sever 160). In embodiments, the Iptables Manager 358 may be driven by both signaling events associated with SIP signaling traffic on a particular call leg and media events associated with Subscription Data Protocol (SDP) media negotiated during the particular call leg may drive the Iptables Manager 358. The SDP media may be represented via CCall and CMedia objects.
For example, the SDP may include an indication that the call has been terminated. In another example, the forwarding rules may be determined on one or more addresses received via session description protocol (SDP). In embodiments, the addresses necessary for packet forwarding under the forwarding rules (e.g., IP address and port values) are specified in an SDP header.
In embodiments, the forwarding rules may include a first rule to change a destination address of the packets to an address of the secondary base station 230 for packets inbound to the primary base station 220 from the server 160; a second rule to change a source address of the packets to an address of the primary base station for packets outbound from the primary base station to the secondary base station; a third rule to change a destination address of the packets to an address of the server for packets inbound from the secondary base station to the primary base station; and a fourth rule to change a source address of the packets to an address of the primary base station for packets outbound from the primary base station to the server. The destination address of the packets, the address of the secondary base station, the source address of the packets, the address of the primary base station, and the address of the server may comprise an IP address and a port value.
In embodiments, the first rule and third rule may each constitute a destination network address translation (DNAT) rule. In embodiments, the second rule and fourth rule may each constitute a source network address translation (SNAT) rule. In embodiments, the forwarding rules may include a first subset of forwarding rules for forwarding RTP packets and a second subset of forwarding rules for forwarding RTCP packets. The first subset of forwarding rules may use even port values for each source address and destination address and the second subset of forwarding rules may use odd port values for each source address and destination address. Further, each port value assigned by the second subset of forwarding rules may be a next highest odd port value of a corresponding even port value assigned by the first subset of forwarding rules.
In embodiments, the entry for the call further includes one or more media transport states of the call. The one or more media transport states of the call may be received via SDP. For example, the one or more media transport states may include one or more media states of a message flow between the primary base station (220) and the server (160) (e.g., actual call leg 404) and a media transport state of a message flow between the primary base station (160) and the secondary station (230) (e.g., proxy call leg 402). The media transport states can be in a closed state (“closed”), a send and receive state (“sendrev”), a receive only state (“recvonly”), or a send only state (“sendonly”). Thus, each row of the call table 550 may contain information about the call, including: CCall objects for the actual and proxy call legs, CMedia transport modes (indicating the state of the media such as CLOSED, SENDRECV, RECVONLY, etc), local/remote IP address and port values for the media streams, and whether NAT forwarding rules are currently enabled or disabled.
For example, as depicted in
In embodiments, the Iptables Manager 358, may delete the entry for the call in the call table upon determining that the call has terminated. Thus, the Iptables Manager 358 can act based on signaling or media events such as creating/deleting a table row when a call is established/deleted, or setting/deleting rules when the SDP indicates the media session are active or closed. Furthermore, such signaling or media events may also control when the Iptables Manager 358 adds/deletes the forwarding rules. For example, prior to adding a set of forwarding rules, the Iptables Manager 358 may determine that the call is determined to have a media transport state of send and receive (“sendrecv”). In another example, the Iptables Manager 358 may receive an indication via SDP of a media transport state of “closed” for the call. This would indicate that the call is terminated. Based on the indication that the call is terminated, the Iptables Manager 358 deletes the forwarding rules from the NAT 356 and deletes the row associated with the call from the call table 550.
In one example, on an inbound proxy call, the server 160 initiates the actual call leg 504 to the primary base station 220 which forwards the proxy call leg 402 to the secondary base station 230. If the wireless terminal 130 answers the call, a new row can be added to the call table 550 containing the pointer to the proxy CCall object. Similarly, when the actual call leg 404 to server 160 is answered, the pointer to the actual CCall is stored in the corresponding table row. Thus, the Iptables Manager 358 tracks the transport modes of both actual and proxy CCall/CMedia objects.
Initially, both transport modes are CLOSED. When SDP negotiation completes, and the media transport endpoints (e.g., IP address and UDP port values) are established, CMedia::SetMode is called with mode SENDRECV. The Iptables Manager 358 is notified, and if the modes for both call legs are SENDRECV, the forwarding rules are set. RTP forwarding begins between the primary base station 220 and secondary base station 230, and also between the primary base station 220 and the server 160. Because the proxy call uses RTP forwarding, the two outbound RTP audio streams from M500 are not required (and may be disabled). Disabling of outbound audio on a call leg is handled by deactivating the Audio Manager 346 of the primary base station 220 (depicted in
When the CMedia is created (in CCall::InitMedia), the rtpForwarding argument (passed to the CMedia constructor) determines whether Audio Manager 346 is enabled or disabled. For proxy call legs, or actual call legs that have an associated proxy call leg, this flag is enabled when the CMedia object is instantiated. When either side terminates the call, invokes CMedia::SetMode method with mode CLOSED. If the modes for both call legs are CLOSED, the Iptables Manager 358 deletes the forwarding rule thus ending RTP and/or RTCP forwarding between primary base station 220 and secondary base station 230 and primary base station 220 and server 160. When the destructor for the actual/proxy CCall objects are invoked, the Iptables Manager 358 deletes the corresponding row in the proxy call table.
The server confirms the request by sending a trying and ringing message to the primary base station which, in turn, sends a ringing message to the secondary base station. Once the session has been confirmed, the server sends a confirmation message to the primary base station via SDP (e.g., OK SDP). The primary base station in turn, sends an acknowledgement message (e.g., ACK) to the server. The primary base station then confirms the session the secondary base station via SDP to the secondary base station which in turns responds acknowledging that the session has been initiated.
Once the call has been established, the Iptables Manager may enable the forwarding rules in the NAT managed by the primary base station (e.g., by the kernel thereof) to forward the call. However, because the server uses direct media streams (such as, for example, OpenSIPS server) the RTP (or RTCP) streams, as depicted, will bypass the server and go directly to the primary base station which will send the media streams to the secondary base station. Similarly, when the primary base station receives the RTP (or RTCP) streams from the secondary base station, the primary base station will bypass the server and send the RTP (or RTCP) streams directly to the deskset.
Accordingly, when the server is an SIP (e.g., OpenSIP) server, the Iptables Manager can set forwarding rules so that the RTP (and/or RTCP) streams are forwarded to and from the far end server or device, e.g., a deskset, bypassing the server. Once the call has been terminated, the server can send a message to the primary base station via SIP (e.g., BYE) that the call has ended. The primary base station responds to acknowledge that the call has been terminated (e.g., BYE). Similarly, the primary base station sends a message via SIP to the secondary base station that the call has been terminated and the secondary base station can respond acknowledging that the call has been terminated. Once the call has been terminated, the Iptables Manager can delete the forwarding rules from the NAT managed by the primary base station.
The method 700 includes receiving, at the primary base station, a request to establish a call between the secondary base station and the server (702). The method 700 further includes adding a set of forwarding rules to a network address translation table of the primary base station. The set of forwarding rules instructs the primary base station to forward packets of the call received form the server to the secondary base station and to forward packets of the call received from the secondary base station to the server (704).
The method 800 includes adding a first rule to change a destination address of the packets to an address of the secondary base station for packets inbound to the primary base station form the server (802). The method 800 further includes adding a second rule to change a source address of the packets to an address of the primary base station for packets outbound from the primary base station to the secondary base station (804). The method 800 further includes adding a third rule to change a destination address of the packets to an address of the server for packets inbound from the secondary base station to the primary base station (806). The method 800 further includes adding a fourth rule to change a source address of the packets to an address of the primary base station for packets outbound from the primary base station to the server (808).
The method 900 further includes the Iptables Manager 358 deleting the set of forwarding rules from the NAT based on the received call hold indication (904). As discussed above, the decision may include using SIP signaling events to determine whether to delete the rules. In embodiments, when the Iptables Manager determines to delete the set of forwarding rules during a call hold based on one or more of the endpoints changing, the Iptables Manager may save the one or more changed endpoints to a call table that includes a destination address of the server and a destination address of the secondary base station.
In embodiments, if the Iptables Manager 358 receives a call hold indication, the Iptables Manager 358 may delete the set of forwarding rules. In embodiments, the call hold SIP message includes a send only (sendonly) session description protocol (SDP) direction.
The method 900 further includes receiving a call resume indication (906). If the Iptables Manager 358 receives a call resume indication, the Iptables Manager 358 may add the set of forwarding rules to the NAT 356 based on the receiving a call resume indication. The method 900 further includes the Iptables Manager adding a new set of forwarding rules to the network address translation table based on the receiving of the call resume indication (908). As discussed above, the new forwarding can be tailored to account for the changes in SDP attributes of an existing session.
For example, if a far-end account (e.g., an account associated with server 160) is using early-media, the initial SDP sent to the primary base station 110 contains IP:port address of a SIP/media server (so audio is substituted for ringback). However, when the server 160 answers, the reINVITE/SDP sent to the primary base station 220 contains the IP address and port values of the server 160 (to switch back to regular voice audio). In this case, the transport endpoints on the actual call leg have changed, so the RTP forwarding rules must be updated. On the reINVITE, the Iptables Manager checks if the endpoints have changed. If so, it deletes old rules, sets new rules, and saves the new endpoint values. On call hold/resume, the holding party sends SIP reINVITE messages with SDP direction “sendonly”, followed by “sendrecv” (when the call is resumed). Since the media endpoints are unchanged by the resume, the RTP forwarding rules (as set on call establishment) are still valid. However, the Iptables Manager deletes and adds the RTP forwarding rules during a local hold/resume to prevent mismatching errors. For a remote hold (i.e., hold on server 160), the RTP forwarding rules established on call setup remain in place (as required for MoH, e.g., FreePBX server).
The kernel of the primary base station 220 may include a connection tracker that tracks the flow of packets from the secondary base station 230 or server 160. When the connection tracker detects a new RTP/RTCP packet flow from the secondary base station 230 or sever 160, the connection tracker will create a new flow connection after consulting the NAT. For the connection tracker to function properly, the forwarding rules must be created early as possible (otherwise the connection tracker will already be set and the forwarding rules will have no effect). Thus, in embodiments, the forwarding rules are configured after one or more media port selections have been completed but before any media packets of the call have been received. Once a call has been terminated, the connection flow the connection tracker will delete the flow connection. Accordingly, in embodiments, after adding the set of forwarding rules, the Iptables Manager will delete each packet flow between the primary base station and the server and the primary base station and the secondary base station tracked by the kernel connection tracker.
In embodiments, the primary base station 220, secondary base station 230, and server 160 may be on an IPV6 network. IPv6 networks include redirect messages that are part of the Neighbor Discover Protocol and are sent to inform hosts of better hop routing decisions. In the case of RTP forwarding, the primary base station 220 will send out ICMPv6 Redirect messages to the secondary base station 1230 and server 160 every 2-4 seconds to inform them to send directly to each other (e.g., secondary base station 230 sends directly to the end server 160). The Iptables Manager 358 can be configured to disable these redirect messages, as they are unnecessary.
Thus, in embodiments, an outbound redirect message from the primary base station 220 to the server 160 and an outbound redirect message from the primary base station 220 to the secondary base station 230 are internet control message protocol version 6 (ICMPv6) messages. The Iptables Manager may disable the outbound redirect message from the primary base station 220 to the server 160 and disable an outbound redirect message from the primary base station 220 to the secondary base station 160. The Iptables Manager may disable the outbound redirect messages on call establishment and enable the outbound redirect messages after call termination.
In embodiments, the Iptables Manager 358 may, prior to the adding of the set forwarding rules to the network address translation table, create a shell process that includes a destination address of the secondary base station, a destination address of the server, and a source address of the primary base station. The shell process may be further configured to run a command to add the set of forwarding rules to the network address translation table managed by the primary base station (e.g., by the kernel or a user-space application). For example, the command can be an iptables command. The command may be spawned by the shell process using either a system( ) call or an execl( ) call.
Thus, adding or deleting of the forwarding rules in the NAT tables can be handled via the shell processes created to run the commands (such as iptables command, ip6tables command, ip4tables command, etc.) The shell script may require the following arguments: “-a” or “-d” (to add or delete rules), and four addresses (e.g., IP address and port values) that specify the media endpoints of the proxy call leg 202, and actual call leg 204 call legs).
The claimed software elements can be realized on a variety of telecommunications systems or subsystems. The following description, in conjunction with the disclosed embodiments described in the foregoing, provides representative, non-limiting examples of potential communications systems or subsystems that could be used to execute the claimed software elements.
At a high level, a communications system or subsystem typically includes, but is not limited to, communication devices, networks, base stations, servers, and a variety of other hardware and software components. Communication devices may include a broad range of devices such as cordless telephones, mobile phones, smartphones, computers, tablets, and other types of devices capable of sending and receiving communication signals. These devices usually include at least one processor, memory, a user interface (such as a display, keyboard, or touch screen), and a network interface for connecting to a network.
The network component of a communications system or subsystem can take various forms, including multi-cell systems, e.g., Digital Enhanced Cordless Telecommunications (DECT), public switched telephone networks (PSTN), the Internet, mobile networks (e.g., 3G, 4G, 5G), local area networks (LAN), wide area networks (WAN), and others. Base stations and/or servers are also commonly part of communications systems, facilitating the storage, processing, and exchange of data. Like the aforementioned communication devices, these elements generally include a processor and memory for executing software applications, as well as network interfaces for communicating with the network and other devices.
Software elements in a communications system may include operating systems, device drivers, networking software, applications, and other types of software. These software elements can be executed on communication devices, base stations, servers, or other hardware components of the telecommunications systems or subsystems. The claimed software elements may be embodied as computer program code that is executed on one or more of the hardware components of the telecommunications system or subsystem. This code could be stored on a non-transitory computer-readable medium that is part of the communication device, base station, server, or other component, or it could be stored on an external storage device, network storage, or cloud storage.
It should be noted that the described communications systems and subsystems are illustrative and that the claimed software elements can be executed on any suitable communications system or subsystem. The specific configuration of the communications system or subsystem may vary depending on the requirements of the application, performance characteristics of the system, cost considerations, and other factors. The scope of the invention is not limited to the specific communications systems and subsystems described herein but includes any and all systems or subsystems suitable for implementing the present invention.
The foregoing detailed description has presented various implementations of the devices and/or processes through the use of block diagrams, schematics, and illustrative examples. As such block diagrams, schematics, and examples include one or more functions and/or operations, it should be understood by those skilled in the art that each function and/or operation within these block diagrams, flowcharts, or examples can be implemented individually and/or collectively by employing a wide range of hardware, software, firmware, or any combination thereof. It should also be recognized by those skilled in the art that the methods or algorithms described herein may incorporate additional steps, may exclude some steps, and/or may execute steps in an order different from the one specified. The various implementations described above can be combined to create additional implementations.
These modifications and other changes can be made to the implementations in light of the above-detailed description. Generally, the terms used in the following claims should not be construed to limit the claims to the specific implementations disclosed in the specification and the claims. Instead, they should be interpreted to encompass all possible implementations, along with the full scope of equivalents to which such claims are entitled. Consequently, the claims are not limited by the disclosure but are intended to cover all possible implementations within their scope.
