Een trunk is de grens waar de carrier bepaalt welke gesprekken je apparatuur mag verzenden en ontvangen. Als je een PBX hebt, het bedrijfstelefoonsysteem dat je gesprekken routeert, een session border controller, een contactcenterplatform of een andere SIP-client, dan is de trunk hoe de gesprekken de buitenwereld bereiken en hoe externe gesprekken binnenkomen. Een session border controller is het apparaat dat de rand van een spraaknetwerk bewaakt.
De eerste vraag is meestal of je er überhaupt een nodig hebt, en het antwoord is ja. Wat verschilt is wat je erachter zet.
Heb ik echt een trunk nodig?
Ja. Wat verschilt tussen opstellingen is de client aan jouw kant, niet of er een trunk is.
Elk gesprek van of naar het telefoonnetwerk loopt er doorheen, omdat de trunk de plek is waar het platform beslist of het gesprek überhaupt wordt geaccepteerd. Twee vormen komen veel voor:
- Je hebt een telefoonsysteem. Een PBX, softswitch of contactcenterplatform dat al gesprekken afhandelt en een route naar het publieke netwerk nodig heeft. Het verbindt als peer, meestal vanaf een vast adres, en het eigen kiesplan, de regels die de gesprekken routeren, doet de gespreksbesturing.
- Je hebt applicatiecode. Je wilt dat je software gesprekken plaatst of ontvangt zonder telefonie-infrastructuur te draaien. Je hebt nog steeds een trunk nodig, en wat ermee praat kan klein zijn: een softphone, een browser, de CLI, of een voice-agentruntime. Het authenticeert met een kortlevende sessiecredential, een tijdelijke gebruikersnaam en wachtwoord voor een SIP-client, in plaats van vanaf apparatuur op een bekend adres.
Het verschil draait om waar de gespreksbesturing zit, niet om schaal, en geen van beide vormen slaat de trunk over. Wat een lichte client je bespaart is het draaien van een telefoonsysteem, niet de verbinding zelf. De eigen tooling van Bird maakt het punt dubbel: de telefoon in het dashboard en de testoproep van de CLI zijn allebei SIP-clients die echte gesprekken plaatsen via een van je trunks.
De trunk is ook geen alternatief voor de API, want geen enkel endpoint plaatst een gesprek naar een bestemming die je kiest. Wat is een voice-API behandelt hoe het configurerende deel en het signalingdeel het werk verdelen.
Wat doet een trunk precies?
Het geeft je apparatuur een adres om gesprekken naartoe te sturen, en bepaalt welke gesprekken het accepteert.
Bird wijst elke trunk een vast SIP-domein toe, en dat is wat je invoert in je telefoonsysteem zodat gesprekken aan de trunk gekoppeld kunnen worden. Je apparatuur stuurt naar dat domein via een van drie transporten: UDP of TCP op 5060, of TLS op 5061 als je de signaling versleuteld wilt laten verlopen.
Een nieuwe trunk wijst elk gesprek af. Beide richtingen staan uit, en er is geen afzender geautoriseerd. Dat is een bewuste standaard, niet een onvolledige setup. Een trunk die gesprekken accepteerde op het moment dat hij bestond zou een open uitnodiging zijn, en tollfraude maakt dat snel kostbaar.
Waarom worden outbound en inbound apart geconfigureerd?
Omdat het verschillende problemen zijn met verschillende foutmodi, en een trunk elke richting apart afhandelt.
Outbound is je telefoonsysteem dat gesprekken plaatst via Bird. Totdat je het inschakelt weigert de trunk elke uitgaande poging ongeacht de credentials, dus een correct geauthenticeerd gesprek mislukt alsnog als de richting uitstaat.
Inbound is Bird dat gesprekken aflevert bij je telefoonsysteem voor de nummers die naar de trunk wijzen. Inschakelen alleen is niet genoeg: een trunk met inbound ingeschakeld en geen delivery-gateway weigert elk inkomend gesprek naar zijn nummers. Een nummer naar de trunk laten wijzen doe je op het nummer, niet op de trunk, en dat is de andere helft die mensen missen.
Inbound uitschakelen zet elk nummer dat naar deze trunk wijst terug op reject, en weer inschakelen herstelt ze niet. De trunk verwijderen doet hetzelfde. Het ongedaan maken is dus niet symmetrisch: als je inbound uitschakelt om iets te testen, plan dan in om elk nummer daarna opnieuw toe te wijzen, en controleer de nummers in plaats van aan te nemen dat de schakelaar ze hersteld heeft.
Hoe bepaalt een trunk wie er gesprekken naartoe mag sturen?
Een IP-allowlijst, API-sleutelauthenticatie en sessiecredentials bepalen dat. Ze kunnen gecombineerd worden, en elk wordt actief zodra er één vermelding in staat.
Een IP-allowlijst. Voeg de publieke adressen toe waarvandaan je apparatuur naar SIP stuurt. Filtering begint op het moment dat de lijst één vermelding heeft, en vanaf dan mogen alleen vermelde bereiken gesprekken sturen. Voor apparatuur achter NAT is dit het publieke adres van de router, niet het privéadres van het telefoonsysteem. Gesprekken van niet-vermelde adressen worden geweigerd op de SIP-laag en bereiken meestal nooit het gesprekslogboek. Een leeg logboek is daarom een symptoom hiervan, niet bewijs dat er niets geprobeerd is.
API-sleutelauthenticatie. Bird daagt het gesprek uit, en je systeem antwoordt met een hash van een wachtwoord in plaats van het wachtwoord zelf. De hash wordt geverifieerd tegen een Bird API-sleutel die spraaktoegang op schrijfniveau heeft. In je PBX is de gebruikersnaam altijd bird en het wachtwoord is het geheim van de sleutel. Net als de IP-lijst wordt het exclusief zodra er één sleutel is toegestaan.
Twee operationele details volgen daaruit. De spraakpermissie van een sleutel verwijderen stopt de authenticatie onmiddellijk. De sleutel blijft in de allowlijst van de trunk staan, gemarkeerd, zodat de lijst nooit als werkend leest terwijl dat niet zo is. De permissie terugzetten herstelt het zonder iets te hoeven wijzigen. Een sleutel intrekken of verwijderen werkt onmiddellijk op elke trunk die hem toestond, en het is permanent. Roteer door eerst de nieuwe sleutel aan de trunk toe te voegen, dan je apparatuur over te zetten, en de oude sleutel als laatste in te trekken.
Sessiecredentials. Een kortlevende SIP-gebruikersnaam en -wachtwoord die dezelfde challenge beantwoorden zonder een langlevend geheim bloot te stellen. Ze staan uit op een nieuwe trunk, en ze horen bij de werkruimte in plaats van bij één trunk. Het wachtwoord wordt alleen teruggegeven op het moment dat het aangemaakt wordt.
Sessiecredentials inschakelen verandert niets aan hoe apparatuur op de allowlijst verbindt. Een gesprek van een vermeld adres op een trunk zonder toegestane API-sleutels wordt nog steeds toegelaten zonder wachtwoordchallenge. Als je bedoelde dat de credential de poort zou zijn, is de IP-lijst stilletjes nog steeds de poort.
Waarom kan mijn browser of softphone niet authenticeren?
Bijna altijd het digest-algoritme. Het is de enige instelling die faalt op een manier die eruitziet als een credentialprobleem.
Standaard biedt Bird eerst SHA-256 aan en daarna MD5, en je apparatuur antwoordt met het eerste dat het ondersteunt. Een trunk accepteert alleen de algoritmen die het aanbiedt, dus het aanbod beperken beperkt wat er kan verbinden.
De valkuil is browsers: een browser antwoordt met MD5 en niets anders. Een trunk die alleen SHA-256 aanbiedt, weigert elk browsergesprek, inclusief de eigen telefoon van het dashboard. Houd MD5 dus in het aanbod op elke trunk waarvandaan je vanuit een browser wilt bellen, en kies pas voor alleen-MD5 wanneer een PBX een challenge die begint met SHA-256 verkeerd afhandelt. API-sleutels werken met beide algoritmen en hoeven nooit opnieuw uitgegeven te worden als je het aanbod wijzigt.
Wat stel ik dan in?
- Een trunk, welke vorm je ook hebt. Elk gesprek loopt er doorheen, dus deze stap is niet optioneel.
- Een peer, als je een telefoonsysteem draait. Verbind de PBX of het contactcenterplatform vanaf een vast adres, en laat het eigen kiesplan de gesprekken besturen.
- Een lichte client, als je applicatiecode hebt. Een softphone, een browser, de CLI of een agentruntime, authenticerend met een kortlevende sessiecredential in plaats van een bekend adres.
- Eén afzenderregel, welke je ook kiest. Een IP-allowlijst, een toegestane API-sleutel of een sessiecredential, en onthoud dat elk exclusief wordt zodra er één vermelding in staat.
- MD5 in het digest-aanbod laten staan op elke trunk waarvandaan je vanuit een browser wilt bellen.
SIP-trunks behandelt elke instelling en waar je die vindt. SIP-clients behandelt het verbinden van een enkele client in plaats van een telefoonsysteem, en voice-probleemoplossing helpt bij gesprekken die niet aankomen.
Kort gezegd
Elk pad naar het telefoonnetwerk loopt via een trunk.
Het verschil zit in de client aan jouw kant: een telefoonsysteem verbonden als peer, of een lichtere SIP-client zoals een browser of de CLI op een kortlevende credential.
Een nieuwe trunk weigert alles.
Beide richtingen staan uit, en er is geen geautoriseerde afzender totdat je er een toevoegt. Dat is bewust, niet een instapstap die je kunt overslaan.
Elke richting wordt apart ingeschakeld, en inbound heeft een gateway nodig.
Een trunk met inbound ingeschakeld maar zonder delivery-gateway weigert elk inkomend gesprek naar zijn nummers.
Inbound uitschakelen is niet schoon ongedaan te maken.
Elk nummer dat naar de trunk wijst gaat terug naar reject, en inbound weer inschakelen herstelt ze niet. Wijs elk nummer zelf opnieuw toe.