PortaSIP enables you to provide a set of telephony services to enterprise customers by configuring the virtual Private Branch Exchange (PBX) environment and offering it as a service.
The PBX is called virtual (cloud PBX) because customers don’t use any on-premises equipment and it’s all hosted in your PortaSwitch.
Users of the hosted PBX aka cloud PBX service normally employ a dedicated vocabulary and operate with a very specific set of concepts, such as “extension”, “hunt group” or “phone line”. The following table explains the mapping between PBX elements and PortaBilling entities.
PBX Concept or Entity |
Entity in PortaBilling |
Description |
---|---|---|
Hosted PBX (also hosted PBX tenant) or cloud PBX environment |
Customer |
A customer object in PortaBilling represents a company or an individual who uses services on one or more phone lines. The customer pays for all the usage. Each customer has his own individual configuration for the hosted PBX service; e.g., a customer can have his own dialing plan, or use any extension number (even if another customer already uses the same extension). |
Phone line |
Account |
A phone line represents the actual IP phone (or an individual line on a multi-line IP phone). |
Phone number |
Account ID |
An account ID is the unique identifier of a phone line across the whole network (not just an individual cloud PBX environment), and so contains the phone number allocated to this phone line. |
DID |
Alias/Account |
DID is a phone number that allows a phone line to be reached directly. Thus you can either add that number as an alias to an existing account or create a new account and assign this phone number as an account ID. |
Extension |
Extension |
A short dialing code assigned to a particular phone line. An extension only exists in the context of a specific cloud PBX environment; e.g., any user in your organization can use the extension 101 to reach you, but if another customer (even one using the same PortaSwitch system) dials 101 – nothing happens. |
Extension list |
A table with mapping between extensions and accounts |
Defined in the customer information. |
Hunt group |
Hunt group |
A way of distributing an incoming call to multiple extensions according to predefined rules. Each hunt group has its own dialing code (e.g., 301). |
Main line (main phone number) |
Account, the main phone number is assigned to this account as an account ID |
This account is either provisioned on the secretary’s phone (so he/she can answer all incoming calls) or has auto attendant configured so that incoming calls are automatically forwarded to the Media Server IVR, where the auto attendant is launched. |
Intra-PBX call presentation
Since people normally use short extension codes to dial their colleagues, these are the numbers that they remember well. So for calls within the same cloud PBX environment, extension numbers should be visible in the call history. On the other hand, if a call is forwarded outside the cloud PBX, the full phone number should be presented. Therefore, call detail presentation is done differently based on context. Let’s look at several use cases.
A call between two extensions
Mary Smith (extension 102) dials 303 to reach her colleague Joe Brown. When she (or the customer, or the administrator of the cloud PBX environment) sees the xDR, it says:
CLI |
CLD |
---|---|
102 (Mary Smith) |
303 (Joe Brown) |
The same information is displayed in the incoming xDRs for this call (those viewed by Joe Brown).
Calling a hunt group
Joe Brown (303) dials 200 (hunt group) to reach Sales. The xDR then shows the hunt group number as the CLD:
CLI |
CLD |
---|---|
303 (John Brown) |
200 (Sales) |
Using abbreviated dialing for an external number
Mary Smith (102) dials 401 (abbreviated dialing) to reach her partner (16045558915). The displayed CLD contains the latter’s full number, as the callee is outside the PBX environment:
CLI |
CLD |
---|---|
102 (Mary Smith) |
16045558915 |