DESC:FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003

COMPLETE SPECIFICATION
(See section 10, rule 13)

SYSTEMS AND METHODS FOR PROVIDING SEAMLESS COMMUNICATIONS AND VOICE QUALITY ENHANCEMENT OF VoIP

BHARAT ELECTRONICS LIMITED
WITH ADDRESS:
OUTER RING ROAD, NAGAVARA, BANGALORE 560045, KARNATAKA, INDIA

HE FOLLOWING SPECIFICATION PARTICULARLY DESCRIBES THE INVENTION AND THE MANNER IN WHICH IT IS TO BE PERFORMED.

TECHNICAL FIELD
[0001] The present disclosure relates generally to communications, and more particularly, to methods for providing seamless communications of voice over internet protocol.
BACKGROUND
[0002] Internet Protocol (IP) is the principal communications protocol in the Internet protocol suite for relaying datagrams across network boundaries. Its routing function enables internetworking, and essentially establishes the Internet. Internet Protocol hides the underlying physical network by creating a virtual network view. It is an unreliable, best-effort, and connectionless packet delivery protocol. The packets sent by IP might be lost, arrive out of order, or even be duplicated. IP assumes higher layer protocols will address these anomalies.
[0003] Voice over Internet Protocol (VoIP) is a methodology and group of technologies for the delivery of voice communications and multimedia sessions over Internet Protocol (IP) networks, such as the Internet. VoIP works by encoding voice information into a digital format, which can be carried across IP networks in discrete packets.
[0004] A voice gateway is a gateway device that uses Internet Protocols to transmit and receive voice communications (VoIP). The voice gateway is used to connect different physical networks in order to provide end-to-end connectivity. In addition, the voice gateway can also connect a VoIP circuit to a public switched telephone network (PSTN) circuit, allowing the use of VoIP despite gaps in networks, or even when only one of the endpoints if VoIP enabled. In order to implement VoIP communications, the functionality to notify an endpoint that another endpoint desires communication is necessary (such as by causing the recipient’s phone to ring). This is called signalling. Developed in the year 1996, the Session Initiation Protocol (SIP) was originally designed as a means of notifying or inviting users to Internet multicast and broadcast sessions. This design, an early form of Internet signalling, made SIP very useful for signalling in VoIP, and thus most VoIP developers have adopted SIP as the core IP telephony standard. Implemented at the application layer, it is capable of establishing, modifying, and terminating sessions. The most current Request For Comments (RFC) definition for SIP, published in 2002, is RFC 3261. However, it has been updated several times since 2002.
[0005] The Real-Time Transport Protocol (RTP) provides the transport of real-time data packets. RTP implements the transport features needed to provide synchronization of multimedia data streams. In VoIP, RTP is used for transport of voice data. The RFC definition for RTP, published in 2003, is RFC 3550.
[0006] A prior art discloses that it enhances the Quality of Service (QoS) of the third-generation (3G) cellular networks. The quality of voice traffic over IP networks (VoIP) is greatly reduced due to the fact that packets in IP networks suffer from packet loss which is inevitable due to the best-effort nature of these networks. Many techniques have been proposed to decrease the effect of packet loss on the speech quality. In this paper we study the effect of packet loss on speech quality; we propose sending a duplicate copy of the speech stream over the network and we study the effect on the speech quality due to this duplication. This is especially useful in networks with extra available bandwidth. The performance of the system is measured according to the EModel as defined in the ITU-T's Recommendation G.107. The speech sources used during the experiments are artificial voices obtained from the ITU-T Recommendation P.50/Appendix I. The results of the proposed scheme suggest improvement in the system performance in terms of speech quality which can then be translated into greater percentage of users satisfied with the service and greater potential revenue. The proposed technique proves to be more effective when situations of higher percentages of packet loss and burst losses rise.
[0007] Another prior art discloses that in a 3G network scenario the quality of voice traffic over IP is greatly reduced due to the strong current limitations in terms of requirements regarding delay and guaranteed bandwidth. Moreover, perceived quality of VoIP communications depends on the individual telephone operator where the radio link is not always reliable for the entire duration of a conversation. In particular, the study concerns the effect of packet loss and the degree of improvement in the perceived quality which can be obtained by sending a duplicate copy of a voice packet through two different operators. In terms of perceived speech quality this approach leads to a significant improvement which stands between 0.5 and 1.5 MOS.
[0008] A traditional VoIP system relies on a single IP network for working. A network can be wired or wireless. The VoIP system uses (Session Initiation Protocol) SIP messages for signalling and Real-time Transport Protocol (RTP) packets for voice data. The process involved in the traditional VoIP system comprises the VoIP packets (SIP/RTP Packets) from the Packet Switching Engine to be forwarded blindly to the call manager or the RTP server, and the VoIP packets from the call manager or the RTP server is forwarded blindly to the packet switching engine in the voice gateways. The quality of a voice call entirely depends on the quality of the network being used. If the IP network comprises multiple packet drops for instance, then an end user experiences voice breaks frequently. Frequent voice breaks occur due to dropping of RTP packets by the network. If the dropped packets are of SIP packets, then the end user faces issues in signalling, for example, a call may not get connected, a call may get disconnected, the system may hang etc.
[0009] Therefore, there is a need for a system and a method for alleviate the above mentioned issues with the traditional VoIP, wherein the probability of losing a packet is reduced in case of adverse network conditions as well.

