Mobile PBX solution

In addition to receiving basic calling services, your mobile subscribers can extend their use of a PBX service to their mobile phones.

PBX users are accustomed to calling each other by dialing extension numbers. Your mobile subscribers can continue that practice by dialing short three- or four-digit dial codes on their mobile phones to reach each other.

Customers can also use short dial codes to call external numbers. Your customers can define, for instance, that 1111 is for customer support, etc. This way their frequently used contacts can be easily reached.

Dial codes for external numbers are defined within the abbreviated dialing list. Thus, if a customer defines that 1111 corresponds to 18005550214, when the customer dials it, the IMS CSCF routes the mobile originated call to PortaSIP according to the routing rules defined by the MNO.

PortaSIP authorizes the mobile originated call in PortaBilling and PortaBilling converts dial code 1111 into 18005550214. Then PortaSIP returns this number to the CSCF. The mobile terminated call from the IMS already contains 18005550214 as the destination number. After PortaSIP processes it, the IMS delivers the call to that destination.

You can supplement traditional call forwarding that is supported by your MNO with the follow-me feature. Your subscribers configure their follow-me lists in PortaBilling and then define how the phones in their lists ring when calls are received: simultaneously, randomly or in a defined order.

PortaSIP supports both unconditional and conditional forwarding. During unconditional forwarding, PortaSIP automatically redirects the call so the callee’s phone does not ring. Conditional forwarding means that PortaSIP redirects calls when the callee is busy or unavailable. Charges for call forwarding are applied to the account initiating the call.

To process a forwarded call, PortaSIP appends the History-Info SIP header to the INVITE request in the terminating triggering call. This header stores information about where to forward the call and the reason for forwarding. If someone else has previously forwarded the call, PortaSIP preserves the History-Info SIP header received in the mobile originated call and updates it for the mobile terminated one.

The following example illustrates how call forwarding works. Let’s say John is at a meeting and has defined that all calls be forwarded to his colleague Peter. When Alice calls John, the following occurs:

• The CSCF sends the mobile originated call from Alice’s phone to PortaSIP.
• PortaSIP authorizes Alice’s account for the outgoing call in PortaBilling and routes the call to the CSCF to be terminated to John.
• The CSCF sends the mobile terminated call to PortaSIP.
• PortaSIP authorizes John’s account for the incoming call in PortaBilling. PortaBilling verifies the forwarding configuration for John and provides PortaSIP with instructions to forward the call to Peter.
• PortaSIP generates the History-Info SIP header and adds it to the INVITE request to the CSCF for the mobile terminated call.
• The CSCF delivers the call to Peter’s phone.
• Alice and Peter begin their conversation.

When the call ends, charges are produced and applied as follows:

• Alice is charged for the outgoing call to John.
• John is charged for the incoming call from Alice plus the forwarded call from Alice to Peter.
• Peter is charged for the incoming call from John.

To configure call routing, apply the service policy to your internal vendor’s connection with the out_hdr_history attribute enabled.

Redirect to MNO voicemail

To ensure service continuity for mobile subscribers, you can redirect their calls to your host MNO’s voicemail. To do this, enable the External voicemail service feature within the product configuration and define the application’s entry point. This enables you to preserve their user experience with the voicemail service.

For PortaSIP to process these calls correctly, include the out_hdr_history and append_incoming_headers attributes in the service policy for the outgoing vendor connection that represents IMS CSCFs.

Then when there is an unanswered call to a subscriber, PortaSIP does the following:

• generates a History-Info SIP header with the information necessary to forward the call to voicemail,
• appends it to the INVITE for the mobile terminated call, and
• sends the INVITE to the IMS CSCF.

The CSCF identifies that the call is intended for voicemail and therefore launches that application.

Few MNOs support the ability to transfer calls within IMS networks. In addition, standard phone models do not have transfer options.

You, however, can enable your mobile subscribers to transfer calls to desired destinations from their mobile phones or external applications via the call control API. For example, if Bob has an international call with Tom but must leave for a meeting, he can transfer Tom to Carol to continue the conversation for him.

To make this happen, these conditions must be met:

• Your MNO must have a 4G network and support VoLTE;
• You integrate PortaSIP as a TAS (Telephony Application Server) in the IMS core; and
• You build/extend your external application (e.g., a mobile dialing app, a CRM switchboard, etc.) to communicate with PortaSwitch via the API.

By doing this, you add VoIP features to your mobile service portfolio. Your business customers can directly transfer calls from their mobile phones as if from IP phones. This improves their calling experience.

Customers can transfer calls blindly or without answering them at all. The transfer target can be an on-net destination (e.g., a Mobile PBX extension) or some external number: fixed, mobile, international, etc. The transferred call goes through the IMS core via the ISC interface.

The example below illustrates how call transfer works.

Let’s say Alice and John are your mobile subscribers. Peter is subscribed to another mobile carrier. Since all calls take place within the LTE network, all communication is accomplished via the CSCF.

• Peter calls Alice. (1)
• PortaSIP successfully processes the terminating triggering call to Alice and routes it to the IMS. (2)
• The IMS delivers the call to Alice so she and Peter can talk. (3)
• After a while, Alice transfers the call to John by pressing the Transfer button from her switchboard app.
• The app sends the API request to PortaSwitch to perform a call transfer to John’s phone number.(4)
• PortaSIP verifies that Alice is permitted to make a call transfer in PortaBilling, disconnects Alice’s previous call and initiates her new outgoing call to John.
• PortaSIP sends the call to the IMS (5) which delivers it to John’s phone. (6)
• John answers, and he and Peter start to talk. (7)
• When the call ends, the accounting information is sent to PortaBilling to produce charges for Alice: for the incoming call from Peter plus for the transferred call to John. John is charged for the incoming call from Peter.

The same flow occurs if Alice decides not to answer the call from Peter but to transfer it to John instead. In this case, the switchboard app informs Alice about the incoming call and offers to instantly transfer it.