Trunk adalah batas tempat operator memutuskan panggilan mana yang boleh dikirim dan diterima perangkat Anda. Jika Anda memiliki PBX, sistem telepon bisnis yang merutekan panggilan Anda, session border controller, platform contact center, atau klien SIP lainnya, trunk adalah cara panggilannya mencapai dunia luar dan cara panggilan luar mencapainya. Session border controller adalah perangkat yang menjaga tepi jaringan suara.
Pertanyaan pertama biasanya apakah Anda memerlukan trunk sama sekali, dan jawabannya ya. Yang berbeda adalah apa yang Anda tempatkan di belakangnya.
Apakah saya benar-benar memerlukan trunk?
Ya. Yang berbeda antarsetup adalah klien di sisi Anda, bukan ada tidaknya trunk.
Setiap panggilan ke atau dari jaringan telepon melewati trunk, karena trunk adalah tempat platform memutuskan apakah panggilan diterima atau tidak. Dua bentuk umum:
- Anda memiliki sistem telepon. PBX, softswitch, atau platform contact center yang sudah menangani panggilan dan memerlukan rute ke jaringan publik. Sistem ini terhubung sebagai peer, biasanya dari alamat tetap, dan dial plan-nya sendiri, aturan yang merutekan panggilannya, mengendalikan panggilan.
- Anda memiliki kode aplikasi. Anda ingin perangkat lunak Anda melakukan atau menerima panggilan tanpa menjalankan infrastruktur telefoni. Anda tetap memerlukan trunk, dan yang berkomunikasi dengannya bisa kecil: softphone, browser, CLI, atau runtime voice agent. Ia melakukan autentikasi dengan kredensial sesi sementara, username dan password temporer untuk klien SIP, bukan dari perangkat di alamat yang diketahui.
Perbedaannya adalah di mana kendali panggilan berada, bukan soal skala, dan tidak ada bentuk yang melewatkan trunk. Yang dihemat klien ringan adalah menjalankan sistem telepon, bukan koneksinya sendiri. Tooling Bird sendiri membuktikannya dua kali: telepon di dashboard dan test call CLI keduanya adalah klien SIP yang melakukan panggilan nyata melalui salah satu trunk Anda.
Trunk juga bukan alternatif dari API, karena tidak ada endpoint yang melakukan panggilan ke tujuan yang Anda pilih. Apa itu voice API membahas bagaimana bagian konfigurasi dan bagian sinyal membagi pekerjaan.
Apa yang sebenarnya dilakukan trunk?
Trunk memberi perangkat Anda alamat untuk mengirim panggilan, dan memutuskan panggilan mana yang akan diterimanya.
Bird menetapkan domain SIP tetap untuk setiap trunk, yang Anda masukkan di sistem telepon agar panggilan dapat dikaitkan dengan trunk tersebut. Perangkat Anda mengirim ke domain itu melalui salah satu dari tiga transport: UDP atau TCP pada 5060, atau TLS pada 5061 jika Anda ingin sinyal dienkripsi saat transit.
Trunk baru menolak setiap panggilan. Kedua arah nonaktif, dan tidak ada pengirim yang diotorisasi. Ini adalah default yang disengaja, bukan pengaturan yang belum lengkap. Trunk yang langsung menerima panggilan begitu dibuat akan menjadi undangan terbuka, dan toll fraud membuat itu cepat mahal.
Mengapa outbound dan inbound dikonfigurasi terpisah?
Karena keduanya adalah masalah yang berbeda dengan mode kegagalan yang berbeda, dan trunk membawa setiap arah secara terpisah.
Outbound adalah sistem telepon Anda melakukan panggilan melalui Bird. Sampai Anda mengaktifkannya, trunk menolak setiap percobaan outbound tanpa memandang kredensial, jadi panggilan yang terautentikasi dengan benar tetap gagal jika arahnya nonaktif.
Inbound adalah Bird mengirim panggilan ke sistem telepon Anda untuk nomor-nomor yang mengarah ke trunk. Mengaktifkannya saja tidak cukup: trunk dengan inbound aktif tanpa delivery gateway menolak setiap panggilan masuk ke nomornya. Mengarahkan nomor ke trunk dilakukan pada nomor tersebut, bukan pada trunk, dan ini adalah bagian lain yang sering terlewat.
Menonaktifkan panggilan inbound mengembalikan setiap nomor yang mengarah ke trunk ini ke reject, dan mengaktifkannya kembali tidak memulihkannya. Menghapus trunk melakukan hal yang sama. Jadi pembatalan tidak simetris: jika Anda menonaktifkan inbound untuk menguji sesuatu, rencanakan untuk mengarahkan ulang setiap nomor sesudahnya, dan periksa nomornya daripada berasumsi toggle memulihkannya.
Bagaimana trunk memutuskan siapa yang boleh mengirim panggilan?
IP allow list, autentikasi kunci API, dan kredensial sesi yang menentukannya. Ketiganya bisa dikombinasikan, dan masing-masing aktif begitu memiliki satu entri.
IP allow list. Tambahkan alamat publik yang digunakan perangkat Anda mengirim ke SIP. Pemfilteran dimulai begitu daftar memiliki satu entri, dan sejak itu hanya rentang yang terdaftar yang boleh mengirim panggilan. Untuk perangkat di belakang NAT, ini adalah alamat publik router, bukan alamat privat sistem telepon. Panggilan dari alamat yang tidak terdaftar ditolak di lapisan SIP dan biasanya tidak pernah muncul di call log. Log yang kosong karena itu adalah gejala dari hal ini, bukan bukti bahwa tidak ada yang dicoba.
Autentikasi kunci API. Bird menantang panggilan, dan sistem Anda menjawab dengan hash dari password, bukan password itu sendiri. Hash diverifikasi terhadap kunci Bird API yang memiliki akses voice di level write. Di PBX Anda, username selalu bird dan password-nya adalah secret dari kunci tersebut. Seperti IP list, autentikasi ini menjadi eksklusif begitu satu kunci diizinkan.
Dua detail operasional mengikuti dari situ. Mencabut izin voice dari kunci langsung menghentikan autentikasinya. Kunci tetap ada di daftar trunk yang diizinkan, ditandai, sehingga daftar tidak pernah terlihat berfungsi padahal tidak. Mengembalikan izin memulihkannya tanpa perubahan apa pun. Mencabut atau menghapus kunci berlaku langsung di setiap trunk yang mengizinkannya, dan bersifat permanen. Rotasi dilakukan dengan menambahkan kunci baru ke trunk terlebih dahulu, memindahkan perangkat Anda, lalu mencabut kunci lama terakhir.
Kredensial sesi. Username dan password SIP sementara yang menjawab tantangan yang sama tanpa mengekspos secret yang berumur panjang. Kredensial ini nonaktif di trunk baru, dan dimiliki oleh workspace, bukan oleh satu trunk. Password hanya dikembalikan saat dibuat.
Mengaktifkan kredensial sesi tidak mengubah cara perangkat yang ada di allow list terhubung. Panggilan dari alamat terdaftar pada trunk tanpa kunci API yang diizinkan tetap diterima tanpa tantangan password sama sekali. Jika Anda bermaksud menjadikan kredensial sebagai gerbang, IP list diam-diam tetap menjadi gerbangnya.
Mengapa browser atau softphone saya gagal melakukan autentikasi?
Hampir selalu karena algoritma digest. Ini adalah satu-satunya pengaturan yang gagal dengan cara yang terlihat seperti masalah kredensial.
Secara default Bird menawarkan SHA-256 lebih dulu dan MD5 kedua, dan perangkat Anda menjawab dengan yang pertama didukungnya. Trunk hanya menerima algoritma yang ditawarkannya, jadi mempersempit penawaran mempersempit apa yang bisa terhubung.
Jebakannya adalah browser: browser menjawab dengan MD5 dan tidak ada yang lain. Trunk yang hanya menawarkan SHA-256 menolak setiap panggilan browser, termasuk telepon bawaan dashboard. Jadi pertahankan MD5 dalam penawaran digest pada trunk mana pun yang akan Anda gunakan untuk menelepon dari browser, dan gunakan MD5-only hanya jika PBX salah menangani tantangan yang dimulai dengan SHA-256. Kunci API berfungsi dengan kedua algoritma dan tidak perlu diterbitkan ulang saat Anda mengubah penawaran.
Jadi apa yang harus saya siapkan?
- Trunk, apa pun bentuk setup Anda. Setiap panggilan melewatinya, jadi langkah ini tidak opsional.
- Peer, jika Anda menjalankan sistem telepon. Hubungkan PBX atau platform contact center dari alamat tetap, dan biarkan dial plan-nya mengendalikan panggilan.
- Klien ringan, jika Anda memiliki kode aplikasi. Softphone, browser, CLI, atau runtime agent, melakukan autentikasi dengan kredensial sesi sementara alih-alih alamat yang diketahui.
- Satu aturan pengirim, apa pun yang Anda pilih. IP allow list, kunci API yang diizinkan, atau kredensial sesi, dengan mengingat bahwa masing-masing menjadi eksklusif begitu memiliki satu entri.
- MD5 tetap ada dalam penawaran digest pada trunk mana pun yang akan Anda gunakan untuk menelepon dari browser.
Trunk SIP membahas setiap pengaturan dan di mana menemukannya. Klien SIP membahas menghubungkan satu klien alih-alih sistem telepon, dan pemecahan masalah voice membantu mengatasi panggilan yang tidak sampai.
Singkatnya
Setiap jalur ke jaringan telepon melewati trunk.
Yang berbeda adalah klien di sisi Anda: sistem telepon yang terhubung sebagai peer, atau klien SIP yang lebih ringan seperti browser atau CLI dengan kredensial sementara.
Trunk baru menolak semuanya.
Kedua arah nonaktif, dan tidak ada pengirim yang diotorisasi sampai Anda menambahkannya. Ini disengaja, bukan langkah pengaturan yang bisa Anda lewati.
Setiap arah diaktifkan terpisah, dan inbound memerlukan gateway.
Trunk dengan inbound aktif tetapi tanpa delivery gateway menolak setiap panggilan masuk ke nomornya.
Menonaktifkan inbound tidak bisa dibatalkan dengan bersih.
Setiap nomor yang mengarah ke trunk kembali ke reject, dan mengaktifkan inbound lagi tidak memulihkannya. Arahkan ulang setiap nomor secara manual.