SUMMARY
[0010] An aspect of the present invention is to address at least the above-mentioned problems and/or disadvantages and to provide at least the advantages described below.
[0011] This method for providing seamless service and voice quality enhancement for voice over internet protocol uses all available networks that are wired or wireless for VoIP, between source node and destination node. A packet duplication procedure at the source node and a packet rejection procedure at the destination node is employed for improving the VoIP service quality and voice quality in spite of presence of a single network connection between nodes. The packet duplication procedure involves creating multiple copies of the same SIP packet, that is, control packets, for VoIP and sends each packet to destination either over the same network or over different networks, if available. In case of adverse network conditions, the probability of losing a packet is reduced since multiple copies of same packets, that is, duplicate packets, are sent, thereby improving the service quality of VoIP in adverse situations. Similarly, the packet duplication procedure allows creation of multiple copies of the same RTP packet, that is, voice data packets for VoIP and sends each packet to destination either over the same network or over different networks, if available. In case of adverse network conditions the probability of losing a packet is reduced since multiple copies of same packets are sent thereby improving the voice quality of VoIP in adverse situations. The packet duplication procedure prevents the VoIP service interruption due to network failures. The service continues through other networks available and provides a glitch-less service. The service continues till the last network breaks down. The bandwidth requirement depends on the number of duplicate packets sent over the network. In an embodiment, the bandwidth requirement is higher than the conventional VoIP communication.
[0012] A packet rejection procedure is employed after the packet duplication procedure for eliminating duplicate SIP and RTP packets at the destination node and providing a single packet, that is unique, to a call manager or a server. The packet duplication procedure and packet rejection procedure are implemented by making changes in the network layer of the voice gateway. The upper layers remain unchanged and the VoIP endpoints such as IP phones remain unchanged.
[0013] Other aspects, advantages, and salient features of the invention will become apparent to those skilled in the art from the following detailed description, which, taken in conjunction with the annexed drawings, discloses exemplary embodiments of the invention
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] The detailed description is described with reference to the accompanying figures.
[0015] FIG. 1 exemplarily illustrates a typical VoIP system with proposed modification.
[0016] FIG. 2 exemplarily illustrates Error! Reference source not found.shows the block diagram of a typical voice gateway with a packet duplication & rejection module (PDRM) as an additional block.
[0017] FIG. 3 exemplarily illustrates a method for providing seamless service and voice quality enhancement for voice over internet protocol.
[0018] FIG. 4 exemplarily illustrates the packet duplication procedure.
[0019] FIG. 5 exemplarily illustrates a packet rejection procedure.
[0020] It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative methods embodying the principles of the present disclosure. Similarly, it will be appreciated that any flow charts, flow diagrams, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.
DETAILED DESCRIPTION
[0021] The present disclosure describes about a method and system for providing seamless service and voice quality enhancement of Voice over Internet Protocol (VoIP).
[0022] In the following description, for purpose of explanation, specific details are set forth in order to provide an understanding of the present disclosure. It will be apparent, however, to one skilled in the art that the present disclosure may be practiced without these details. One skilled in the art will recognize that embodiments of the present disclosure, some of which are described below, may be incorporated into a number of systems.
[0023] However, the systems and methods are not limited to the specific embodiments described herein. Further, structures and devices shown in the figures are illustrative of exemplary embodiments of the presently disclosure and are meant to avoid obscuring of the presently disclosure.
[0024] It should be noted that the description merely illustrates the principles of the present invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described herein, embody the principles of the present invention. Furthermore, all examples recited herein are principally intended expressly to be only for explanatory purposes to help the reader in understanding the principles of the invention and the concepts contributed by the inventor to furthering the art and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass equivalents thereof.
[0025] FIG. 1 exemplarily illustrates a voice over internet protocol (VoIP) system 100. The VoIP system comprises end user devices 101 at source, that is node A, such as internet protocol (IP) phone, soft IP phone, analog phone, etc., voice gateway A 102, one or more routers 103 coupled to the voice gateway A 102, one or more networks 104, one or more routers 105, voice gateway B 106 coupled to the one or more routers 105, and end user devices 107 at destination, that is node B.. A network can be wired or wireless. The VoIP system uses session initiation protocol (SIP) messages for signalling and real-time transport protocol (RTP) packets for voice data. There are two nodes, node A & node B that are interconnected with ‘n’ number of IP networks. The entry point of each node to the network will be a router. The end devices, such as phone, for example internet protocol (IP) phone, soft IP phone, analog phone, etc., are connected to voice gateway A that corresponds to node A and voice gateway B that corresponds to node B. The node A is considered as, for example, a source node and the node B is considered as, for example, destination node. The voice gateway A generates multiple copies, that is, duplicates, of same VoIP packets, that is the SIP packets and the RTP packets and sends each packet to the destination node, that is node B, either over the same network or over different networks based on the availability. In case of adverse network conditions the probability of losing the VoIP packet is reduced since multiple copies of same VoIP packets are sent to the destination. Therefore, the service quality and voice quality of VoIP improves in adverse situations.
[0026] FIG. 2 exemplarily illustrates Error! Reference source not found.shows a block diagram of the voice gateway 102, 106. For example, the voice gateway A 102 comprises one or more interfaces 201, a packet buffer 202, packet switching engine 203, a packet duplication & rejection module (PDRM) 204, a call manager 205, and a real-time transport protocol (RTP) server 206. The end user devices 101 terminate on the voice gateway 102 at each node. The voice gateway 102 is responsible for handling local voice calls, that is calls between subscribers in the same node, trunk voice calls, that is, calls originating from subscribers in one node to subscribers in a different node over the network, and converting analog voice to IP packets, etc. The IP interface, that is the Ethernet interface, handles the routers and IP phones connections. The packets from the Ethernet interface is forwarded to a packet switching engine 203. A Plain Old Telephone Service (POTS) interface handles POTS phone connections and converts analog voice data from POTS phones to voice over internet protocol (VoIP) packets. The VoIP packets are forwarded to the packet switching engine 203. Other voice interfaces in the gateway, if present, convert the voice data to the VoIP packets and forward the VoIP packets to the packet switching engine 203. All the packets received by the the packet switching engine 203 are stored in the packet buffer 202 prior processing.
[0027] The real-time transport protocol (RTP) server 206 accepts RTP packets, modifies the RTP packets and reroutes the RTP packets, under the supervision of the call manager 205. The call manager 205 is responsible for accepting session initiation protocol (SIP) packets, generating SIP packets, managing sessions, and managing the RTP Server 206. The voice gateway A 102 and voice gateway B 106 comprises a PDRM. The PDRM 204 at the voice gateway A 102 performs packet duplication procedure if the node A is the source node. The PDRM at the voice gateway 106 performs a packet rejection procedure if the node B is the destination node. The procedures performed by the PDRM may vary based on the node being a source or a destination. The PDRM 204 comprises one or more processors for executing the packet duplication procedure and packet rejection procedure.
[0028] FIG. 3 illustrates a method for providing seamless service and voice quality enhancement for voice over internet protocol. The method employs the packet duplication & rejection module (PDRM) 204 for providing seamless service and voice quality enhancement for voice over internet protocol. The PDRM 204 comprises the RTP duplication section, the RTP rejection section, the SIP duplication section, and the SIP rejection section. The packets to be transferred between the source node and the destination node is session initiation protocol packets and real-time transport protocol packets The PDRM 204 duplicates 301 one or more packets by the source node for transmission between the source node and the destination node using one or more networks, The PDRM 204 determines 301a availability of one or more network connections for transmitting the packet between the source node and the destination node. If the source node and the destination node are connected through multiple networks, then the PDRM 204 creates 301b copies of the packet equivalent to the number of network connections upon determining availability of multiple network connections. If the source node and the destination node are connected through a single network, then the PDRM 204 creates copies of the packets based on the number of maximum duplicate packets allowed in the single network.
[0029] The PDRM 204 stores the packet and one or more copies of the packet in the buffer 202 for transmitting the packets to the destination node. The PDRM 204 configures 301c the packet and the one or more copies of the packet based on network parameters of the network connection through which the packet and each of the one or more copies of the packet is to be transmitted upon determining availability of multiple networks between the source node and the destination node. The PDRM 204 writes the configured packet and one or more copies of the configured packet to the buffer 202 for transmitting the packets to the destination node upon determining the presence of multiple network connections between the source node and the destination node. The PDRM 204 transmits 301d the configured packet and the copies of the configured packet through the packet switching engine 203 by the source node to the available one or more network connections. The configured packet comprises a checksum for determining the maintenance of integrity of the packets during transmission of the packets. The PDRM 204 calculates the checksum for each copy of the packet based on the network parameters of the network connection through which the packet is to be transmitted. The source node forwards each copy of the packet to the packet switching engine 203 during the transmission of the one or more packets. If the packets are identified as local packets that are between subscribers in the same node based on the destination internet protocol address, then the identified packets are forwarded to the packet switching engine 203 without any modification.
[0030] The RTP duplication section of the PDRM 204 identifies trunk RTP packets, that is, RTP packets between nodes, from the RTP server based on destination IP address of the packet. The RTP duplication section of the PDRM 204 creates ‘n’ number of copies of the trunk RTP packet, where ‘n’ is the total number of available networks between nodes if multiple networks are available, else ‘n’ is the maximum number of copies of a packet to be forwarded through a single available network between the source node and the destination node. Further, the RTP duplication section of the PDRM 204 calculates checksum for each copy of the trunk RTP packet with parameters of the network through which the packets shall be forwarded and the RTP duplication section modifies each copy of the trunk RTP packet, with parameters of the network through which the packets shall be forwarded, and the updated checksum. The RTP duplication section forwards each copy of the trunk RTP packet to the packet switching engine and identifies local RTP packets, that is RTP packets between subscribers in same node, based on the destination IP address of the packet and forwards local RTP packets to the packet switching engine without any modification.
[0031] The SIP duplication section of the PDRM 204 identifies trunk SIP packets, that is, SIP packets between the nodes, from the call manager based on destination IP address of the packet. The SIP duplication section of the PDRM 204 creates ‘n’ number of copies of the trunk SIP packet, where ‘n’ is the total number of available networks between nodes if multiple networks are available, else ‘n’ is the maximum number of copies of a packet to be forwarded through a single available network. The SIP duplication section of the PDRM 204 calculates the checksum for each copy of the trunk SIP packet with parameters of the network through which the packets shall be forwarded. The SIP duplication section modifies each copy of the trunk SIP packet, with parameters of the network through which the packets shall be forwarded, and the updated checksum. The SIP duplication section forwards each copy of the trunk SIP packet to the packet switching engine, identifies local SIP packets, that is, SIP packets between subscribers in same node, based on destination IP address of the packet and forwards the local SIP packets to the packet switching engine without any modification.
[0032] The voice gateway B 106 comprising the PDRM 204 at the destination node receives 302a the packets and discards 302 the received duplicate packets. The PDRM 204 at the destination node extracts 302b identifier from the packet. The one or more packets from the packet switching engine are identified by the PDRM 204 of the destination node as one or more local packets based on an internet protocol address of the source node. The local packets are forwarded to a server without discarding the packets. The PDRM 204 stores the identifier in the first in first out buffer upon determining the absence of the identifier in the first in first out buffer and accepts the packet corresponding to the identifier stored in the first in first out buffer of the destination node. The identifier extracted from the packet is pushed into the first in first out buffer from a first end and flushed through a second end.
[0033] The PDRM 204 determines 302c the presence of the extracted identifier in the first in first out buffer by comparing the extracted identifier with one or more contents of the first in first out (FIFO) buffer. The PDRM 204 discards 302d the packet upon determining presence of the corresponding identifier in the FIFO buffer. The server is a real-time transport protocol server during the transmission and reception of the real-time transport protocol packets and the server is a session initiation protocol server during the transmission and reception of the session initiation protocol packets.
[0034] The RTP rejection section of the PDRM 204 identifies trunk RTP packets, that is, the RTP packets between nodes, from the packet switching engine based on the source IP address of the packet. The RTP rejection section of the PDRM 204 extracts the ‘ipidentifier’ field of each trunk RTP packets, that are the RTP packets between nodes, and maintains an ipidentifier first in first out (FIFO) for storing the ‘ipidentifier’ values of the past ‘i’ number of accepted trunk RTP packets, as disclosed in the detailed description of Figure 5.
[0035] Further, the RTP rejection section compares the ‘ipidentifier’ value of the current trunk RTP packet against the entries of the ipidentifier FIFO and rejects the trunk RTP packet if the value is matching with any of the entries of ipidentifier FIFO. The RTP rejection section accepts the trunk RTP packet if the value does not match with any of the entries of ipidentifier FIFO and pushes the new ‘ipidentifier’ value into the ipidentifier FIFO through entry ‘0’, and flushes the entry ‘i’ out. The RTP rejection section identifies the local RTP packets, that is, the RTP packets between subscribers in same node, based on source IP address of the packet and forwards the local RTP packets to the RTP server without rejection, as disclosed in the detailed description of Figure 5.
[0036] The SIP rejection section of the PDRM 204 identifies trunk SIP packets, that is, SIP packets between nodes, from packet switching engine based on source IP address of the packet. The SIP rejection section of the PDRM 204 extracts the ‘ipidentifier’ field of each trunk SIP packets, that is, SIP packets between nodes, maintains an ipidentifier FIFO that stores the ‘ipidentifier’ values of the past ‘i’ number of accepted trunk SIP packets. The SIP rejection section of the PDRM 204 compares the ‘ipidentifier’ value of the current trunk SIP packet against all the entries of the ipidentifier FIFO and rejects the trunk SIP packet if the value is matching with any of the entries of ipidentifier FIFO. The SIP rejection section accepts the trunk SIP packet if the value does not match with any of the entries of ipidentifier FIFO, pushes the new ‘ipidentifier’ value into the ipidentifier FIFO through entry ‘0’, and flush the entry ‘i’ out. The SIP rejection section of the PDRM 204 identifies local SIP packets, that is, SIP packets between subscribers in same node, based on source IP address of the packet and forwards local SIP packets to the SIP server without rejection, as disclosed in the detailed description of Figure 5.
[0037] FIG. 4 exemplarily illustrates the packet duplication procedure. The VoIP packets originated from one node and destined to a different node over the network, that is, the trunk VoIP packets, traverse through the packet duplication & rejection module (PDRM). The local VoIP packets, that is, the VoIP packets between subscribers in same node shall not be modified by the PDRM and are directly forwarded. The PDRM comprises separate sections for the session initiation protocol (SIP) and the real-time transfer protocol (RTP) packets. The PDRM comprises SIP Duplication, SIP Rejection, RTP Duplication and RTP rejection sections. The duplication and rejection of packets is based on ‘ipidentifier’ section of IP header.
[0038] For example, the trunk VoIP packets from the call manager or the RTP Server of Node A will be destined to Network ‘1’. The PDRM forwards the packet to the packet switching engine without any modification. If there are multiple networks available between the nodes, the packet is duplicated, modified with Network ‘2’ parameters and IP checksum of the packet is calculated and updated. The PDRM then forwards the new packet to the packet switching engine. This process repeats for Network ‘3’, Network ‘4’, etc., up to Network ‘n’, where ‘n’ is the total number of networks between Node A and Node B. The SIP/RTP packets go through all the available networks between node A and node B. For example, consider a single network available between the nodes A and B, then duplicate packets will be forwarded through the same network and the packets will reach in Node B, where the packets are screened at the PDRM of Node B.
[0039] FIG. 5 exemplarily illustrates the packet rejection procedure. The PDRM forwards a single copy of the VoIP packet to the call manager or the RTP server and rejects duplicate packets. The first packet to reach at the node is accepted. The ‘ipidentifier’ field of the packet is assigned to ‘ipiden’ variable. An ipidentifier FIFO, that is ‘ipiden FIFO’ stores the ipidentifier values of the past ‘i’ number of accepted VoIP packets. The ‘ipiden’ value of the current packet is compared against all the entries of the ipiden FIFO. If the ipiden value exists in the FIFO, then it is inferred that one copy of the packet has already been accepted. Therefore the new packet is rejected. On contrary, if the ipiden value is not present in the FIFO, then it is inferred that the packet is new and the packet is accepted. The new ipiden value is pushed into the FIFO through entry ‘0’ and the entry ‘i’ is flushed out of the FIFO queue. Therefore the PDRM tracks of the accepted packets and prevents redundant copies of packets from entering the call manager or the RTP server. Therefore the packet rejection procedure decreases the probability of packet drops and improves the voice quality and service quality of VoIP systems. The VoIP systems comprising voice gateways are modified based on the flexibility for incorporating the PDRM. In an embodiment, the present invention may be implemented using VHDL, Verilog and C/C++.
[0040] The methods or procedures discussed above use all the available networks that are wired or wireless for VoIP. This packet duplication procedure and packet rejection procedure improves the VoIP service quality and voice quality in spite of presence of a single network connection between nodes. The bandwidth requirement depends on the number of duplicate packets sent over the network. In an embodiment, the bandwidth requirement is higher than the conventional VoIP communication. The packet duplication procedure involves creating multiple copies of the same SIP packet, that is, control packets, for VoIP and sends each packet to destination either over the same network or over different networks, if available. In case of adverse network conditions, the probability of losing a packet is reduced since multiple copies of same packets, that is, duplicate packets, are sent, thereby improving the service quality of VoIP in adverse situations. Similarly, the packet duplication procedure allows creation of multiple copies of the same RTP packet, that is, voice data packets for VoIP and sends each packet to destination either over the same network or over different networks, if available. In case of adverse network conditions the probability of losing a packet is reduced since multiple copies of same packets are sent, thereby improving the voice quality of VoIP in adverse situations. The packet duplication procedure prevents the VoIP service interruption due to network failures. The service continues through other networks available and provides a glitch-less service. The service continues till the last network breaks down. This packet duplication procedure is implemented by making changes in the network layer of the voice gateway. The upper layers remain unchanged and the VoIP endpoints such as IP phones remain unchanged.
[0041] The packet duplication procedure and packet rejection procedure and the voice gateways comprising the PDRM disclosed herein can be configured to work in a network environment comprising one or more computers that are in communication with one or more devices via a network. In an embodiment, the computers communicate with the devices directly or indirectly, via a wired medium or a wireless medium such as the Internet, a local area network LAN, a wide area network WAN or the Ethernet, a token ring, or via any appropriate communications mediums or combination of communications mediums. Each of the devices comprises processors, examples of which are disclosed above, that are adapted to communicate with the computers. In an embodiment, each of the computers is equipped with a network communication device, for example, a network interface card, a modem, or other network connection device suitable for connecting to a network. Each of the computers and the devices executes an operating system, examples of which are disclosed above. While the operating system may differ depending on the type of computer, the operating system provides the appropriate communications protocols to establish communication links with the network. Any number and type of machines may be in communication with the computers.
[0042] In an embodiment, the computer programs that implement the methods and algorithms disclosed herein are stored and transmitted using a variety of media, for example, the computer readable media in a number of manners. In an embodiment, hard-wired circuitry or custom hardware is used in place of, or in combination with, software instructions for implementing the processes of various embodiments. Therefore, the embodiments are not limited to any specific combination of hardware and software. The computer program codes comprising computer executable instructions can be implemented in any programming language. Examples of programming languages that can be used comprise C, C++, C#, Java®, JavaScript®, Fortran, Ruby, Perl®, Python®, Visual Basic®, hypertext preprocessor PHP, Microsoft® .NET, Objective-C®, etc. Other object-oriented, functional, scripting, and/or logical programming languages can also be used. In an embodiment, the computer program codes or software programs are stored on or in one or more mediums as object code. In another embodiment, various aspects of the method and the voice gateway comprising the PDRM disclosed herein are implemented in a non-programmed environment comprising documents created, for example, in a hypertext markup language HTML, an extensible markup language XML, or other format that render aspects of a graphical user interface GUI or perform other functions, when viewed in a visual area or a window of a browser program. In another embodiment, various aspects of the method and the voice gateway comprising the PDRM disclosed herein are implemented as programmed elements, or non-programmed elements, or any suitable combination thereof. In an embodiment, the present invention may be implemented using VHDL, Verilog and C/C++.
[0043] The foregoing examples have been provided merely for the purpose of explanation and are in no way to be construed as limiting of the method and voice gateway comprising the PDRM disclosed herein. While the method and the voice gateway comprising the PDRM have been described with reference to various embodiments, it is understood that the words, which have been used herein, are words of description and illustration, rather than words of limitation. Furthermore, although the method and the voice gateway comprising the PDRM have been described herein with reference to particular means, materials, and embodiments, the method and the voice gateway comprising the PDRM have are not intended to be limited to the particulars disclosed herein; rather, the method and voice gateway comprising the PDRM extend to all functionally equivalent structures, methods and uses, such as are within the scope of the appended claims. While multiple embodiments are disclosed, it will be understood by those skilled in the art, having the benefit of the teachings of this specification, that the method and the voice gateway comprising the PDRM disclosed herein are capable of modifications and other embodiments may be effected and changes may be made thereto, without departing from the scope and spirit of the method and the system disclosed herein.
[0044] Those skilled in this technology can make various alterations and modifications without departing from the scope and spirit of the invention. Therefore, the scope of the invention shall be defined and protected by the following claims and their equivalents.
[0045] FIGS. 1-5 are merely representational and are not drawn to scale. Certain portions thereof may be exaggerated, while others may be minimized. FIGS. 1-5 illustrate various embodiments of the invention that can be understood and appropriately carried out by those of ordinary skill in the art.
[0046] In the foregoing detailed description of embodiments of the invention, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments of the invention require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the detailed description of embodiments of the invention, with each claim standing on its own as a separate embodiment.
[0047] It is understood that the above description is intended to be illustrative, and not restrictive. It is intended to cover all alternatives, modifications and equivalents as may be included within the spirit and scope of the invention as defined in the appended claims. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of the invention should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein,” respectively.
,CLAIMS:We claim:

1. A method for providing seamless service and voice quality enhancement for voice over internet protocol, the method comprising:

duplicating one or more packets by a source node for transmission between the source node and a destination node using one or more networks, wherein the step of duplicating the one or more packets for transmission comprising:

determining availability of one or more network connections for transmitting the packet between the source node and the destination node;

creating copies of the packet equivalent to one of the number of network connections upon determining availability of multiple network connections and number of maximum duplicate packets allowed in a single network upon determining presence of a single network connection;

configuring the packet and the copies of the packet based on network parameter of the network connection through which the packet and each of copies of the packet is to be transmitted upon determining availability of multiple networks between the source node and the destination node;;

transmitting the configured packet and one or more copies of the configured packet through a packet switching engine by the source node to the available one or more network connections;

discarding the received duplicate packets by the destination node, wherein the method of discarding the duplicate packets comprising:

receiving the transmitted one or more packets by the destination node;

extracting an identifier from the packet by the destination node;

determining presence of the extracted identifier in a first in first out buffer by comparing the extracted identifier with one or more contents of the first in first out buffer; and

discarding the packet upon determining presence of the corresponding identifier in the first in first out buffer.

2. The method as claimed in claim 1, wherein the step of duplicating the one or more packets further comprising storing the packet and one or more copies of the packet in a buffer for transmitting the packets to the destination node upon determining the availability of a single network connection between the source node and the destination node.

