designing high performance rtc signaling servers

27
Daniel-Constantin Mierla @miconda - www.asipto.com - Co-Founder Kamailio Fosdem - January 2016 - Brussels Designing High Performance RTC Signaling servers

Upload: daniel-constantin-mierla

Post on 09-Feb-2017

256 views

Category:

Technology


1 download

TRANSCRIPT

Page 1: Designing High Performance RTC Signaling Servers

Daniel-Constantin Mierla @miconda - www.asipto.com - Co-Founder Kamailio

Fosdem - January 2016 - Brussels

Designing High Performance RTC Signaling servers

Page 2: Designing High Performance RTC Signaling Servers

a very large set of features

kamailiocontinuos development since 2001

2002 Jun 2005 Jul 2008 Aug 2008 Nov 2008

SIP Express Router (SER)

OpenSER Kamailio

Other Forks...

Same application: Kamailio - SER

Oct 2009 Jan 2010

v3.0.0

Integration Completed

v1.5.0

Sep 2011Sep 2001

First Line Of

Code

Open Source

GPL

FhG Fokus

Institute

Berlin

rename

Awarded Best Open

Source Networking

Software 2009

By InfoWorld

10 Years

Jun 2012

v3.3.0

ITSPA UK

Award

Mar 2013

v4.0.0

Kamailio

v4.1.0

Dec 2013

………. v4.2.0

Oct 2014

now over 100 on github

June 2015

v4.3.0

Page 3: Designing High Performance RTC Signaling Servers
Page 4: Designing High Performance RTC Signaling Servers

not designed as a typical telephony engine

open source sip serverframework - toolkit

SIP signalling routing

• fast

• reliable

• flexible

In other words

• not initiating calls

• not answering calls

• no audio-video processing

Page 5: Designing High Performance RTC Signaling Servers

Key Features

✤ Modular SIP Poxy, Registrar and Redirect server

✤ Designed for scalability and flexibility

✤ IPv4, IPv6, UDP, TCP, TLS, SCTP, WebSocket

✤ NAT Traversal, internal and external caching engines

✤ JSON, XMLRPC, HTTP APIs

✤ IMS Extensions, SIP-I/SIP-T, IM & Presence

✤ SQL and NoSQL backends

✤ Asynchronous processing (TCP/TLS, SIP routing), external event API

✤ Embedded interpreters (Lua, Perl, Python, .Net, Java)

✤ Load balancing, LCR, DID routing, Number portability

Page 6: Designing High Performance RTC Signaling Servers

http://www.kamailioworld.com

YouTube KamailioWorld Channelhttps://www.youtube.com/channel/UCElq4JNTPd7bs2vbfAAYVJA

Page 7: Designing High Performance RTC Signaling Servers

Designing High Performance RTC Signaling Servers

Protocol Message ParsingMemory ManagementSynchronisationTimersCaching

Page 8: Designing High Performance RTC Signaling Servers

Message Parsing

Page 9: Designing High Performance RTC Signaling Servers

Lazy Parsing - Benefits

✤ parse only what is needed

✤ cache what was parsed

✤ no cloning - keep references to the receive buffer

✤ use private memory

✤ move to shared memory only if needed

✤ keep changes as diff list

✤ apply changes when sending out (or on demand)

Page 10: Designing High Performance RTC Signaling Servers

Lazy Parsing - Drawbacks

✤ not full validation of the message

✤ confusion for new comers regarding the changes

Page 11: Designing High Performance RTC Signaling Servers

Lazy Parsing

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 192.168.99.1:5060;branch=z88 From: Alice <sip:[email protected]>;tag=123 To: Bob <sip:[email protected]> Call-ID: [email protected] CSeq: 1 INVITE Subject: Happy Christmas Contact: BigGuy <sip:[email protected]> Content-Type: application/sdp Content-Length: 147

v=0 o=UserA 2890844526 2890844526 IN IP4 here.com s=Session SDP c=IN IP4 100.101.102.103 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000

Operation: delete Position: line 7 Length: 26

Operation: add Position: line 11 Value: My-Subject: hello!\r\n

internal SIP message structure

SIP message buffer

list with changes to SIP message content

Page 12: Designing High Performance RTC Signaling Servers

Lazy Parsing

From: Alice <sip:[email protected]>;tag=123

= from.body.s from.body.len = 34

= from.displayname.s from.displayname.len = 5

= from.uri.s from.uri.len = 18

= from.username.s from.username.len = 5

= from.domain.s from.domain.len = 8

= from.tag_value.s from.tag_value.len = 3

