Call process / Supported services

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

• PortaSIP receives a registration request from the IP phone (1).
• PortaSIP sends a challenge to the IP phone (this is done instead of having the phone send a password over the Internet) (2).
• The IP phone sends a reply, including a response to the challenge as calculated by the IP phone. PortaSIP forwards the received information to PortaBilling (3).
• PortaBilling verifies the account information to see whether service is allowed for this account and whether the supplied password is correct, and returns the result to PortaSIP (4).
• PortaSIP checks if the IP phone is behind a NAT and enters the information in the database of IP phone registrations (5).
• PortaSIP sends confirmation to the IP phone that it has been registered (6).

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

Please note:  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 IVR.

An example:

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, he sets 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.

This is the simplest case:

• User A dials user B’s number (121). His SIP user agent sends an INVITE request to PortaSIP (1).
• PortaSIP sends an authorization request to the billing engine (2).
• The billing engine performs several operations:
  • Checks 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.
  • Performs a dialed number translation according to the customer dialing rules or abbreviated dialing table (121 is converted to 12027810009).
  • Checks if A is actually allowed to call that number and what is the maximum allowed call duration.
  • Checks whether the number dialed is one of our SIP accounts, and if it is currently registered.
  • Based on the results of the above operations, the billing engine sends an authorization response to PortaSIP (3).
• PortaSIP checks its registration database to find the actual contact address of the SIP user agent with that number.
• PortaSIP checks the NAT status of both SIP phones.
• PortaSIP sends an INVITE to the SIP user agent for user B (4).
• If one of the SIP phones is behind a NAT, PortaSIP will be instructed by the billing engine to send a voice stream via the RTP proxy. Otherwise, PortaSIP may allow A and B’s user agents to talk directly to each other.
• When the call is finished, PortaSIP sends accounting information to the billing engine.

• User A dials 121 in an attempt to reach user B. His SIP user agent sends an INVITE request to PortaSIP (1).
• PortaSIP performs authorization in the billing engine (2). The billing engine will perform number translation and determine whether the destination number is actually an account.
• The billing engine checks the registration database but finds that this account is not online at the moment. If B has unified messaging services enabled, the billing engine will return routing (3) for this call, which will be sent to the IVR Thus A will be redirected to a voicemail system and can leave a message for B (4). The same thing would happen if B were online, but not answering his phone.
• In any other case, the call will fail.

• An example: we are able to terminate calls to the US and Canada to a vendor, X-Telecom. This would then be described as a VoIP to vendor connection in the billing engine, with the remote address being the address of the vendor’s SIP server (or SIP-enabled gateway).
• The billing engine returns the IP address of the vendor’s SIP server in the route information, with login/password optional. 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 C’s SIP user agent.
• After the call is established, PortaSIP starts the call timer, disconnecting the call once the maximum call duration is exceeded.
• After the call is completed, PortaSIP sends accounting information for the call to the billing engine.

• Customer B, using PBX services, purchases an extra DID number (18005551234) to serve as his 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.
• User C wishes to call company B. He dials B’s phone number 18005551234.
• The call is routed through the telecom network of the carrier providing the services to C, 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 ITSP. From the switch of the carrier X-Telecom, the call is sent to PortaSIP.
• When an incoming call arrives to PortaSIP (1), 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 billing (2).
• 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 (3).
• PortaSIP connects the incoming call (4) 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 C chooses the option of being transferred to one of the extensions in the PBX environment, PortaSIP establishes a new outgoing call.
• When an employee answers the call on that extension, PortaSIP connects this call portion with the incoming call from user C.