Modern VoIP in Modern Infrastructures
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
Title |
| |
Subtitle |
| |
Title of Series | ||
Number of Parts | 490 | |
Author | ||
License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
Identifiers | 10.5446/47261 (DOI) | |
Publisher | ||
Release Date | ||
Language |
Content Metadata
Subject Area | ||
Genre | ||
Abstract |
|
00:00
InternettelefoniePoint cloudRevision controlQuicksortMereologyInternettelefonieMultiplication signBitComputer animation
00:42
HypermediaFocus (optics)Information securityMachine visionTime evolutionInternettelefoniePoint cloudScalabilityDirected setConfiguration spaceMereologyProjective planeEntire functionPoint cloudVirtuelles privates NetzwerkLastteilungOpen sourceCloud computingComputing platformInternettelefonieInternet service providerStrategy gameSingle-precision floating-point formatAreaImplementationMultiplication signConnectivity (graph theory)ScalabilityMaxima and minimaInformation securityContext awarenessBitPhysical systemCartesian coordinate systemMedical imagingDirect numerical simulationCovering spaceLatent heatDecision theoryConfiguration spaceEvoluteServer (computing)
04:50
InternettelefonieFirewall (computing)Group actionIP addressInformation securityGame controllerComputer animation
05:23
Computer networkVoltmeterSession Initiation ProtocolComputing platformMultiplication signTwitter
05:44
Communications protocolPoint cloudSanitary sewerEvoluteCommunications protocol
06:07
InternettelefoniePoint cloudInternet service providerVirtual machineIP addressConstraint (mathematics)Physical systemMaxima and minimaLastteilungLevel (video gaming)Connectivity (graph theory)Time zoneService (economics)Elasticity (physics)Asynchronous Transfer ModeConfiguration spacePoint cloudComputer animation
08:00
Address spaceDirected setComponent-based software engineeringInternettelefonieGastropod shellBit rateBand matrixFloating pointTablet computerEndliche ModelltheorieScale (map)Computing platformDirect numerical simulationChemical equationSession Initiation ProtocolComputer networkPartial derivativeUDP <Protokoll>Structural loadSource codeNetwork socketScalable Coherent InterfaceChemical equationCodecMultiplication signLevel (video gaming)Mathematical optimizationComputing platformIP addressState of matterAbstractionBit rateSource codeServer (computing)LastteilungSystem callDifferent (Kate Ryan album)Streaming mediaMaxima and minimaGroup actionCloud computingPoint cloudService (economics)Band matrixWeb applicationElasticity (physics)Interface (computing)MereologySession Initiation ProtocolDependent and independent variablesTheory of relativityVirtual machineStructural loadProgramming paradigmConnectivity (graph theory)Tracing (software)Direct numerical simulationBitRight angleRoutingComplex (psychology)Connected spaceInternettelefonieInformationClient (computing)Operator (mathematics)
13:17
UDP <Protokoll>Chemical equationCommercial Orbital Transportation ServicesStandard deviationSession Initiation ProtocolBand matrixHypermediaBit ratePoint cloudLimit (category theory)Computing platformTransport Layer SecuritySystem programmingDynamic random-access memoryScripting languageResource allocationRippingServer (computing)Client (computing)Extension (kinesiology)Reverse engineeringCommunications protocolVapor barrierService (economics)Term (mathematics)Source codeInternettelefonieStructural loadComputer networkSession Initiation ProtocolSoftwareClient (computing)Real-time operating systemCartesian coordinate systemGoodness of fitLastteilungInternet service providerCASE <Informatik>Cloud computingServer (computing)MereologyTerm (mathematics)Point cloudCommunications protocolScripting languageCovering spaceData conversionConnected spaceHypermediaPoint (geometry)Level (video gaming)InternettelefonieStandard deviationView (database)Multiplication signTelecommunicationReal numberOpen set
16:27
Multiplication signComputer animation
16:56
Point cloudFacebookOpen sourceComputer animation
Transcript: English(auto-generated)
00:05
So next up we got Giacomo here, all-timer from the room as well, and he's gonna tell us about modern VoIP infrastructures. Take it away. Yes, thanks. So this is a sort of back-chat that we've been having for a couple of
00:22
years with Federico, and we've been working on this concept for some time now. And Federico did a presentation, a little bit more extended than this in September at Januscon. And today we will see something like a light version which is more focused on signaling. And the other parts
00:45
that we typically cover are more related to media, handling in QoS, debugging tools and security. So I've been in the VoIP area for some time now, and I've been in various companies that
01:00
use open source components and involved with the Kamailo project and other projects in the area, like Janus, Asterisk and Freeswitch and RTP Engine and so on. And so let's see the overview. As I mentioned, we'll cover mainly signaling today, and we'll see a little bit about the
01:24
evolution of the infrastructures where VoIP is actually deployed nowadays, and which bits of VoIP are impacted, and some workarounds, so what you typically see together today, and possibly some thoughts for the future. So why the cloud and why we are deploying VoIP
01:47
platforms in cloud infrastructure is easy to sell. There are many advantages. Sometimes even the customers or the partners somehow expect it. HA is definitely more easy to achieve, and
02:05
scalability comes in an easier way. And if you are starting small, it's easier to then grow and have a small upfront investment. Geographic distribution, which is very valuable,
02:21
it's easy to achieve even with small implementations. And sometimes you get, for the easiest things, you get tools that are just there off the shelf, like HTTP load balancers or caching systems like Redis and DNS already there and so on.
02:44
So there are some challenges though, because when you choose a cloud provider, then if you already have a system, you most probably need to redesign either the entire infrastructure, the entire architecture or parts of it. And instead, if you are starting from
03:02
a specific cloud provider, you probably need to take some decisions that you will need to cover in the future. And you may pay if you decide just to move to another provider. Sometimes you don't have shared dedicated resources and it's difficult to assess the impact
03:24
in a real-time context. And so it's not easy if you instead decide to spread a little your strategy and not relying on a single cloud provider. You may have part of the
03:41
infrastructure in a cloud provider and part in another, and there is no standard simple solution that works every time. Typically you need to either do something specific like VPNs or discuss with the providers for a specific solution, but there isn't anything that you can just use. And sometimes you have tools that are just specific from those cloud providers.
04:08
So just in general, we moved, so starting from 2001 and so on, I think we moved from the server side where max uptime was a reasonable goal and was considered the positive
04:23
achievement. But now what we focus on is the maximum possible resilience to restart of the applications. And we moved from configuration updates just maybe more recently to an infrastructure that can be called immutable, where when you want to change something, you don't change
04:42
the configuration, you change the components that are involved, like for example deploying new container images. And so we grew up in our VoIP experience with a very simple infrastructure where everything was under our control, provision wasn't that simple, things didn't move fast,
05:07
but we could know everything, IP addresses, we could have public IP addresses directly on the machines, and we have full control on firewall and what now are called typically security groups.
05:25
Then if you look back, so we stumbled upon this tweet from Rosenberg last year, and he said, well, you know, this is how much time has passed since this work on this protocol started. So if you see just RTP and SIP, we're talking more than 20 years, but if you compare
05:46
it with the evolution of the infrastructure, instead, you see that most of the protocols were actually designed when the infrastructure was different than today. And I think this is
06:00
probably also visible in some aspects, and we're going to take a look. So this is more similar to what we would like to see, not care that much about the orbiter, being able to have our systems
06:21
provided by containers, so any orchestration system generically, even Kubernetes possibly, but then, in particular for the inbound part, having a component like this blue load balancer thing that we draw, a component that is VoIP aware and is able to manage the incoming
06:45
and possibly also the outgoing traffic, but with minimum configuration and with minimum work, as you can do, for example, with HTTP. The problem is what we typically end up working now
07:01
is more likely something like this. So you have elastic IPs or static IPs depending on the cloud infrastructure, so floating IPs in general. You need to take care of their location and associate them to your virtual machines or to your containers and manage the relationship with
07:22
the service that's behind those floating IP addresses. Sometimes if you want to maximize reliability, you typically have a virtual machine or a container in active mode and another one in standby mode, but then you have constraints on how the standby can do the health
07:43
checks for the active one. For example, in AWS you can do level 3 checks only inside the same availability zone and you need to take care of all these details by yourself.
08:01
So, in general, something that impacts the architecture is that the IP addresses in when you are in particular with containers that can be brought up and down, the IP addresses change and not only the relationship with the public interface, but also if you redeploy a
08:25
container you may have a different IP address. This doesn't work well in general with signaling and typically you only get a one-to-one nothing between your machines and a public interface and you don't have a direct visibility of your public IP addresses.
08:50
So slightly related, but not for this session, is also the difference between the bandwidth that cloud providers tell you that you have and instead the packet rate that you actually have
09:02
and also typically you don't even know what your maximum packet rate is because the bandwidth is computed with Jambo packets and not with the small packets that come with CODEC optimization and also containers are ephemeral so they can be brought up and die and then you need to
09:22
do something for the calls that do have a state and other things that are less important but still critical for operations which is related to logs and other information like traces for example. So the main difference between an HTTP-based or web-based world and VoIP is that you may say
09:46
VoIP sessions are sticky, they are not part of the request and response paradigm and this doesn't cope well with an architecture that adds components but at the
10:01
same time can remove components which may be even more tricky so you need to find a balance between the immutability of the state of the calls but also the volatility of the components that are serving, that are providing the service. As we mentioned the IP addresses are ephemeral so
10:23
one time ago you could decide this is your box, it will have a long time, it will have a public IP address, possibly one or more private IP addresses and signaling for ongoing calls could rely on those IP addresses for correct routing. This is difficult to achieve now
10:47
with the volatility of IP addresses and so you need to shift the design of the architecture more towards DNS and in general so having for example to work with console and be assured that
11:04
routing is done with DNS and not with IP addresses which is an additional complexity and it doesn't really provide the solution for RTP and we'll see later a little bit what Rosenberg has been proposing recently in relation to this. So in general we
11:25
have a lack of native components for VoIP in cloud infrastructure and in particular we don't have what we would like to have which is basically just a SIP load balancer. So what typically happens is that you talk with people in your team and they say well okay just use a load balancer,
11:43
just pick up a load balancer but then I'm having these conversations over and over. This just doesn't work. So first of all AWS elastic load balancer work only for HTTP. So the network load balancer are very nice and are powerful but at the same time
12:01
first of all for TCP and TLS which is the best scenario they are based on the stream so they don't do load balancing, they do stream balancing between a source of the stream and a target group and for UDP it just doesn't work and we will see quickly an example and the same can be exactly say at this level of abstraction with
12:25
Google cloud platform. So just to give an example so as long as you have UDP traffic coming in if you use just an AWS NLB it will choose one target and will route the
12:41
requests to that target but also it will route back the responses which is very useful. But if the call is long enough that is there are requests from the server like a re-invite or a buy from the server after some time you may end up in the scenario on the right where
13:01
there's no more trapped connection in the load balancer and the basically the requests go directly from the target to the client and it's more likely than not the client will not even accept those packages. So of course we've been reading during these months and we were
13:22
looking at suggestions and recommendations and then I don't know you can pick up for example this AWS white paper about the all the solutions for real-time communication then you start getting more and more excited as you read but then you find this eventually when you
13:41
when you need to find a real solution for SIP networks you find something like this that says if you really want to do level four load balancing and UDP is involved and you use SIP then you need to search for an application in the marketplace basically and use it which is not what we want because more or less it's what we are all redesigning each one in our own
14:05
in our own case this is media I'm not going to cover it not this one not debug so this is part of a bigger conversation so as we said there's no interconnecting there's no standard interconnection with clouds so and these are the the workarounds that we see today
14:27
everybody is rebuilding their own load balancer so we are not doing a common work from this point of view of course we can use Camellio we can use Open SIPs or Dragti or other solutions then we are more or less duplicating the work and there are still around drain scripts there's
14:45
nothing automatic in the in the in the infrastructure themselves and so quickly to conclude if you take a look at this proposal this is a proposal for changing the way trunking is made in between void providers it doesn't cover this client to server communication but in our opinion
15:08
it can it can be extended to cover that and basically it's a way of setting up trunks using HTTP 3 and also having the media flowing through parallel quick connections rather than using
15:23
RTP so this could be something that at community level we can we we can discuss so just very very quickly it SIP and RTP just as an example do are old at the same time even WebRTC is dragging
15:40
more and more usage of these protocols because they they made the bridging between all the new WebRTC applications that are being designed and the good old PSTN world so for the long term what we would like to have is a VoIP load balancer a concept that can scale up internally
16:02
that is aware of the target servers that can distribute calls and proper managing the dialogues and in the VoIP sessions avoiding vendor lock-in so we can move more easily from a cloud provider
16:21
to another and have some best practices and possibly refine the other protocols and that's all yeah thank you thank you maybe we have time for one question until
16:41
it's all set up one question no question okay and okay now thank you thanks