Scribd
Upload
14 views

08 Alex - Balashov Kamailio ITSP Changes

Uploaded by

huenth
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
14 views

08 Alex - Balashov Kamailio ITSP Changes

Uploaded by

huenth
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 12

Kamailio in the ITSP:

Changing Winds
Alex Balashov
Evariste Systems LLC
Athens, Georgia, USA
http://www.evaristesys.com/
Evariste Systems?
● Based in Athens, Georgia, USA (university town close to Atlanta);

● Kamailio consultancy from 2007;

● Vendor of CSRP (Class 4 routing product) based on Kamailio:


○ http://www.csrpswitch.com/

● Blog on Kamailio technical topics:


○ http://www.evaristesys.com/blog/

● Provider of SIP and Kamailio training;

● Kamailio project contributor, advocate.


Conventional wisdom about ITSP infrastructure (2000s,
early 2010s):
● Big, serious and real-time;

● Dedicated and ample hardware for best economies of scale;

● Cloud and virtualisation are hostile to “media performance” and “real-time”


anything;
○ Poor call quality and the rest.

● Real-time communications are special and require artisanal, nuanced


infrastructure approach.
Nevertheless:
● Big shift: ITSPs embracing major cloud
services anyhow.
● CxO suite sold by:
○ In “developed world” only, mostly; ○ Divestiture of non-core
AWS & friends’ POPs elsewhere are competencies;
nonexistent. ○ Reduction of business
risk and headcount
● AWS EC2/GCE/Azure are not perfect for expenditure for
media and RTC handling; operations;
○ Fashionable trends and
● “Just good enough”
buzz, FOMO.
○ Kind of like public Internet backbone
from late 2000s;

● Virtualisation has objectively evolved


○ Almost first-class CPU tenant;
○ Close “to the metal”.
What the businesspeople want:


Fire the system admins and reduce operations headcount.


The “big fat box” model of telecoms infrastructure:
● Big, well-resourced physical server (leased dedicated or owned);
○ Typical stats: 4+ cores, 32+ GB of RAM, SSDs, Gigabit LAN.

● Own administration, responsibility for redundancy and upkeep


○ Requires people (system admins, data centre remote hands, etc.) for care and feeding;
○ Engineering, storage, etc. mostly local concern, which can be bad without big CAPEX;

● Services provider infrastructure and applications highly centralised.


○ Big database;
○ Lots of IOps;
○ Lots of RAM;
○ Central proxy;
○ Aggregation;
○ Focus on optimising throughput.
Typical “big box” data centre architecture (CSRP):
“Big fat box” to cloud:
● Cannot simply migrate “big fat box” architecture as-is!

● Hosting on someone else’s hypervisor/infrastructure is not cloud; it’s just hosted;


○ To develop cloud-native services, you must “get” cloud;
○ Cloud platform pricing will not support this approach;
■ Will increase OPEX;
■ Not savings;
■ Big instances are very expensive.

● Cloud-native service & application characteristics:


○ Distributed;
○ Dynamic discovery / self-assembly;
○ Elasticity;
○ Dimensions fitted to instances and componentry of cloud.
“Big fat box” to cloud (cont’d):
● Typically requires extensive re-architecture of highly centralised applications;

● Just breaking big, centralised components (e.g. into containers) for distribution is
not enough;

● You still need [lots of] people to build and run this! Skill sets:
○ Linux sysadmin folk traditions;
○ Updated for modern “cloud” DevOps;
■ Orchestration (Ansible, Salt, Puppet, Chef, etc.);
■ Discovery and synchronisation (e.g. Consul, Serf, Kubernetes, etcd, Redis, Route53, etc, etc.);
■ Cloud platform APIs and automation;
■ Idiosyncrasies of cloud platform (networking, limitations, economics of instances).
○ True to the name: more “dev” to go with “ops”.
Unexpected factors for ITSPs:
● Big instances are very expensive — cloud ● Network and reachability issues as artifices
providers really, really want you to buy lots of cloud product rather than technological
of smaller ones; limitations;

● Often invisible and non-obvious resource ● All of this has a-la-carte solutions and
constraints: becomes a line item on your bill!
○ PPS and bandwidth limits;
○ Not necessarily published; ● Will you save money?
○ Backbone and transit transfer limits. ○ Maybe; maybe the opposite.

● Occasional ● Will you reduce risk and improve


scheduling/contention/hypervisor issues; availability?
○ Probably not, but shape of problem is
different.
Kamailio features complementary to cloud-native dev.:
● Hot reloading: ● Flexible logging;
○ dispatcher
○ rtpengine (sets defined in DB) ● Flexible invocation and environment for
○ RPC containerised execution;

● Fallback to mostly stateless relay (except for ● http_async_client for HTTP REST interactions;
hop-by-hop messages);
● Options to support 1-to-1 NAT and advertising of
● DMQ public addresses:
○ dmq_usrloc and dialog replication ○ listen=udp:x.x.x.x:5060 advertise
y.y.y.y:5060
○ Database-synced approaches aren’t so
○ rtpengine -i external/10.x.x.x!56.1.2.3
good for cloud due to
bandwidth/backbone contsraints;
Thanks!
Please find me if you have further questions, or visit: http://www.evaristesys.com/

You might also like