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:
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 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:
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.
A regular VoIP service
Requires a DID number to receive calls from outside of your network
A base number for the enterprise customer; Lists all extra numbers (aliases)
Configures the rest of customer subscribers in its self-care web interface
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
Forwards incoming calls to multiple extensions
Ringing policy defines in which order the extensions will ring
Dynamically registers a remote IP PBX device
Handles multiple users behind the IP PBX device
IP authentication of legacy IP PBX devices incapable of registering with the platform
Might require Trusted Subscriber and Trusted Source configuration
Regular subscriber with prepaid billing profile
Authorization of services based on customer balance; Disconnection of calls on “zero balance”
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:
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.