PortaSIP as the IMS Telephony Application Server

To begin providing mobile services, you do not need to build your own mobile network. Instead, you can become an MVNO (Virtual Mobile Network Operator). Negotiate the network capacity of an existing mobile network operator (MNO) and then integrate PortaSIP with the MNO’s IMS (IP Multimedia Subsystem). This way you can deliver calls to subscribers using the mobile network – without needing to deploy a full network core. This significantly reduces your initial investment.

In IMS, PortaSIP functions as the Telephony Application Server. In order for PortaSIP to receive calls from IMS, the MNO sets up a routing rule. It instructs the IMS core to route calls made by or to your subscribers to PortaSIP. PortaSIP communicates with the IMS core via the SIP protocol.

In the mobile network, the CSCF (Call Session Control Function) is the IMS core component responsible for the signaling part of the call. It performs user authentication, service policy control with PCRF and routing functions.

The functions of PortaSIP as the Application Server include:

• Real-time authorization in PortaBilling;
• Routing to the IMS CSCF for call delivery; and
• Managing user data and service configurations.

Let’s take a closer look at call flow when a mobile subscriber calls another one. As an example, let’s say it’s a VoLTE call, though the call flow is exactly the same for a 3G network. This means you have choices for which network to operate in.

During a VoLTE call services are triggered twice: for the mobile originated and the mobile terminated calls. According to the rules defined by the MNO, the CSCF loops both the mobile originated and the mobile terminated calls through PortaSIP.

So, let’s say Peter and John are your mobile subscribers. When Peter calls John, the following occurs:

• Peter’s phone sends an INVITE request to the CSCF (1).
• The CSCF sends a mobile originated call to PortaSIP (2). This request contains the P-Served-User header with information about which party to bill for the outgoing call (Peter’s account).
• PortaSIP authenticates the call by the P-Served-User header, and authorizes Peter’s account for the outgoing call in PortaBilling.
• Upon successful authorization, PortaSIP routes the call to the CSCF (3).
• The CSCF sends a mobile terminated call to PortaSIP (4).
• PortaSIP performs the same authorization check towards the called party (John) in PortaBilling. Additionally PortaBilling checks the service policy configuration for John’s account.
• PortaBilling identifies that the service policy attribute append_incoming_headers is set to Yes and that the account is not registered on an IP phone. So now PortaSIP routes the call to the CSCF (5).
• The CSCF terminates the call on John’s mobile phone (6).
• Peter and John start to talk.
• When the call is complete, PortaBilling calculates the charges and produces xDRs for both the calling and the called parties.

To enable calls over the LTE network, an administrator must perform the following configuration steps:

1. Configure a call handling rule to authorize calls by the P-Served-User header and define the translation rule for it as Python regular expressions (e.g., to strip the + sign and/or append a suffix to the account ID). The call handling rule applies for calls authenticated by the IP address of the CSCF;
2. Configure the service policy with the append_incoming_headers option set to Yes;
3. Create a virtual vendor that represents the IMS and define the outgoing connection for this vendor. The connection tariff rates must take the highest priority and include the huntstop.
4. Assign the service policy to the connection and the accounts.
5. Configure the product and define the rating list with the ORIGINATE.IMS and INCOMING.IMS access codes for outgoing and incoming calls, respectively.

To make and receive calls over the LTE network, the user accounts must not be registered on IP devices. Otherwise, the account registration will override the service policy settings and PortaSIP will attempt to deliver the call over the VoIP network.

In IMS networks, users must only be alerted about a call once all call parameters have been confirmed. This means that caller A and callee B must negotiate all the call parameters and allocate the necessary network resources for media streaming before B’s phone rings.

To do this, A and B’s phones exchange SIP preconditions while the call is being established. A SIP precondition is a set of constraints about the resources that the caller and callee must meet and agree to. SIP preconditions are communicated in the SDP part of SIP messages.

PortaSIP as the IMS Application Server supports calls with SIP preconditions by:

• Transmitting SIP preconditions between caller and callee; and
• Processing PRACK/UPDATE messages within the SIP dialogue to determine the session establishment’s progress.

Calls with SIP preconditions are possible if:

• Both caller and callee support them;
• The call does not ring on several devices simultaneously (e.g., in case of call forking); and
• The user does not call the IVR application because calls to the IVR require that they be answered prior to playing media.

To enable the support of SIP preconditions, configure the following options for PortaSIP on the Configuration server:

• Set Yes for the allow_precondition and allow_100rel options;
• Set No for the convert_1xx option.

An early dialog is communication between call parties before a call is set up.

In IMS networks, several early dialogs can occur for the same call. These dialogs can appear because of:

• Call forking to several endpoints;
• Announcements played to the caller before a ringback tone;
• Call forwarding upon no answer.

Multiple early dialogs provide early media streams that are played to a caller. IMS equipment, including user phones, uses the P-Early-Media SIP header (RFC 5009) to identify which media stream to play:

• Carrier announcements before a call is set up (e.g., You are calling a premium number. The call cost is $2 per minute);
• Ringback tones from the called party after carrier announcements;
• Ringback tones from a remote party if the call is forwarded upon no answer.

PortaSIP as an IMS TAS supports multiple early dialogues and the P-Early-Media SIP header. PortaSIP resends 183 Session Progress provisional responses from the IMS core to a caller so that their phone can select the correct media stream based on the P-Early-Media value. When a phone receives a new early dialogue with the P-Early-Media sendonly or sendrcv, it plays media from this source.

The examples below illustrate how calls with multiple early dialogs are established and processed. Since these are calls among mobile subscribers, all communication is accomplished via the CSCF.

Let’s say Alice calls Bob, who has his call forwarding configured to go to Carol, and PortaSIP successfully processes the originating triggering call from Alice.

1. PortaSIP receives the terminating triggering call to Bob.
2. Upon successful authorization, PortaSIP checks for Bob’s account and then routes the call to the CSCF.
3. PortaSIP receives a 183 Session Progress provisional response from Bob’s phone. This creates early dialogue 1.
4. There is the P-Early-Media:sendonly SIP header and early media in scope of dialog 1. PortaSIP resends this message and relays the early media to Alice so that Alice hears the ringback tone.
5. PortaSIP receives another 183 Session Progress provisional response with the P-Early-Media:sendonly. This creates early dialogue 2.
6. PortaSIP sends this message to Alice. Alice’s phone plays ringback tone from early dialog 2.
7. Bob does not answer his phone, thus the call is forwarded to Carol.
8. PortaSIP receives the next 183 Session Progress provisional response with the P-Early-Media:sendonly from Carol’s phone. This creates early dialogue 3.
9. PortaSIP sends early dialog 3 to Alice and now she hears the ringback tone provided in early dialog 3.
10. Carol answers and their phone conversation begins.When the call ends, PortaBilling produces the following xDRs:
    • For Alice, for the outgoing call to Bob.
    • For Bob, for the incoming call from Alice, plus for a forwarded call from Alice to Carol.

Example 2. The called party is busy

John calls Peter who is already talking on the phone. Since the processing flow for the originating triggering call from John is pretty much the same as for the example above, it is omitted here.

1. PortaSIP receives the terminating triggering call to Peter, authorizes it in PortaBilling and then routes it to the CSCF.
2. PortaSIP receives a 183 Session Progress provisional response. It includes the P-Early-Media:sendonly SIP header and a media stream. Early dialog 1 is created.
3. PortaSIP resends the response to John. John hears, “the number is busy, please wait.”
4. PortaSIP receives another 183 Session Progress provisional response from Peter’s phone with the P-Early-Media:sendonly. This creates early dialog 2.
5. PortaSIP resends it to John.
6. John’s phone starts playing the early media from dialog 2.
7. John hears ringback tones.
8. Peter answers and their conversation starts.