TECHNICAL SCIENCES
CARMA APPROACH TO VOIP/SIP ARCHITECTURE
Adegoke A.S
Taras Shevchenko National University of Kyiv, Ukraine
ABSTRACT
Gradually, the server-client mechanism of network architecture is being faced out due to its familiar problems of scalability, bad resource management among the likes. However, core technologies have already been built on this and are inadvertently suffering from these inefficiencies.
VoIP telephony technology is one of the overlays built using this architecture and also suffers data packet loss/lag hence a need for an improved mechanism of node identification within it's network.
This article explains the concept of VoIP/SIP technology, CARMA model and it's implementation as a means of tackling the problems of the traditional server-client model during the process of network awareness.
Keywords: VOIP, SIP, CARMA, P2P, Networking, Server-client.
SIP: Session Initiation Protocol, VOIP: Voice Over IP, CARMA: Combined Affinity Reconnaissance Metric Architecture, P2P: Peer-to-peer.
In building an efficient distributed network, topo-logical distance estimation is key to managing network resources. Traditionally, node communication via message exchange is required and this typically has impact on resource consumption within the network. VoIP (Voice over IP) is a method used for realtime delivery of voice communications and media sessions over public or private data network.
In VoIP systems, the SIP is used for session initiations and it uses three primary address parts to locate an endpoint. Requests are sent to an SIP server via TCP to locate the client and registrations are subsequently set up following the success of the server to locate the node. The unreliability of the server-client model gave birth to a new system, peer-to-peer, where nodes on the network form swarms and are collective contributors to the larger network as a whole.
This system does not require a central server in most cases or if it'll ever need one, it'll merely be for the sake of registration on the network and the server the server has no real role to play in the activities that take place within the network.
A node on the p2p network that needs a resource sends a request for a file on the network, other nodes propagate the request for the file and available nodes with the file create a swarm then can they begin exchange of the file. Each node in the swarm is technically referred to as a seed. The requesting node maintains connection with the swarm till all data needed have been successfully downloaded. This essentially makes the network scalable and to an extent guarantees more security for the nodes on the network as multilayered security approach is employed.
The application of P2P systems can be found in some of the most notable overlay networks today, instant messaging, VoIP, video streaming etc. all use the peer-to-peer system to transmit packet data from endpoint to endpoint. SIP despite being the preferred method of communication initiation in VoIP does not cater for scalability in the network and suffers greatly
per bandwidth available hence a need for more ways to improve VoIP quality of service.
Previous Research
The concept of building a virtual network over an existing network is an old concept and the Internet can in fact be considered an overlay network as it was originally built to overlay on telephone networks which was the most common at the time. As the Internet grew and more overlays were built, research has shown that VoIP, which is an overlay on top of the Internet, started getting prominent due the low cost of setup and maintenance. Researchers claim Upon the receipt of an analog voice (standard voice) by telephone, Voice Gateway first digitizes the signal and compresses the new digital signal in the form of standard data blocks, known as IP packets [3][6]. They say the packets are sent over the Internet to the entrance of a Voice Gateway, where the process is reversed and with this technology researchers claim it is possible to make three different types of calls: PC to PC, PC to phone, and phone to phone.
VoIP consists of three essential components: CODEC (Coder/Decoder), packetizer and playout buffer. At the sender side, analog voice signals are converted into digital signals, compressed and then encoded into a predetermined format using voice codecs. There are various voice codecs developed and standardized by International Telecommunication Union Telecommunication (ITU-T) such as G.711, G.729, and G.723 etc. After this, packetization process is performed and this is when the encoded voice is fragmented into equal size of packets. Each packet has protocol header from the different layers that are attached to the voice bit that has been encoded.
These headers are added to the packets using RTP (Real Time Protocol), UDP (User Datagram Protocol) and the IP (Internet Protocol) as well as DLL (Data Link Layer) header [5]. Additionally researchers claim, RTP and Real Time Control Protocol (RTCP) were designed at the application layer to support realtime applications. Although TCP transport protocol is commonly used on the Internet, UDP protocol is preferred in VoIP and other delay sensitive real-time ap-
plications. TCP protocol is suitable for less delay-sensitive data packets and not for delay-sensitive packet due to the acknowledgement (ACK) scheme that TCP applies. This scheme introduces delay, as receiver has to notify the sender for each received packet by sending an ACK. On the other hand, UDP does not apply this scheme and thus, it is more suitable for VoIP applications [6]. The packets are then sent out over IP network to its destination where the reverse process of decoding and depacketizing of the received packets is carried out. During the transmission process, time variations of packet delivery (jitter)
may occur. Hence, a play out buffer is used at the receiver end to smoothen the playout by mitigating the incurred jitter. Packets are queued at the playout buffer for a playout time before being played. However, packets arriving later than the playout time are discarded. Besides, there are signaling protocols of VoIP namely Session Initiation Protocol (SIP) and H.323 [4][6]. These signaling protocols are required at the very beginning to establish VoIP calls and at the end to close the media streams between the clients.
Figure 1. Showing the structure of VoIP Architecture
Previous researches show that SIP uses DNS procedures to allow a client to resolve a SIP URI into the IP address, port, and transport protocol of the next hop to contact and that it also uses DNS to allow a server to send a response to a backup client if the primary client has failed. It also uses the DNS to address the issues of server, intermediate proxy location as well as location of the backup client in the failure of the failure of the primary client. First when an SIP connection is started, the SIP end system typically referred to as the user agent or client forwards the call request to a proxy server within it's own domain, this proxy
server then locates the proxy server in the other user agent's domain and forwards the request to the server who uses the URI to locate the other agent. As part of this call flow, proxy 1 needs to determine a SIP server for domain B. To do this, proxy 1 makes use of DNS procedures, using both SRV and NAPTR records that are basically specifications of data in the DNS that defines the location and port number of servers and some other devices [2].
A diagrammatic representation of this usually referred to as the SIP trapezoid is shown in the figure below.
Figure 2. Showing an SIP Trapezoid
It is important to note that DNS lookups can be used multiple times throughout the processing of a call. In general, an element that wishes to send a request may need to perform a DNS processing to determine the IP address, port and transport protocol of the next hop element (mostly the server) Such processing in principle could occur a number of times/number hops [5][8]. A common resolve most past researches have is that since SIP is used for connection initiations, the time required to setup a call ideally should be minimal and the margin for error should follow suit.
VOIP/SIP Problems
Despite the relative low cost of hardware and software maintenance involved in the use of VoIP, there are still a few key problems associated with it's use. During VoIP calls, packet loss is a common phenomenon and this often caused by jitters in the network and expired TTL in the packets. A network with high latency will often take longer to form the connection between the SIP clients and subsequent packet encoding/decoding will also suffer thereby leading to dropped calls, echo etc. [4][5].
Typically, it is advisable to have 80 to 90 kbps upload and download speed for a two-way conversation using the G711 codec. Other applications running on the softphone may also try to use part of the bandwidth available thereby causing dead spots or creating choppy calls. To achieve optimum call quality on VoIP, the use of network equipment that support packet prioritization along the link is required. This is not necessarily a good option as the balance of bandwidth usage is affected therefore there is a need for a solution that is less expensive to both hard and software components of the network and also provides quality service without affecting the throughput of the network. CARMA. To achieve a more stable SIP process and ultimately a higher QoS, a method of con-
necting clients that will be less reliant on bandwidth and coordinating server is required and this is where CARMA comes in [6][8].
CARMA is a network model that approximates the Internet as a mesh of interconnected Autonomous Systems. An AS is typically divided into IP ranges and subranges and may link to other ASes through a third subordinate AS. The mutual linkage of these ASes form an exchange point which allows to define the metric of how many AS junctions a packet has to travel between arbitrary nodes. But this falls short because the metric only allows for 7 locality flavors and practically, real hop counts that go beyond 7 are common which consequently leads to dropped packets and therefore inability to communicate with nodes farther away. CARMA addresses this problem by locally computing the metric and it does this by downloading AS IP structures from the publicly available FTP server of RIR [5] [6] After downloading the file, CARMA converts the information into a format that can be and then uses an in-built algorithm to estimate the metric between the arbitrary nodes. Judging by result accuracy,
CARMA has been compared with other distance estimation techniques like PING and TRACEROUT and was even implemented in a p2p system, it was shown to have solved the problem of packets timing out before getting to destination and also the inaccuracy that occurs due to network servers using packet-shapers to block ICMP/TCP packets. CARMA showed an improvement of 2.7% during implementation in the P2P environment. This of course is what the first version of CARMA was able to achieve on a broad scale p2p network [3][5]. Bringing the local distance estimation technique of CARMA into clients in a VoIP network, where if each client were to be fully aware of the network and knows what is the shortest path to the client to which it intends to connect, this will decentralize the workload on the SIP
server and make the system more scalable as well, during the encoding and decoding of the voice packets during the phone call, voice packets can be routed to and fro communicating clients through other clients within the network. This is basically creating another overlay network on top of the existing VoIP network and also unleashing the full potential of CARMA-P2P in VoIP.
Conclusion.
Since CARMA does local computation of network awareness, implementation of CARMA in SIP to replace client location tasks currently handled by SIP servers will eliminate latency that might occur during connection sessions when a call is being initiated. While this may sound as simple as they come, a broader research work on the possibility of this will definitely pay off.
References
1. Node Placement Analysis for Overlay Networks in IoT Applications International Journal of Distributed Sensor Networks Volume 2014 (2014), Article ID 427496.
2. https:// datatracker.ietf.org/doc/rfc2848/
3.https://www.packetizer.com/ipmc/papers/under standing_voip/ how_voip_works.html.
4. Poryev G. Multi-Tier Locality Awareness in Distributed Networks // IH^opMamnm TexHO^oriï Ta KOMn'roTepHa iH^eHepia. 2009. № 3(16). C. 13-17.
5. Poryev G. CARMA based MST Approximation for Multicast Provision in P2P Networks/Poryev G., Schloss H., Oechsle R.//In Proceedings of the Sixth International Conference on Networking and Services, 7-13 March 2010 p.,Cancun:Proceedings Cancun, Mexico: IARIA, 2010.—P. 123-128. 6. H. Schloss, R. Oechsle, J. Botev, M. Esch, A. Hohfeld, and " I. Scholtes,"HiOPS overlay efficient provision of multicast in peer-to-peer systems ," in 16th IEEE International Conference on Networks (ICON 2008), New Delhi, India, 2008, pp. 1-6.
7. B. Augustin, X. Cuvellier, B. Orgogozo, F. Viger, T. Friedman, M. Latapy, C. Magnien, and R. Teixeira, "Avoiding traceroute anomalies with Paris traceroute," in IMC '06: Proceedings of the 6th ACM SIGCOMM conference on Internet measurement. New York, NY, USA: ACM, 2006, pp. 153- 158
8. S. Ratnasamy, M. Handley, R. Karp, and S. Shenker,"Topologically-aware overlay construction and server selection," in INFOCOM 2002. Twenty-First Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE, vol. 3, 2002, pp. 1190- 1199 vol.
ДЕМОН АНДРЕЕВА, ДВИГАТЕЛЬ АНДРЕЕВА, ЦИКЛ
АНДРЕЕВА
Андреев Ю.П.
Независимый исследователь
ANDREEV'S DEMON, ANDREEV'S ENGINE, ANDREEV'S
CYCLE
Andreev U.P.
Independent researcher
АННОТАЦИЯ
В 1867 году английский физик Д.К. Максвелл придумал мысленный эксперимент с мифическими демонами с целью проиллюстрировать кажущийся парадокс второго начала термодинамики. В 1929 году Л. Сцилард предложил вариант двигателя с одной молекулой, который как бы мог нарушить второе начало. В "Фейнмановских лекциях по физике" Р.Ф. Фейнманом также был предложен вариант двигателя в виде храповика с собачкой, как вариант устройства, как бы нарушающего второе начало. Но все эти предложенные варианты так и не были созданы в виде реальных устройств. В данной статье рассматривается устройство - демон Андреева. Это устройство является полным аналогом множества демонов Максвеллы. То есть, это устройство пропускает отдельные молекулы с одной стороны стенки и не пропускает с другой. И конструкция этого устройства настолько проста, что его несложно изготовить в наше время. В результате появиться реальная возможность подтвердить или опровергнуть второе начало термодинамики.
ABSTRACT
In 1867, English physicist D.K.Maxwell devised a thought experiment using mythical demons to demonstrate an apparent paradox of the second law of thermodynamics. In 1929, L.Scilard offered a one-molecule engine version that could supposedly break the second law. In "The Feynman Lectures on Physics", R.P.Feynman offered a ratchet-and-pawl engine version that could also hypothetically break the second law. However, all of these versions were not real, created devices. This article discusses a device - "Andreev's Demon". This device is a complete analogue of the Maxwell's Demons; that is, this device allows separate molecules to pass through a wall from one side without allowing them to pass through from the other side. The design of this device is so