A contact contains information such as the name, the postal and email addresses, and others. A contact’s main purpose is to identify entities (resellers, customers, peers and subscribers) it is associated with.
A person or an organization may represent a few entities and it is handy to create a corresponding organization’s contact beforehand and use it repeatedly when creating new entities. In this case we suggest populating the External # field to distinguish between customers associated with the same contact.
 |
Note that the only required contact field is email. For contacts associated with customers, it will be used for sending invoices and notifications such as password reset, new subscriber creation and others. A contact for a subscriber is created automatically but only if you specify an email address for this subscriber. It is mainly used to send notification messages, e.g. in case of a password reset.
The reseller model allows you to expand your presence in the market by including virtual operators in the sales chain. A virtual operator can be a company without its own VoIP platform and even without a technical background, but with sales presence in a market. You define such a company as a reseller in the platform: grant limited access to the administrative web interface (the reseller administrator will only see his own customers, domains and billing profiles) and define wholesale rates for this reseller. Then, the reseller is free to operate under its own brand, make up its retail rates, establish the customer base and resell your services to its customers. The reseller’s profit is a margin between the wholesale and retail rates.
Let us consider an example:
- You operate in Munich and provide residential and business services.
- A company Cheap Call that has a strong presence in Frankfurt offers to resell your services under its own brand in this city.
- You define wholesale rates for Cheap Call, such as calls to Argentina at €0,03.
- Cheap Call defines its retail price and offers calls to Argentina at €0,04.
- When one of Cheap Call’s subscribers makes a 5-minute call to Argentina, this subscriber will be charged €0,20.
- You will get €0,15 revenue and Cheap Call’s profit will be €0,20 − €0,15 = €0,05.
 |
A reseller usually uses dedicated IP addresses or SIP domain names to provide services. Also, a reseller can rebrand the self-care web interface for its customers and select languages per SIP domain that allows the reseller to operate even in multiple countries.
A SIP domain represents an external Internet address where your subscribers register their SIP phones to make calls or send messages. The SIP domain also contains particular default configuration for all the subscribers registered with this SIP domain. A SIP domain can be a regular FQDN (e.g. sip.yourdomain.com) or a NAPTR/SRV record. Using IP addresses for SIP domains in production is strongly discouraged.
You can create as many SIP domains as required to satisfy your networking or marketing requirements, e.g.:
- A dedicated SIP domain is suggested per CloudPBX customer.
- A separate SIP domain may be dedicated to every whitelabel reseller.
- Multiple SIP domains may be used to provide services in different countries or regions.
- Multiple SIP domains may be used to brand your own services.
 |
A contract is a combination of a contact and a billing profile, hence it represents a business contract for your resellers and peering partners.
Contracts can be created in advance on the Reseller and Peering Contracts page, or immediately during creation of a peer or a reseller.
 |
Note that the customer entity (described below) is a special type of the contract. A customer entity has an email and an invoice templates in addition to a contact and a billing profile.
A customer is a physical or legal entity whom you provide the VoIP service with and send invoices to. Here are the main features of a customer:
- Contains the contact and legal information. For example, an address or an email address for invoicing.
- Associated with a billing profile (to define fees per destination) and tracks the balance (used mostly for post-paid customers).
- Contains a certain number of subscribers who actually use the service and whose calls appear in the customer’s list of CDRs.
- Provides some default parameters for all its subscribers. For example, voice prompts and call restriction.
Here are two common examples of the customer model:
With this service you provide your residential and SOHO customers with one or multiple numbers and offer the service on a post-paid basis.
For a residential customer you usually create one customer entity with one subscriber under it. A residential customer can register multiple devices with the same number thus having a convenient Viber or Skype-like service: any device can be used to make a call and all of them will ring simultaneously when there is an incoming call. At the end of the billing period, you send an invoice to the customer.
 |
