Systeembeheerder in het MKB: er wordt soms op neergekeken. Je zou jezelf niet genoeg kunnen ontwikkelen, het betaalt te weinig, je kunt niet werken met de nieuwste technieken en je werkt vaak alleen, waardoor je te weinig kritiek van vakgenoten krijgt en dingen te veel op je eigen manier gaat doen. En ga zo maar door. Hoewel deze opvattingen niet helemaal onterecht zijn, valt er toch het nodige op af te dingen. Als systeembeheerder in het MKB krijg je vaak een ongekende hoeveelheid vrijheid en vertrouwen. Je gaat dan inderdaad dingen op je eigen manier doen, maar eigenlijk is dat juist hartstikke leuk!

Zo werd in 2015 de vraag bij mij neergelegd of we als bedrijf niet over konden stoppen op VoIP om kosten te besparen. De crisis was nog steeds voelbaar en elke besparing was mooi meegenomen.

 Mijn eerste antwoord was: “Natuurlijk!” Alleen had ik nog geen idee hoe, aangezien ik geen enkele ervaring had met VoIP. Ik zag echter wel in dat het een mooie gelegenheid was om dingen eens anders te gaan doen.

 Voor onze telefonie zijn wij altijd klant geweest bij KPN. Hoewel ik KPN na moet geven dat ze altijd betrouwbare oplossingen leverden en we nooit noemenswaardige problemen hadden, heb ik toch een hekel aan het bedrijf. KPN heeft namelijk de onhebbelijke gewoonte om zogenaamde blackbox oplossingen te leveren. Thuisgebruikers die klant zijn bij KPN zullen dit herkennen. De door KPN geleverde Experia Boxen zijn flink dichtgetimmerd. Het aantal aanpassingen dat je als gebruiker zelf kunt doen is minimaal. Zo kun je bijvoorbeeld niet eens de IP-range van je LAN aanpassen en ben je gedwongen de door KPN voorgeprogrammeerde range te gebruiken.

 Dat was met onze telefooncentrale ook het geval. Een dichtgetimmerde zwarte doos, waar we zelf vrijwel niets mee konden. Voor de kleinste dingetjes moest KPN gebeld worden, die dan op afstand de aanpassing doorvoerde en daar dan een dikke rekening voor stuurde. Dat wilde ik anders gaan doen!

 Een mogelijkheid was natuurlijk om voor een kant-en-klare cloud-oplossing te kiezen. Destijds hadden we echter een 20/20 internetverbinding, die het zwaar had te verduren. Bellen via de cloud zou betekenen dat ook de interne telefoontjes (het merendeel) allemaal via het internet zouden gaan. Dat zag ik vanwege de beperkte bandbreedte niet zitten.

 Bovendien zou een cloud-oplossing weer beperkingen betekenen. Weliswaar geven die over het algemeen meer vrijheid dan we van KPN gewend zijn, maar toch. Een ander bezwaar was dat we dan weer aan abonnementen en contracten vast zouden zitten en voor elk toestel apart moesten gaan betalen. Het was dus de vraag in hoeverre dit een besparing op zou leveren.

 Een andere mogelijk was om een gespecialiseerd bedrijf in de arm nemen en die een kant-en-klare VoIP oplossing te laten leveren. Ik had bij andere bedrijven in de buurt echter al gezien dat dit ook een dure oplossing zou gaan worden en ons bovendien niet zou vrijwaren van problemen. 

 Het spreekwoord luidt daarom niet voor niets: “als je iets goed wilt doen, doe het dan zelf”.

Asterisk

Iedereen weet dat Asterisk dé software is om zelf een telefooncentrale (PBX) te draaien. Ik had deze software al langer op mijn wensenlijstje staan en dit was natuurlijk een uitstekende gelegenheid om dat in de praktijk te gaan brengen. Met de bedrijfsleiding werd afgesproken dat ik 1 à 2 jaar de tijd zou krijgen om me Asterisk eigen te maken en aan de overstap naar VoIP te werken. Ik wilde de uitdaging natuurlijk graag aangaan, maar dan wilde ik wel goed beslagen ten ijs komen. Tenslotte is een telefooncentrale een belangrijk bedrijfsonderdeel.

 Ik begon met de aanschaf van het boek Asterisk The Definitive Guide 4th edition van de bekende uitgever O’Reilly Media. De PDF is gratis te downloaden, maar als je voor een grafisch bedrijf werkt, geef je natuurlijk de voorkeur aan een papieren versie. Het boek leest prettig, geeft goede uitleg en is goed te gebruiken als naslagwerk. Het gaf mij in elk geval een solide basis. Als die basis er eenmaal is, dan gebruik je natuurlijk het internet voor meer diepgang.

