Search

The use of container-oriented orchestration platforms such as Kubernetes, is becoming more popular due to their ability to hide from developers the deployment details of the application and the capability of these platforms to support autoscaling and failure recovery. Most container orchestration environments have focused on supporting the HTTP protocol and are challenging to use in protocols such as SIP and RTP. When SIP/RTP services are deployed in the Kubernetes environment, failures related to port mapping and affinity occur. These failures are reflected as packets sent to the non-existent ports in either the overlay or underlay network in Kubernetes. This paper details these failures and presents solutions for resolving the SIP/RTP port mapping and the RTP affinity constraint failures. The SIP/RTP port mapping failure is solved by correctly mapping the internal SIP/RTP ports to those exposed externally by Kubernetes while the RTP affinity constraint solution leverages the concept of the creation of unique endpoints and labels for each RTP service port opened for a SIP call. The paper also offers some insight into the challenges faced in replicating the SIP constraint affinity failure. These solutions have been implemented in a Kubernetes aware SIP Proxy (SIP-K8S-Proxy) that supports port mapping and managing of the RTP affinity as well. The overhead associated with implementing this solution has been computed to be about 2 seconds in the establishment of a SIP call.

This paper discusses the issue with scaling SIP/RTP services in a container orchestration cluster such as Kubernetes. In order to run SIP/RTP services in the Kubernetes platform, we require that state and affinity between the two ends, be maintained by the container orchestration cluster. Currently Kubernetes primarily supports stateless services like HTTP. The paper explains the challenge of the Kubernetes overlay network for SIP/RTP services by presenting four failure scenarios with the objective to validate the failure scenarios and present viable solutions. Two of the four failure scenarios have been validated and our approach to counter these failures are presented. One proposed solution is based on a SIP back-to-back user agent or proxy integrated with the Kubernetes environment and a second that leverages the Kubernetes Ingress architecture and services. A third probable solution discussed are the service meshes.

The Fixed Node Assisted Collection Tree Protocol (FNA-CTP) is a Collection Tree Protocol (CTP) for sensor network that has been augmented with special fixed nodes in order to support mobility. The algorithm functions like the conventional CTP algorithm taking advantage of the fixed nodes only when it loses a parent. Prior simulation analysis of CTP in mobile environments demonstrated that conventional CTP has significant overhead when the sensor nodes are mobile even if some nodes are fixed. On the other hand, FNA-CTP reduces the overhead due to fixed nodes and alterations to the trickle algorithm. This chapter presents experimental analysis of the FNA-CTP algorithm implemented on a set of sensor nodes that support tinyOS in an indoor sports field. Unlike the simulation results, the experimental results show that CTP outperforms the FNA-CTP algorithm though this primarily because it was not possible to recreate an experiment where the sink node was out of range of the mobile nodes resulting in less parent changes in CTP than FNA-CTP. In this chapter we present details and challenges of these experiments such as capturing and pre-processing of the packets captured by a sniffer in the field as well as at the sink.