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.

• User A attempts to call his co-worker, user C. C has not been assigned a SIP phone yet, thus he only has a normal PSTN phone number from the 202 area code, and A dials 3001234. A’s SIP user agent sends an INVITE request to the PortaSIP server (hereinafter referred to as SIP server) (1).
• PortaSIP sends an authorization request to the billing engine (2).
• Billing 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 (so 3001234 will be converted into 12023001234).
  • Checks if A is actually allowed to call that number, and what is the maximum allowed call duration.
  • Discovers that the destination number is off-net.
  • Computes the routing for this call to the external vendors according to their cost and preferences and the customer’s routing plan.
• Based on the results of the above operations, billing sends an authorization response to PortaSIP (3).
• PortaSIP tries to send a call to all routes returned by the billing engine sequentially, until either a connection is made or the list of routes is exhausted (4).
• When the call is finished, PortaSIP sends accounting information to the billing engine.

• 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.

• Let’s assume that T1 is connected to Qwest on our gateway GW-NY-02 in New York, where we are able to terminate calls to the US. This connection would be described as a PSTN to vendor connection. PortaSIP obtains the address of the GW-NY-02 gateway in the route information.
• PortaSIP sends an INVITE to the remote gateway (GW-NY-02).
• GW-NY-02 performs authentication on the incoming call via the remote IP address. Even if the call was actually originated by A (a dynamic IP address), but the INVITE request to GW-NY-02 arrived from PortaSIP, the PortaSIP’s IP address will be authenticated. Since PortaSIP is defined as our node, authentication will be successful.
  Remote IP authentication on the gateway is not required in this case, but is highly recommended. Otherwise, someone else might try to send calls directly to the gateway, bypassing authentication and making such calls for free.
• The call will be routed to the PSTN on the gateway.
• 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 two VoIP call legs to the billing engine. The gateway will also send accounting information about the answer/VoIP and originate/Telephony call legs. The billing engine will combine this information, since accounting from the SIP server allows us to identify who made the call, while accounting from the gateway carries other useful information – for example, through which telephony port the call was terminated.

This is another important aspect of SIP telephony. Your subscribers not only want to make outgoing calls, they also want other people to be able to call them on their SIP, regardless of where they are at the moment. In order to do so, you will need to obtain a range of phone numbers from your telecom operator, and make sure that calls made to these numbers on the PSTN network are routed to your gateway via the telephony interface.

• C wishes to call A. He thus dials A’s phone number (since C is in the US, he dials it using the North American format, 2027810003).
• This call is routed through the telecom network to gateway GW-NY-02. When the incoming call arrives on the gateway (1), it starts a special TCL application PSTN2SIP to handle this call. This application does several things:
  • Converts the phone number to the E.164 format, so that 2027810003 become 12027810003.
  • Performs authorization in the billing engine (2) – whether A is allowed to receive incoming telephony calls from GW-NY-01, and, if you charge for incoming calls, what is the maximum call time allowed, based on A’s current balance (3). One important point is that authorization should happen without a password check since the application does not know the valid password for the SIP account.
  • Starts outgoing call to 12027810003.
  • Starts the timer once the call is established, disconnecting the call when the maximum call duration is exceeded.
  • The gateway is configured such that it knows that calls to 1202781…. numbers should be sent to the PortaSIP server, thus it sends an INVITE to PortaSIP (4).
    The gateway cannot make this call “on behalf” of A, since even if we know A’s account ID, we do not know A’s password; therefore, such a call will be rejected. In addition, Cisco gateways currently do not support INVITE with authorization.
• PortaSIP receives the INVITE, but without authorization information. So PortaSIP performs authentication based on the IP address (5), (6). Since this call is made from our trusted node – gateway GW-NY-02 – the call is authorized.
• PortaSIP checks if the SIP user agent of the dialed number (12027810003) is registered at the time. If yes, a call setup request is sent (7).
• If the dialed number belongs to a SIP account with unified messaging services enabled, but this account is not online at the moment or does not answer, the call will be redirected to a voicemail system.
• After the call is completed, PortaSIP sends accounting information for the two VoIP call legs to the billing engine. The gateway will also send accounting information about the answer/Telephony and originate/VoIP call legs. The billing engine will combine this information, since accounting from the SIP server allows us to recognize that the call was terminated directly to the SIP user agent, and not to a vendor, while accounting from the gateway will contain information as to which account should be billed for this call.

In the previous section, we discussed traditional PSTN to SIP service when a call is delivered to your gateway via E1/T1 lines and then forwarded to a SIP phone. This service scheme assumes direct interconnection with the telco that owns DID numbers.

Establishing such direct interconnections with every telco from which you would like to get phone numbers can be problematic (e.g., if you want to give your customers the ability to choose a phone number from any European country, you will need many gateways in different places). Fortunately, however, there are more and more companies that offer incoming DID service, e.g., they already have an interconnection with a specific telecom operator, and so can forward incoming calls on these numbers to you via IP. Thus, no extra investment is required to provide phone numbers from a certain country or area, except signing a contract with such a “DID consolidator”.

• C wishes to call A on his German phone number. He thus dials A’s phone number (since C is in the US, he dials it using the North American format, 0114929876543).
• The call is routed through the telecom network to the gateway of DID consolidator X-Telecom (1).
• X-Telecom in turn forwards this call to your PortaSIP server (2).
• PortaSIP receives an incoming VoIP call and sends an authorization request to the billing engine (3).
• The billing engine detects that this call is coming via a “VoIP from Vendor” connection, so it initiates a special authorization for this call: the call will be billed to the account which receives it. Thus, the maximum call time duration is calculated based on A’s current balance. In the authorization response, PortaSIP is instructed to send the call to A’s SIP phone 12027810003 (4).
• PortaSIP sends a call setup request to the SIP phone (5).
• If the dialed number belongs to a SIP account with unified messaging services enabled, and the account is not online at the moment or does not answer, the call will be redirected to a voicemail system.

After the call is completed, A is charged for it; also, costs are calculated for the incoming call according to the tariff associated with X-Telecom’s “VoIP from Vendor” connection.

• The service provider wants to allow customers to access an IVR application (e.g., to check their voicemail from an external phone line). The number to be dialed by users (e.g., 18005555865 – 1800-555-5VML) is purchased from the DID provider.
• The administrator creates a new record in the Entry point section in PortaBilling, assigning the “Voicemail Access (with PIN protection)” application to 18005555865, and configures the parameters of the application, if necessary.
• Customer C wishes to check his voice messages while out of the office; he dials 18005555865 from his mobile phone.
• The call is routed through the telecom network of the cellular 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 incoming DID calls to the ITSP. From X-Telecom’s switch, the call is sent to PortaSIP.
• When an incoming call arrives at PortaSIP (1), PortaSIP checks the call handling rules to determine how this call should be authorized, e.g., 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 “VoIP from Vendor” connection that belongs to X-Telecom.
  • Then PortaBilling detects that there is a record in the Entry point section which designates 18005555865 as a special IVR application number.
  • PortaBilling sends the authorization confirmation, which includes the internal routing to the IVR back to PortaSIP (3).
• PortaSIP connects the incoming call and, based on the number called (18005555865), launches the “Voicemail Access” application.
• The application prompts the user to enter a mailbox ID (his phone number on the VoIP network) and PIN. Upon successful authentication, he can listen to his messages in the same way as he would from his IP phone.

• 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.