Raspberry Pi

Ik begon met Asterisk for Raspberry Pi, op een Raspberry Pi 2. Natuurlijk niet voor het bedrijf, maar bij mezelf thuis. Het ding werd in de meterkast opgehangen en via SSH ingesteld. Ik had de mogelijkheid om daarbij gebruik te maken van FreeBPX. Dat is een webinterface voor Asterisk, dat kant-en-klaar werd meegeleverd op de image. Ik besloot dat echter niet te doen, omdat ik Asterisk zélf eigen wilde maken en daarom zo dicht mogelijk bij de basis wilde blijven. Dus in plaats van een webinterface werd het configuratiebestanden editen met VIM, via SSH. Iets wat eerlijk gezegd mijn voorkeur heeft.

 Via mijn broer kon ik een paar oude Grandstream GXP 2010 toestellen op de kop tikken en zo kon het oefenproject beginnen. Over dit project wil ik verder niet uitweiden, aangezien het een oefenproject was. Wel wil ik zeggen dat die Raspberry Pi 2 nog steeds in de meterkast hangt en dagelijks in gebruik is. Hetzelfde geldt voor de Grandstream toestellen. Voor wie thuis wil experimenteren met VoIP kan ik het zeker aanraden. Het is echt ontzettend leuk om mee te prutsen. Aangezien tegenwoordig bijna iedereen al via VoIP belt, is de drempel erg laag. Je hebt immers al een SIP-account om je centrale met de buitenwereld te verbinden, dus je kunt direct aan de slag.

Een Asterisk server bouwen

Nu ik de basis onder de knie had en enige praktijkervaring had opgedaan, werd het tijd om naar de zakelijke oplossing te gaan kijken. Ik ben begonnen om Ubuntu op een oude PC te installeren en dat als basis te gebruiken voor een vanilla Asterisk server. Later is dat gevirtualiseerd op Hyper-V.

 Na installatie van Asterisk zijn twee bestanden van belang voor de configuratie. Dat zijn sip.conf en extensions.conf. In het eerste bestand worden alle SIP-instellingen beheerd. Dat zijn zowel de SIP-trunk naar de provider, als de SIP-accounts voor alle toestellen. In extensions.conf wordt het dialplan bepaald. Laten we beginnen met de General section van sip.conf.

[general]

context=default

allowguest=no

alwaysauthreject=yes

bindaddr=0.0.0.0

bindport=5060

externip=123.123.123.123

localnet=192.168.0.0/255.255.255.0

srvlookup=yes

register => login:wachtwoord@sip.provider.nl

registertimeout=120

nat=force_rport,comedia

qualify=yes

directmedia=no

callcounter=yes

busylevel=1

callevents=yes

sendrpid=yes

trustrpid=no

tlsenable=yes

tlsbindaddr=0.0.0.0

tlscertfile=/etc/asterisk/keys/cert.pem

tlscapath=/etc/asterisk/keys

tlscipher=TLSv1

tlsclientmethod=tlsv1

disallow=all

allow=alaw

allow=ulaw

allow=gsm

De meeste opties spreken voor zich. Het gaat te ver om alles in dit artikel door te nemen. Ik noem daarom alleen de optie die voor mij belangrijk was: de optie sendrpid=yes. Na de overstap bleek de ID niet goed meegestuurd te worden, zodat al onze telefoontjes uit Amsterdam afkomstig leken te zijn. Dat leverde natuurlijk verbaasde reacties van klanten op. Door deze optie op yes te zetten, werd dat probleem opgelost.

Beveiliging

