Call process/supported services

For simplicity all diagrams below depict the registration process as a single step. Technically, registrations as well as call initiations are performed in three steps. Read more in the User authentication chapter.

Below is a brief description of the steps followed when an IP phone reaches PortaSIP and attempts to register:

1. IP phone sends a registration request to PortaSIP.
2. PortaSIP forwards the received information to PortaBilling for authentication. PortaBilling verifies the account information to see whether service is allowed for this account and whether the correct password is used.
3. PortaBilling returns the result to PortaSIP. If authentication is successful, PortaSIP saves information about IP phone registration into the database.
4. PortaSIP sends confirmation to the IP phone that it has been registered.
   If PortaBilling denies account registration (due to wrong account information, a blocked account, etc.), the IP phone will still be informed that it is registered (SIP response code 200) although in reality it is not, and the phone will not be able to use the service. On the first call attempt the user will be informed of the actual state of their account via the voce application. This is done to avoid brute-force attacks using registration requests.

Now you can see the account as registered on the PortaBilling web interface.

A customer purchases your VoIP services, and two of his employees, A and B, are assigned SIP phone numbers 12027810003 and 12027810009, respectively. For convenience, the administrator creates two abbreviated dialing rules: 120 for 12027810003 and 121 for 12027810009. Also, they set up standard US dialing rules, so that users can dial local numbers in the 202 area code by just dialing a 7-digit phone number.

1. User A dials user B’s number (121). Their SIP user agent sends an INVITE request to PortaSIP.
2. PortaSIP sends an authorization request to PortaBilling to perform several operations:
   • Check that such an account exists, that it is not blocked/expired, that the supplied password is correct, that the account is allowed to use SIP services, etc.
   • Perform a dialed number translation according to the customer dialing rules or abbreviated dialing table (121 is converted to 12027810009).
   • Check if user A is actually allowed to call that number and what is the maximum allowed call duration based on the current balance and price per minute.
   • Check whether the number dialed is one of our SIP accounts.
3. Based on the results of the above operations, PortaBilling sends an authorization response to PortaSIP with the instruction to deliver the call to the account contact address. PortaSIP checks its registration database to find the actual contact address of the SIP user agent with that number and the NAT status of both SIP phones.
4. PortaSIP sends an INVITE to the SIP user agent for user B.

   If one of the SIP phones is behind a NAT, PortaSIP instructs SIP phones to send a voice stream via the RTP proxy. Otherwise, PortaSIP instructs A and B’s user agents to send a voice stream directly to each other.

5. The call between users A and B is established.
   • After the call is established, PortaSIP starts the call timer, disconnecting the call once the maximum call duration is reached.
   • After the call is completed, PortaSIP sends accounting information for the call to PortaBilling.

1. User A dials user B’s number (121). Their SIP user agent sends an INVITE request to PortaSIP.
2. PortaSIP sends an authorization request to PortaBilling to perform several operations.
   • Check that such an account exists, that it is not blocked/expired, that the supplied password is correct, that the account is allowed to use SIP services, etc.
   • Perform a dialed number translation according to the customer dialing rules or abbreviated dialing table (121 is converted to 12027810009).
   • Check if user A is actually allowed to call that number and what is the maximum allowed call duration based on the current balance and price per minute.
   • Check whether the number dialed is one of our SIP accounts.
3. Based on the results of the above operations, PortaBilling sends an authorization response to PortaSIP with the instruction to deliver the call to the account contact address. PortaSIP checks its registration database to find the actual contact address of the SIP user agent with that number and the NAT status of both SIP phones.
4. Since the registration information isn’t found in the database, PortaSIP performs one of the following:
   • Returns the error to the user A, so the call fails.
   • Redirect the call, e.g., to forward the call to the mobile phone number, if user B has call forwarding enabled.
   • Launches the voicemail application, if user B has unified messaging services enabled. Thus, user A can leave a message for user B.

   The same thing would happen if user B were online, but not answering the call.

Let’s say you have a termination agreement with X-Telecom to send calls to the US and Canada. This would then be configured as a VoIP to vendor connection in PortaBilling, with the remote address being the address of the vendor’s SIP server.

1. User A dials the phone number of user B. Their SIP user agent sends an INVITE request to PortaSIP
2. PortaSIP sends an authorization request to PortaBilling to check if user A is allowed to call user B.
3. The call is authorized successfully and PortaBilling sends an authorization response to PortaSIP with the instruction to deliver the call to the IP address of the vendor’s SIP server in the route information.
4. PortaSIP sends an INVITE request to that address (providing the proper credentials), and then proceeds in basically the same way as if it were communicating directly with B’s SIP user agent.
   • After the call is established, PortaSIP starts the call timer, disconnecting the call once the maximum call duration is reached.
   • After the call is completed, PortaSIP sends accounting information for the call to PortaBilling.

Let’s say the company SmartDesign, the customer using PBX services, purchases an extra DID number (18005551234) to serve as their main office number. An account with ID 18005551234 is created and the auto attendant service is enabled for it. This account will not be provisioned on any IP phone, since the goal is to let the IVR handle the call. The customer logs in to the self-care interface and configures the desired menu structure – which announcements should be made, which extensions/hunt groups calls should be forwarded to, etc.

1. User A wishes to call the SmartDesign company. He dials the company’s phone number 18005551234 from their mobile phone.

   The call is routed through the network of the carrier providing the services to user A, and then possibly via some transit operators. Eventually, the call is delivered to the DID consolidator X-Telecom, which supplies the incoming DID calls to the CSP. From the switch of the carrier X-Telecom, the call is sent to PortaSIP.

2. When an incoming call arrives at PortaSIP, PortaSIP checks the call handling rules to determine how this call should be authorized, based on the remote IP address or using the username and password. After gathering the required information, PortaSIP sends an authorization request to PortaBilling.
3. On the PortaBilling side, several operations are performed:
   • First of all, PortaBilling detects that this is a call coming from a “Calls from Vendor via SIP” connection that belongs to X-Telecom.
   • Then PortaBilling checks that an account (or account alias) with ID 18005551234 exists, meaning that this number indeed belongs to one of the customers; otherwise, the authorization fails and the call is dropped.
   • Since the account 18005551234 has the auto attendant service enabled, and this is not provisioned on any IP phone, PortaBilling returns the authorization response instructing PortaSIP to make internal routing to the IVR.
4. PortaSIP connects the incoming call and based on the number called (18005551234), retrieves its configuration settings (e.g., auto attendant activated for this number, voice prompts for menus, etc.).
   • The auto attendant IVR application starts up, plays the menu prompts (e.g., “Welcome to SmartDesign! Please press 1 for sales and 2 for technical support”), and collects the user’s input.
   • If, after navigating the menu structure, user A chooses the option of being transferred to one of the extensions in the PBX environment, PortaSIP establishes a new outgoing call.
   • When an employee of SmartDesign answers the call on that extension, PortaSIP connects this call portion with the incoming call from user A.