Page 13: Designing High Performance RTC Signaling Servers

Memory Management

Page 14: Designing High Performance RTC Signaling Servers

✤ reserve zones of system memory for private and shared access

✤ allocates smaller chunks in each zone

✤ manage alloc, realloc, free and join operations

system memory

kamailio private memory

kamailio private memory

kamailio shared memory

kamailio allocated chunk

Page 15: Designing High Performance RTC Signaling Servers

✤ benefits✤ optimizations for common chunk sizes✤ enable/disable join operations✤ select among different allocator algorithms (at startup)

✤ fast malloc, quick malloc, tlsf malloc, doug lea malloc✤ avoid unnecessary locking✤ tunings for troubleshooting

✤ drawbacks✤ not easy to use various memory management tools✤ maintenance of code

Page 16: Designing High Performance RTC Signaling Servers

Synchronization

Page 17: Designing High Performance RTC Signaling Servers

✤ relevant facts✤ private memory vs shared memory✤ mutexes - standard (posix) vs custom (busy loop)✤ message queues✤ memory bariers

Page 18: Designing High Performance RTC Signaling Servers

Timers

Page 19: Designing High Performance RTC Signaling Servers

✤ timer processes

✤ lazy operations for many modules

✤ keep alives, cleaning expired data

✤ increase (or reduce) the timer interval

… modparam("usrloc", "timer_procs", 4) … modparam("nathelper", "natping_processes", 6) … modparam("dialog", "timer_procs", 4) modparam("dialog", "ka_timer", 10) modparam("dialog", "ka_interval", 300) …

Page 20: Designing High Performance RTC Signaling Servers

caching

Page 21: Designing High Performance RTC Signaling Servers

✤ config or internal hash sizes

✤ indexing of data in memory

✤ location records (usrloc), dialogs, generic hash tables

… modparam("usrloc", "hash_size", 12) … modparam("htable", "htable", “a=>size=4;autoexpire=7200;") modparam("htable", "htable", "b=>size=8;") … modparam("dispatcher", "ds_hash_size", 9) …

https://en.wikipedia.org/wiki/Hash_table

Hash Table Head

name:test

size: 2

key: alice

slots

“xyz”

0

1

2

3

key: bob

123

key: john

“1ab”

Page 22: Designing High Performance RTC Signaling Servers

✤ config or internal tree structures✤ indexing of numbers in memory✤ pdt, mtree, userblacklist

https://en.wikipedia.org/wiki/Tree_(data_structure)

… loadmodule “mtree.so" … # ----- mtree params ----- modparam("mtree", "db_url", DBURL) modparam("mtree", "mtree", "name=didmap;dbtable=didmap;type=0") modparam("mtree", "char_list", "0123456789*+") modparam("mtree", "pv_value", "$var(mtval)") … if(mt_match("didmap", "$rU", "0")) { $avp(dsid) = $(var(mtval){s.int}); route(DISPATCH); exit; } …

Page 23: Designing High Performance RTC Signaling Servers

✤ asynchronous processing✤ delegate the execution to other workers than sip routing processes

✤ async module

✤ tmx (suspend) - mqueue (transmit) - rtimer (process)

✤ async database queries (mysql)

✤ async http/jsonrpc interactions

… async_workers=4 … modparam("sqlops","sqlcon","ca=>dbdriver://username:password@dbhost/dbname") sql_query_async("ca", "delete from domain"); … modparam("acc", "db_insert_mode", 2) …

http://www.kamailio.org/events/2014-KamailioWorld/day2/26-Daniel-Constantin.Mierla-Kamailio.cfg-Async.pdf

Page 24: Designing High Performance RTC Signaling Servers

✤ bonus

✤ children

✤ number of worker processes

✤ tcp - tls

✤ max connections

✤ file description limits

✤ internal dns caching

✤ blacklisting

Page 25: Designing High Performance RTC Signaling Servers

✤ don’t forget

✤ database indexes

✤ syslog asynchronous mode

✤ dns infrastructure availability

✤ api services responsiveness

Page 26: Designing High Performance RTC Signaling Servers

Kamailio World 2016 - A Special Edition

Kamailio Project 15 YEARS OF DEVELOPMENT

2001-2016 from SER to Kamailio

www.kamailioworld.com

Thank you!Questions?@miconda

Page 27: Designing High Performance RTC Signaling Servers

the photos used inside this presentation were found on various webpages and there was no copyright or restriction of reuse mentioned

if some conditions were overseen, that was unintentional, please contactthe author of the presentation for appropriate corrections