De optie alwaysauthreject=yes lijkt echter ook een beetje bijzonder. Dit wordt aangeraden om bots, die automatisch proberen SIP-accounts te kraken, in de war te brengen. Het is werkelijk verbazingwekkend hoe snel je deze pogingen in je logs voorbij ziet komen. Bedenk daarbij dat een succesvolle hack flink in de papieren kan lopen. Die wordt in de meeste gevallen gebruikt om via jouw centrale peperdure telefoontjes naar het buitenland te plegen. En die rekening moet je dan gewoon betalen. Het is dus ontzettend belangrijk om de beveiliging van je centrale heel serieus te nemen.

 Een manier om dit te doen is fail2ban, die bots automatisch blokkeert na een ingesteld aantal foutieve pogingen om in te loggen. Op internet zijn genoeg tutorials te vinden, die je precies uitleggen hoe dat moet. Als je echter alleen met vaste toestellen werkt, dan kun je ook gewoon de SIP-poorten in je firewall alleen openzetten voor het IP-adres van je SIP-provider en de vaste toestellen buiten het bedrijf. De rest van de wereld blokkeer je dan gewoon. Simpel en effectief.

 

SIP-trunks

Vervolgens moet de SIP-trunk ingesteld worden, die natuurlijk moet worden aangevraagd bij een SIP-provider. Als de gegevens verstrekt zijn, dan komt dat er zo uit te zien.

[inkomend]

type=peer

secret=supergeheim

defaultuser=gebruikersnaam

authname=gebruikersnaam

fromuser=gebruikersnaam

host=sip.provider.nl

context=inkomend

qualify=300

insecure=invite

dtmfmode=rfc2833

disallow=all

allow=alaw

allow=ulaw

allow=gsm

Ik heb dezelfde trunk nog een keer aangemaakt, maar dan natuurlijk voor de context uitgaand. Een context is gewoon een groep, waar een SIP-account (of trunk) bij hoort. Om eerdergenoemde veiligheidsredenen is het beter om verschillende zaken en afdelingen zoveel mogelijk uit elkaar te trekken in verschillende contexten. Op die manier kun je per context precies instellen wat wel en niet mag. Zo hoeft een toestel in een vergaderruimte echt niet naar het buitenland te bellen.

SIP-accounts

Dan moeten er natuurlijk accounts aangemaakt worden voor alle toestellen. Zo’n account ziet er als volgt uit.

[systeembeheer.01]

type=friend

defaultuser=systeembeheer.01

callerid=”Marinus ten Napel” <123>

host=dynamic

secret=supergeheim

context=systeembeheer

dtmfmode=rfc2833

callgroup=9

pickupgroup=7,8,9

In veel voorbeelden zul je zien dat als accountnaam het nummer gebruikt wordt. Uit veiligheidsoverweging wordt echter afgeraden om dat te doen. Want dat is precies wat de meeste bots zullen proberen om op jouw centrale in te loggen. Het nummer en de accountnaam voor het SIP-account zijn ook twee totaal verschillende dingen. Het uiteindelijke nummer wordt in het dialplan bepaald.

Het dialplan

Het dialplan is het kloppend hart van Asterisk. Hier wordt namelijk bepaald hoe alle telefoontjes afgehandeld worden. De syntax komt eerst een beetje stroef over, maar het went snel en geeft veel mogelijkheden. In de nieuwste versies van Asterisk is het zelfs mogelijk om aparte functies te schrijven met de applicatie GoSub(), die een input verwerkt en dan een waarde teruggeeft. Ik gebruik dit bijvoorbeeld om te bepalen welke callerid meegestuurd moet worden met uitgaande gesprekken.

Contexten

Inkomende gesprekken worden altijd afgehandeld binnen dezelfde context. Inkomend wil zeggen: er komt een gesprek binnen bij Asterisk, dat afgehandeld moet worden. Dus als Jan wil bellen naar Piet, dan is de oproep van Jan een inkomend gesprek. Het hele systeem van verschillende contexten kan, zeker in het begin, wat verwarring geven. Want hoe kan iemand uit de context administratie nu iemand bellen die in de context verkoop zit? De realiteit is dat dit (in de meeste gevallen) dan ook helemaal niet zal gebeuren.

 Ik ben begonnen om een aparte context te maken, waar alle interne nummers inzitten. Een voorbeeld van de interne nummers ziet er zo uit.

[intern]

exten => 101,1,NoOp()

same => n,GotoIf($[“${SIPPEER(gbu.balie.01,curcalls)}” > “0”]?intern,bezet,1)

same => n,Dial(SIP/gbu.balie.01,30,kKtT)

same => n,Hangup()

exten => bezet,1,NoOp()

same => n,Busy(1)

same => n,Hangup()

•De eerste regel is de naam van de context.

