Before we begin, here is some general terminology that is important for understanding this article.
|Carrier||A carrier (telecom company, mobile network operator (MNO), aggregator etc) who offers routes to/from the Public Switched Telephone Network (PSTN). E.g. AT&T, Verizon|
|BYOC User||An individual or organization who has a business relationship with a carrier. BYOC stands for Bring Your Own Carrier.|
This documentation is intended for both Carriers and BYOC users as defined above.
Somleng is an Open Source, white-labeled, Cloud Communications Platform as a Service (CPaaS), featuring programmable voice and SMS.
There are two kinds of use-cases depending on whether you're a Carrier or BYOC user.
We recommend you try out Somleng by signing up for a carrier account here . If you're looking to install Somleng on your local machine read the Getting Started Guide . Note that this requires some technical knowledge.
Once you have a carrier account you can begin configuring your account to handle programmable voice and SMS.
The dashboard can be used to manually provision carrier resources. Use the Carrier API to automate the provisioning of carrier resources.
You must sign into the dashboard to use Somleng. The first time you sign in you will be required to setup two factor authentication (2FA). We recommend you use Authy , Google Authenticator or your password manager to setup 2FA.
Here you will find general settings for the carrier.
From the settings page you'll see your company's name, country, logo and Carrier API Key.
You can update the name of your company, country and company logo. The logo and name of your company is used to provide custom branding for your dashboard.
You can also configure webhooks by specifying a webhook URL. Once a Webhook URL has been configured you'll see Webhook signing secret on the settings page. You'll need the signing secret when verifying webhooks .
To update your carrier settings:
Accounts are used by carriers, carrier customers and BYOC users to send/receive calls and SMS via Somleng's implementation of Twilio's REST API.
Typically a carrier would create an account for each of their customers. BYOC users might create an account for each project or just create one account for their usage.
There are two types of accounts. Carrier managed and customer managed.
Carrier managed accounts are managed by carriers. These types of accounts are used by carriers themselves, or by the carrier's individual customers. Carrier managed accounts do not allow customer access. The Account SID and Auth token, which are required to access the Twilio REST API, are accessible by the carrier only and are displayed on the Account's page.
Customer managed accounts are managed by carrier customers directly. These types of accounts can be created via the dashboard by specifying an account owner when creating the account. After providing the account owner's name and email address, the owner will be invited to the dashboard and can manage their account by themselves. The customer will have access to their Account SID and Auth Token and this info will no longer be displayed on the Account's page. The carrier can disable and enable individual customer accounts from the Dashboard.
To create an account via the Dashboard:
Inbound SIP Trunks are used to configure inbound dialing to Somleng (aka Direct Inbound Dialing). When you create an Inbound SIP Trunk you specify the source IP address from which SIP invite is sent from. Somleng uses this information to determine the carrier, account and how to handle the call.
Once you have setup your inbound SIP trunk, you can then send SIP to any of the following endpoints. We recommend that you use sip.somleng.org for high-availability.
To create an inbound SIP trunk via the Dashboard:
Outbound SIP Trunks are used to configure outbound dialing from Somleng. When you create an Outbound SIP Trunk you specify the destination host to send outbound calls. You can specify your host as either a fully qualified domain name (FQDN) or IP address. The outbound SIP trunk configuration determines the dial string that will be used to send calls to your SIP server.
SIP and RTP from Somleng sent through a NAT Gateway from the IP address below. You should allow this IP address on your firewall. You may also need to setup Symmetric Latching on your device.
To create an outbound SIP trunk via the Dashboard:
Phone Numbers represent direct inbound dialing (DID) numbers. A phone number can be either an E.164 formatted phone number or a short code. When you create a phone number you can optionally assign it to an account.
Once provisioned and assigned to an account, phone numbers can be configured with a Voice URL which returns TwiML for controlling the call. This can either be done by the carrier or by the account owner (for customer managed accounts).
To create a phone number via the Dashboard:
Once the phone number has been created you can configure it. To configure a phone number via the Dashboard:
In order to bulk import phone numbers, you can upload a CSV file from the Dashboard.
|Column Header||Content||Possible Values||Example|
|Number||The phone number or short code||E.164 formatted number or short code. e.g. 85512345678 or 1234||1234|
|Enabled||Whether to enable or disable the phone number||
Number,Enabled 1234,false 85512345678,true
Carrier owners can invite their colleagues to the dashboard.
To invite a user to the Dashboard:
The user will receive an email inviting them to the dashboard. Users with the owner role can manage other users, update their role and reset their 2FA.
SIP and RTP from Somleng is sent through a NAT Gateway. This means that the ports specified in the SDP in the SIP Invite from Somleng are unreachable which normally causes one-way audio issues. To work-around this problem, it is required that you setup Symmetric Latching on your device.
Symmetric RTP means that the IP address and port pair used by an outbound RTP flow is reused for the inbound flow. The IP address and port are learned when the initial RTP flow is received on your device. The flow's source address and port are latched onto and used as the destination for the RTP sourced by the other side of the call. The IP address and port in the c line and m line respectively in the SDP message are ignored.
If your device does not support symmetric latching we can configure your account to use a symmetric NAT. Currently this option is not configurable on the dashboard. Please contact us for assistance.