For SOHO customers you usually create multiple subscribers under the same customer and assign every subscriber a dedicated number to allow users make and receive calls. A common invoice will contain calls of all the subscribers.
 |
In this case you create a Customer and all the required entities under it to reflect the company’s structure: subscribers, extensions, hunt groups, auto-attendant menus, etc.
 |
If a customer PBX can register itself with C5, you create a regular subscriber for it and configure a standard username/password authentication. Multiple PBX users can then send and receive calls.
 |
Legacy PBX devices that are not capable of passing the challenge-based authentication can be authenticated by the IP address. Optionally, every user of such a PBX can be authenticated separately by the FROM header and the IP address. For more details, refer to the Trusted Sources section.
The pre-paid model works perfectly for mobile application users. In this case you generally create a single subscriber under a customer.
In this case you will most likely create a single subscriber under a customer, although multiple subscribers would work as well. In the latter case, they will share and top-up the common balance. Notice that the customer entity itself does not contain any technical configuration for the VoIP service authentication and instead contains other entities called subscribers, which do.
Every subscriber represents a SIP line or a SIP trunk. For example, in the residential services a subscriber entity is dedicated to every user. In the SIP trunking scenario, a subscriber can be used to authenticate all VoIP traffic from the remote PBX device.
In the following table logical subscriber types and their purpose are described.
| Service | Subscriber Type | Purpose | Features |
|---|---|---|---|
Residential | Regular subscriber | A regular VoIP service | Requires a DID number to receive calls from outside of your network |
Enterprise (CloudPBX) | Pilot subscriber | A base number for the enterprise customer; Lists all extra numbers (aliases) | Configures the rest of customer subscribers in its self-care web interface |
Extension | Extra numbers (DIDs, “implicit” extensions) for the enterprise customer | Can be dialed in different ways; The number configuration builds on top of the Pilot subscriber | |
PBX Group | Forwards incoming calls to multiple extensions | Ringing policy defines in which order the extensions will ring | |
SIP Trunk | Digest authentication | Dynamically registers a remote IP PBX device | Handles multiple users behind the IP PBX device |
IP authentication | IP authentication of legacy IP PBX devices incapable of registering with the platform | Might require Trusted Subscriber and Trusted Source configuration | |
Prepaid | Regular subscriber with prepaid billing profile | Authorization of services based on customer balance; Disconnection of calls on “zero balance” |
| tip | |
Subscriber Aliases can provide Extra DIDs or extension numbers to a subscriber. |
A SIP peering is your interconnection with the external VoIP or PSTN network. Usually, a VoIP service provider has at least a few termination partners to offer its subscribers calls to virtually any landline and mobile destination.
SIP peerings also enable incoming calls to your platform. For example, if you rent a pool of DID numbers from a SIP peer and offer them to your residential and business customers.
An interconnection with your termination partners and DID number providers can include multiple servers and enable both outbound and inbound calls, hence such a configuration is called a SIP peering group. You configure at least one SIP peering group for every partner and the main principle here is that all servers in a group terminate calls to the same set of listed destinations.
Any SIP peering group is associated with a contract for reconciliation and billing purposes and includes two main technical configurations:
- Peering Servers Represent connections to/from your SIP peering’s network. The parameters include an IP address and/or a hostname of the remote part. For outbound calls, this is the destination address where to send calls to and for inbound calls it is an IP authorization of the remote server.
- Outbound/Inbound Peering Rules Outbound rules define through which SIP peering group a call from a specific subscriber will be sent for termination to a specific destination.
The example below shows four SIP peering groups with different priorities, callee prefixes (actual destinations offered by this SIP peering) and callee / called patterns (fine-tuning which callee request URIs and caller URIs are allowed through this SIP peering group).
 |
The figure shows how calls from premium subscribers can in the first place be routed through a dedicated SIP peering group unavailable to regular subscribers.
See the Routing Order Selection section for details about call routing.
Inbound rules allow filtering out incoming INVITE requests arriving from the corresponding SIP peering servers.