3. The method as claimed in claim 1, wherein the step of duplicating the one or more packets further comprising writing the configured packet and one or more copies of the configured packet to a buffer for transmitting the packets to the destination node upon determining the presence of multiple network connections between the source node and the destination node.

4. The method as claimed in claim 1, wherein the step of discarding the received duplicate packets further comprising
storing the identifier in the first in first out buffer upon determining the absence of the identifier in the first in first out buffer and
accepting the packet corresponding to the identifier stored in the first in first out buffer of the destination node.

5. The method as claimed in claim 1, wherein the packets to be transferred between the source node and the destination node is session initiation protocol packets and real-time transport protocol packets.

6. The method as claimed in claim 1, further comprising identifying one or more packets from a call manager by the source node based on an internet protocol address of the destination node of the packet.

7. The method as claimed in claim 6, wherein the call manager accepts and generates session initiation protocol packets, manages sessions and manages a real time transport protocol server.

8. The method as claimed in claim 1, further comprising calculating the checksum for each copy of the packet based on the parameters of the network connection through which the packet is to be transmitted.

9. The method as claimed in claim 1, further comprising forwarding each copy of the packet to a packet switching engine by the source node during the transmission of the one or more packets.

10. The method as claimed in claim 1, further comprising identifying one or more local packets that are between subscribers in the same node based on the destination internet protocol address.

11. The method as claimed in claim 10, wherein forwarding the identified packets to the packet switching engine without modifying by configuring the packet.

12. The method as claimed in claim 1, further comprising identifying the one or more packets from a packet switching engine by the destination node, based on an internet protocol address of the source node.

13. The method as claimed in claim 1, wherein the identifier extracted from the packet is pushed into the first in first out buffer from a first end and flushed through a second end.

14. The method as claimed in claim 1 further comprising identifying one or more local packets that are between subscribers in the same node based on the source internet protocol address.

15. The method as claimed in claim 14, wherein forwarding the identified packets to a server without discarding the packet.

16. The method as claimed in claim 15, wherein the server is a real-time transport protocol server during the transmission and reception of the real-time transport protocol packets and the server is a session initiation protocol server during the transmission and reception of the session initiation protocol packets.

Dated this 03rd day of April, 2019

FOR BHARAT ELECTRONICS LIMITED
(By their Agent)

D. MANOJ KUMAR (IN/PA-2110)
KRISHNA & SAURASTRI ASSOCIATES LLP