•De tweede regel geeft aan dat het om nummer 101 gaat en priority 1. NoOp() is een zogenaamde applicatie. In dit geval een applicatie die helemaal niets doet, simpelweg om de regel correct af te sluiten en het geheel visueel overzichtelijker te maken.

•De derde regel kijkt of het toestel bezet is (current calls > 0). Zo ja, dan springt het naar de context intern. Hier kan dus een context verlaten worden, maar in dit geval blijft het dialplan in dezelfde context. Dan zoekt Asterisk naar de tag bezet en vervolgt daar het dialplan bij priority 1. Zo niet, dan gaat Asterisk gewoon verder met de volgende regel.

•De vierde regel belt het betreffende toestel met een time-out van 30 seconden. Verloopt die time-out, dan gaat Asterisk verder naar de vijfde regel en wordt opgehangen. Dat betekent dat het proces wordt afgebroken en Asterisk niet verder gaat met het dialplan.

•Het stukje bezet doet niets anders dan de bezettoon laten horen, zodat de beller weet dat de betreffende persoon in gesprek is en hangt dan ook op.

De uiteindelijke verdeling in verschillende contexten komt er dan zo uit te zien.

[verkoop]

include => intern

[administratie]

include => intern

Etc.

De included context is altijd ondergeschikt aan de context waar die included wordt. In sip.conf wordt per account aangegeven bij welke context die hoort. Op deze manier worden de interne nummers dus per context hergebruikt en blijft elke afdeling in de eigen context, terwijl toch het hele bedrijf intern gebeld kan worden.

Vrijheid

De kracht en de mogelijkheden van Asterisk zijn bijna eindeloos. Zo hebben we het nog niet eens gehad over queues, wachtmuziek, keuzemenu’s, encryptie, signaling, BLF en noem maar op.

 Het is ook mogelijk om zogenaamde operator panel software aan te schaffen, dat gebruikt kan worden door de telefonistes. Zelf hebben we FOP2 aangeschaft om een overzicht van alle toestellen weer te geven, zodat onze balie snel kan zien of iemand in gesprek is. Wie er de moeite voor wil nemen: deze software kan nog veel meer.

 Het is werkelijk een verademing om met een open systeem als Asterisk te werken. Vrijwel elk verzoek heb ik tot nog toe kunnen waarmaken. Iets wat ik in de oude situatie wel kon vergeten. Daarbij word ik ook niet beperkt door een GUI. Ik kan naar hartenlust het dialplan aanpassen naar eigen wens. Wijzigingen en aanpassingen kan ik ook allemaal zelf doorvoeren, net als het aanmaken van extra accounts.

Probleemloos?

Is de overstap dan helemaal zonder problemen gegaan? Nou nee, er waren natuurlijk wel wat overgangsproblemen. Dat was te verwachten en was dus ook ingecalculeerd. Ik heb het meesturen van de verkeerde callerid al genoemd, maar we hebben ook heel even problemen gehad met het geluid. Dat bleek te komen, omdat externe telefoons niet overweg konden met de gekozen audio codec. Verder kregen we na een aanpassing in de queue te maken met een crashende Asterisk. Dat bleek te komen door een bug in de SIP-driver, die met Ubuntu werd meegeleverd.

 Afgezien van deze problemen is de overgang eigenlijk boven verwachting soepel verlopen en is het hele bedrijf erg blij met de nieuwe toestellen en de uitgebreide mogelijkheden van de nieuwe centrale.

 Enkele thuiswerkers zijn ook allemaal van een SIP-toestel voorzien, die via een versleutelde verbinding ook is aangemeld bij Asterisk. Daardoor konden extra abonnementen opgezegd worden en verlopen die gesprekken voortaan ook intern en dus gratis.

 De maandelijkse telefoonrekening is aanzienlijk gezakt en levert ons een gigantische kostenbesparing op. De investering in nieuwe apparatuur (VoIP-toestellen, POE-switches en nieuwe bekabeling) hebben we dus snel terugverdiend. De ongekende flexibiliteit van onze nieuwe telefonie is een welkome aanvulling op ons bedrijf.

Conclusie

Je verdiepen in Asterisk is zeker de moeite waard. Het kan niet alleen een flinke besparing opleveren, maar het geeft je ook ontzettend veel vrijheid, zelfbeschikking  en nieuwe mogelijkheden. Bovendien is het gewoon ontzettend leuk!